DATA·TRENDS
Latam
Buenos Aires, ArgentinaNewsletter
DGL Talent - El talento en datos. Lo conocemos.
Data GovernanceExplicativo

Agentes de IA: recuperar hechos, no definirlos

LR
La Redacción
18 de sept de 2026 · 4 min de lectura
Agentes de IA: recuperar hechos, no definirlos

Los agentes de inteligencia artificial no deben ser la fuente de verdad de una organización: deben consultar esa fuente, no reemplazarla. La distinción parece obvia hasta que un agente empieza a responder preguntas de negocio con datos que nadie auditó, en pipelines que nadie gobierna.

Cuando una organización despliega agentes de IA para automatizar decisiones —desde aprobación de créditos hasta reportes regulatorios—, uno de los riesgos más subestimados no es técnico sino semántico: el agente puede “definir” un hecho porque ningún sistema autoritativo le indicó cuál es la versión correcta. Si no existe un catálogo de datos activo, un ownership claro por dominio y reglas de calidad documentadas, el agente opera en el vacío y llena ese vacío con inferencias. Eso no es inteligencia artificial; es ambigüedad automatizada a escala.

Qué significa que un agente “defina” un hecho

En arquitecturas de recuperación aumentada (RAG) o en agentes con acceso a múltiples fuentes, el sistema elige qué dato usar cuando encuentra versiones contradictorias. Si no hay una capa de gobernanza que declare cuál sistema es el registro maestro —el sistema of record— para cada concepto crítico de negocio (cliente, producto, saldo, riesgo), el agente toma esa decisión de facto. Lo hace de forma opaca, no documentada y, en muchos casos, no reproducible. El problema no es el modelo de lenguaje en sí: es la ausencia del marco de datos que debería preceder a cualquier despliegue agentico.

Cuándo aplica / cuándo NO

Este riesgo aplica en cualquier flujo donde el agente accede a más de una fuente de datos para construir una respuesta o tomar una acción: consultas sobre clientes en CRM + ERP, generación de reportes desde múltiples data marts, o automatización de procesos con datos de terceros. No aplica —o aplica con menor urgencia— cuando el agente opera sobre una única fuente de datos bien delimitada, con esquema fijo y ownership documentado. En ese escenario reducido, el agente efectivamente “recupera” sin riesgo de “definir”. El problema escala con la complejidad del ecosistema de datos.

El DAMA-DMBOK y la capa que falta antes del agente

El marco DAMA-DMBOK identifica la gestión de datos maestros (MDM, Master Data Management) y la gestión de datos de referencia como disciplinas previas a cualquier consumo analítico o automatizado. Un agente de IA es, a efectos prácticos, un consumidor de datos de alta velocidad y baja supervisión humana. Si los datos maestros de cliente no tienen un data steward asignado, si el glosario de negocio no está publicado y si el data lineage no traza de dónde viene cada atributo, el agente heredará todos esos problemas —y los amplificará, porque operará sin fricción humana correctiva. La secuencia correcta es: definir el dato canónico → documentar su linaje → habilitar el acceso al agente, no al revés.

Tres controles concretos antes de escalar agentes en producción

  • Designar un data steward por dominio crítico (cliente, producto, riesgo, transacción) con autoridad explícita para declarar el sistema of record. Sin ese ownership, el agente no tiene a quién consultar cuando hay conflicto entre fuentes.
  • Publicar un glosario de negocio vinculado al catálogo de datos. Cada concepto que el agente puede consultar debe tener una definición aprobada, una fuente autoritativa y una fecha de revisión. Herramientas como Collibra, Alation o Apache Atlas permiten implementarlo; lo que no puede delegarse en la herramienta es la decisión sobre qué definición es la correcta.
  • Implementar trazabilidad (data lineage) a nivel de atributo en los datasets que alimentan al agente. Si el agente devuelve un resultado que luego se cuestiona, el equipo de gobernanza debe poder responder en minutos de dónde vino ese dato, quién lo transformó y cuándo.

Bancos y aseguradoras en LATAM ya enfrentan esta tensión

En Argentina, las entidades financieras bajo supervisión del BCRA deben garantizar la integridad de la información reportada —la Comunicación A 7724 y sus actualizaciones establecen controles sobre la calidad y consistencia de los datos prudenciales—. Si un agente de IA interviene en la generación de esos reportes sin una capa de MDM robusta, la entidad expone no solo la calidad del reporte sino su trazabilidad ante el regulador. En Brasil, la resolución BCB 85/2021 que regula el Open Finance impone estándares similares sobre consistencia de datos compartidos entre instituciones. En ambos casos, el regulador espera datos trazables y auditables; un agente sin gobernanza de datos subyacente no puede garantizar ninguna de las dos condiciones.

En México, el marco de la CNBV sobre gestión de riesgos tecnológicos también demanda controles sobre la calidad e integridad de los datos utilizados en sistemas de decisión automatizada. Los equipos de datos que estén evaluando agentes de IA para procesos regulados deben mapear primero qué datos consume el agente, qué define como “fuente verdadera” cuando hay conflicto y quién es responsable si esa definición es incorrecta. Si ninguna de esas preguntas tiene respuesta documentada, el agente no está listo para producción regulada.

Para leer los principios de gestión de datos maestros y referencia en profundidad, el DAMA-DMBOK 2.0 (capítulos 9 y 10) y el framework CDMC del EDM Council son los puntos de partida más rigurosos disponibles para equipos que necesitan construir esa capa antes de escalar agentes.

El briefing semanal de datos, privacidad e IA en LATAM

Análisis, regulación y noticias curadas. Sin ruido, directo al punto.