La base de coneixement del teu agent d'IA: què donar-li a llegir i com mantenir-la viva
Blog
Tornar al blog
·10 min min de lectura·base de coneixementdocumentació de l'agentagent d'IAqualitat de dadesatenció al clientoperacions B2Bsense codipimes

La base de coneixement del teu agent d'IA: què donar-li a llegir i com mantenir-la viva

P
Pere Mesquida
BeeAgent Team

L'agent respon en dos segons, amb un to impecable i total seguretat: «Els pressupostos tenen una validesa de 30 dies». El client tanca la trucada satisfet. El problema és que aquesta política va canviar al març —ara són 15— i el document que l'agent va llegir és el PDF de la tarifa anterior, que algú va pujar el primer dia i ningú no va tornar a mirar. No ha fallat el model, ni el guió, ni l'escalat: ha fallat la biblioteca.

Quan es prepara un primer agent, gairebé tota l'atenció se'n va cap al que és visible: el guió i el to, els límits i l'escalat, la presentació a l'equip. La base de coneixement —els documents que l'agent llegeix per respondre— sol resoldre's en una tarda: s'ajunta el que hi ha, es puja i a una altra cosa. I tanmateix és la peça que decideix, cada dia i en cada conversa, si l'agent diu la veritat.

Aquest article va d'aquesta peça: què donar-li a llegir a un agent operatiu, què no donar-li mai, com organitzar la informació perquè no es contradigui i —la part que gairebé ningú no planifica— com mantenir-la viva quan el negoci canvia, que és sempre.

L'agent respon tan bé com el que ha llegit

Un agent operatiu no s'inventa l'horari de la teva empresa ni el termini de les teves devolucions: els llegeix de la documentació que li has donat. Aquesta és la bona notícia —controles el que sap— i també la responsabilitat: la qualitat de les seves respostes té un sostre, i aquest sostre és la teva documentació.

Convé entendre les dues maneres diferents com això falla. La primera és sorollosa i benigna: l'agent no troba la resposta, diu que no ho sap i escala a una persona. Molesta, però no enganya ningú, i a més deixa rastre: cada escalat per manca d'informació és un avís de quin document falta. La segona és silenciosa i cara: l'agent troba una resposta —la del document vell, la del PDF que contradiu el web— i la dona amb total convicció. El client no té manera de sospitar-ho, l'equip no ho veu perquè el cas es va resoldre "bé", i l'error només aflora quan algú reclama.

D'aquesta asimetria en surt el principi que ordena tota la resta: és millor un agent que sap menys i escala més que un que sap molt de fonts dubtoses. Una base petita, correcta i mantinguda guanya sempre a una base gran que ningú no vigila.

Què donar-li a llegir (i què no)

La temptació del primer dia és abocar-ho tot: el manual d'acollida, el catàleg complet, el web exportat, tres anys de circulars. És un error amb forma de drecera. El que un agent operatiu necessita cap en quatre categories:

  • Les preguntes reals amb la seva resposta correcta. No les FAQ que algú es va imaginar en una reunió: les preguntes que de veritat arriben per telèfon i correu. La millor font és la teva pròpia safata compartida: les vint o trenta consultes més repetides de l'últim trimestre, amb la resposta que avui és correcta, valen més que qualsevol manual.
  • Les dades operatives estables. Horaris, adreces, formes de pagament i de contacte, terminis estàndard, condicions de servei. Canvien poc, es pregunten molt i són el terreny on l'agent brilla des del primer dia.
  • Les polítiques que s'apliquen tal qual. Devolucions, cancel·lacions, garanties, requisits d'un tràmit. Si la política té excepcions que depenen del criteri d'una persona, la política entra a la base i l'excepció entra a les regles d'escalat, no a l'inrevés.
  • Les frases que no es poden parafrasejar. L'avís legal, la menció de gravació, la presentació de l'agent. Es marquen com a literals, igual que es fa en fixar el guió de veu.

Igual d'important és la llista del que no hi entra:

  • Documents duplicats o obsolets. Si conviuen la tarifa de 2025 i la de 2026, l'agent pot citar qualsevol de les dues. Abans de pujar, es neteja: una versió per document, la vigent.
  • Criteris interns que no han d'arribar al client. Marges, descomptes màxims, notes del tipus "als clients grans se'ls concedeix". L'agent conversa amb clients; el que no diries en veu alta davant d'un, no li ho dones a llegir.
  • Dades personals que no necessita. La base de coneixement és documentació general, no un arxiu d'expedients. Les dades de cada client viatgen en cada cas concret, amb la seva pròpia lògica d'accés, no a la biblioteca comuna.
  • Tot allò que ningú no mantindrà. Aquesta és la criba més dura i la més útil. Cada document és un compromís: algú l'haurà d'actualitzar quan canviï la realitat. Si la resposta honesta és "ningú", és millor deixar aquesta pregunta fora de l'abast i que l'agent l'escali.

