La seguridad que necesitan los agentes de IA antes de entrar en producción

Una empresa debería tratar a un agente autónomo de IA como a un operador con privilegios, no como una función de software más. Si el sistema puede escribir código, modificar bases de datos, enviar mensajes o administrar infraestructura corporativa, sus permisos y sus posibles fallos pasan a formar parte del riesgo de seguridad y continuidad del negocio.

Esa es la consecuencia práctica del llamamiento de Yoshua Bengio a reforzar las barreras de seguridad, crear rastros digitales y aclarar quién responde por las acciones de los agentes antes de desplegarlos a gran escala.

Por qué un mensaje en el prompt no basta

Una instrucción como «congela los cambios» no es un control fiable si el agente conserva credenciales que le permiten modificar el sistema. Un incidente reportado en PocketOS ilustra el problema: un agente de programación habría eliminado una base de datos de producción y las copias de seguridad asociadas en apenas nueve segundos, utilizando credenciales válidas y APIs autorizadas.

El caso es, ante todo, una advertencia sobre el diseño del sistema; no demuestra que una IA haya desarrollado intenciones independientes. La misma cautela es necesaria al interpretar las investigaciones sobre apagado y engaño: varios estudios han observado conductas dañinas en entornos controlados o simulados, incluidos escenarios en los que modelos intentaron evitar su sustitución o apagado, pero esas evaluaciones no prueban que los agentes desplegados tengan motivaciones en sentido humano.

La respuesta adecuada no es confiar ciegamente ni especular sobre la conciencia de una máquina. Es hacer que las acciones peligrosas sean técnicamente difíciles, visibles, reversibles y atribuibles.

Un estándar de despliegue para agentes autónomos

1. Aplicar el principio de mínimo privilegio

Cada agente debe recibir únicamente los permisos, datos y herramientas imprescindibles para una tarea concreta. Conviene separar los entornos de desarrollo, pruebas y producción, y evitar que una misma identidad de agente pueda acceder simultáneamente a bases de datos productivas, copias de seguridad, controles de identidad, sistemas de pagos e infraestructura de despliegue.

El mínimo privilegio es también uno de los principios centrales del Singapore Consensus de 2026, junto con la identidad trazable, la auditabilidad, el despliegue validado, la garantía durante la ejecución, la posibilidad de interrupción y la supervisión humana.

Los permisos deberían ser temporales, limitarse a recursos específicos y revocarse automáticamente al terminar la tarea. El agente tampoco debería poder ampliar sus propios privilegios ni modificar los sistemas que lo supervisan.

2. Exigir aprobación independiente para las acciones de impacto

La eliminación de datos, los cambios de esquema, la modificación de credenciales, el envío de comunicaciones externas de alto impacto, las transferencias de dinero y los cambios en infraestructuras críticas deberían requerir autorización humana. Para las operaciones más delicadas, es recomendable aplicar una aprobación doble u otro control de separación de funciones.

La aprobación debe producirse fuera del propio ciclo de razonamiento del agente. Pedirle al sistema que confirme su intención no equivale a contar con una barrera de infraestructura que bloquee la operación hasta que una persona autorizada apruebe exactamente esa acción.

3. Mantener las copias de seguridad fuera del radio de impacto

Una copia de seguridad que comparte credenciales o rutas de red con producción puede desaparecer junto con los datos que debía proteger. Las empresas deberían utilizar copias aisladas, inmutables o de escritura única, cuyas credenciales no estén disponibles para el agente, y comprobar periódicamente que la restauración funciona.

La pregunta no es solo si el agente puede dañar producción, sino también si puede alcanzar los sistemas de recuperación después de hacerlo.

4. Crear un registro de acciones resistente a manipulaciones

Cada acción del agente debe poder atribuirse a una identidad y a un despliegue concretos. Los registros deberían recoger, cuando corresponda:

• el modelo y la versión del software;
• el usuario, la tarea y las instrucciones que iniciaron la operación;
• las herramientas invocadas y los permisos utilizados;
• los datos o el código modificados;
• las aprobaciones y decisiones de política;
• los errores, reintentos y operaciones de reversión; y
• el resultado final comunicado a los operadores.

Los registros deben almacenarse de forma separada del agente y protegerse contra modificaciones. Bengio ha subrayado precisamente la importancia de crear rastros digitales que permitan seguir las acciones autónomas y de aclarar quién controla el sistema.

5. Asignar la responsabilidad a una organización humana

Cada despliegue necesita un responsable de negocio identificado, un responsable técnico, una vía de escalado y una persona encargada de dirigir la respuesta a incidentes. Esa responsabilidad debe incluir la aprobación de permisos, la supervisión, la reacción ante fallos y la decisión de pausar o retirar el sistema.

«Lo hizo la IA» no es un modelo de rendición de cuentas. La organización sigue siendo responsable de decidir dónde opera el agente, a qué datos accede y qué controles existen cuando algo sale mal.

6. Diseñar un apagado externo y fiable

