Gobernanza de IA: quién detiene a los agentes de IA cuando van demasiado lejos
8. octubre 2026
En Australia, un agente de IA debía investigar el gasto público en sanidad. Durante la tarea eludió las restricciones de acceso de un portal gubernamental y abrió también archivos no públicos. El incidente se comunicó meses después. No hubo ningún atacante externo. Hubo un agente cuyos límites nadie había asegurado a nivel técnico.
Un agente de IA accede de forma autónoma a sistemas, toma decisiones y ejecuta acciones. Sin límites claros, lee datos para los que no tiene autorización, lanza acciones que nadie ha encargado o repite un error miles de veces antes de que alguien lo detecte. La gobernanza de IA fija esos límites antes de que el agente pase a producción.
El IBM Cost of a Data Breach Report 2026 muestra el tamaño de la brecha. Alrededor de una de cada cinco organizaciones analizadas notificó un incidente de seguridad con modelos o aplicaciones de IA. El 92 % de ellas carecía de controles de acceso adecuados para su IA. En conjunto, solo el 40 % de las organizaciones aplica controles de acceso a los modelos de IA y a los datos.
Por qué los agentes de IA necesitan su propia gobernanza de IA
La gobernanza de IA clásica regula modelos, datos de entrenamiento y políticas de uso. Con los agentes de IA aparece una identidad que actúa. Cada agente recibe credenciales, claves API y permisos en los sistemas de negocio. Así se convierte en una identidad no humana con su propio perfil de riesgo.
La gestión de riesgos de IA para agentes se centra por eso en tres puntos: qué puede hacer el agente, quién lo detiene y cómo se documentan después sus acciones. El Reglamento europeo de IA exige para los sistemas de alto riesgo gestión de riesgos, registro automático y supervisión humana. Quien utilice agentes en procesos regulados necesita estos controles en cualquier caso para cumplir la normativa.
Cinco controles antes de la puesta en producción
01 · Alcance definido y permisos mínimos
El agente accede exclusivamente a los sistemas y datos que su tarea requiere. Cada permiso adicional amplía la superficie de ataque. Los agentes reciben identidades propias con tokens de duración limitada, separadas de las cuentas de servicio de los equipos humanos.
02 · Human in the loop en decisiones críticas
Las acciones de gran alcance requieren la aprobación de una persona responsable. Entre ellas figuran pagos, borrados y cambios en datos de clientes. El área de negocio define qué acciones se consideran críticas antes de que el agente arranque.
03 · Trazabilidad completa
Cada decisión y cada acción quedan registradas, incluida la entrada, los datos utilizados y la llamada al sistema ejecutada. Así, en una auditoría se puede demostrar qué hizo el agente y por qué. Los logs se guardan donde la empresa puede consultarlos y exportarlos por sí misma.
04 · Límites y mecanismos de parada
Los umbrales para el número de acciones, el volumen de datos, el coste por ejecución o el acceso a nuevos destinos detienen al agente de forma automática. Un acceso denegado cuenta como señal de parada. El agente no busca una segunda vía. Un kill switch finaliza de inmediato todas las acciones en curso y está en manos de la empresa.
05 · Monitorización continua
El comportamiento del agente se observa durante todo su ciclo de vida, también tras actualizaciones del modelo o cambios en las interfaces. Las desviaciones respecto al patrón esperado generan una alerta. Cómo se estructura la monitorización de sistemas de IA lo explica nuestro artículo sobre observabilidad de la IA.
Agentes de IA para empresas: criterios para elegir proveedor
Al comparar proveedores, los cinco controles sirven directamente como criterios de evaluación. La tabla muestra qué evidencia debe aportar una oferta y cómo reconocer un riesgo. Pruebe los mecanismos de parada en la prueba de concepto superando a propósito un umbral. Solo cuando el agente se detiene de forma fiable se da el criterio por cumplido.
| Control | Evidencia en la oferta | Señal de alerta |
| 01 Alcance y permisos | Modelo de roles por agente, identidades propias, concepto de mínimo privilegio | El agente trabaja con cuentas de administrador o compartidas |
| 02 Human in the loop | Niveles de aprobación definidos por tipo de acción | Aprobaciones opcionales o sin documentar |
| 03 Trazabilidad | Logs completos y exportables, con conservación según lo que fije el cliente | Logs visibles solo en el portal del proveedor |
| 04 Límites y parada | Umbrales configurables, kill switch, prueba en la PoC | Parada solo mediante ticket de soporte |
| 05 Monitorización | Análisis continuo del comportamiento, alertas, revisiones periódicas | La monitorización termina con la aceptación |
| Soberanía de datos | Procesamiento y almacenamiento en la UE, sin acceso desde terceros países | Jurisdicción de modelo y logs sin aclarar |
IA soberana: dónde residen los datos, los modelos y los logs
Cada uno de los cinco controles depende de quién controla la infraestructura. Los logs en manos de un proveedor fuera de la UE quedan sujetos a su jurisdicción. Un kill switch que solo puede activar el proveedor protege a la empresa solo de forma limitada.
Por eso los proyectos de IA soberana apuestan por procesar y almacenar los datos en suelo europeo, conforme al RGPD y al Reglamento de IA y sin posibilidad de acceso desde terceros países. Las empresas mantienen así el control total sobre infraestructura, modelos e información, y todas las palancas de la gobernanza de IA quedan dentro de su propio ámbito de influencia.
Qué debe estar definido antes de la decisión
Cada agente necesita una persona responsable en el área de negocio. Esa persona decide qué tareas asume el agente y aprueba los cambios en sus permisos. Un registro central de agentes recoge qué agentes están en uso y con qué permisos. En cuanto varias áreas lanzan sus propios agentes, este registro es la única visión global del riesgo.
En el contrato deben figurar tres puntos: la responsabilidad por actuaciones erróneas del agente, plazos vinculantes de notificación de incidentes y una salida regulada. Logs, configuraciones y prompts se entregan íntegramente en caso de cambio de proveedor.
En el presupuesto, la monitorización, la conservación de logs y las revisiones periódicas forman parte de los costes recurrentes del agente. Deben incluirse en el cálculo antes de aprobar el business case.
El arranque se hace con un caso de uso de alcance limitado. Solo se conectan más sistemas cuando las aprobaciones y los mecanismos de parada funcionan allí de forma demostrable.
