L' observabilitat en sistemes tradicionals ha estat associada gairebé exclusivament al monitoratge d' infraestructures, temps de resposta i taxes d' error. Tanmateix, quan parlem d'agents IA —sistemes autònoms que raonen, decideixen i executen accions— el paradigma canvia per complet. Un agent pot executar una trucada a una API sense errors, retornar dades vàlides i, tot i així, prendre una decisió equivocada que passi desapercebuda per a tots els dashboards. La veritable fallada no està en el 'què' sinó en el 'per què'.
En els últims anys, moltes organitzacions han començat a implementar agents IA per a tasques com la classificació de tiquets, la moderació de contingut o l'automatització de processos interns. Equips de desenvolupament reporten mètriques impecables: latències baixes, cap excepció, èxit del 99,8% en les eines invocades. Però després descobreixen que, durant setmanes, l'agent ha estat escalant problemes trivials com si fossin crítics perquè va interpretar malament una paraula clau. Això no genera un crash; genera una decisió silenciosament incorrecta que no apareix en cap log d'infraestructura. La lliçó és clara: l'observabilitat d'agents IA exigeix mirar més enllà de les trucades a eines i centrar-se en la capa de raonament.
El repte d' instrumentar la decisió, no només l' execució
La traçabilitat distribuïda tradicional, com la que ofereix OpenTelemetry, es va dissenyar per rastrejar peticions a través de serveis: quin servei va cridar a quin, quant va tardar, on hi va haver latència. En un agent, aquesta mateixa lògica només captura quines eines es van invocar i en quin ordre. Però el raonament que porta a triar una eina en lloc d'una altra passa dins del context del model, no a través d'un límit de servei. Per això, els instruments clàssics no tenen on fixar-se. El resultat és una traça completa en les parts que no importen i buida en la qual sí que importa. Grups de treball com el de GenAI observability dins d'OpenTelemetry porten més d'un any construint convencions semàntiques per a agents, desenvolupant spans d'agent, esdeveniments de decisió i mètriques d'orquestració que abans no existien. Empreses com Datadog, Honeycomb i New Relic ja estan implementant aquestes extensions. És una admissió estructural que el model de traçat tradicional es queda curt.
El cost de no capturar el raonament
Quan un equip confia únicament en logs de trucades a eines i mètriques d'infraestructura, perd la capacitat de respondre a la pregunta més important en una revisió post-incident: per què l'agent va prendre aquesta decisió? Sense un registre del context que el model va veure abans d'actuar —les instruccions del prompt, la informació de l'usuari, l'historial de la conversa— no hi ha forma de reproduir o entendre la decisió. Alguns equips eviten guardar el raonament complet perquè és verbós i car d'emmagatzemar. Però aquesta decisió d'estalvi acaba costant molt més quan un incident crític no es pot explicar.
Una estratègia pragmàtica consisteix a aplicar registre complet en qualsevol acció irreversible: pagaments, escalats, escriptures en registres de clients. Per a la resta de decisions, es pot aplicar mostreig. La regla és simple: necessitaràs aquest registre exactament una vegada per incident, i no sabràs quina execució és la rellevant fins després que passi. Una escalada que no pots explicar és una escalada que no pots defensar en una postmortem. Per això, en projectes de ia per a empreses que desenvolupem en Q2BSTUDIO, recomanem des del disseny una estratègia de logging per capes que diferenciï entre accions crítiques i consultes rutinàries. No és només una qüestió tècnica; és una decisió de governança que afecta directament la qualitat del servei i la capacitat de millora contínua.
De la vella certesa a la nova incertesa
Depurar un sistema determinista implicava llegir codi, trobar el condicional que prenia la branca incorrecta i corregir la lògica. Era tediós però predictible. Amb els agents IA, el raonament és no determinista, depèn del context i no es reprodueix dues vegades igual si s' executa de nou. Aquesta pèrdua de certesa és real i no s'ha d'ignorar. Els qui intenten debugir agents amb eines dissenyades per a la vella certesa se sorprenen una i altra vegada quan no funciona. La solució no és evitar els agents, sinó adaptar les pràctiques d'observabilitat. Això implica registrar transcripcions completes, capturar la finestra de context en els punts de decisió i mostrejar les traces de raonament com es mostregen les dades de profiling.
Revisió periòdica: l' hàbit que marca la diferència
Registrar traces de raonament no serveix de res si ningú les revisa fins que alguna cosa es trenca. En Q2BSTUDIO, quan ajudem els nostres clients a implementar aplicacions a mida amb components d'intel·ligència artificial, sempre incloem la creació d'una rutina lleugera de revisió de mostres dins del cicle de guàrdia. No perquè cada mostra reveli un error, sinó perquè la pràctica de mirar regularment és el que atrapa un calibratge incorrecta abans que es converteixi en un patró de múltiples escalades errònies. És un treball poc glamurós, més proper a la revisió de codi que a un dashboard de monitoratge. Però és l'única manera de detectar el que les mètriques no mesuren. La recomanació és programar aquesta revisió amb la mateixa disciplina amb què es revisen els logs de consultes lentes. No després d'un incident. Abans.
La intersecció amb altres àrees crítiques
L'observabilitat d'agents IA no és un tema aïllat. S'entrellaça directament amb la ciberseguretat (com saber si un agent ha estat manipulat mitjançant injecció de prompt?), amb els serveis cloud aws i azure (escalat i emmagatzematge de traces) i amb els serveis intel·ligència de negoci com Power BI per visualitzar patrons de decisió. A més, les empreses que treballen amb programari a mida necessiten integrar aquests mecanismes des de la fase de disseny, no com un afegit posterior. Les decisions d' arquitectura de dades, cost d' emmagatzematge i retenció de logs s' han de planificar juntament amb el desenvolupament del propi agent. Perquè un agent ben construït però mal observat és, en el fons, un risc per a l'operació.
Conclusió: el que no es mesura no es millora
La majoria dels agents IA que s'executen avui a les empreses passen totes les mètriques amb què se'ls mesura, i aquest és precisament el problema. Aquestes mètriques van ser dissenyades per a sistemes que fallen llançant errors, i els agents rarament fallen així. La solució no és un dashboard més bonic, sinó acceptar que les fallades interessants viuen una capa per sota del que l'eina actual pot veure. Implica construir l'hàbit deliberat de registrar a la capa de decisió i revisar abans que un incident t'obligui a fer-ho. Registra l'eina invocada, sí. Però registra primer la decisió. Aquesta és la capa que et diu si l'agent realment va fer el correcte o només va fer alguna cosa de manera neta.
En Q2BSTUDIO, entenem que la intel·ligència artificial no es desplega com un producte tancat, sinó com un sistema que requereix observabilitat contínua, ajust fi i governança. Per això oferim serveis de consultoria i desenvolupament que integren des de l'inici estratègies de traçat semàntic, mostreig intel·ligent, i revisió periòdica. Perquè sabem que la diferència entre un agent que funciona i un que realment aporta valor està en els detalls que les mètriques tradicionals no capturen.
