Etiqueta: Ai Privacy

La gobernanza de datos agéntica propone reemplazar flujos de aprobación manuales por agentes de inteligencia artificial que detectan, clasifican y aplican políticas de datos en tiempo real. No es una evolución incremental del modelo tradicional: implica redistribuir la autoridad sobre los datos entre humanos y sistemas automatizados, con consecuencias directas sobre roles como el data steward y el Chief Data Officer.

Durante décadas, la gobernanza de datos funcionó como un proceso secuencial: alguien detecta un problema de calidad o clasificación, lo escala al steward correspondiente, el steward lo revisa, y una política se actualiza semanas después. Ese ciclo, razonable cuando los volúmenes de datos eran manejables, colapsa frente a arquitecturas modernas donde un pipeline de datos en la nube puede generar miles de activos nuevos por día. La gobernanza agéntica surge precisamente para cerrar esa brecha operativa.

Qué significa “agéntico” en la práctica de gobernanza

Un sistema agéntico no es un dashboard más sofisticado ni un motor de reglas tradicional. Es un agente de IA —generalmente construido sobre modelos de lenguaje grande o modelos especializados— que puede percibir el estado del entorno de datos, razonar sobre él y ejecutar acciones sin instrucción humana explícita en cada paso. En gobernanza, eso se traduce en capacidades concretas: el agente puede escanear un data lake, inferir que una columna nueva contiene información de salud basándose en el contenido y el contexto, aplicar automáticamente la política de retención correspondiente, y registrar la acción en el catálogo de datos con su linaje completo. El ciclo que antes tomaba días ocurre en minutos, sin intervención humana directa.

La diferencia clave respecto a la automatización tradicional es la capacidad de razonamiento bajo ambigüedad. Un motor de reglas clásico aplica lógica determinista: si el campo se llama “DNI”, aplica la política de datos personales. Un agente puede inferir que un campo llamado “identificador_cliente_legado” contiene, de hecho, números de documento, aunque el nombre no lo indique. Esa capacidad de inferencia es lo que hace al modelo agéntico cualitativamente distinto —y también lo que exige controles más rigurosos.

Los cuatro componentes que definen una arquitectura agéntica de gobernanza

• Percepción continua: el agente monitorea fuentes de datos, catálogos y pipelines en tiempo real, no en ciclos de auditoría periódica.
• Razonamiento contextual: evalúa el contenido, el esquema, el origen y el uso histórico de cada activo para inferir clasificaciones y riesgos.
• Ejecución autónoma con guardrails: aplica políticas dentro de umbrales predefinidos; acciones de mayor impacto (borrado permanente, cambio de propietario) siguen requiriendo aprobación humana.
• Trazabilidad nativa: cada decisión del agente queda registrada con su justificación, habilitando auditoría y rollback. Sin esto, el modelo colapsa ante cualquier regulador.

Cuándo aplica — y cuándo todavía no

La gobernanza agéntica tiene sentido en organizaciones con volúmenes de datos que hacen inviable la revisión manual: plataformas de datos en la nube con cientos de dominios, empresas que operan con arquitecturas data mesh donde cada dominio produce y consume datos de forma descentralizada, o equipos de datos que ya superaron la capacidad operativa de sus stewards humanos. El DAMA-DMBOK v2 define la función de administración de datos (Data Stewardship) como responsabilidad formal sobre activos de datos; la gobernanza agéntica no elimina esa responsabilidad, la eleva: el steward deja de ejecutar tareas repetitivas y pasa a diseñar las políticas que el agente aplica, supervisar su comportamiento y gestionar las excepciones.

Donde todavía no aplica —o aplica con riesgo alto— es en organizaciones sin un catálogo de datos maduro, sin políticas formalizadas y sin linaje documentado. Un agente agéntico sin esos insumos tomará decisiones sobre bases frágiles y producirá clasificaciones incorrectas que se propagarán a escala. El EDM Council, en su marco DCAM (Data Management Capability Assessment Model), ubica la automatización avanzada en los niveles 4 y 5 de madurez; intentarla en el nivel 2 es contraproducente.

