Il dilemma degli agenti AI nei processi regolati — e come risolverlo

Quasi tutti concordano che gli agenti AI ridisegneranno i processi. In un contesto regolato, però, il problema non è se usarli: è come mantenerne il controllo. Tre scelte architetturali fanno la differenza.

Poche tesi raccolgono più consenso di questa: gli agenti AI diventeranno parte dei processi core di banche, assicurazioni e amministrazioni pubbliche. Se è vero, i leader affrontano un dilemma. Spingere sull'adozione significa portare un sistema probabilistico dove esiste un revisore; attendere significa cedere ai concorrenti i guadagni di produttività. La nostra esperienza sui progetti in produzione indica che il dilemma si risolve con tre scelte di architettura, non con l'attesa.

La prima scelta è un set di valutazione costruito prima del codice, insieme agli esperti di dominio. Se l'organizzazione non sa definire cosa sia una buona risposta, non potrà dimostrare che il sistema funziona. Nella pratica, i programmi che partono dal modello anziché dal criterio di valutazione impiegano in media il doppio del tempo ad arrivare alla firma delle funzioni di controllo.

La seconda scelta riguarda i guardrail. Un agente che può solo leggere pone un problema di riservatezza; un agente che può scrivere pone un problema di responsabilità. La distinzione va risolta a livello architetturale: un elenco chiuso di operazioni consentite e conferma umana obbligatoria per quelle irreversibili. Non è un limite alla potenza del sistema — è ciò che ne rende difendibile l'impiego.

La terza è un registro delle decisioni leggibile dalle funzioni di controllo: non un file di log tecnico, ma una traccia che colleghi input, evidenze recuperate, azione compiuta e responsabile. È la differenza tra un sistema auditabile e uno che spera di esserlo.

Sopra queste tre scelte vale una regola che emerge costantemente sul campo: la valutazione non è un evento di rilascio, è un processo continuo. Dati, modelli e comportamenti degli utenti cambiano; il set di valutazione va rieseguito a ogni modifica e monitorato come un indicatore di produzione.

L'implicazione è chiara. Le organizzazioni che trattano il controllo come un requisito di progettazione arrivano in produzione in mesi; quelle che lo aggiungono alla fine restano ferme alla demo. E i programmi che falliscono raramente falliscono sul modello: falliscono perché nessuno ha definito chi risponde di una decisione sbagliata. La risposta a quella domanda va scritta prima della prima riga di codice.