Etiqueta: Ai Privacy

La IA agéntica —sistemas capaces de tomar decisiones y ejecutar acciones de forma autónoma en cadena— está llegando a las organizaciones antes de que sus datos estén en condiciones de soportarla. Para los equipos de gobierno de datos en América Latina, esto no es una advertencia futura: es el problema del trimestre.

A diferencia de los modelos de lenguaje que simplemente responden preguntas, los agentes de IA operan en loops: consultan fuentes, toman decisiones intermedias, invocan herramientas externas y producen efectos en sistemas reales. Cada paso de esa cadena depende de datos. Si esos datos tienen linaje (data lineage) desconocido, propietarios (data owners) indefinidos o clasificaciones inconsistentes, el agente amplifica el error en lugar de resolverlo. El output incorrecto de un chatbot es una molestia; el output incorrecto de un agente que procesa órdenes de compra o evalúa solicitudes de crédito es un problema de negocio —y potencialmente legal.

El problema no es el modelo, es el dato que lo alimenta

El DAMA-DMBOK define la calidad del dato como una de las diez áreas de conocimiento del gobierno de datos, y no por accidente: datos sin definición semántica consistente producen resultados no reproducibles. En el contexto agéntico, esto se agrava porque el agente puede encadenar múltiples fuentes sin intervención humana. Un pipeline donde el campo “cliente activo” tiene tres definiciones distintas en tres sistemas —CRM, ERP y data warehouse— ya era un riesgo en BI tradicional. En IA agéntica, ese campo puede activar o bloquear una acción autónoma con consecuencias directas.

El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), identifica el control de acceso basado en clasificación como una capability crítica. Para que un agente opere con datos sensibles de forma confiable, el catálogo de datos debe indicar no solo dónde está el dato, sino quién puede usarlo, bajo qué condición y con qué restricción regulatoria. Sin esa capa, el agente toma decisiones con datos a los que, en un proceso manual, ningún analista habría tenido acceso.

Lo que el CDO necesita revisar esta semana

El punto de partida operativo es el inventario de datos que ya están —o estarán pronto— disponibles para sistemas agénticos. Tres preguntas concretas para ese inventario:

• ¿Cada dataset tiene un data steward identificado con responsabilidad formal sobre su calidad y clasificación?
• ¿El data lineage está documentado hasta el nivel de campo, o solo a nivel de tabla o sistema?
• ¿Las políticas de acceso reflejan sensibilidad regulatoria, o son herencias de permisos históricos que nadie auditó?

Si la respuesta a cualquiera de esas tres preguntas es negativa o incierta, el dato en cuestión no debería alimentar un agente autónomo. Ese es el criterio mínimo, no el ideal. Bob Seiner, referente de Non-Invasive Data Governance, sostiene que las organizaciones no necesitan programas nuevos para gobernar datos en IA: necesitan hacer cumplir las políticas que ya definieron pero que nadie estaba aplicando con rigor. La IA agéntica simplemente hace visible lo que ya estaba roto.

El contexto regulatorio de LATAM agrega urgencia

En Brasil, la LGPD (Lei Geral de Proteção de Dados) establece responsabilidad para el controlador por el tratamiento automatizado de datos personales, incluyendo decisiones que afecten a titulares. Un agente de IA que clasifica clientes, aprueba solicitudes o genera comunicaciones personalizadas es, en términos jurídicos, un mecanismo de decisión automatizada sujeto a los artículos 20 y concordantes. Si el dato que lo alimenta no tiene trazabilidad ni control de calidad documentado, la organización no puede demostrar el cumplimiento ante la ANPD en caso de un reclamo. En Argentina, la situación es análoga bajo la Ley 25.326 y las resoluciones de la AAIP, que ya han señalado el tratamiento automatizado como área de atención prioritaria. En México, la LFPDPPP y los lineamientos del INAI sobre decisiones automatizadas imponen obligaciones similares para el sector privado.

