Hace unos meses, durante una evaluación de gobernanza en una empresa de servicios financieros de tamaño medio, hice una pregunta sencilla: «¿Quién es el dueño de la gobernanza de la IA aquí?»
El CISO dijo que el CTO la poseía porque la IA es una decisión tecnológica. El CTO dijo que el equipo de datos era el responsable porque la IA es fundamentalmente un problema de datos. El responsable de datos dijo que el cumplimiento lo poseía porque la exposición regulatoria es el verdadero riesgo. Cumplimiento afirmó que estaban esperando a que el CTO definiera qué debía gobernar antes de poder redactar las políticas.
Cuatro líderes, cuatro respuestas seguras, cero propiedad.
No era una organización disfuncional. Eran personas experimentadas y bienintencionadas que habían gobernado con éxito la adopción de la nube, la privacidad de datos y las operaciones de seguridad. Tenían marcos, juntas de revisión y auditorías trimestrales, ninguna de las cuales cubría IA. La brecha era estructural, no de conciencia: la gobernanza de la IA no encaja perfectamente en el mandato existente de ningún equipo, así que se sitúa en el espacio entre mandatos, en teoría de todos y nadie en la práctica.
El problema de la gobernanza en la sombra
Si crees que este patrón se limita a programas formales de IA, considera lo que ocurre en los espacios que la dirección no ve.
He visto departamentos de marketing crear herramientas de generación de contenido impulsadas por IA con su propio presupuesto y patrocinio ejecutivo, sin revisión de seguridad, sin clasificación de datos, sin conciencia de TI hasta que apareció la factura tres meses después. En una de las operaciones, un equipo de producto había desplegado una docena de agentes de IA en su flujo de trabajo, la mayoría redundantes, algunos llamándose entre sí en bucles, gastando costes de inferencia que nadie estaba siguiendo porque la factura caía en una cuenta cloud compartida. En otra empresa, una unidad de negocio gestionó su propio proveedor de identidad durante más de un año sin conocimientos de TI, con políticas de autenticación diferentes, sin conexión a sistemas de RRHH para la salida. Cuando preguntamos cómo gestionaban la revocación de acceso, la respuesta fue «honestamente no lo hacemos.»
Si un departamento puede ejecutar una infraestructura de identidad paralela sin que nadie se dé cuenta, ya está ejecutando herramientas de IA paralelas. Las mismas dinámicas organizativas que crean la TI en la sombra crean la IA en la sombra, excepto que la IA en la sombra toma decisiones, genera contenido que los clientes ven y accede a datos que la IT en la sombra tradicional nunca tocó.
La brecha de gobernanza que describí en la publicación 13 trataba sobre organizaciones que despliegaban IA sin marcos de gobernanza. Esta publicación trata sobre lo que ocurre a continuación: organizaciones que saben que necesitan gobernanza pero no se ponen de acuerdo sobre quién la construye, quién la hace cumplir y quién es responsable cuando falla.
Por qué los modelos tradicionales de gobernanza rompen con la IA
La gobernanza tradicional de TI funciona porque las responsabilidades se corresponden claramente con los límites organizativos: el equipo de red gobierna la red, el equipo de seguridad controla los controles de acceso, el equipo de datos gobierna la calidad de los datos. Cada dominio tiene un propietario claro, un alcance claro y una vía de escalada clara.
La IA rompe este modelo porque es inherentemente multifuncional. Un solo agente de IA podría:
- Acceder a datos sensibles de clientes (gobernanza de datos)
- Toma decisiones que afecten a los ingresos (gobierno empresarial)
- Generar contenido que represente a la empresa (marca y gobernanza legal)
- Utiliza modelos de terceros con sus propios términos de servicio (gobernanza del proveedor)
- Funcionar sobre infraestructura cloud con implicaciones de costes (gobernanza FinOps)
- Introducir vulnerabilidades de seguridad a través de su acceso a la herramienta (gobernanza de seguridad)
Ningún mandato de un solo equipo cubre todos estos aspectos. Y cuando la gobernanza requiere coordinación entre seis equipos, el resultado por defecto es que nadie coordina y todos asumen que alguien más lo está gestionando.
Esto no es un problema nuevo en principio. La gobernanza de la nube se enfrentó al mismo desafío transversal hace una década. Pero la gobernanza de la nube tenía una función forzada: la factura llegaba mensualmente y alguien tenía que hacerse cargo. La gobernanza de la IA carece de esa función única de forzar. Los costes se distribuyen, los riesgos son probabilísticos y los fallos a menudo son invisibles hasta convertirse en incidentes.
La paradoja de las herramientas de gobernanza
La industria está respondiendo. OWASP publicó su Iniciativa de Seguridad Agentical Top 10 a principios de 2026, el primer marco revisado por pares específicamente para la seguridad de agentes de IA. Mend.io publicado un Marco de Gobernanza de Seguridad en IA que cubre inventario de activos, clasificación de riesgos y modelos de madurez. Microsoft desarrolló Entra Agent ID para gestionar las identidades de los agentes de IA con acceso condicional y gestión del ciclo de vida. AWS publicó AgentCore Identity para marcos equivalentes de identidad de agente.
Las herramientas existen, pero la arquitectura de gobernanza para que funcione no.
Aquí está la paradoja: Microsoft desarrolló herramientas reales de gobernanza para agentes de IA (Entra Agent ID proporciona acceso condicional, protección de identidad y gestión del ciclo de vida), pero en abril de 2026, investigadores de Silverfort descubrieron que el propio rol de Administrador de ID de Agente tenía un exceso crítico de alcance. Un usuario asignado a ese rol podría asumir cualquier entidad principal de servicio en el tenant, no solo las identidades de los agentes. El noventa y nueve por ciento de los inquilinos tuvo al menos un principal de servicio privilegiado expuesto.
Las herramientas de gobernanza para agentes de IA no estaban gobernadas. El rol destinado a gestionar las identidades de los agentes se basaba en los mismos principios de servicio primitivos que las aplicaciones, y nadie había definido correctamente el límite entre ellos.
El problema estructural es más amplio que el de cualquier proveedor individual: cuando construyes herramientas de gobernanza sin responder primero «¿quién gobierna la gobernanza?», creas una nueva capa de riesgo no propietario.
Cómo es realmente la propiedad
Tras trabajar este problema en múltiples colaboraciones, hemos convergido hacia un modelo que funciona. No hay nada revolucionario en ello, sinceramente. El enfoque se toma de cómo las organizaciones maduras gobiernan la infraestructura en la nube, adaptado a la naturaleza transversal específica de la IA.
El principio fundamental: la propiedad de la gobernanza se asigna por categoría, no por sistema.
En lugar de preguntar «¿quién es el dueño de la gobernanza de la IA?» (una pregunta demasiado amplia para responder), descompones la gobernanza de la IA en categorías específicas y asignas cada una al rol mejor posicionado para definirla, revisarla y hacerla cumplir.
Así es como se ve eso en la práctica. Estas categorías son intencionadamente organizativas más que técnicas: asignan las responsabilidades de gobernanza a los equipos ya capaces de hacerlas cumplir.
| Categoría | Propietario | Lo que gobiernan |
|---|---|---|
| base de seguridad | Responsable de Seguridad / CISO | Cifrado, control de acceso, gestión de secretos, identidad del agente |
| Restricciones | Responsable de Cumplimiento / Legal | Requisitos regulatorios, residencia de datos, trayectoria de auditoría |
| Barandillas arquitectónicas | Arquitecto | Patrones de integración, selección de modelos, límites de infraestructura |
| de codificación | de Ingeniería | Calidad del código, requisitos de pruebas, procesos de revisión |
| Preparación operativa | SRE / Líder | Monitorización, alerta, respuesta a incidentes, procedimientos de reversión |
| de protección de costes | de FinOps | Presupuestos de tokens, enrutamiento por nivel de modelo, detección de anomalías de costes |
| específicas de IA/GenAI | Líder de IA/ML o propietario | Control de alucinaciones, monitorización de sesgos, requisitos de intervención humana en el bucle |
| Fiabilidad | SRE / Líder | Objetivos de disponibilidad, conmutación por error, degradación gradual |
| en el rendimiento | Jefe de Ingeniería / Arquitecto | Requisitos de latencia, estrategia de caché, optimización de recursos |
| Sostenibilidad | en la nube | Eficiencia de recursos, ajuste de tamaño, planificación consciente del carbono |
Si tu organización no tiene un rol dedicado para cada categoría, el principio sigue siendo válido: asignar al líder existente más cercano y dejar que el ámbito crezca con la práctica.
Cada categoría tiene un modelo de gravedad: Obligatorio (sin excepciones, bloquea la infracción por despliegue), Obligatorio (excepciones requieren aceptación documentada del riesgo firmada por un aprobador) y Recomendado (buenas prácticas, desviación señalada pero no bloqueada).
El detalle clave es la cadencia de repaso. Cada propietario de categoría revisa sus barreras de seguridad trimestralmente, confirmando que siguen siendo relevantes, los niveles de severidad son adecuados y se incorporan nuevos requisitos organizativos. Sin la cadencia, el marco se vuelve una documentación obsoleta. Con ello, la gobernanza evoluciona junto con la tecnología.
De la teoría a la práctica: qué cambió
Una organización con la que trabajamos, una empresa de servicios financieros con unos 2.000 empleados, había estado atrapada en el vacío de gobernanza durante ocho meses. Tenían un documento estratégico de IA, un patrocinador ejecutivo y un comité multifuncional que se reunía mensualmente. Nada se estaba haciendo cumplir.
El problema del comité era estructural: tenía autoridad para recomendar pero no para hacer cumplir. Las recomendaciones volvieron a los equipos individuales, que las priorizaron frente a sus retrasos existentes. La gobernanza de la IA siempre perdía ante la entrega de funcionalidades.
Les ayudamos a pasar de un modelo de comité a uno de propiedad por categoría. El CISO no poseía la «gobernanza de la IA». Ella era responsable de la categoría de seguridad básica, con límites específicos que definió, un nivel de severidad que asignó y una revisión trimestral que realizó. El responsable de ingeniería era responsable de los estándares de codificación, el responsable de cumplimiento las restricciones regulatorias, y cada persona sabía exactamente qué era suyo para definir y hacer cumplir.
Tres cosas cambiaron de inmediato:
Primero, las decisiones se aceleraron. Cuando un equipo quería desplegar un nuevo agente de IA, no necesitaba programar una reunión de comité. Revisaron el documento de las barreras de seguridad. Si su diseño cumplía, seguían adelante. Si chocaba con una barrera de seguridad obligatoria, sabían exactamente a quién escalar y cómo era el proceso de excepción. Su primer despliegue de agentes bajo el nuevo modelo fue aprobado en menos de una semana, menos que en el ciclo de seis semanas en el que estaban atrapados.
Segundo, la rendición de cuentas se volvió concreta. Cuando un agente de IA accedía a los datos de los clientes sin la clasificación adecuada, la conversación iba directamente a los detalles: se violó la barrera de seguridad de la gobernanza de datos en la categoría 2, el responsable de cumplimiento es el responsable de la categoría, y aquí está el proceso de excepción que debería haberse seguido. La culpa desapareció porque la estructura hacía obvio el siguiente paso.
Tercero, el marco escalaba sin escalar el número de empleados. Esta es la paradoja que un profesional de seguridad expresó perfectamente: «Si tuviéramos que hacer una evaluación de riesgos de IA a la escala que la empresa quiere desplegar en casos de uso, tendríamos que añadir tanta plantilla en seguridad que perderíamos cualquier ganancia.» La propiedad de categorías soluciona esto porque cada propietario gobierna su dominio usando la experiencia que ya posee. El responsable de seguridad no necesita entender la arquitectura de modelos. El arquitecto no necesita entender el cumplimiento normativo. Cada persona gobierna lo que ya sabe, aplicado a sistemas de IA.
La señal de precios del proveedor
Hay una señal reveladora en cómo los proveedores valoran la gobernanza de agentes de IA. El ejecutivo de Microsoft, Rajesh Jha, describió a los agentes de IA como «oportunidades de asiento», lo que significa que cada agente necesita una licencia de software igual que cada empleado. El modelo de precios revela si los proveedores tratan a los agentes como plantilla o como sistemas, y el incentivo económico es vender más plazas, no ayudarte a gobernarlos. La complejidad de la propiedad crece con cada nuevo agente que despliegas.
Tu marco de gobernanza no puede depender solo de las herramientas del proveedor. La responsabilidad, la gravedad, la cadencia de revisión y la arquitectura de la aplicación deben proceder de la organización.
La comunidad está construyendo a los primitivos
Lo que me da confianza en que este modelo funciona es que la comunidad está llegando de forma independiente a los mismos patrones. Los desarrolladores están creando listas de denegación de acciones para agentes MCP (lo que los agentes no pueden hacer) y flujos de trabajo de PR gobernados (puertas de aprobación humana para cambios iniciados por agentes). La Iniciativa de Seguridad Agential OWASP formaliza lo que los profesionales han ido descubriendo a través del dolor de producción: los agentes necesitan arquitectura de gobernanza, no solo capacidad.
Estos son los pilares de la gobernanza de la IA como código. Los negadores de acciones definen lo que los agentes no pueden hacer. Las PR gobernadas requieren aprobación humana antes de que los cambios iniciados por agentes lleguen a producción. En conjunto, ofrecen a las organizaciones una forma de conceder autonomía a los agentes dentro de los límites, que es exactamente lo que permite el modelo de propiedad de categorías a nivel organizativo.
La convergencia se produce desde ambas direcciones: de arriba hacia abajo (marcos de gobernanza organizacional) y de abajo arriba (primitivas de gobernanza construidas por desarrolladores). Las organizaciones que conecten ambos gobiernan la IA de manera eficaz. Quienes solo tienen una tendrán una gobernanza que no podrá aplicarse (solo de arriba hacia abajo) o una aplicación sin alineación estratégica (solo de abajo hacia arriba).
Qué significa esto para tu organización
Si estás leyendo esto y reconociendo el vacío de propiedad en tu propia organización, aquí tienes por dónde empezar:
No formes otro comité. Los comités recomiendan. Los propietarios deciden. El cambio de «comité de gobernanza de IA multifuncional» a «propietarios de categoría con alcance y autoridad definidos» es el cambio de mayor influencia que puedes hacer.
Empieza con tres categorías, no diez. La línea base de seguridad, las barreras de seguridad específicas de IA/GenAI y las de costes cubren las áreas de mayor riesgo. Añade categorías a medida que la organización madura. Intentar gobernar todo a la vez garantiza que no gobiernes nada.
Haz que las barreras de seguridad documenten la fuente de la verdad. Cada despliegue de IA, cada configuración de agente, cada integración de modelos debería hacer referencia a este documento. Las propias herramientas de IA deberían validar contra ella antes de su despliegue. Las barreras que solo existen en un PDF de política que nadie lee están muertas al llegar.
Hacer cumplir la revisión trimestral. La gobernanza que no evoluciona se convierte en un obstáculo. La revisión trimestral es cuando los propietarios de las categorías confirman que sus límites siguen siendo la realidad, ajustan los niveles de gravedad según los incidentes e incorporan nuevos requisitos. Si se salta la revisión, el marco se descompone en dos trimestres.
Una última reflexión
La pregunta «¿quién es el dueño de la gobernanza de la IA?» es irrespondible en su forma actual. Es como preguntar «¿quién es el dueño de la nube?» La respuesta es: depende de qué aspecto de la nube te refieras, y la organización que intente asignar un solo propietario a todo ello fracasará.
La propiedad de la gobernanza de la IA es una decisión de arquitectura, no de organigrama. Lo diseñas igual que diseñas la arquitectura del sistema: descomponiendo un problema complejo en dominios acotados, asignando una propiedad clara a cada dominio, definiendo las interfaces entre ellos y estableciendo la cadencia con la que se revisa todo el sistema.
Cerrar la brecha de gobernanza se reduce a tres preguntas respondidas concretamente: quién posee cada parte, qué autoridad tienen y cómo la ejercen. Los documentos de estrategia no te llevarán hasta ahí. Los propietarios designados con alcance definido sí lo harán.
El vacío es la vulnerabilidad, y la única forma de llenarlo es con estructura.
Ricardo
