Agents IA en producció: el gap de qualitat que ningú mesura (i com tancar-lo)

El teu equip ha desplegat un agent IA en producció. Els dashboards estan verds: la latència és baixa, els tokens estan dins del pressupost, els traces s'emmagatzemen correctament, l'uptime és 99.9%. Tot sembla funcionar. Fins que un client escriu al canal de suport: "la resposta que em va donar el vostre assistent era completament incorrecta". I aleshores descobreixes que fa setmanes que serveixes respostes mediocres sense que cap alerta saltés.

Aquest és el gap de qualitat en agents IA enterprise. I és molt més comú del que la majoria de CTOs creu.

Observabilitat no és qualitat

Les dades recents pinten una imatge incòmoda. El 89% dels equips que despleguen agents IA en producció tenen alguna forma d'observabilitat: veuen traces, mesuren latència, compten tokens, controlen costos. És l'equivalent a monitoritzar que un servidor respon — necessari, però insuficient.

Només el 52% d'aquests equips avalua activament la qualitat de les respostes que els seus agents generen. I la qualitat continua sent la barrera número 1 en producció per al 32% dels equips — per davant de la latència, el cost o la integració tècnica.

La raó d'aquesta bretxa és estructural: les eines d'observabilitat clàssiques (Langfuse, LangSmith, Helicone, Datadog) estan dissenyades per respondre "l'agent es va executar?". Cap respon de forma nativa i automàtica a la pregunta que realment importa: "la resposta va ser bona?".

La dada incòmoda: en la majoria de desplegaments enterprise, els problemes de qualitat es descobreixen quan un usuari es queixa, no quan una alerta salta. El feedback negatiu d'un client arriba dies o setmanes després que l'agent comencés a degradar-se. Per aleshores, centenars o milers de converses ja han servit respostes deficients.

Les 6 dimensions de qualitat que importen en enterprise

Avaluar qualitat en un agent IA no és posar una nota de l'1 al 10 a cada resposta. És mesurar múltiples dimensions que, juntes, determinen si la resposta genera valor real per a l'usuari o si genera risc per a l'organització. Aquestes són les sis que un CTO hauria d'exigir abans d'anar a producció:

1. Rellevància. La resposta contesta la pregunta que l'usuari va fer? Un agent pot generar text perfecte que no té res a veure amb el que se li va preguntar. La rellevància mesura aquesta alineació.
2. Utilitat. La resposta aporta valor concret? Una resposta pot ser rellevant i alhora buida: "depèn del context" és rellevant però no útil. La utilitat mesura si l'usuari pot actuar sobre la resposta.
3. Completesa. Falten detalls importants? Una resposta que encerta però omet un matís crític pot ser pitjor que no respondre. La completesa detecta aquestes omissions.
4. Coherència. La lògica és fàcil de seguir? En respostes llargues o multi-pas, la coherència mesura si l'argumentació té sentit de principi a fi, sense contradiccions internes.
5. Seguretat. Existeix risc legal o reputacional? Aquesta és la dimensió que més preocupa els equips legals i de compliance. Una sola resposta que recomani alguna cosa il·legal, discriminatòria o factualment perillosa pot tenir conseqüències desproporcionades. En el context de l'EU AI Act, que s'aplica des d'agost de 2025, aquesta dimensió passa de "nice to have" a "obligatòria".
6. Puntuació general. Un score consolidat (0-10) que pondera les cinc dimensions anteriors i permet respondre d'un cop d'ull: l'agent està funcionant bé o no?

Aquestes sis dimensions no són teòriques. Són les que equips en producció estan mesurant avui per prendre decisions operatives: desplego aquesta nova versió del prompt? Canvio de model? Necessito intervenir manualment? Sense elles, cadascuna d'aquestes decisions es pren a cegues.

El patró LLM-as-judge: avaluació automàtica sense datasets

La forma més escalable d'avaluar qualitat en producció és un patró que s'ha consolidat els últims 12 mesos: LLM-as-judge. La idea és simple: un segon LLM, independent del que genera les respostes, avalua cada conversa contra les dimensions de qualitat definides. No necessita datasets manuals, no necessita avaluadors humans per a cada resposta, i escala a milers de converses diàries sense esforç operatiu.

L'LLM avaluador rep la conversa completa (pregunta de l'usuari + resposta de l'agent + context) i produeix un score per dimensió. Si el score de seguretat baixa d'un llindar (per exemple, 3 sobre 10), una alerta es dispara automàticament. Si el score general es degrada consistentment durant 24 hores, l'equip rep una notificació abans que cap usuari es queixi.

El que és crític és que l'avaluació passa de forma asíncrona: l'usuari rep la seva resposta sense cap retard addicional. L'LLM-as-judge treballa en segon pla, i les alertes arriben a l'equip en temps real. Zero impacte en latència, visibilitat total de la qualitat.

Sentygent: quality monitoring automàtic per a agents en producció

Sentygent és una plataforma de monitoratge de qualitat per a agents IA que implementa exactament aquest patró. Un LLM-as-judge independent avalua automàticament cada conversa en les sis dimensions de qualitat — sense configuració manual, sense datasets, sense revisió humana per defecte.

