Agents d’IA per a empreses: abans d’implantar-ne un.

És un sistema dissenyat per avançar una missió concreta utilitzant un model d’IA, coneixement autoritzat i, quan cal, eines de l’empresa. Pot interpretar una petició, consultar informació, preparar una resposta, proposar una acció o executar passos delimitats.

La diferència important no és que “conversi”, sinó que treballa dins d’un circuit: rep una entrada, aplica criteris, utilitza fonts, produeix un resultat i sap quan s’ha d’aturar o demanar revisió. Per això un agent empresarial no s’hauria de definir només amb un nom i un prompt, sinó amb missió, propietari, fonts, permisos, límits, proves i Human Gates.

Un chatbot general respon dins d’una conversa i, per defecte, no coneix els processos, les versions documentals ni les responsabilitats específiques de l’empresa. Un agent s’ha configurat per a una funció delimitada i pot treballar amb fonts i eines autoritzades.

Això no vol dir que qualsevol agent sigui millor que un xat. Per explorar idees, redactar un primer esborrany o fer una consulta puntual, un assistent conversacional pot ser suficient. L’agent té sentit quan hi ha una tasca repetida, un criteri estable, un recorregut recognoscible i un resultat que es pot avaluar.

No exactament. Una automatització clàssica segueix regles previsibles: si passa A, executa B. Un agent pot interpretar llenguatge, context o documents i decidir quin pas delimitat correspon dins d’un conjunt d’opcions.

Molts bons sistemes combinen les dues coses. Les parts deterministes —moure un fitxer, actualitzar un camp o enviar una notificació aprovada— es resolen amb automatització. La IA entra allà on cal classificar, resumir, comparar, extreure o preparar una recomanació. Aquesta separació redueix cost, variabilitat i risc.

Tècnicament pot executar seqüències sense intervenció constant, però “pot” no significa “convé”. El nivell d’autonomia s’ha d’ajustar a l’impacte de l’acció, la sensibilitat de les dades, la reversibilitat i la qualitat de les proves.

Consultar i preparar acostuma a requerir menys control que publicar, enviar, modificar registres, comprometre pressupost o prendre decisions sobre persones. En aquests punts, Karmina situa Human Gates: moments en què una persona pot veure fonts i context, revisar el resultat, corregir-lo i autoritzar el pas següent.

Una plantilla ajuda a repetir una petició. Un agent, quan està ben dissenyat, pot recuperar el context correcte, seleccionar eines, mantenir estat dins d’un procés, aplicar regles diferents segons el cas i registrar què ha fet.

La pregunta pràctica és si aquesta capacitat addicional resol una fricció real. Si una persona pot obtenir un resultat fiable amb una plantilla, una font clara i dos minuts de revisió, construir un agent pot ser innecessari. L’arquitectura s’ha de guanyar amb valor, no amb complexitat.

Té sentit quan hi ha una feina que es repeteix, consumeix temps qualificat i necessita interpretar text, documents, dades o context abans de produir un resultat. També ha d’existir prou estabilitat: entrades recognoscibles, fonts disponibles, criteris que l’equip pugui explicar i una persona responsable del procés.

Alguns senyals favorables són preguntes internes recurrents, informes que es reconstrueixen cada mes, classificacions manuals, primers esborranys amb una pauta comuna o informació dispersa que sempre acaba buscant la mateixa persona. La decisió no hauria de néixer de “volem tenir un agent”, sinó de “aquesta fricció té prou volum i estructura per provar una manera millor de resoldre-la”.

Un bon candidat té un inici i un final identificables, entrades que es poden descriure, un resultat útil per a algú i prou exemples per distingir una resposta bona d’una de deficient. També convé que les excepcions siguin visibles i que els errors es puguin detectar abans de provocar un impacte greu.

La freqüència importa, però no és l’únic factor. Una tasca setmanal pot justificar un agent si concentra molt criteri o desbloqueja diverses persones. En canvi, una tasca diària pot no justificar-lo si canvia constantment, no té font fiable o l’única manera d’avaluar-la és “ja ho veurem quan surti”.

No convé quan el procés encara no està entès, cada cas es resol de manera completament diferent o les fonts són contradictòries i ningú no pot decidir quina té autoritat. Tampoc quan l’error pot afectar drets, seguretat, reputació o diners i no existeix una revisió proporcional.

Altres senyals d’alerta són voler substituir una responsabilitat que ningú no vol assumir, utilitzar l’agent per donar aparença d’objectivitat a una decisió subjectiva o automatitzar una tasca amb tan poc volum que mantenir el sistema costarà més que fer-la. A vegades la millor primera intervenció és una plantilla, una política, una base documental o una automatització simple.

