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

Una release AI non è il solo modello né la stringa del prompt: è l’intera configurazione che determina come una richiesta viene interpretata, instradata, autorizzata e osservata. Ripristinare il modello precedente lasciando attivi un nuovo schema degli strumenti, una policy diversa o un retry modificato significa effettuare un rollback soltanto nominale. Per sapere che cosa è stato valutato, che cosa ha servito una richiesta problematica e dove riportare il traffico, occorre assegnare una sola identità alla configurazione completa.

Che cosa deve contare come un’unica release AI?

Deve contare come un’unica release ogni insieme risolto di dipendenze che possa cambiare comportamento, autorità, rischio, costo, latenza oppure osservabilità del servizio. Il confine include quindi prompt, identificativo del modello e parametri di inferenza, contratti e permessi degli strumenti, policy e guardrail, configurazione del contesto, codice del workflow, schemi di ingresso e uscita, dipendenze runtime e binding ambientali rilevanti. Componenti interni o di terzi entrano nell’inventario solo quando possono produrre un effetto materiale.

Le risorse di valutazione richiedono un trattamento distinto. Dataset, valutatori, rubriche e soglie non appartengono normalmente al percorso che serve la richiesta, ma possono cambiare la decisione di autorizzare il rilascio. Vanno quindi versionati e collegati alla release come risorse di garanzia. La distinzione evita di confondere ciò che produce il comportamento con ciò che consente di giudicarlo, mantenendo però entrambi ricostruibili nello stesso fascicolo decisionale.

• Creare un nuovo candidato quando cambia un prompt, uno snapshot del modello o un parametro effettivo.
• Crearlo anche per modifiche a strumenti, permessi, policy, retrieval, workflow, schemi, dipendenze o binding che incidono sulle richieste.
• Conservare le cronologie dei singoli componenti, ma non usarle come sostituto dell’identità unitaria della release.

Come si lega lo stack comportamentale in un manifest?

Lo stack si lega congelando un manifest immutabile che identifica il candidato e risolve ogni puntatore modificabile. Il documento minimo indica ID della release, ora di creazione, responsabile, servizio destinatario, stato, condizioni di arresto, proprietario del rollback e configurazione precedente nota come funzionante. Per ogni componente registra versione, commit, digest dell’artefatto, hash del contenuto o altro riferimento stabile insieme alle impostazioni effettive. Alias come “production” o “latest” restano puntatori, non prove di ciò che è stato rilasciato.

Il manifest registra anche le connessioni approvate, il riferimento ai dati o al retrieval, l’identità del feature flag e i vincoli di routing, senza incorporare i segreti. Quote di traffico e orari di deployment appartengono invece a eventi di promozione collegati. Un aumento dell’esposizione già approvato può riguardare il medesimo candidato; un cambiamento del routing o di un binding che alteri contesto, autorità o comportamento per richiesta impone una nuova identità.

• support-assistant-r18 lega prompt p-42, snapshot m-2026-07 e relativi parametri, schema CRM t-9 e policy policy-12.
• Lo stesso manifest include commit wf-a71, schema di uscita reply-6 e lock delle dipendenze runtime.
• Il fascicolo collegato identifica suite eval-23, versioni dei valutatori, risultati, approvazioni e osservazioni del rollout.
• support-assistant-r17 resta destinazione di rollback solo dopo una verifica dei nuovi campi opzionali per scadenza ed escalation.

Questo esempio mostra perché la versione del prompt non basta. In alcuni registri il template è immutabile, mentre alias o configurazioni del modello possono ancora cambiare; inoltre un alias di famiglia del fornitore può risolvere uno snapshot diverso. La release deve pertanto conservare l’effettivo insieme risolto. Fissare uno snapshot riduce l’ambiguità, ma non garantisce risultati identici da un servizio stocastico o ospitato.

Se può cambiare il comportamento servito o l’evidenza che lo autorizza, deve avere un’identità risolta nel registro della release.

Quali evidenze devono decidere l’avanzamento del candidato?

L’avanzamento deve dipendere da evidenze riferite all’esatto candidato completo e terminare con una decisione registrata: promuovere, sospendere o respingere. Le note di release chiariscono intento comportamentale, dipendenze cambiate, scenari e interfacce interessati, variazioni di permessi o osservabilità, risultati, limiti noti, rischio residuo, proprietari del rollout e destinazione compatibile del rollback. In questo modo il gate risponde a una domanda operativa precisa, anziché accumulare punteggi privi di un decisore.

Il confronto deve includere la release corrente, esempi reali del workflow, segmenti importanti e casi limite rari ma costosi. Un punteggio medio favorevole non compensa una violazione materiale di contratto, autorità, sicurezza o prestazione in un segmento rilevante. Anche dataset, valutatori, rubriche e soglie vanno versionati: se cambia il criterio, cambia l’interpretazione del risultato pur restando identico il candidato runtime. I valutatori automatici richiedono controlli periodici e revisione competente del dominio.

• Verificare build, risoluzione del manifest, compatibilità degli schemi e caricamento delle dipendenze.
• Misurare qualità del compito, escalation, strumenti, affidabilità, latenza e costo rispetto alla release corrente.
• Controllare policy, confini dei dati, permessi, approvazioni e azioni vietate.
• Assegnare un responsabile all’esito e, per i rischi maggiori, separare autore della modifica e approvatore.

