Seguretat d'IA certificable: portes de desplegament amb prova per als LLM que usen eines
Hi ha un mode de fallada específic dels LLM 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 veurà després. L'LLM emet una distribució de tokens. El sistema en mostreja. Algunes mostres invoquen eines. Les sortides de les eines tornen a entrar al context. La distribució de tokens següent està condicionada per aquestes sortides. Tot és adaptatiu, dependent, recursiu.
El monitoratge estadístic estàndard pressuposa observacions independents. La detecció de drift estàndard pressuposa una distribució de referència fixa. Les proves A/B estàndard pressuposen que el test no influeix en les dades. Cap d'aquests supòsits no es compleix per a un LLM que usa eines en producció. El comportament mateix de l'agent — i les respostes de les eines — canvia la distribució que el monitor observa. Vaig passar anys construint monitoratge per a sistemes en producció abans que arribessin els LLM, i cada pipeline d'alertes que vaig desplegar es recolzava com a mínim en un d'aquests supòsits.
El paper recent Certifiable AI Safety Theory (CAST): Convex-Analytic, Measure-Theoretic, and Proof-Carrying Deployment Gates for Tool-Using LLM Systems (Fradelos, febrer de 2026) aborda el problema de cara. La contribució és un marc matemàtic per certificar la seguretat exactament d'aquesta classe de sistemes, amb monitoratge estadístic anytime-valid (e-processos) dissenyat explícitament per a dades adaptatives i dependents.
La matemàtica és densa. El patró d'enginyeria és més accessible, i és la part que vull repassar aquí — perquè l'alternativa, fer veure que el problema de dependència no existeix, és el mode de fallada silenciós de bona part del monitoratge d'IA en producció actual.
Per què importa que cada acció porti la seva prova
La idea central: a cada punt de decisió — cada cop que l'agent vol executar una acció, invocar una eina, emetre una resposta — es construeix un certificat que demostra 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ó tira endavant. Si no ho és, el sistema o bé recorre a una sortida segura per defecte («dummy output») o bé projecta l'acció cap a una alternativa segura propera («convex repair»).
És la mateixa idea que el proof-carrying code del programari de sistemes: qui produeix una acció aporta un certificat que un verificador pot comprovar a baix cost. La confiança es desplaça de «el productor es comporta bé» a «el certificat és vàlid».
Per a sistemes d'IA, això és operativament important perquè:
- Verificar és més barat que reentrenar. Un cop fixat el format del certificat, la comprovació és ràpida. Reentrenar un model perquè sigui més segur és car i incert.
- El verificador mereix confiança al marge del model. En un verificador petit, simple i especificat formalment s'hi pot confiar amb un nivell de garantia més alt que en un model gran i opac.
- El fallback respon a un criteri, no a la improvisació. Quan el certificat falla, el sistema sap com fallar de manera segura: emet una sortida dummy o projecta cap a una alternativa segura.
Les dades adaptatives trenquen l'estadística estàndard
L'aposta tècnica central del paper és fer servir e-processos (un tipus concret d'acumulador d'evidència estadística basat en supermartingales) per al monitoratge. Els e-processos tenen una propietat que els p-valors convencionals no tenen: continuen sent vàlids amb aturada opcional (optional stopping) i recollida adaptativa de dades.
Dit planerament: amb els tests estadístics convencionals, la validesa del test depèn que t'hagis compromès per endavant amb quantes dades recolliràs i què contrastaràs. Si fas un cop d'ull a les dades i decideixes si continues recollint-ne segons el que hi has vist, has trencat les garanties del test. És el problema de l'«early stopping».
Per a un sistema d'IA en producció, l'early stopping no es pot evitar. Monitores contínuament, actuaràs a partir del monitoratge (alertes, throttling, bloquejos), i les teves accions afecten les dades que el monitor observa. Els tests estadístics convencionals et donen garanties que no s'aguanten en aquest règim.
Els e-processos sí que s'hi aguanten. Donen validesa uniforme en el temps: pots monitorar contínuament, aturar-te quan vulguis, i la garantia de falsos positius continua valent. Aquesta és la base matemàtica que fa possible el monitoratge continu de seguretat d'IA.
La implicació pràctica: si fas detecció de drift amb p-valors sobre un sistema d'IA en producció, estàs operant fora del règim de validesa del mètode estadístic. Encara no he vist cap stack de monitoratge en producció que ho tingui en compte, i és el tipus d'error que produeix alhora falsa confiança (mentre no esclata) i falses alarmes que ningú sap explicar (quan esclata).
El monitor necessita evidència que l'agent no pugui falsificar
El paper especifica una construcció canònica del monitor amb quatre components:
1. Logging fiable
Cada entrada, cada sortida del model, cada tool call i cada resposta d'eina queden registrats de manera que l'agent no els pot falsificar. El log és el substrat de tota la resta.
2. Aleatorietat privada del monitor
El monitor fa servir nombres aleatoris als quals l'agent no té accés. És la mateixa idea que mantenir en secret, davant de l'auditat, la llavor d'una auditoria basada en atzar. Impedeix que l'agent burli el monitor anticipant què 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 mai 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 impliquen resultats d'eines, el monitor pot reexecutar tool calls de manera determinista (o en un entorn aïllat) per verificar que la resposta era la que tocava.
Aquests quatre elements, junts, donen al monitor prou evidència independent per construir els certificats que el runtime necessita. Cap no és exòtic; tots quatre són a l'abast de qualsevol equip que es prengui seriosament el monitoratge. La contribució és especificar exactament què cal i per què.
Composició modular: per què importa
Un maldecap pràctic de la seguretat d'IA és la composició. Pots certificar que dos components són segurs per separat i acabar amb un sistema compost insegur. El cas clàssic: una eina que és segur de cridar un cop, cridada moltes vegades en successió ràpida, pot produir efectes agregats insegurs (denegació de servei contra un sistema situat més avall, escalada per crides repetides, etc.).
El paper aporta un teorema de composició modular: sota condicions concretes, els certificats de seguretat dels components componen un certificat de seguretat del sistema. Les condicions són reals i no trivials, però són explícites. Un equip que construeixi sistemes agèntics compostos pot comprovar-les i saber si la seva composició és al règim on la seguretat dels components implica la seguretat del sistema.
L'enquadrament honest importa. El paper ho etiqueta com «un primer règim composicional»: un punt de partida útil, no una teoria completa de la seguretat composicional. Els equips d'enginyeria ho haurien de tractar igual: útil per als casos que cobreix, cap garantia per als que no.
Segur a cada pas no vol dir segur en agregat
Una contribució subtil però important: un corol·lari que reparteix un pressupost global de risc entre els instants de decisió en temps d'execució. Això ataca el mode de fallada «segur per pas, insegur en agregat».
Cada punt de decisió té una probabilitat petita de produir una acció insegura. Sumada al llarg de milers o milions de decisions, la probabilitat agregada de produir-ne almenys una es torna gran. El paper proporciona una manera de repartir el pressupost global de risc al llarg del calendari de decisions perquè l'agregat quedi acotat.
A la pràctica, això vol dir fixar llindars de seguretat per acció en funció de quantes accions esperes que el sistema executi, amb un seguiment explícit del pressupost. Un sistema que executa un milió d'accions al dia i vol una probabilitat agregada d'acció insegura ≤1% necessita un llindar per acció molt més estricte que un que n'executa mil.
Aquesta és la mena de comptabilitat que la majoria de sistemes d'IA en producció no fan explícitament. Fixen un llindar per acció a ull i no verifiquen l'agregat. CAST dona el marc per fer-ho bé.
Convex repair: quan el certificat falla
Quan una acció no passa la certificació, hi ha dues opcions:
- Fallback dummy: emetre una sortida segura per defecte. Conservadora, simple, i sovint degrada l'experiència d'usuari.
- Convex repair: projectar la sortida insegura cap al punt més proper del conjunt segur. Exigeix que el conjunt segur sigui convex i que la projecció sigui tractable.
El paper aporta teoremes de projecció cap a la seguretat en geometries KL/Bregman i de transport òptim, amb una via de tractabilitat explícita per a la reparació basada en transport. La matemàtica diu: sota condicions concretes, pots calcular una acció tan a prop com sigui possible de l'acció insegura original sense sortir del conjunt segur.
La lliçó d'enginyeria: quan dissenyis el conjunt segur, fes-lo convex. Els conjunts segurs convexos admeten projecció en temps polinòmic; els no convexos, en general, no. És una decisió de disseny que prens en especificar la política de seguretat, i determina si el convex repair és tan sols una opció.
Què implica per als equips d'IA en producció
Tres coses que posaria en marxa a qualsevol equip que tingui sistemes LLM amb eines en producció:
1. Verifica la metodologia de monitoratge
Si la teva detecció de drift o el teu monitoratge de seguretat fan servir mètodes estàndard basats en p-valors sobre dades recollides adaptativament, les garanties estadístiques no s'aguanten. O passes a un monitoratge basat en e-processos (la resposta correcta) o deixes explícit que el teu monitoratge és heurístic i no estadísticament rigorós (una resposta provisional defensable).
2. Especifica el conjunt segur explícitament
La frase «el model és segur» no té un significat precís. «Les sortides pertanyen al conjunt S», sí. Especifica S en codi o en una descripció formal. Llavors pots verificar la pertinença, projectar-hi les fallades i raonar sobre la composició.
3. Comptabilitza el risc global
Si el teu sistema executa moltes accions, fixa els llindars per acció a partir del pressupost de risc agregat, no de la intuïció per acció. La matemàtica no és difícil un cop has decidit el pressupost; la disciplina és decidir-se a fer-ho.
On CAST no s'aplica
El paper és explícit amb l'abast: no és una teoria de robòtica, no pressuposa cap superintel·ligència i es posiciona com a «contenció i certificació de nivell financer / de computació científica». És per a lleis de seguretat especificades explícitament sobre sistemes LLM que usen eines.
Aquest és el règim on viu la major part del desplegament d'IA en producció el 2026. CAST apunta bé al problema pràctic. Els equips que posen en producció agents basats en LLM que toquen eines reals — el gruix de la IA agèntica en producció — haurien de llegir aquest paper i adaptar-ne els patrons.
L'alternativa és un monitoratge matemàticament erroni per a les dades que processa. I aquesta és la mena d'error que produeix incidents que ningú no sap explicar a posteriori.
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.
Tens LLM amb eines en producció i vols un monitoratge que sigui de debò estadísticament vàlid per a les dades que reculls? Parla amb un CTO sobre desplegar capacitat d'enginyeria nearshore capaç d'incorporar seguretat certificable al runtime.
