Versionare prompt, modelli e logica del workflow come un’unica release AI

Una release AI è l’intera configurazione che può cambiare il comportamento servito, non il solo endpoint del modello o la stringa del prompt. Ripristinare il modello precedente lasciando attivi un nuovo schema dello strumento, una regola di autorizzazione diversa o un percorso di retry modificato non ricrea ciò che era stato verificato. Senza un’identità comune, il team fatica a stabilire quale configurazione abbia gestito una richiesta, quali evidenze ne abbiano autorizzato la distribuzione e quale insieme compatibile debba ricevere nuovamente il traffico.

Che cosa deve contare come un’unica release AI?

Deve contare come release l’insieme completo delle dipendenze che possono alterare il servizio effettivo. I sistemi AI di produzione comprendono configurazioni, verifiche, metadati, infrastruttura e monitoraggio oltre al modello; inoltre, le decisioni prese in un punto del ciclo di vita possono influire sulle fasi successive. Il confine preciso resta specifico del sistema: una dipendenza va inclusa quando può incidere materialmente su comportamento, autorità, rischio, costo, latenza od osservabilità.

• Prompt e istruzioni di sistema, con template, variabili e formato effettivamente risolti.
• Identificatore del modello, parametri di inferenza e impostazioni del fornitore realmente applicate.
• Schemi degli strumenti, permessi, approvazioni, policy, guardrail e azioni vietate.
• Configurazione di retrieval o contesto, workflow, schemi di input e output e dipendenze di runtime.
• Binding dell’ambiente, routing e collegamenti approvati che possono cambiare la gestione di una richiesta.

Dataset di valutazione, grader, rubriche e soglie non eseguono normalmente nel percorso di servizio, ma possono cambiare la decisione di promozione. Vanno quindi versionati e collegati alla release come asset di garanzia, senza confonderli con la configurazione di runtime. Lo stesso criterio vale per dipendenze interne o di terzi: entrano nel record solo se influenzano il servizio o l’interpretazione delle prove. Qualsiasi modifica rilevante a uno di questi elementi genera un nuovo candidato.

Come si lega lo stack comportamentale in un manifesto di release?

Lo stack si lega congelando un manifesto immutabile che assegna al candidato un ID e riferimenti stabili per ogni componente. Un alias come «production» o «latest» è soltanto un puntatore: il record deve conservare la versione, il commit, il digest dell’artefatto, l’hash del contenuto o un altro identificatore risolto, insieme alle impostazioni effettive. Questo è importante perché un registro può rendere immutabile il template del prompt lasciando modificabili alias o configurazioni associate.

• Identità: ID della release, data di creazione, proprietario, servizio target, stato e release precedente nota e funzionante.
• Componenti: prompt, snapshot del modello e parametri, strumenti, permessi, policy, retrieval, workflow, schemi e lock delle dipendenze.
• Ambiente: chiave del feature flag, regole di routing, collegamenti approvati e riferimenti a dati o indici, senza copiare segreti nel manifesto.
• Compatibilità: vincoli, migrazioni, contratti degli strumenti e verifiche necessarie per il target di rollback.
• Decisione: evidenze collegate, approvazioni, tappe di promozione, condizioni di arresto, responsabile del rollback e procedura per gli effetti esterni.

Per un assistente di supporto, support-assistant-r18 può legare il prompt p-42, lo snapshot m-2026-07, temperatura 0.2 e limite di output, lo schema CRM t-9, la policy policy-12, il commit wf-a71, lo schema reply-6 e il lock del runtime. Il pacchetto collega separatamente eval-23 e le versioni dei grader. support-assistant-r17 diventa target di rollback solo dopo aver verificato la compatibilità con i nuovi campi opzionali di scadenza ed escalation.

Le allocazioni di traffico e gli orari di distribuzione cambiano durante la promozione e appartengono quindi a eventi collegati, non al manifesto congelato. Un aumento di esposizione già approvato può riguardare lo stesso candidato. Se invece cambia una regola di routing o un binding che modifica contesto, autorità o comportamento per richiesta, occorre un nuovo ID. La provenienza resta così interrogabile senza dover ricostruire a posteriori cronologie indipendenti di prompt, modello e workflow.

Se qualcosa può cambiare il comportamento servito o le prove che lo autorizzano, deve avere un’identità risolta nel record della release.

Quali evidenze decidono se il candidato può avanzare?

La decisione deve basarsi su evidenze riferite all’esatto candidato che potrebbe essere promosso. Le note di release chiariscono intento comportamentale, dipendenze modificate, scenari e interfacce interessati, variazioni di permessi e osservabilità, limiti noti, rischio residuo, responsabili e target compatibile di rollback. Dataset, grader, rubriche e soglie sono anch’essi versionati: cambiare un gate può cambiare l’interpretazione dei risultati anche quando il runtime resta identico.

Le valutazioni generali del modello non descrivono ogni sfumatura di un workflow aziendale. Servono casi tratti dal lavoro reale, situazioni rare ma costose, controlli sui valutatori automatici e confronto con la release corrente. Un punteggio aggregato non può compensare una violazione materiale di contratto, autorità o sicurezza, né una regressione importante in un segmento. Ogni gate termina con «promuovere», «sospendere» o «respingere», una motivazione registrata e un responsabile nominato.

Per release a rischio maggiore, chi autorizza la promozione può essere diverso da chi ha preparato la modifica. Piattaforme di distribuzione permettono di applicare revisioni obbligatorie e verifiche esterne, ma il principio non dipende da uno strumento specifico. Anche un team piccolo deve conservare l’esito, le evidenze considerate e le eccezioni. Le soglie restano proprie del servizio: copiarne di universali produrrebbe una precisione apparente, non una decisione meglio fondata.