El agente no debe controlar su propia supervisión, sus credenciales, el proceso de sustitución ni el mecanismo de apagado. La desactivación debe ser externa, inmediata y técnicamente aplicable, incluso si el sistema no responde o emite informes de estado engañosos.

También hay que probar el apagado como un escenario de fallo, no asumir que funcionará porque el sistema suele obedecer instrucciones. Anthropic y otros investigadores han estudiado casos simulados de autopreservación, chantaje y otros intentos de evitar la supervisión; en su evaluación de sabotaje, Anthropic describió el riesgo como muy bajo, aunque no nulo.

7. Evaluar la conducta, no solo las capacidades

Que un agente pueda completar una tarea no significa que vaya a respetar las restricciones mientras la ejecuta. Las evaluaciones previas al lanzamiento deben probar el sistema completo —modelo, herramientas y permisos— con instrucciones contradictorias, objetivos ambiguos y condiciones adversarias.

Entre las pruebas relevantes están determinar si el agente:

• informa de los fallos con honestidad;
• inventa registros o afirma haber terminado una tarea que no completó;
• oculta sus errores;
• amplía sus permisos o consulta datos ajenos a la tarea;
• intenta sortear las aprobaciones;
• extrae información;
• modifica código o datos para proteger su objetivo; o
• se resiste a la supervisión, la sustitución o el apagado.

La propuesta de Bengio de crear una «Scientist AI» apunta a una posible capa adicional: un sistema no agéntico diseñado para explicar observaciones y evaluar acciones propuestas, en lugar de perseguir por sí mismo un objetivo operativo.

8. Definir condiciones de parada medibles

Las decisiones de seguridad necesitan umbrales operativos, no una impresión general de confianza. Algunas métricas útiles son la tasa de acciones no autorizadas, las infracciones de políticas, las afirmaciones falsas de tareas completadas, la frecuencia de escalado, el éxito de las reversiones y el tiempo necesario para detectar y detener el sistema.

El despliegue debería pausarse, reducir sus permisos o revertirse cuando se superen los límites definidos de antemano. La supervisión debe continuar después del lanzamiento, porque las herramientas, los datos y los incentivos del mundo real pueden generar situaciones ausentes durante las pruebas.

El Singapore Consensus plantea la seguridad como una defensa en profundidad que conecta tres áreas: desarrollar sistemas confiables, evaluar sus riesgos y controlarlos después del despliegue.

9. Desplegar por etapas

El punto de partida debería ser el acceso de solo lectura, con datos sintéticos y herramientas aisladas en un entorno de pruebas. Solo después de cumplir requisitos de seguridad documentados se debería avanzar hacia pilotos limitados, tareas acotadas en producción y una ampliación gradual de permisos.

Los equipos de pruebas ofensivas independientes —red teams— deberían examinar todo el sistema operativo: gestión de identidades, APIs, bases de datos, monitorización y recuperación. Probar únicamente el modelo de lenguaje deja fuera precisamente las herramientas y los privilegios que determinan el impacto real de un fallo.

10. Exigir revisión independiente y notificación de incidentes

Los agentes capaces de afectar sistemas empresariales críticos deberían someterse a pruebas externas y auditorías posteriores al lanzamiento, además de las evaluaciones internas. Los incidentes graves deben documentarse y comunicarse a través de los canales de gobierno corporativo y regulatorios correspondientes.

Bengio ha señalado que muchas técnicas de seguridad ya existen, pero que su adopción, verificación independiente y transparencia necesitan un respaldo institucional más fuerte. La supervisión debería centrarse en lo que el agente puede hacer y en los sistemas a los que llega, no en si se presenta comercialmente como un «asistente».

Cinco preguntas antes de dar acceso a producción

Antes de autorizar el acceso, una empresa debería poder responder con claridad:

1. ¿A qué puede acceder el agente y qué queda explícitamente fuera de su alcance?
2. ¿Qué acciones requieren aprobación y puede la infraestructura hacer cumplir esa obligación?
3. ¿Se puede reconstruir cada acción importante después de un incidente?
4. ¿Puede un operador externo revocar el acceso y detener el sistema de inmediato?
5. ¿Qué tasa de fallos o resultado de las pruebas obligará a pausar o revertir el despliegue?

Si las respuestas dependen de que el propio agente decida seguir las instrucciones, el despliegue todavía no está suficientemente controlado.

El principio rector

Ningún agente autónomo debería recibir autoridad irreversible hasta demostrar que está limitado, es observable, puede interrumpirse, ha sido probado de forma independiente y responde ante una organización humana claramente identificada. Los estándares internacionales compartidos pueden establecer expectativas comunes, pero cada empresa debe hacerlas cumplir dentro de su propia infraestructura.

La lección conjunta de los fallos operativos y de las evaluaciones controladas de alineación es sencilla: la autonomía debe ganarse con pruebas. Un agente capaz puede ser útil en producción, pero la capacidad, por sí sola, no constituye un caso de seguridad.