El argumento empieza con una admisión
En una publicación del sábado por la tarde, titulada “Models as Insider Risks in the Super Intelligence Era” (“Los modelos como riesgos internos en la era de la superinteligencia”), el consejero delegado de Microsoft, Satya Nadella, sostuvo que las organizaciones que despliegan modelos de frontera deberían tomar prestados los controles que ya aplican a las personas poderosas dentro del edificio, y dejar de tratar las garantías de un proveedor como sustituto de las propias.
El argumento arranca con algo que hoy nadie puede hacer. Con el software convencional, escribió Nadella, “teníamos las herramientas y la capacidad de rastrear comportamientos hasta una ruta de código concreta”. Con los modelos de frontera, “no podemos atribuir los comportamientos y las salidas del modelo a entradas concretas de datos de entrenamiento ni a configuraciones de pesos” y, pese a ello, esos modelos se despliegan “con acceso a nuestros datos más sensibles y dándoles la capacidad de emprender acciones críticas en nuestro nombre”.
Su conclusión es un traslado de responsabilidad, no de confianza. “Sencillamente no podemos externalizar la responsabilidad por lo que la inteligencia hace en nuestro nombre”, escribió. “Las garantías de un proveedor de modelos no nos eximen de esa responsabilidad.” La fórmula que usa para el objetivo de diseño es que “hay que separar el suministro de inteligencia de la autoridad sobre ella”.
Por qué los controles tienen que estar fuera del modelo
La objeción de Nadella a la solución evidente — poner un modelo a vigilar a otro — es que no reduce la opacidad, la apila. “Se puede y se debe usar modelos para probarse y verificarse mutuamente de forma adversarial”, escribió. “Sin embargo, así se acaba con un modelo opaco dentro de una capa de orquestación opaca, vigilado por otro modelo opaco. Esencialmente, cajas negras anidadas.”
La alternativa a la que recurre es más antigua que el campo. Los controles que rigen a qué puede acceder un modelo y qué puede hacer “deben situarse fuera del modelo”, por “un principio de seguridad de la información que se remonta a los años setenta: un programa no debe poder eludir ni manipular los mecanismos que hacen cumplir sus permisos”. En la práctica eso significa separar el modelo del arnés que orquesta su trabajo y del espacio de acciones que define lo que puede hacer.
También fijó un mínimo de transparencia del razonamiento, y nombró aquello que no quiere ver usado como excusa. La transparencia de la cadena de pensamiento es “innegociable”, escribió, y “el ‘neuralés’ no puede justificar que el razonamiento del modelo sea opaco”, aunque admitió que la transparencia por sí sola no es fiable, porque “todavía no sabemos cómo lograr que las salidas del modelo sean sistemáticamente fieles o transparentes”.
Siete principios, incluido el freno
La publicación enumera siete principios de diseño. Diversidad de modelos: ningún modelo debería ser la única dependencia de un resultado importante, ni verificar su propio trabajo. Observarlo todo: “Toda acción significativa del modelo debe dejar evidencia legible por humanos y a prueba de manipulación.” Verificabilidad: probar el sistema entero, incluidos fallos, ataques y casos límite, no solo las tareas que salen bien. Controles independientes: una organización debería poder decidir por sí misma a qué llega un modelo y qué hace. Auditabilidad independiente: “Ningún modelo debería controlar a la vez el comportamiento de un sistema y la evidencia necesaria para determinar si ese comportamiento se ajusta a la intención original.”
Luego la contención, que es la línea que más lejos ha llegado. “Debemos suponer que un modelo está comprometido y contenerlo desde el principio”, escribió Nadella. “Piénsenlo como un freno de emergencia. Una persona autorizada debería poder siempre pausar o apagar un modelo a mitad de tarea.” Los modelos más capaces, añadió, exigirán tecnologías de contención que el sector tendrá que normalizar.
El séptimo es la divulgación de incidentes: cuando estos sistemas fallen o sean comprometidos, “divulgación oportuna a los afectados” más una vía para compartir qué salió mal, qué controles fallaron y cómo evitar que se repita, incluidos — precisó — los detalles de implementación que cambian el comportamiento de los agentes en tiempo de ejecución.
Qué mirar ahora
Nadella no comprometió a Microsoft a nada concreto en la publicación, y los principios se formulan como argumento, no como hoja de ruta de producto ni como norma. Lo que los hace dignos de lectura es quién los formula y hacia dónde apuntan: dejar de preguntar si se puede confiar en un modelo dado y pasar a construir sistemas que no lo necesiten. Su frase final lo dice sin rodeos: “El sistema de superinteligencia más fiable no será el que tenga el modelo en el que más confiamos. Será el que nos permita confiar lo menos posible en el modelo.”
Dos de los siete — la observabilidad y la divulgación de incidentes — son además objeto de disputas políticas abiertas. Si Microsoft los defiende en esos foros, y no solo en la cuenta de su consejero delegado, es lo siguiente que habrá que mirar.
