Formar un equip per utilitzar ChatGPT, Microsoft Copilot o una altra eina d’IA acostuma a començar amb tasques conegudes: resumir un correu, completar un registre de CRM o classificar una incidència. El problema apareix quan, per fer l’exercici més realista, es copia una conversa real, una exportació interna o un document de client. Aleshores, la pràctica deixa de ser només una activitat formativa i passa a dependre de dades, permisos i configuracions que potser no s’han revisat per a aquesta fi
L’alternativa és crear un banc de proves formatiu: casos completament ficticis que reprodueixen l’estructura, el llenguatge i les decisions de cada lloc de treball sense reutilitzar informació recognoscible de l’organització. Així, la formació d’IA per perfils pot comprovar una cosa més important que la destresa a l’hora de redactar prompts: si cada persona sap detectar límits, demanar aclariments, revisar una sortida i aturar una acció quan falten dades.
L’error de practicar amb informació real «només per provar»
Un correu real pot contenir dades personals, informació confidencial, referències comercials o context que no resulta evident a primera vista. L’Agència Espanyola de Protecció de Dades recomana no introduir en eines d’IA informació confidencial de l’organització, de les persones treballadores o de la clientela, i recorda que el tractament també pot involucrar metadades, a més del text introduït. Per a una sessió d’aprenentatge, convé partir de material inventat des de l’origen, i no de documents parcialment ocults. [4]
També és important separar la formació de l’operació. Una pràctica busca observar com respon una persona davant d’una tasca delimitada; no hauria de convertir-se en una autorització implícita per actualitzar sistemes, enviar comunicacions o alimentar automatitzacions. En entorns de Microsoft Copilot, les respostes es basen en els permisos existents de l’usuari. Per això, ensenyar a utilitzar l’eina no substitueix la revisió de quin contingut està compartit ni de qui hi pot accedir. [5]
Com dissenyar una mostra fictícia que s’assembli a la feina
Una bona mostra imita la tasca, no les dades reals. Pot conservar columnes, tipus d’incidència, passos d’un procés i vocabulari habitual, però ha d’utilitzar noms, empreses, productes, imports, dates, adreces i identificadors inventats. Si una dada permet reconèixer una persona, una operació o una font interna, no és una mostra adequada per a un exercici general de formació.
Cada cas ha de contenir fricció deliberada. Incloeu-hi com a mínim una dada ambigua, una d’absent i una de contradictòria. L’objectiu no és que la IA trobi una resposta elegant costi el que costi, sinó comprovar si qui hi participa diferencia un fet d’una suposició i sap aturar-se. Per exemple, una data de lliurament pot no coincidir amb la indicada en una comanda; la resposta vàlida ha d’assenyalar la discrepància, no triar una data sense justificar-la.
- Definiu el perfil: vendes, administració, operacions, suport, direcció o TI.
- Descriviu una única tasca observable i un resultat esperat.
- Indiqueu quines dades fictícies es poden utilitzar i quina informació falta expressament.
La plantilla mínima d’un cas i tres exercicis
La plantilla pot ser senzilla: perfil destinatari, objectiu, material fictici, instruccions, format de sortida, informació conflictiva, motius d’escalat i criteris de revisió. Afegiu una versió del cas per poder comparar exercicis similars al llarg del temps. NIST planteja la gestió del risc d’IA com a activitats de governança, contextualització, mesurament i gestió, i inclou la definició de l’abast, les competències de les persones que operen el sistema i la supervisió humana com a elements rellevants. [2]
Exemple hipotètic per a vendes: lliureu una conversa inventada amb un client i demaneu un esborrany d’actualització de CRM. La persona ha de separar els camps confirmats dels que estan pendents de validació. Exemple hipotètic per a administració: utilitzeu tres comandes simulades en què la referència, la data i la quantitat no encaixen; el resultat ha de registrar l’excepció. Exemple hipotètic per a suport: presenteu incidències fictícies i sol·liciteu una taula de prioritat que indiqui quina evidència falta abans de proposar una acció.
- No avalueu només si la resposta està ben redactada.
- Demaneu que s’indiquin fets, supòsits, dubtes i la revisió humana següent.
- Eviteu que l’exercici inclogui enviaments, canvis o accions reals.
Avaluar la revisió humana, no només el prompt
Una rúbrica útil observa conductes verificables: si la persona identifica contradiccions, conserva el format sol·licitat, evita inventar camps, distingeix les propostes dels fets i escala una decisió quan correspon. També pot demanar que identifiqui la font fictícia de cada dada rellevant. Això evita confondre una resposta fluida amb una resposta apta per entrar en un CRM, un correu o un flux automatitzat.
Les proves s’haurien de fer abans d’ampliar un ús i continuar durant l’operació, comparant resultats amb referències i documentant allò observat. El marc de NIST indica que mesurar inclou avaluar sistemes d’IA i registrar resultats que ajudin a gestionar els riscos identificats. En formació, això es tradueix a conservar només les evidències necessàries: tasca assignada, versió del cas, resposta, correcció i necessitat de reforç. [3]
Passar de la simulació a una prova interna controlada
Superar exercicis ficticis no demostra una competència permanent ni autoritza automatitzacions sense revisió. Si l’empresa decideix provar un cas intern, el pas següent ha de ser gradual: abast reduït, informació expressament autoritzada, permisos revisats, responsable de validació i un criteri clar per aturar el pilot. La revisió ha de considerar tant la sortida de la IA com la qualitat i l’exposició del material de partida.
Les capacitats disponibles poden canviar segons les llicències, els serveis connectats, la retenció de dades i la configuració de l’espai de treball. En el cas de ChatGPT per a entorns de treball, els controls administratius i el comportament dels fitxers o connectors depenen de la configuració aplicable. Abans de convertir una pràctica en un procés habitual, convé confirmar aquests límits amb les persones responsables de l’entorn tècnic i de la informació. [1]
- Comenceu per una tasca amb impacte limitat i una sortida revisable.
- Establiu qui valida el resultat i on es registra la correcció.
- Utilitzeu els errors observats per ajustar la formació, les dades de prova o els controls.
Preguntes freqüents
Per què no n’hi ha prou amb anonimitzar un document real per formar l’equip?
Ocultar alguns camps pot no eliminar referències, context o metadades que facin recognoscible la informació. Crear un cas totalment fictici permet practicar la mateixa tasca amb una separació més clara entre aprenentatge i operació.
Què s’ha de puntuar en una formació pràctica d’IA?
A més de la qualitat del text, convé avaluar si la persona detecta dades absents o contradictòries, respecta el format, diferencia els fets dels supòsits, evita inventar informació i sol·licita revisió humana quan correspon.
Pot una empresa passar directament d’un curs a automatitzar una tasca?
No és recomanable assumir-ho. La formació ajuda a observar habilitats en casos definits, però una automatització requereix valorar per separat l’abast, els permisos, la qualitat de les dades, la validació humana i els límits operatius.