Seguridad de IA certificable: puertas de despliegue con prueba verificable para LLMs que usan herramientas
Hay un modo de fallo específico en los LLMs modernos que usan herramientas del que no se habla lo suficiente: los datos que el sistema genera no son estadísticamente independientes de los datos que el monitor verá después. El LLM emite una distribución de tokens. El sistema muestrea de ella. Algunas muestras invocan herramientas. Las salidas de las herramientas vuelven al contexto. La siguiente distribución de tokens está condicionada por 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 en los datos. Ninguno de estos supuestos se cumple 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 está observando. Pasé años construyendo monitoreo para sistemas en producción antes de que llegaran los LLMs, y cada pipeline de alertas que puse en marcha se apoyaba en al menos uno de esos supuestos.
El paper reciente Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, febrero de 2026) aborda el problema de frente. Su contribución es un marco matemático para certificar la seguridad de exactamente esta clase de sistemas, usando monitoreo estadístico anytime-valid (e-procesos) diseñado explícitamente para datos adaptativos y dependientes.
La matemática es densa. El patrón de ingeniería es más accesible, y es la parte que quiero recorrer aquí — porque la alternativa, fingir que el problema de dependencia no existe, es el modo de fallo silencioso de la mayor parte del monitoreo de IA en producción actual.
Por qué importa que la acción «lleve su prueba»
La idea central: en cada punto de decisión — cada vez que el agente quiere ejecutar una acción, invocar una herramienta, emitir una respuesta — se construye un certificado que demuestra 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 valor por defecto seguro («dummy output») o bien proyecta la acción hacia una alternativa segura cercana («convex repair»).
Es la misma idea que el proof-carrying code en software de sistemas: quien produce una acción aporta un certificado que un verificador puede comprobar a bajo coste. La confianza se desplaza de «el productor se comporta bien» a «el certificado es válido».
Para los sistemas de IA, esto es operativamente importante porque:
- Verificar es más barato que reentrenar. Una vez fijado el formato del certificado, comprobarlo es rápido. Reentrenar un modelo para hacerlo más seguro es caro e incierto.
- En el verificador se puede confiar con independencia del modelo. Un verificador pequeño, simple y formalmente especificado merece un nivel de confianza más alto que un modelo grande y opaco.
- El fallback tiene fundamento. Cuando el certificado falla, el sistema sabe cómo fallar de forma segura: o emite una salida dummy o proyecta hacia una alternativa segura.
Los datos adaptativos rompen la estadística estándar
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 convencionales no tienen: siguen siendo válidos bajo parada opcional y recolección adaptativa de datos.
En términos llanos: con los tests estadísticos habituales, la validez del test depende de que te hayas comprometido por adelantado a cuántos datos recogerás y qué vas a contrastar. Si echas un vistazo a los datos y decides si seguir recogiendo en función de lo que has visto, has roto las garantías del test. Es el problema del «early stopping».
Para un sistema de IA en producción, el early stopping es inevitable. Monitorizas de forma continua, vas a actuar a partir del monitoreo (alertar, limitar el tráfico, bloquear), y tus acciones afectan a los datos que el monitor observa. Los tests estadísticos habituales te dan garantías que no se sostienen en este régimen.
Los e-procesos sí se sostienen. Ofrecen validez uniforme en el tiempo: puedes monitorizar de forma continua, parar cuando quieras, y la garantía sobre falsos positivos sigue aplicándose. Esta es la base matemática que hace posible el monitoreo continuo de seguridad de IA.
La implicación práctica: si usas detección de drift basada en p-valores sobre un sistema de IA en producción, estás operando fuera del régimen válido del método estadístico. Todavía no he visto un stack de monitoreo en producción que tenga esto en cuenta, y es el tipo de error que produce a la vez falsa confianza (cuando no muerde) y falsas alarmas inexplicables (cuando sí lo hace).
El monitor necesita evidencia que el agente no pueda falsificar
El paper especifica una construcción canónica del monitor con cuatro componentes:
1. Logging confiable
Cada entrada, cada salida del modelo, cada tool call, cada respuesta de herramienta se registra de forma que el agente no pueda falsificarla. El log es el sustrato de todo lo demás.
2. Aleatoriedad privada del monitor
El monitor usa números aleatorios a los que el agente no tiene acceso. Es la misma idea que mantener en secreto, frente al auditado, la semilla de una auditoría basada en aleatoriedad. Impide que el agente manipule al monitor anticipando qué va a 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 las comprobaciones que involucran resultados de herramientas, el monitor puede reejecutar tool calls de forma determinista (o en un entorno aislado) para verificar que la respuesta era la que debía ser.
Estos cuatro componentes juntos dan al monitor suficiente evidencia independiente para construir los certificados que el runtime necesita. Ninguno es exótico; los cuatro están al alcance de cualquier equipo que se tome el monitoreo en serio. La contribución está en especificar exactamente qué hace falta 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 por separado y aun así tener un sistema compuesto inseguro. El caso clásico: una herramienta segura si se invoca de forma aislada, llamada muchas veces en rápida sucesión, puede producir efectos agregados inseguros (denegación de servicio contra un sistema aguas abajo, escalada mediante llamadas repetidas, etc.).
El paper aporta 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» — es decir, un punto de partida útil, no una teoría completa de seguridad composicional. Los equipos de ingeniería deberían tratarlo igual: útil para los casos que cubre, no una garantía para los que no cubre.
Seguro en cada paso no es seguro en agregado
Una contribución sutil pero importante: un corolario que reparte un presupuesto global de riesgo entre los puntos de decisión en runtime. Esto aborda el modo de fallo «seguro por paso, inseguro en agregado».
Cada punto de decisión tiene una probabilidad pequeña de producir una acción insegura. Sumada a lo largo de miles o millones de decisiones, la probabilidad agregada de que ocurra al menos una acción insegura se vuelve grande. El paper aporta una forma de repartir el presupuesto global de riesgo a lo largo del calendario de decisiones para que el agregado quede acotado.
En la práctica, esto significa fijar los umbrales de seguridad por acción en función de cuántas acciones esperas que el sistema ejecute, con un seguimiento explícito del presupuesto. Un sistema que ejecuta un millón de acciones al día y quiere una probabilidad agregada de acción insegura ≤1% necesita un umbral por acción mucho más estricto que uno que ejecuta mil acciones.
Es el tipo de contabilidad que la mayoría de los sistemas de IA en producción no hace de forma explícita. Fijan un umbral por acción a base de intuición y no verifican el agregado. CAST aporta el marco para hacerlo bien.
Convex repair: cuando el certificado falla
Cuando una acción no supera la certificación, hay dos opciones:
- Fallback dummy: emitir una salida segura por defecto. Conservadora, simple, y a menudo degrada la experiencia de usuario.
- Convex repair: proyectar la salida insegura al punto más cercano del conjunto seguro. Requiere que el conjunto seguro sea convexo y que la proyección sea computacionalmente tratable.
El paper aporta teoremas de proyección hacia la seguridad en geometrías KL/Bregman y de transporte óptimo, con una vía de tratabilidad explícita para la reparación basada en transporte. La matemática dice: bajo condiciones específicas, puedes calcular una acción lo más cercana posible a la acción insegura original que quede 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 no convexos, en general, no. Es una decisión de diseño que tomas al especificar la política de seguridad, y determina si la reparación convexa está siquiera disponible.
Qué significa esto para los equipos de IA en producción
Tres cosas que pondría en marcha en cualquier equipo que opere sistemas LLM con uso de herramientas en producción:
1. Verifica tu metodología de monitoreo
Si tu detección de drift o tu monitoreo de seguridad usa métodos estándar basados en p-valores sobre datos recogidos de forma adaptativa, las garantías estadísticas no se sostienen. O bien migras a un monitoreo basado en e-procesos (la respuesta correcta) o bien dejas explícito que tu monitoreo es heurístico y no estadísticamente riguroso (una respuesta provisional defendible).
2. Especifica el conjunto seguro explícitamente
La frase «el modelo es seguro» no tiene un significado preciso. «Las salidas pertenecen al conjunto S» sí lo tiene. Especifica S en código o en una descripción formal. A partir de ahí puedes verificar pertenencia, proyectar los fallos hacia S y razonar sobre la composición.
3. Contabiliza el riesgo global
Si tu sistema ejecuta muchas acciones, fija los umbrales por acción a partir del presupuesto agregado de riesgo, no de la intuición por acción. La matemática no es difícil una vez decidido el presupuesto; la disciplina está en decidir hacerlo.
Dónde no aplica CAST
El paper es explícito sobre su alcance: no es una teoría de robótica, no asume superinteligencia, y se posiciona como «contención y certificación de grado financiero / de computación científica». Está pensado para leyes de seguridad especificadas explícitamente sobre sistemas LLM que usan herramientas.
Ese es el régimen en el que vive la mayor parte del despliegue de IA en producción en 2026. CAST apunta bien al problema práctico. Los equipos que llevan a producción agentes basados en LLM que tocan herramientas reales — el grueso de la IA agéntica en producción — deberían estar leyendo este paper y adaptando sus patrones.
La alternativa es un monitoreo matemáticamente erróneo respecto de los datos que procesa. Y ese es el tipo de error que produce incidentes que después nadie sabe explicar.
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.
¿Operas LLMs con uso de herramientas en producción y quieres un monitoreo que sea de verdad estadísticamente válido para los datos que estás recogiendo? Habla con un CTO sobre cómo desplegar capacidad de ingeniería nearshore capaz de integrar seguridad certificable en el runtime.
