Com mesurar les correccions humanes en automatitzacions amb IA

Una automatització amb IA pot llegir correus, resumir sol·licituds, identificar dades de contacte i preparar canvis en un CRM. Però que una persona premi «aprovar» no demostra per si sol que la sortida fos adequada. Pot haver revisat amb pressa, no haver vist el correu original o haver detectat un problema sense deixar-ne constància.

El problema apareix quan l’empresa només mesura volum processat, aprovacions o temps estalviat. Per decidir si un flux s’ha de mantenir sota supervisió, ajustar-se o ampliar-ne l’abast, necessita convertir cada correcció, rebuig i escalat en un senyal operatiu. La clau no és acumular una taxa global d’errors, sinó entendre què ha fallat, en quin context i quin n’hauria estat l’impacte.

El punt de control ha d’evitar un dany concret

Abans de mesurar, delimiti l’acció que revisa la persona i l’efecte que vol prevenir. Per exemple, un flux pot extreure del correu una empresa, una prioritat i una acció següent, però deixar el registre de CRM com a esborrany fins que algú validi la proposta. Aquest plantejament permet intervenir abans d’una actualització errònia, un missatge inadequat o una assignació comercial incorrecta.

La revisió humana té més valor quan el revisor pot comparar el resultat proposat amb la seva font: el missatge original, les dades internes disponibles i el camp que es modificarà. Microsoft documenta fluxos d’aprovació en què una persona revisa i actua sobre un contingut o una decisió abans que el procés continuï. Per a decisions crítiques o ambigües, la derivació a revisió manual ajuda a conservar el control humà. [3] [4]

• Comenci per accions reversibles, com classificar una sol·licitud, crear un esborrany o proposar un registre pendent de validació.
• Definiu quines dades pot consultar el revisor i quins permisos té per aprovar, corregir, escalar o aturar el cas.
• Eviteu que el flux executi automàticament accions fora de l’abast acordat, encara que semblin rutinàries.

Registre cinc resultats de revisió, no només aprovar o rebutjar

Una pantalla amb dos botons, aprovar o rebutjar, simplifica excessivament el que ha passat. Una correcció de format no té la mateixa rellevància que canviar el client associat a una oportunitat. Classificar el resultat de cada revisió permet separar els ajustos lleus dels errors que haurien afectat les vendes, l’atenció al client o les operacions.

Podeu utilitzar cinc resultats bàsics: aprovat sense canvis; aprovat amb canvi menor; corregit abans d’executar; escalat a una altra persona; i rebutjat o aturat. En tots els casos convé desar l’identificador del cas, la data, la versió del flux, el valor proposat i, quan hi hagi modificació, el valor final i el motiu. NIST recomana instrumentar els sistemes amb registres, historials d’auditoria i estadístiques sobre intervencions o anul·lacions d’usuaris i operadors, errors comunicats i temps de resposta. [2]

• Aprovat sense canvis: estableix una línia de base, però no garanteix que la sortida fos correcta.
• Aprovat amb canvi menor: registra camps de format, to, normalització o etiquetatge.
• Corregit abans d’executar: conserva la proposta, el valor final i el motiu de la correcció per detectar l’impacte evitat. Exemple hipotètic

Classifiqueu l’error i conserveu el context

Una taxonomia breu i observable evita que totes les incidències acabin en comentaris lliures difícils d’analitzar. Les categories han de descriure el problema, no atribuir culpes de manera automàtica. Així, l’equip pot distingir una fallada del model d’una dada d’origen incompleta, una regla d’integració defectuosa o una instrucció empresarial ambigua.

Una classificació útil pot incloure: dada absent o no avalada per la font; dada extreta del contacte equivocat; prioritat mal classificada; acció suggerida no autoritzada; font interna desactualitzada o insuficient; instrucció ambigua; i cas fora de l’abast definit. Afegiu variables de context, com ara idioma, canal d’entrada, producte, plantilla, tipus de client o versió de la instrucció. Un exemple hipotètic: si els errors es concentren en fils amb diversos contactes, el problema pot requerir una regla d’identificació addicional, no un canvi general del flux.

