Memoria degli agenti di IA: separare contesto, preferenze e fatti persistenti, e decidere quando scadono

Ricordare non significa conservare la cronologia

Un agente che assiste la stessa persona o lo stesso team in più occasioni ha bisogno di continuità: può essere ragionevole ricordare una lingua preferita, il formato abituale di una consegna o il nome di un progetto. Tuttavia, trasformare tutte le conversazioni, i documenti recuperati e le inferenze del modello in memoria riutilizzabile introduce un problema di governance. Il sistema può recuperare informazioni irrilevanti, obsolete, errate, sensibili oppure applicabili soltanto a una circostanza precedente.

La questione architetturale non è se l’agente disponga di memoria, ma quale specifica affermazione conservi, chi possa usarla, per quale scopo e per quanto tempo. Una frase come «il cliente preferisce approvare le modifiche via e-mail» può essere una preferenza dichiarata, un’osservazione dedotta da un singolo scambio oppure una regola operativa vigente. Queste interpretazioni hanno un valore diverso e non dovrebbero essere memorizzate né applicate nello stesso modo.

La memoria persistente non acquisisce autorità solo perché è stata memorizzata. Un’istruzione comparsa in una conversazione passata, in un documento importato o in un risultato di recupero rimane contenuto della fonte che l’ha fornita. Non deve prevalere su istruzioni di autorità superiore né abilitare azioni che l’agente non può compiere nel contesto attuale. Questa separazione è particolarmente importante quando il contenuto recuperato non è stato convalidato o potrebbe essere manipolato.

Per orientare questa guida è utile distinguere tra fatti di progettazione e decisioni di policy. È un fatto operativo che un sistema possa assegnare date di creazione, revisione o scadenza ai record. Decidere invece che una preferenza scada dopo novanta giorni è una policy dell’organizzazione: deve essere giustificata dal rischio, dalla volatilità del dato e dall’esperienza attesa, non presentata come una regola universale.

Quattro oggetti da separare

La parola «memoria» spesso mescola componenti con cicli di vita molto diversi. Separarli riduce i recuperi impropri e rende più comprensibile il comportamento dell’agente. Il contesto di sessione contiene lo scambio immediato necessario per interpretare la richiesta attuale. Dovrebbe essere limitato alla sessione e scomparire o diventare inaccessibile alla sua chiusura, salvo che una parte venga promossa deliberatamente a un’altra categoria.

Lo stato dell’attività rappresenta l’avanzamento di un lavoro specifico: identificativo di una richiesta, elementi già elaborati, bozza in corso, risultato parziale o passaggio in sospeso. Può dover sopravvivere a una breve interruzione, ma non per questo è una preferenza o un fatto da rendere disponibile nelle attività future. La documentazione degli strumenti di esecuzione per agenti di Google offre un esempio di stato del flusso di lavoro collegato a una sessione e di pulizia esplicita o tramite tempo di vita alla conclusione dell’attività o della conversazione.

La memoria dichiarata è l’informazione che una persona o un team ha fornito per assicurare continuità, come lingua preferita, fuso orario o convenzione di denominazione. Deve conservare la dichiarazione originale, o un riferimento a essa, oltre al suo ambito. Un’impostazione indicata per un progetto non deve necessariamente estendersi a tutti i progetti, né la preferenza di un membro del team deve essere attribuita all’intera organizzazione.

La conoscenza recuperabile raccoglie affermazioni ottenute da fonti identificabili: una policy interna vigente, lo stato di un servizio o un elenco di responsabili. La sua progettazione assomiglia meno a un profilo utente e più a un record di provenienza: fonte, versione o momento della consultazione, responsabile, ambito e condizioni di aggiornamento. L’ontologia PROV-O del W3C fornisce concetti per rappresentare entità, attività e agenti, nonché relazioni di generazione, derivazione e invalidazione. Non impone l’adozione di uno specifico database, ma aiuta a rendere esplicita la tracciabilità.

Il record minimo di un ricordo governabile

