Saltar al contenido
Todos los insights

Gobernanza operativa de IA: la que se ejecuta, no la que se firma

5 min de lecturaAI GovernanceAgentesEU AI Act
Diagrama de las tres capas de la gobernanza operativa: decidir, con políticas y límites de autonomía; vigilar, con un guardián en runtime y aprobación humana; y demostrar, con trazas y evidencia verificable

Si preguntas en una empresa mediana si tiene gobernanza de IA, la respuesta suele ser que sí. Hay un comité, una política de uso aceptable de dos páginas, un registro de riesgos que se revisa cada trimestre y, en las más avanzadas, una persona con el título de responsable de IA. Todo eso existe y todo eso es papel.

Si preguntas después qué pasa cuando un agente conectado al CRM intenta borrar mil contactos a las tres de la mañana, la respuesta es distinta: nadie lo sabe, porque nada lo está mirando.

Esa distancia entre lo que está escrito y lo que ocurre es el problema que la gobernanza operativa viene a cerrar. No sustituye al comité ni a la política. Es la parte que falta debajo.

Tres verbos

La gobernanza operativa se resume en tres verbos, y cada uno produce algo que se puede enseñar a un auditor, a un cliente o a un consejo.

Decidir. Alguien ha escrito qué puede hacer cada sistema de IA por su cuenta, qué necesita aprobación y qué está prohibido. No en abstracto: para este agente, con estas herramientas, sobre estos datos. El artefacto es una política que una máquina puede evaluar, no un párrafo que una persona interpreta.

Vigilar. Algo fuera del sistema comprueba cada acción relevante contra esa política antes de que ocurra. Si la acción no se puede deshacer, se detiene y espera a una persona. El artefacto es un punto de control en runtime, lo que el OWASP GenAI Security Project llama un Guardian Agent.

Demostrar. Cada decisión, humana o automática, deja un registro que permite reconstruir qué hizo el sistema, con qué datos y bajo qué regla. El artefacto es una traza que el SOC ya sabe leer y que el auditor puede verificar sin pedir capturas de pantalla.

Cuando falta cualquiera de los tres, lo que hay es otra cosa. Política sin vigilancia es un deseo. Vigilancia sin política es un filtro arbitrario que cada equipo configura a su manera. Y las dos sin evidencia no sirven el día que alguien pregunta qué pasó.

Qué la diferencia de la gobernanza de documento

La gobernanza clásica de IA se diseñó para modelos que se entrenaban, se validaban y se desplegaban una vez. Tiene sentido que sus herramientas sean de esa escala: una evaluación de impacto antes de salir a producción, una revisión anual, un comité que aprueba casos de uso.

Los agentes rompen ese ritmo. Un agente decide en cada turno qué herramienta invocar y con qué argumentos, y esos argumentos pueden venir de un correo, de una página web o de un documento que alguien ha dejado en un SharePoint. El caso de uso aprobado en enero no describe lo que el agente hará en marzo, porque lo que hará depende de lo que lea.

Por eso las preguntas cambian de escala:

  • La gobernanza de documento pregunta si el caso de uso está aprobado. La operativa pregunta si esta llamada concreta a esta herramienta está dentro de lo aprobado.
  • La de documento revisa el sistema cada trimestre. La operativa revisa cada acción antes de ejecutarla.
  • La de documento produce actas. La operativa produce trazas.

No es que una sea buena y la otra mala. Es que la primera sin la segunda ya no describe lo que pasa en producción.

Lo que produce cada capa

Merece la pena bajar al detalle, porque "gobernanza" es una palabra que admite cualquier cosa y aquí queremos que admita poco.

Decidir

  • Inventario con responsables. Cada sistema de IA, incluidos los que llegaron dentro de un SaaS, con una persona que responde y puede apagarlo. Cómo levantarlo en cinco días lo contamos en inventario de sistemas de IA en una semana.
  • Límites de autonomía por sistema. Una tabla de tres columnas: lo que hace solo, lo que hace con aprobación, lo que no hace. Escrita para cada agente, no para la empresa.
  • Política evaluable. Las reglas en un lenguaje que un motor pueda ejecutar: Cedar, Rego o el que ya use tu plataforma. Una política en prosa no se puede aplicar en runtime, y por tanto no se aplica.

Vigilar

  • Punto de control fuera del agente. El agente propone, algo externo decide. Si la lógica de control vive dentro del mismo proceso que el modelo, el modelo puede convencerla.
  • Permisos mínimos por herramienta. Identidad propia para cada agente y solo las credenciales que necesita para su tarea. Es el control que más falla en la práctica y le dedicamos un artículo aparte: permisos de herramientas para agentes.
  • Aprobación humana donde no hay vuelta atrás. Pagos, borrados, envíos externos, cambios de permisos. La persona no supervisa todo, supervisa lo irreversible.

Demostrar

  • Traza por acción. Qué se pidió, qué regla se evaluó, qué se decidió, qué se ejecutó. Con la procedencia de cada argumento, porque el argumento es donde entra el ataque.
  • Evidencia exportable. Si la traza solo la ve la plataforma del agente, no es evidencia. Tiene que salir a donde ya vive la seguridad de la empresa: el SIEM, en un formato como OCSF.
  • Métricas de cobertura. Qué porcentaje de acciones pasa por el punto de control. Una gobernanza que cubre el 40 % de las llamadas a herramientas no es gobernanza, es muestreo.

Por qué ahora encaja con la regulación

No es casualidad que las tres capas se parezcan a lo que pide el Reglamento (UE) 2024/1689 para sistemas de alto riesgo: gestión de riesgos continua (Art. 9), registro de eventos (Art. 12) y supervisión humana con capacidad real de intervenir (Art. 14). Tampoco a lo que un auditor de ISO/IEC 42001 busca cuando pregunta por control operativo.

La diferencia es que la regulación describe el resultado y no dice cómo llegar. La gobernanza operativa es el cómo, y tiene la ventaja de que la evidencia que produce para el negocio es la misma que sirve para el cumplimiento. Qué obligaciones aplican y desde cuándo lo desglosamos en qué exige el Reglamento de IA; si dudas de la categoría de tu sistema, la calculadora de riesgo del EU AI Act la resuelve en unos minutos.

Por dónde se empieza

Por el inventario. Es la capa más barata y la única sin la que el resto no tiene sentido: no se puede escribir la política de un sistema que no se sabe que existe.

Después, un agente. No la empresa entera: el agente con más acceso a sistemas reales. Se le escriben los límites, se le pone el punto de control delante y se comprueba que la traza llega al SIEM. Con uno funcionando, el segundo cuesta una fracción.

Y antes de todo eso, una medida. Hemos preparado un checklist de control de agentes con cuarenta comprobaciones de sí o no en ocho áreas. Se hace en una tarde, no necesita herramientas nuevas y la puntuación dice por cuál de las tres capas empezar. Si prefieres que lo hagamos con tu equipo sobre tus sistemas, eso es exactamente el diagnóstico de control.