El riesgo de accountability cuando el agente decide

El nudo regulatorio más complejo de la gobernanza agéntica es la cadena de responsabilidad. Si un agente clasifica erróneamente un dato personal como no sensible y ese dato termina en un reporte público, ¿quién responde? La respuesta no está en el agente: está en el CDO que aprobó el despliegue, en el data steward del dominio y en el marco de políticas que habilitó esa decisión. Esto no es un problema futuro: es un problema presente. El AI Act de la Unión Europea, aplicable desde 2025, clasifica como sistemas de alto riesgo aquellos que toman decisiones automatizadas sobre datos personales en contextos sensibles. Aunque el AI Act no es vinculante en América Latina, marca la dirección hacia la que se mueve la regulación global y ya influye en las políticas de proveedores que operan en la región.

En la región, el marco regulatorio agrega capas adicionales. La Ley General de Protección de Datos de Brasil (LGPD) exige en su artículo 20 que el titular pueda solicitar revisión humana de decisiones tomadas exclusivamente por medios automatizados. La Ley 25.326 de Argentina —actualmente en proceso de modernización— contiene disposiciones equivalentes en su artículo 16. La LFPDPPP de México establece obligaciones similares en su reglamento. Esto significa que cualquier arquitectura agéntica que tome decisiones con efecto sobre datos personales de titulares latinoamericanos debe mantener, por diseño, un circuito de revisión humana accesible. No es opcional: es un requisito legal vigente.

Lo que un CDO necesita resolver antes de desplegar agentes de gobernanza

El punto de partida no es elegir la herramienta, sino mapear las decisiones que el agente tomará y su nivel de impacto. Una decisión de bajo impacto —etiquetar automáticamente un campo nuevo como “interno”— puede delegarse con guardrails simples. Una decisión de alto impacto —restringir el acceso a un activo de datos usado en producción— requiere aprobación humana en el flujo. Ese mapeo debe traducirse en una política de autonomía del agente, documentada y versionada, que el equipo de gobernanza pueda auditar. Sin ese documento, el despliegue es un experimento sin control, no una capacidad de gobernanza.

Adicionalmente, el CDO debe resolver la cuestión del linaje de decisiones del propio agente: ¿dónde se registra qué clasificó, por qué, y con qué confianza? Herramientas como Apache Atlas, Collibra o Alation —presentes en stacks de gobernanza de organizaciones líderes en Brasil, México y Colombia— ofrecen APIs donde estos registros pueden integrarse. Sin esa trazabilidad, el agente es una caja negra que invalida cualquier argumento de compliance ante la ANPD, el INAI o la AAIP.

Para profundizar en los marcos de madurez que condicionan la viabilidad de estas arquitecturas, el punto de referencia más completo sigue siendo el DCAM del EDM Council, disponible en edmcouncil.org, y el DAMA-DMBOK v2, cuyo capítulo 17 sobre gestión de metadatos es lectura obligatoria antes de cualquier decisión de despliegue agéntico.

Mondelēz International —fabricante de Oreo, Cadbury y Chips Ahoy— decidió que antes de escalar el uso de inteligencia artificial necesitaba resolver un problema más antiguo y más barato de ignorar: la calidad y la propiedad de sus datos. El resultado fue un rediseño completo de su modelo de gobernanza, con ownership transferido de IT a los equipos de negocio, antes de encender cualquier modelo.

La secuencia importa. Muchas organizaciones invierten en IA sobre datos que nadie sabe exactamente quién tiene que mantener, con linaje desconocido y calidad sin medir. Mondelēz invirtió ese orden: primero construyó la base, después habilitó los casos de uso. La plataforma elegida fue Ataccama ONE, que integró calidad de datos, catálogo y data lineage —trazabilidad del origen y transformación de cada activo de datos— en un único entorno operativo, según informó la empresa.

