Del pilot d’IA a producció

Quan passa a producció, un pilot d’IA canvia de context. En una prova, una persona tria l’exemple i observa la resposta. En la feina diària arriben documents incomplets, dades repetides i situacions que ningú no havia preparat per a la demostració.

La dificultat és aconseguir que el procés continuï sent útil quan això passa. L’equip necessita saber què pot acceptar, què ha de revisar i què ha de fer quan el sistema no pot resoldre una tasca.

Per això, abans d’ampliar una prova, convé descriure la feina completa. La part d’IA pot ocupar només un pas. La resta determina si el resultat serveix per a l’operativa.

Comença per una tasca concreta

«Automatitzar administració» és massa ampli per avaluar un primer projecte. Una tasca com extreure determinats camps d’una autorització i vincular-la amb un registre permet parlar d’entrades, sortides i errors concrets.

Defineix qui fa avui aquesta feina, amb quina freqüència i què necessita revisar abans de donar-la per acabada. També has d’identificar què passa després: si la dada es consulta, si alimenta una factura o si desencadena una altra acció.

Aquesta destinació canvia l’exigència. Un text que ajuda a preparar un esborrany es pot corregir durant la lectura. Un identificador que s’incorpora al registre equivocat pot traslladar l’error a diverses operacions posteriors.

Si no pots descriure com reconeixeràs un resultat correcte, encara falta feina de definició. Començar per aquí evita que el projecte es valori per com de convincent sembla una resposta.

La solució pot combinar tècniques diferents

No totes les tasques requereixen un assistent generatiu. Un fitxer estructurat es pot processar amb regles. Un document pot necessitar extracció de camps. Una consulta interna pot demanar una cerca sobre informació autoritzada.

RAG combina recuperació d’informació amb generació d’una resposta. MCP defineix una manera de connectar aplicacions d’IA amb eines i dades. Són conceptes diferents de l’extracció documental, com explica la guia sobre IA generativa, RAG i MCP.

No té sentit atribuir experiència en totes aquestes tècniques a un cas que en demostra una. Per seleccionar una solució, demana que s’expliqui quina part fa cada component i per què és necessària per a la tasca.

També hi pot haver passos que convingui mantenir manuals. Si una excepció és poc freqüent i automatitzar-la afegeix molta complexitat, oferir a l’equip una manera clara de resoldre-la pot ser una decisió raonable.

Prova allò que arriba realment

Una prova útil inclou exemples representatius i casos incòmodes: documents amb formats diferents, informació absent, duplicats o referències que no coincideixen. El conjunt ha de reflectir la feina que esperes rebre, sense limitar-se als exemples que funcionen millor.

Separa els documents que fas servir per ajustar el sistema dels que utilitzes per avaluar-lo. Si es revisa una vegada i una altra la mateixa mostra, és fàcil millorar aquella demostració sense aprendre prou sobre què passarà amb dades noves.

Acorda quin resultat es considera correcte per a cada camp o tasca. El percentatge global pot amagar diferències importants: confondre un text secundari no té la mateixa conseqüència que associar una operació a una altra persona.

Registra també els casos que el sistema rebutja o deriva a revisió. Que una tasca no s’automatitzi pot ser un comportament adequat si evita introduir un resultat dubtós. El que compta és que aquesta derivació sigui visible i utilitzable.

Mesura el procés complet

La velocitat de generació no és suficient per valorar l’estalvi. Compta la preparació de dades, la revisió, les correccions i les incidències. Si obtenir la resposta triga poc però comprovar-la exigeix refer la feina, la millora és limitada.

Compara tasques equivalents i deixa el context per escrit: període, tipus de feina, persones implicades i manera de recollir la mesura. Quan no es coneix una dada, és millor mantenir aquesta limitació que completar el relat amb una precisió inventada.

A més del temps, pots observar quants casos acaben correctament, quants necessiten intervenció i quins errors apareixen. El criteri ha de respondre a la decisió que necessites prendre, no a acumular indicadors per a una presentació.

No converteixis un resultat inicial en una promesa per a tots els clients. El format de les dades, les regles i l’organització de la feina poden canviar molt entre empreses.

Una revisió humana que es pugui fer

Afegir «amb supervisió humana» a una descripció no resol el disseny del procés. La persona que revisa necessita veure la dada extreta, el context i prou informació original per comprovar-la.

També ha de poder corregir, rebutjar o deixar pendent una operació sense buscar solucions fora del sistema. Si el resultat sembla correcte però falta informació, el flux necessita un estat que representi aquesta situació.

La responsabilitat ha de quedar clara. Decideix qui revisa cada tipus d’incidència i quines operacions requereixen confirmació abans de continuar. No cal que una persona ho comprovi tot de la mateixa manera. Sí que el criteri estigui definit i sigui viable en la feina diària.

Prova aquesta part amb les persones que l’hauran de fer servir. Una pantalla que resulta evident per a qui l’ha desenvolupat pot exigir massa interpretació a algú que gestiona moltes tasques seguides.

Els permisos i els errors formen part de la integració

Una integració d’IA ha de respectar què pot consultar o modificar cada usuari. Que el model pugui accedir tècnicament a informació no vol dir que totes les persones l’hagin de rebre.

Distingeix la lectura de l’escriptura. Preparar una proposta de canvi i aplicar-la a un sistema són accions diferents, amb conseqüències diferents. Abans d’automatitzar la segona, defineix condicions, confirmacions i una manera d’investigar què ha passat.

La connexió també pot fallar per motius aliens al resultat de la IA. Has de poder reconèixer una operació pendent, evitar duplicats i recuperar la feina quan un servei torna a estar disponible.

Aquest funcionament mereix una prova pròpia. Interrompre de manera controlada una connexió en un entorn d’assaig pot revelar problemes que una demostració sense incidències no mostra.

Quiralis demostra un flux documental concret

A Quiralis, la plataforma desenvolupada per Mecexis incorpora Google Cloud Document AI per extreure informació d’autoritzacions. L’equip administratiu revisa i corregeix les dades i les vincula amb els actes corresponents i la seva facturació.

El cas recull una reducció de 8 hores a 20 minuts de revisió documental diària per persona, arrodonida al 96%. L’empresa usuària va validar la mesura en diferents dies durant mesos d’ús, amb supervisió administrativa.

El resultat correspon a aquesta tasca recurrent. No descriu l’estalvi de tota l’activitat del centre ni permet deduir el mateix resultat en un altre procés. Tampoc converteix el cas en una demostració d’assistents RAG o agents que actuen de manera autònoma.

El que és rellevant per a aquesta decisió és que l’extracció està integrada en un recorregut de feina amb revisió i destinació de les dades. El model aporta una part del resultat. La plataforma i les persones fan possible utilitzar-lo.

Desplega amb un abast que puguis observar

Una primera fase de producció es pot limitar a un tipus de document, un equip o una part del recorregut. Aquesta limitació ha de permetre completar una tasca útil i detectar problemes abans d’ampliar l’abast.

Acorda quan avançar i quan aturar l’ampliació. Si apareixen errors que l’equip no pot resoldre o la revisió consumeix més feina de la prevista, has d’ajustar el procés abans d’incorporar més volum.

Després del llançament, els formats, les regles i els components poden canviar. Conserva exemples d’avaluació i revisa el comportament després de canvis rellevants. L’acceptació inicial no substitueix el manteniment.

Un pilot comença a convertir-se en una eina quan l’equip el pot fer servir en un dia corrent, corregir allò que falla i entendre el resultat. Aquesta és una prova més exigent i més útil que una demostració que només ha de sortir bé una vegada.