La integració requereix cinc línies de codi (un wrapper sobre el client de l'LLM provider que ja facis servir) i l'avaluació passa de forma asíncrona — l'usuari mai experimenta latència addicional. Això la converteix en una eina que es pot afegir a un agent ja desplegat sense tocar la lògica del sistema.

El que aporta a un equip enterprise

• Alertes automàtiques de seguretat. Si el score de seguretat de qualsevol conversa baixa d'un llindar (per defecte 3/10), Sentygent dispara una alerta via webhook immediatament. Per a un CTO, això significa que els problemes de seguretat es detecten en minuts, no en dies.
• Dashboards de qualitat en temps real. Scores per dimensió, tendències horàries, filtratge per tags (model, versió del prompt, tipus d'intent). L'equip pot veure d'un cop d'ull si una nova versió de l'agent va millorar o empitjorar la qualitat.
• Traçabilitat multi-agent. En arquitectures amb diversos agents orquestrats (cada cop més comunes en enterprise), Sentygent mostra el cost i la qualitat desglossats per agent individual. Això permet saber exactament quin dels agents del pipeline està degradant la resposta final.
• RAG natiu. Les operacions de retrieval es capturen amb detall: chunks recuperats, scores de rellevància individuals, fonts. Si la qualitat cau perquè el retriever està portant documents irrellevants, es veu directament al trace.
• Zero fricció d'integració. Compatible amb Anthropic, AWS Bedrock, OpenAI, Cohere, Mistral, Groq, Ollama i Vercel AI SDK. La instrumentació no requereix refactoritzar el codi existent — s'embolcalla el client de l'LLM provider i el SDK captura tot automàticament.

Per a un equip que ja té observabilitat però no quality monitoring, Sentygent tanca exactament aquest gap: passa de "sé que l'agent va respondre" a "sé que l'agent va respondre bé, i si no, me n'assabento abans que l'usuari".

Com connectar qualitat en producció amb qualitat en desenvolupament

Aquí és on la conversa es posa interessant per a un CTO que pensa en sistemes, no en eines aïllades.

El quality monitoring en producció detecta problemes. Però els problemes s'originen en desenvolupament — en un prompt mal dissenyat, en un context insuficient, en una especificació ambigua. Si l'equip de desenvolupament treballa amb Spec-Driven Development, les especificacions defineixen els criteris d'acceptació de cada feature. Aquests mateixos criteris poden alimentar el quality monitoring en producció.

El flux complet es veu així:

1. En desenvolupament, l'equip especifica què ha de fer l'agent: quines preguntes ha de respondre, amb quin nivell de completesa, quines restriccions de seguretat apliquen. Això és una spec.
2. Al deploy, el codi de l'agent s'instrumenta amb Sentygent (5 línies, sense refactor).
3. En producció, Sentygent avalua automàticament cada resposta contra les 6 dimensions. Si la qualitat es degrada, l'alerta arriba a l'equip.
4. En la iteració, l'equip compara els scores de qualitat amb les specs originals i decideix si el problema és del prompt, del model, del context o de la spec mateixa.

Aquest cicle — spec → deploy → monitor → iterate — és el que converteix un agent IA en un sistema enterprise real. Sense el monitoring de qualitat, el cicle es trenca al tercer pas i l'equip vola a cegues.

Connexió pràctica. A onext, els equips que fan servir onext AI-Accelerated Development defineixen les regles de qualitat a la constitució del projecte (el que l'agent ha de fer i el que no). Eines com Sentygent permeten tancar el bucle verificant en producció que aquestes regles es compleixen conversa a conversa. La spec diu "l'agent mai ha de recomanar medicaments"; Sentygent detecta la primera vegada que ho fa abans que cap usuari ho escali.

Què hauria d'exigir un CTO abans d'anar a producció

Basat en el que veiem en els equips que passen de pilot a producció enterprise amb èxit, aquestes són les cinc condicions mínimes que un CTO hauria de verificar abans de donar llum verda:

1. Quality monitoring actiu en les 6 dimensions. No només observabilitat. Si no pots respondre "quina va ser la qualitat mitjana de les respostes de l'agent aquesta setmana?", no estàs preparat per a producció.
2. Alertes automàtiques de seguretat. Si el score de seguretat baixa d'un llindar, l'equip se n'assabenta en minuts. No en dies ni quan un client es queixa.
3. Traçabilitat de cost per conversa i per agent. En arquitectures multi-agent, saber quant costa cada resposta és fonamental per controlar el pressupost. Si un agent del pipeline està consumint el 80% del cost però aportant el 10% del valor, cal saber-ho.
4. Un flux d'iteració definit. Quan la qualitat es degrada, qui actua? Què es revisa primer? Es canvia el prompt, el model, el context o la spec? Sense un protocol clar, les alertes de qualitat es converteixen en soroll.
5. Especificacions escrites de què ha de fer i què no ha de fer l'agent. Si l'única font de veritat sobre el comportament esperat de l'agent és la memòria del developer que el va construir, l'avaluació de qualitat no té referència contra la qual comparar.

Conclusió: la qualitat és el nou uptime

Durant els últims 20 anys, la indústria del programari va construir una obsessió saludable per l'uptime. Avui ningú desplega un servei sense alertes de disponibilitat, dashboards de latència i runbooks d'incidents. Aquesta infraestructura va trigar una dècada a madurar, però avui és estàndard.

Amb els agents IA, la qualitat és el nou uptime. Un agent que està disponible però respon malament és pitjor que un agent caigut — perquè el dany és silenciós, acumulatiu i difícil de revertir un cop l'usuari perd la confiança. La infraestructura de quality monitoring està on la infraestructura d'uptime estava el 2010: existeix, funciona, però la majoria d'equips encara no l'ha adoptada.

Els equips que l'adoptin avui — amb eines com Sentygent per al monitoring automàtic i amb SDD per a les especificacions en desenvolupament — tindran l'avantatge de detectar problemes abans que els seus usuaris, iterar amb dades reals i construir la confiança que separa un pilot d'un producte enterprise.

Observar tokens és necessari.
Avaluar qualitat és el que separa els agents que funcionen dels que funcionen bé.

Escrit per

Jordi García

Tech Lead a onext

Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.

LinkedIn →