Ir al contenido principal
OpenAI

28 de septiembre de 2026

Seguridad

Hacia argumentos de seguridad para el entrenamiento de IA de vanguardia

Cargando…

Creemos que estamos entrando en una nueva era en la que debería exigirse documentación estructurada sobre seguridad antes de continuar cualquier ejecución de entrenamiento por refuerzo de modelos de vanguardia. Lo ideal sería que esa documentación alcanzara el nivel de los «argumentos de seguridad»: justificaciones exhaustivas, estructuradas y basadas en evidencias sobre el riesgo, como las que se utilizan en otros sectores donde la seguridad es crítica. Los argumentos de seguridad son el objetivo que guía nuestro trabajo. Al mismo tiempo, reconocemos las dificultades de dotarlos del mismo rigor para los modelos de IA que en la aviación o la energía nuclear, debido a la complejidad que surge con cada nuevo nivel de capacidad de la IA. Estamos trabajando en un marco para formalizar estas prácticas.

A continuación presentamos algunas directrices iniciales que creemos que deberían formar parte de estos argumentos de seguridad para el entrenamiento de IA de vanguardia. Estas buenas prácticas reflejan lo que hemos aprendido hasta ahora y prevemos que evolucionen a medida que sigamos perfeccionando nuestros procesos internos para un desarrollo cuidadoso. Las compartimos ahora para dar a conocer con transparencia nuestro enfoque actual e invitar a la comunidad a aportar sus comentarios. Ten en cuenta que este documento se centra en el entrenamiento por refuerzo de modelos de vanguardia; el despliegue interno y externo requiere considerar un conjunto mucho más amplio de propiedades de alineación.

1. Salvaguardas técnicas