Un record non deve conservare il testo conversazionale completo per essere utile. In molti casi sono sufficienti un’affermazione normalizzata e metadati. Ad esempio, invece di conservare un intero dialogo, un record potrebbe indicare che una persona ha scelto di ricevere riepiloghi in spagnolo per uno specifico spazio di lavoro. La riduzione del contenuto non elimina tutti i rischi, ma limita l’esposizione e facilita l’ispezione.

Come minimo, ogni elemento dovrebbe includere un identificativo stabile; contenuto o riferimento al contenuto; proprietario o soggetto a cui è attribuito; finalità consentita; ambito di applicazione; fonte e modalità di acquisizione; livello di fiducia; data di creazione; data dell’ultima verifica; regola di scadenza; e stato di cancellazione o limitazione. Se deriva da altri dati, deve anche conservarne le dipendenze. In questo modo è possibile individuare quali ricordi richiedano una revisione quando una fonte cambia oppure quando una persona chiede una rettifica.

È opportuno distinguere il livello di fiducia dall’autorizzazione all’uso. Una preferenza dichiarata direttamente dalla persona può avere alta affidabilità riguardo a ciò che ha espresso, ma un ambito limitato. Un dato estratto automaticamente da un documento può essere potenzialmente utile, ma richiedere convalida umana o consultazione della fonte primaria prima di attivare un’azione. La fiducia non deve trasformarsi in un punteggio opaco che sostituisca la provenienza.

Per le informazioni personali, il Regolamento generale sulla protezione dei dati dell’Unione europea stabilisce principi di limitazione della finalità, minimizzazione, esattezza e limitazione della conservazione, insieme a diritti relativi a rettifica, cancellazione e limitazione del trattamento nelle condizioni applicabili. Un prodotto che operi in questo quadro deve tradurre tali principi in processi effettivi; aggiungere un campo chiamato «TTL» non dimostra di per sé la conformità giuridica.

Che cosa può persistere e che cosa dovrebbe scomparire

La persistenza deve essere decisa in base alla necessità funzionale e al rischio, non alla semplicità di archiviazione. Una preferenza esplicita e a basso impatto può persistere se ha un proprietario chiaro, una finalità concreta e una modalità accessibile per modificarla. Uno stato dell’attività viene normalmente eliminato al termine del lavoro. Un fatto esterno mutevole, come una tariffa, una policy o la disponibilità di un servizio, può essere conservato come indizio per il recupero, ma non dovrebbe essere trattato come prova vigente quando sta per essere presa una decisione rilevante.

Le inferenze meritano una categoria separata. Il fatto che il modello abbia dedotto che qualcuno preferisca comunicazioni brevi non equivale al fatto che quella persona lo abbia dichiarato. Se il prodotto decide di memorizzare inferenze, dovrebbe etichettarle come tali, ridurne l’ambito, prevedere una revisione breve e offrire un meccanismo semplice per confermarle, correggerle o scartarle. In scenari ad alto impatto, è più prudente non trasformare inferenze comportamentali in memoria persistente senza una decisione esplicita di prodotto e una valutazione dei rischi.

I dati sensibili richiedono una valutazione più rigorosa rispetto alle impostazioni di presentazione. La sensibilità dipende sia dalla natura del dato sia dal contesto, dal destinatario, dalla finalità e dalla giurisdizione. Questa guida non sostituisce l’analisi legale o di sicurezza. Come criterio di prodotto, la presenza di un dato sensibile non giustifica la sua persistenza: il team deve dimostrare una finalità specifica, controlli di accesso, una conservazione limitata e un processo efficace per gestire modifiche o cancellazioni quando necessario.

È inoltre importante non nascondere questa classificazione dietro un’unica etichetta di «memoria». L’interfaccia e le API interne dovrebbero riflettere le differenze: un utente può voler modificare una preferenza, annullare un’attività sospesa oppure contestare l’esattezza di un fatto proveniente da una fonte esterna. Si tratta di operazioni diverse, che richiedono tracce diverse.

Scadenza: espirazione, revisione ed eventi