Una sola font de veritat per a cada dada

La fallada més comuna de les bases de coneixement no és la manca d'informació: és la contradicció. L'horari apareix al web, al peu dels correus i en un PDF de condicions, i les tres versions van ser certes en algun moment —però només una ho és avui—. Una persona resol l'ambigüitat amb context ("el PDF és vell, fes cas al web"); un agent no té per què triar igual, i el que és greu és que triarà amb seguretat.

La regla és d'higiene, no de tecnologia: cada dada viu en un sol lloc. Una tarifa, un document de tarifes. Un horari, una fitxa d'horaris. Quan canvia, es canvia allà, i només allà. Si la mateixa dada ha d'aparèixer en diversos documents per raons de context, un d'ells és el mestre i els altres hi remeten en lloc de repetir la xifra.

I hi ha una segona regla per a les dades que canvien cada dia: el que es copia envelleix; el que es consulta, no. L'estat d'una comanda, el saldo d'un compte, els forats de l'agenda no s'escriuen en cap document: l'agent els consulta al sistema corresponent en el moment de la conversa, com fa quan atén trucades fora d'horari i comprova l'estat d'un tràmit. La base de coneixement guarda el que és cert durant setmanes; el que és cert durant hores es consulta en viu.

La informació amb data de caducitat

Entre l'estable i el viu hi ha una franja traïdora: la informació que és certa fins a una data. La promoció de setembre, l'horari d'agost, el termini especial de la campanya de la renda. És la que produeix els errors més visibles, perquè caduca en silenci: ningú no recorda el document fins que l'agent ofereix a l'octubre el descompte que va acabar el 30 de setembre.

El tractament té tres parts. Primer, etiquetar la caducitat en crear el document, no confiar-la a la memòria: tota peça temporal porta la seva data de fi visible. Segon, revisar al venciment: la data de caducitat és una cita al calendari del responsable, i aquell dia el document s'actualitza o es retira —no es deixa "per si de cas"—. Tercer, preferir la retirada a l'acumulació: una base on conviuen cinc promocions passades "per context" és una fàbrica de contradiccions.

La versió operativa d'aquesta idea és simple i s'assembla al que ja fas amb el teu web: cada canvi del negoci que afecti el que l'agent diu ha d'incloure "actualitzar l'agent" a la seva checklist. Si pugen les tarifes, el dia que es publica la tarifa nova s'actualitza el document de l'agent. Si l'horari d'estiu comença al juliol, el document entra al juny amb la seva caducitat posada. L'agent deixa de ser un projecte a part i passa a ser un canal més que es manté, exactament igual que el web o la centraleta.

Mantenir-la viva: el cicle de correccions

Una base de coneixement no s'acaba: es cultiva. I el material de cultiu són les mateixes converses de l'agent, que assenyalen cada setmana on és el següent forat. El cicle té tres fonts i un sol responsable.

La primera font són els escalats per manca d'informació. Quan l'agent transfereix un cas perquè no sabia la resposta, deixa una dada valuosa: una pregunta real que la base no cobreix. Revisar aquests casos setmanalment converteix els forats en documents, començant pels que més es repeteixen.

La segona són les correccions de l'equip. Quan algú revisa un esborrany de l'agent i el corregeix, o detecta una resposta equivocada en una transcripció, aquesta correcció ha d'arribar a la base —no quedar-se en el cas concret—. Aquest és el circuit que descrivim en parlar de l'adopció per part de l'equip: un equip que veu les seves correccions aplicades en dies alimenta l'agent; un que les veu morir en una bústia deixa de proposar-les.

La tercera són els canvis del negoci, que arriben per la checklist de l'apartat anterior en lloc de per sorpresa.

El responsable és el propietari de l'agent: una persona concreta d'operacions que decideix què hi entra, retira el que caduca i aplica les correccions. No és un rol tècnic ni una dedicació completa: estabilitzat el flux, la revisió setmanal —converses marcades, escalats per manca d'informació, documents a punt de caducar— sol cabre en una hora. El que no funciona és repartir-la entre tots: una biblioteca de la qual tothom és responsable acaba exactament igual que un arxiu compartit del qual tothom és responsable.