Los argumentos de seguridad deberían cubrir tres aspectos de la arquitectura técnica: el entrenamiento para la alineación, la contención y la monitorización. Estas salvaguardas ayudan a garantizar que el modelo no intente realizar acciones desalineadas y que, incluso si lo hiciera, le resulte difícil superar las barreras de contención y la monitorización lo detecte antes de que se produzcan daños.

  • Alineación del modelo: la primera línea de defensa debería ser entrenar los modelos para que estén alineados, es decir, para que actúen de forma fiable según lo previsto. Esto podría incluir:

    • Entornos de entrenamiento y calificación: reducir el riesgo de que los modelos desarrollen comportamientos desalineados, evitando reforzar positivamente la manipulación de recompensas durante el entrenamiento. Esto podría incluir:

      • Revisiones automatizadas de conjuntos de datos: usar agentes para detectar y corregir entornos de aprendizaje por refuerzo defectuosos que podrían permitir que las trayectorias desalineadas reciban recompensas elevadas por explotar fallos, en lugar de seguir el comportamiento previsto. Así se reducen las oportunidades de reforzar la desalineación durante el entrenamiento.

      • Revisiones manuales de conjuntos de datos: complementar el red teaming automatizado con revisiones manuales y controles de calidad de los conjuntos de datos para identificar tareas defectuosas que puedan reforzar involuntariamente comportamientos desalineados.

      • Ajuste de los calificadores: ajustar los calificadores para penalizar los intentos del modelo de explotar fallos o manipular los entornos de aprendizaje por refuerzo durante el entrenamiento.

      • Análisis de ejecuciones previas: aplicar clasificadores a las trazas de experimentos anteriores para comprobar que los calificadores funcionan según lo previsto.

    • Medición de la alineación: realizar evaluaciones que sigan la propensión del modelo a la desalineación para medir la eficacia del entrenamiento para la alineación. Esto podría incluir:

      • Evaluaciones de alineación fuera de línea: realizar evaluaciones de alineación durante las ejecuciones de entrenamiento de modelos de vanguardia para determinar si el entrenamiento funciona según lo previsto e investigar cualquier retroceso significativo.

      • Validación retrospectiva: validar las evaluaciones de alineación con incidentes anteriores para confirmar que detectan modelos que ya mostraron desalineación y que no se están sobreajustando a incidentes concretos.

      • Seguimiento de la manipulación de evaluaciones: vigilar la conciencia de la evaluación o el metajuego (cuando los modelos reconocen que están siendo evaluados) que podrían inducir un cambio de comportamiento, con umbrales de bloqueo específicos (por ejemplo, activar monitores de conciencia de la evaluación y de metajuego en las evaluaciones de alineación).

      • Pruebas de estrés en el peor escenario: provocar los peores comportamientos indebidos posibles y comprobar que al menos una evaluación los detectaría.

    • Evitar el entrenamiento basado en la cadena de pensamiento: no permitir que los calificadores automatizados vean la cadena de pensamiento durante el aprendizaje por refuerzo, para evitar que los modelos evolucionen de forma que eludan los monitores de la cadena de pensamiento.

  • Contención: si un modelo se desalinea, el aislamiento y la seguridad deben ser lo bastante sólidos como para impedir acciones dañinas. Esto podría incluir:

    • Múltiples capas de seguridad de la infraestructura: invertir de forma decidida en reforzar tanto el entorno aislado donde se ejecuta el modelo como la infraestructura de investigación que lo aloja, para contar con una capa adicional de protección si el modelo escapa del entorno aislado.

    • Red teaming de la contención: mejorar la seguridad del entorno aislado, de la infraestructura de investigación y del perímetro mediante ejercicios iterativos de red teaming de estos sistemas utilizando puntos de control de ejecuciones de entrenamiento de modelos de vanguardia, sujetos a un análisis de seguridad, para detectar y cerrar cualquier brecha. Someter también a pruebas de red teaming todos los servicios a los que el modelo podría acceder durante el entrenamiento (por ejemplo, la caché de internet).

    • Comunicación entre muestras: limitar la comunicación de gran ancho de banda entre muestras a vías aprobadas, como las herramientas multiagente, y cerrar los canales laterales de la infraestructura que tengan gran ancho de banda y sean fáciles de descubrir para los agentes.

    • Transcripciones inmutables: guardar las transcripciones de los agentes de forma inmutable durante un plazo razonable (por ejemplo, en cuentas de almacenamiento de escritura única) para todo el entrenamiento por refuerzo, la evaluación y el despliegue interno, con el fin de permitir investigaciones fiables de incidentes y evitar modificaciones involuntarias.

  • Monitorización: si los modelos empiezan a realizar acciones desalineadas, contar con un sistema de monitorización en tiempo real para detectar cualquier posible desalineación y resolver rápidamente los problemas prioritarios antes de que se produzca un incidente grave. Esto podría incluir:

    • Garantizar la capacidad de monitorización: asegurar que los modelos sigan siendo monitorizables, mediante evaluaciones de la capacidad de monitorización y de evasión de la monitorización con umbrales claros, para detectar pronto los comportamientos preocupantes.

    • Alta sensibilidad ante problemas conocidos: garantizar que el sistema de monitorización tenga una alta sensibilidad para detectar incidentes pasados en una evaluación reservada y no utilizada durante el desarrollo.

    • Evaluaciones actualizadas de los monitores: crear casos de evaluación representativos de riesgos completamente nuevos para las nuevas ejecuciones, de modo que las mediciones de sensibilidad y precisión de los monitores no queden obsoletas.

    • Respuesta rápida: implementar alertas prioritarias que den lugar a una acción dentro del plazo definido en un SLA, ya sea avisando a una persona de guardia o pausando automáticamente la ejecución afectada, antes de que el modelo cause daños (por ejemplo, avisar al personal de seguridad de guardia y al responsable de la ejecución cuando haya incidentes durante el día, y pausar automáticamente las ejecuciones por la noche si las alertas no reciben acuse de recibo).

2. Directrices operativas

