Muchas iniciativas de inteligencia artificial llegan al mismo punto: el piloto funciona, pero llevarlo a producción obliga a responder preguntas que el modelo no resuelve.
¿La información que utiliza sigue vigente? ¿Ese agente debería tener acceso a esos datos? ¿La organización podría reconstruir qué ocurrió si entrega una respuesta incorrecta o ejecuta una acción equivocada?
Ese es, en la práctica, un problema de gobierno de datos para IA.
Cuando una organización me pregunta si está preparada para escalar inteligencia artificial, no empiezo por la elección del modelo. Primero reviso si los datos que sostienen el caso de uso son confiables, si su uso está autorizado y si existe trazabilidad suficiente desde la fuente hasta el resultado.
Esto no exige gobernar todo el patrimonio de datos antes de avanzar. Exige identificar qué información es crítica para cada caso de uso y aplicar un nivel de control proporcional a su riesgo.
Esta lógica es consistente con el AI Risk Management Framework de NIST, que plantea que la gobernanza y la gestión del riesgo deben acompañar el ciclo de vida de los sistemas de inteligencia artificial.
No necesitas gobernar todos tus datos para empezar con IA
Una organización que quiere implementar agentes internos o una solución de generación aumentada por recuperación (RAG) no necesita corregir cada problema de datos existente en la compañía.
Sí necesita controlar las fuentes que esos sistemas pueden utilizar y las condiciones bajo las cuales pueden hacerlo.
En una evaluación de preparación de datos para IA, revisaría primero preguntas concretas:
- ¿Cuál es la fuente autorizada para cada dato o documento crítico?
- ¿Qué nivel de actualización requiere el caso de uso?
- ¿Quién responde cuando la calidad cae bajo un umbral aceptable?
- ¿Qué versión de un documento está indexando una solución RAG?
- ¿Qué datos y herramientas puede utilizar un agente según su identidad?
- ¿Qué evidencia queda disponible para reconstruir una respuesta o acción?
Cuando responder estas preguntas exige buscar correos antiguos, revisar varios sistemas o localizar a la persona que “sabe cómo funciona”, la brecha de gobierno ya es visible.
Y normalmente se vuelve más costosa cuando el caso de IA intenta pasar de un piloto controlado a cientos o miles de usuarios en producción.
1. Calidad de datos con controles operativos, no solo métricas
No toda falla de calidad tiene el mismo impacto.
Un atributo incompleto en una base secundaria y un dato incorrecto utilizado para calcular riesgo, recomendar una acción comercial o responder a un cliente son problemas distintos.
Por eso, la calidad de datos para IA debería definirse alrededor del caso de uso. Para los datos críticos, conviene establecer controles observables: umbrales de completitud, consistencia y frescura, validaciones contra fuentes autorizadas y mecanismos para gestionar excepciones.
La calidad deja de ser un concepto cuando una regla puede ejecutarse, generar una alerta, identificar al responsable y activar una acción correctiva.
Medir calidad permite entender el problema. Operacionalizarla permite evitar que el mismo error llegue repetidamente al modelo, al agente o al usuario final.
En ese sentido, un enfoque de gobierno de datos genera valor cuando las políticas terminan conectadas con controles y procesos operativos, no cuando permanecen únicamente en documentación.
2. Responsabilidad clara sobre el dato antes de automatizar decisiones
La tecnología puede ejecutar una política. No puede decidir quién tiene autoridad de negocio para definirla.
Antes de automatizar un proceso con IA, debería estar claro quién define los datos críticos, quién puede aprobar nuevos usos y quién responde frente a una discrepancia.
La falta de documentación es solo una parte de la brecha. La dificultad real aparece cuando existen dos definiciones válidas para una misma métrica, distintas áreas consideran oficial una fuente diferente o nadie tiene autoridad para resolver el conflicto.
Ahí es donde roles como Data Owner y Data Steward dejan de ser títulos dentro de un modelo de gobierno y pasan a cumplir una función operacional.
Si una solución de IA va a consumir una definición como contexto, la organización necesita saber quién puede determinar cuál es la correcta.
3. Un RAG empresarial necesita contexto, vigencia y permisos
En un sistema RAG, una fuente sin contexto puede ser tan riesgosa como una fuente incorrecta.
Un caso sencillo: una política interna fue actualizada hace seis meses, pero el repositorio conserva también la versión anterior. Si ambas terminan indexadas, el sistema puede recuperar información obsoleta y construir una respuesta coherente sobre una regla que ya no debería aplicarse.
Ese problema no se corrige cambiando el prompt.
Requiere gobernar también el conocimiento: metadatos, versionado, clasificación, responsabilidad sobre el dato, permisos, vigencia y fuentes autorizadas.
La pregunta relevante no es si el chatbot responde bien durante una demostración. Es si la organización puede controlar qué conocimiento entra en esas respuestas cuando la solución escala.
En proyectos de RAG empresarial, esa diferencia es crítica. Un repositorio puede ser técnicamente accesible y, aun así, no ser una fuente válida para determinada respuesta, usuario o contexto.
Por eso, los controles de acceso también deben mantenerse durante la recuperación de información. Microsoft documenta este enfoque en sus recomendaciones para seguridad y control de acceso en soluciones RAG, donde la autorización debe respetarse al momento de recuperar el contenido que alimentará al modelo.
4. Linaje y auditabilidad deben diseñarse dentro de la arquitectura
Cuando una solución de IA participa en un proceso relevante, observar el resultado no siempre es suficiente.
También debería ser posible identificar qué fuentes recuperó, qué versiones utilizó y qué transformaciones ocurrieron antes de que la información llegara al modelo o al usuario.
DataArt enfrentó este desafío en una firma global de análisis crediticio. La plataforma desarrollada automatizó la extracción desde reportes financieros, normalizó la información mediante una taxonomía común y mantuvo auditabilidad hasta la fuente original. El nuevo proceso fue más rápido y alcanzó el doble de precisión que el sistema anterior.
Lo relevante del caso es una decisión de arquitectura: la trazabilidad fue incorporada en el diseño de la solución, no agregada después como respuesta a una auditoría o incidente.
Ese mismo principio resulta especialmente importante cuando la inteligencia artificial empieza a intervenir en procesos financieros, operacionales o comerciales donde reconstruir lo ocurrido deja de ser opcional.
5. Los agentes amplían el perímetro del gobierno
Los permisos tradicionales fueron pensados principalmente alrededor de usuarios y aplicaciones.
Los agentes de IA amplían esa lógica porque pueden tener identidad propia, consultar datos, invocar herramientas y ejecutar acciones.
Gobernar solamente quién puede ver una tabla deja fuera una parte importante del riesgo.
Para un agente empresarial también debería estar definido:
- con qué identidad opera;
- qué fuentes y herramientas están autorizadas;
- qué acciones puede ejecutar y cuáles están restringidas;
- cuándo necesita supervisión humana;
- qué registro queda disponible para auditoría.
Este enfoque también es consistente con el marco de gestión de riesgos de IA de NIST, donde la gobernanza se plantea como una función transversal que debe conectar responsabilidades organizacionales, controles y operación.
DataArt llevó esta lógica a producción al desarrollar una plataforma interna de IA para un grupo financiero global. La solución opera dentro de la infraestructura del cliente, centraliza controles de acceso y auditoría y soporta una comunidad de 73.000 usuarios.
El caso muestra algo especialmente relevante: la plataforma incorpora acceso controlado, trazabilidad de las interacciones y gobierno centralizado sobre el uso de capacidades de IA.
La lección es concreta: si los controles aparecen recién después de la adopción, cada nuevo caso de uso aumenta la deuda de gobierno. Cuando forman parte de la plataforma, la capacidad de escalar cambia.
Gobierno suficiente para avanzar, no gobierno por gobierno
Existe un riesgo en el sentido contrario: detectar estas brechas y responder con un programa de gobierno tan amplio que la IA deba esperar meses antes de producir valor.
En ACL Data Practice parto desde el caso de negocio y desde los datos que realmente pueden comprometerlo.
Una evaluación puede revisar arquitectura, calidad, catálogo, linaje, accesos y preparación para IA para determinar:
- qué riesgos pueden afectar los casos prioritarios;
- qué controles ya existen y pueden reutilizarse;
- qué brechas necesitan intervención inmediata;
- qué capacidades conviene desarrollar después.
Ese enfoque evita dos extremos costosos: escalar IA sobre una base que no puede controlarse o reconstruir toda la plataforma de datos antes de generar valor.
El objetivo es establecer el nivel de gobierno necesario para que el caso pueda avanzar de forma segura y sostenible y extender ese patrón a medida que crece la adopción.
Qué aporta ACL powered by DataArt
Desde ACL powered by DataArt puedo abordar este problema sobre una misma cadena tecnológica: arquitectura e integración de datos, gobierno y calidad, plataformas de inteligencia artificial y operación.
Esa combinación importa cuando la conversación deja de ser cómo construir un buen piloto y pasa a ser cómo operarlo con múltiples fuentes, información sensible, cientos o miles de usuarios y exigencias reales de auditoría.
La propuesta de ACL Data Practice conecta arquitectura, ingeniería de datos, gobierno, analítica e inteligencia artificial con necesidades concretas del negocio.
A eso se suma la experiencia de DataArt en escenarios donde acceso, trazabilidad y control forman parte de la arquitectura, desde plataformas financieras con auditabilidad hasta entornos de IA empresarial a gran escala.
Para mí, el indicador de éxito debería ser simple: cuántos casos de IA pueden llegar a producción con un nivel de calidad, seguridad y trazabilidad acorde con su impacto en el negocio, no cuántos controles o artefactos de gobierno logra crear una organización.
Antes de escalar el próximo caso de IA
Si mañana un agente ejecuta una acción incorrecta, ¿tu organización podría demostrar qué información utilizó, de dónde vino y por qué estaba autorizado a usarla?
Cuando responder eso requiere investigar varios sistemas o depender de conocimiento informal, ya existe una señal clara de dónde empezar.
En ACL powered by DataArt puedo ayudar a evaluar esa brecha, priorizar los controles que realmente necesita el caso de uso y definir un camino para llevarlo desde piloto a producción sin sobredimensionar la iniciativa.
Si tu organización ya está trabajando con modelos, RAG o agentes de IA, conversemos sobre qué tan preparada está tu plataforma de datos para escalarlos con control.
Preguntas frecuentes sobre gobierno de datos para IA
¿Qué datos debería gobernar primero una empresa que quiere implementar IA?
Los datos con mayor impacto sobre el caso de uso. La prioridad debería considerar su criticidad para el negocio, sensibilidad, nivel de acceso, requerimientos de calidad y consecuencias potenciales de una respuesta o acción incorrecta.
¿Qué controles necesita una solución RAG empresarial?
Una solución RAG empresarial debería trabajar con fuentes autorizadas, control de versiones, metadatos, permisos, clasificación de información, trazabilidad y criterios de vigencia. Los permisos deberían mantenerse también durante la recuperación de información para evitar que el modelo exponga contenido que el usuario no debería poder consultar.
¿Cómo cambia el gobierno de datos al implementar agentes de IA?
Un agente puede consultar información, utilizar herramientas y ejecutar acciones. Por eso, el gobierno debe extenderse a la identidad del agente, sus permisos, fuentes disponibles, herramientas autorizadas, límites de acción, supervisión humana y auditabilidad.