Come deve entrare in produzione lo stesso candidato?

Lo stesso candidato risolto deve avanzare attraverso esposizioni progressive e misurate, senza modifiche nascoste tra una fase e l’altra. Dove è praticabile, si comincia con shadow o replay non attuativo: gli strumenti di scrittura e gli altri effetti conseguenti vanno disabilitati o isolati, perché replicare alla cieca azioni di produzione potrebbe creare nuovi effetti reali. Si prosegue con utenti interni, una coorte di produzione stabile, un’esposizione ampliata e infine tutto il traffico.

Ogni evento registra regole della coorte, allocazione, momento iniziale, periodo di osservazione e decisione, collegandoli all’ID immutabile. Le assegnazioni stabili e la telemetria etichettata per release rendono più leggibile il confronto con la versione corrente. Quote di traffico, campioni e finestre devono derivare dal rischio del servizio, dal volume, dalla latenza di rilevazione e dalla capacità operativa: non esistono valori universali. Shadow e canary, inoltre, possono non rappresentare condizioni rare o l’intera produzione.

1. Eseguire il replay rappresentativo con azioni esterne disabilitate e confrontare le tracce complete.
2. Aprire il candidato al gruppo interno mantenendo le approvazioni sulle azioni conseguenti.
3. Usare una coorte di produzione stabile e confrontare segnali di compito, sicurezza, strumenti, affidabilità, latenza e costo.
4. Ampliare soltanto dopo le osservazioni previste, senza cambiare il candidato.
5. Passare al traffico completo conservando la release precedente come destinazione verificata per il periodo stabilito.

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

La release deve fermarsi quando emerge una condizione di arresto dichiarata in anticipo: violazione di sicurezza o policy, comportamento non autorizzato degli strumenti, rottura di un contratto oppure grave guasto di affidabilità. Per le altre regressioni valgono limiti specifici del servizio, non soglie copiate altrove. Un segnale ambiguo può giustificare una pausa e un’indagine invece di un rollback automatico, ma esito, responsabile e tempo della decisione devono comunque essere registrati.

Il rollback deve ripristinare il bundle completo, compatibile e noto come funzionante, non un componente isolato. Prima di indicare una release precedente come destinazione occorre verificare schemi, stato, migrazioni, contratti degli strumenti, routing, dipendenze e disponibilità dei fornitori. Il percorso di ripristino va provato prima dell’emergenza. Nel caso dell’assistente, r17 è utilizzabile soltanto se gestisce correttamente i campi opzionali introdotti da r18 e le relative transizioni di stato.

Il ripristino della configurazione controlla le richieste future; non elimina messaggi, non annulla scritture, non cancella approvazioni e non ritira azioni già completate in sistemi esterni. Le tracce etichettate per release servono a individuare richieste e identificativi delle azioni interessate. Da quel momento interviene un runbook separato e autorizzato per contenimento, riconciliazione, correzione, notifica, ripristino o compensazione, secondo il tipo di effetto e le responsabilità organizzative.

• Registrare trigger, primo momento osservato, release, coorte e percorsi interessati.
• Confermare destinazione nota come funzionante e risultato della verifica di compatibilità.
• Separare ora del ripristino del traffico e convalida tecnica dalle azioni correttive esterne.
• Chiudere con esito finale, responsabile del seguito e aggiornamenti necessari a valutazioni e monitoraggio.

Quale registro rende ricostruibile una release AI?

Una release diventa ricostruibile conservando un registro collegato della configurazione effettiva, dell’evidenza osservata e della decisione adottata. Il nucleo comprende manifest immutabile, identificativi e parametri risolti, binding ambientali, verifiche di compatibilità, versioni e risultati delle valutazioni, approvazioni, eventi di deployment, allocazioni, rilievi, rollback ed esito finale. Collegare l’ID della release alle tracce consente di attribuire generazioni, chiamate agli strumenti, handoff, guardrail, tempi ed esiti alla configurazione che li ha serviti.

Quando disponibili, vanno registrati sia l’identificativo della richiesta del fornitore sia quello della traccia applicativa, così da seguire un problema oltre i confini del sistema. Ciò non impone di trattenere ogni prompt, input di uno strumento, output o contenuto del cliente. Identificativi, risultati e campioni governati possono essere conservati separatamente dai payload sensibili, secondo le politiche aziendali su accesso, riservatezza e durata della conservazione.

• Identità e digest dei componenti, impostazioni effettive, attori e tempi.
• Evidenze di valutazione, limitazioni note, approvazioni ed eccezioni.
• Eventi di esposizione, coorti, tracce, rilievi e decisioni di promozione.
• Destinazione precedente, prova di compatibilità, rollback e azioni correttive collegate.

Il risultato è riproducibilità della configurazione e della decisione, non promessa di replica identica dell’output. Anche con snapshot fissati, parametri archiviati e richieste conservate, campionamento, infrastruttura ospitata e comportamento del fornitore possono limitare il replay. Conviene adottare il fascicolo più piccolo che identifichi candidato, garanzie, promozione e destinazione di rollback. Cambiamenti relativi a dati sensibili, permessi conseguenti, processi regolati o rimedi esterni richiedono il coinvolgimento delle funzioni qualificate dell’organizzazione.