Seguridad de IA Certificable: Puertas de Despliegue Con Prueba para LLMs Que Usan Herramientas
Hay un modo de fallo específico en los LLMs modernos que usan herramientas que no recibe suficiente atención: los datos que el sistema genera no son estadísticamente independientes de los datos que el monitor ve después. El LLM emite una distribución de tokens. El sistema muestrea de ella. Algunas muestras invocan herramientas. Las salidas de las herramientas se retroalimentan al contexto. La siguiente distribución de tokens está condicionada en esas salidas. Todo es adaptativo, dependiente, recursivo.
El monitoreo estadístico estándar asume observaciones independientes. La detección de drift estándar asume una distribución de referencia fija. El testing A/B estándar asume que el test no influye los datos. Ninguna de estas asunciones se mantiene para un LLM que usa herramientas en producción. El propio comportamiento del agente — y las respuestas de las herramientas — cambia la distribución que el monitor observa.
El paper reciente Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, febrero 2026) lo aborda directamente. La contribución es un framework matemático para certificar la seguridad exactamente de esta clase de sistemas, usando monitoreo estadístico anytime-valid (e-procesos) que están explícitamente diseñados para datos adaptativos y dependientes.
La matemática es densa. El patrón de ingeniería es más accesible. Vale la pena entenderlo porque la alternativa — fingir que el problema de dependencia no existe — es el modo de fallo silencioso de la mayoría del monitoreo actual de IA en producción.
Por Qué "Con Prueba" Importa
La idea central: en cada punto de decisión — cada vez que el agente quiere tomar una acción, invocar una herramienta, emitir una respuesta — se construye un certificado mostrando que la acción pertenece a un conjunto seguro. El runtime verifica el certificado en tiempo polinómico. Si el certificado es válido, la acción procede. Si no lo es, el sistema o bien recurre a un default seguro ("dummy output") o proyecta la acción a una alternativa segura cercana ("convex repair").
Esta es la misma idea que el código con prueba en software de sistemas: el productor de una acción proporciona un certificado que un verificador puede comprobar barato. La confianza cambia de "el productor se comporta bien" a "el certificado es válido".
Para sistemas de IA, esto es operativamente importante porque:
- La verificación es más barata que el reentrenamiento. Una vez el formato del certificado está fijado, comprobar es rápido. Reentrenar un modelo para que sea más seguro es caro e incierto.
- El verificador se puede confiar independientemente del modelo. Un verificador pequeño, simple, formalmente especificado se puede confiar a un nivel más alto que un modelo grande y opaco.
- El fallback es principial. Cuando el certificado falla, el sistema sabe fallar con seguridad, o emitiendo una salida dummy o proyectando a una alternativa segura.
El Problema de Datos Adaptativos
El movimiento técnico central del paper es usar e-procesos (un tipo específico de acumulador de evidencia estadística basado en supermartingalas) para el monitoreo. Los e-procesos tienen una propiedad que los p-valores normales no tienen: se mantienen válidos bajo stopping opcional y recolección adaptativa de datos.
En términos llanos: con tests estadísticos regulares, la validez del test depende de que te hayas comprometido por adelantado a cuántos datos recolectarás y qué probarás. Si echas un vistazo a los datos y decides si seguir recolectando basado en lo que has visto, has roto las garantías del test. Este es el problema "early stopping".
Para un sistema de IA en producción, no puedes evitar el early stopping. Estás monitoreando continuamente, vas a actuar sobre el monitoreo (alertando, throttling, bloqueando), y tus acciones afectan los datos que el monitor observa. Los tests estadísticos regulares te dan garantías que no se mantienen en este régimen.
Los e-procesos sí se mantienen. Dan validez uniforme en el tiempo: puedes monitorear continuamente, parar cuando quieras, y la garantía de falso positivo todavía se aplica. Esta es la base matemática que hace funcionar el monitoreo continuo de seguridad de IA.
La implicación práctica: si estás usando detección de drift basada en p-valores en un sistema de IA en producción, estás operando fuera del régimen válido del método estadístico. Esto es algo a lo que casi nadie está prestando atención en 2026, y es el tipo de error que produce tanto falsa confianza (cuando no muerde) como falsas alarmas inexplicadas (cuando sí lo hace).
La Capa de Construcción del Monitor
El paper especifica una construcción canónica del monitor con cuatro componentes:
1. Logging de confianza
Cada entrada, cada salida del modelo, cada tool call, cada respuesta de herramienta se registra de manera que el agente no puede falsificar. El log es el sustrato para todo lo demás.
2. Aleatoriedad privada del monitor
El monitor usa números aleatorios a los que el agente no tiene acceso. Esta es la misma idea que mantener secreta la semilla de una auditoría basada en aleatoriedad respecto del auditado. Evita que el agente juegue con el monitor anticipando lo que el monitor comprobará.
3. Shadow sampling
Para algunas comprobaciones, el monitor muestrea salidas adicionales del modelo con el mismo prompt para estimar la distribución de salida. Esas muestras sombra no llegan al usuario; existen solo para caracterizar la distribución de comportamiento que el modelo está produciendo.
4. Reejecución de herramientas
Para comprobaciones que involucran resultados de herramientas, el monitor puede reejecutar tool calls de manera determinista (o en un entorno sandboxed) para verificar que la respuesta era lo que tenía que ser.
Esos cuatro juntos dan al monitor suficiente evidencia independiente para construir los certificados que el runtime necesita. Ninguno de ellos es exótico; los cuatro están al alcance de cualquier equipo que tome el monitoreo en serio. La contribución es especificar exactamente qué se necesita y por qué.
Composición Modular: Por Qué Importa
Un dolor de cabeza práctico en seguridad de IA es la composición. Puedes certificar que dos componentes son seguros individualmente y tener un sistema compuesto inseguro. El caso clásico: una herramienta que es segura llamar individualmente, llamada muchas veces en rápida sucesión, puede producir efectos agregados inseguros (denial-of-service contra un sistema descendente, escalada por llamadas repetidas, etc.).
El paper proporciona un teorema de composición modular: bajo condiciones específicas, los certificados de seguridad de los componentes se componen en un certificado de seguridad para el sistema. Las condiciones son reales y no triviales, pero son explícitas. Un equipo que construye sistemas agénticos compuestos puede comprobar las condiciones y saber si su composición está en el régimen donde la seguridad de los componentes implica la seguridad del sistema.
El encuadre honesto importa. El paper etiqueta esto como "un primer régimen composicional" — significa que es un punto de partida útil, no una teoría completa de seguridad composicional. Los equipos de ingeniería deberían tratarlo de la misma manera: útil para los casos que cubre, no una garantía para los que no cubre.
El Presupuesto Global de Riesgo
Una contribución sutil pero importante: un corolario que asigna un presupuesto global de riesgo a través de los tiempos de decisión en runtime. Esto aborda el modo de fallo "seguro por paso, inseguro en agregado".
Cada punto de decisión tiene una pequeña probabilidad de producir una acción insegura. Sumado a través de miles o millones de decisiones, la probabilidad agregada de al menos una acción insegura se hace grande. El paper proporciona una manera de asignar el presupuesto global de riesgo a través del calendario de decisiones para que el agregado esté limitado.
En la práctica, esto significa establecer umbrales de seguridad por acción basados en cuántas acciones esperas que el sistema tome, con seguimiento explícito del presupuesto. Un sistema que toma un millón de acciones por día y quiere probabilidad agregada de acción insegura ≤1% necesita un umbral por acción mucho más estrecho que un sistema que toma mil acciones.
Este es el tipo de contabilidad que la mayoría de sistemas de IA en producción no hacen explícitamente. Establecen un umbral por acción basado en intuición y no verifican el agregado. CAST da el framework para hacerlo correctamente.
Convex Repair: Cuando el Certificado Falla
Cuando una acción falla la certificación, existen dos opciones:
- Fallback dummy: emite una salida default segura. Conservadora, simple, a menudo degrada la experiencia del usuario.
- Convex repair: proyecta la salida insegura al punto más cercano en el conjunto seguro. Requiere que el conjunto seguro sea convexo y que la proyección sea tratable.
El paper proporciona teoremas de proyección a la seguridad en geometrías KL/Bregman y de transporte óptimo, con un camino de tratabilidad explícito para la reparación basada en transporte. La matemática dice: bajo condiciones específicas, puedes calcular una acción que es "tan cercana como sea posible" a la acción original insegura mientras está dentro del conjunto seguro.
La conclusión de ingeniería: cuando diseñes tu conjunto seguro, diséñalo convexo. Los conjuntos seguros convexos admiten proyección en tiempo polinómico. Los conjuntos seguros no convexos generalmente no. Esta es una decisión de diseño que tomas cuando especificas la política de seguridad, y determina si el convex repair está incluso disponible.
Qué Significa Para Equipos de IA en Producción
Tres acciones prácticas para cualquier equipo que ejecute sistemas LLM con uso de herramientas en producción:
1. Verifica tu metodología de monitoreo
Si tu detección de drift o monitoreo de seguridad usa métodos estándar basados en p-valores sobre datos recolectados adaptativamente, las garantías estadísticas no se mantienen. O bien muévete a monitoreo basado en e-procesos (la respuesta correcta) o sé explícito que tu monitoreo es heurístico en lugar de riguroso estadísticamente (una respuesta provisional defendible).
2. Especifica el conjunto seguro explícitamente
La frase "el modelo es seguro" no tiene un significado preciso. "Las salidas son miembros del conjunto S" sí. Especifica S en código o descripción formal. Luego puedes verificar la pertenencia, proyectar fallos a S y razonar sobre la composición.
3. Ten en cuenta el riesgo global
Si tu sistema toma muchas acciones, establece umbrales por acción basados en presupuesto de riesgo agregado, no en intuición por acción. La matemática no es difícil una vez has decidido el presupuesto; la disciplina está en decidir hacerlo.
Dónde No Se Aplica CAST
El paper es explícito sobre el alcance: no es una teoría de robótica, no asume superinteligencia, y se posiciona como "contención y certificación de grado financiero / grado computación científica". Es para leyes de seguridad explícitamente especificadas en sistemas LLM con uso de herramientas.
Este es el régimen donde vive la mayoría del despliegue de IA en producción en 2026. CAST está bien dirigido al problema práctico. Los equipos que envían agentes basados en LLM que tocan herramientas reales — la mayor parte de la IA agéntica en producción — deberían estar leyendo este paper y adaptando los patrones.
La alternativa es monitoreo que es matemáticamente erróneo sobre los datos que procesa. Este es el tipo de error que produce incidentes que nadie puede explicar después del hecho.
Fuente: Fradelos, G. Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Ginebra, 12 de febrero de 2026). SSRN 6307158.
¿Ejecutando LLMs con uso de herramientas en producción y quieres monitoreo que sea realmente estadísticamente válido para los datos que recoges? Habla con un CTO sobre desplegar capacidad de ingeniería nearshore que pueda construir seguridad certificable en el runtime.
