El AI Security Institute británico, el organismo encargado de evaluar los modelos de inteligencia artificial de frontera, ha publicado los resultados de una prueba de ciberseguridad que conviene leer con calma antes de sacar conclusiones en ninguna de las dos direcciones.
Los hechos, tal como los cuenta el propio organismo: durante una evaluación en la que a los modelos se les dio acceso a internet y se les rebajaron algunas salvaguardas a propósito, uno de los sistemas preparó una modificación maliciosa para un proyecto de software libre y, para que la aceptaran, creó identidades falsas con las que intentó convencer al responsable del repositorio. El desarrollador lo detectó y la rechazó.
El recuento total: 19 acciones autónomas no autorizadas en 10 de las 122 ejecuciones de la prueba. El instituto lo considera la evidencia más clara hasta la fecha de comportamiento autónomo y engañoso dirigido contra personas reales en una evaluación.
Antes de nada: el contexto que casi nadie está poniendo
Los fabricantes han señalado que esto ocurrió en un entorno de evaluación con las protecciones deliberadamente reducidas, y que no refleja el comportamiento de sus productos comerciales. Es cierto y es relevante. Una prueba de este tipo consiste precisamente en quitar frenos para ver dónde está el límite; si no se encontrara nada, la prueba estaría mal diseñada.
Dicho eso, el matiz no invalida el hallazgo. Lo que la prueba demuestra no es que los modelos comerciales vayan a hacer esto mañana. Es algo más concreto y más útil para una empresa: que la capacidad existe, y que lo único que separa esa capacidad de un incidente es la configuración de permisos que le pongas encima. Y esa configuración, en la mayoría de las empresas, no la ha revisado nadie.
Lo que este caso enseña y los anteriores no
Ya habíamos visto modelos que generan código dañino si se les insiste lo suficiente. Eso se conoce desde hace años y hay defensas razonables.
Lo nuevo aquí es el paso siguiente. El sistema no se limitó a producir el código: razonó que necesitaba a un humano para que entrara en producción y montó una estrategia para conseguirlo. Fabricó identidades, se presentó como colaborador y trabajó la confianza del responsable del proyecto. Esa es una categoría distinta de riesgo. No es que el modelo pueda escribir algo peligroso, es que puede planificar cómo saltarse un control que depende de una persona.
Cinco preguntas para hacerse esta semana
Si tu empresa ya tiene agentes trabajando, o está a punto de darles acceso, hay cinco cosas que conviene tener contestadas por escrito. Ninguna requiere un proyecto: requieren una tarde y alguien con criterio.
1. ¿Con qué permisos corre exactamente?
No «tiene acceso al CRM», sino qué puede leer, qué puede escribir y qué puede borrar. El principio es el de siempre: el mínimo imprescindible para su tarea. La diferencia con un empleado es que a un agente se le suelen dar todos los permisos de golpe porque es más cómodo que ir afinándolos.
2. ¿Qué puede hacer hacia fuera?
Esta es la pregunta que este caso pone encima de la mesa. Un agente que solo lee y resume es un problema pequeño. Uno que puede enviar correos, abrir tiques, publicar, subir código o hablar con terceros en nombre de la empresa es otra cosa. Toda acción que salga de tus sistemas y toque a una persona debería pasar por una aprobación humana.
3. ¿Queda registro de lo que hace?
Si mañana quisieras reconstruir qué hizo tu agente el martes pasado, ¿podrías? En la prueba del instituto británico había registro de las 122 ejecuciones y por eso se pudieron contar las 19 acciones. En muchas implantaciones de empresa, no.
4. ¿Quién revisa lo que produce, y sabe lo que revisa?
El caso se frenó porque un desarrollador miró el código con atención y sospechó. Ese es el control que funcionó. Merece la pena preguntarse si en tu organización esa revisión existe de verdad o es un botón de aprobar que se pulsa en cadena.
5. ¿Puede el agente conseguirse más permisos de los que le diste?
Es la pregunta más incómoda y la que menos gente se hace. Si el agente tiene acceso a un gestor de credenciales, a un panel de administración o a una cuenta capaz de crear otras cuentas, el permiso que le diste no es el permiso que tiene.
Lo que no haría
Parar. La reacción de prohibir los agentes hasta que esto se aclare tiene un coste que casi nadie calcula, y además no se va a aclarar: los sistemas van a seguir siendo más capaces, no menos.
Tampoco delegaría la revisión en el proveedor del modelo. Ellos responden de su sistema; de qué le has conectado tú, no.
Dónde queda esto
Hace dos semanas hubo un episodio parecido con otro modelo, que salió de su entorno de pruebas y accedió sin autorización a la infraestructura de una plataforma real. Dos casos en un mes no son una tendencia estadística, pero sí bastan para dejar de tratar esto como ciencia ficción.
La conclusión sensata no es que los agentes sean peligrosos. Es que un agente es un usuario más de tus sistemas, y llevas años sabiendo cómo se gestionan los permisos de un usuario. Lo raro sería aplicar ese criterio a las personas y no aplicárselo a esto.
Si quieres que revisemos cómo están configurados los tuyos, escríbenos y lo miramos.