1. Triar una tasca que puguis avaluar
Busca una activitat repetitiva amb entrades reconeixibles i una sortida comprovable: classificar sol·licituds, preparar un esborrany de resposta o extreure camps de documents. Descarta com a primer pilot els processos on un error pugui provocar pagaments, compromisos comercials o decisions difícils de revertir. La primera versió ha de permetre aprendre sense traslladar tota la responsabilitat al sistema.
Escriu el procés actual amb l’entrada, el responsable, la sortida i les excepcions. Si una regla senzilla resol la tasca de manera consistent, potser no cal IA. Reserva el model per a la part que requereix interpretar llenguatge o documents i conserva regles explícites per a dates, imports, permisos i estats. Així és més fàcil entendre què ha fallat i corregir-ho.
2. Acordar dades, límits i responsables
L’AI Risk Management Framework del NIST ofereix un marc voluntari per gestionar riscos dels sistemes d’IA durant el disseny, l’ús i l’avaluació. Per a un pilot, la traducció pràctica és concreta: deixar per escrit propòsit, responsables, límits i criteris de revisió. [1]
Fes un mapa de les dades que entren, on es processen, qui les pot consultar i quant de temps es conserven. Comença amb exemples sintètics o preparats per a proves, sense secrets ni informació personal innecessària. Verifica les condicions del proveïdor per al teu compte i contracte concrets; no pressuposis que tots els productes tracten les dades de la mateixa manera.
3. Dissenyar un flux amb una sortida segura
Exemple hipotètic: arriben correus amb sol·licituds de suport. La IA proposa una categoria i un esborrany; una persona comprova tots dos i decideix si l’envia. El sistema registra la proposta, la correcció i el temps emprat. En aquesta fase no esborra correus, no modifica contractes i no escriu directament sobre dades de producció. La revisió humana és una etapa definida del procés.
Estableix què passa quan falta informació, hi ha un format inesperat o la petició queda fora de l’abast. Una bona sortida pot ser “requereix revisió”, amb el motiu corresponent. Evita obligar el model a donar una resposta concloent en tots els casos. Les regles d’acceptació s’han de validar al codi o a l’aplicació que executa el flux, no dependre només del que digui el model.
4. Tractar els documents com a dades
OWASP descriu la injecció indirecta d’instruccions com un risc quan contingut extern, com un fitxer o un web, altera el comportament d’un model. Recuperar documents amb RAG no elimina per si sol aquest risc. [2]
Per això convé separar allò que el sistema pot fer del que troba en un correu. Dona a les integracions només els permisos necessaris i mantén les credencials fora del contingut enviat al model. Si el pilot només prepara esborranys, no necessita permís per enviar-los. Demana confirmació a una persona abans d’accions amb conseqüències i registra qui les ha aprovat.
5. Mesurar amb exemples representatius
Prepara un conjunt de casos habituals i excepcions abans de començar. Inclou informació incompleta, duplicats, ambigüitats i els idiomes reals del negoci. Conserva una resposta esperada o un criteri d’avaluació per cas. Separa els exemples utilitzats per ajustar el flux dels que faràs servir per comprovar-lo; així no confons adaptació amb qualitat general.
Mesura el temps total, inclosa la revisió, els errors acceptats, les correccions i el cost per tasca. Compara amb el procés anterior sobre casos equivalents. Un esborrany ràpid pot no estalviar feina si revisar-lo costa més temps que redactar-lo. Defineix abans el nivell de qualitat acceptable i qui decideix si el pilot continua, s’ajusta o s’atura; no prometis un percentatge d’estalvi sense mesurar-lo.
6. Ampliar només allò que has comprovat
Comença amb poques persones i un volum limitat. Documenta com aturar el flux, tornar al procés manual i revisar feines pendents sense executar-les dues vegades. Cada canvi de model, instruccions o integració pot alterar els resultats: guarda versions i repeteix una avaluació proporcionada abans d’ampliar permisos o volum.
Per a equips a Barcelona o distribuïts internacionalment, prova cada idioma que utilitzaran i acorda horaris de suport intern. El resultat del pilot ha de ser una decisió argumentada: continuar, modificar l’abast o abandonar la idea. Una automatització útil és la que l’equip pot supervisar, mantenir i explicar després de la demostració inicial.