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.