El movimiento clave: del ownership de IT al ownership del negocio

El cambio estructural más relevante no fue tecnológico sino organizacional. Mondelēz trasladó la responsabilidad formal sobre los datos desde el área de tecnología hacia los equipos de negocio que los crean y consumen. En la terminología del DAMA-DMBOK, esto equivale a formalizar el rol de data steward en las líneas de negocio, reconociendo que el área de IT puede administrar la infraestructura pero no puede ser la última responsable de la semántica ni de la calidad de datos que nunca generó. Bob Seiner, referente de la corriente de Non-Invasive Data Governance, describe este patrón como asignar responsabilidades a quienes ya las ejercen informalmente —la formalización no crea el trabajo, lo hace visible y auditable.

La consecuencia práctica es que los data stewards de cada unidad de negocio pasan a ser los responsables de definir reglas de calidad, aprobar cambios en definiciones de datos maestros y validar el linaje antes de que un dataset llegue a un modelo de IA. Sin ese mecanismo, la cadena de responsabilidad se rompe y el error de datos se convierte en error de modelo —un problema infinitamente más difícil de diagnosticar.

Calidad, catálogo y linaje: por qué los tres juntos y no por separado

La decisión de consolidar calidad de datos, catálogo y linaje en un entorno único en lugar de mantener herramientas separadas responde a un problema de fricción operativa conocido en la industria. Cuando el catálogo vive en un sistema, las reglas de calidad en otro y el linaje en un tercero, los data stewards pasan tiempo reconciliando vistas inconsistentes en lugar de gobernar. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica la integración de estos tres dominios como una capability de nivel avanzado —equivalente aproximadamente al nivel 4 sobre 5 en el modelo de madurez— que habilita la confianza en datos para casos de uso de analytics e IA.

Para Mondelēz, conectar esos tres dominios significó poder responder preguntas concretas antes de autorizar el uso de un dataset en un modelo: ¿De dónde vienen estos datos? ¿Quién los modificó por última vez y cuándo? ¿Qué porcentaje cumple las reglas de calidad definidas por el steward responsable? Sin esas respuestas, la confianza en el output del modelo es, en el mejor caso, optimismo.

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

El modelo de Mondelēz es replicable en organizaciones con volumen de datos distribuido entre múltiples unidades de negocio, fuentes heterogéneas y ambición de escalar IA más allá de proyectos piloto. No es la solución adecuada para empresas en etapas tempranas de madurez donde el problema es más básico —inventario de fuentes, definición de dominios de datos, identificación de propietarios— porque implantar un catálogo activo sobre datos sin ownerships claros genera ruido, no gobernanza. El DAMA-DMBOK sugiere evaluar primero la madurez en Data Management antes de seleccionar plataformas: sin un mapa de dominios y stewards asignados, la herramienta no sustituye el trabajo conceptual previo.

Tampoco es un modelo listo para operar en contextos con datos altamente sensibles sin capas adicionales de control. En sectores regulados —financiero, salud, telecomunicaciones— la gobernanza de datos para IA debe articularse además con marcos de gestión de riesgo como el NIST AI RMF, que exige documentación de la procedencia de los datos de entrenamiento y de las métricas de calidad utilizadas para validar los modelos.

La lectura desde América Latina: regulación y presión sobre el dato de negocio

En la región, la presión para formalizar el ownership de datos tiene cada vez más anclaje regulatorio. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que las organizaciones puedan demostrar la trazabilidad de los datos personales utilizados en procesos automatizados de toma de decisiones —exactamente el tipo de linaje que Mondelēz construyó, aunque aplicado aquí a un requerimiento de cumplimiento legal y no solo operativo. En Argentina, la Ley 25.326 y las disposiciones de la AAIP sobre tratamiento automatizado plantean exigencias similares en materia de responsabilidad sobre el dato. En México, el INAI ha comenzado a preguntar por los mecanismos de control sobre datos utilizados en sistemas de IA en el sector privado.