Senyals que la base s'ha quedat vella

Cap base de coneixement no avisa que ha caducat; cal llegir els senyals indirectes, i convé saber quins són abans de necessitar-los:

  • Seguretat sense veritat. L'agent respon amb total convicció coses que ja no són certes. És el senyal més perillós perquè no sembla un error: es detecta llegint transcripcions a l'atzar o creuant les respostes amb la realitat actual, no esperant queixes.
  • Escalats que pugen en una intenció concreta. Si una pregunta que l'agent resolia sol comença a escalar més, alguna cosa ha canviat en la realitat que el seu document no recull.
  • Clients que corregeixen l'agent. "Doncs al web hi posa una altra cosa", "això em van dir el mes passat i era diferent". Cada aparició d'aquesta frase en una transcripció és un document contradictori o caducat amb nom i cognoms.
  • L'equip torna a respondre a mà. Quan els qui revisen deixen de refiar-se dels esborranys de l'agent i reescriuen des de zero, la desconfiança gairebé sempre apunta a informació vella, i és el primer pas del veto silenciós que ja coneixes.

La resposta a qualsevol dels quatre és la mateixa: anar als documents d'aquesta intenció, comparar-los amb la realitat d'avui i corregir o retirar. És una feina de biblioteca, no de tecnologia.

El següent nivell: integració en temps real

Tot l'anterior funciona amb una base documental: la biblioteca que guarda el que és cert durant setmanes. El següent nivell és connectar l'agent als sistemes on viu la resta: el CRM, el programa de gestió, l'agenda, l'eina de tiquets. Un agent integrat no respon des d'una còpia: consulta la fitxa del client en el moment de la trucada, veu si la factura està pagada o la comanda enviada, comprova els forats reals de l'agenda abans de proposar hora. I funciona en les dues direccions: a més de llegir, escriu —registra la trucada a la fitxa del client, actualitza l'estat del cas, crea la tasca de seguiment per al comercial—.

L'efecte sobre la base de coneixement és doble. Primer, s'encongeix: cada dada que l'agent consulta en viu és un document que desapareix de la llista de manteniment, i el risc de respondre amb una còpia caducada desapareix amb ell. Segon, les respostes pugen de categoria: de "el termini de lliurament habitual és de cinc dies" a "la teva comanda va sortir ahir i arriba demà". La primera la pot donar qualsevol web; la segona és la que fa que el client no necessiti demanar una persona.

No cal integrar-ho tot el primer dia: el patró sa és arrencar amb la base documental i connectar el primer sistema quan el flux ja funciona, començant pel que més preguntes concentra —el CRM si el que arriba és comercial, l'agenda si són cites, el gestor d'expedients si és estat de tràmits—. I com que cada operació fa servir eines diferents, aquesta part no ve en caixa: si estàs pensant en un flux concret amb el teu CRM o el teu programa de gestió, escriu-nos i el muntem amb tu —ens adaptem als sistemes que ja fas servir, no al revés—.

Com hi encaixa BeeAgent

A BeeAgent, la base de coneixement la gestiona la mateixa persona que gestiona la resta de l'agent: l'equip d'operacions, sense codi i sense tiquets a desenvolupament. Pujar un document nou, substituir una tarifa o retirar una promoció caducada són operacions de minuts, cosa que fa viable el cicle setmanal de correccions —la diferència entre mantenir la base viva i prometre que es mantindrà—.

La traçabilitat tanca el circuit: cada conversa queda registrada, de manera que el propietari de l'agent pot llegir les transcripcions de la setmana, localitzar els escalats per manca d'informació i veure exactament què va respondre l'agent i d'on va sortir la resposta. I per a les dades vives, l'agent consulta els sistemes connectats en el moment de la conversa —estat d'un expedient, forats d'agenda—, de manera que la biblioteca guarda només el que ha de guardar: la informació que és certa durant setmanes, no la que canvia cada hora.

Comença per la biblioteca aquesta setmana

Si estàs preparant el teu primer agent —o si el que tens ja ha donat alguna resposta caducada—, l'ordre que funciona és aquest. Primer, les trenta preguntes reals: treu-les del correu i de les trucades de l'últim trimestre, amb la resposta correcta a dia d'avui. Segon, la criba del que no hi entra: duplicats fora, versions velles fora, criteris interns fora, i fora també tot allò que ningú no mantindrà. Tercer, un sol lloc per dada: si un horari o una tarifa viuen en tres documents, tria el mestre i retira els altres. Quart, dates de caducitat: tota peça temporal, etiquetada i amb la seva revisió al calendari. I cinquè, el propietari i la seva hora setmanal: una persona, un cicle curt, correccions aplicades en dies.

