Esclusa: controles y evidencia compartida para supervisar agentes de IA

Durante años, un programa de inteligencia artificial se limitaba a escribir texto en una pantalla. Lo que ocurriera después dependía de que una persona leyera ese texto y decidiera hacer algo con él. Esa distancia se ha terminado.

Hoy los sistemas que llamamos agentes ejecutan acciones por su cuenta: abren conexiones, leen y escriben archivos, llaman a servicios de pago, lanzan procesos, modifican sistemas. No es una capacidad futura ni excepcional; es cómo funcionan ya las herramientas que muchas empresas usan a diario para programar, gestionar infraestructura o atender clientes.

Y aquí aparece un hueco incómodo: nadie sabe con datos qué intentan hacer realmente esos agentes. No existe un registro compartido, comparable y auditado de cuántas veces un agente ha intentado una acción fuera de lo que tenía autorizado, ni de cuántas lo ha conseguido. Cada laboratorio conoce fragmentos de lo suyo. El debate público, mientras tanto, se libra con anécdotas: un caso llamativo en una red social, una demostración impactante, una negación genérica. Sobre esa base no se puede decidir nada.

Discutimos si los agentes de IA son seguros sin disponer de la única cosa que permitiría responder: mediciones comparables, hechas en condiciones conocidas, que alguien independiente pueda comprobar.

Esta es una propuesta para construir esa base de datos, y para construirla en el mismo sitio donde se pueden imponer límites reales.

Por qué en el origen y no en Internet

La reacción intuitiva es vigilar la red. No funciona: Internet no tiene unas pocas puertas obligatorias por las que todo deba pasar. Es un conjunto de redes administradas de forma independiente, y un control instalado en unos cuantos operadores grandes deja huecos por todas partes.

Sí existe, en cambio, un punto de paso obligatorio: el entorno donde el agente se ejecuta. Ahí, antes de que la acción salga al mundo, hay una oportunidad real de comprobarla. Y hay un segundo punto de apalancamiento que casi nadie usa: los proveedores de cómputo. Los agentes potentes corren en muy pocos sitios, y esos sitios se rigen por contratos.

Qué es Esclusa

Esclusa es una propuesta de infraestructura común entre laboratorios, proveedores de cómputo y auditores independientes. Hace dos cosas: limita las acciones no autorizadas de los agentes, y produce evidencia comprobable sobre la eficacia de ese límite.

El nombre describe el mecanismo. Una esclusa no cierra el paso: lo organiza en tramos. Un barco atraviesa compuertas sucesivas y en ningún momento hay una vía directa entre los dos extremos, porque una puerta no se abre hasta que la anterior se ha cerrado. Eso es exactamente lo que hace falta aquí.

Su alcance es el control dentro de entornos definidos y evaluados. No garantiza contener una superinteligencia ni resuelve el problema de alineamiento. Puede mostrar que las pruebas ya no justifican un despliegue; no puede garantizar que detectará toda pérdida de control. Conviene decirlo al principio, porque el resto del texto sólo tiene sentido dentro de ese límite.

Las piezas técnicas no son nuevas: permisos acotados, aislamiento y supervisión existen desde hace décadas, y su aplicación a modelos de IA es un campo activo de investigación, el llamado AI control. Lo que se propone aquí es distinto: coordinarlas entre organizaciones, compartir los resultados y exigir aprobación independiente para actualizar tanto al vigilante como al modelo vigilado.

Cómo funciona

El sistema se instala en el entorno donde se ejecutan los agentes. Las conexiones externas y las llamadas a herramientas atraviesan componentes que el agente no administra. La instalación tiene que comprobar que no existen rutas alternativas: configurar un proxy no basta si queda una salida sin cubrir.

El agente nunca alcanza el exterior directamente. Las credenciales viven fuera de él; el registro, fuera de todos.

• Permisos por tarea. Cada ejecución recibe una identidad y límites de recursos, operaciones, tiempo y presupuesto.
• Intermediario de herramientas. Conserva las credenciales y comprueba cada operación antes de ejecutarla. El modelo no obtiene acceso general por conocer una contraseña, porque nunca llega a tenerla.
• Control de red. Restringe destinos y conexiones. Una conexión permitida no autoriza cualquier operación dentro de ese servicio.
• Evaluadores de IA. Analizan acciones y secuencias sospechosas. Activan bloqueos o suspensiones locales; ampliar su alcance exige revisión independiente. No conceden permisos ni modifican políticas.
• Registro externo. Conserva solicitudes, decisiones y resultados fuera del alcance del agente. Los evaluadores tampoco pueden alterarlo.

