Seguretat d'IA Certificable: Portes de Desplegament Amb Prova per a LLMs Que Usen Eines
Hi ha un mode de fallada específic als LLMs moderns que usen eines que no rep prou atenció: les dades que el sistema genera no són estadísticament independents de les dades que el monitor veu després. L'LLM emet una distribució de tokens. El sistema en mostreja. Algunes mostres invoquen eines. Les sortides de les eines es retroalimenten al context. La següent distribució de tokens està condicionada en aquestes sortides. Tot és adaptatiu, dependent, recursiu.
El monitoratge estadístic estàndard assumeix observacions independents. La detecció de drift estàndard assumeix una distribució de referència fixa. El testing A/B estàndard assumeix que la prova no influeix les dades. Cap d'aquestes assumpcions es manté per a un LLM que usa eines en producció. El propi comportament de l'agent — i les respostes de les eines — canvia la distribució que el monitor observa.
El paper recent Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, febrer 2026) ho aborda directament. La contribució és un framework matemàtic per certificar la seguretat exactament d'aquesta classe de sistemes, usant monitoratge estadístic anytime-valid (e-processos) que estan dissenyats explícitament per a dades adaptatives i dependents.
La matemàtica és densa. El patró d'enginyeria és més accessible. Val la pena entendre'l perquè l'alternativa — fer veure que el problema de dependència no existeix — és el mode de fallada silenciós de la majoria del monitoratge actual d'IA en producció.
Per Què "Amb Prova" Importa
La idea central: a cada punt de decisió — cada cop que l'agent vol prendre una acció, invocar una eina, emetre una resposta — es construeix un certificat mostrant que l'acció pertany a un conjunt segur. El runtime verifica el certificat en temps polinòmic. Si el certificat és vàlid, l'acció procedeix. Si no ho és, el sistema o bé recorre a un default segur ("dummy output") o projecta l'acció a una alternativa segura propera ("convex repair").
Aquesta és la mateixa idea que el codi amb prova al programari de sistemes: el productor d'una acció proporciona un certificat que un verificador pot comprovar barat. La confiança canvia de "el productor es comporta bé" a "el certificat és vàlid".
Per a sistemes d'IA, això és operativament important perquè:
- La verificació és més barata que el reentrenament. Un cop el format del certificat està fixat, comprovar és ràpid. Reentrenar un model perquè sigui més segur és car i incert.
- El verificador es pot confiar independentment del model. Un verificador petit, simple, formalment especificat es pot confiar a un nivell més alt que un model gran i opac.
- El fallback és principial. Quan el certificat falla, el sistema sap fallar amb seguretat, o emetent una sortida dummy o projectant a una alternativa segura.
El Problema de Dades Adaptatives
El moviment tècnic central del paper és usar e-processos (un tipus específic d'acumulador d'evidència estadística basat en supermartingales) per al monitoratge. Els e-processos tenen una propietat que els p-valors normals no tenen: es mantenen vàlids sota stopping opcional i recollida adaptativa de dades.
En termes plans: amb tests estadístics regulars, la validesa del test depèn que t'hagis compromès per avançat a quantes dades recolliràs i què provaràs. Si fas un cop d'ull a les dades i decideixes si seguir recollint basat en el que has vist, has trencat les garanties del test. Aquest és el problema "early stopping".
Per a un sistema d'IA en producció, no pots evitar l'early stopping. Estàs monitorant contínuament, vas a actuar sobre el monitoratge (alertant, throttling, bloquejant), i les teves accions afecten les dades que el monitor observa. Els tests estadístics regulars et donen garanties que no es mantenen en aquest règim.
Els e-processos sí es mantenen. Donen validesa uniforme en el temps: pots monitorar contínuament, parar quan vulguis, i la garantia de fals positiu encara s'aplica. Aquesta és la base matemàtica que fa funcionar el monitoratge continu de seguretat d'IA.
La implicació pràctica: si estàs usant detecció de drift basada en p-valors en un sistema d'IA en producció, estàs operant fora del règim vàlid del mètode estadístic. Això és una cosa a la qual quasi ningú està parant atenció el 2026, i és el tipus d'error que produeix tant falsa confiança (quan no fa mal) com falses alarmes inexplicades (quan sí ho fa).
La Capa de Construcció del Monitor
El paper especifica una construcció canònica del monitor amb quatre components:
1. Logging de confiança
Cada entrada, cada sortida del model, cada tool call, cada resposta d'eina es registra de manera que l'agent no pot falsificar. El log és el substrat per a tota la resta.
2. Aleatorietat privada del monitor
El monitor usa nombres aleatoris als quals l'agent no té accés. Aquesta és la mateixa idea que mantenir secreta la llavor d'una auditoria basada en aleatorietat respecte de l'auditat. Evita que l'agent jugui amb el monitor anticipant el que el monitor comprovarà.
3. Shadow sampling
Per a algunes comprovacions, el monitor mostreja sortides addicionals del model amb el mateix prompt per estimar la distribució de sortida. Aquestes mostres ombra no arriben a l'usuari; existeixen només per caracteritzar la distribució de comportament que el model està produint.
4. Reexecució d'eines
Per a comprovacions que involucren resultats d'eines, el monitor pot reexecutar tool calls de manera determinista (o en un entorn sandboxed) per verificar que la resposta era el que havia de ser.
Aquests quatre junts donen al monitor prou evidència independent per construir els certificats que el runtime necessita. Cap d'ells és exòtic; els quatre estan a l'abast de qualsevol equip que prengui el monitoratge seriosament. La contribució és especificar exactament què cal i per què.
Composició Modular: Per Què Importa
Un mal de cap pràctic en seguretat d'IA és la composició. Pots certificar que dos components són segurs individualment i tenir un sistema compost insegur. El cas clàssic: una eina que és segura cridar individualment, cridada moltes vegades en ràpida successió, pot produir efectes agregats insegurs (denial-of-service contra un sistema descendent, escalada per crides repetides, etc.).
El paper proporciona un teorema de composició modular: sota condicions específiques, els certificats de seguretat dels components es componen en un certificat de seguretat per al sistema. Les condicions són reals i no trivials, però són explícites. Un equip que construeix sistemes agèntics compostos pot comprovar les condicions i saber si la seva composició està al règim on la seguretat dels components implica la seguretat del sistema.
L'enquadrament honest importa. El paper etiqueta això com "un primer règim composicional" — significa que és un punt de partida útil, no una teoria completa de seguretat composicional. Els equips d'enginyeria haurien de tractar-ho de la mateixa manera: útil per als casos que cobreix, no una garantia per als que no cobreix.
El Pressupost Global de Risc
Una contribució subtil però important: un corol·lari que assigna un pressupost global de risc a través dels temps de decisió en runtime. Això aborda el mode de fallada "segur per pas, insegur en agregat".
Cada punt de decisió té una petita probabilitat de produir una acció insegura. Sumat a través de milers o milions de decisions, la probabilitat agregada d'almenys una acció insegura es fa gran. El paper proporciona una manera d'assignar el pressupost global de risc a través del calendari de decisions perquè l'agregat estigui limitat.
A la pràctica, això significa establir llindars de seguretat per acció basats en quantes accions esperes que el sistema prengui, amb seguiment explícit del pressupost. Un sistema que pren un milió d'accions per dia i vol probabilitat agregada d'acció insegura ≤1% necessita un llindar per acció molt més estret que un sistema que pren mil accions.
Aquest és el tipus de comptabilitat que la majoria de sistemes d'IA en producció no fan explícitament. Estableixen un llindar per acció basat en intuïció i no verifiquen l'agregat. CAST dona el framework per fer-ho correctament.
Convex Repair: Quan el Certificat Falla
Quan una acció falla la certificació, existeixen dues opcions:
- Fallback dummy: emet una sortida default segura. Conservadora, simple, sovint degrada l'experiència de l'usuari.
- Convex repair: projecta la sortida insegura al punt més proper al conjunt segur. Requereix que el conjunt segur sigui convex i que la projecció sigui tractable.
El paper proporciona teoremes de projecció a la seguretat en geometries KL/Bregman i de transport òptim, amb un camí de tractabilitat explícit per a la reparació basada en transport. La matemàtica diu: sota condicions específiques, pots calcular una acció que és "tan propera com possible" a l'acció original insegura mentre està dins del conjunt segur.
La conclusió d'enginyeria: quan dissenyis el teu conjunt segur, dissenya'l convex. Els conjunts segurs convexos admeten projecció en temps polinòmic. Els conjunts segurs no convexos generalment no. Aquesta és una decisió de disseny que prens quan especifiques la política de seguretat, i determina si el convex repair està fins i tot disponible.
Què Significa Per a Equips d'IA en Producció
Tres accions pràctiques per a qualsevol equip que executi sistemes LLM amb ús d'eines en producció:
1. Verifica la teva metodologia de monitoratge
Si la teva detecció de drift o monitoratge de seguretat usa mètodes estàndard basats en p-valors sobre dades recollides adaptativament, les garanties estadístiques no es mantenen. O bé mou-te a monitoratge basat en e-processos (la resposta correcta) o sigues explícit que el teu monitoratge és heurístic en lloc de rigorós estadísticament (una resposta interim defensable).
2. Especifica el conjunt segur explícitament
La frase "el model és segur" no té un significat precís. "Les sortides són membres del conjunt S" sí. Especifica S en codi o descripció formal. Llavors pots verificar la pertinença, projectar fallades a S i raonar sobre la composició.
3. Tingues en compte el risc global
Si el teu sistema pren moltes accions, estableix llindars per acció basats en pressupost de risc agregat, no en intuïció per acció. La matemàtica no és difícil un cop has decidit el pressupost; la disciplina és en decidir fer-ho.
On No S'Aplica CAST
El paper és explícit sobre l'abast: no és una teoria de robòtica, no assumeix superintel·ligència, i es posiciona com "contenció i certificació de grau financer / grau computació científica". És per a lleis de seguretat explícitament especificades en sistemes LLM amb ús d'eines.
Aquest és el règim on viu la majoria del desplegament d'IA en producció el 2026. CAST està ben dirigit al problema pràctic. Els equips que envien agents basats en LLM que toquen eines reals — la major part de la IA agentic en producció — haurien d'estar llegint aquest paper i adaptant els patrons.
L'alternativa és monitoratge que és matemàticament erroni sobre les dades que processa. Aquest és el tipus d'error que produeix incidents que ningú pot explicar després del fet.
Font: Fradelos, G. Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Ginebra, 12 de febrer de 2026). SSRN 6307158.
Executant LLMs amb ús d'eines en producció i vols monitoratge que sigui realment estadísticament vàlid per a les dades que recull? Parla amb un CTO sobre desplegar capacitat d'enginyeria nearshore que pot construir seguretat certificable al runtime.
