Alignment Forum propone 4 pasos: la nueva generación de IA, solo después de verificar la actual

En el AI Alignment Forum ha aparecido un post breve pero revelador sobre cuál debería ser el estándar mínimo de ritmo en el desarrollo de IA si la industria acuerda, no una pausa total, sino solo una desaceleración. La tesis es una: un laboratorio no tiene derecho a entrenar la siguiente generación de modelos, la que suponga un salto en capacidades, mientras no haya resuelto todos los problemas de alineamiento significativos de la actual. El autor construye el proceso en cuatro etapas y lo presenta como un mínimo, no como una condición suficiente.

Lógica de la propuesta

La analogía procede de la aviación. No se puede lanzar un avión que vuela a Mach 3 mientras no se entienda por qué se estrella el aparato a Mach 2. Con cualquier otra tecnología peligrosa, nadie aceptaría el «encogerse de hombros y seguir adelante». En una nota al pie, el autor matiza: es posible que la causa de los accidentes a Mach 2 deje de ser un problema a Mach 3, pero darlo por hecho sería una locura.

Subraya además que la fórmula sirve tanto a los optimistas como a los pesimistas sobre el alineamiento «prosaico», es decir, el que se limita a perfeccionar los métodos actuales. Los primeros esperan que una desaceleración moderada baste para cerrar los problemas en cada generación. Los segundos prevén que el requisito conducirá a una pausa prolongada y dará tiempo para buscar enfoques radicalmente nuevos.

Las cuatro etapas del ciclo

• Auditoría durante el entrenamiento. Varias organizaciones independientes de alineamiento revisan y someten a red teaming el modelo recién entrenado sobre múltiples checkpoints, con acceso completo a los datos y con las mejores herramientas disponibles. Los problemas se toman en serio también cuando no existe una métrica y simplemente algo está «cualitativamente mal», y cuando no se puede demostrar de forma fiable que el modelo tenga una propiedad deseable. Los problemas tempranos no bloquean necesariamente el proceso, pero hace falta un argumento de seguridad convincente que explique por qué las fases finales del entrenamiento los eliminarán.
• Lanzamiento limitado. El modelo solo está disponible para un grupo de usuarios de confianza, con tareas que no afectan al entrenamiento ni a la monitorización. Las organizaciones vigilan la aparición de nuevos problemas.
• Despliegue amplio, interno o externo. Solo se permite tras un periodo significativo de lanzamiento limitado sin incidentes.
• Siguiente generación. El entrenamiento comienza únicamente después de una operación prolongada sin problemas significativos.

Si surge un problema grave en la segunda o la tercera etapa, el esquema es estricto: se retira el modelo, se analiza la causa raíz y se averigua por qué el problema no se detectó durante el entrenamiento. Después se busca la manera de tratar la enfermedad y no el síntoma, se entrena el siguiente modelo de la misma generación y se empieza de nuevo.

Un detalle importante de la nota al pie: los «resultados mejores que los de modelos anteriores» no se consideran un criterio adecuado. Si, tras el lanzamiento, un usuario señala un comportamiento extraño pero inquietante que no se había detectado antes, se trata de un fallo crítico tanto del modelo como del proceso.

Lo que queda fuera

El propio autor reconoce que la propuesta es heurística y no un reglamento concreto. Señala cuatro lagunas evidentes:

• cómo definir una «generación de modelos» dentro de un mismo laboratorio y entre laboratorios distintos;
• qué hacer si la corrección de un problema de alineamiento aumenta además de forma notable las capacidades;
• cómo formalizar y verificar el acuerdo si no se puede depender solo de métricas fijadas de antemano;
• dónde está el umbral de gravedad a partir del cual se detiene un modelo, teniendo en cuenta que el laboratorio tendrá interés en inflar ese umbral.

Estos son los principales puntos de fallo. Mientras no exista una definición común de generación, cualquier modelo puede presentarse como una «versión intermedia». Y cuando el umbral de gravedad lo fija el propio laboratorio, el proceso se convierte en autocertificación.

Conclusión práctica

La propuesta no tiene fuerza jurídica y, por ahora, sigue siendo un post en una plataforma especializada. Pero resulta útil como plantilla de preguntas que conviene hacer a los laboratorios. ¿Cuentan con auditores externos con acceso a los datos de entrenamiento? ¿Cuánto dura el lanzamiento limitado y qué se considera un incidente? ¿Qué ocurrirá exactamente con el calendario de lanzamientos si se encuentra un problema después del estreno? Reguladores y clientes corporativos pueden incluir estas preguntas en los requisitos a proveedores ya ahora, sin esperar a un acuerdo de toda la industria. Para los propios laboratorios, es una referencia con la que un observador externo medirá hasta qué punto se toman en serio sus declaraciones sobre seguridad.