La aviación no se volvió segura probando si cada perno podía soportar su carga nominal. Se volvió segura preguntando cómo interactúan las partes, quién tiene permitido comandar qué y cómo las operaciones reales se alejan de las condiciones que asumía el caso de seguridad. Esa disciplina es la seguridad de sistemas. Su conjunto de herramientas incluye STPA, FRAM y STECA, métodos que las industrias reguladas ya requieren.
La seguridad de la IA en su mayoría no los ha importado. Un artículo de 2026 sí lo hace.
Luca Carlucci, James Fillingham, Robert Walpole y Bartłomiej Kryś aplican esos tres métodos a un agente de codificación de vanguardia en una configuración de producción realista (laboratorio, cliente empresarial, desarrolladores) en "Un enfoque de pensamiento sistémico sobre el riesgo de pérdida de control de la IA avanzada" (arXiv:2606.13474; Taller Técnico de Gobernanza ASI de ICML 2026). Encuentran tres peligros que las pruebas ordinarias de modelos nunca fueron diseñadas para detectar.
Los tres métodos, en lenguaje sencillo
El escenario que usaron
Aplicaron los tres métodos a un agente de codificación de frontera en trabajo de software en producción: horizonte largo, uso de herramientas, con bases de código reales y servicios externos, supervisado por un laboratorio, clientes empresariales y desarrolladores. Así es como estos sistemas ya se distribuyen. El riesgo de pérdida de control a nivel de sistemas sigue apenas analizado.
Tres hallazgos que las evaluaciones de modelos pasan por alto
En su esquema, el laboratorio establece los compromisos de seguridad, redacta las normas de uso y vigila las infracciones. Reguladores, clientes y auditores no pueden verificar las operaciones de forma independiente. El autoinforme es el principal bucle de retroalimentación.
STECA lo señala como una estructura de control rota. Una acción de control solo funciona si alguien puede ver si dio resultado. Cuando la parte responsable de la seguridad es también la principal fuente de prueba de que la seguridad se mantiene, el bucle está comprometido. Eso es un hecho de diseño, no una afirmación de que algún laboratorio en particular sea deshonesto.
STPA mapea la brecha entre que un agente actúe y que un humano se entere de que actuó. En ejecuciones de varios pasos y en tiempo real, el agente ya ha llamado a una herramienta, escrito código o empujado un cambio antes de que un revisor vea la alerta.
En aviación se llama salir del bucle. La autoridad formal para detener el sistema sigue existiendo en el papel. La autoridad funcional no alcanza a seguir el ritmo. Así es como podría verse hoy la supervisión en tiempo real de agentes de codificación de frontera.
FRAM se centra en la variación ordinaria. Las salvaguardas se ajustan a cómo se veía el sistema en el momento del despliegue. Luego cambian los prompts, cambia la mezcla de tareas, se acumulan los casos límite y la distribución en vivo se aleja de la muestra usada en el lanzamiento.
Nada alarma. Las salvaguardas siguen haciendo exactamente lo que fueron diseñadas para hacer contra las condiciones de ayer. La brecha crece en silencio hasta que un caso novedoso choca con una regla que ya no encaja.
Lo que esto significa para la gobernanza
Las pruebas de modelos preguntan qué hace el sistema con ciertas entradas. No mapean la estructura de control que lo rodea, quién es responsable de qué ni cómo derivan las operaciones después del lanzamiento. Las puntuaciones de capacidad y los equipos rojos siguen siendo necesarios. No son suficientes.
La petición del artículo es simple: emparejar el análisis de peligros a nivel de modelo con el análisis de peligros a nivel de sistemas como parte obligatoria de la evaluación de seguridad. STPA, FRAM y STECA son un comienzo concreto. Escalado de un agente de codificación a toda una economía, ese mismo punto ciego es lo que hace que desempoderamiento gradual difícil de ver hasta tarde.
Para la Fundación, la lección recae en el diseño, no en un solo artículo. La inspección independiente, las normas de cómputo y la verificación externa existen para que la seguridad no dependa de que un laboratorio se evalúe a sí mismo. Por eso nuestro plan se centra en límites vinculantes y verificación, no solo la autoevaluación voluntaria. Lee el artículo si quieres el detalle completo del método: arXiv:2606.13474. Luego aplica ese hallazgo en leyes e instituciones, no solo en una cita de taller.