El principi que dóna títol a aquest article és una lliçó d’enginyeria: en sistemes amb agents d’IA, demanar al model que raoni més no és suficient. Cal obligar el sistema a verificar cada acció abans que produeixi un efecte real. Durant els últims mesos, moltes empreses han començat a delegar tasques operatives en agents LLM. L’atractiu és evident: responen més ràpid, automatitzen processos i redueixen costos. Tanmateix, quan un agent pot escriure directament en una base de dades, una API o un sistema de gestió, cada decisió es converteix en un risc potencial. Una resposta lenta és un problema menor; una transició d’estat il·legal que ningú detecta és un incident greu.
El terme tècnic que descriu aquesta fallada és el d’estat incorrecte silenciós. L’eina rep una crida ben formada i l’executa, però la transició sol·licitada està prohibida per la política del negoci. Ningú llança una excepció perquè la sintaxi de la crida és correcta; el sistema informa d’èxit, tot i que el resultat final estigui fora de les regles. En un entorn aeronàutic, una operació prohibida pot ser una devolució no autoritzada, un canvi de dates sense permís o una aprovació registrada sense l’evidència necessària. L’usuari veu una confirmació, però l’empresa veu una dada corrupta.
El problema no és una anomalia d’un model concret. És una conseqüència estructural d’utilitzar models generatius per executar accions. Un LLM prediu text; les restriccions de negoci són un context que ha de conèixer, no una capacitat innata. Quan la política viu en un manual o en la configuració d’una sola eina, l’agent pot ignorar-la sense voler. Per això, dependre d’instruccions més detallades o de cadenes de raonament més llargues ofereix una millora limitada i poc reproduïble. La fiabilitat real exigeix una capa que no depengui de la probabilitat. Aquesta capa és fora del model: és a l’arquitectura.
Les comportes deterministes de preexecució són verificacions de només lectura que s’executen abans de permetre una escriptura. La crida proposada i l’estat actual es comparen amb un conjunt de regles invariants. Si la regla no es compleix, l’escriptura es bloqueja. No importa com de convincent sigui la resposta de l’agent ni com de ben formada estigui la petició tècnica; la decisió final la pren un mecanisme determinista. Aquesta és la diferència clau amb les mitigacions habituals, que solen ser probabilístiques o dependre del propi model. Aquí no hi ha terme mitjà: una comporta o permet la transició o la rebutja.
Les dades que donen suport a aquesta idea no són teòriques. En un entorn d’avaluació centrat en el domini aeronàutic, el 78% de les fallades observades en un agent econòmic eren estats incorrectes silenciosos, és a dir, no hi havia error d’eina, però l’operació acabava en un estat no permès. Després d’aplicar un conjunt de quatre comportes, l’èxit global va passar del 29,6% al 42,0%. El resultat es va repetir en un segon conjunt de llavors d’aleatorietat, cosa que confirma que la millora no era fruit de l’atzar. L’efecte es concentrava en les tasques on les comportes s’activaven; on no s’activaven, el canvi no era rellevant.
Per a una empresa, les implicacions van més enllà de la precisió del model. Un agent que diu completar una tasca sense haver-la completat correctament pot causar danys en l’operació, en el compliment normatiu i en la relació amb el client. A més, aquestes fallades són difícils de trobar perquè no apareixen als registres d’error. Només es descobreixen quan algú compara l’estat final amb el que hauria de ser. Per això, qualsevol projecte que desenvolupi agents d’IA en producció hauria d’incloure un mecanisme de control d’accions des del primer dia, no després d’un incident.
A Q2BSTUDIO, empresa de desenvolupament de programari i tecnologia, apliquem aquesta filosofia quan dissenyem arquitectures per a automatització intel·ligent. La combinació de serveis d’IA amb un backend ben estructurat fa que l’agent actuï dins d’un marc de regles, no fora d’ell. Les empreses que ja treballen amb aplicacions a mida tenen un avantatge clar: poden incorporar aquestes comportes al mateix lloc on s’executa la lògica de negoci, sense dependre d’un producte extern que no coneix els seus processos.
L’observabilitat és el complement natural. Cada vegada que una comporta bloqueja una operació, ha de quedar registrat un esdeveniment. Aquesta informació, tractada amb eines de BI i Power BI, es converteix en un quadre de comandament de confiança de l’agent que ajuda els equips a entendre quantes operacions s’han bloquejat, en quin departament, amb quin model i a quina hora. Així, la seguretat deixa de ser un fet binari i esdevé un procés gestionable.
La infraestructura també importa. Desplegar aquests sistemes en entorns cloud AWS/Azure facilita centralitzar les polítiques d’accés i escalar l’execució d’agents. La ciberseguretat aporta la capa final: si un atacant pot modificar les regles o manipular els esdeveniments, la protecció perd valor. Per això, les comportes no han de ser un afegit decoratiu, sinó part d’una estratègia de seguretat integral.
El títol d’aquest article pot semblar provocador. No es tracta d’abandonar el raonament dels models, sinó de posar-lo al seu lloc. Raonar ajuda a determinar què cal fer; verificar garanteix que el que es fa és admissible. En un món on els agents d’IA executen operacions de negoci reals, les empreses necessiten menys entusiasme per la propera resposta brillant i més mecanismes que impedeixin la fallada silenciosa. Les comportes deterministes no prometen un èxit perfecte, però ofereixen una cosa encara més valuosa: la certesa que certes accions prohibides no s’arribaran a executar mai.