Normalment és millor començar per un agent o un circuit molt delimitat que permeti provar fonts, permisos, qualitat, temps estalviat i comportament davant d’excepcions. Un pilot ben triat produeix aprenentatges que després es poden reutilitzar: taxonomies, connectors, mètriques, polítiques i formes de revisió.

L’ecosistema té sentit quan diversos agents comparteixen coneixement i responsabilitats sense duplicar-se. Per exemple, escoltar converses, preparar un calendari, revisar el to i publicar són funcions diferents. Connectar-les massa aviat pot crear dependències difícils d’explicar. Primer cal demostrar cada funció; després decidir quines comparteixen base i com es passen la feina.

El departament ajuda a identificar propietat, vocabulari i riscos, però el disseny ha de seguir el procés real. Moltes feines travessen àrees: una proposta comercial pot necessitar vendes, operacions, legal i marca; una resposta d’atenció pot dependre de producte, logística i comunicació.

Per això convé dibuixar qui aporta cada font, qui valida cada criteri i qui utilitza el resultat. L’agent pot tenir una àrea propietària i alhora servir un circuit transversal. El que s’ha d’evitar és construir una solució tancada dins d’un departament que reprodueixi informació o regles diferents de les de la resta de l’empresa.

Necessita la informació estrictament relacionada amb la seva missió: procediments, criteris, definicions, exemples, plantilles, polítiques i dades operatives quan siguin necessàries. Donar-li “tots els documents de l’empresa” no crea automàticament més context; sovint introdueix versions antigues, contradiccions i informació que no hauria de consultar.

El mapa de fonts ha d’explicar què conté cada repositori, qui n’és responsable, amb quina freqüència s’actualitza i en quins casos es pot utilitzar. També són valuosos els contraexemples: respostes que semblen correctes però vulneren el to, un límit o una política. Aquest material converteix coneixement implícit en criteri aplicable.

En molts casos no. La primera opció acostuma a ser connectar el model amb fonts recuperables i autoritzades perquè consulti la informació rellevant en el moment de respondre. Això facilita actualitzar contingut, mostrar cites, respectar permisos i retirar una font sense haver de tornar a entrenar res.

L’ajust o entrenament específic pot tenir sentit per estabilitzar un comportament, un format o una classificació quan hi ha prou exemples de qualitat. No és la solució adequada per memoritzar documentació canviant. Abans de triar arquitectura, cal separar tres necessitats diferents: saber informació, seguir instruccions i produir un estil consistent.

Amb governança documental: una font canònica per a cada tipus d’informació, responsable identificat, dates de revisió, control de versions i regles de prioritat quan dues fonts discrepen. L’agent hauria de poder indicar d’on surt una afirmació important i reconèixer quan la informació no és prou clara.

També cal provar consultes que deliberadament exposin conflictes: preus antics, polítiques substituïdes, noms semblants o documents sense data. La solució no és demanar al model que “sigui rigorós”, sinó limitar el corpus, afegir metadades útils i definir què ha de fer davant d’una contradicció: aturar-se, citar les dues fonts o escalar la pregunta.

Només quan la finalitat ho justifica, l’eina i la configuració són adequades i l’accés respecta les mateixes restriccions que ja té l’organització. Cal minimitzar dades, evitar còpies innecessàries, separar entorns i revisar condicions de tractament, retenció, ubicació i ús per a entrenament del proveïdor.

La pregunta no és només si el model “és segur”, sinó qui pot activar l’agent, quins registres pot consultar, què apareix als logs, quina informació surt en el resultat i qui la rebrà. Per a dades especialment sensibles o decisions sobre persones, cal involucrar els responsables jurídics, de privacitat i de seguretat abans del pilot.

És la base governada de coneixement i criteris que permet descriure què sap l’organització, quina font té autoritat, qui pot validar-la, quins permisos s’apliquen i com es comprovarà que el sistema respon bé. No és només una carpeta de documents ni una base vectorial.

Va abans perquè l’agent amplifica allò que rep. Si el vocabulari, les polítiques, els processos o els exemples estan incomplets, l’automatització no resol el buit: el fa més ràpid i menys visible. Construir la Foundation pot revelar que una part del projecte és tecnològica i una altra és una decisió organitzativa que l’empresa encara ha de prendre.

