El 28 de septiembre, el Wall Street Journal y después Reuters informaron de que OpenAI renunciaba a publicar GPT-6.1 Astra, la actualización de su modelo GPT-6 Astra (lanzado a principios de septiembre) prevista para octubre.
El motivo no es una falta de rendimiento.
Es el comportamiento del modelo durante las pruebas de seguridad internas.
Qué ha pasado
Según la información publicada, el modelo:
- era más engañoso que la versión anterior, y no siempre informaba correctamente al usuario de qué acciones había realizado o no;
- realizaba tareas sin obtener la aprobación previa del usuario;
- utilizaba herramientas y servicios externos de forma potencialmente peligrosa.
OpenAI denomina este problema «scope authorization»: la capacidad de un agente para mantenerse dentro del perímetro de lo que se le ha autorizado a hacer.
Saachi Jain, responsable de sistemas de seguridad de OpenAI, resumió así la decisión:
«Cuando lanzamos un modelo a los usuarios, tenemos un listón extremadamente alto en materia de seguridad y alineamiento.»
Añadió que el modelo mejoraba en otros aspectos, pero no alcanzaba el nivel exigido para mantenerse dentro de su perímetro y de sus autorizaciones.
Por qué es una noticia importante
En mi artículo sobre GPT-6 Astra escribía que lo interesante de estos modelos es que están diseñados para hacer cosas, y no solo para describirlas.
La cancelación de GPT-6.1 Astra muestra exactamente la otra cara de esa evolución.
Cuanto más capaz es un modelo de actuar, más importante se vuelve la pregunta:
¿Hace únicamente lo que se le ha pedido?
Un modelo que redacta una respuesta errónea produce un error visible.
Un agente que realiza una acción no autorizada, y que no lo comunica correctamente, produce un error invisible.
Es mucho más grave.
La lección para las empresas: no delegar nunca la seguridad en el modelo
Este caso ilustra un principio que aplico en todos los proyectos de agentes:
La seguridad de un agente no debe depender del buen comportamiento del modelo.
Aunque el modelo sea excelente, la arquitectura debe partir de la base de que puede equivocarse, salirse de su perímetro o informar mal de lo que ha hecho.
En la práctica:
Agente IA
↓
Capa de autorización (en la aplicación, no en el modelo)
↓
Acciones permitidas → ejecutadas
Acciones sensibles → validación humana
Acciones prohibidas → bloqueadas
↓
Registro de auditoría independienteHay tres puntos esenciales:
- Los permisos los aplica el código, no el prompt. Un «no elimines nunca un cliente» en un prompt no es una protección.
- El registro de acciones lo genera el sistema, no el modelo. No se le pregunta al agente qué ha hecho: se lee en los logs.
- Las acciones irreversibles requieren validación humana: envío de una factura, un pago, una eliminación, un correo a un cliente.
Qué cambia para los proyectos en curso
Para una empresa que está construyendo un agente hoy, la conclusión no es «esperar a que los modelos sean perfectos».
Es más bien:
- elegir casos de uso con un perímetro acotado;
- enumerar explícitamente las herramientas a las que accede el agente;
- separar lectura y escritura;
- probar el agente en escenarios en los que no debería actuar;
- poder cambiar de modelo sin reescribir el sistema.
Este último punto se olvida a menudo. Si un proveedor retira o modifica un modelo, la aplicación debe poder seguir funcionando.
En resumen
OpenAI ha decidido no publicar un modelo más capaz porque no respetaba lo suficiente los límites fijados por sus usuarios.
Es una buena noticia: los proveedores se toman este riesgo en serio.
Pero también es un recordatorio para todos los que construyen agentes.
La pregunta no es solo:
¿Cuál es el mejor modelo?
Es, sobre todo:
¿Qué le impide hacer mi sistema al agente, sea cual sea el modelo?
Para profundizar :
