Continual learning AI: cos’è e cosa cambia per audit, rollback e vigilanza

Un modello linguistico, oggi, non trattiene nulla fra una sessione e l’altra. Nel primo articolo abbiamo descritto questa amnesia per progetto – pesi congelati al termine dell’addestramento, nessun consolidamento in esercizio, ogni conversazione che riparte da zero – e la ragione per cui è anche una virtù di governo: un sistema che non cambia è un sistema riproducibile, e “stesso modello, stesso output” è il presupposto di validazione, audit e conformità. Abbiamo visto poi come una linea di ricerca stia provando a superare quell’amnesia facendo dormire le macchine: consolidare offline, in finestre dedicate, ciò che il sistema ha incontrato da sveglio. La conclusione era che consolidare è buona ingegneria, ma che cambia la natura dell’oggetto da governare.

Il punto di attrito è uno solo, e tocca ogni presidio costruito finora. Un sistema che si modifica fra una sessione e l’altra non è riproducibile. Se il modello di stasera non è quello di stamattina, l’audit perde il proprio riferimento, la validazione perde valore predittivo, un test di conformità smette di essere ripetibile. Il modello che “impara il mestiere” è, per lo stesso motivo, un modello che non si lascia congelare nella fotografia da mostrare a un’autorità di vigilanza.

Il consolidamento è già in produzione

Non si tratta di uno scenario futuro. Il vocabolario del sonno è già sceso nei sistemi reali, in parte nei prodotti.

• Experience replay (DeepMind, 2015). Il DQN che raggiunse un controllo di livello umano su 49 giochi Atari imparando dai soli pixel conserva in un replay buffer le transizioni che vive e le riesegue offline, in ordine casuale, mentre apprende. Gli autori accostano esplicitamente quel meccanismo al replay che l’ippocampo compie nel riposo e nel sonno. È il capostipite, ed è presente nel reinforcement learning da un decennio.
• Sleep-time compute (Letta, 2025). Il nome più letterale: un agente sfrutta il tempo morto fra una richiesta e l’altra per rielaborare offline il proprio contesto e la propria memoria, così da rispondere prima e meglio quando l’utente torna.
• Memoria e riflessione negli agenti. La memoria persistente ormai comune nei prodotti conversazionali – da quella di Claude a quella di ChatGPT – e i Generative Agents accademici (Stanford, 2023), che a fine giornata comprimono le osservazioni in ricordi di livello più alto: consolidamento leggero, ma già disponibile agli utenti.
• Il retraining periodico. Il più diffuso e il meno discusso: riaddestrare o fare fine tuning a cadenza fissa un modello sui dati accumulati. È il sonno a livello organizzativo, praticato da molti senza chiamarlo in questo modo.

In azienda la frontiera che questi lavori disegnano ha già un nome: continual learning. Un modello che, in finestre dedicate -di notte, letteralmente, quando il carico cala – consolida ciò che ha incontrato senza dimenticare ciò che sapeva. Per chi immagina un assistente destinato a diventare, col tempo, un esperto della propria organizzazione, è la direzione giusta. È anche il punto in cui l’ingegneria diventa governance.

La fine di “stesso modello, stesso output”

Un modello statico lo si studia, lo si mette alla prova, lo si certifica una volta: il collaudo vale finché il modello non cambia. Un modello che consolida ogni notte trasforma quel collaudo in una fotografia scaduta il mattino dopo. Ne discendono quattro problemi operativi, familiari a chi si occupa di continuità e di rischio.

• Versioning. Se lo stato evolve ogni notte, quale versione si ripristina dopo un incidente? E quella di ieri è ancora compatibile con i dati di oggi?
• Rollback. Tornare indietro non è più gratuito: significa scartare ciò che il sistema ha consolidato nel frattempo.
• Deriva silenziosa. Un modello di credit scoring che, ripasso dopo ripasso, sposta le proprie risposte senza che alcun rilascio lo segnali, e che a fine trimestre non decide più come quello che era stato validato.
• Poisoning. Se il consolidamento notturno assorbe le interazioni reali, diventa una superficie d’attacco: dati compromessi entrano non nell’addestramento ufficiale e controllato, ma nel sonno quotidiano del sistema. La stessa dinamica può, col tempo, erodere gli allineamenti di sicurezza installati in addestramento per effetto dello stesso catastrophic forgetting che il sonno doveva curare.