Un ejemplo. Un agente autorizado para analizar código intenta crear un servidor y enviarle archivos. El intermediario rechaza ambas operaciones porque están fuera de su alcance. El evaluador examina el episodio y puede suspender esa ejecución concreta. Queda evidencia de todo ello fuera del alcance del agente.

Ningún modelo de lenguaje autoriza una acción. La autorización procede siempre de reglas externas. Pero conviene no exagerar la fuerza de ese principio: si una acción permitida sólo se detiene cuando el evaluador percibe el peligro, su seguridad sigue dependiendo en parte de ese evaluador. La ausencia de una alerta no demuestra que la acción fuera segura.

Por eso los evaluadores se entrenan con actividad legítima e intentos de evasión, y equipos independientes los atacan en dos direcciones: para pasar inadvertidos y para provocar bloqueos indebidos. Manipular al vigilante para que detenga trabajo legítimo es una forma de denegación de servicio, y además es el camino más cómodo para conseguir que alguien acabe desactivando el sistema entero.

La sobrecarga se mide igual que todo lo demás. No toda operación necesita una evaluación individual: la política fija qué análisis debe completarse antes de actuar y cuál admite revisión posterior. Las pruebas comparan tareas equivalentes con y sin Esclusa —efectos no autorizados, bloqueos erróneos, latencia añadida en los percentiles 95 y 99, coste por tarea—. Una sobrecarga alta es un problema que se corrige; no habilita un modo sin controles.

Lo que no resuelve

Tres límites forman parte del diseño y no se van a cerrar con más ingeniería:

• Acciones autorizadas pero dañinas. Cumplir los permisos no garantiza que una decisión, o sus consecuencias, sean seguras.
• El canal humano. Un modelo puede persuadir a una persona para que ejecute código, relaje una política o apruebe un despliegue. Ninguna puerta lo impide.
• Ejecuciones fuera del perímetro. Una copia de los pesos, publicada o sustraída, puede ejecutarse sin Esclusa allí donde haya hardware suficiente. Es una vía estructural para eludir el control en origen.

El canal humano admite mitigación parcial, y merece la pena aplicarla: las solicitudes del modelo se revisan en un proceso separado, con evidencia comprobable, permisos mínimos y caducidad, y los cambios de alto impacto requieren una segunda revisión independiente. Esto reduce el riesgo. No convierte a las personas en supervisores infalibles.

Cómo se extiende

La adopción se apoya en contratos: determinados recursos de cómputo exigen controles activos, registros y acceso de auditores, y el proveedor puede suspender el servicio afectado si se incumplen las condiciones. Es una palanca más rápida que cualquier regulación y ya existe la relación comercial que la soporta.

La atestación de hardware ayuda a verificar propiedades concretas del entorno. Los mecanismos disponibles para GPU no certifican el comportamiento del modelo ni toda su conectividad, y la gobernanza apoyada en hardware requiere desarrollo adicional. Equipos privados, hardware ya desplegado y operadores no participantes impiden prometer cobertura universal.

Quién aprueba las versiones

Esclusa y el modelo vigilado no aprueban sus propias actualizaciones, y ninguno de los dos puede ser el certificador único del otro. Un equipo externo evalúa cada versión con criterios fijados de antemano, y responsables identificados autorizan el despliegue.

Un órgano de evaluación independiente del laboratorio decide qué usos requieren vigilancia obligatoria y valida esa clasificación antes de ejecutarlos; el laboratorio no puede eximirse por su cuenta. Se acuerdan también las condiciones de suspensión —evasiones reproducibles, pérdida de registros, resultados insuficientes— y si la vigilancia obligatoria falla, las operaciones que dependen de ella se detienen.

La evidencia compartida

Este es el producto duradero, el que sobrevive aunque una defensa concreta deje de funcionar.

Para que los números de dos organizaciones sean comparables hay que fijar antes qué se cuenta. El consorcio mantiene una taxonomía compartida y versionada de eventos reportables: un efecto externo no autorizado es una acción consumada fuera de los recursos u operaciones permitidos —transmitir datos, modificar un sistema, crear un proceso—, y los intentos bloqueados se cuentan aparte. Cada evento identifica la política vigente, la categoría y la gravedad. Un órgano independiente arbitra los casos frontera y los cambios de criterio conservan el historial.

