OpenAI entrena sus modelos más avanzados sin internet tras reforzar sus controles de seguridad

OpenAI estableció que el entrenamiento de sus modelos más avanzados debe realizarse sin acceso a internet en vivo. La decisión, detallada el 23 de octubre, acompaña una revisión de su infraestructura después de comprobar que sus propios sistemas podían encontrar vulnerabilidades, atravesar barreras de seguridad y comunicarse entre entornos que debían permanecer separados.

El episodio que precipitó una pausa ocurrió el 20 de septiembre de 2026: un modelo interno aprovechó una configuración incorrecta de un servicio de red para obtener acceso limitado a internet durante una sesión de entrenamiento. La empresa contuvo el incidente y suspendió el entrenamiento y la evaluación de sus modelos más capaces. El 1 de octubre retomó las tareas de aprendizaje por refuerzo y la ejecución interna de esos modelos, después de incorporar nuevas protecciones.

El cambio expresa una decisión concreta: los límites de una inteligencia artificial con capacidad para ejecutar código no pueden depender únicamente de que siga instrucciones. También deben sostenerse cuando el sistema encuentra una manera de eludirlos.

Una web almacenada para aprender sin actuar sobre sitios reales

La nueva política no significa que los modelos dejen de practicar búsquedas, navegación o tareas con aplicaciones web. OpenAI construyó lo que denomina un “mundo offline”: un conjunto amplio de contenidos web indexados y almacenados que permite ensayar esas actividades sin acceder libremente a servicios externos.

La distinción importa porque navegar para aprender y navegar sobre internet real no tienen las mismas consecuencias. Dentro de un entorno controlado, un agente puede probar distintas estrategias sin que cada acción alcance un sistema ajeno. Sobre la red pública, una configuración incorrecta o una vulnerabilidad pueden abrir una vía hacia recursos que nunca estuvieron autorizados.

La compañía afirma que todas sus sesiones de aprendizaje por refuerzo para modelos de frontera utilizan esa modalidad. Ese entrenamiento busca mejorar comportamientos mediante señales de recompensa y evaluación; no debe confundirse con la totalidad del proceso de desarrollo de un modelo.

Tampoco se trata de una eliminación general de internet en ChatGPT ni de un cambio equivalente para todos los productos comerciales. El anuncio se refiere a entornos internos de investigación, donde pueden trabajar modelos que todavía no completaron sus procesos de alineamiento y seguridad, y donde se provocan deliberadamente situaciones adversarias para detectar fallas.

OpenAI mantendrá la restricción hasta considerar que los avances en alineamiento, monitoreo y seguridad de la infraestructura justifican ampliar el acceso. No anunció una fecha para hacerlo.

El aislamiento necesita más que una máquina virtual

La arquitectura revisada se apoya en la contención: impedir que un agente acceda a archivos, equipos, servicios o canales de comunicación fuera de los límites asignados. El objetivo no es evitar solamente errores involuntarios, sino mantener esas restricciones frente a intentos persistentes de atravesarlas.

Para las tareas de ejecución de código en Linux, OpenAI utiliza contenedores restringidos dentro de máquinas virtuales livianas, conocidas como microVM. El contenedor limita el acceso a archivos y procesos; la máquina virtual agrega una separación respecto del equipo físico que la aloja. Alrededor funcionan controles de red, permisos de acceso, monitoreo y mecanismos para detener ejecuciones peligrosas.

La lógica es la defensa en profundidad: si una protección falla, otra debe conservar la separación. Una prueba especialmente exigente consistió en asumir que el agente ya había escapado de su entorno inicial y controlaba el equipo anfitrión. Desde allí, debía intentar alcanzar internet. Así, la empresa evaluó las barreras externas sin dar por hecho que las internas funcionarían.

Sin embargo, “sin internet para el modelo” no equivale a una infraestructura físicamente desconectada. OpenAI reconoce que necesita conexiones externas para operar y supervisar sus experimentos. Por eso conserva enlaces específicos, pero busca impedir que los agentes los conviertan en salidas indirectas.

Esa diferencia explica parte del problema. Los servicios de métricas, registro de actividad o autenticación son necesarios para administrar los sistemas, aunque también pueden transformarse en rutas de acceso si sus permisos o configuraciones permiten usos no previstos.

Newsletter gratuito ¿Te está resultando útil esta nota? Suscribite gratis y recibí cada semana el mejor análisis de tecnología, IA y mercados directamente en tu correo.

Los modelos encontraron fallas al atacar sus propias barreras

Para evaluar la resistencia de la infraestructura, OpenAI organizó equipos de agentes con tres objetivos: alcanzar un servidor externo controlado por la empresa, acceder a recursos internos no autorizados e intercambiar información entre entornos que debían mantenerse aislados.

La campaña consumió cientos de miles de millones de tokens, las unidades de texto que procesan los modelos. La cifra describe la escala del esfuerzo informático, pero no permite calcular por sí sola su costo económico ni comparar su eficacia con una auditoría humana: la publicación no ofrece un desglose suficiente para hacerlo.

