Il pilota funzionava. La produzione è un altro problema

Quasi tutti i piloti di agenti AI funzionano. Non è il segnale che il sistema è pronto: è il segnale che la demo era disegnata per riuscire. Gira sul percorso felice, su dati scelti da qualcuno, con uno sviluppatore nella stanza pronto a correggere la rotta quando serve. La produzione gira su tutto il resto — senza nessuno a guardare, alle tre di notte, su input che nessuno ha visto prima. La distanza fra le due cose non è il modello. È la superficie operativa intorno al modello, ed è lì che la maggior parte dei piloti si arena in silenzio.

Le domande che una demo non deve affrontare

Mettete in fila le domande che una demo non è mai costretta ad affrontare e la forma del lavoro vero viene fuori. Cosa fa l'agente quando un tool va in timeout a metà di una scrittura: lascia un record a metà, o niente? Se la stessa richiesta viene rieseguita, crea un record o due? Con quale identità agisce quando nessun umano sta guardando, e cosa può toccare quell'identità? Cosa succede alla coda quando il provider del modello degrada per quaranta minuti invece di cadere del tutto? Chi viene chiamato quando qualcosa si rompe, e cosa vede davvero quando apre la traccia?

Nessuna di queste domande riguarda l'accuratezza. Riguardano cosa succede intorno alla decisione, non la decisione. Un pilota può andare benissimo ignorandole tutte.

Nessuna di queste è una questione di modello

Retry, chiavi di idempotenza, service account a privilegio minimo, backpressure, tracciabilità. È ingegneria ordinaria di sistemi distribuiti — lo stesso lavoro che faresti per qualsiasi servizio che scrive su un database e chiama altri servizi. Con un agente diventa più difficile per via del modo in cui fallisce. Un processo che va in crash solleva un'eccezione che puoi intercettare. Un output sbagliato di un LLM no: è una risposta plausibile, ben formattata, che torna 200 e prosegue a valle identica a una giusta.

Per una software house .NET questo cambia l'ordine delle priorità. Non puoi contare sul fatto che il processo fallisca in modo rumoroso. Devi progettare per il caso in cui ogni livello riporta successo e il contenuto è comunque sbagliato — il che vuol dire che la registrazione di cosa ha fatto l'agente va ingegnerizzata quanto l'azione.

L'ultima riunione

Poi arriva la riunione che decide se il pilota va in produzione. Il responsabile del rischio, un revisore, o il team di sicurezza di un partner fa una domanda stretta: cosa ha fatto l'agente su questa pratica, quattro mesi fa? Se la risposta è una tabella di log nello stesso database su cui scrive l'applicativo, il pilota finisce lì. Chiunque abbia i permessi di amministratore può modificarla, e nessuno può dimostrare che non sia successo. "Fidatevi dei nostri log" non è una risposta che un revisore accetta.

C'è anche un vincolo che spinge nella stessa direzione: l'AI Act, per i sistemi ad alto rischio, richiede la registrazione automatica degli eventi. Non è un extra da mettere in preventivo dopo — condiziona l'architettura fin dall'inizio. La voce del registro va scritta da un componente con una sua identità, revisionato come ogni altro pezzo di codice in produzione, e resa non riscrivibile: il modo più pulito è ancorare l'impronta del registro su una catena che nessuno controlla, così un terzo può verificare senza doversi fidare di te. L'azione è ciò che il pilota dimostra. La prova dell'azione è ciò che gli permette di sopravvivere all'ultima riunione.

Il pilota si misura sull'accuratezza. La produzione su cosa succede quando sbaglia — e sul fatto che, mesi dopo, tu possa dimostrare cosa ha fatto.

Quale di queste domande è ancora aperta nel vostro pilota?