Quale prompt ha preso quella decisione?
Quasi nessun team sa dire quale prompt, quale versione del modello e quale indice hanno prodotto una decisione AI. Vanno trattati come artefatti di rilascio e registrati con ogni decisione.
Prendete una decisione presa in produzione dalla vostra funzione AI tre settimane fa e fate una domanda semplice: quale prompt l'ha prodotta? Nella maggior parte dei team la risposta onesta è "probabilmente quello attuale, a meno che qualcuno non l'abbia cambiato". Non è una risposta che si può dare in una revisione di incidente, a un cliente o a un revisore.
Tre cose cambiano il comportamento, e nessuna passa dal rilascio
Il comportamento di una funzione AI non dipende solo dal codice. Il prompt decide come viene istruito il modello. Il modello decide come quelle istruzioni vengono interpretate. L'indice del retrieval decide quale contesto il modello vede. Basta cambiare una delle tre e lo stesso input può produrre una decisione diversa.
In molti sistemi nessuna delle tre passa da un rilascio. Il prompt sta in una riga di database o in un pannello di amministrazione e si modifica direttamente in produzione. Il modello è richiamato con un alias come "latest", e il fornitore sposta quell'alias su una versione nuova secondo il suo calendario. L'indice viene ricostruito da un job notturno. Nessuno rompe niente, eppure il comportamento si sposta, e quando qualcuno chiede perché non c'è niente con cui confrontare.
Trattarli come artefatti di rilascio
La soluzione non è un nuovo strumento. È la disciplina di rilascio che già applichiamo al codice, estesa alle parti che cambiano di più il comportamento.
Il prompt è codice: sta nel repository, passa dalla review, ha una versione e arriva in produzione con un rilascio. Il modello è una dipendenza: si fissa l'identificativo esatto di versione esposto dal fornitore, mai l'alias, e lo si aggiorna di proposito. Anche l'indice ha una versione, legata ai documenti e al modello di embedding che l'hanno costruito.
Per una software house .NET non c'è niente di nuovo da imparare: è la stessa cura che si mette nel fissare la versione di un pacchetto NuGet. Ogni modifica a uno dei tre passa dallo stesso cancello: set di eval sulla nuova combinazione, confronto con quella in produzione, poi rilascio. Il rollback è un redeploy della combinazione precedente, non un prompt riscritto a memoria.
Registrare la terna con ogni decisione
L'ultimo passo dà senso agli altri. Ogni decisione registra la terna su cui ha girato: versione del prompt, identificativo del modello, versione dell'indice, accanto a input e output.
Così una revisione di incidente parte dai fatti: questa decisione, questo prompt, questo modello, questi documenti. La si può riprodurre e confrontare col comportamento attuale. L'AI Act chiede ai sistemi ad alto rischio la registrazione automatica degli eventi; senza la terna, quel registro dice cosa è successo ma non su quale configurazione.
Non c'è niente di esotico: versioni, dipendenze fissate, cancelli di rilascio. Ci siamo solo dimenticati di applicarli alla parte del sistema che cambia di più il comportamento.
Dove vive oggi il prompt che avete in produzione, e sapreste dire quale versione ha preso le decisioni del mese scorso?