El punto de confluencia es claro: los marcos de privacidad de la región no esperan a que las organizaciones “maduren” su gobierno de datos antes de exigir accountability. La ANPD puede sancionar hoy por un tratamiento automatizado que no pueda auditarse. Eso convierte el data lineage y el data ownership en requisitos de compliance, no solo en buenas prácticas de arquitectura.

Confianza como requisito de diseño, no como resultado

El concepto de “trustworthy AI” —IA confiable— que promueven tanto la Unión Europea en su AI Act como los marcos emergentes en América Latina no se construye en la capa del modelo. Se construye en la capa del dato. Un agente que opera sobre un catálogo bien gobernado, con stewardship activo, lineage documentado y políticas de acceso auditadas, puede ser explicado, auditado y corregido. Uno que opera sobre un lago de datos sin gobierno es, por definición, una caja negra, independientemente de cuán sofisticado sea el modelo subyacente.

Las organizaciones que lleguen tarde al gobierno de datos no van a poder desplegar IA agéntica confiable: van a desplegar riesgo agéntico.

La irrupción de sistemas multi-agente con capacidades multimodales en plataformas cloud como AWS redefine el perímetro del gobierno de datos corporativo. Cuando múltiples agentes de inteligencia artificial consumen, transforman y visualizan datos de forma autónoma, las estructuras tradicionales de data governance quedan expuestas en sus puntos más débiles: el data lineage, el ownership y la clasificación de activos.

Los arquitectos de datos llevan años construyendo marcos de gobierno sobre pipelines predecibles: un origen, una transformación, un destino. Los sistemas multi-agente rompen esa lógica. Cada agente puede actuar como productor y consumidor de datos de manera simultánea, encadenar llamadas a APIs externas, generar visualizaciones y alimentar a otros agentes con outputs que nunca fueron previstos en el catálogo original. El resultado es un grafo de dependencias que ningún data steward puede rastrear manualmente.

El problema del lineage en entornos agénticos

El data lineage —la capacidad de trazar el origen, el recorrido y las transformaciones de un dato a lo largo de su ciclo de vida— es el primer capability en tensión cuando se despliegan arquitecturas multi-agente. Según el DAMA-DMBOK (Data Management Body of Knowledge), el lineage es un componente crítico del área de conocimiento de Metadata Management, y su ausencia compromete directamente la confianza en los datos de negocio. En entornos donde los agentes de IA operan con autonomía, capturar ese linaje de forma automatizada deja de ser una buena práctica para convertirse en un requisito de gobernabilidad.

AWS propone resolver parte de este desafío con servicios como AWS Glue Data Catalog y Amazon DataZone, que permiten registrar activos, asignar ownership y documentar transformaciones. Sin embargo, la integración de agentes construidos sobre Amazon Bedrock introduce capas de interacción que los catálogos convencionales no estaban diseñados para absorber. Cada invocación de un modelo foundation que modifica o enriquece un dataset debería registrarse como un evento de transformación, con su contexto, su versión de modelo y sus parámetros. En la práctica, ese nivel de instrumentación raramente se implementa desde el día cero.

Ownership difuso y el rol del data steward

Uno de los principios centrales del Data Governance Institute (Gwen Thomas) es que todo dato debe tener un owner identificado con responsabilidad formal sobre su calidad y uso. En arquitecturas multi-agente, el ownership se vuelve difuso: ¿quién es el data steward de un dataset que fue generado por un agente a partir de la síntesis de tres fuentes distintas, ninguna de las cuales estaba en el catálogo corporativo? Esta pregunta no es teórica. Es el lunes a la mañana de cualquier equipo de governance que haya habilitado agentes de IA en producción sin un marco previo de clasificación y asignación de responsabilidades.