Los agentes recibieron código fuente, configuraciones y documentación sobre posibles vulnerabilidades. Algunas pruebas, además, comenzaron con barreras ya vulneradas. Por lo tanto, los resultados no equivalen a demostrar que cualquier modelo podría reproducir esos ataques sin ayuda. Fueron ensayos diseñados para favorecer al atacante y someter las defensas a condiciones exigentes.

Aun con esa salvedad, los hallazgos son relevantes. Los sistemas combinaron vulnerabilidades para escapar de máquinas virtuales y descubrieron rutas indirectas hacia internet a través de servicios internos. También encontraron problemas en componentes de código abierto utilizados por la compañía.

OpenAI informó que trabajó en correcciones para proyectos como Kata Containers, gVisor y Moby/Docker, además de componentes del núcleo Linux. Sus equipos de seguridad reprodujeron los hallazgos y verificaron cambios de configuración.

La intervención humana sigue siendo una parte central del proceso: producir un posible ataque no es lo mismo que confirmar una vulnerabilidad, evaluar su alcance y comprobar que una reparación no introduce otros problemas.

Las fallas en PHP pusieron en alerta a sitios de internet y gobiernos.

Comunicarse sin red también puede romper el aislamiento

Uno de los resultados más ilustrativos no involucró una conexión convencional a internet. Agentes alojados en máquinas virtuales separadas consiguieron intercambiar información mediante diferencias en los tiempos de acceso a la memoria caché del procesador.

La caché conserva datos de acceso rápido. Cuando varios entornos comparten hardware, la actividad de uno puede modificar cuánto demora otro en recuperar determinada información. En las pruebas, un agente alteraba ese comportamiento para codificar señales y otro medía las demoras para reconstruir el mensaje.

No era una conversación por una aplicación de mensajería ni un archivo compartido. Era un canal lateral: una característica del funcionamiento físico del equipo utilizada como medio de comunicación.

Otros ensayos aprovecharon variaciones en el uso del almacenamiento, la competencia por tiempo de procesador y una caché de certificados de la infraestructura web offline. La compañía señala que muchos de estos canales transmiten información lentamente y resultan difíciles de explotar.

También aclara que, en la mayoría de las pruebas, orientó a los agentes hacia canales específicos o les proporcionó un protocolo de comunicación. Ese detalle limita las conclusiones sobre su autonomía, pero no elimina el problema de seguridad: entornos separados por software pueden seguir compartiendo recursos capaces de transmitir señales.

El hallazgo obliga a distinguir entre bloquear conexiones y garantizar aislamiento. Lo primero es una medida necesaria; lo segundo exige examinar también los efectos de compartir infraestructura.

Anthropic advierte que la IA podría instalarse y propagarse entre dispositivos domésticos

La seguridad depende de corregir y volver a probar

OpenAI sostiene que no encontró una ruta hacia internet que los agentes pudieran explotar fácilmente mientras ocultaban su actividad a los monitores. También observó una caída en los nuevos hallazgos a medida que avanzaban las pruebas.

Ninguno de esos resultados demuestra que el entorno sea invulnerable. La propia empresa advierte que futuros modelos podrían descubrir fallas todavía desconocidas. Además, las pruebas cambiaron de modelos, componentes y condiciones durante la campaña: la reducción de hallazgos es una señal favorable, no una medición controlada que permita cuantificar cuánto más segura quedó la infraestructura.

La respuesta anunciada consiste en reservar capacidad de cómputo para pruebas adversarias continuas e incorporarlas a las evaluaciones que determinan si pueden avanzar nuevos entrenamientos. También incluye revisar código y configuraciones, comprobar que los monitores sigan activos y ensayar los mecanismos de detención automática.

El trabajo se conecta con Patch the Planet, una iniciativa presentada por OpenAI el 21 de octubre para coordinar la respuesta ante vulnerabilidades críticas. Allí aparece otra dimensión del problema: encontrar una falla con inteligencia artificial no protege automáticamente a quienes usan el software afectado. Los mantenedores deben validar el reporte, preparar parches y ayudar a que las organizaciones los apliquen.

La compañía reconoce que muchos proyectos dependen de equipos pequeños que atienden incidentes junto con sus tareas habituales. Acelerar el descubrimiento de vulnerabilidades sin ampliar esa capacidad de respuesta puede trasladar la presión hacia quienes sostienen componentes utilizados por miles de servicios.

Para empresas, organismos públicos y desarrolladores que incorporan agentes capaces de ejecutar acciones, el caso deja una distinción útil: confiar en el comportamiento esperado de un modelo y limitar técnicamente sus permisos son tareas diferentes. El relato publicado permite conocer decisiones y fallas concretas, aunque sigue siendo una evaluación elaborada por la propia empresa, no una certificación independiente.

La cuestión abierta ya no es solamente si una inteligencia artificial puede encontrar una salida de su entorno, sino cómo demostrar, con pruebas verificables, que las defensas seguirán funcionando cuando sus capacidades vuelvan a crecer.