La demo ha funzionato. Il modello ha risposto bene, gli stakeholder hanno annuito, e qualcuno ha posto la domanda ragionevole: quanto ci vuole per andare in produzione? La risposta onesta è di solito "più tardi di quanto suggerisca la demo" — non perché il modello debba diventare più intelligente, ma perché alla demo è stato permesso di saltare tutto ciò che rende un sistema affidabile. I team che mettono a budget solo la demo non consegnano nulla. I team che mettono a budget le dieci questioni qui sotto consegnano sistemi che sopravvivono al contatto con gli utenti reali.
Perché la demo era facile
Un prototipo si guadagna il suo effetto facendo assunzioni silenziose. Girava su un insieme curato di documenti scelti a mano. Rispondeva a domande a cui i suoi costruttori sapevano che poteva rispondere. Nessuno gli ha chiesto di rispettare i permessi, perché tutti nella stanza potevano vedere tutto. Nessuno ha misurato il suo tasso di errore, perché gli errori venivano silenziosamente ritentati. Non costava nulla che valesse la pena tracciare, perché un uso prototipale a basso volume raramente rivela il costo operativo della scala organizzativa.
Niente di tutto questo è una critica — il compito di un prototipo è dimostrare che l’idea merita ingegneria. L’errore è trattare il prototipo come il sistema con qualche dettaglio da sistemare, invece che come la prima riga della specifica di quello vero.
Dati e grounding: da esempi curati a fonti reali
La prima domanda di produzione non è "quale modello?" ma "quali dati, e chi può vederli?"
Nella demo il retrieval girava su un corpus pulito. In produzione gira sulle fonti reali dell’organizzazione — wiki che si contraddicono, documenti con restrizioni di accesso, record che cambiano ogni giorno. Il retrieval deve diventare consapevole dei permessi: un sistema che mostra un documento a qualcuno che non era autorizzato a leggerlo è un guasto di sicurezza, per quanto utile possa sembrare la risposta. E le risposte hanno bisogno di attribuzione — una risposta che cita le sue fonti può essere verificata; una che non lo fa va creduta ciecamente, e gli utenti enterprise fanno bene a non farlo.
Un test utile: prendete la migliore risposta del prototipo e chiedete da dove viene ogni frase, e se ogni persona che userà il sistema è autorizzata a vedere quelle fonti. Se una delle due risposte non è chiara, il livello dati non è finito.
Valutazione: definire cosa significa "funziona" prima del rilascio
I prototipi si giudicano a impressione; i sistemi di produzione hanno bisogno di criteri. Prima che una funzionalità AI vada in produzione dovrebbero esistere tre cose: una definizione di risposta corretta per il suo compito, un test set che rappresenti l’uso reale e non i percorsi felici, e una misurazione di baseline con cui confrontare ogni modifica futura.
Non è burocrazia — è ciò che rende sicuro il cambiamento. I modelli vengono aggiornati, i prompt vengono modificati, le fonti crescono. Senza un framework di valutazione, ogni modifica è una scommessa che nessuno può quantificare; una regressione arriva in silenzio e la scoprono gli utenti. Con il framework, un aggiornamento di versione del modello che degrada la qualità delle risposte viene intercettato il giorno stesso, non il trimestre dopo.
Operatività: la parte che nessuno mostra in demo
Quattro questioni trasformano una funzionalità AI in un sistema operabile:
- Confini di sicurezza. L’accesso del sistema a dati e strumenti è un’integrazione, e riceve una review da integrazione: identità propria, privilegio minimo, revoca. Un prototipo che gira sul token personale di uno sviluppatore non è un percorso di deployment.
- Observability. Quando una risposta è sbagliata, qualcuno deve poter vedere perché — cosa è stato recuperato, cosa è stato chiesto al modello, cosa ha restituito. Un sistema AI senza tracce è indebuggabile per costruzione.
- Gestione dei guasti. I modelli vanno in timeout, i provider applicano rate limit, il retrieval torna vuoto. Ogni modalità di guasto ha bisogno di un comportamento progettato — un fallback, un rifiuto, un’escalation a un umano — non di un’eccezione in un log.
- Budget di costi e latenza. Un workflow che in demo costa centesimi può costare denaro vero su scala organizzativa, e una risposta di dieci secondi che in demo divertiva verrà abbandonata dagli utenti quotidiani. Entrambi hanno bisogno di budget, misurati per richiesta, prima della scala — non dopo la fattura.
Cambiamento: il sistema non starà fermo
I sistemi AI di produzione poggiano su un terreno che si muove. I provider deprecano i modelli secondo i propri tempi. I prompt accumulano modifiche finché nessuno ricorda perché una frase è lì. I dati sorgente derivano. Il workflow che il sistema automatizza cambia forma.
Per questo l’ultima questione è organizzativa più che tecnica: la responsabilità. Qualcuno possiede i risultati della valutazione, decide quando adottare una nuova versione del modello, rivede l’uso effettivo del sistema e risponde del suo comportamento. Una capability AI senza un responsabile non è infrastruttura — è un esperimento che si dà il caso sia esposto agli utenti.
Una checklist di readiness per la produzione
Dieci domande, a cui si risponde in un pomeriggio, che predicono se il prototipo è vicino alla produzione o lontano:
- Quali fonti legge, e i permessi sono verificati per utente?
- Ogni risposta può citare la propria origine?
- Cos’è una risposta corretta, per iscritto?
- Esiste un test set che riflette l’uso reale?
- Esiste una baseline con cui confrontare le modifiche?
- Il sistema ha un’identità propria e un accesso a privilegio minimo?
- Potete risalire dalla risposta sbagliata alla sua causa?
- Ogni modalità di guasto è progettata, non solo loggata?
- Quali sono i budget di costo e latenza, e cosa succede quando vengono superati?
- Chi risponde del comportamento di questo sistema tra un anno?
Un team che sa rispondere a tutte e dieci sta finendo un progetto di ingegneria. Un team che sa rispondere a tre ha una demo promettente — che è un’ottima cosa da avere, purché nessuno la chiami quasi finita.