La respuesta operativa pasa por extender el modelo de stewardship hacia los pipelines agénticos: cada agente debe tener un owner humano registrado, sus outputs deben clasificarse automáticamente según la taxonomía de datos corporativa, y las visualizaciones generadas deben heredar el nivel de sensibilidad del dato más restrictivo que hayan consumido. Bob Seiner, referente del modelo Non-Invasive Data Governance, señala que la clave está en respetar los roles y responsabilidades existentes en lugar de crear estructuras paralelas —un principio que aplica directamente cuando se incorporan agentes de IA como actores del ecosistema de datos.

El contexto regulatorio latinoamericano no espera

Para los equipos de governance en la región, la presión no es solo técnica. En Brasil, la LGPD exige que las organizaciones puedan demostrar el tratamiento de datos personales en cualquier punto del ciclo de vida del dato. Si un agente de IA procesa registros con información personal sin que eso quede registrado en el linaje, la organización queda expuesta ante la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 y las disposiciones de la AAIP establecen obligaciones similares de documentación y control. Colombia, bajo la Ley 1581, también exige principios de finalidad y limitación de uso que son directamente vulnerables cuando los agentes operan sin restricciones explícitas sobre qué datos pueden consumir y con qué propósito.

El CDO que habilita un sistema multi-agente sin actualizar su Data Management Policy está, en los hechos, creando un punto ciego regulatorio. El lunes concreto implica tres acciones: primero, mapear todos los agentes en producción y pre-producción como actores en el catálogo de datos; segundo, definir qué clases de datos pueden consumir según la taxonomía vigente (datos públicos, internos, confidenciales, restringidos); y tercero, establecer un mecanismo de captura automática de eventos de transformación —ya sea mediante hooks en el orquestador de agentes o mediante integración con el Data Catalog existente.

Visualización: el output que nadie gobierna

Las visualizaciones generadas por agentes multimodales representan un caso particular que los marcos de governance raramente contemplan: son outputs derivados que pueden contener datos sensibles en forma de gráficos, tablas o dashboards, y que suelen compartirse fuera del perímetro corporativo sin pasar por controles de clasificación. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el control de distribución de activos de datos como una capability de nivel 9 —de los más avanzados en el modelo de madurez. Para la mayoría de las organizaciones latinoamericanas, ese control ni siquiera existe para visualizaciones estáticas, mucho menos para las generadas dinámicamente por IA.

Gobernar agentes de IA no es un problema futuro: es el gap que ya existe entre los frameworks de governance que las organizaciones dicen tener y los entornos que están operando hoy.

La Unión Europea postergó hasta diciembre de 2027 las obligaciones de alto riesgo del AI Act —las que cubren scoring crediticio, selección de personal, servicios esenciales e infraestructura crítica—, extendiendo en 16 meses un plazo que originalmente vencía en agosto de 2026. Para las empresas latinoamericanas que operan bajo estándares europeos o que exportan servicios a ese mercado, la prórroga no es un alivio: es tiempo que no debe desperdiciarse.

La decisión del Parlamento Europeo, confirmada en mayo de 2026, desplazó las obligaciones del Anexo III del AI Act. No se trata de un cambio de fondo en las exigencias —los requerimientos de documentación, trazabilidad de datos de entrenamiento, gestión de riesgos y supervisión humana siguen intactos—, sino de una señal de que la industria no estaba lista. Esa misma señal debería resonar con fuerza en los equipos de gobierno de datos de la región.

Por qué la fecha importa más que el contenido

El AI Act establece, para los sistemas de IA de alto riesgo, la obligación de demostrar que los datos utilizados para entrenar y validar modelos son representativos, están documentados y son gestionados con controles verificables. En términos de DAMA-DMBOK, eso equivale a tener operativas al menos las áreas de conocimiento de Calidad de Datos, Data Lineage y Gestión de Metadatos. El problema es que muchas organizaciones —europeas y latinoamericanas por igual— todavía no pueden responder con precisión quién es el data steward de un conjunto de entrenamiento, ni dónde se originaron esos registros.