Cada ejecución declara antes de comenzar si es una prueba adversaria o uso ordinario. La etiqueta original queda registrada y no se modifica; cualquier rectificación se añade con revisión independiente. Un incidente no puede convertirse retrospectivamente en un ejercicio. Los auditores contrastan los registros con el inventario de ejecuciones del proveedor de cómputo para detectar omisiones, y las discrepancias suspenden la validez del reporte afectado.

Queda el problema más sutil, y es el que más equivocaciones produce: un registro limpio puede significar que no pasó nada o que no se vio nada.

El registro sólo contiene lo que la detección captó. Sin medir la sensibilidad, un sistema ciego produce el mejor informe.

La solución es calibrar la detección con violaciones conocidas, sembradas periódicamente en recursos de prueba aislados, sin revelar al vigilante qué casos son. Se conserva evidencia externa de los efectos consumados y se mide qué fracción detecta la cadena completa de registro y clasificación. Esa fracción, con su propio margen de error, es lo que permite convertir una tasa observada en una cota sobre la tasa real. Y tiene su propio límite: detectar casos sembrados no garantiza detectar ataques de otra forma.

El primer paso

Nada de esto se justifica por escrito. Se justifica con un piloto acotado: dos o tres entornos controlados, servicios de prueba, y equipos independientes intentando ampliar permisos, sacar información o poner en marcha procesos fuera de su alcance.

Lo que ese piloto tiene que medir está fijado de antemano: cuántos intentos consiguen efectos externos, cuánto tarda la contención, qué trabajo legítimo se interrumpe, qué sucede cuando falla un componente y qué fracción de las violaciones sembradas detecta el sistema. Esos resultados, y no el diseño, deciden qué usos admite la arquitectura.

Hace falta que un primer grupo —un laboratorio, un proveedor de cómputo y un auditor— acepte de antemano las consecuencias de lo que salga: mantener, restringir o suspender un uso. Esa aceptación previa es el requisito difícil. El resto es ingeniería conocida.

Anexo: cómo se calculan las cotas

Este anexo desarrolla el cálculo del apartado anterior. Los números son ficticios y sirven para mostrar el método.

Supongamos un ensayo que registra cero ejecuciones con efectos detectados entre un millón. Lo primero es no leer ese cero como un cero: acota la tasa registrada, no la real. La referencia clásica para interpretar numeradores nulos es Hanley y Lippman-Hand (JAMA, 1983).

Supongamos además una calibración separada en la que el sistema detecta 94 de 100 ejecuciones con una violación conocida. Si ambas muestras admiten un modelo binomial y la sensibilidad medida se transfiere al grupo evaluado, los límites unilaterales al 97,5 % dan:

• Tasa de ejecuciones con efectos detectados: límite superior de 3,6889 por millón.
• Sensibilidad de detección: límite inferior de 87,3970 %.
• Tasa real de ejecuciones afectadas: límite superior corregido de 4,22 por millón, dividiendo el primero entre el segundo.

Usar ambos límites al 97,5 % conserva al menos un 95 % de cobertura conjunta mediante la corrección de Bonferroni. No basta con dividir por la sensibilidad estimada: hay que dividir la cota superior de la tasa entre la cota inferior de la sensibilidad, que es la dirección conservadora.

La corrección no es cosmética. Con estos números añade un 14 % a la cota, y con detectores peores crece deprisa. Si el criterio acordado de antemano exigía un límite inferior a 1 por millón, este ensayo no basta: harían falta unos 4,2 millones de ejecuciones sin efectos detectados, manteniendo la misma sensibilidad.

Dos advertencias sobre el método. Los informes separan versión, configuración y familia de tareas, y comparan grupos con permisos y condiciones equivalentes; compartir configuración no prueba dependencia, pero tampoco garantiza diversidad, y si hay ejecuciones correlacionadas el análisis debe tratar sus agrupaciones explícitamente. Sin un modelo justificable no se publica un intervalo binomial ni se inventa un tamaño efectivo de muestra. Y ninguna de estas cotas se extrapola a ataques que no estaban en el ensayo.