Immagina un’azienda che ha fatto tutto bene.
Ha negoziato il contratto giusto, con le clausole di uscita al posto giusto. Quando decide di cambiare fornitore AI, l’export funziona: i documenti tornano indietro, le conversazioni tornano indietro, le configurazioni tornano indietro, ogni singolo byte è contabilizzato. Il vecchio provider è stato impeccabile, anche perché la legge non gli lasciava alternative.
Tre settimane dopo, qualcuno se ne accorge.
Il nuovo agente ha tutto ed è come se non sapesse niente. Ripropone la modifica al modulo legacy che il vecchio sistema aveva imparato a non toccare senza una verifica. Rifà l’errore sulla fatturazione che era stato corretto a marzo, e poi ad aprile, e poi mai più. Chiede spiegazioni su un’eccezione che nessuno ha mai scritto da nessuna parte, perché non ce n’era bisogno: il sistema la conosceva.
L’azienda ha esportato tutto. E ha scoperto, proprio in quel momento, di non avere portato via la cosa più importante.
Concediamo tutto all’obiezione
Prima di costruire un allarme, bisogna concedere parecchio terreno a un’obiezione seria: il problema della portabilità lo conosciamo già, e l’Europa lo sta affrontando in modo tutt’altro che ingenuo.
Il Data Act, applicabile dal 12 settembre 2025, non si limita a proclamare un generico diritto a riavere i propri dati. Per i servizi di trattamento dati che rientrano nel suo campo di applicazione impone di rimuovere gli ostacoli tecnici e contrattuali al cambio di fornitore. Parla di dati esportabili e, categoria interessante, di digital asset. Per alcune classi di servizi introduce un concetto ambizioso: la functional equivalence, l’idea che dopo lo switching il servizio di destinazione debba poter fare sostanzialmente quello che faceva quello di origine. E dal 12 gennaio 2027 i costi di switching spariscono del tutto.
È una risposta normativa molto più sofisticata della caricatura secondo cui Bruxelles starebbe regolamentando il cloud con categorie del Novecento. E la spinta continua: il pacchetto sulla sovranità tecnologica presentato il 3 giugno 2026 dichiara come obiettivo la capacità dell’Europa di sviluppare e controllare tecnologie, dati e infrastrutture strategiche riducendo le dipendenze da fornitori extra europei, e una consultazione dedicata alla data sovereignty, aperta fino all’8 settembre, sta mappando le dipendenze che limitano concretamente la capacità delle organizzazioni europee di usare e trasferire i propri dati.
Ho scritto più volte che la sovranità non abita nel data center, e questa politica sembra averlo capito meglio di molti suoi critici. Non confonde sovranità con autarchia. Non pretende che tutto sia europeo. Pretende che la dipendenza sia reversibile, che è la pretesa giusta.
Ed è esattamente qui che scatta il problema.
Mentre impariamo a rendere portabili i dati, l’oggetto da cui dipendiamo sta cambiando.
Il terzo oggetto
Con il software tradizionale era ragionevole pensare che la parte essenziale di un sistema fosse fatta di due cose: il software e i dati su cui operava. Potevi cambiare database, cloud o applicazione, e il problema fondamentale era preservare le informazioni insieme alla capacità di elaborarle. Tutta la disciplina della portabilità, contratti compresi, è costruita su questa coppia.
Con gli agenti compare un terzo oggetto, molto più strano: lo stato che il sistema ha accumulato lavorando.
Non è la cronologia delle conversazioni, che si esporta senza difficoltà e serve a poco. È ciò che l’agente ha imparato essere rilevante. Sono le sintesi che ha costruito dalle interazioni passate, le convenzioni che considera affidabili, le relazioni fra entità che ha dedotto, le correzioni ricevute nel tempo e assimilate. Dentro questo stato finiscono istruzioni organizzative, provenienza delle informazioni, regole che determinano quali strumenti usare in quali circostanze.
Non è un’astrazione da paper. Microsoft descrive ormai esplicitamente la memoria degli agenti come qualcosa che non si limita a conservare informazioni ma modifica il comportamento futuro del sistema, incluse le chiamate agli strumenti. E nel giugno 2026 il suo team di sicurezza ha aggiunto un’osservazione che vale più di molti convegni: una memoria persistente cambia il threat model. Un attaccante non ha più bisogno di riuscire in una singola interazione; può tentare di alterare gradualmente ciò che l’agente ricorderà e userà in seguito. La parte più sensibile, scrive Microsoft, è la memoria procedurale, quella che può ricordare quando si applica una procedura, quali controlli si possono saltare, quale strumento va usato.
Fermiamoci su questa frase, perché contiene già metà del saggio. Se la memoria procedurale è la più pericolosa da avvelenare, è perché è la più potente. E se è la più potente, è anche la più costosa da perdere.
Una trasformazione, non un archivio
Qui sta il punto concettuale che il dibattito sulla portabilità non ha ancora messo a fuoco.
La memoria di un agente non è un database. È una trasformazione del database.
Due organizzazioni potrebbero possedere esattamente gli stessi documenti e avere agenti completamente diversi, perché quei sistemi hanno imparato a considerare importanti parti differenti. O perché hanno consolidato diversamente le conversazioni precedenti. O perché uno ha imparato che una certa eccezione aziendale prevale sulla procedura standard e l’altro no.
La ricerca sulla memoria degli agenti va tutta in questa direzione: non archivi integrali di conversazioni, ma sistemi che consolidano le interazioni passate trasformandole in conoscenza riutilizzabile. Il valore non sta in ciò che è stato detto. Sta in ciò che il sistema ne ha ricavato.
La sovranità digitale tradizionale domanda: posso portare via i miei dati?
La domanda dell’era agentica è un’altra: posso portare via ciò che il sistema ha imparato dai miei dati?
Non è una sfumatura semantica. Potrebbe diventare una delle forme più potenti di lock-in dei prossimi anni.
Un anno dopo
Prendiamo una software house che usa quotidianamente un agente su decine di repository. È lo scenario che conosco meglio, e ha il pregio di essere misurabile.
All’inizio l’agente riceve il codice e alcune istruzioni. Dopo un anno, dispone di una rappresentazione molto più ricca dell’organizzazione. Sa che certe componenti legacy non si toccano senza una verifica precisa. Ha incontrato gli errori ricorrenti di quella base di codice, non gli errori ricorrenti in generale. Ha assimilato migliaia di correzioni umane, ognuna delle quali era un piccolo atto di formazione che nessuno ha registrato come tale. Conosce eccezioni che la documentazione formalizza male o non formalizza affatto, perché le organizzazioni vere funzionano così.
Se domani quella software house cambia provider, il repository si trasferisce. La documentazione si trasferisce. Gli issue si trasferiscono. Il Data Act, dove si applica, garantirà che tutto questo avvenga senza ostacoli e presto senza costi.
Ma il nuovo agente sarà nello stesso punto in cui era il vecchio?
No. Sarà al giorno uno, con un anno di correzioni da rifare. E ogni correzione rifatta è un costo che nessuna clausola contrattuale ha mai nominato.
Sovranità del contesto
Serve un nome per questa cosa, e lo propongo con la prudenza dovuta ai nomi nuovi: sovranità del contesto.
La definirei così: la capacità di un’organizzazione di controllare, ispezionare e trasferire lo stato informativo che determina il comportamento dei propri sistemi AI.
La parola «informativo» è scelta con cura, perché evita la metafora antropomorfica della mente, che qui sarebbe solo rumore. Non sto dicendo che l’organizzazione possieda una coscienza artificiale da rivendicare. Sto dicendo una cosa molto più concreta: fra i documenti originali e le decisioni dell’agente esiste ormai uno strato persistente di trasformazioni, e quello strato può diventare economicamente prezioso quanto i documenti stessi.
Il momento rende la questione meno teorica di quanto sembri. Nei dati pubblicati da OpenAI il 12 agosto, a giugno 2026 il traffico agentico misurato attraverso Codex rappresentava il 64% dei token complessivi prodotti da Codex e ChatGPT insieme, fra i clienti enterprise. Nello stesso dataset, gli utenti attivi settimanali di Codex fuori dall’ingegneria sono cresciuti da febbraio di 108 volte nel legal e di 41 nel recruiting, contro le 5 dell’engineering. Non è una misura dell’intero mercato, e va letta per quello che è, il dato di un singolo fornitore sui propri clienti. Ma il segnale è inequivocabile: il lavoro delegato agli agenti sta crescendo più in fretta del lavoro assistito.
E più lavoro si delega, più vale il contesto accumulato da chi lo esegue.
Il paradosso dell’interoperabilità
Il paradosso è che tutto questo accade mentre l’infrastruttura agentica diventa più interoperabile, non meno.
MCP è sotto la governance della Agentic AI Foundation della Linux Foundation, insieme ad AGENTS.md. A2A costruisce uno standard perché agenti di fornitori diversi possano parlarsi. La fondazione ha annunciato a metà agosto di aver raggiunto 247 organizzazioni aderenti, con nomi che vanno dalla finanza alle piattaforme. Gli standard aperti stanno facendo progressi reali, e chi li liquida come convenzioni di carta non ha guardato la velocità con cui stanno diventando infrastruttura.
Ma guardiamo che cosa standardizzano. MCP descrive come un agente accede a Jira. A2A permette a due agenti di dialogare. AGENTS.md rende portabili alcune istruzioni di progetto. Sono, per usare una parola sola, il corpo dell’agente: le sue interfacce, i suoi protocolli, i suoi attrezzi.
Nessuno di questi meccanismi garantisce che il nuovo agente possieda lo stato operativo del precedente.
Il risultato possibile è un ecosistema perfettamente interoperabile in superficie, nel quale cambiare modello è tecnicamente semplicissimo e organizzativamente costosissimo. Il corpo si sostituisce in un pomeriggio. La memoria resta dov’era.
È una forma di lock-in molto più sottile di quella del cloud, e vale la pena dirla senza giri di parole: non ti impedisce di uscire. Ti rende stupido quando esci.
Il dipendente che se ne va
La metafora giusta non viene dall’informatica. Viene dalle risorse umane.
Un’organizzazione può possedere tutti i documenti prodotti da una persona e perdere comunque una quantità enorme di conoscenza quando quella persona se ne va. Non perché abbia sottratto file. Perché esiste una differenza fra possedere l’archivio e sapere come quell’archivio va interpretato: quali documenti sono superati anche se nessuno li ha marcati come superati, quale eccezione prevale su quale regola, perché quella decisione del 2019 si fa ancora così.
Per secoli abbiamo chiamato questa cosa conoscenza tacita, e abbiamo accettato che fosse un attributo delle persone. Gli agenti la stanno industrializzando. Quello che prima evaporava con le dimissioni ora si accumula in un sistema, il che sembrerebbe un progresso, ed è un progresso, finché non ci si chiede di chi è il sistema.
L’analogia serve anche a evitare la soluzione sbagliata. In un’organizzazione umana non pretendiamo il dump completo della testa di un dipendente che se ne va, e non perché manchi la tecnologia: perché è la domanda sbagliata. Cerchiamo invece di ridurre la quantità di conoscenza critica che esiste soltanto in quella testa. Documentiamo, formalizziamo, facciamo affiancamento, scriviamo le procedure.
La stessa strategia può diventare una disciplina architetturale per gli agenti.
La conoscenza fuori dall’agente
Qui il discorso tocca il modo in cui si lavora davvero, e posso essere concreto.
Più conoscenza organizzativa riesci a spostare dal comportamento implicito dell’agente verso artefatti espliciti e versionabili, meno dipendi dalla sua memoria privata. I file di istruzioni come CLAUDE.md e AGENTS.md, gli architecture decision record, le specifiche formali, perfino un repository documentato con serietà: tutti questi oggetti acquistano un significato nuovo. Non sono soltanto il modo per ottenere risposte migliori dal modello di questa settimana. Sono strumenti di riduzione del lock-in cognitivo, perché vivono nel tuo repository, sotto il tuo controllo di versione, e ogni agente futuro li leggerà allo stesso modo.
Il principio si può dire in una riga: ciò che è importante per il comportamento dell’agente dovrebbe esistere, quando possibile, fuori dall’agente.
Non significa eliminare la memoria, che è precisamente ciò che rende utile un agente rispetto a un modello senza stato. Significa distinguere due cose che oggi si confondono: ciò che l’organizzazione vuole deliberatamente rendere persistente, e che allora merita di stare in un artefatto suo, e ciò che un particolare provider ha inferito per rendere il proprio prodotto più efficace, e che resta, finché nessuno pone la domanda, un vantaggio del provider travestito da servizio.
Dichiarata e derivata
La distinzione fra ciò che l’organizzazione rende persistente di proposito e ciò che il provider inferisce da solo merita di essere presa sul serio, perché le due memorie hanno nature giuridiche ed economiche diverse anche quando abitano lo stesso sistema.
La memoria dichiarata è quella che qualcuno ha scritto. L’utente dice all’assistente: ricordati che i rilasci si fanno il giovedì, che il cliente X vuole le fatture in quel formato, che quella cartella non si tocca. Sono istruzioni. Hanno un autore, una data, un contenuto leggibile. Se il fornitore le conserva in una forma ispezionabile, esportarle è un problema tecnico modesto, e chi le riceve dall’altra parte può ricaricarle quasi senza perdita.
La memoria derivata è un’altra cosa. Nessuno ha mai detto al sistema che le stime di quel team vanno prese con cautela: lo ha concluso da solo, dopo l’ennesimo scostamento. Nessuno ha scritto che la procedura ufficiale di deploy viene ignorata il venerdì: lo ha osservato. Queste conclusioni non hanno un autore umano, spesso non hanno una forma testuale stabile, e possono essere rappresentate in modi che dipendono interamente dall’architettura del fornitore.
Il paradosso è che la memoria derivata è di solito la più preziosa delle due. La dichiarata, per definizione, esiste già da qualche parte: qualcuno la sapeva abbastanza bene da dettarla. La derivata è conoscenza che l’organizzazione non sapeva di avere, o non aveva mai avuto il tempo di formulare. Ed è esattamente quella che, a contratto finito, nessuno oggi sa dire a chi appartenga.
C’è anche un risvolto di sicurezza, ed è il motivo per cui il lavoro di Microsoft sulla memoria non è un dettaglio da specialisti. Una memoria che modifica il comportamento futuro è una superficie di attacco: chi riesce ad avvelenarla non compromette una risposta, compromette una disposizione. Ma sicurezza e sovranità, qui, sono due facce dello stesso requisito. Per difendere la memoria bisogna poterla ispezionare, tracciare la provenienza di ciò che contiene, distinguere che cosa vi è entrato e perché. Che è, parola per parola, la stessa infrastruttura che servirebbe per esportarla. Un fornitore che sostiene di non poter rendere trasparente lo stato dei propri agenti sta anche dicendo qualcosa sulla propria capacità di proteggerlo.
Che cosa dice, e non dice, il Data Act
La parte regolatoria è più interessante di quanto mi aspettassi quando ho cominciato a studiarla, perché il Data Act usa categorie sorprendentemente adatte al problema, pur essendo nato prima del problema.
Non parla soltanto di dati: parla di digital asset. Impone ai provider, nei casi previsti, di specificare quali categorie possano essere portate via durante lo switching. E per alcune classi di servizi fissa l’obiettivo della functional equivalence.
La domanda da porre non è se il Data Act renda già portabile la memoria degli agenti: sarebbe una conclusione giuridica più forte di quanto testo e prassi oggi consentano, e non è il mio mestiere forzare i testi. La domanda interessante è un’altra.
Che cosa significherà functional equivalence quando il servizio non esegue semplicemente una funzione, ma accumula esperienza?
Se uso per tre anni un servizio agentico e poi lo sostituisco, quali elementi appartengono ai miei dati esportabili e ai miei digital asset? Le memorie create esplicitamente dall’utente, le istruzioni che ho scritto io, sembrano un caso semplice. Molto meno semplice è lo stato costruito con sintesi automatiche, ranking e inferenze proprietarie. E qui il regolamento contiene un confine che diventerà conteso: le informazioni legate al funzionamento interno del provider e ai suoi segreti commerciali restano protette. Una parte importante del valore della memoria potrebbe risiedere esattamente nel modo proprietario in cui il provider la consolida.
L’obiezione del provider
A questo punto un saggio onesto deve dare voce al provider, perché la sua obiezione è legittima e liquidarla sarebbe advocacy travestita da analisi.
Se un’azienda sviluppa un metodo migliore per costruire memoria a lungo termine, perché dovrebbe consegnare al concorrente il risultato del proprio vantaggio tecnologico? L’interoperabilità non può significare che ogni innovazione venga standardizzata nel momento in cui nasce: sarebbe il modo più rapido per fermare la ricerca in un campo che ne ha ancora molto bisogno.
La risposta non è «perché la sovranità viene prima». Le risposte a slogan non reggono i contratti.
La risposta è distinguere l’algoritmo dal risultato organizzativo. Non serve poter esportare il motore con cui il provider costruisce la memoria. È ragionevole invece pretendere che l’organizzazione possa conoscere e trasferire una rappresentazione sufficientemente completa dello stato che quel motore ha costruito usando la sua attività, i suoi documenti, le sue correzioni.
È la stessa distinzione che facciamo, senza accorgercene, fra un database e il DBMS. Non abbiamo bisogno del codice sorgente di PostgreSQL per esportare una tabella. Il modo in cui il motore organizza le pagine su disco è affare suo; le mie righe sono affare mio.
Il territorio che si apre qui non ha ancora un vocabolario: formati per le memorie degli agenti, provenienza delle inferenze, distinzione fra memoria dichiarata dall’utente e memoria derivata, livelli di confidenza, meccanismi per ricostruire un contesto presso un altro fornitore. Non proporrò uno standard, perché sarebbe prematuro e perché gli standard prematuri fanno più danni dei monopoli.
Propongo un criterio.
Le domande da fare adesso
In attesa di vocabolario e standard, qualcosa si può fare da subito, ed è aggiornare le domande che si pongono a un fornitore prima della firma. Le so riconoscere perché sono le domande che ho cominciato a fare io.
Il servizio accumula stato oltre la sessione? Sembra banale, ma molti contratti non permettono nemmeno di rispondere a questa. Se lo accumula, quale parte è ispezionabile dal cliente, in che forma, con quale granularità? Quale parte è esportabile, e in un formato documentato o in un dump opaco? Lo stato derivato dall’attività del cliente viene usato per migliorare il servizio reso ad altri, oppure resta segregato? E alla fine del rapporto che cosa succede: cancellazione certificata, restituzione, o silenzio contrattuale?
L’ultima domanda è la più rivelatrice, e conviene farla per iscritto: se fra tre anni vorremo andarcene, che cosa ci porteremo via oltre ai dati che vi abbiamo dato?
Un fornitore serio oggi risponderà in modo incompleto, perché il problema è nuovo per tutti. Ma c’è una differenza enorme fra chi risponde in modo incompleto e chi scopre la domanda in quel momento. La qualità dell’esitazione, in questi colloqui, è un dato tecnico.
Il test di uscita
La misura della sovranità di un sistema agentico non dovrebbe essere soltanto dove viene eseguito, né soltanto dove conserva i dati.
Dovrebbe essere la risposta a una domanda sola: se domani sostituisco il provider, quanta capacità organizzativa perdo?
Ho scritto pochi giorni fa, a proposito del Digital Markets Act, che il vero contenuto politico della portabilità è il prezzo dell’uscita. Gli agenti aggiungono a quel prezzo una voce nuova, che nessun listino espone: il costo di riaddestramento organizzativo, le settimane in cui il nuovo sistema rifà gli errori che il vecchio aveva smesso di fare, le eccezioni da rispiegare, la fiducia da ricostruire.
Questo test ridimensiona anche una certa retorica della sovereignty infrastructure. Possedere data center europei è importante. Avere modelli europei può esserlo altrettanto. Ma nessuna infrastruttura è davvero sovrana se la capacità accumulata di usarla appartiene implicitamente a un altro sistema. La Commissione definisce oggi la sovranità tecnologica come capacità di sviluppare e controllare tecnologie, dati e infrastrutture riducendo le dipendenze strategiche. Sono tre dimensioni giuste. Il decennio agentico ne aggiunge una quarta, che non ha bisogno di diventare uno slogan istituzionale per essere presa sul serio: il controllo sul contesto.
Ed è una prosecuzione naturale, non una rottura, dell’idea europea di apertura senza autarchia. La sovranità non richiede di possedere tutto. Richiede che il costo dell’uscita non diventi una forma di subordinazione.
La cosa che rende il caso dell’AI diverso da tutti i precedenti è la natura di quel costo. Non è una penale, non è un fee, non è nemmeno il famoso costo di migrazione dei dati che il Data Act sta smontando pezzo per pezzo.
È amnesia.
Chi possiede la cultura
Il prossimo monopolio digitale potrebbe non trattenere i nostri dati. Potrebbe lasciarceli portare via tutti, fino all’ultimo byte e con il sorriso, sapendo che ciò che conta davvero è quello che il sistema ha imparato a farne.
Vorrei chiudere lontano dai regolamenti, perché il fondo di questa storia non è regolatorio.
Ogni organizzazione possiede una quantità enorme di conoscenza che non coincide con i documenti che produce. È fatta di interpretazioni sedimentate, di eccezioni capite lentamente, delle ragioni per cui certe decisioni si prendono in un modo e non nell’altro anche quando nessuno sa più spiegare bene perché. Per secoli l’abbiamo chiamata cultura organizzativa, e l’abbiamo considerata inseparabile dalle persone che la incarnano.
L’AI sta iniziando a renderne una parte computazionale. Le interpretazioni si consolidano in memoria, le eccezioni diventano regole di comportamento, le correzioni si accumulano in uno stato che orienta le decisioni future. Qualcosa che è sempre stato di tutti e di nessuno, disperso nelle teste e nei corridoi, sta assumendo per la prima volta una forma tecnica: ispezionabile, trasferibile, e quindi possedibile.
Ed è proprio nel momento in cui la cultura diventa computazionale che la domanda smette di essere tecnica.
L’azienda della prima scena aveva letto bene il contratto. Aveva contato i byte. Le mancava una riga sola, quella che nessun contratto oggi contiene: alla fine del rapporto, ciò che il sistema ha imparato da noi torna a essere nostro.
Finché quella riga non esiste, ogni migrazione riuscita continuerà a somigliare a quel trasloco perfetto in cui gli scatoloni arrivano tutti, e la casa nuova non sa niente di noi.
Cosa ti porti a casa
Il Data Act è una risposta più sofisticata della sua caricatura: applicabile dal 12 settembre 2025, impone di rimuovere ostacoli tecnici e contrattuali allo switching fra servizi di trattamento dati, parla di dati esportabili e digital asset, introduce la functional equivalence e dal 12 gennaio 2027 vieta i costi di switching. Il pacchetto sulla sovranità tecnologica del 3 giugno 2026 e la consultazione sulla data sovereignty in chiusura l’8 settembre completano il quadro: l’Europa non pretende che tutto sia europeo, pretende che la dipendenza sia reversibile.
Mentre i dati diventano portabili, l’oggetto della dipendenza cambia. Fra i documenti e le decisioni di un agente si forma uno strato persistente: le sintesi che ha costruito, le convenzioni che considera affidabili, le eccezioni assimilate da migliaia di correzioni umane. Non è la cronologia delle conversazioni, e non è un database: è una trasformazione del database. Due organizzazioni con gli stessi documenti possono avere agenti completamente diversi.
Microsoft descrive la memoria degli agenti come qualcosa che non si limita a conservare informazioni ma modifica il comportamento futuro, e nel giugno 2026 ha scritto che una memoria persistente cambia il threat model: un attaccante può alterare gradualmente ciò che l’agente ricorderà, e la memoria procedurale, quella che decide quali controlli saltare e quali strumenti usare, è la parte più sensibile.
Il paradosso del momento: l’infrastruttura agentica sta diventando interoperabile, con MCP, AGENTS.md e A2A sotto governance aperte e 247 organizzazioni nella Agentic AI Foundation, proprio mentre cresce lo strato che nessuno standard copre. Si può standardizzare perfettamente il corpo dell’agente lasciandone proprietaria la memoria: un ecosistema dove cambiare modello è tecnicamente semplicissimo e organizzativamente costosissimo. È un lock-in che non ti impedisce di uscire. Ti rende stupido quando esci.
La delega sta accelerando e con lei il valore del contesto accumulato: nei dati pubblicati da OpenAI il 12 agosto, a giugno 2026 il traffico agentico via Codex valeva il 64% dei token enterprise complessivi di Codex e ChatGPT, e gli utenti attivi settimanali fuori dall’ingegneria sono cresciuti di 108 volte nel legal e di 41 nel recruiting da febbraio. Più lavoro deleghiamo, più ciò che il sistema ha imparato vale quanto i documenti da cui l’ha imparato.
La difesa non è pretendere l’export della testa dell’agente ma ridurre ciò che esiste soltanto lì dentro: spostare la conoscenza organizzativa dal comportamento implicito verso artefatti espliciti e versionabili. CLAUDE.md, AGENTS.md, ADR e specifiche smettono di essere solo modi per ottenere risposte migliori: diventano strumenti di riduzione del lock-in cognitivo. Ciò che è importante per il comportamento dell’agente dovrebbe esistere, quando possibile, fuori dall’agente.
La misura della sovranità di un sistema agentico non è dove viene eseguito né dove conserva i dati, ma la risposta a un test di uscita: se domani sostituisco il provider, quanta capacità organizzativa perdo? Nessuna infrastruttura è davvero sovrana se la capacità accumulata di usarla appartiene implicitamente a un altro sistema. Il costo dell’uscita, nell’AI, potrebbe non essere economico: potrebbe essere amnesia.
Domande e risposte
Il Data Act non risolve già il problema della portabilità?
Risolve il problema per cui è stato scritto, e lo fa in modo più sofisticato di quanto si racconti. Per i servizi di trattamento dati che rientrano nel suo campo di applicazione impone di rimuovere gli ostacoli tecnici e contrattuali al cambio di fornitore, prevede l’esportazione di dati e digital asset, introduce l’obiettivo della functional equivalence per alcune classi di servizi e dal 12 gennaio 2027 elimina i costi di switching. La domanda aperta è un’altra: che cosa significherà functional equivalence quando il servizio non esegue semplicemente una funzione ma accumula esperienza? Le memorie create esplicitamente dall’utente sembrano un caso semplice. Uno stato costruito con sintesi automatiche, ranking e inferenze proprietarie lo è molto meno, anche perché il regolamento protegge le informazioni legate al funzionamento interno del provider e ai suoi segreti commerciali, ed è proprio lì che può annidarsi una parte del valore.
Che cos'è lo «stato cognitivo» di un agente, concretamente?
Non è la cronologia delle conversazioni. È ciò che il sistema ha consolidato lavorando: le sintesi costruite dalle interazioni passate, le convenzioni che considera affidabili, le relazioni fra entità che ha dedotto, le correzioni ricevute e assimilate, le istruzioni organizzative e le regole che determinano quali strumenti usare in quali circostanze. Microsoft descrive questa memoria come qualcosa che non si limita a conservare informazioni ma modifica il comportamento futuro dell’agente, incluse le chiamate agli strumenti. La formulazione meno antropomorfica è anche la più utile: fra i documenti originali e le decisioni dell’agente esiste uno strato persistente di trasformazioni, e quello strato può valere economicamente quanto i documenti.
Perché gli standard aperti come MCP e A2A non bastano?
Perché standardizzano il corpo dell’agente, non il suo stato. MCP descrive come un agente accede agli strumenti, A2A permette ad agenti di fornitori diversi di parlarsi, AGENTS.md rende portabili alcune istruzioni di progetto. Sono progressi reali, e il fatto che MCP e AGENTS.md siano sotto la governance della Agentic AI Foundation della Linux Foundation, che ad agosto 2026 conta 247 organizzazioni, dimostra che l’interoperabilità agentica sta diventando infrastruttura. Ma nessuno di questi meccanismi garantisce che il nuovo agente possieda lo stato operativo del precedente. È possibile un ecosistema apparentemente interoperabile in cui cambiare modello sia tecnicamente semplicissimo e organizzativamente costosissimo.
Il provider non ha ragione a proteggere il proprio metodo di memoria?
Ha un’obiezione legittima e va presa sul serio: se un’azienda sviluppa un metodo migliore per costruire memoria a lungo termine, obbligarla a consegnarlo al concorrente significherebbe standardizzare ogni innovazione nel momento in cui nasce. La distinzione utile è fra l’algoritmo e il risultato organizzativo. Non serve poter esportare il motore con cui il provider consolida la memoria; è ragionevole invece pretendere che l’organizzazione possa conoscere e trasferire una rappresentazione sufficientemente completa dello stato che quel motore ha costruito usando la sua attività. È la stessa distinzione che facciamo fra un database e il DBMS: non serve il codice sorgente di PostgreSQL per esportare una tabella.
Cosa può fare concretamente un'organizzazione, oggi?
Applicare agli agenti la stessa strategia che si usa con le persone: non pretendere un dump della testa di chi se ne va, ma ridurre la quantità di conoscenza critica che esiste soltanto in quella testa. In pratica significa spostare la conoscenza organizzativa dal comportamento implicito dell’agente verso artefatti espliciti e versionabili: file di istruzioni come CLAUDE.md e AGENTS.md, architecture decision record, specifiche formali, documentazione che cattura le eccezioni invece di lasciarle alla memoria del sistema. E significa porre al fornitore una domanda che quasi nessun contratto oggi prevede: quali parti dello stato accumulato dal servizio sono ispezionabili ed esportabili, in quale formato, e che cosa ne resta quando il contratto finisce.
L'autore
