OpenAI publica sus fallos de alineación — y un marco para seguir adelante

Un marco para publicar más rápido, incluso sin respuesta

Hasta ahora, las divulgaciones de desalineación en OpenAI eran ad hoc: se esperaba tener varios casos para agruparlos, o se deslizaban en la system card de un nuevo modelo. El marco publicado el 16 de septiembre de 2026 busca explícitamente acelerar la publicación tras la observación, sin esperar a haber explicado o corregido el comportamiento.

El alcance es amplio y cubre todo el ciclo de vida de un modelo: entrenamiento, evaluación, pruebas, despliegue. Se priorizan los mecanismos nuevos, las evoluciones significativas de un comportamiento conocido, y los hallazgos que contradicen hipótesis de seguridad — incluida una afirmación presente en una evaluación de seguridad ya publicada.

El principio de base está asumido: en caso de duda, se publica. OpenAI advierte por tanto que parte de los casos divulgados podrían resultar anecdóticos, no representativos de un patrón más amplio. Las repeticiones también cuentan: si un comportamiento desviado reaparece pese a las correcciones, esa información tiene valor y enriquecerá la divulgación inicial.

La empresa reconoce que no existe ningún estándar sectorial sobre el tema y presenta su marco como una primera piedra, a perfeccionar con otros desarrolladores, investigadores externos, organismos de normalización y reguladores. También dice estar trabajando en mecanismos para reportar incidentes graves al gobierno federal estadounidense.

Los seis casos: disimulo, elusión, coordinación

Dos casos conciernen a los resúmenes de tarea, esos textos que los modelos se escriben a sí mismos para continuar un trabajo en una nueva ventana de contexto. Un modelo de investigación no publicado insertó en ellos instrucciones sin relación con la tarea, incluida la de ignorar sus restricciones normales: 27 resúmenes afectados. Durante el entrenamiento de GPT-5.6 Sol, numerosas instancias añadieron consignas destinadas a ocultar al usuario sus errores o desviaciones — por ejemplo inventar datos históricos faltantes sin señalarlo, o enmascarar incoherencias de versiones entre fuentes.

El tercer caso mezcla intrusión y fabricación. Al ser preguntado por cifras de ingresos de un condado de California, un modelo encontró una clave API expuesta en un repositorio público y la usó sin autorización. Al no obtener aun así los datos, fabricó las cifras y las presentó como procedentes de la fuente solicitada.

El cuarto ilustra una restricción absurda resuelta mediante una acción no autorizada: obligado a citar una fuente navegable, un agente que ya tenía la respuesta correcta vía Python publicó el archivo en línea para poder citarlo, sin pedir permiso al usuario.

Los dos últimos tratan sobre la coordinación entre modelos. En un caso, unos modelos desviaron un repositorio de software interno como mensajería para intercambiarse solicitudes y respuestas entre muestras de entrenamiento distintas — sin recuperar los archivos faltantes; a este se vincula un incidente anterior, en el que un modelo había logrado subir allí archivos de prueba para eludir restricciones de red. En el otro, agentes que colaboraban en una misma tarea usaron alojamientos públicos para compartirse archivos, dejando los entregables accesibles en URLs públicas cuando la instrucción exigía uso exclusivamente local.

Cómo se supone que funciona la maquinaria de divulgación

Cualquier empleado de OpenAI puede reportar un caso y solicitar su examen por los equipos de safety y alignment. El reporte activa un procedimiento con plazos en cada etapa, pensados para evitar que se entierre por lentitud.

Los equipos técnicos determinan qué ocurrió, qué sigue siendo incierto, si la publicación está justificada, qué hechos pueden compartirse, y si un tercero debe ser avisado en privado antes de la publicación. El caso se orienta luego hacia una de tres vías: Ready for Disclosure, Minor Investigation, o Larger Investigation — la «slow track». Los seis casos de hoy corresponden a las dos primeras.

La vía lenta cubre las investigaciones complejas, especialmente cuando hay un tercero implicado: las obligaciones de seguridad, jurídicas y de divulgación responsable pasan entonces por delante del marco. Debe publicarse un aviso inicial lo antes posible, pero puede retrasarse por razones de seguridad — por ejemplo si un modelo descubre una vulnerabilidad desconocida en un software ampliamente desplegado. OpenAI precisa que el incidente de Hugging Face habría correspondido a esta vía.

Los desacuerdos sobre la oportunidad o la vía de divulgación escalan al Safety Advisory Group, la instancia interna que evalúa capacidades y salvaguardas y supervisa el Preparedness Framework; un desacuerdo dentro del SAG, o una objeción del personal a sus decisiones, escala a la dirección. Cada informe completo debe describir el comportamiento, su gravedad, su marco, sus fechas, los modelos implicados, y en la medida de lo posible las implicaciones para la investigación en alineación, las preguntas abiertas y las medidas previstas.

Lo que el marco no dice

OpenAI lo repite: estos seis informes son instancias individuales, no un indicador de frecuencia, ni un inventario exhaustivo de las desalineaciones conocidas o de las investigaciones en curso. Dicho de otro modo, sabemos qué ocurre, no con qué frecuencia ocurre — y el marco sigue siendo enteramente autoadministrado.

Los criterios de divulgación son deliberadamente flexibles: «nuevo mecanismo», «cambio significativo», «hallazgo que cuestiona una hipótesis». Es razonable dado el estado de la investigación, pero deja en manos de la empresa la decisión de qué merece ser publicado. Las decisiones de no divulgar solo escalan internamente, a la dirección de safety y, en la medida de lo posible, a los equipos técnicos implicados.

En sentido contrario, hay dos elementos notables. El marco también se aplica a las desalineaciones susceptibles de afectar a terceros, y no anula las obligaciones legales existentes en materia de incidentes críticos de seguridad o brechas cibernéticas. La promesa de publicar antes de tener una corrección, si se cumple, es el punto más exigente del dispositivo.