Etiqueta: Ai Privacy

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.

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.

Cuando una organización lanza un proyecto de inteligencia artificial sin haber establecido gobernanza de datos, el resultado suele ser el mismo: retroceder al punto de partida para mapear, limpiar y documentar lo que debería haber estado ordenado desde antes. No es un problema de tecnología, es un problema de fundamentos.

La gobernanza de datos es el conjunto de políticas, roles, procesos y estándares que definen quién puede hacer qué con qué datos, bajo qué condiciones y con qué nivel de calidad garantizado. En la práctica, es la diferencia entre un ecosistema de datos que una organización puede operar con confianza y un inventario opaco de activos sin dueño, sin linaje documentado y sin criterios de calidad consistentes. El marco DAMA-DMBOK, referencia global para profesionales del área, sitúa la gobernanza como la función habilitante de las otras diez disciplinas de gestión de datos: sin ella, capacidades como data quality, metadata management o data lineage quedan sin anclaje institucional.

Por qué la IA fuerza la conversación que muchas organizaciones evitaron

Durante años, la gobernanza de datos fue tratada como un proyecto de mediano plazo que siempre cedía ante prioridades más urgentes. La expansión de iniciativas de inteligencia artificial generativa cambió ese cálculo de forma abrupta. Entrenar un modelo, alimentar un agente o construir un sistema de recuperación aumentada (RAG) requiere saber exactamente de dónde vienen los datos, qué representan, quién los autorizó para ese uso y si su calidad es suficiente para producir outputs confiables. Sin esa información, el equipo técnico dedica semanas o meses a tareas de arqueología de datos antes de poder escribir una sola línea de código productivo. En términos de CDMC (Cloud Data Management Capabilities), del EDM Council, ese trabajo corresponde a las capabilities de Data Governance y Data Quality, que en organizaciones sin madurez formal suelen ejecutarse de manera ad hoc y sin registro.

Los roles que faltan: data steward y data owner como piezas críticas

Uno de los déficits más frecuentes no es de herramientas sino de responsabilidades. El modelo de Non-Invasive Data Governance que propone Bob Seiner parte de una premisa operativa: los datos ya tienen dueños de hecho —las áreas que los producen y consumen—, pero esa responsabilidad no está formalizada. Designar data stewards por dominio (finanzas, clientes, operaciones) y establecer un data owner con autoridad de decisión sobre cada activo crítico es el primer paso concreto antes de evaluar cualquier plataforma de catálogo o linaje. Sin ese mapa humano, ningún software de metadata management resuelve el problema estructural.

Cuándo aplica la gobernanza formal y cuándo no alcanza con buenas intenciones

La gobernanza estructurada es indispensable cuando la organización opera con datos de múltiples dominios cruzados, cuando existen obligaciones regulatorias sobre la calidad o trazabilidad de los datos, o cuando hay proyectos de IA, analítica avanzada o reporting regulatorio en marcha. No aplica —o aplica de forma mínima— en equipos muy pequeños con un solo dominio de datos bien delimitado y sin exposición regulatoria relevante. El error más común es implementar un marco complejo de gobernanza en contextos donde lo que se necesita es simplemente un acuerdo de definiciones entre tres personas. La sobreingeniería de la gobernanza es tan costosa como su ausencia.

El ángulo regulatorio en América Latina: LGPD, Ley 25.326 y la presión desde afuera

En la región, la gobernanza de datos dejó de ser opcional en el momento en que las regulaciones de protección de datos personales comenzaron a exigir accountability sobre el tratamiento. La Lei Geral de Proteção de Dados (LGPD) de Brasil requiere que las organizaciones puedan demostrar bases legales para cada tratamiento y acreditar medidas técnicas y organizativas adecuadas: eso es, en esencia, gobernanza aplicada a datos personales. La Ley 25.326 de Argentina —en proceso de actualización— y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México imponen obligaciones similares sobre inventario, propósito y seguridad de los datos. Las organizaciones que construyeron capacidades de gobernanza para cumplir con estas leyes tienen una ventaja estructural cuando llega el momento de escalar proyectos de IA: ya saben qué tienen, dónde está y quién responde por ello.

Tres decisiones concretas para un equipo de datos sin programa formal de gobernanza

El punto de entrada no es un comité ni una política de cien páginas. Para un CDO o Data Lead que necesita resultados en el corto plazo, el recorrido mínimo viable implica tres movimientos secuenciales:

• Inventario de activos críticos: identificar los diez conjuntos de datos de mayor impacto para el negocio o la regulación, documentar su origen, formato, frecuencia de actualización y área responsable. Sin este paso, todo lo que sigue es especulativo.
• Asignación de data owners y stewards: para cada activo del inventario, nombrar un responsable con autoridad para decidir sobre acceso, calidad y uso. No tiene que ser un cargo nuevo: en la mayoría de los casos, esa persona ya existe y solo necesita que la responsabilidad sea explícita.
• Definición de criterios de calidad mínimos: establecer, por dominio, qué significa que un dato es “suficientemente bueno” para ser usado en un proceso de negocio o en un modelo. Completitud, unicidad, consistencia temporal: tres dimensiones básicas que el framework ISO/IEC 25012 ya define y que pueden operacionalizarse sin infraestructura compleja.

Estos tres pasos no reemplazan un programa maduro de gobernanza, pero eliminan el síntoma más costoso: el equipo que no sabe qué tiene ni a quién preguntar cuando un proyecto se traba en el primer sprint.

La gobernanza de datos no es el proyecto que viene después de la IA: es la condición sin la cual la IA es, en el mejor caso, un experimento que no escala. Para lectura de referencia, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los puntos de partida técnicos más sólidos disponibles hoy para equipos de la región.