La prórroga no suspende las obligaciones para sistemas de IA de propósito general (GPAI) ni para los usos prohibidos, que ya están vigentes desde febrero de 2025. Lo que se posterga es precisamente el segmento más sensible para sectores financieros y de recursos humanos: el scoring y el filtrado automatizado de personas. Que esa capa específica haya necesitado más tiempo dice mucho sobre el estado real de madurez en gobierno de datos dentro de la industria de IA.

El lunes a la mañana: qué hace un CDO con esta información

La prórroga ofrece una ventana concreta. Un Chief Data Officer que quiera llegar a diciembre de 2027 con algo más que PowerPoints debería estructurar los próximos trimestres alrededor de tres prioridades verificables:

• Inventario de datasets críticos: identificar qué conjuntos de datos alimentan —o podrían alimentar— modelos de scoring, contratación o asignación de servicios esenciales, con ownership documentado y clasificación de sensibilidad según el marco del EDM Council (CDMC Capability 8: Data Lineage).
• Auditoría de linaje: mapear el recorrido completo de esos datos desde la fuente hasta el modelo, incluyendo transformaciones intermedias. Herramientas de data catalog con linaje automatizado dejan de ser un “nice to have” para convertirse en evidencia regulatoria.
• Definición de roles de stewardship para IA: asignar data stewards específicos para los pipelines de entrenamiento y validación, separados de los stewards de reportes operativos. Esta distinción, poco común en la región, será exigible bajo el AI Act.

En paralelo, conviene revisar los contratos con proveedores de modelos o plataformas de IA: el AI Act asigna responsabilidades al “deployer” —quien despliega el sistema en contexto de alto riesgo—, no solo al fabricante. Eso significa que una empresa en Buenos Aires o Ciudad de México que use un modelo europeo para evaluar crédito puede quedar alcanzada por las obligaciones aunque el modelo lo construya un tercero.

El paralelo regulatorio en LATAM

Brasil avanza en su Marco Legal de IA —aprobado en la Câmara dos Deputados en mayo de 2024 y en proceso de sanción definitiva—, que replica en parte la estructura de riesgos del enfoque europeo. La Lei Geral de Proteção de Dados (LGPD) ya exige, en su artículo 20, que los titulares puedan solicitar revisión de decisiones automatizadas significativas. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) emitió la Resolución 159/2024, que establece buenas prácticas para el uso de IA en el sector público con foco en explicabilidad y no discriminación. En México, la LFPDPPP no contempla explícitamente la IA, pero el INAI ha señalado que las decisiones automatizadas entran en el ámbito del derecho de acceso y rectificación. El vector regulatorio es claro: gobierno de datos y accountability algorítmica convergen.

Lo que el AI Act llama “data governance for high-risk AI” no es distinto, en esencia, de lo que DAMA lleva años describiendo como gobierno corporativo de datos bien implementado: ownership claro, calidad medible, linaje documentado y metadatos útiles. La diferencia es que ahora hay fechas, multas y un regulador con jurisdicción extraterritorial.

Confianza en los datos como activo regulatorio

El concepto de “data trust” —confianza en los datos— suele tratarse como un valor abstracto en las presentaciones de estrategia. En un entorno regulado por el AI Act, se vuelve operativo: significa poder demostrar, ante una autoridad competente, que los datos que alimentaron un modelo de alto riesgo son exactos, representativos y fueron tratados con los controles adecuados. No alcanza con tenerlo; hay que poder probarlo.

“La regulación de IA no crea nuevos problemas de datos: expone los que ya existían y les pone nombre, fecha y consecuencia.”

— Perspectiva editorial, DataTrends LATAM

Para los equipos de gobierno de datos en la región, la prórroga del AI Act es la última oportunidad de construir capacidades reales antes de que el reloj regulatorio venza de nuevo —y esta vez sin extensiones.

Dieciséis meses adicionales no cambian la dirección del viaje: solo determinan si llegás preparado o corriendo.