El punto de convergencia es que los CDOs de empresas de consumo masivo con operaciones en Brasil, Argentina o México no pueden separar la gobernanza de datos para IA de su programa de cumplimiento en protección de datos personales. El ownership de negocio que Mondelēz formalizó no es solo buena práctica de DAMA: en determinados contextos regulatorios regionales, es condición de cumplimiento.

Lo que un CDO puede hacer a partir de este caso

El caso de Mondelēz sugiere una secuencia de tres movimientos concretos. Primero, auditar qué porcentaje de los datasets que hoy alimentan o alimentarán modelos de IA tienen un data steward formalmente asignado en el área de negocio —no en IT. Segundo, evaluar si calidad, catálogo y linaje están integrados o son silos que requieren reconciliación manual; si lo segundo, cuantificar el costo operativo de esa fricción antes de la próxima conversación presupuestaria. Tercero, mapear cuáles de esos datasets contienen datos personales y si el linaje documentado es suficiente para responder a una auditoría de la ANPD, la AAIP o el INAI. Los tres pasos son independientes de la plataforma elegida y pueden iniciarse con los recursos de gobernanza ya existentes.

La referencia técnica de base para este enfoque es el DAMA-DMBOK segunda edición, en particular los capítulos de Data Quality Management y Data Governance; para el marco de madurez en nube, el CDMC del EDM Council ofrece el benchmark más usado actualmente en organizaciones con arquitecturas híbridas.

El data mesh no es una moda de arquitectura de datos: es la respuesta estructural al problema que la inteligencia artificial generativa volvió urgente. Cuando los agentes de IA consumen datos de decenas de dominios en tiempo real, el modelo centralizado de data warehouse colapsa. La pregunta ya no es si adoptar data mesh, sino cómo gobernarlo cuando los consumidores son máquinas, no personas.

Data mesh, el paradigma desarrollado por Zhamak Dehghani y popularizado a partir de 2019, propone descentralizar la propiedad del dato: cada dominio de negocio —finanzas, operaciones, producto, clientes— es dueño de sus propios data products y los expone al resto de la organización con estándares comunes. En vez de un equipo central de ingeniería que mueve y transforma todo, el ownership recae en quien mejor conoce el dato. La infraestructura se comparte; la responsabilidad, no. Este modelo resuelve cuellos de botella clásicos de los data lakes corporativos, pero crea tensiones propias cuando la IA entra en escena.

Por qué la IA presiona los cuatro principios del data mesh

El data mesh se apoya en cuatro principios: propiedad del dato por dominio, el dato como producto, infraestructura de autoservicio y gobernanza federada. Los tres primeros escalan razonablemente bien. El cuarto —gobernanza federada— es donde la IA introduce fricciones nuevas. Un agente de IA que razona sobre datos de clientes, inventario y contratos simultáneamente no distingue si está cruzando dominios con distintos niveles de clasificación. Si el data product de clientes tiene etiqueta PII y el de inventario no, el agente puede generar outputs que mezclan ambos sin que ningún steward de dominio lo haya autorizado explícitamente. El DAMA-DMBOK v2 identifica la integración entre dominios como uno de los puntos de mayor riesgo en arquitecturas distribuidas, y los flujos de IA lo amplifican.

El data lineage —la trazabilidad de origen, transformación y consumo del dato— se vuelve crítico en este escenario. Sin lineage granular, es imposible auditar qué dato alimentó qué decisión del modelo. Herramientas como OpenLineage o los módulos de linaje de catálogos como Apache Atlas, DataHub o Collibra permiten registrar esos flujos, pero solo si el data product fue diseñado desde el inicio para exponer metadata de linaje. En la mayoría de las organizaciones latinoamericanas, ese diseño no existe: los data products se construyeron para consumo humano, no para consumo de agentes.