Una data di scadenza risponde alla domanda su quando smettere di recuperare automaticamente un dato. Una revisione obbligatoria risponde a un’altra domanda: quando verificarlo di nuovo prima di considerarlo valido. Le due cose possono coesistere. Per esempio, una preferenza di formato può restare disponibile finché la persona non la modifica o la elimina, mentre una policy operativa può rimanere indicizzata ma richiedere la consultazione della sua fonte prima di essere usata per approvare un’azione.

Le regole basate su eventi integrano l’orologio. Un cambio di progetto, ruolo, fornitore, account o versione documentale può invalidare ricordi associati. Se un’affermazione dipende da una fonte specifica, l’aggiornamento o il ritiro di tale fonte dovrebbe attivare una revisione dei suoi derivati. Modellare derivazioni e invalidazioni consente di individuare l’insieme interessato invece di attendere che ogni elemento scada separatamente.

La scadenza non deve essere confusa con la cancellazione fisica immediata. Per motivi operativi o normativi possono esistere stati diversi, come «non recuperabile», «in attesa di cancellazione» o «conservato in base a una policy specifica». Per il comportamento dell’agente è essenziale che un elemento scaduto o limitato non rientri silenziosamente nel contesto della risposta. L’implementazione deve documentare chi possa accedere a ciascuno stato e per quale finalità.

Le tempistiche concrete non possono essere dedotte da una fonte tecnica generale. Devono derivare dalla finalità, dal tipo di dato, dal rischio di obsolescenza, dagli obblighi applicabili e dalle necessità operative. Un team può definire classi di conservazione, ma dovrebbe misurarne gli effetti: quanti ricordi scadono senza essere usati, quanti vengono corretti e quanti recuperi sono bloccati per assenza di validità.

Conflitti: istruzioni attuali, preferenze e fonti

Un conflitto frequente si presenta quando una preferenza ricordata contraddice la richiesta presente. La regola operativa più semplice è che la richiesta attuale della persona, entro i limiti di autorizzazione e sicurezza del sistema, prevalga su una preferenza precedente. Se qualcuno aveva chiesto risposte brevi ma ora richiede un’analisi dettagliata, l’agente deve soddisfare la richiesta attuale e, se opportuno, proporre l’aggiornamento della preferenza invece di modificarla silenziosamente.

La gerarchia delle istruzioni è indipendente dalla memoria. La specifica dei modelli di OpenAI descrive livelli di autorità delle istruzioni e indica che il contenuto non affidabile non acquisisce autorità solo perché compare in dati forniti o recuperati. Di conseguenza, un’istruzione memorizzata nella memoria dichiarata o incorporata da un documento non può annullare regole di autorità superiore. La progettazione deve conservare l’origine di ogni istruzione ed evitare che il recupero la presenti come un ordine di sistema.

Quando due fonti di conoscenza differiscono, l’agente non dovrebbe risolvere la discrepanza inventando una sintesi. Deve identificare che esiste un conflitto, preferire una fonte primaria o più recente secondo una policy definita, oppure chiedere intervento umano se la decisione ha conseguenze rilevanti. Il record di memoria deve contrassegnare gli elementi contestati affinché non vengano riutilizzati come fatti consolidati.

La correzione ha due dimensioni. Correggere il record principale evita che il dato continui a comparire in nuovi recuperi. Correggere i suoi derivati evita che sopravviva in riepiloghi, indici, cache, valutazioni o dati di addestramento del recupero, secondo l’architettura. Un processo di rettifica o cancellazione che aggiorna solo una tabella visibile ma lascia il dato negli indici che alimentano l’agente non raggiunge l’obiettivo operativo di impedirne il riutilizzo.

Rivalidare prima di un’azione esterna

La memoria può aiutare a formulare una risposta, ma non sempre è sufficiente per compiere un’azione esterna. Se l’agente sta per inviare informazioni, modificare un record, avviare una transazione, cambiare autorizzazioni o prendere una decisione con impatto, deve valutare la validità del dato che condiziona quell’azione. Quanto maggiore è l’impatto e quanto più mutevole è la fonte, tanto maggiore deve essere il requisito di consultazione o conferma.

