I milestone AI vogliono gate, non ottimismo

La demo non è il milestone

Una demo AI è un artefatto di apprendimento utile, ma è un milestone prodotto pericoloso. Una demo dimostra che un percorso stretto può funzionare una volta, spesso con input amichevoli, un operatore paziente e una stanza piena di persone che vogliono vedere il successo. Un prodotto deve funzionare quando l’utente è distratto, l’input è sporco, la latenza si sente, l’output viene contestato e nessuno del team è accanto al workflow.

Per questo il milestone non dovrebbe essere demo completata. Dovrebbe essere gate superato. La tesi è semplice: i milestone di prodotto AI hanno bisogno di gate demo-to-product, non di ottimismo da lancio.

L’ottimismo da lancio sembra ragionevole perché la demo produce evidenza. Il modello ha risposto. L’agente ha chiamato il tool. La bozza generata sembrava buona. L’utente ha annuito. Il rischio è che questa evidenza sia quasi sempre evidenza di possibilità, non di prontezza. Chip Huyen descrive diversi errori comuni nelle applicazioni di generative AI che spiegano proprio questo passaggio: usare generative AI quando basterebbe un metodo più semplice, confondere un cattivo prodotto con una cattiva AI, partire troppo complessi, sopravvalutare il successo iniziale e rinunciare alla valutazione umana sistematica. Il suo punto, cioè che arrivare a una demo è molto più facile che arrivare a un prodotto, è il motivo per cui serve un gate prima di festeggiare il milestone in roadmap. Chip Huyen, Common pitfalls when building generative AI applications

Un gate non è burocrazia. È un rituale operativo breve che chiede se la demo regge le condizioni del workflow reale. Se non le regge, la decisione non è un fallimento. La decisione è tenere l’artefatto in modalità apprendimento invece di fingere che sia già un prodotto.

Cosa deve contenere un gate demo-to-product?

Il gate deve essere abbastanza piccolo da essere usato e abbastanza duro da contare. Per la maggior parte di product builder e technical PM AI bastano cinque controlli.

Primo, definire il baseline non-AI. Se il workflow può essere gestito con ricerca, regole, template, uno script deterministico o un approccio di machine learning più semplice, la versione AI deve battere quel baseline su una dimensione rilevante per l’utente. Non novità. Non entusiasmo interno. Una dimensione reale, come tempo di completamento, qualità della decisione, recupero dell’ambiguità, costo per task riuscito o riduzione dei passaggi di mano.

Secondo, testare l’inserimento nel workflow. La domanda non è se l’output del modello impressiona. La domanda è dove arriva nella giornata dell’utente. Arriva prima che la decisione sia presa? Costringe l’utente a riscrivere tutto? Crea una nuova coda di review che nessuno possiede? Chiede all’utente di scrivere in una casella vuota quando preferirebbe scegliere tra azioni suggerite? Qui molti team scambiano un problema di prodotto per un problema di AI.

Terzo, mettere un limite alla complessità. Il gate deve chiedere quali parti della demo sono necessarie e quali sono teatro architetturale. Togli il framework agentico se bastano chiamate dirette. Rimanda il fine-tuning se prompt e retrieval sono sufficienti. Evita di aggiungere un vector database prima di aver capito il problema di retrieval. È la stessa disciplina operativa di La scelta dei modelli parte dai task: scegliere il sistema attorno al portafoglio di task, non attorno al componente più interessante.

Quarto, richiedere valutazione umana. Gli eval automatici sono utili, ma non devono essere l’unico giudice prima del lancio. Un piccolo gruppo di reviewer di dominio dovrebbe ispezionare input reali o realistici, etichettare i fallimenti e scrivere cosa rende accettabile una risposta. Se le persone non riescono a concordare lo standard, il sistema non è pronto solo perché un LLM judge restituisce un punteggio alto.

Quinto, assegnare un failure budget e un owner. Il gate deve nominare le modalità di fallimento tollerate, il percorso di escalation e la persona responsabile per ogni rischio non risolto. Un workflow che ogni tanto produce una bozza debole è diverso da un workflow che invia istruzioni sbagliate ai clienti. Un assistente a basso rischio può partire con review visibile. Un’automazione ad alto rischio può richiedere limiti di permesso, code o rollback prima che qualsiasi promessa di produzione sia onesta. Questo è vicino all’argomento di AI confidence theater: servono workflow che reggono, ma il gate lo trasforma in una decisione di milestone, non in uno slogan culturale.