El data steward de dominio necesita un nuevo mandato cuando el consumidor es un modelo

En un data mesh maduro, cada dominio tiene un data steward —en la nomenclatura del Data Governance Institute, el responsable de la calidad, semántica y política de acceso del dato dentro de su área. Cuando el consumidor era un analista, el steward podía gestionar accesos con listas de control y revisiones periódicas. Cuando el consumidor es un agente de IA que consulta el dato miles de veces por día y puede encadenar inferencias no previstas, el mandato cambia: el steward debe definir contratos de datos explícitos que incluyan restricciones de uso por tipo de consumidor, no solo por persona o equipo. Esto implica extender los data products con atributos de política: “este campo puede ser usado para entrenamiento”, “este campo puede alimentar outputs hacia externos”, “este campo requiere enmascaramiento antes de exponerse a modelos no validados”.

El marco CDMC (Cloud Data Management Capabilities) del EDM Council, que varias instituciones financieras de Brasil y México están adoptando como referencia, incluye la capability 8 de controles de datos sensibles como requisito para entornos de IA. La exigencia no es nueva: el Banco Central de Brasil, a través de la Resolución BCB 4.658/2018 sobre gestión de riesgo tecnológico, ya demandaba trazabilidad de datos críticos en entornos cloud. La novedad es que ahora esa trazabilidad debe extenderse hasta los pipelines de inferencia de los modelos.

Cuándo el data mesh resuelve el problema y cuándo no

El data mesh es apropiado cuando la organización tiene dominios de negocio bien definidos, equipos con capacidad técnica suficiente para operar data products, y un plano de gobernanza federada con políticas comunes acordadas. En esas condiciones, la IA se beneficia: encuentra datos clasificados, con linaje, con contratos explícitos, servidos por equipos que conocen su semántica. El riesgo de alucinación por datos incorrectos baja. El riesgo regulatorio —especialmente bajo la LGPD brasileña o la Ley 25.326 argentina, que exigen que el responsable del tratamiento pueda identificar la fuente y el propósito de cada dato personal procesado— se vuelve manejable.

El data mesh no resuelve el problema cuando la gobernanza federada es nominal: dominios que publican data products sin clasificación, sin steward activo, sin SLA de calidad. En ese escenario, descentralizar el ownership solo descentraliza el caos. Un CDO que quiera aprovechar los agentes de IA sin haber cerrado primero los contratos de datos entre dominios está construyendo sobre arena. El NIST AI RMF (AI Risk Management Framework) es explícito en este punto: la gestión del riesgo de IA requiere trazabilidad del dato de entrada como condición previa, no como mejora iterativa.

Tres acciones concretas para CDOs en organizaciones con data mesh parcial

La mayoría de las organizaciones latinoamericanas con arquitecturas de data mesh se encuentran en estadios intermedios: algunos dominios maduros, otros sin steward asignado, y catálogos de datos con cobertura parcial. Ante la presión de incorporar IA generativa, el riesgo es saltear los pasos de gobernanza. Las acciones con mayor retorno inmediato son tres. Primero, auditar qué data products están siendo consumidos —o podrían serlo— por modelos de IA, y verificar si tienen clasificación de sensibilidad y linaje registrado. Segundo, extender los contratos de datos existentes con una dimensión de política de uso por tipo de consumidor, empezando por los dominios de clientes y finanzas, que concentran la mayor densidad de datos personales bajo regulación. Tercero, alinear al data steward de cada dominio con el equipo de IA sobre los límites de uso del dato: sin ese diálogo, el modelo consumirá lo que técnicamente pueda acceder, no lo que la política autoriza.

El DAMA-DMBOK v2 y el CDMC del EDM Council son los marcos de referencia más utilizados en la región para estructurar esta transición; ambos están disponibles en sus sitios oficiales y son el punto de partida obligado antes de habilitar cualquier agente de IA sobre un data mesh en producción.