DataTrends LATAM

Categoría: Data Governance

  • Gemini 4 Argon de Google y el desafío de gobernar flujos de IA de larga duración

    Gemini 4 Argon de Google y el desafío de gobernar flujos de IA de larga duración

    Los modelos de IA capaces de ejecutar flujos de trabajo autónomos durante horas o días no son un problema de ingeniería: son un problema de gobernanza de datos. El lanzamiento de Gemini 4 Argon por parte de Google fuerza a los equipos de datos a repensar qué significa “controlar” un proceso cuando el agente toma decisiones encadenadas sin intervención humana entre cada paso.

    Gemini 4 Argon fue diseñado específicamente para sostener flujos de trabajo de agentes de IA que se extienden en el tiempo —lo que la industria llama long-running agentic workflows— con capacidad para mantener contexto, ejecutar subtareas y operar sobre múltiples fuentes de datos de forma secuencial. A diferencia de una consulta puntual a un modelo de lenguaje, estos flujos pueden durar minutos, horas o incluso días, tomando decisiones intermedias sobre qué datos consultar, transformar o escribir. Ese ciclo extendido es exactamente lo que los marcos de gobernanza tradicionales no contemplaron.

    Por qué los flujos agentivos rompen los controles de data lineage existentes

    El concepto de data lineage —trazabilidad del origen, movimiento y transformación de un dato a lo largo de su ciclo de vida— asume, en la mayoría de las implementaciones actuales, que los procesos son discretos y auditables en tiempo razonable. Un pipeline ETL tiene un inicio, una transformación documentada y un destino. Un agente de IA que opera durante horas genera decisiones intermedias que no quedan registradas en ningún catálogo de datos si la arquitectura no fue diseñada para capturarlas. El resultado es un agujero negro de linaje: se sabe de dónde partió el proceso y dónde terminó, pero no qué datos intermedios influyeron en cada decisión.

    Según el marco DAMA-DMBOK, la trazabilidad es uno de los once dominios de conocimiento de gestión de datos y está directamente vinculada a la confiabilidad del dato para la toma de decisiones. Cuando un agente de IA actúa como transformador dinámico —no como un script predecible— ese dominio queda sin cobertura real a menos que se instrumente el modelo desde el diseño. El EDM Council, en su estándar CDMC (Cloud Data Management Capabilities), lista el control de acceso granular y la auditabilidad como capabilities de nivel 8, justamente las más difíciles de mantener cuando el ejecutor del proceso es un modelo generativo.

    El problema de ownership cuando el agente escribe, no solo lee

    La distinción entre lectura y escritura de datos es central para cualquier esquema de data stewardship. Los data stewards —los responsables operativos de la calidad, clasificación y uso adecuado de un conjunto de datos dentro de un dominio— pueden supervisar pipelines que consumen datos, pero la situación se complica cuando el agente también produce o modifica registros. Un flujo de Gemini 4 Argon que, por ejemplo, enriquece un CRM con datos de fuentes externas, clasifica registros y actualiza campos de manera autónoma está ejerciendo funciones que hasta ahora correspondían a un proceso controlado por un humano o un script revisado. ¿A qué steward le pertenece ese output? ¿Quién valida la calidad del dato generado?

    Bob Seiner, referente de Non-Invasive Data Governance, argumenta que la gobernanza efectiva no requiere nuevos roles sino extender la accountability de los existentes hacia los procesos que los afectan. Aplicado aquí: el steward del dominio CRM debería tener visibilidad sobre qué transformaciones realizó el agente y con qué criterio, lo que exige instrumentación explícita en la capa de orquestación del modelo.

    Cuándo aplica este desafío — y cuándo no

    Este problema de gobernanza es relevante cuando el flujo agentivo opera sobre datos regulados, clasificados como sensibles o que alimentan decisiones con impacto en personas. No aplica de la misma manera a agentes que solo consumen datos públicos o ejecutan tareas de bajo impacto sin persistencia. La diferencia práctica: si el output del agente va a un sistema de registro (ERP, CRM, data warehouse, lago de datos), la gobernanza es obligatoria; si el output es efímero y no persiste, el riesgo de linaje es menor aunque no nulo.

    En América Latina, este umbral tiene implicancias regulatorias directas. Las empresas sujetas a la Lei Geral de Proteção de Dados (LGPD) en Brasil deben ser capaces de demostrar, ante la Autoridade Nacional de Proteção de Dados (ANPD), qué tratamientos automatizados se realizan sobre datos personales y con qué base legal. Un flujo agentivo que procesa datos personales sin trazabilidad auditada pone a la organización en incumplimiento del artículo 20 de la LGPD, que reconoce el derecho a la revisión de decisiones automatizadas. En Argentina, la situación es análoga bajo la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP), aunque el marco de decisiones automatizadas está menos desarrollado normativamente que en Brasil.

    Tres controles que un CDO debe instrumentar antes de habilitar flujos agentivos en producción

    La habilitación de modelos como Gemini 4 Argon en entornos empresariales no puede quedar librada a los equipos de ingeniería sin una política de gobernanza explícita. Los controles mínimos que un Chief Data Officer debe exigir antes de poner un flujo agentivo de larga duración en producción incluyen:

    • Registro de decisiones intermedias: cada acción del agente sobre un conjunto de datos —lectura, transformación, escritura— debe quedar logueada en un sistema de auditoría externo al modelo, no solo en los logs nativos del proveedor cloud.
    • Clasificación de datos en scope: antes de lanzar el flujo, el catálogo de datos debe marcar explícitamente si los datasets involucrados contienen datos personales, datos regulados o datos de alta criticidad para el negocio. Si el catálogo no tiene esa clasificación, el flujo no debería habilitarse.
    • Steward asignado al output: cada dataset producido o modificado por el agente debe tener un data steward nombrado que valide la calidad y el uso adecuado del resultado antes de que se propague a sistemas downstream.

    Estos controles no son exclusivos de Gemini 4 Argon: aplican a cualquier framework agentivo, incluyendo los basados en modelos de Anthropic, OpenAI o soluciones open-source como LangGraph. La particularidad de Argon es que su capacidad extendida de contexto y duración eleva el riesgo de linaje a una escala que los controles actuales de la mayoría de las organizaciones latinoamericanas no están preparados para cubrir.

    Para profundizar en los marcos de referencia aplicables, el CDMC del EDM Council (edmc.net/cdmc) y el capítulo de Data Quality del DAMA-DMBOK son los puntos de partida más robustos para estructurar una política de gobernanza sobre flujos agentivos.

  • Registros municipales de McMinnville quedaron expuestos en línea sin protección

    Registros municipales de McMinnville quedaron expuestos en línea sin protección

    Un especialista en ciberseguridad detectó que registros sensibles del municipio de McMinnville, Oregon, estaban accesibles públicamente en línea sin ningún control de acceso. Según se informó, los archivos expuestos incluían información personal de residentes y fueron descriptos por el investigador como “un tesoro de información”.

    El hallazgo fue reportado por KOIN.com a partir de la alerta de un especialista en ciberseguridad que identificó los registros municipales expuestos. No se precisó en la información disponible cuánto tiempo estuvieron accesibles los archivos ni si terceros no autorizados accedieron a ellos antes de que el problema fuera detectado. La ciudad de McMinnville no había emitido una declaración pública confirmada al momento del reporte.

    Datos confirmados sobre la exposición

    • Actor afectado: municipio de McMinnville, Oregon, Estados Unidos.
    • Tipo de datos: registros municipales sensibles con información personal de residentes, según se informó.
    • Método de detección: alerta de un especialista externo en ciberseguridad.
    • Acceso no autorizado confirmado: no verificado al momento de la publicación.
    • Fecha de reporte público: 1 de octubre de 2025.

    Qué se sabe y qué falta confirmar

    Lo confirmado es que los registros estaban disponibles en línea sin restricciones de acceso y que el problema fue identificado por un tercero, no por el propio municipio. Lo que permanece sin confirmar incluye el volumen exacto de registros expuestos, el período de exposición, la naturaleza precisa de los datos comprometidos y si hubo descarga o exfiltración por parte de actores maliciosos. Tampoco se ha informado si el municipio notificó formalmente a los ciudadanos afectados ni bajo qué marco legal deberá hacerlo.

    En términos de gobernanza, el incidente ilustra una falla en la clasificación y el control de acceso sobre activos de datos públicos: el dato estaba accesible porque nadie tenía asignada la responsabilidad de garantizar que no debía estarlo. En organismos equivalentes de América Latina, este tipo de exposición activaría obligaciones de notificación bajo marcos como la Ley 25.326 en Argentina —que exige comunicar a la Agencia de Acceso a la Información Pública (AAIP) ante incidentes que afecten bases de datos registradas— o la Lei Geral de Proteção de Dados (LGPD) en Brasil, que establece plazos de notificación a la Autoridade Nacional de Proteção de Dados (ANPD) en un máximo de dos días hábiles desde el conocimiento del incidente cuando existe riesgo relevante.

    El próximo hito crítico es la determinación oficial por parte del municipio de McMinnville sobre si existió exfiltración, dato que definirá si se activan obligaciones formales de notificación a los residentes afectados.

  • “AI Ready” es un eslogan vacío: lo que realmente importa es la calidad del dato

    “AI Ready” es un eslogan vacío: lo que realmente importa es la calidad del dato

    Declararse “AI ready” se convirtió en un ritual corporativo que rara vez sobrevive al primer audit de datos. La promesa de estar preparado para la inteligencia artificial se derrumba sistemáticamente en tres frentes concretos: calidad del dato, gobernanza operativa y confianza institucional en los sistemas de información.

    El término “AI ready” proliferó en presentaciones de directorio y comunicados de prensa durante los últimos dos años, pero en la práctica funciona más como señal de aspiración que como diagnóstico técnico. Cuando los equipos de datos intentan construir un pipeline de machine learning o desplegar un modelo de lenguaje sobre datos corporativos, el primer obstáculo no es el algoritmo: es el estado real del dato subyacente. Duplicados, registros incompletos, esquemas inconsistentes entre sistemas heredados y ausencia de un data owner identificable son los bloqueos más frecuentes que reportan los equipos de ingeniería en organizaciones que se autoproclaman preparadas.

    Calidad de datos: el prerequisito que nadie quiere medir

    La calidad del dato no es un atributo binario. El marco DAMA-DMBOK v2 distingue al menos seis dimensiones relevantes: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Un modelo de IA entrenado o inferido sobre datos que fallan en dos o más de esas dimensiones produce outputs que amplifican los errores de origen, no los corrigen. El problema operativo para un CDO es que la mayoría de las organizaciones no tienen una línea de base medida para ninguna de esas dimensiones. Sin medición, la autoevaluación de “AI readiness” es subjetiva por definición.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), sitúa la gestión de calidad en las capabilities 5 y 6 de su modelo de madurez. Organizaciones que no han formalizado esas capabilities difícilmente pueden sostener que sus datos son aptos para alimentar sistemas de IA de manera confiable. La certificación CDMC no es un requisito universal, pero sus categorías sirven como checklist diagnóstico independiente del proveedor de nube o de plataforma.

    Gobernanza sin data stewards activos es decorativa

    El segundo vector de falla es la gobernanza. Muchas organizaciones tienen políticas documentadas, un comité de datos en papel y un catálogo de datos parcialmente poblado. Pero si no existe un data steward con responsabilidad operativa sobre cada dominio crítico —y con tiempo real asignado para esa función, no como tarea residual—, la gobernanza no escala cuando la IA la exige. Bob Seiner, referente en Non-Invasive Data Governance, señala que la gobernanza efectiva requiere asignar responsabilidad sobre el dato a quien ya toma decisiones sobre él, no crear una capa burocrática paralela. En contextos de IA, esa asignación se vuelve urgente porque los modelos consumen datos de múltiples dominios simultáneamente y el data lineage —la trazabilidad del dato desde su origen hasta el output del modelo— debe ser reconstruible para auditar resultados.

    En América Latina, este déficit tiene consecuencias regulatorias concretas. Los bancos colombianos sujetos a las circulares de la Superintendencia Financiera sobre gestión de riesgo operativo, y las entidades financieras brasileñas bajo la Resolução CMN 4.557, están obligadas a documentar los datos que alimentan modelos de decisión crediticia. Si el data lineage no existe o está incompleto, el cumplimiento regulatorio es formal pero no sustantivo. El Banco Central de Brasil ya incorporó en su agenda supervisora el uso de modelos algorítmicos, y la CNBV en México avanza en lineamientos similares para fintech. Declararse “AI ready” sin linaje documentado en esos contextos es un riesgo regulatorio concreto, no solo un problema de madurez interna.

    Confianza institucional: cuándo aplica y cuándo no

    El tercer componente —confianza— es el menos tangible pero el que más frecuentemente determina si un proyecto de IA llega a producción o muere en piloto. La confianza en este contexto tiene dos dimensiones: confianza técnica (¿el equipo de negocio cree que el dato es correcto?) y confianza institucional (¿los usuarios del sistema aceptarán las recomendaciones del modelo?). Ambas se construyen con transparencia sobre las limitaciones del dato, no con afirmaciones de exactitud que luego se contradicen en el uso diario.

    La confianza técnica se gana mostrando métricas de calidad accesibles para usuarios no técnicos —dashboards de completitud por dominio, tasas de error en validaciones, antigüedad promedio del dato—. La confianza institucional requiere que los data stewards y los responsables de negocio participen activamente en la validación de los datos de entrenamiento antes del despliegue del modelo, no después del primer incidente.

    Cuándo aplica “AI ready” y cuándo no

    El concepto tiene sentido como objetivo de roadmap, no como estado presente. Una organización puede afirmar que trabaja hacia la preparación para IA si tiene: (a) una línea de base medida de calidad del dato en al menos sus dominios críticos, (b) data stewards asignados con mandato formal sobre esos dominios, y (c) un catálogo de datos activo con linaje documentado para los procesos que serán automatizados. Sin esos tres elementos simultáneos, “AI ready” describe una intención, no una capacidad.

    No aplica —y el término resulta contraproducente— cuando se usa para justificar inversiones en infraestructura de IA antes de resolver los problemas de datos subyacentes. Comprar una plataforma de MLOps o un contrato empresarial con un proveedor de modelos fundacionales no resuelve la calidad del dato de origen. La secuencia importa: primero gobernanza, después arquitectura, después modelos.

    Tres verificaciones concretas antes del próximo comité de datos

    Para un CDO que necesita evaluar el estado real de su organización, tres preguntas operativas son más útiles que cualquier encuesta de madurez:

    • ¿Podés identificar, en menos de 48 horas, el data steward responsable de cada dominio de datos que alimentaría el primer caso de uso de IA priorizado?
    • ¿Tenés una métrica de completitud y exactitud medida en los últimos 90 días para esos dominios, con un benchmark definido como umbral de aceptación?
    • ¿El linaje de datos desde el sistema fuente hasta el punto de consumo del modelo está documentado y es auditable por un tercero —regulador, auditor externo o equipo de riesgo interno?

    Si alguna de las tres respuestas es “no” o “parcialmente”, el roadmap de IA necesita un paso previo de gobernanza, no un paso adicional de tecnología. El DAMA-DMBOK y el CDMC del EDM Council ofrecen marcos de referencia públicos para estructurar ese diagnóstico sin depender de consultoras externas.

    Para profundizar en los estándares de referencia: el DAMA-DMBOK v2 está disponible en dama.org y el marco CDMC del EDM Council puede consultarse en edmcouncil.org; ambos son el punto de partida obligado para cualquier diagnóstico serio de preparación para la IA.

  • Databricks CustomerLake: gobernanza de datos de clientes en la banca

    Databricks CustomerLake: gobernanza de datos de clientes en la banca

    Databricks anunció CustomerLake, una solución diseñada para que los bancos centralicen y gobiernen los datos de sus clientes dentro de su propio entorno de datos, sin ceder el control a plataformas de CRM externas. La propuesta reactiva un debate que el sector financiero nunca cerró del todo: quién es el dueño real del dato del cliente y quién responde cuando ese dato falla.

    CustomerLake parte de una premisa operativa concreta: los bancos acumulan décadas de datos transaccionales, de comportamiento y de contacto dispersos en silos —core bancario, CRM, canales digitales, call center— sin un modelo de gobernanza que los unifique bajo un data owner identificable. La propuesta de Databricks es construir esa capa de unificación sobre el lakehouse propio de la institución, manteniendo los datos bajo la jurisdicción y el control de la entidad financiera, no del proveedor de CX.

    Qué hace CustomerLake y por qué importa en banca

    La arquitectura de CustomerLake, según se informó, combina capacidades de ingesta unificada, resolución de identidad de clientes (identity resolution) y perfilado en tiempo real, todo dentro del entorno de datos del banco. El punto de diferenciación frente a soluciones de Customer Data Platform (CDP) tradicionales es que el dato nunca abandona el lakehouse de la institución: no hay sincronización hacia un SaaS de terceros que almacene una copia del perfil del cliente. Para los equipos de gobernanza de datos, eso cambia el mapa de riesgo de forma sustancial: el data lineage —la trazabilidad del dato desde su origen hasta su uso en una campaña o en una decisión crediticia— queda bajo control interno, auditable con las herramientas que ya tiene el banco.

    Desde la perspectiva del DAMA-DMBOK, esta arquitectura aborda directamente dos capability areas críticas: Data Integration & Interoperability y Data Security. La resolución de identidad centralizada elimina duplicados y perfiles fragmentados, que son una de las causas raíz más frecuentes de problemas de calidad en datos de clientes bancarios. Un perfil duplicado no es solo un problema de marketing; en banca es un riesgo de cumplimiento: puede implicar KYC incompleto, alertas de prevención de lavado mal asignadas, o comunicaciones regulatorias enviadas a la dirección equivocada.

    Cuándo aplica CustomerLake y cuándo no

    CustomerLake aplica cuando el banco ya opera sobre Databricks o está en proceso de consolidar su arquitectura de datos en un lakehouse. No es una solución autónoma: presupone que existe —o se está construyendo— un Data Governance Council con capacidad de definir data domains, asignar data stewards por dominio (clientes, productos, riesgo) y mantener un catálogo activo. Si la institución no tiene ese andamiaje de gobernanza, CustomerLake entrega infraestructura técnica sin el modelo operativo que la hace funcionar. La herramienta resuelve el “dónde vive el dato”; no resuelve el “quién responde por él”.

    Tampoco es la respuesta correcta para bancos medianos o cooperativas de crédito que no tienen equipo de ingeniería de datos propio. En esos casos, el costo operativo de mantener un lakehouse gobernado supera los beneficios de tener el dato in-house frente a una CDP SaaS con controles contractuales sólidos.

    El flanco regulatorio en Argentina, Brasil y México

    Para la banca latinoamericana, la propuesta de CustomerLake no es solo una decisión de arquitectura: es una decisión regulatoria. En Argentina, las entidades financieras supervisadas por el BCRA deben cumplir la Comunicación A 7724 y sus actualizaciones sobre gestión de riesgo tecnológico, que exigen trazabilidad sobre los sistemas que procesan datos de clientes. Transferir datos de clientes a un SaaS offshore implica, en muchos casos, informar a la autoridad de control y cumplir con los requisitos de localización o de acuerdo de transferencia que establece la Ley 25.326 y su decreto reglamentario. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que el controlador —el banco— pueda demostrar una base legal para cada tratamiento y responder ante la ANPD en caso de incidente; si el dato está en manos de un procesador externo sin contrato de procesamiento adecuado, esa demostración se complica. En México, la LFPDPPP y la regulación sectorial de la CNBV imponen obligaciones similares sobre el responsable del tratamiento. Mantener el dato dentro del entorno propio simplifica esa cadena de accountability, aunque no la elimina: el banco sigue siendo responsable de lo que hace con el dato, independientemente de dónde lo almacene.

    Lo que un CDO bancario necesita definir antes de implementar

    Antes de evaluar CustomerLake como solución, un Chief Data Officer del sector financiero debería tener respuestas operativas a tres preguntas: primero, ¿existe un data domain “cliente” formalmente definido, con un data steward asignado y métricas de calidad activas? Segundo, ¿el catálogo de datos corporativo registra hoy qué sistemas son fuente de verdad (system of record) para cada atributo del perfil del cliente —nombre, dirección, score de riesgo, historial de contacto? Tercero, ¿el equipo legal tiene mapeados los flujos de datos de clientes hacia terceros, con los contratos de procesamiento de datos actualizados según la regulación local? Si alguna de esas tres respuestas es “no” o “parcialmente”, la prioridad no es la herramienta: es el modelo de gobernanza que la herramienta va a ejecutar. CustomerLake puede acelerar la implementación técnica, pero el diseño del data ownership es una decisión institucional que ningún proveedor puede tomar por el banco.

    La especificación técnica de CustomerLake está disponible en la documentación oficial de Databricks; los marcos de referencia para el diseño del modelo de gobernanza pueden consultarse en el DAMA-DMBOK (segunda edición) y en el CDMC del EDM Council, que incluye controles específicos para datos de clientes en industrias reguladas.

  • OpenAI lanza Dots: qué preguntas de gobernanza de datos plantea

    OpenAI lanza Dots: qué preguntas de gobernanza de datos plantea

    OpenAI presentó Dots, un sistema diseñado para que los modelos de inteligencia artificial retengan contexto personalizado entre sesiones. La capacidad de persistir información sobre usuarios individuales abre interrogantes concretos sobre propiedad del dato, clasificación, retención y auditoría que los equipos de gobernanza de datos no pueden diferir.

    Dots funciona como una capa de memoria estructurada: en lugar de que cada conversación comience desde cero, el modelo extrae y almacena fragmentos de contexto —preferencias, instrucciones recurrentes, datos de comportamiento— para recuperarlos en interacciones futuras. Desde la perspectiva de un Chief Data Officer, esto no es una mejora de experiencia de usuario sino un nuevo repositorio de datos con ciclo de vida propio, sin que la mayoría de las organizaciones hayan definido quién es el data steward responsable de ese almacén ni cómo se integra al catálogo corporativo.

    Qué tipo de dato genera Dots y por qué importa clasificarlo hoy

    El contenido que Dots retiene puede incluir desde preferencias operativas hasta información inferida sobre comportamientos o roles organizacionales. Según el DAMA-DMBOK, la clasificación es el primer control del ciclo de vida del dato: sin saber qué categoría ocupa un fragmento de memoria persistida, no es posible aplicar controles de acceso, políticas de retención ni reglas de eliminación. Si un empleado le indica a un agente de IA cuál es su área de negocio, su nivel jerárquico o las herramientas que usa, esa información inferida puede calificar como dato personal bajo la Ley 25.326 en Argentina, la LGPD brasileña o la LFPDPPP mexicana, independientemente de que el almacenamiento ocurra en infraestructura de OpenAI.

    La distinción no es trivial. Bajo la LGPD (Lei 13.709/2018), el controlador —la empresa que despliega la herramienta— es responsable de garantizar que el operador (en este caso, OpenAI como proveedor) trate los datos conforme a las instrucciones contractuales. Si Dots almacena datos de colaboradores sin que exista una cláusula de data processing agreement que contemple específicamente la retención de memoria persistente, la empresa está operando fuera del marco del contrato de tratamiento.

    Data lineage y el problema del contexto opaco

    Uno de los desafíos de gobernanza más inmediatos que presenta Dots es el data lineage, es decir, la trazabilidad del origen y transformación de cada fragmento de dato. En un flujo tradicional, un dato entra por un sistema fuente, se transforma en pipelines auditables y llega a un destino documentado. Con memoria persistente en un modelo de lenguaje, la extracción del contexto es semideterminista: el modelo decide qué retener y qué descartar según criterios que no son completamente transparentes para el operador empresarial. Esto rompe la cadena de linaje y dificulta responder ante una solicitud de acceso o supresión bajo cualquier régimen de derechos ARCO.

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica la capacidad de rastrear datos personales a través de sistemas de terceros como uno de los requerimientos centrales para organizaciones que operan en la nube. Los bancos colombianos sujetos a la Circular Externa 029 de la SFC, o las entidades financieras argentinas bajo la Comunicación A 8073 del BCRA, ya deben demostrar trazabilidad de datos sensibles en proveedores cloud. Un sistema de memoria de IA no certificado bajo esos esquemas representa un gap de control documentable.

    Cuándo aplica el riesgo de gobernanza y cuándo no

    No toda implementación de Dots genera el mismo nivel de exposición. El riesgo es alto cuando: (1) los usuarios finales son empleados que interactúan con información corporativa confidencial o datos de clientes; (2) la organización opera en sectores regulados —salud, finanzas, educación— donde la retención no autorizada tiene consecuencias específicas; o (3) no existe un data processing agreement actualizado con OpenAI que cubra explícitamente la funcionalidad de memoria persistente. El riesgo es bajo o gestionable cuando el uso se limita a entornos sandbox sin datos reales, cuando se activa la opción de deshabilitar la memoria (si OpenAI la provee a nivel enterprise), o cuando el flujo de datos ya está cubierto por un DPA vigente y revisado por el equipo legal.

    La distinción importa porque la respuesta operativa es diferente: en el primer escenario, la acción es bloquear o restringir el despliegue hasta cerrar los gaps contractuales y de clasificación; en el segundo, alcanza con documentar el análisis de riesgo en el registro de actividades de tratamiento que exigen tanto el artículo 31 del GDPR como sus equivalentes en LGPD y Ley 25.326.

    Tres acciones concretas para equipos de gobernanza ante el lanzamiento de Dots

    • Revisar el inventario de sistemas de IA corporativos e identificar cuáles utilizan o planean utilizar OpenAI con funcionalidades de memoria activa; asignar un data steward responsable para cada caso.
    • Actualizar o solicitar la actualización del data processing agreement con OpenAI para que cubra explícitamente la retención de contexto, los plazos de conservación y los mecanismos de supresión, alineados con los requerimientos de la regulación local aplicable.
    • Incorporar en el catálogo de datos corporativo una categoría para “datos de memoria de IA” con clasificación, nivel de sensibilidad y política de retención definida, tal como se haría con cualquier otra fuente de datos de terceros.

    La documentación técnica de Dots y los términos de servicio empresariales de OpenAI son el punto de partida obligado para cualquier análisis de brecha; el equipo de gobernanza no puede subcontratar esa lectura al área legal sin haber definido primero qué datos están en juego.

  • Calidad de datos: el requisito no negociable para que la IA funcione

    Calidad de datos: el requisito no negociable para que la IA funcione

    Los modelos de inteligencia artificial no fallan solo por arquitecturas deficientes: fallan porque los datos que los alimentan son inconsistentes, incompletos o simplemente incorrectos. La calidad del dato ha dejado de ser un problema de backoffice para convertirse en un requisito de ingeniería de IA tan crítico como la capacidad de cómputo.

    Durante años, la calidad de datos fue un ítem postergado en la agenda corporativa: algo que “había que mejorar” pero que rara vez bloqueaba proyectos. La irrupción de sistemas de IA en producción cambió esa dinámica de forma abrupta. Un modelo de lenguaje entrenado con registros duplicados, un sistema de recomendación alimentado con atributos mal clasificados, o un motor de detección de fraude que consume datos sin linaje verificable producen resultados que no solo son incorrectos, sino que pueden ser jurídicamente problemáticos en contextos regulados.

    Qué significa “calidad de datos” en un pipeline de IA

    En el marco del DAMA-DMBOK, la calidad de datos se descompone en al menos seis dimensiones: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Para un pipeline de IA, cada una de esas dimensiones tiene consecuencias directas sobre el comportamiento del modelo. Un dataset con baja completitud introduce sesgos sistemáticos hacia los segmentos mejor representados. La falta de consistencia entre fuentes provoca que el modelo aprenda contradicciones como si fueran patrones reales. La ausencia de unicidad —registros duplicados— infla artificialmente la frecuencia de ciertos eventos y distorsiona las distribuciones de entrenamiento. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), clasifica la gestión de calidad como una capability de nivel 2, es decir, prerequisito para cualquier uso avanzado de datos, incluida la IA.

    Data lineage: sin trazabilidad, no hay auditabilidad del modelo

    El data lineage —la capacidad de rastrear el origen, las transformaciones y el destino de cada dato a lo largo de su ciclo de vida— es el componente de gobernanza que más directamente habilita la auditabilidad de sistemas de IA. Sin lineaje documentado, es imposible responder preguntas regulatorias básicas: ¿con qué datos fue entrenado este modelo?, ¿esos datos eran representativos de la población objetivo?, ¿existía algún sesgo de selección en la fuente? En jurisdicciones donde los sistemas de IA de alto riesgo deben poder explicar sus decisiones —como establece el AI Act de la Unión Europea en su artículo 13— el lineaje deja de ser una buena práctica y se convierte en evidencia jurídica.

    En América Latina, el vínculo entre lineaje y cumplimiento normativo es menos explícito en los textos legales, pero ya está siendo requerido de forma implícita. El Banco Central de Brasil, por ejemplo, exige a las instituciones financieras supervisadas que demuestren la idoneidad de los modelos de riesgo crediticio que usan en sus decisiones automatizadas, lo que en la práctica demanda tener el linaje de los datos de entrenamiento disponible para inspección. En Argentina, la Comunicación A 8073 del BCRA sobre gestión de riesgo operacional establece controles sobre los modelos utilizados en procesos críticos, con implicancias directas sobre la documentación de los datos que los alimentan.

    Cuándo aplica gobernanza de datos para IA — y cuándo no

    La gobernanza de datos orientada a IA aplica con urgencia cuando una organización está entrenando o ajustando (fine-tuning) modelos propios, cuando consume APIs de modelos externos con datos internos sensibles, o cuando los outputs de IA alimentan decisiones automatizadas sobre personas (crédito, salud, contratación, seguridad). No aplica —o aplica con menor criticidad— cuando el uso de IA es puramente exploratorio, sin datos de producción, y sin impacto en procesos de negocio ni en derechos de terceros. El error frecuente es tratar ambos escenarios con el mismo nivel de exigencia, lo que genera fatiga de compliance sin reducir riesgo real.

    El rol del data steward en proyectos de IA

    Bob Seiner, referente en Non-Invasive Data Governance, sostiene que el data steward —el responsable de un dominio de datos dentro de la organización— es la figura que debe certificar la aptitud de un dataset para un caso de uso específico antes de que ese dataset ingrese a un pipeline de entrenamiento. Este rol, que en muchas organizaciones latinoamericanas todavía se ejerce de forma informal o no existe formalmente, se vuelve crítico cuando los modelos de IA empiezan a escalar. Sin un steward que valide la calidad, la relevancia y los permisos de uso de los datos, el equipo de datos o de ingeniería termina tomando decisiones de gobernanza para las que no tiene mandato ni contexto de negocio.

    La adopción de este rol en la región es desigual. Empresas de servicios financieros en México, Colombia y Brasil con exposición a reguladores internacionales (BIS, FSB) ya tienen estructuras de stewardship activas. En sectores como retail, salud privada y gobierno, el rol existe en el organigrama pero raramente tiene atribuciones formales sobre los datasets que alimentan sistemas de IA.

    Tres controles mínimos antes de poner datos en un modelo

    Las organizaciones que empiezan a formalizar su gobernanza de datos para IA no necesitan implementar un framework completo desde el día uno. Tres controles concretos reducen el riesgo de forma inmediata:

    • Perfil de calidad documentado: completitud, duplicados y distribución de valores nulos por campo, generado antes de cada ciclo de entrenamiento o actualización del modelo.
    • Registro de origen: para cada dataset en producción, un registro legible por humanos que indique fuente primaria, fecha de extracción, transformaciones aplicadas y responsable de aprobación.
    • Control de acceso por sensibilidad: clasificación del dataset según si contiene datos personales, datos financieros regulados o datos de categoría especial, con acceso restringido al equipo de IA según esa clasificación.

    Estos tres controles se alinean con las capabilities de nivel básico del CDMC del EDM Council y son auditables por cualquier regulador que solicite evidencia de diligencia debida en el uso de datos para IA.

    Para profundizar en los estándares aplicables, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los documentos de referencia más completos disponibles para equipos de gobernanza que trabajan en contextos de IA. Ambos están disponibles en sus respectivos sitios oficiales.

  • Gobernanza de datos de marketing: el eslabón que define la madurez IA

    Gobernanza de datos de marketing: el eslabón que define la madurez IA

    Las organizaciones con gobernanza sólida de sus datos de marketing tienen significativamente más probabilidades de estar preparadas para implementar inteligencia artificial y de reportar crecimiento de ingresos, según un estudio conjunto de Integrate y Demand Metric. La correlación no es accidental: sin datos confiables, los modelos de IA amplifican el error en lugar de la ventaja competitiva.

    El reporte, publicado en septiembre de 2025, analiza la relación entre la madurez en gobernanza de datos de marketing y dos variables de negocio clave: la disposición operativa para adoptar IA (AI readiness) y el crecimiento de ingresos. La conclusión central es que las empresas que invierten en calidad, consistencia y ownership de sus datos de demanda obtienen resultados superiores tanto en automatización como en desempeño comercial. No se trata de una correlación decorativa: el estudio señala que la gobernanza de datos actúa como condición habilitante para que los sistemas de IA funcionen con precisión en contextos de generación de demanda B2B.

    Qué significa “gobernanza de datos de marketing” en este contexto

    La gobernanza de datos de marketing abarca el conjunto de políticas, roles y controles que aseguran que los datos captados durante el ciclo de demanda —formularios, eventos, integraciones con CRM, datos de terceras partes— sean precisos, completos, deduplicados y rastreables hasta su origen. En términos del marco DAMA-DMBOK, esto involucra al menos tres dominios: calidad del dato (Data Quality Management), integración y gestión de metadatos (Data Integration & Interoperability), y definición de roles de data stewardship sobre los activos de marketing. Sin un data steward que valide la procedencia de un lead o que estandarice la taxonomía de campañas, cualquier modelo predictivo construido sobre esos datos hereda el ruido estructural del proceso de captura.

    Por qué la IA amplifica el problema si la gobernanza falla primero

    Los sistemas de IA aplicados a marketing —scoring de leads, personalización, atribución multitoque, forecasting de pipeline— son esencialmente funciones de los datos sobre los que se entrenan. Un modelo entrenado con datos de intención duplicados, con campos de industria inconsistentes o con leads de baja calidad mezclados con prospectos calificados produce outputs que pueden parecer sofisticados pero que reflejan las mismas distorsiones del dataset original. El NIST AI Risk Management Framework (AI RMF) identifica la calidad de los datos de entrenamiento como uno de los factores de riesgo primarios en la dimensión de “govern” del ciclo de vida de un sistema de IA. Dicho de otro modo: el riesgo de un sistema de IA que recomienda mal no es un problema del modelo, es un problema del dato.

    Cuándo aplica este enfoque — y cuándo no es suficiente

    Este vínculo entre gobernanza y AI readiness aplica con mayor fuerza en organizaciones B2B con volúmenes significativos de datos de demanda distribuidos entre múltiples plataformas: MAP (marketing automation platforms), CRM, herramientas de intent data, y fuentes externas de enriquecimiento. En esos entornos, la fragmentación de datos es la norma, y los pipelines de datos sin controles de calidad producen catálogos de contactos que se degradan a tasas de entre el 20% y el 30% anual, según estimaciones de Gartner y Forrester citadas en la industria. El enfoque pierde relevancia relativa en organizaciones muy pequeñas donde el volumen de datos no justifica una capa de governance formal; en esos casos, una simple política de higiene de CRM puede ser suficiente. Pero a medida que la organización escala y adopta herramientas de IA sobre sus datos de marketing, la ausencia de un marco de governance deja de ser una deuda técnica menor para convertirse en un limitante estructural de negocio.

    El estado de la gobernanza de datos de marketing en América Latina

    En la región, el debate sobre gobernanza de datos de marketing está aún supeditado al cumplimiento normativo, no a la habilitación de IA. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a las organizaciones a mapear el tratamiento de datos personales —incluyendo datos de marketing— y a designar un Encarregado equivalente al DPO europeo. En Argentina, la Ley 25.326 de Protección de Datos Personales impone controles similares sobre bases de contactos, y la Agencia de Acceso a la Información Pública (AAIP) ha intensificado su actividad inspectora desde 2023. En México, el INAI regula el uso de datos personales con fines comerciales bajo la LFPDPPP. Sin embargo, el cumplimiento normativo de privacidad no es sinónimo de gobernanza de datos de marketing: una empresa puede respetar el consentimiento y aun así operar con datos duplicados, sin linaje claro, y sin ownership definido por segmento de campaña. La madurez que el estudio de Integrate y Demand Metric correlaciona con AI readiness requiere ir bastante más allá del checkbox regulatorio.

    Tres capacidades de governance que un equipo de datos de marketing debería auditar primero

    • Definición de data ownership por fuente: ¿quién es el data steward responsable de los leads provenientes de eventos, de formularios web, de integraciones con plataformas de intent? Sin ownership claro, la calidad no tiene dueño.
    • Reglas documentadas de deduplicación y estandarización: criterios explícitos para consolidar registros de contacto y homogeneizar campos críticos (industria, tamaño de empresa, región) que alimentarán modelos de scoring.
    • Linaje desde la captura hasta el modelo: capacidad de rastrear un dato desde el formulario original hasta el input del sistema de IA, con registro de transformaciones intermedias. Sin este data lineage, auditar la calidad de un output de IA es prácticamente imposible.

    Estas tres capacidades corresponden a lo que el EDM Council clasifica en el nivel 2 (“Managed”) del CDMC (Cloud Data Management Capabilities), el piso mínimo para operar datos en entornos donde se aplica IA sobre decisiones de negocio con impacto en revenue.

    El reporte completo de Integrate y Demand Metric está disponible en el sitio de Demand Gen Report; la documentación técnica de referencia para las capacidades mencionadas puede consultarse en el DAMA-DMBOK (segunda edición) y en el AI RMF del NIST, ambos de acceso público.

  • Gobernanza de datos en Finanzas: del reporte a la decisión

    Gobernanza de datos en Finanzas: del reporte a la decisión

    El área de Finanzas corporativa sigue produciendo reportes que nadie cuestiona pero pocos usan para tomar decisiones reales. La diferencia entre una función financiera reactiva y una que genera valor está, cada vez más, en cómo se gobierna el dato antes de que llegue al dashboard.

    Durante décadas, el departamento de Finanzas fue el custodio de los números de la organización: cierres mensuales, estados de resultados, proyecciones de flujo de caja. Pero custodiar números no es lo mismo que gobernarlos. Un número sin contexto de origen, sin ownership claro y sin trazabilidad hacia la fuente transaccional es, en el mejor caso, un dato plausible. En el peor, es una cifra que alimenta una decisión equivocada con aspecto de rigor.

    La brecha entre el reporte y la decisión: qué falla en el medio

    El problema no es la ausencia de datos —las áreas financieras están, si acaso, sobrecargadas de ellos. El problema es estructural: los datos financieros suelen carecer de definiciones formales acordadas entre áreas, de un data steward que responda por su integridad y de un linaje (data lineage) documentado que permita rastrear cada cifra hasta su registro de origen. Cuando el CFO pregunta por qué el EBITDA del reporte de Finanzas no coincide con el que muestra el ERP, la respuesta habitual es una cadena de Excel intermedios y transformaciones manuales que nadie firmó. Eso es exactamente el déficit de gobernanza.

    El marco DAMA-DMBOK identifica diez áreas de conocimiento en gobernanza de datos, y al menos cuatro son críticas para Finanzas: calidad del dato, gestión de metadatos, data lineage y gestión del ciclo de vida del dato. En la práctica, la mayoría de las áreas financieras de empresas medianas en América Latina operan sin ninguna de las cuatro de forma formalizada. Los procesos existen —alguien concilia, alguien valida— pero no están documentados, no tienen SLA y no escalan cuando la organización crece o cuando el regulador exige trazabilidad.

    Data stewardship financiero: quién firma el dato

    La gobernanza de datos en Finanzas requiere definir, primero, quién es el data owner de cada métrica crítica. El concepto de Non-Invasive Data Governance, desarrollado por Bob Seiner, propone formalizar roles que ya existen informalmente en la organización —en lugar de crear estructuras paralelas que nadie adopta. En la práctica, eso significa que el Controller que hoy corrige manualmente las conciliaciones se convierte, formalmente, en el data steward de las cuentas por cobrar; con la diferencia de que ahora su criterio de validación queda documentado y reproducible, no encapsulado en su memoria o en una macro sin comentarios.

    Un catálogo de datos (data catalog) con las definiciones de negocio acordadas —¿qué cuenta como “venta neta”?, ¿cuándo se reconoce un ingreso?— es el artefacto más inmediato que separa a un área de Finanzas que produce reportes de una que produce decisiones. Sin esa capa semántica, cada equipo trabaja con su propia definición y el debate en el comité de dirección termina siendo sobre los números, no sobre la estrategia.

    Ecuador, Argentina y Brasil: regulación que ya exige trazabilidad financiera

    En América Latina, la presión regulatoria está acelerando esta conversación. En Argentina, el Banco Central (BCRA) exige a las entidades financieras reportes con trazabilidad explícita bajo la Comunicación A 8073 y normas concordantes de gestión de riesgos, lo que obliga a documentar el origen de cada cifra reportada. En Brasil, la Resolução CMN 4.966 y los requerimientos de IFRS 9 bajo supervisión del Banco Central do Brasil imponen estándares de calidad del dato en cartera crediticia que son, de facto, requisitos de gobernanza. En Ecuador —donde el debate sobre gobernanza de datos financieros está ganando tracción en el sector corporativo— la Superintendencia de Compañías, Valores y Seguros incorporó lineamientos de gobierno corporativo que incluyen integridad de la información financiera como dimensión evaluable.

    El punto de convergencia es el mismo en todos los casos: el regulador no acepta “el sistema lo calculó así” como respuesta. Exige un responsable humano identificable, una metodología documentada y una cadena de custodia del dato. Eso es gobernanza de datos aplicada a Finanzas, aunque no siempre se llame así.

    Cuándo aplica esta transformación y cuándo no

    La maduración de Finanzas hacia una función orientada a decisiones tiene sentido cuando la organización ya tiene volumen de datos suficiente para que la ambigüedad semántica genere fricción real —discrepancias entre áreas, tiempo perdido en conciliaciones, reportes descartados por falta de confianza. No tiene sentido como proyecto autónomo en empresas pequeñas donde un único Controller maneja el ciclo completo y el contexto es suficiente para interpretar cualquier cifra. En esos casos, el esfuerzo de formalización supera el beneficio. La señal de que es momento de actuar es simple: cuando el debate en el comité ejecutivo empieza a ser sobre qué dato es el correcto en vez de sobre qué decisión tomar, el problema ya es de gobernanza.

    El lunes siguiente: tres movimientos concretos para un CDO o CFO

    Si el diagnóstico aplica, el punto de entrada no es un proyecto de data governance de dieciocho meses. Es un inventario de las cinco métricas financieras más usadas en la toma de decisiones ejecutivas —EBITDA, margen bruto, días de cuentas por cobrar, flujo de caja libre, costo por unidad— y una revisión de tres preguntas para cada una: ¿hay una definición escrita y acordada entre Finanzas y las áreas que la usan? ¿Hay un responsable identificado (data steward) que valida el cálculo antes de que salga al reporte? ¿Existe un linaje documentado desde el registro fuente hasta el número que ve el CFO? Las métricas donde la respuesta a las tres preguntas es “no” son el backlog inicial del programa de gobernanza financiera. Ese ejercicio toma menos de una semana y produce un mapa de riesgo más útil que cualquier diagnóstico de madurez genérico.

    La referencia de partida para estructurar este trabajo es el DAMA-DMBOK (segunda edición), disponible en DAMA International, complementado con el CDMC (Cloud Data Management Capabilities) del EDM Council para organizaciones con infraestructura híbrida o en la nube.

  • Gobernanza de datos y trazabilidad en el sector energético: el modelo de Bruno Magnano

    Gobernanza de datos y trazabilidad en el sector energético: el modelo de Bruno Magnano

    La gobernanza de datos y el data lineage —trazabilidad del dato desde su origen hasta su uso final— se consolidan como palancas de eficiencia operativa en la industria de hidrocarburos no convencionales. Bruno Magnano, referente del sector en Argentina, sostiene que sin una arquitectura clara de ownership y linaje, las decisiones operativas se toman sobre información degradada.

    En la industria del shale —donde cada pozo genera miles de variables en tiempo real, desde presiones de inyección hasta tasas de producción— la calidad del dato no es un problema de IT: es un problema de negocio. Un dato mal clasificado o sin propietario asignado puede traducirse en una decisión de completación incorrecta, un fallo de mantenimiento no anticipado o una proyección de reservas que no resiste el escrutinio de un auditor externo. Magnano, según se informó, ha trabajado en estructurar procesos de gobernanza que atacan exactamente esa brecha.

    Data lineage en upstream: por qué el origen del dato define su confiabilidad

    El data lineage —concepto central del DAMA-DMBOK 2.0 dentro del área de conocimiento de Metadatos— responde a una pregunta operativa concreta: ¿este número que veo en el dashboard, de dónde vino, quién lo tocó y qué transformaciones sufrió? En el upstream de petróleo y gas, esa pregunta tiene consecuencias directas. Un caudal de gas medido en boca de pozo puede pasar por hasta cinco sistemas antes de consolidarse en un reporte de producción diaria: SCADA, historiador de proceso, sistema de balanceo, ERP y plataforma de reporting. Si cada tramo de ese recorrido no está documentado y validado, el dato final es, en el mejor caso, sospechoso.

    El enfoque de Magnano, según se informó, prioriza la definición de data stewards —responsables temáticos del dato, distintos del propietario técnico del sistema— para cada dominio crítico: producción, reservorios, mantenimiento e integridad. Esta distinción entre data owner (quién rinde cuentas por la calidad del dominio) y data steward (quién opera los controles cotidianos) es la que establece el Non-Invasive Data Governance de Bob Seiner: no crear una burocracia paralela, sino formalizar responsabilidades que ya existen informalmente en la operación.

    Cuándo aplica este modelo y cuándo no

    Este esquema de gobernanza es pertinente cuando una organización opera múltiples fuentes de datos heterogéneas que convergen en decisiones críticas —como ocurre en operaciones de shale con pozos horizontales multilaterales y fractura hidráulica masiva. No aplica, o aplica de forma simplificada, en operaciones pequeñas con un único sistema de captura y sin integración downstream relevante. La clave está en el volumen de transformaciones que sufre el dato antes de ser consumido: a mayor número de saltos entre sistemas, mayor necesidad de linaje documentado.

    Tampoco es un modelo que funcione sin respaldo ejecutivo. El EDM Council, en su marco DCAM (Data Capability Assessment Model), ubica el patrocinio ejecutivo como el primer capability habilitante: sin un CDO o un sponsor en C-suite que otorgue mandato real a los data stewards, el programa se diluye en reuniones sin poder de decisión. Magnano, según se informó, opera con ese respaldo dentro de su organización.

    Argentina y la madurez de datos en el sector energético

    En Argentina, la expansión de Vaca Muerta como cuenca productiva de escala global obliga a las operadoras a elevar su madurez en gestión de datos. La Secretaría de Energía de la Nación requiere reportes de producción e inversión con granularidad creciente, y los compromisos ante organismos como el ENARGAS o la Comisión Nacional de Valores —para compañías con deuda en mercados de capitales— elevan el estándar de trazabilidad y auditoría. Un dato de producción que no puede ser reconstruido desde su origen no solo es un problema operativo: puede ser un problema regulatorio y de reporte financiero.

    Este contexto diferencia a Argentina de otras cuencas latinoamericanas. En Brasil, el marco de la ANP (Agência Nacional do Petróleo, Gás Natural e Biocombustíveis) establece requisitos de medición y reporte que, en la práctica, empujan a las operadoras a desarrollar capacidades equivalentes a los niveles 6 y 7 del DCAM —gestión activa de calidad de datos y alineación con objetivos de negocio— aunque sin el rótulo formal del framework.

    Tres decisiones que define el linaje de datos en producción

    En la práctica, documentar el linaje de datos en una operación de upstream implica resolver al menos tres decisiones de diseño que suelen subestimarse:

    • Granularidad del linaje: ¿a nivel de campo, de pozo o de sensor individual? A mayor granularidad, mayor costo de mantenimiento, pero mayor capacidad de diagnóstico ante anomalías.
    • Automatización versus documentación manual: los catálogos de datos modernos (Collibra, Alation, Microsoft Purview) permiten capturar linaje técnico de forma automática desde pipelines de datos, pero el linaje de negocio —qué significa ese dato para la operación— sigue requiriendo intervención humana del data steward.
    • Versionado de reglas de transformación: si la fórmula de cálculo de producción neta cambia, ¿quedan registradas ambas versiones con sus períodos de vigencia? Sin ese control, la comparabilidad histórica se rompe y el análisis de tendencias pierde validez.

    Estas decisiones no son técnicas en abstracto: las toma —o debería tomar— el CDO en coordinación con el área de operaciones. El modelo de Magnano, según se informó, aborda los tres niveles de forma integrada, con foco en que el dato de producción sea auditable de punta a punta.

    Para profundizar en los fundamentos del data lineage y su lugar dentro de la gestión de metadatos, el capítulo 12 del DAMA-DMBOK 2.0 (“Metadata Management”) ofrece el marco de referencia más completo disponible en español para equipos de gobernanza en América Latina.

  • Linaje de datos no alcanza: cómo rastrear lo que hacen los agentes de IA

    Linaje de datos no alcanza: cómo rastrear lo que hacen los agentes de IA

    El linaje de datos tradicional registra cómo se mueven los datos entre sistemas; los agentes de inteligencia artificial hacen algo distinto: toman decisiones, ejecutan acciones y modifican el entorno sin que ningún pipeline clásico deje constancia de ello. Para los equipos de gobernanza, eso abre una brecha de trazabilidad que los marcos actuales todavía no cierran.

    El concepto de data lineage —trazabilidad del dato desde su origen hasta su consumo— es uno de los pilares del DAMA-DMBOK y de frameworks como el CDMC del EDM Council. Su lógica supone que los datos fluyen de un punto A a un punto B a través de transformaciones conocidas y registrables. Pero un agente de IA no es un pipeline: es un sistema que percibe un estado, decide una acción y produce un efecto. El “dato” que entra puede ser un fragmento de texto no estructurado; el “efecto” puede ser una llamada a una API externa, una modificación en una base de datos o la generación de un documento que nadie etiquetó como output formal. Nada de eso queda capturado por las herramientas de linaje convencionales.

    Por qué el linaje clásico no modela acciones ni decisiones de agentes

    Las herramientas de linaje —desde Apache Atlas hasta las capacidades nativas de plataformas como Databricks Unity Catalog o Collibra— están optimizadas para rastrear transformaciones de datos estructurados entre nodos de un grafo de dependencias. Capturan “este campo viene de esta tabla, pasó por esta query, llegó a este dashboard”. Lo que no modelan es la cadena de razonamiento de un agente: qué contexto consumió, qué herramienta invocó, qué decisión intermedió, qué efecto produjo en un sistema externo y con qué nivel de confianza lo hizo. En términos de DAMA, estamos ante un gap en la capability de Metadata Management que los catálogos actuales no resuelven de fábrica.

    El problema se amplifica con los agentes multi-step y multi-tool. Un agente que consulta una base de datos de clientes, llama a un modelo de lenguaje para redactar un correo y luego lo envía a través de una API de CRM ha ejecutado tres acciones con tres impactos distintos sobre datos posiblemente sensibles. El linaje tradicional, en el mejor caso, registra la consulta inicial a la base de datos. El resto es invisible para el catálogo.

    Cuándo aplica una capa de “agent observability” y cuándo no

    La observabilidad de agentes —registrar prompts, tool calls, outputs intermedios y estados del agente— es necesaria cuando el sistema toma decisiones que afectan datos regulados, activos de negocio o usuarios finales. Si el agente opera en un sandbox sin acceso a datos de producción y sin capacidad de escritura en sistemas externos, el linaje clásico puede ser suficiente. Pero en cuanto el agente tiene acceso a datos personales, puede modificar registros o interactúa con sistemas de terceros, la trazabilidad debe extenderse al nivel de la acción, no solo del dato.

    La distinción operativa clave es entre read-only agents y read-write agents. Los primeros generan riesgo principalmente de exposición de información; los segundos generan riesgo de modificación no auditada de datos, con implicancias directas sobre data quality, data integrity y, en contextos regulados, sobre compliance. Un agente que corrige registros de clientes en un CRM sin dejar audit trail es, desde la perspectiva de gobernanza, equivalente a una transformación ETL sin linaje documentado: invisible e inauditable.

    Tres capacidades que los equipos de gobernanza deben sumar para agentes de IA

    • Registro de tool calls con contexto: cada vez que un agente invoca una herramienta externa —API, base de datos, modelo—, ese evento debe quedar registrado con el input que lo disparó, el output que produjo y el timestamp. Esto es el equivalente funcional del lineage node en un pipeline clásico, pero para acciones.
    • Clasificación de datos consumidos por el agente: si el agente accede a datos etiquetados como PII, confidenciales o regulados, el data steward responsable de esa fuente debe recibir una señal. Sin esta integración entre el sistema de clasificación del catálogo y el runtime del agente, el ownership de datos se vuelve nominal.
    • Política de retención del agent log: los registros de actividad del agente son metadata crítica. Deben estar sujetos a las mismas políticas de retención y acceso que los datos que el agente procesó, especialmente bajo marcos como la LGPD brasileña (art. 37, sobre registros de operaciones de tratamiento) o la Ley 25.326 argentina, que exige documentar el tratamiento de datos personales.

    El ángulo regulatorio en Brasil, Argentina y México

    En América Latina, la ausencia de trazabilidad sobre agentes de IA no es solo un problema de gobernanza interna: puede derivar en incumplimiento regulatorio. La LGPD brasileña establece en su artículo 18 el derecho del titular a obtener información sobre el tratamiento automatizado de sus datos; si un agente procesó datos de ese titular sin dejar registro, la organización no puede responder a un DSAR (Data Subject Access Request). La situación es análoga bajo la Ley 25.326 argentina y la LFPDPPP mexicana, que también exigen que los responsables puedan acreditar las operaciones de tratamiento realizadas. La Autoridad Nacional de Protección de Datos de Brasil (ANPD) ya ha señalado en sus guías de 2024 sobre agentes automatizados que la responsabilidad por el tratamiento no se diluye por el hecho de que lo ejecute un sistema autónomo.

    Para los CDOs en organizaciones que operan en estos mercados, esto significa que el agent observability no es una decisión técnica opcional: es un requisito de compliance que debe estar modelado en el framework de gobernanza antes de que los agentes lleguen a producción, no después. El EDM Council incluye en CDMC la capability de “AI Governance Integration” precisamente para forzar esta conversación antes del deployment.

    Los marcos de referencia disponibles —DAMA-DMBOK, CDMC, NIST AI RMF— ofrecen el vocabulario para abordar este gap, pero ninguno lo resuelve de forma prescriptiva todavía. El punto de partida concreto para un equipo de gobernanza es inventariar qué agentes ya están en producción, qué datos tocan y qué registros dejan; todo lo demás viene después de ese inventario.