Quale domanda dovrebbe fermare il lancio?

La domanda più utile è: cosa ci farebbe vergognare di averlo chiamato production-ready?

Va fatta prima della launch review, non dopo l’incident review. La risposta di solito espone il buco nascosto. Forse la demo ha funzionato solo su esempi interni puliti. Forse l’utente non ha modo di correggere la risposta senza ricominciare. Forse la latenza è accettabile in una sala riunioni ma dolorosa nel workflow. Forse il tool può compiere un’azione che dovrebbe richiedere approvazione. Forse nessuno sa distinguere se un output sbagliato dipende dal prompt, dal retrieval, dalla scelta del modello, dal framing di prodotto o dall’input dell’utente.

Un buon gate trasforma queste ansie in controlli espliciti. Se il rischio è che l’assistente dia risposte plausibili ma incomplete, il gate richiede un set etichettato di esempi incompleti e una rubrica di review umana. Se il rischio è che gli utenti non si fidino dell’output, il gate richiede un test di workflow in cui gli utenti devono decidere se accettare, modificare o rifiutare il suggerimento. Se il rischio è azione non controllata, il gate richiede confini di permesso e una coda, non un’altra riga di prompt che chiede al modello di stare attento.

Questo conta perché le demo AI spesso nascondono il costo dell’ultimo miglio. Il successo iniziale può essere reale e comunque fuorviante. Il primo output utile dimostra che la direzione ha promessa. Non dimostra che il team conosca edge case, soglie di qualità, carico di supporto o fiducia degli utenti. Il gate protegge il team dal trasformare entusiasmo in impegno prematuro.

Dove il successo iniziale nasconde rischio

Il nascondiglio più comune è il passaggio dall’output del modello alla decisione dell’utente. Un summarizer può produrre un riassunto elegante e perdere l’unica action item che serviva. Un assistente di supporto può rispondere correttamente ma in modo poco utile. Un agente di coding può creare una patch che passa i test ignorando i criteri di accettazione, ed è per questo che AI coding: prima i criteri di accettazione vale anche oltre i team software. Lo standard di accettazione va definito prima che l’artefatto AI venga considerato finito.

Un altro nascondiglio è lo scope della valutazione. I team spesso testano più volte l’happy path perché l’happy path è disponibile. La produzione richiede il set scomodo: richieste ambigue, contesto parziale, permessi mancanti, formulazioni avversarie, dati vecchi, record duplicati e utenti che non seguono lo script della demo. Il gate deve obbligare il team a mostrare cosa succede fuori dalla corsia della demo.

Un terzo nascondiglio è la proprietà operativa. Una demo può essere portata avanti dal builder. Un prodotto ha bisogno di un operatore. Chi rivede il campione giornaliero? Chi cambia il prompt? Chi approva gli upgrade di modello? Chi monitora il costo? Chi decide che il tasso di errore è diventato troppo alto? Se la risposta a tutto è il team, la risposta reale è nessuno.

Fai audit di un workflow AI prima del lancio

Prendi una demo che viene discussa come pronta per la produzione e fai passare il gate per iscritto. Nomina il baseline. Descrivi il momento nel workflow. Rimuovi uno strato di complessità non necessario. Fai rivedere un campione di output a persone competenti. Definisci il failure budget. Assegna owner ai rischi che restano.

Il risultato può essere ancora un lancio. Può essere una beta più stretta. Può essere la decisione di spedire prima una funzione rule-based e tenere la versione AI in discovery. Tutte e tre le opzioni sono migliori che trasformare una buona demo in una promessa fragile.

Il punto di un gate demo-to-product non è rallentare il lavoro AI. È rendere il progresso leggibile. I team devono costruire demo, perché le demo rivelano possibilità. Ma il milestone che merita fiducia non è il momento in cui la demo funziona. È il momento in cui il workflow ha superato il gate.