• Utilitzeu una categoria tancada i un comentari opcional per aportar matisos.
• Vinculeu la correcció al camp afectat: empresa, contacte, prioritat, responsable, import, resposta o acció proposada.
• Conserveu l’origen disponible per a la revisió, respectant els permisos i les polítiques internes aplicables.

Mesureu indicadors que permetin decidir

La taxa global de correcció és insuficient perquè amaga diferències de risc. Mesureu la taxa de correcció per tipus de camp i per context; la taxa d’escalat; les incidències detectades després d’una aprovació; el temps de revisió per tipus de cas; i la repetició d’una mateixa fallada. Segmenteu els resultats entre casos estàndard, excepcions, missatges incomplets i situacions amb diverses entitats o instruccions contradictòries.

NIST planteja avaluar els sistemes d’IA abans del seu desplegament i regularment durant el seu funcionament, documentant mètriques, resultats i context d’ús. També recomana comparar el que s’observa en producció amb els mesuraments previs, vigilar anomalies i establir actuacions posteriors a una alerta, inclosa la revisió humana i el registre de les accions preses. Això orienta el mesurament cap a decisions operatives, no cap a una única xifra de precisió. [1] [2]

• Reviseu una mostra de casos aprovats sense canvis: l’absència de correcció no prova que el resultat fos adequat.
• Analitzeu per separat els errors amb possible impacte en el client, el CRM o la comunicació externa.
• No utilitzeu el temps de revisió com a únic criteri d’èxit: una revisió més ràpida pot amagar manca d’evidència o sobrecàrrega de l’equip.

Tanqueu el cicle de millora sense canvis improvisats

Definiu per endavant quins senyals exigeixen actuar. Per exemple, una dada no avalada, una acció no autoritzada o una associació de client errònia poden requerir aturar el flux per a aquest tipus de cas. Altres incidències, com un format inconsistent, potser justifiquen una millora programada. No hi ha un llindar universal: el criteri ha de dependre de l’abast, del dany potencial i de la capacitat de l’equip per detectar i corregir errors.

Després d’una correcció repetida, reviseu una mostra de casos amb les persones responsables del procés. Decidiu si correspon ajustar instruccions, millorar fonts internes, incorporar una validació, limitar l’abast o derivar més casos a revisió humana. Proveu el canvi en una mostra controlada i documenteu la decisió, la versió i els resultats observats. La revisió humana en etapes crítiques s’utilitza com a mecanisme de control de qualitat i seguiment en aplicacions generatives, però ha d’anar acompanyada de permisos clars, avaluació i límits operatius. [2] [5]

• Establiu qui pot pausar el flux, com s’impedeixen noves execucions i com es gestionen els casos en curs.
• Assigneu responsables per revisar tendències i decidir canvis en regles, fonts o integracions.
• Considereu una auditoria d’IA i automatització quan necessiteu revisar el disseny del flux, els seus permisos, els seus punts de control i e

Preguntes freqüents

Què ha de desar l’equip quan corregeix una sortida d’IA?

Com a mínim, l’identificador del cas, la data, la versió del flux, el resultat proposat, el valor final si es va modificar, el camp afectat, la categoria de l’error i el motiu. També convé desar el context que permeti analitzar patrons, com el canal, l’idioma o el tipus de sol·licitud.

Una taxa baixa de correccions significa que l’automatització funciona bé?

No necessàriament. Pot indicar que el flux funciona adequadament, però també que els revisors no disposen de prou context, tenen poc temps o no estan registrant els problemes. Reviseu una mostra d’aprovacions sense canvis i contrasteu els resultats amb incidències posteriors.

Quan convé aturar una automatització amb IA?

Convé tenir un procediment intern per pausar el flux davant d’errors que puguin provocar una acció no autoritzada, associar dades a la persona o empresa equivocada, generar informació no avalada o superar l’abast definit. La decisió ha de considerar l’impacte potencial, els permisos disponibles i la possibilitat de gestionar els casos en