Una automatització pot llegir un correu, classificar una sol·licitud i actualitzar l'estat d'una oportunitat en segons. El problema apareix quan, dies després, una persona detecta que el canvi era incorrecte i ningú no pot respondre amb claredat quina informació es va utilitzar, quina regla es va aplicar o si hi va haver una aprovació humana. Saber que el flux tècnic va acabar correctament no explica si la decisió de la IA era adequada.

Un registre de decisions d'IA al CRM aporta una traçabilitat operativa per investigar canvis concrets i detectar patrons d'error. No consisteix a desar indiscriminadament correus, documents o instruccions completes. Consisteix a conservar evidència proporcional: la proposta, el context de procés necessari, la versió utilitzada, la decisió humana quan n'hi hagi i el valor final escrit al CRM.

El problema: un camp canvia i ningú no sap per què

Imaginem un cas hipotètic: una IA interpreta un correu d'un client i proposa canviar una oportunitat de «en negociació» a «perduda». El flux s'executa sense errors i el CRM mostra el nou estat. Tanmateix, el correu només indicava que el client volia ajornar la conversa. Si l'equip comercial troba el problema més tard, necessita reconstruir la decisió sense revisar manualment totes les execucions realitzades aquell mes.

La traçabilitat ha de distingir entre l'operació tècnica i la decisió de negoci. L'historial d'un flux pot indicar inici, final, durada, estat, desencadenador, propietari i errors; aquestes dades ajuden a investigar fallades d'execució. Però, per entendre una actualització incorrecta, també cal saber quin camp es va proposar modificar, amb quina versió d'instruccions o regles i quin va ser el resultat de la revisió. A més, l'historial tècnic pot tenir una retenció limitada i no sempre constitueix un registre complet per a totes les finalitats operatives. [3]

Què ha d'incloure la fitxa mínima de cada canvi

Dissenyeu una fitxa de traçabilitat vinculada a cada proposta o escriptura rellevant al CRM. Ha d'incloure un identificador intern d'operació; data i hora; nom del procés o flux; versió de les instruccions, regles o configuració; referència segura a l'entrada original; taula, registre i camp afectats; valor anterior; valor proposat per la IA; regla de negoci aplicada; nivell de revisió requerit; resultat de la revisió; valor final escrit; rol o persona revisora quan correspongui; i estat tècnic amb referència a l'error si n'hi hagués. No tots els processos necessiten el mateix detall, però els elements han de permetre relacionar l'execució, l

En plataformes com Dataverse, l'auditoria es pot configurar per entorn, taula i columna, i pot registrar canvis en registres i camps auditats, inclosos els valors anteriors i nous quan correspongui. Aquesta capacitat no substitueix per si sola el registre de decisió: convé relacionar l'esdeveniment d'auditoria amb l'automatització, la seva versió i l'aprovació o correcció realitzada. Així s'evita confondre el fet que una dada hagi canviat amb l'explicació de per què es va decidir canviar-la. [2]

  • Identificador d'operació o cas per relacionar execució, proposta i actualització.
  • Referència a l'origen sense duplicar innecessàriament el contingut del correu o document.
  • Valor anterior, proposta d'IA, decisió de revisió i valor final al CRM.

Desar el que calgui i limitar l'accés

No convé registrar per defecte el text complet de tots els correus, els adjunts, les credencials, els secrets d'integració ni dades que no siguin necessàries per investigar un cas. Una referència interna al missatge o document original pot ser suficient si les persones autoritzades ja tenen accés a la font. Abans d'activar escriptures automàtiques, definiu quines dades justifiquen conservar-se, qui les pot consultar i quins responsables gestionen el flux, el procés funcional i els permisos del registre.

La decisió sobre què s'ha d'auditar i durant quant de temps ha de formar part del disseny. Microsoft adverteix que les dades d'auditoria poden contenir informació sensible i consumir capacitat d'emmagatzematge; també assenyala que l'auditoria es configura amb un abast determinat i no cobreix automàticament totes les accions. Per això, separeu la retenció de l'historial tècnic de l'evidència operativa que realment necessiti l'equip per analitzar incidències, sempre amb permisos restringits i criteris de minimització. [2]

  • Eviteu incloure secrets, contrasenyes, tokens o còpies automàtiques d'adjunts.
  • Apliqueu accés per rol al registre i als documents d'origen.
  • Reviseu periòdicament si cada camp registrat continua sent útil per investigar o millorar el procés.

Convertir el registre en millora contínua

Reviseu el registre setmanalment o mensualment amb tres indicadors senzills: percentatge de propostes corregides o rebutjades; camps o tipus de sol·licitud que concentren més incidències; i execucions fallides, cancel·lades o pendents de revisió respecte del total. Aquestes mètriques no demostren per si soles que la IA sigui fiable, però orienten sobre on cal investigar. Una taxa elevada de correccions en un camp pot revelar una regla ambigua, dades d'origen incompletes o una automatització que requereix revisió humana abans d'escriure.

Les correccions humanes han de servir per ajustar el procés, no per quedar-se en una safata d'excepcions. Agrupeu errors similars, actualitzeu regles o instruccions quan hi hagi una causa identificable i proveu el canvi amb exemples representatius abans d'ampliar-ne l'abast. Les guies de NIST recomanen documentar el context d'ús, la supervisió humana, el monitoratge posterior al desplegament i els mecanismes per registrar incidències i anul·lacions humanes. Per a l'avaluació manual, resulta útil definir criteris d'acceptació observables i registrar el resultat de cada revisió. [1] [4]

  • Mantingueu revisió humana per a casos de més impacte o ambigüitat.
  • Proveu els canvis de versió amb casos realistes i d'una intenció clara.
  • Si persisteix un patró d'errors, reduïu l'abast de l'automatització o retorneu aquest cas a la gestió manual.

Preguntes freqüents

N'hi ha prou amb l'historial d'execucions del flux?

No sempre. L'historial tècnic indica si el flux s'ha iniciat, ha acabat o ha fallat, però pot no explicar quina decisió va proposar la IA, quina versió de regles va intervenir, si una persona va corregir el resultat o quin va ser el valor final aplicat. Relacioneu tots dos registres mitjançant un identificador intern.

Cal desar el contingut complet de cada correu processat?

No per defecte. Conserveu només el que calgui per revisar el canvi. En molts casos n'hi ha prou amb una referència segura al missatge original, juntament amb els camps afectats, la proposta, la regla aplicada i la decisió final. Definiu l'accés i la conservació segons la utilitat operativa del procés.

Quan ha d'intervenir una persona revisora?

Abans de definir-ho, classifiqueu els canvis per impacte i ambigüitat. Una persona pot revisar propostes que afectin estats rellevants, dades sensibles o casos amb poca claredat. Per a canvis de menys impacte, el registre del valor anterior i final permet fer revisions per mostreig i detectar si cal ajustar les regles.

Fonts primàries

  1. AI RMF Core - AIRC
  2. Manage Dataverse auditing - Power Platform | Microsoft Learn
  3. Monitor your flows - Power Automate | Microsoft Learn
  4. Design evaluation prompts for Copilot agent evaluation | Microsoft Learn
  5. Artificial Intelligence Risk Management Framework (AI RMF 1.0)
  6. Transparency & Documentation