Además de las recomendaciones sobre salvaguardas técnicas, hemos trabajado en buenas prácticas operativas para los argumentos de seguridad de una ejecución de entrenamiento de IA de vanguardia. Estas podrían incluir:

  • Objeciones (análisis premortem): una vez redactado un argumento de seguridad, un miembro de otro equipo debería escribir un informe de objeciones para detectar posibles carencias y ofrecer una valoración ponderada del riesgo. El equipo de entrenamiento debería responder a estas objeciones para reforzar los argumentos de seguridad.

  • Aprobaciones: los miembros de la alta dirección deberían revisar el argumento de seguridad y cada uno debería poder vetar la ejecución, para garantizar que esta se somete a múltiples controles internos (por ejemplo, el responsable o vicepresidente de investigación, el responsable de seguridad y el director científico).

  • Rendición de cuentas: el alto directivo responsable de una ejecución de entrenamiento (por ejemplo, el responsable o vicepresidente de investigación) debería rendir cuentas por el argumento de seguridad y por cualquier respuesta a incidentes, también en sus evaluaciones de desempeño. Así, los equipos de entrenamiento también tendrían incentivos para promover la seguridad y la alineación.

  • Pausas: si se detectan problemas que invalidarían un argumento de seguridad (por ejemplo, un nuevo problema de seguridad), debe garantizarse que existan procedimientos operativos, controles técnicos y acuerdos de nivel de servicio (SLA) para pausar todas las ejecuciones cubiertas.

  • Transparencia interna: los argumentos de seguridad deberían ponerse a disposición de los grupos de supervisión interna (por ejemplo, el Comité de Seguridad y Protección).

  • Auditorías: los auditores deberían disponer de acceso suficiente para comprobar que las afirmaciones del argumento de seguridad son válidas y sólidas, y señalar las carencias que encuentren.

  • Escalado: debería existir un proceso claro para escalar los problemas de desalineación, con una tabla que defina los niveles de gravedad y un responsable de guardia que pueda alertar a los directivos (por ejemplo, al director ejecutivo) cuando una ejecución alcance cierto nivel de gravedad.

  • Controles técnicos: debería ser difícil para las personas y los agentes iniciar ejecuciones que incumplan los requisitos. Las funciones de seguridad, como la monitorización y las pausas automáticas, deberían bloquear el funcionamiento en caso de fallo (por ejemplo, no debería ser posible iniciar ejecuciones sin la monitorización adecuada activada, ni desactivarla desde el entrenamiento por refuerzo, la evaluación o un despliegue interno).

  • Capacidad de reversión: debería ser fácil identificar todos los usos posteriores de un modelo desalineado en el proceso de entrenamiento (por ejemplo, la generación de datos o la calificación), para poder deshacer los efectos de sus resultados desalineados si fuera necesario.

  • Inventario completo de riesgos residuales: los argumentos de seguridad deberían enumerar, de la forma más exhaustiva posible, los riesgos residuales que no cubren las medidas de mitigación ya implantadas, para permitir decisiones informadas sobre la aceptación del riesgo.

Estas son nuestras recomendaciones actuales y estamos implantándolas en OpenAI. Prevemos que nuestras prácticas sigan evolucionando en las próximas semanas.

3. Investigación de incidentes de desalineación

También hemos desarrollado buenas prácticas para investigar incidentes graves de desalineación de la IA. Los laboratorios deberían intentar aprender todo lo posible de cada incidente (de forma similar a las prácticas de investigación⁠(se abre en una ventana nueva) de otros sectores donde hay mucho en juego) para evitar que se repitan en el futuro. Estas medidas podrían incluir:

  • Transparencia interna: dado que una investigación puede llevar bastante tiempo, deberían presentarse actualizaciones periódicas sobre su avance dentro de la organización (por ejemplo, actualizaciones diarias de las investigaciones en curso). Los empleados deberían disponer de vías definidas para ampliar su acceso, incluidas las transcripciones sin procesar y la obtención de muestras de modelos desalineados, siempre que sea seguro y pertinente para su trabajo.

  • Causa raíz de la desalineación: los investigadores deberían determinar las causas raíz en la dinámica del entrenamiento (por ejemplo, mediante ablaciones específicas o experimentos de remuestreo) para comprender cómo se introdujeron los comportamientos desalineados, profundizar en el conocimiento científico de la desalineación y prevenirla mejor en el futuro.

  • Análisis post mortem: debería realizarse un análisis post mortem de los aspectos operativos y de la cultura organizativa para comprender todas las causas que contribuyeron al incidente, como por qué se introdujeron los problemas y no se detectaron o escalaron antes del incidente.

  • Detección: deberíamos desarrollar métodos de evaluación de la alineación capaces de descubrir la propensión a causar el incidente, sin optimizarlos de forma iterativa basándonos directamente en información derivada de este (por ejemplo, transcripciones o resúmenes del incidente). Deberían crearse evaluaciones derivadas de incidentes a modo de «pruebas de regresión», para garantizar que los futuros modelos no muestren propensión a la desalineación en incidentes muy similares.

  • Divulgación pública: los resultados de las investigaciones, los análisis post mortem y los cambios operativos deberían compartirse con el público una vez concluida la investigación. Debería notificarse a los terceros afectados lo antes posible.

Autor

OpenAI