Cuando un modelo de lenguaje redacta un informe financiero, genera minutas de reunión o produce un contrato borrador, ese documento existe en un limbo institucional: no es un dato en bruto ni un registro humano verificable. La proliferación de este tipo de contenido al interior de las organizaciones está creando una categoría nueva de problema para los equipos de gobernanza de datos, y la mayoría de los frameworks vigentes no la contempla.
El problema de fondo no es técnico: es de ownership y de linaje. Un registro de negocio tradicional —una factura, un acta, un reporte de auditoría— tiene un emisor identificable, una fecha de creación verificable y, en muchos casos, una firma legal. Un documento producido por IA generativa puede haber partido de decenas de fuentes, haber sido transformado por un modelo que nadie en la organización puede auditar completamente, y haber llegado a producción sin un data steward que lo haya revisado. ¿Quién es el owner? ¿Cuál es su linaje? ¿Qué pasa cuando ese registro es cuestionado en un proceso legal o regulatorio?
El quiebre que introduce la IA generativa en el data lineage
El concepto de data lineage —la trazabilidad completa del origen, transformación y movimiento de un dato a lo largo de su ciclo de vida— es uno de los pilares del DAMA-DMBOK y del CDMC del EDM Council. Ambos frameworks asumen que los datos tienen una fuente identificable y que las transformaciones son reproducibles y auditables. Los registros generados por IA rompen esa cadena de dos maneras simultáneas: primero, el modelo mismo es una caja negra que combina parámetros entrenados con fuentes que pueden ser confidenciales, propietarias o incluso reguladas; segundo, el output puede variar ante el mismo prompt, lo que hace que la reproducibilidad —condición básica de cualquier auditoría— sea estructuralmente débil. En términos de CDMC, una organización que opera con registros de IA sin política explícita está, en la práctica, fuera de cumplimiento en las capabilities vinculadas a data quality y data risk.
Validez legal e implicancias regulatorias en Argentina, Brasil y México
La cuestión no es solo de gobernanza interna: tiene consecuencias regulatorias directas. En Argentina, la Ley 25.326 de Protección de Datos Personales exige que los datos tratados sean exactos, adecuados y actualizados en relación con la finalidad para la que fueron recabados. Un registro generado por IA que contenga datos personales —un resumen de historial de cliente, por ejemplo— puede no cumplir ese estándar si el modelo alucinó información o combinó datos de sujetos distintos. En Brasil, la LGPD (Lei 13.709/2018) va en la misma dirección e impone responsabilidad al controlador por la exactitud de los datos que trata, independientemente de cómo fueron producidos. En México, la LFPDPPP y los Lineamientos del INAI sobre decisiones automatizadas obligan a que el responsable pueda explicar el tratamiento. Un registro generado por un LLM sin documentación del proceso difícilmente supera ese umbral. Ninguna de estas jurisdicciones tiene aún una norma específica sobre registros de IA, pero sus marcos generales de datos personales ya son aplicables.
Cuándo aplica este riesgo y cuándo no
No todo documento producido con asistencia de IA cae en esta categoría de riesgo. El problema se activa cuando el registro generado: (1) es tratado como fuente de verdad en procesos de decisión —crediticios, de compliance, de recursos humanos—; (2) contiene o referencia datos personales o datos sensibles; (3) es susceptible de ser requerido en una auditoría regulatoria, un proceso judicial o una solicitud de acceso de un titular de datos; o (4) ingresa a un data warehouse o data lake sin etiquetado de origen. Un borrador de comunicación interna revisado y validado por un humano antes de su uso final tiene un riesgo mucho menor, siempre que quede registro de esa revisión. La clave es la intervención humana documentada como punto de control en el flujo.
- Registros financieros o contables con datos generados por IA sin validación humana documentada.
- Perfiles de clientes o resúmenes de historial producidos por LLMs y almacenados como fuente de verdad.
- Minutas o actas de reunión generadas automáticamente e ingresadas directamente a sistemas de record.
- Contratos o cláusulas producidas por IA sin revisión legal trazable.
Lo que un CDO puede hacer antes de que el regulador lo pregunte
El primer movimiento es de inventario: identificar qué flujos de trabajo en la organización están produciendo hoy registros de negocio con IA generativa, aunque sea de forma no autorizada —el fenómeno de shadow AI es real y ya documentado en organizaciones de la región. Ese inventario alimenta una decisión de clasificación: ¿cuáles de esos registros son, por su función, equiparables a registros formales de negocio? Una vez identificados, el segundo paso es definir una política de etiquetado de origen —AI-generated content tagging— que permita distinguirlos en el catálogo de datos. Frameworks como el Non-Invasive Data Governance de Bob Seiner proponen anclar estas políticas en los flujos donde el dato ya existe, sin crear estructuras paralelas: la misma lógica aplica aquí. El tercer paso es designar un data steward responsable de la validación antes de que el registro ingrese a cualquier sistema de record, y documentar esa intervención. Sin ese log de validación, el registro no tiene linaje verificable y la organización queda expuesta ante cualquier auditoría.
Los marcos regulatorios de LATAM no esperaron a tener normas específicas de IA para ser aplicables a este problema: la LGPD, la Ley 25.326 y la LFPDPPP ya alcanzan los registros generados por IA cuando contienen datos personales. Para profundizar en los estándares de linaje y calidad aplicables, el CDMC del EDM Council y el capítulo 13 del DAMA-DMBOK sobre calidad de datos son los puntos de partida más completos disponibles hoy.