L’evidenza di validità non è un’affermazione generica secondo cui il record ha «alta fiducia». Può consistere in una consultazione recente della fonte primaria autorizzata, in una conferma esplicita della persona competente o in un dato firmato e ancora valido secondo le regole del dominio. Il sistema dovrebbe registrare quale verifica sia stata effettuata, quando, rispetto a quale fonte e quale decisione abbia consentito. Se non può verificarlo, deve astenersi, ridurre l’ambito dell’azione oppure chiedere conferma.

Il progetto OWASP Gen AI Security identifica rischi associati all’avvelenamento della memoria e del contesto nelle applicazioni agentiche. In termini di progettazione, questo rafforza la necessità di separare il contenuto recuperato dalle istruzioni autorizzate, registrare la provenienza e osservare quali ricordi abbiano influenzato un’azione. Un filtro semantico da solo non garantisce che un ricordo sia affidabile né che sia appropriato per l’obiettivo attuale.

NIST propone nel proprio quadro di gestione del rischio dell’IA attività di governance, mappatura, misurazione e gestione, incluse la monitorizzazione e la documentazione durante l’operatività. Applicato alla memoria, ciò suggerisce di trattare recuperi falliti, ricordi obsoleti e correzioni ripetute come segnali misurabili di rischio, non soltanto come incidenti isolati di qualità.

Controlli di prodotto e test operativi

Una vista della memoria non è soltanto una pagina di configurazione. Deve consentire di capire quali dati usi l’agente e distinguere almeno tra preferenze dichiarate, fatti recuperabili, inferenze e stati dell’attività quando siano visibili alla persona. Per ciascun elemento, una presentazione utile include contenuto comprensibile, fonte o modalità di acquisizione, ambito, ultima revisione, data di scadenza e opzioni di modifica, limitazione o cancellazione quando applicabili.

Il registro d’uso è il complemento tecnico di tale vista. Davanti a una risposta problematica, il team deve poter ricostruire quali elementi siano stati recuperati, quali scartati, quali abbiano influenzato la decisione e se vi sia stata rivalidazione. Non è necessario esporre internamente tutti i dati a tutti gli operatori: anche i registri richiedono controlli di accesso, minimizzazione e tempi di conservazione. La tracciabilità deve supportare l’indagine senza diventare un’altra memoria illimitata.

I test devono coprire più del recupero corretto. Includi casi in cui un ricordo vecchio contraddice la richiesta attuale; una fonte è cambiata; un’inferenza è errata; una preferenza appartiene a un altro progetto; e un elemento eliminato compare in un riepilogo o in una cache. Per le azioni esterne, verifica che l’assenza di evidenza valida blocchi l’azione o richieda una conferma appropriata.

Misura i tassi di recupero di ricordi scaduti o fuori ambito, conflitti rilevati e non risolti, rettifiche, cancellazioni completate, blocchi dovuti alla mancanza di rivalidazione e azioni dipese dalla memoria. Queste metriche non dimostrano da sole che il sistema sia sicuro o conforme, ma rivelano dove la memoria stia diventando una fonte di decisioni difettose.

Checklist di distribuzione

Prima di attivare la memoria persistente, il team dovrebbe poter rispondere in modo verificabile a diverse domande: quali classi di dati conserva; chi ne è il proprietario; quale finalità giustifica ogni classe; come sia identificata la fonte; quando scada; quali eventi la invalidino; chi possa visualizzarla o modificarla; e che cosa accada negli indici, nelle cache e nei riepiloghi quando viene corretta o eliminata.

L’architettura non deve risolvere tutti i rischi mediante automazione. In alcuni domini, la risposta corretta è limitare la memoria a preferenze a basso impatto, tenere i fatti sensibili fuori dalla persistenza dell’agente oppure richiedere revisione umana per modifiche ad alto impatto. La continuità operativa non dipende dal ricordare di più, ma dal ricordare solo ciò che può essere governato.

Per ampliare il quadro, collega questa pratica ai contenuti di Learn sulla progettazione degli agenti, a Sicurezza per i rischi operativi e al Glossario per concordare termini quali provenienza, conservazione, ambito e rivalidazione. Mantenere un vocabolario comune evita che prodotto, ingegneria, dati e sicurezza usino «memoria» per riferirsi a meccanismi incompatibili.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.