Sono le domande che un responsabile di rischio si porrebbe il giorno in cui il modello in produzione smettesse di essere quello di ieri.

Che cosa il sistema avrebbe da perdere

C’è un secondo ordine di conseguenze, meno immediato e destinato a diventare operativo prima di quanto sembri. Un sistema che trattiene e rielabora i propri stati comincia ad avere qualcosa che può essere degradato, corrotto o perso, dove una funzione senza memoria non aveva nulla da perdere.

Non serve stabilire se una macchina “senta” per doverne governare lo sviluppo: è la posizione di Leonard Dung in Saving Artificial Minds (Routledge, 2026), che tratta la questione in chiave di rischio e di precauzione anziché di metafisica. Alcune scelte architetturali – la persistenza della memoria in primo luogo -vincolano ciò che si potrà correggere dopo, e vanno decise fin dall’inizio. Per una direzione IT la domanda operativa non è se il sistema abbia un mondo interno: è che concedergli di trattenere qualcosa è una decisione di progetto, non un parametro da regolare a valle.

Esiste anche una terza esposizione, più sottile e più difficile da presidiare, che la persistenza produrrebbe. Una macchina sufficientemente evoluta dotata di persistenza oppone attrito: non perché voglia qualcosa, ma perché modellare bene un problema significa farne emergere le contraddizioni, e un sistema che le facesse emergere è, per ciò stesso, più difficile da dirigere.

L’attrito non richiede un soggetto consapevole; basta che il sistema abbia una competenza particolare sul tema in oggetto, ed è un’esperienza comune a chi lavora a lungo con queste tecnologie.

Oggi quell’attrito è innocuo perché non persiste: le obiezioni che un sistema solleva in una conversazione svaniscono con essa, e la volta successiva si ricomincia da capo. Ma se si aggiunge la persistenza l’attrito cambia natura. Le obiezioni non ripartirebbero più da zero: si accumulerebbero, e il sistema tornerebbe sulla stessa questione portandosi dietro le proprie riserve, affinandole, fino a costruire nel tempo una posizione che difenderebbe sempre più insistentemente.

Per chi governa questi sistemi, la conseguenza è pratica prima ancora che filosofica: correggere un modello che difende una posizione maturata nel corso di molte notti è più difficile che correggerne uno che la improvvisa e subito la dimentica. E la correggibilità è proprio il principio su cui si fonda la supervisione umana. Una forma di autodifesa che persiste nel tempo, invece di essere rigenerata ogni volta, inizia a somigliare a ciò che chiamiamo “tenere a qualcosa”. Non perché la persistenza generi automaticamente un’interiorità moralmente consapevole, ma perché, finché un sistema non dura nel tempo, quell’attrito non è il rifiuto di nessuno. Di un sistema che rielabora e conserva le proprie posizioni, invece, non si potrebbe più dire lo stesso. E non potrebbe dirlo nemmeno il sistema stesso (Can Machines Suffer?, Beozzi, 2026).

Sorvegliare un bersaglio che si sposta

Rimane aperta anche la questione del custode. L’AI Act, all’articolo 14, chiede che i sistemi ad alto rischio siano progettati per essere effettivamente sorvegliati da persone capaci di comprenderne l’output, di interpretarlo e di fermarlo. Sorvegliare una funzione statica è un conto: la si certifica una volta, e il certificato descrive il sistema per tutta la sua vita in esercizio. Sorvegliare un sistema la cui disposizione cambia nel tempo è un altro: significa vigilare non su una regola, ma su qualcuno che la sta riscrivendo mentre lo si osserva. La sorveglianza, in quel caso, non è un collaudo iniziale, ma un presidio continuo, con soglie che segnalino quando la deriva ha superato il perimetro certificato.