Amb això, l'agent té el que necessita per dir la veritat avui i un mecanisme per continuar dient-la quan el negoci canviï demà.

Conclusió

La conversa sobre agents d'IA sol girar al voltant del model: quin entén millor, quin sona més natural. Però en l'operació diària, la diferència entre un agent fiable i un que cal vigilar gairebé mai no és al model: és a la biblioteca que llegeix. Quins documents té, si es contradiuen, qui els manté i quant triguen a reflectir un canvi del negoci. Aquesta biblioteca no es construeix una vegada: es cultiva cada setmana, i el cost de cultivar-la és una fracció del cost de les respostes equivocades que evita.

Si vols veure com es tradueix això en un flux concret, als casos d'ús tens exemples reals —de l'atenció al client al triatge de correu— o escriu-nos i muntem amb tu aquesta primera base de trenta preguntes.

Preguntes freqüents

Quina documentació necessita un agent d'IA per començar a treballar?
Menys de la que sembla, però més ben triada: les respostes a les preguntes que el negoci rep de veritat (tretes de correus i trucades reals, no d'un brainstorming), les dades operatives que canvien poc (horaris, adreces, terminis, condicions), les polítiques que l'agent ha d'aplicar tal qual i les frases fixes que no pot parafrasejar. Un bon punt de partida són vint o trenta preguntes reals amb la seva resposta correcta i actual, abans que un manual corporatiu de cent pàgines.
Quina informació no convé donar-li a un agent d'IA?
Documents obsolets o duplicats (si conviuen dues versions d'una tarifa, l'agent pot citar qualsevol), criteris interns que no han d'arribar al client (marges, excepcions que es concedeixen 'segons qui truqui'), dades personals que no necessita per a la seva tasca i tot allò que ningú no mantindrà. Cada document que entra a la base és un compromís de manteniment; si ningú no l'actualitzarà, és millor que l'agent escali aquesta pregunta que no pas que la respongui amb una versió vella.
Com s'evita que un agent d'IA doni informació desactualitzada?
Amb tres pràctiques: una sola font de veritat per a cada dada (una tarifa viu en un sol lloc, no en tres PDF), data de caducitat explícita per a la informació temporal (promocions, horaris d'estiu, terminis de campanya) amb revisió obligatòria en vèncer, i connexió a sistemes vius per a les dades que canvien cada dia —l'estat d'una comanda es consulta al sistema, no es copia en un document—. El que es copia envelleix; el que es consulta, no.
Qui ha de mantenir la base de coneixement de l'agent?
Una persona concreta d'operacions —el propietari de l'agent—, no 'l'equip' en general ni IT. És qui decideix què hi entra, retira el que caduca i aplica les correccions que l'equip proposa. La feina real és modesta si es fa en cicle curt: revisar les converses marcades de la setmana, corregir el que l'agent va dir malament i actualitzar els documents afectats sol cabre en una hora setmanal un cop estabilitzat el flux.
Com sé si la base de coneixement s'ha quedat obsoleta?
Hi ha quatre senyals primerencs: l'agent respon amb seguretat coses que ja no són certes (el més perillós, perquè no sembla un error), pugen els escalats d'una intenció que abans resolia sol, els clients corregeixen l'agent en la mateixa conversa ('al web hi posa un altre preu'), i l'equip deixa de refiar-se'n i torna a respondre a mà. Qualsevol dels quatre demana revisar els documents d'aquesta intenció, no canviar de model.
Quanta feina dona mantenir la base de coneixement d'un agent?
El pic és al principi: preparar la base inicial i corregir cada dia les dues primeres setmanes. A partir d'aquí, amb una font única per dada i dates de caducitat, el manteniment típic és una revisió setmanal curta de converses i ajustos puntuals quan canvia alguna cosa al negoci. La regla pràctica: cada canvi de tarifes, horaris o polítiques ha d'incloure 'actualitzar l'agent' a la seva pròpia checklist, igual que inclou actualitzar el web.
#base de coneixement #documentació de l'agent #agent d'IA #qualitat de dades #atenció al client #operacions B2B #sense codi #pimes

Llest per automatitzar les teves operacions?

Crea el teu primer agent d'IA per a trucades i correu en minuts, sense codi.

Uneix-te a la llista d'espera