Scenario illustrativo. Il fornitore mostra l’agente di supporto: risponde bene a sei domande e la sala applaude. La milestone viene fatturata. Tre settimane dopo, la responsabile del servizio clienti dice che “non è finito” perché si perde con gli ordini resi; il fornitore risponde che non è mai stato nel perimetro. Nessuno dei due mente. Nessuno ha scritto cosa volesse dire “finito”.
La tesi in una riga: un agente IA non si consegna quando funziona in demo, ma quando rispetta criteri di accettazione scritti prima di cominciare e firmati da qualcuno del business. Senza quel foglio, il progetto non finisce mai o finisce per stanchezza.
Cosa sono i criteri di accettazione di un agente IA e perché la demo non basta?
I criteri di accettazione di un agente IA sono le condizioni misurabili che l’agente deve rispettare, su casi reali e per un periodo concordato, perché il cliente lo consideri consegnato. Su un modulo web, “funziona” è binario: salva il dato o non lo salva. Un agente risponde in modo diverso ogni volta e ha ragione in una certa proporzione dei casi, quindi “funziona” è sempre una domanda incompleta: con che frequenza, su quali casi e a che costo quando fallisce?
La demo non risponde a nessuna delle tre, perché la sceglie chi vende: i casi migliori nel giorno migliore (ne parliamo in la demo usava i tuoi casi migliori). E il problema di fondo non è tecnico. L’analisi di RAND sul perché falliscono i progetti di IA, basata su interviste a ingegneri e data scientist, indica tra le cause più frequenti un problema da risolvere capito o comunicato male (RAND, 2024). I criteri di accettazione sono quella conversazione messa per iscritto, con una data e dei nomi.
Cosa deve includere il documento di accettazione di un agente?
Sei cose, e tutte e sei stanno in una pagina. Se una non ci sta, significa che non sapete ancora cosa state comprando.
- Casi di prova che vengono dalla tua operatività, non da quella del fornitore. Un insieme chiuso di casi reali, con quelli difficili e le eccezioni dentro, congelato prima di iniziare. Se l’insieme cambia durante il progetto, i risultati non sono confrontabili. Come valutare: valutare la qualità degli agenti IA e evals: senza misurare non sai se funziona.
- L’errore tollerato, per tipo di errore. Non un “95% di accuratezza” globale: sbagliare il tono non costa come promettere un rimborso che la policy non prevede. Perché la media inganna: il 95% di accuratezza non basta in produzione.
- Cosa fa quando non sa. Criteri di escalation: in quali situazioni passa la mano a una persona, con quale contesto e in quanto tempo. Il design è in cosa fa un agente quando non sa.
- Cosa può toccare e fin dove. Quali sistemi legge, su quali scrive e quali azioni richiedono l’approvazione di una persona, secondo i livelli di autonomia di un agente.
- Come si misura e per quanto tempo. Un periodo di prova supervisionato in produzione reale, con la metrica definita in anticipo. Cosa misurare senza raccontarsela: misurare le prestazioni delle tue automazioni.
- Chi firma. Un nome e un ruolo del business, non un reparto.
Chi deve firmare che l’agente è finito?
La persona che subisce le conseguenze se fallisce: il responsabile del processo. Non chi compra la tecnologia e non chi la costruisce. Il fornitore propone i criteri e dimostra che sono rispettati; il business decide se gli bastano. Se firma solo l’area tecnologica, ciò che si accetta è che il sistema sia in piedi, non che il lavoro venga fatto bene.
La firma include il diritto di rifiutare. Un documento che si può solo firmare è una formalità. E aiuta una seconda firma: quella di chi manterrà l’agente dopo. Accettare qualcosa che nessuno saprà gestire significa rimandare il problema al mese successivo (vedi chi mantiene gli agenti IA quando sono già in produzione).
| Cosa si scrive prima di iniziare | Cosa succede se non si scrive | Chi lo definisce |
|---|---|---|
| Un insieme di casi reali | Il fornitore prova con ciò che sa che funziona | Il business fornisce, il fornitore aiuta a coprire i vuoti |
| Errore tollerato per tipo | Una bella media nasconde l’errore costoso | Il business, in base a quanto costa ogni errore |
| Quando passa a una persona | L’agente improvvisa proprio dove non dovrebbe | Business e fornitore, insieme |
| Permessi e azioni con approvazione | Il perimetro reale si scopre il giorno dell’incidente | Business e responsabile sicurezza |
| Periodo di prova e metrica | “Finito” si misura a sensazione | Il business, con il fornitore come consulente |
| Firma | Il progetto non finisce o finisce per stanchezza | Un ruolo del business con un nome |
Cosa succede se non ci sono criteri di accettazione?
Ci sono due finali possibili e nessuno dei due è buono. Nel primo, il progetto non finisce mai: ogni nuova richiesta è vissuta come un fallimento dell’agente, il fornitore vede il perimetro crescere senza limite e il cliente ha l’impressione di pagare per riparare ciò che ha già comprato. Nel secondo, finisce per stanchezza: lo si dichiara buono perché nessuno regge un’altra riunione, e l’agente va in produzione senza che nessuno conosca il suo vero tasso di errore.
Il secondo finale è il peggiore, perché sembra un successo. È la versione contrattuale di ciò che spieghiamo in perché falliscono i progetti di automazione con l’IA: il progetto non fallisce in demo, fallisce nel vuoto tra ciò che ciascuno dava per scontato.
Come si scrive un criterio che si possa davvero verificare?
Con tre ingredienti: un insieme di casi, una soglia e una condizione di fallimento non negoziabile. Un esempio di formulazione (le cifre sono illustrative; le tue le fissi in base a quanto ti costa ogni errore):
Nota l’asimmetria: la soglia si negozia, la condizione di fallimento no. Alcuni errori si tollerano in una certa proporzione, altri per nulla. Scriverlo evita la discussione più costosa del progetto, quella che arriva quando l’errore è già arrivato a un cliente.
Quando non serve un documento di accettazione formale?
Quando è un prototipo dichiarato come tale, un esperimento interno senza clienti né dati personali, o un caso in cui sbagliare costa poco ed è reversibile. Lì bastano una frase e una data: “questa è una prova, si rivede il giorno X”. Appena l’agente tocca clienti, denaro o dati personali, la pagina si scrive.
Se hai già un agente in funzione e nessuno ricorda cosa è stato accettato, il momento di scrivere il documento è adesso, prima della prossima estensione. E se stai per ingaggiarne uno, valutare la qualità degli agenti IA è il lavoro che trasforma questa pagina in un insieme di casi e una soglia eseguibili.
La riga da portare via: un agente non è finito quando impressiona, ma quando qualcuno del business, con nome e ruolo, firma che rispetta ciò che era stato scritto prima di iniziare.
Fonti (consultate il 27 ottobre 2026): “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed”, RAND Corporation (2024). Lo scenario iniziale e le cifre dell’esempio sono illustrativi, non un caso reale.