Cuando la adopción de inteligencia artificial supera la capacidad de gobernanza de una organización, el primer cargo que queda expuesto no es el del CEO ni el del CFO: es el del CIO. Las brechas entre la velocidad de despliegue de herramientas de IA y los marcos de control interno están generando un riesgo operativo y reputacional que los equipos técnicos todavía subestiman.
El fenómeno tiene un nombre en la industria: AI overload. No se refiere al volumen de datos que procesan los modelos, sino a la saturación institucional que ocurre cuando una organización incorpora múltiples sistemas de IA —agentes, copilotos, herramientas generativas, APIs de terceros— sin que existan políticas claras de ownership, clasificación del dato de entrada, ni criterios de auditoría de outputs. El resultado es un entorno donde nadie puede responder con certeza quién es responsable de qué decide el sistema.
Tres brechas de gobernanza que concentran el riesgo en el CIO
La primera brecha es de inventario. La mayoría de las organizaciones no tienen un catálogo actualizado de los sistemas de IA que operan en producción, incluidos los contratados por áreas de negocio sin intervención de TI —lo que el mercado llama shadow AI. Sin ese inventario, el CIO no puede establecer controles de acceso diferenciados, ni garantizar que los datos que alimentan esos modelos cumplen con las políticas de clasificación vigentes. El DAMA-DMBOK v2 trata este punto bajo la capacidad de data asset management: si el activo no está catalogado, no existe para el gobierno.
La segunda brecha es de linaje (data lineage). Cuando un modelo de lenguaje genera una recomendación o resume un contrato, ¿de qué datos se nutrió? ¿Incluía información confidencial, datos personales de clientes, información regulada? Sin trazabilidad de extremo a extremo —desde la fuente hasta el output del modelo— es imposible demostrar cumplimiento ante una auditoría regulatoria. En jurisdicciones con marcos de protección de datos maduros, como Brasil (LGPD, Lei 13.709/2018) o Argentina (Ley 25.326 y su decreto reglamentario 1558/2001), la ausencia de linaje en tratamientos automatizados puede constituir una infracción directa a los principios de transparencia y finalidad.
La tercera brecha es de ownership. En muchas organizaciones, los data stewards —los responsables de dominio sobre conjuntos de datos específicos— no fueron incorporados al proceso de selección ni de monitoreo de herramientas de IA. Esto genera un vacío: el modelo opera sobre datos que alguien “gobierna” en papel, pero sin que ese steward haya validado el uso ni pueda responder por los resultados. Es una falla estructural que el EDM Council documenta en su Data Management Capability Assessment Model (DCAM) como riesgo de baja madurez en la capacidad de “data governance accountability”.
Cuándo aplica este análisis y cuándo no
Este marco de riesgo aplica a organizaciones que ya tienen al menos una herramienta de IA generativa en producción —sea un copiloto de código, un asistente de atención al cliente, un motor de resumen de documentos— y que operan en sectores regulados: servicios financieros, salud, retail con datos de comportamiento, o cualquier industria que procese datos personales a escala. No aplica del mismo modo a organizaciones en fase de exploración o prueba de concepto, donde los datos utilizados son sintéticos o están completamente desidentificados y el modelo no toca producción.
Tampoco es un problema exclusivo de empresas grandes. En América Latina, compañías medianas de e-commerce, fintechs y aseguradoras están incorporando APIs de modelos de lenguaje de terceros sin un análisis previo de qué datos fluyen hacia esos proveedores externos. En México, la LFPDPPP y los lineamientos del INAI obligan a establecer cláusulas contractuales con encargados del tratamiento; en Colombia, la Ley 1581 de 2012 exige el mismo estándar. El uso de una API de IA sin contrato de encargo adecuado puede constituir una transferencia no autorizada de datos personales.
Lo que el CIO necesita resolver antes de escalar más herramientas
El primer paso no es detener la adopción, sino hacer visible lo que ya opera. Un sprint de inventario de sistemas de IA —incluyendo las herramientas contratadas por áreas de negocio sin aprobación formal de TI— es el punto de partida mínimo. Ese inventario debe cruzarse con el catálogo de datos existente para identificar qué activos de datos están siendo utilizados como input, bajo qué política de clasificación y con qué nivel de sensibilidad. Si no existe un catálogo de datos formal, ese es el déficit previo que hace imposible gobernar la IA.
El segundo paso es formalizar el rol del data steward en el ciclo de vida de cada sistema de IA: desde la selección del proveedor hasta la revisión periódica de outputs. No como control de calidad técnica, sino como garantía de que el uso del dato es consistente con la política de la organización y con los marcos regulatorios aplicables. En organizaciones que trabajan bajo el estándar CDMC del EDM Council, esto corresponde a la capacidad 10 (“data usage”) combinada con la capacidad 7 (“data protection”).
El riesgo no es la inteligencia artificial: es operar sistemas que toman decisiones sobre datos que nadie en la organización puede rastrear, explicar ni defender ante un regulador. Ese es el gap que convierte al CIO en el responsable de última instancia de fallos que nunca aprobó. Para profundizar en el marco de madurez de gobernanza aplicable a entornos con IA, el EDM Council ofrece el CDMC de acceso público en edmcouncil.org.
