Dos comités de gobernanza conviven hoy en buena parte de las empresas que ya operan algún agente de IA en producción: uno más antiguo, centrado en calidad, acceso y linaje del dato; otro más nuevo, creado de urgencia cuando el primer piloto de IA generativa se salió de control, centrado en riesgo de modelo, sesgo y aprobación de casos de uso. Ambos tienen un mandato parecido — decidir qué puede ejecutarse, bajo qué control, bajo responsabilidad de quién —, pero rara vez comparten reunión, planilla de riesgo o vocabulario.
Este diseño no nació de un plan. Nació de la velocidad: el programa de gobernanza de datos ya existía desde hacía años cuando la ola de agentes autónomos llegó demasiado rápido para esperar la reestructuración de un comité con la agenda llena. El resultado son dos estructuras paralelas — y una zona gris en el medio, donde nadie decide quién aprueba al agente que actúa sobre un dato que el otro comité ya supervisa.
El síntoma: dos comités, una zona gris en el medio
El patrón aparece en cuanto un agente falla en producción: el comité de IA revisa el modelo, el prompt, el registro de decisión — y concluye que el modelo "se comportó como se esperaba" dado lo que recibió. El comité de datos nunca llegó a ver el caso, porque en la cabeza de todos aquello era "problema de IA", no "problema de dato". El incidente queda sin dueño real: cada comité investigó la mitad del problema que le correspondía.
Los números muestran la misma fragmentación a escala. Una encuesta de McKinsey de 2026 encontró que el 70% de las empresas de la Fortune 500 ya tiene un comité de riesgo de IA, y el 41% armó un equipo dedicado de gobernanza de IA — casi siempre reportando fuera de la línea que ya se ocupaba de calidad y acceso de datos. Un relevamiento de Gartner con más de 1.800 ejecutivos, del mismo año, encontró que el 55% de las empresas tiene un consejo o comité formal de supervisión de IA. La estructura nueva creció rápido; la pregunta de cómo encaja con la antigua quedó para después.
La gobernanza de IA que nace junto a la gobernanza de datos resuelve el problema equivocado dos veces — una vez en cada comité.
La brecha de responsabilidad no se queda solo entre comités — sube hasta la cima. La misma encuesta de McKinsey encontró que apenas el 28% de las empresas dice que el CEO asume responsabilidad directa por la gobernanza de IA, y solo el 17% se la atribuye al directorio. Aunque el 62% de los directorios discute IA con regularidad, solo el 27% formalizó el tema en el estatuto de algún comité. Existe debate sobre IA en casi toda dirección — pero rara vez existe un dueño único, formal, que responda cuando el programa falla.
Por qué se volvió un debate abierto en 2026
El gasto confirma que la duda no es académica. Gartner proyecta que el mercado de plataformas de gobernanza de IA moverá US$ 492 millones en 2026 — más del doble de 2024 — y superará los US$ 1.000 millones para 2030, impulsado por una regulación que debe cubrir el 75% de las economías del mundo para entonces. Las empresas que adoptan una de estas plataformas tienen 3,4 veces más probabilidades de reportar alta efectividad en su propia gobernanza de IA, según una encuesta de Gartner a 360 organizaciones en el segundo trimestre de 2025 — pero comprar una herramienta no resuelve la pregunta de estructura detrás de ella.
En el Gartner Data & Analytics Summit 2026 — en Orlando, Londres y Sídney —, analistas como Sarah Turkaly y Anurag Raj presentaron la misma tesis en sesiones dedicadas: las empresas llegaron a un punto de inflexión en el que la gobernanza de datos y analítica puede convertirse en el único punto de falla de toda la estrategia de IA. La formulación repetida en las tres ediciones — "gobernanza de la IA, por la IA y para la IA" — no trata a los dos programas como mundos separados; trata la gobernanza de datos como la base sobre la que cualquier gobernanza de IA debe construirse, no como una disciplina hermana que evoluciona en paralelo.
La mayoría de los incidentes de agentes nace del lado equivocado de la línea
Ya mostramos que un agente exige un estándar de datos más estricto que un dashboard en cuatro ejes específicos: frescura, contexto de negocio, control de acceso por identidad y trazabilidad de punta a punta. Cuando un comité de IA investiga un agente que decidió mal y no ve esos cuatro ejes como parte de su propio alcance, está evaluando el síntoma sin examinar la causa más probable.
La mayoría de los incidentes que parecen falla de modelo son, en el fondo, falla de dato que nadie catalogó como tal.
Lo mismo vale del lado de la automatización. La gobernanza de datos como código ya resuelve, de forma automática, el atributo de trazabilidad que toda investigación de incidente de agente necesita consultar primero — de dónde vino el dato, cuándo se actualizó, qué regla de negocio se aplicó. Una empresa que trata esto como propiedad exclusiva del programa de datos, sin puente con el comité de IA, reconstruye de memoria en cada investigación una traza que ya existía, automatizada, en otra parte de la misma casa.
Esto no significa que la gobernanza de IA sea solo gobernanza de datos con nombre nuevo. El sesgo de clasificación, los ataques de prompt injection, la alucinación factual y la decisión de cuándo un agente actúa sin revisión humana son problemas que la instrumentación tradicional de datos no cubre por sí sola. La pregunta correcta no es "un programa elimina al otro" — es dónde queda la frontera entre ambos, y quién la cruza cuando un incidente no respeta la división del organigrama.
Un programa, dos capas: el diseño que cierra el hueco del medio
El diseño que evita la zona gris no es fusionar los dos comités en una sola reunión, ni mantener dos programas que nunca se hablan. Es tratar la gobernanza de IA como una segunda capa que hereda, obligatoriamente, la primera:
- Capa de base — gobernanza de datos como prerrequisito de onboarding. Ningún agente entra en producción sin pasar por los cuatro atributos de dato listo para IA ya auditados por el programa existente. Esto elimina el escenario en que el comité de IA aprueba un caso de uso sin saber que el dato detrás nunca fue evaluado con ese estándar.
- Capa específica — riesgo que solo existe porque el consumidor decide solo. Sesgo, explicabilidad, prueba adversarial, política de cuándo exigir revisión humana antes de la acción. Esto queda con el comité de IA porque exige una competencia que el equipo de datos tradicionalmente no tiene — no porque sea menos importante.
- Escalamiento único, no doble. Cuando un agente falla, existe un solo camino de investigación que atraviesa las dos capas en el orden correcto — dato primero, modelo después —, en vez de dos investigaciones paralelas que nunca se encuentran.
- Un responsable nombrado por caso de uso, no solo por comité. El rol de dueño del agente ya responde por esto a nivel operativo — la misma lógica de responsabilidad nombrada necesita existir un nivel más arriba, en la decisión de qué comité aprueba qué antes de que el agente salga a producción.
- Traza de auditoría compartida, no duplicada. La trazabilidad que la gobernanza de datos como código ya produce automáticamente se convierte en insumo directo de cualquier investigación de IA — sin que el comité de IA necesite reconstruir la misma información con herramienta propia.
La presión regulatoria empuja en la misma dirección. La ANPD de Brasil ya eligió la IA como eje de fiscalización aun con el marco legal trabado en el Congreso, y la propia Gartner proyecta que, para 2030, la mitad de las empresas usará agentes autónomos para traducir política de gobernanza en contratos de datos verificables por máquina — el tipo de automatización que solo funciona si ambas capas ya hablan el mismo idioma hoy.
La pregunta no es qué comité gana — es dónde queda la frontera
Programa único o dos programas nunca fue, en sí mismo, una disputa de organigrama — es una disputa sobre quién examina qué primero cuando algo sale mal. Una empresa que trata la gobernanza de IA como extensión de la gobernanza de datos, con frontera explícita y escalamiento único, entra a cada incidente sabiendo por dónde empezar la investigación. Una empresa que deja crecer a los dos comités en paralelo sin puente formal solo descubre la frontera después de que un incidente cae justo en el medio de ella.
Preguntas que siempre vuelven
Para cerrar, las dudas más comunes sobre cómo estructurar la gobernanza de IA y la gobernanza de datos.
¿Gobernanza de IA y gobernanza de datos son lo mismo?
No. La gobernanza de datos rige la calidad, el acceso y el linaje del dato; la gobernanza de IA rige cómo se aprueba, monitorea y desactiva un modelo o agente — incluyendo riesgos que el dato por sí solo no cubre, como el sesgo de clasificación, el prompt injection y la decisión de exigir revisión humana antes de una acción. Son disciplinas distintas, pero la mayoría de los incidentes atribuidos a la IA nace de un problema de dato que el programa de datos ya tenía — o debería haber tenido — cubierto.
¿Necesito un comité de IA separado del comité de datos?
Depende de la madurez y de la exposición regulatoria de la empresa, pero el mayor riesgo no es tener dos comités — es tener dos comités sin puente formal entre ellos. El diseño más robusto trata la gobernanza de IA como una segunda capa que hereda obligatoriamente la primera: ningún agente entra en producción sin pasar por los atributos de dato listo para IA ya auditados por el programa existente, con un único camino de escalamiento cuando algo falla.
¿Quién debe responder cuando un agente falla por un dato malo?
El dueño nombrado de ese agente específico es el primer punto de contacto operativo, pero la investigación necesita seguir la frontera correcta: dato primero, modelo después. Si el programa de datos y el programa de IA nunca compartieron traza de auditoría, esa investigación reconstruye de memoria una información que ya existía, automatizada, en otra parte de la misma empresa — el motivo más común por el que un incidente tarda semanas en explicarse en vez de minutos.