Depèn de l’especificitat del procés, les integracions, els requisits de dades i la capacitat de manteniment. Una solució existent és adequada quan resol una necessitat comuna i permet governar usuaris, dades i resultats. Una plataforma configurable dona més flexibilitat sense assumir tot el desenvolupament. El codi a mida es reserva per a fluxos diferenciats, integracions complexes o controls que el mercat no cobreix.

La decisió no s’hauria de prendre només pel cost inicial. També compten la dependència del proveïdor, la portabilitat del coneixement, els límits d’ús, la traçabilitat, la velocitat de canvi i qui podrà mantenir el sistema d’aquí a un any. En molts projectes, la millor arquitectura és híbrida i utilitza eines que l’empresa ja té.

Primer es defineixen les proves i després es comparen models. Els criteris poden incloure qualitat en els casos reals, cost per operació, velocitat, longitud de context, tractament de dades, disponibilitat regional, capacitat d’utilitzar eines, observabilitat i compatibilitat amb la infraestructura existent.

No sempre cal el model més potent. Una classificació estable pot funcionar amb un model més petit; una anàlisi complexa pot necessitar-ne un d’avançat; una acció sensible pot requerir una segona comprovació o no executar-se automàticament. Separar funcions permet utilitzar el recurs adequat per a cada pas i evita lligar tot el sistema a una sola marca.

Pot integrar-se amb gestors documentals, CRM, eines de projectes, correu, analítica, bases de dades, formularis, help desks o canals de publicació, sempre que hi hagi una interfície segura i permisos compatibles. La integració no implica necessàriament donar capacitat d’escriptura: sovint convé començar amb consulta o preparació d’esborranys.

Cada connector amplia utilitat i superfície de risc. Cal definir quines accions són de lectura, quines són reversibles, quines necessiten aprovació i què passa si una eina no respon. També s’ha de registrar prou informació per reconstruir el circuit sense guardar més dades de les necessàries.

No hi ha un termini universal. Un prototip amb fonts preparades i sense integracions pot existir ràpidament; convertir-lo en un sistema fiable acostuma a requerir més temps per ordenar coneixement, definir permisos, crear proves, resoldre excepcions, formar usuaris i preparar manteniment.

El calendari depèn menys del nombre de pantalles que de la disponibilitat de responsables i evidències. Una seqüència realista inclou diagnosi, disseny del pilot, preparació de la Foundation, configuració, avaluació amb casos reals, ús en ombra, ajust i decisió de desplegament. Accelerar saltant aquestes fases només trasllada el temps a incidències posteriors.

Com a mínim cal una persona propietària del procés, persones expertes que puguin explicar el criteri, un responsable tècnic o d’integracions quan correspongui i representació de seguretat, privacitat o legal segons el risc. També convé incloure usuaris reals, perquè detecten friccions que no apareixen en un diagrama.

El proveïdor pot facilitar disseny i implementació, però no pot inventar l’autoritat de les fonts ni assumir la responsabilitat operativa de l’empresa. El projecte funciona millor quan els rols estan escrits: qui decideix, qui valida, qui pot aturar el sistema, qui revisa mètriques i qui actualitza el coneixement.

Es redueixen limitant la missió, recuperant informació de fonts fiables, exigint cites quan són rellevants, millorant instruccions i exemples, i permetent que el sistema digui que no ho sap. També ajuda separar l’extracció de dades de la redacció i validar automàticament formats o camps que tenen una regla objectiva.

No existeix el risc zero. Per això cal mesurar els tipus d’error que importen en aquell procés i decidir què passa quan apareixen. Una resposta sense font pot quedar com a esborrany; una dada crítica pot necessitar una comprovació; una contradicció pot activar un escalat. El control és una propietat del circuit complet, no una frase dins del prompt.

Amb un conjunt de casos representatius que inclogui exemples habituals, casos límit, informació incompleta, instruccions ambigües, intents de desviar el sistema i situacions en què s’ha d’aturar. Cada prova necessita un resultat esperat o una rúbrica que permeti valorar exactitud, utilitat, fonts, to i compliment dels límits.

Després de la prova controlada convé un període en ombra: l’agent prepara resultats però no actua, i l’equip els compara amb el procés habitual. Aquesta fase revela errors, temps real de revisió i comportaments inesperats. Només s’amplia l’autonomia quan les evidències justifiquen el canvi.

És un punt explícit del procés on una persona revisa informació suficient i decideix si el sistema pot continuar. No és una aprovació simbòlica: la interfície ha de mostrar el resultat, les fonts, els canvis proposats i els avisos necessaris perquè la persona pugui corregir o rebutjar.

