Dal proof of concept alla produzione: cosa cambia davvero

Dati veri, non dati scelti

Nel prototipo i dati li scegli tu. In produzione arrivano da un archivio con duecentomila file, metà duplicati e nomi come definitivo_v3_OK. Prima di collegare una fonte servono tre risposte scritte: chi ha il diritto di leggerla, quanto è aggiornata, chi la mantiene.

La terza è quella che nessuno vuole affrontare. Ogni archivio ha la sua massa di documenti orfani: procedure scritte da chi non lavora più lì, manuali fermi a un prodotto che non vendete più. Se li indicizzi senza dirlo, il sistema li citerà con la stessa sicurezza del listino di ieri.

La regola operativa è secca: ogni fonte nell’indice ha una data e un responsabile. Quello che non ha né l’una né l’altro resta fuori, oppure entra marcato come non ufficiale e il sistema lo dichiara nella risposta.

Chi vede cosa

In demo sono tutti amministratori. In produzione l’assistente deve ereditare i permessi di chi fa la domanda, non quelli dell’account tecnico che ha costruito l’indice.

L’errore classico è indicizzare tutto con un service account che vede ogni cartella. Funziona benissimo finché qualcuno del commerciale fa la domanda giusta e si ritrova in chat le buste paga. Il filtro va applicato al recupero dei documenti, non affidato al prompt: un’istruzione testuale non è un controllo di accesso.

Se nel flusso passano dati su persone identificabili valgono le domande che il GDPR pone da sempre: su quale base giuridica, con quanti dati al minimo, per quanto tempo si conservano i log, chi tratta cosa quando il modello gira da un fornitore esterno. Vanno chiuse prima di aprire l’accesso agli utenti.

Costi ricorrenti e secondi di attesa

Il proof of concept costa un pomeriggio di token su una carta aziendale. La produzione costa ogni giorno. E la voce grossa non è il listino a richiesta: sono i tentativi ripetuti, i contesti che si allungano mentre l’indice cresce, il ricalcolo degli embedding a ogni reindicizzazione, le ore di chi presidia il sistema.

Misura il costo per attività completata, non per token: è l’unico numero confrontabile con quanto costava farla a mano. Poi fissa un tetto mensile con un allarme e decidi prima cosa succede quando lo tocchi: modello più economico, coda, blocco. Un sistema senza tetto è una fattura aperta.

La latenza è l’altro costo, e lo pagano gli utenti. Dodici secondi in demo non li nota nessuno; quaranta volte al giorno fanno abbandonare lo strumento in due settimane, e nessuno ti dirà perché. Raramente la risposta è un modello più veloce: è una cache sulle domande ricorrenti, un recupero in meno, un prompt più corto. Conta anche dove vive: un assistente che obbliga ad aprire un’altra scheda perde contro lo strumento già aperto.

Quando il modello sbaglia

Sbaglierà. Il punto non è come impedirlo, è cosa succede nei dieci minuti successivi. Un sistema si giudica dal comportamento nel caso peggiore, e quel comportamento va progettato prima, non scoperto in escalation.

C’è poi un punto che l’AI Act mette in primo piano con il suo approccio basato sul rischio: chi riceve la risposta deve poter capire che dall’altra parte non c’è una persona, e chi adotta il sistema ha obblighi propri, distinti da quelli di chi lo fornisce. Dichiararlo nell’interfaccia costa una riga.

• Un fallback esplicito: quando le fonti mancano, il sistema dice che non lo sa e passa la mano, invece di produrre una risposta plausibile e sbagliata.
• Una soglia dichiarata di revisione umana: quali casi non escono senza la firma di una persona — importi, comunicazioni al cliente, decisioni sul personale.
• Tracciabilità: per ogni risposta devi poter ricostruire domanda, fonti usate, versione del prompt, versione del modello e orario. Quello che non ricostruisci non lo difendi davanti a un auditor.

Chi lo tiene in piedi dopo la consegna

Un prompt è codice: vive nel repository, con revisione, storico e test. Modificarlo in produzione dalla console di un tool, senza che nessuno sappia dire cosa c’era prima, è la versione moderna della query lanciata a mano sul database.

Lo stesso vale per i modelli. I fornitori aggiornano e ritirano versioni: l’output si sposta in modo sottile e per settimane non se ne accorge nessuno. Fissa la versione dove il fornitore lo consente e tieni trenta o cinquanta casi reali con la risposta attesa, da rilanciare a ogni cambio di prompt, di modello o di indice.

Resta la domanda che in troppi progetti non trova risposta: chi lo mantiene fra sei mesi. Serve un nome, non un reparto, con ore dedicate: aggiornare le fonti, guardare la spesa, leggere le segnalazioni, rilanciare i test. Se alla consegna nessuno sa dire quel nome, il sistema non è in produzione: è in prestito.

Prima di dire che è in produzione

Questa è la lista che compiliamo prima di dichiarare chiuso un passaggio in produzione. Va riempita con nomi e date, non con intenzioni.

Se manca una voce il sistema può partire lo stesso: basta dire che è un pilota, e per quanto tempo lo resta. Il danno non lo fa il prototipo in produzione, lo fa il prototipo che tutti chiamano produzione. Prova a compilare la lista sul tuo caso d’uso più promettente: le caselle vuote sono il piano di lavoro dei prossimi due mesi.

• Ogni fonte ha un responsabile, una data di aggiornamento e una regola su cosa farne quando invecchia.
• I permessi dell’utente finale sono applicati al recupero e verificati con un test da un account a bassi privilegi.
• Esiste un costo per attività completata misurato su volumi veri, un tetto mensile e un comportamento definito quando il tetto arriva.
• Esiste un fallback per il caso «non lo so» e un elenco scritto dei casi che richiedono la firma di una persona.
• Ogni risposta è ricostruibile a posteriori: input, fonti, versione del prompt, versione del modello.
• Un nome, con ore dedicate, che mantiene il sistema, e una batteria di test da rilanciare a ogni cambio.