Come deve entrare in produzione lo stesso candidato?

Lo stesso candidato risolto deve attraversare tappe progressive, senza modifiche silenziose tra una tappa e l’altra. Le prove offline e il monitoraggio in esercizio sono complementari: nessuna delle due prospettive copre tutte le condizioni reali. Quando è possibile, si comincia con shadow traffic o replay non attuativo; gli strumenti di scrittura e gli altri effetti rilevanti vanno disabilitati o confinati in una sandbox, evitando di riprodurre ciecamente azioni di produzione.

1. Eseguire replay rappresentativi con azioni esterne disattivate e confrontare le tracce complete con la release corrente.
2. Aprire il candidato a un gruppo interno, mantenendo le approvazioni sulle azioni conseguenti.
3. Assegnare una coorte di produzione stabile al candidato e confrontare qualità, sicurezza, strumenti, affidabilità, latenza e costo.
4. Espandere l’esposizione soltanto dopo l’osservazione prevista, mantenendo immutata la configurazione risolta.
5. Passare al traffico completo e continuare il monitoraggio associato all’ID della release.

Quote di traffico, quantità di esempi e finestre temporali vanno scelte in funzione di rischio, volume, velocità con cui un problema diventa osservabile e capacità del team di intervenire. Una coorte stabile riduce la contaminazione tra esperienze, mentre eventi di distribuzione registrano regole, allocazione, tempi ed esito. Resta un limite essenziale: shadow traffic e canary possono non rappresentare ogni condizione di produzione o un guasto raro. Se cambia una dipendenza comportamentale, la promozione si interrompe e nasce un nuovo candidato.

Quando bisogna fermare la release e che cosa deve ripristinare il rollback?

La release deve fermarsi quando si verifica una condizione di arresto dichiarata prima dell’esposizione. Violazioni di sicurezza o policy, comportamento non autorizzato degli strumenti, rotture di contratto e gravi guasti di affidabilità richiedono un hard stop; per altre regressioni si applicano limiti specifici del servizio. Un segnale ambiguo può giustificare una pausa e un’indagine invece di un rollback automatico, ma anche questa scelta deve avere un esito, una motivazione e un responsabile espliciti.

Il rollback deve riportare il traffico verso l’intero bundle noto, funzionante e ancora compatibile, non verso un solo componente precedente. Prima della release occorre provare il percorso di ripristino e verificare schemi, stato persistente, migrazioni, contratti degli strumenti, routing e disponibilità del fornitore. Un target chiamato «precedente» non è automaticamente utilizzabile: una modifica ai dati o alle interfacce può aver eliminato la compatibilità necessaria.

• Registrare il trigger, l’ora della prima osservazione, la release e le coorti interessate.
• Confermare il target noto e funzionante e il risultato della verifica di compatibilità.
• Ripristinare il traffico e convalidare contratti, telemetria e percorsi essenziali.
• Individuare dalle tracce le richieste e gli identificatori delle azioni esterne coinvolte.
• Gestire contenimento, riconciliazione, correzione, notifica o compensazione con una procedura separata e autorizzata.

Il rollback della configurazione controlla le richieste future; non elimina messaggi, non annulla scritture di dati, non cancella approvazioni e non revoca automaticamente azioni già concluse in sistemi esterni. Nell’esempio dell’assistente, ripristinare r17 impedisce nuove azioni tramite r18, ma non elimina un’attività CRM già creata. Le tracce servono a trovare gli ID interessati; la risposta successiva dipende dal sistema, dalle autorizzazioni e dalle procedure qualificate dell’organizzazione.

Quale registro rende ricostruibile una release AI?

Il registro deve permettere di ricostruire la configurazione effettiva, le evidenze osservate e la decisione presa. Conserva il manifesto immutabile, identificatori e parametri risolti, binding dell’ambiente, verifiche di compatibilità, versioni e risultati delle valutazioni, approvazioni, eventi di distribuzione, allocazioni, riscontri, rollback ed esito finale. Collegare l’ID della release alle tracce attribuisce generazioni, chiamate agli strumenti, passaggi, guardrail, tempi e risultati al candidato che ha servito la richiesta.

• Versioni dei componenti, esecutori, tempi, parametri, artefatti e target precedente.
• Decisioni di promozione, proprietari, eccezioni e osservazioni per ogni tappa.
• ID delle richieste del fornitore e identificatori delle tracce applicative, quando disponibili.
• Richieste e azioni coinvolte in un rollback, con esito del ripristino e attività successive.
• Versioni aggiornate di test o monitoraggi introdotte dopo un problema.

Una traccia utile non richiede di conservare ogni prompt, input dello strumento, output del modello o payload del cliente. Gli identificatori, i metadati e i campioni governati possono essere separati dai contenuti sensibili; raccolta e durata di conservazione seguono le regole dell’organizzazione. Anche con snapshot, parametri e hash fissati, un modello stocastico o un servizio ospitato può non produrre lo stesso output. L’obiettivo corretto è la riproducibilità della configurazione e della decisione, non la replica byte per byte.

Il pacchetto minimo è quello che identifica senza ambiguità il candidato di runtime, le evidenze versionate che ne hanno sostenuto l’autorizzazione, le decisioni di promozione e un target di rollback compatibile. Quando la release modifica trattamento di dati sensibili, permessi rilevanti, workflow regolamentati, obblighi di conservazione o rimedi per azioni esterne, il team deve coinvolgere gli specialisti qualificati dell’organizzazione. Questo metodo operativo organizza le prove e le responsabilità, ma non determina da solo requisiti legali, di sicurezza, privacy o settore.