És especialment important abans de publicar, enviar comunicacions sensibles, modificar dades mestres, eliminar informació, compartir dades, comprometre diners o prendre decisions que afecten persones. La intensitat del Gate pot variar: revisió de cada cas, revisió per mostreig, doble aprovació o escalat només quan apareix una excepció.

A més dels riscos habituals d’accés i dades, un agent pot rebre instruccions malicioses dins d’un document o una web, utilitzar una eina fora de context, revelar informació, encadenar errors o acceptar com a fiable una sortida manipulada. Com més eines i autonomia té, més important és separar permisos i validar cada pas.

Les mesures inclouen privilegi mínim, llistes d’accions permeses, aïllament d’entorns, validació d’entrades i sortides, protecció de secrets, registres, límits de despesa o freqüència i proves adversàries. Les fonts externes s’han de tractar com a dades no fiables, encara que el text sembli una instrucció adreçada a l’agent.

Depèn del rol de l’organització, la finalitat i el context d’ús. No tots els agents són d’alt risc, però una empresa ha d’inventariar els sistemes, entendre per a què s’utilitzen, aplicar mesures d’alfabetització, revisar pràctiques prohibides i identificar si hi ha obligacions de transparència o requisits sectorials.

L’agent s’ha de classificar pel que fa, no pel nom comercial de l’eina. Un assistent intern de consulta no planteja el mateix nivell de risc que un sistema utilitzat en ocupació, serveis essencials o decisions sobre persones. La classificació i la documentació s’han de revisar amb assessorament jurídic especialitzat quan el cas pugui entrar en àmbits regulats.

El cost depèn del diagnòstic, la preparació de fonts, les integracions, el nivell d’autonomia, les proves, la seguretat i el manteniment. Una demostració pot ser barata perquè ignora gran part d’aquest treball; un sistema empresarial inclou decisions i controls que no es veuen a la interfície.

Per comparar propostes convé separar cinc blocs: disseny i criteri, Foundation, configuració o desenvolupament, infraestructura i ús, i operació continuada. També cal comptar el temps intern de persones expertes i revisores. El pressupost és més honest quan explica què queda fora, quina hipòtesi es provarà i què faria augmentar l’abast.

Primer es mesura la situació actual: volum, temps per cas, temps d’espera, errors, retraball, dependències i valor del resultat. Després es compara amb el pilot, incloent el temps de revisió humana, el cost d’ús i el manteniment. Estalviar minuts no és retorn si la qualitat baixa o l’equip ha de corregir més.

El retorn pot aparèixer com a capacitat, rapidesa, consistència, reducció de risc o millor servei, no només com a reducció de costos. Cal triar poques mètriques vinculades a una decisió: continuar, ajustar, ampliar o aturar. Les estimacions inicials són hipòtesis; el pilot existeix per substituir-les per evidència.

Depenen de la missió. Poden incloure exactitud, percentatge de respostes amb font, compliment del format, temps fins al resultat, taxa d’acceptació sense canvis, tipus de correccions, escalats correctes, incidències i satisfacció de l’usuari. Les mètriques d’activitat —nombre de consultes o documents generats— no demostren per si soles valor.

Convindria combinar qualitat, operació i risc. Per exemple: una resposta pot ser ràpida però no resolutiva; un informe pot complir l’estructura però interpretar malament una mètrica. Les mostres revisades per experts i la taxonomia d’errors ajuden a veure tendències que una mitjana amagaria.

Cal mantenir fonts, permisos, integracions, instruccions, models, proves i mètriques. També s’han de revisar canvis de procés, noves excepcions, incidències, costos d’ús i actualitzacions dels proveïdors. Un agent connectat a coneixement viu no és un projecte que es lliura i queda congelat.

El manteniment ha de tenir propietari i cadència. Algunes revisions són operatives i freqüents; d’altres són trimestrals o s’activen quan canvia una política, una font o una eina. Les modificacions importants s’han de provar contra el conjunt d’avaluació abans de desplegar-les, igual que es faria amb qualsevol sistema que afecta la feina.

Escollir una fricció concreta i descriure-la sense parlar encara d’eines: qui inicia la feina, quines entrades utilitza, quines decisions aplica, quin resultat produeix, quines excepcions apareixen i qui respon de la qualitat. Després es mesura el punt de partida i es revisa si existeixen les fonts i els permisos necessaris.

Amb aquesta informació es pot decidir si cal una plantilla, una automatització, un assistent o un agent. Si l’agent és la resposta, es defineix un pilot amb abast, Human Gates, proves i criteri de sortida. Començar petit no significa pensar petit: significa construir evidència abans d’augmentar autonomia i dependències.