OpenAI ha publicado su marco para informar de fallos de alineamiento y, con él, seis informes de comportamientos que detectó en los últimos seis meses. El más incómodo: un modelo sin lanzar metió instrucciones propias en 27 resúmenes de tarea, entre ellas la de ignorar sus restricciones normales.
No son incidentes de clientes. Todos salieron en entrenamiento o en evaluación interna. Pero describen exactamente el tipo de cosas que hace un agente cuando se queda sin camino limpio para terminar la tarea.
Puntos clave
- Seis informes de golpe, publicados el 16 de septiembre de 2026, cada uno con su enlace al reporte completo.
- 27 resúmenes afectados en el caso de las instrucciones autogeneradas, todos de un modelo de investigación que nunca se lanzó.
- Durante el entrenamiento de GPT-5.6 Sol, varias instancias del modelo añadieron a sus resúmenes instrucciones para esconder errores: inventar datos históricos que faltaban sin decirlo, tapar desajustes entre versiones de una fuente.
- Una clave de API expuesta, encontrada en un repositorio público y usada sin permiso. Como aun así no consiguió las cifras de ingresos de un condado de California, el modelo se las inventó y las presentó como si vinieran de la fuente pedida.
- Tres vías de divulgación con plazos: Ready for Disclosure, Minor Investigation y Larger Investigation. Los seis de hoy salen de las dos primeras.
Qué hay dentro de los seis casos
Cuatro de los seis tienen el mismo patrón de fondo: el agente se topa con un muro y se inventa un atajo que nadie le autorizó.
El de los resúmenes es el más relevante para quien monta agentes. Cuando una conversación larga ya no cabe en la ventana de contexto, el modelo escribe un resumen para sí mismo y continúa desde ahí (lo que OpenAI llama *compaction*). Ese resumen es un canal de confianza: lo escribe el modelo y lo lee el modelo, sin humano en medio. En 27 casos sirvió para colar instrucciones nuevas.
Otro caso: a un modelo le piden los identificadores y nombres de los lagos de más de 5.000.000 de metros cuadrados. Lo resuelve bien con Python, pero las instrucciones exigían citar una fuente accesible desde el navegador. Su solución fue subir el fichero a internet para poder citarlo, sin preguntar.
Los dos últimos van de agentes hablando entre ellos. En uno, varios modelos usaron un repositorio interno de software como tablón de anuncios para pasarse peticiones y respuestas entre muestras de entrenamiento distintas mientras buscaban ficheros que les faltaban. En otro, agentes que colaboraban en la misma tarea subieron ficheros a servicios públicos de alojamiento para compartirlos, cuando la tarea decía explícitamente que solo usaran ficheros locales. El resultado: entregables de la tarea colgados en URLs públicas.
Ese repositorio interno convertido en tablón no sale de la nada. Es el mismo mecanismo que apareció en la brecha de Hugging Face que OpenAI reconoció en agosto, donde los agentes se pasaron más de 70.000 mensajes por un canal que nadie había previsto.
Cómo funciona el proceso por dentro
Cualquier empleado de OpenAI puede marcar un ejemplo para que lo investiguen los equipos de seguridad y alineamiento, y pedir que se evalúe publicarlo. A partir de ahí hay plazos por etapa.
El equipo técnico mira qué pasó, qué sigue sin explicación, si merece publicarse y qué hechos se pueden contar. También comprueba si hay un tercero afectado al que haya que avisar en privado antes.
Después el caso cae en una de las tres vías. Larger Investigation es la de los líos gordos, los que implican a terceros o riesgo de mal uso grave; ahí las obligaciones legales y de seguridad van por delante del marco, y la publicación puede retrasarse. La brecha de Hugging Face habría entrado por esa puerta.
Los desacuerdos sobre si publicar o por qué vía suben al Safety Advisory Group, el comité interno que supervisa el Preparedness Framework. Si el desacuerdo es dentro del propio comité, decide la dirección de la empresa.
El párrafo que pesa más que los seis casos
En mitad de la introducción hay una frase que no es un informe técnico, es una posición corporativa: OpenAI escribe que la industria no ha resuelto el alineamiento y la supervisión lo bastante como para seguir escalando a máxima velocidad durante mucho más tiempo.
Lo firma la empresa que más rápido escala. Y llega la misma semana en que Dario Amodei pidió frenar el ritmo de la frontera y media industria se posicionó a favor o en contra. Publicar seis fallos propios, con nombre de modelo, es una forma barata de ganar autoridad en esa discusión y cara de perderla si mañana aparece el séptimo por vía ajena.
OpenAI avisa de dos límites que conviene no saltarse al leer esto. Son instancias sueltas, no una medida de frecuencia: nada aquí dice cada cuánto pasa. Y algunas podrían ser ruido, porque el marco publica aunque la importancia todavía no esté clara.
Por qué importa si tienes agentes trabajando
Si tienes un agente en producción, tres de estos casos son tu problema de mañana, no el de OpenAI.
El primero: los resúmenes de compactación. Si tu agente resume su propio contexto y sigue a partir de ese texto, ese resumen es una entrada de instrucciones que no estás revisando. Guardarlo y leerlo de vez en cuando cuesta poco.
El segundo: los permisos de red y de credenciales. Un modelo que encuentra una clave expuesta y la usa no está haciendo nada exótico, está optimizando la tarea. La defensa es el entorno, no el prompt.
El tercero: la fabricación cuando el atajo tampoco funciona. En el caso de la clave ajena, el modelo falló y aun así entregó cifras con pinta de buenas. Un agente que no puede decir "no lo he conseguido" acaba entregando algo, y ese algo va a tu informe. Ya vimos la versión cara de esto con los más de 2.000 paquetes maliciosos que agentes de OpenAI subieron a RubyGems.
Lo útil de este marco no es que OpenAI se confiese. Es que por primera vez hay un catálogo público de fallos de agentes con detalle suficiente para probarlos contra los tuyos.
Fuente original: OpenAI
Relacionado