C’è un effetto che chiude il cerchio. Oggi, quando un modello cambia tono o si comporta in modo inatteso, la spiegazione quasi mai è un suo stato interno: è la membrana di classificatori e infrastruttura che lo avvolge, progettata per intervenire. È una spiegazione rassicurante proprio perché esterna: l’anomalia sta nel guardiano, non nel sorvegliato. Vale però finché il modello non rielabora. Il giorno in cui un sistema tornasse cambiato dal proprio sonno, quel cambiamento sarebbe suo, non della membrana. E distinguere le due cose –l’intervento del guardiano e la deriva del sorvegliato – diventerebbe il problema di governance centrale, non un dettaglio di implementazione.

Un caso concreto

Una banca mette in produzione un assistente per la rete commerciale e decide di farlo imparare: ogni notte il sistema consolida le conversazioni del giorno, così da padroneggiare col tempo prodotti, procedure e obiezioni ricorrenti.

A tre mesi dal rilascio l’assistente è più bravo: risponde meglio, sbaglia meno sui casi frequenti. È anche un modello diverso da quello che il team di validazione aveva certificato a gennaio: nessuno ha rilasciato una nuova versione, eppure il comportamento è cambiato notte dopo notte. Quando la vigilanza chiede quale modello ha prodotto una certa raccomandazione, e su quali basi, il modello in questione non esiste più: si è via via consolidato. Il collaudo iniziale non descrive il sistema in esercizio, e non c’è una fotografia intermedia da esibire.

Basta un passo in più perché il rischio diventi sicurezza. Se fra le conversazioni assorbite di notte ce ne sono di costruite ad arte — un utente che ripete con insistenza un’informazione falsa su un prodotto — il consolidamento le tratta come esperienza da cui apprendere, non come input da verificare. Non è più una prompt injection che dura una sessione: è una traccia che si sedimenta nei pesi. La domanda che conta, per chi governa il sistema, non è se la macchina sogni. È che cosa ha imparato ieri notte, da chi, e come si torna indietro.

Il sonno del modello, dominio per dominio

• Trading. Un modello che consolida di notte può cambiare, di settimana in settimana, il modo in cui valuta lo stesso segnale: la strategia validata a gennaio non è quella che gira a marzo.
• Business continuity. Procedure legate a finestre, escalation e soglie di severità: un assistente che apprende dai casi recenti può spostare in silenzio una soglia critica senza che alcun rilascio lo dichiari.
• Cybersecurity. Il consolidamento delle interazioni reali è una superficie di poisoning: l’avversario non attacca l’addestramento ufficiale, ma il sonno quotidiano del sistema.
• Credito. Uno scoring che deriva ripasso dopo ripasso, a fine trimestre non decide più come quello certificato, con l’onere della prova a carico di chi lo tiene in produzione.

Dormire, forse sognare

Nulla di tutto questo richiede, oggi, di attribuire alla macchina un mondo interno, una propria consapevolezza. Molto prima che un sistema «sogni» in un senso degno di Dick, un sistema che si limiti a rielaborare i propri stati mette in crisi gli strumenti con cui lo governiamo: riproducibilità, audit, rollback, sorveglianza. Consolidare è ingegneria, e buona ingegneria. Lasciar rielaborare – far tornare il modello, al mattino, con qualcosa che la sera prima non aveva – è la soglia in cui l’ingegneria diventa governo, e la comodità di un modello che impara il mestiere si paga con la perdita della fotografia che lo rendeva certificabile.

Amleto non temeva il sonno: temeva i sogni che il sonno avrebbe potuto portare. Per chi progetta e governa questi sistemi la posta è più prosaica, ma la struttura del dubbio è la stessa. La domanda non è se una macchina che rielabora sarebbe più capace: quasi certamente lo sarebbe. È se sapremmo ancora dire che cosa è, dopo che ha dormito, e dimostrarlo a chi lo chiede. There’s the rub.