L’Europa e l’AI di frontiera che non controlla

Il 7 luglio la Commissione europea ha presentato un Action Plan su cybersicurezza e intelligenza artificiale. A firmarlo è Henna Virkkunen, che nella nuova Commissione porta una delega dal nome esplicito, sovranità tecnologica, sicurezza e democrazia, e che ha messo in fila un ragionamento semplice, l’AI sta cambiando il significato stesso della sicurezza informatica e l’Europa deve tenere il passo alle vulnerabilità che le nuove tecnologie si portano dietro. Nelle settimane precedenti, a Bruxelles, si leggeva un fatto molto preciso: un modello di frontiera, il Mythos di Anthropic, aveva mostrato di saper individuare vulnerabilità nascoste nel software, e un governo straniero aveva deciso di limitarne l’accesso a chi non è cittadino americano.

Per anni l’Europa ha scritto regole per un’intelligenza artificiale che non costruisce. Questo piano è il primo documento che lo dice ad alta voce, con parole sue: le capacità di frontiera nascono per lo più fuori dai confini dell’Unione, e la loro disponibilità dipende da processi decisi altrove, spesso poco trasparenti. La cybersicurezza, letta così, non è un problema di adempimento, è un problema di sovranità digitale.

Una capacità di valutazione da costruire

La prima mossa concreta è una capacità europea di valutazione dei modelli, che la Commissione vuole creare nel 2027. Servirà a esaminare i modelli di frontiera prima che arrivino sul mercato, anche dal lato della sicurezza informatica, a sostegno del lavoro dell’AI Office, con criteri pubblici per i valutatori indipendenti che vorranno candidarsi.

Sotto l’annuncio c’è un’ammissione. Oggi l’Europa non riesce a valutare da sola i modelli che pretende di regolare. L’AI Act le ha dato il diritto di chiedere che quei modelli vengano esaminati, questo piano riconosce che le manca il muscolo per farlo in proprio.

Il primo pezzo di quel muscolo arriva prima. ENISA, l’agenzia dell’Unione per la cybersicurezza, e il Centro comune di ricerca costruiranno entro fine 2026 una piattaforma europea sicura per mettere alla prova i modelli in ambienti simulati, portando competenza sull’uso sicuro dell’AI agli operatori dei settori critici, dalla finanza alla sanità, dall’energia ai trasporti fino alla pubblica amministrazione.

Quando a decidere l’accesso è un altro

Qui il piano tocca il nervo scoperto. Le capacità di frontiera, scrive la Commissione, si sviluppano quasi tutte fuori dall’Unione, e chi le vuole usare dipende da processi decisi altrove. Conoscerle e potervi accedere non riguarda soltanto la resilienza informatica, riguarda la sovranità tecnologica di un continente.

L’episodio Mythos serve da promemoria. Un modello capace di trovare falle nascoste diventa un’arma se finisce nelle mani sbagliate, uno strumento di difesa se resta in quelle giuste, però la mano che decide chi può usarlo, in quel caso, stava a Washington e non a Bruxelles. È l’idea del permesso revocabile portata su scala geopolitica: quando il permesso di usare una capacità può essere ritirato da qualcun altro, dall’esterno, la tua sovranità sui processi che quella capacità protegge è presa in prestito.

Somiglia alla competenza presa in prestito di cui scrivevo a proposito del nostro rapporto quotidiano con questi modelli, solo che qui il prestito non tocca una singola persona che smette di saper fare una cosa, tocca la capacità di un’intera economia di difendere le proprie infrastrutture.

Dal codice condiviso alla vulnerabilità che resta scoperta

Il secondo pilastro guarda dentro le organizzazioni. Il piano non chiede di aspettare, chiede di usare da subito le capacità di AI già disponibili, compresi i modelli aperti, per trovare e correggere le vulnerabilità più in fretta di prima, e per reagire quando un attacco è già in corso. Da qui a fine 2026 ENISA pubblicherà linee guida e buone pratiche, e aprirà un progetto pilota sulla resilienza del software libero critico, pensato per accelerare la correzione delle falle con l’aiuto dell’AI.

Il codice aperto, in questo disegno, pesa più di una bandiera ideologica. Resta la sola capacità che un’organizzazione può ispezionare riga per riga e far girare sulle proprie macchine, senza chiedere permesso a nessuno e senza che nessuno la spenga da lontano. La stessa falla che un modello di frontiera straniero potrebbe scovare al posto tuo, oggi, un modello aperto che controlli tu può aiutarti a chiuderla domani.

La difesa prima della norma

C’è un contrasto che vale la pena guardare in faccia. Nelle stesse settimane in cui prepara questo piano, l’Europa rallenta il suo stesso codice: il 29 giugno il Consiglio ha dato il via libera definitivo alla semplificazione dell’AI Act, che sposta in avanti gli obblighi sui sistemi ad alto rischio, al dicembre 2027 per quelli autonomi e all’agosto 2028 per quelli dentro i prodotti.

Frenare la regola e costruire la difesa, allo stesso tempo, sembra una contraddizione e invece è una sola mossa. Il baricentro si sposta da ciò che vietiamo prima a ciò che sappiamo fare adesso, dalla conformità alla capacità. È l’ansia da competitività dei rapporti Draghi e Letta tradotta in atti di governo, e cambia il modo in cui un CIO dovrebbe leggere la politica europea sull’AI.

La lettura solo per adempimento non basta più. Ciò che pesa davvero, sui tavoli dove si decide, è lo stesso metro che vale con gli agenti: la reversibilità, cioè il controllo su runtime, contesto e permessi e la rapidità con cui puoi fermare un processo e riportarlo indietro senza danni.

Sovranità digitale, da iniziare adesso

Il piano, in filigrana, detta anche cosa fare senza aspettare né l’agenzia del 2027 né la sfida europea di fine anno. C’è l’igiene di base da rafforzare e la sicurezza da mettere fin dentro la progettazione, come le regole sulla cybersicurezza già chiedono. Conviene poi iniziare a usare i modelli disponibili, anche quelli aperti, per scovare e chiudere le vulnerabilità e per rispondere quando un attacco è già partito. Merita attenzione, da qui a fine anno, la piattaforma di ENISA per la sperimentazione dei modelli, con le linee guida che arriveranno tra il terzo e il quarto trimestre.

E la dipendenza da un singolo modello di frontiera controllato da un altro Stato va trattata per quello che è, un’esposizione nella catena di fornitura che una decisione presa altrove può accendere o spegnere da un giorno all’altro.

L’occasione, per chi in Europa costruisce sicurezza e AI nello stesso posto, prende una forma concreta. Bruxelles lancerà entro fine 2026 una sfida europea per le soluzioni di cybersicurezza basate sull’AI, e sta studiando con la Banca europea per gli investimenti uno strumento pubblico che finanzi i progetti strategici, la frontiera dell’AI compresa. Attorno a una capacità sovrana, che si possa ispezionare e valutare in casa, si sta formando un mercato.

Il piano costruisce la capacità di valutare i modelli e gli strumenti per difendere le reti, e sono due cose che all’Europa mancano da tempo. Resta però, sui tavoli dove lavoro, una domanda a cui non ho ancora una risposta netta: si può davvero essere sovrani su una capacità che non hai costruito e che non riesci a vedere fino in fondo? Finché la risposta non è chiara, la sovranità digitale somiglia più a un cantiere aperto che a un traguardo raggiunto.


Il documento è l’Action Plan on Cybersecurity and Artificial Intelligence presentato dalla Commissione europea il 7 luglio 2026, con il comunicato integrale della Commissione. La struttura in tre pilastri e le scadenze operative sono ricostruite dal servizio di Agence Europe. Il via libera definitivo alla semplificazione dell’AI Act è del Consiglio dell’UE, 29 giugno 2026.

Chi può ancora dire di no

Sta diventando normale vedere un agente che si mette in moto da solo, magari perché è arrivata una nuova richiesta o perché qualcosa nel lavoro si è bloccato, prende in carico il compito, lo divide in molte parti più piccole e le affida ad altrettanti agenti che procedono in parallelo, ognuno nel suo spazio isolato, mentre lui tiene d’occhio quello che producono e rilancia i pezzi che si inceppano, fino a tornare con una proposta di modifica pronta da rivedere. Ai tavoli dove passo le giornate incontro sempre più persone che lavorano in questo modo, coordinando decine di agenti su progetti veri senza quasi più scrivere codice a mano.

Davanti a una scena del genere la domanda che viene subito è quanto sia autonomo il sistema, e per rispondere si è diffusa l’abitudine di usare una scala che assegna un numero e ti dice quanto sei avanti nel lavorare con l’AI. Quel numero è comodo proprio perché è uno solo, e per un po’ ha funzionato come misura veloce del rischio, ma finisce per nascondere la cosa che conta di più dentro un’impresa cognitiva, e cioè chi, in mezzo a tutto questo, può ancora dire di no e con quanta rapidità riesce a farlo.

Quanto lo lasci andare, quanti ne tieni insieme

La scala più citata è quella proposta da Steve Yegge in «Welcome to Gas Town», costruita su un asse solo che sale dal basso verso l’alto, da quando l’agente si limita a suggerire fino a quando arriva a gestire l’intera baracca per conto suo. Come modo per dire quanta fiducia riponi in un singolo agente funziona ancora bene, ma nel frattempo il lavoro è cambiato e la leva più importante è diventata un’altra, perché conta meno fino a che punto lasci andare un singolo agente e conta molto di più quanti agenti riesci a coordinare nello stesso momento. Sono due cose diverse, e Addy Osmani ha fatto bene a tenerle separate, mettendo su un asse l’autonomia del singolo e sull’altro la capacità di orchestrarne molti, dato che una persona bravissima a far lavorare in sicurezza cinquanta agenti in parallelo può benissimo restare prudente su quanto si fida di ciascuno di loro preso da solo.

Questo spostamento cambia il modo di ragionare sull’autonomia. Non è un livello da raggiungere né una medaglia da esibire mentre si sale di grado, è piuttosto un permesso, e come ogni permesso si concede quando serve e si ritira quando serve. Davanti a un compito, allora, la domanda giusta smette di essere quanto in alto posso spingermi e diventa quanto rischio quel compito è capace di sopportare, e quale prova mi permette di difendere la scelta di lasciarlo correre da solo.

Conta quanto pulito torni indietro

Per capire se un sistema sta lavorando con un’autonomia davvero alta mi appoggio a tre domande che devo a Osmani, e riguardano tutte la possibilità di correggere il tiro: con quanta rapidità mi accorgo se sta sbagliando, con quanta facilità posso annullare quello che ha fatto, e che cosa mi dimostrerebbe invece che sta andando nella direzione giusta. Quando le risposte sono che me ne accorgo tardi, che tornare indietro è complicato e che in fondo mi sto fidando del riassunto, di autonomia alta è rimasto soltanto il nome, e sotto c’è un azzardo con un cruscotto messo lì a rassicurare.

È qui che l’idea del permesso revocabile diventa concreta. La sovranità di un’organizzazione sui propri processi si misura da quanto in fretta riesce a fermarli e a riportare le cose com’erano senza fare danni, molto più che dal numero di agenti che riesce a mettere in moto. Un intervento delicato come la riscrittura del motore dei pagamenti, se è protetto da verifiche serie, da agenti che controllano il lavoro di altri agenti e da un ritorno indietro pulito, può sopportare un’autonomia molto più alta di un compito che tocca dei contenuti senza avere una fonte certa con cui confrontarsi. Il livello di autonomia dipende dal processo di verifica che gli abbiamo costruito attorno, molto più che dal nome che diamo al compito.

Il debito nascosto nel riassunto

Man mano che l’agente si prende carico di compiti ben delimitati, la verifica smette di passare dai tuoi occhi e si sposta sulle prove che l’agente stesso produce, come le verifiche automatiche che vanno a buon fine, le schermate, le registrazioni di quello che è successo e le istruzioni per riprodurre un problema. Da un lato è un guadagno, perché nel frattempo puoi occuparti d’altro o semplicemente andare a dormire, dall’altro è un rischio, perché la scorciatoia è sempre a portata di mano, e cioè prendere il riassunto che l’agente ti consegna e usarlo al posto della revisione vera, dando per scontato che basti.

Questa scorciatoia, nei miei appunti, ha un nome e si chiama debito cognitivo. Ogni volta che accetto un riassunto senza pretendere lo stesso corredo di prove che chiederei a una revisione fatta a mano, e cioè il confronto delle modifiche, le verifiche, le registrazioni e i rischi rimasti scoperti, contraggo un debito che prima o poi qualcuno dovrà ripagare, con gli interessi. Per questo, in un’organizzazione che lavora con gli agenti, la verifica diventa una forma di capitale, qualcosa che va costruito, va mantenuto e quando manca si nota subito. Nessun modello te la regala già pronta, è una capacità che l’impresa coltiva nel tempo. In «Pelle Digitale» ho provato a raccontare proprio questa membrana sottile che ci separa dalla macchina che agisce al posto nostro, ed è lì che il debito cognitivo comincia ad accendersi.

Anthropic ha misurato tutto questo osservando circa quattrocentomila sessioni di lavoro con Claude Code, raccolte tra l’ottobre del 2025 e l’aprile del 2026, e ne è uscito un quadro abbastanza chiaro, perché nella sessione tipica sono le persone a prendere circa il settanta per cento delle decisioni di pianificazione, quelle su cosa fare e su quando considerare finito il lavoro, mentre è il modello a prendere circa l’ottanta per cento delle decisioni di esecuzione, quelle su quali file toccare e quale comando eseguire. Letta con questi numeri, l’autonomia alta non toglie le persone dal processo ma le sposta di posto, portandole dal compiere ogni singolo passo al decidere in che direzione muovere quello successivo, e chi porta con sé più competenza del proprio ambito ottiene di più da ogni istruzione e se la cava meglio quando l’agente si blocca, perché sa rimettere a fuoco il problema invece di lasciar perdere.

Il contratto prima della corsa

Prima di lasciar partire un agente conviene mettere per iscritto, in modo breve, che cosa dovrà cercare di ottenere. Non serve un documento burocratico, basta un foglio chiaro che chiunque, compreso un altro agente, possa leggere per capire dove passano i confini. Osmani ne propone una forma pratica che trovo solida, e la riprendo adattandola al modo in cui ragiono io sui permessi.

La prima cosa da fissare è l’obiettivo, che va detto come risultato e non come attività, quindi non «usa questa tecnica» ma «porta il tempo di caricamento sotto il secondo». Attorno all’obiettivo si dispone tutto il resto, e cioè il perimetro entro cui l’agente può muoversi insieme alle cose che invece deve lasciar stare, i permessi con cui gli è concesso toccare il mondo fuori dal suo recinto, la condizione che gli dice quando fermarsi e che è meglio sia misurabile, le prove che confermano il risultato in modo indipendente da lui, il momento e la persona a cui deve passare la mano quando qualcosa si complica, e infine un limite prefissato di tempo, di tentativi e di token, che per questi sistemi sono la moneta con cui pagano il lavoro che fanno.

Su come funzionano davvero il runtime, il contesto e i permessi degli agenti mi sono già soffermato di recente, e non torno qui sui dettagli. Senza un contratto del genere, comunque, l’autonomia alta resta soltanto un atto di fede, e gli atti di fede, quando finiscono in produzione, prima o poi si pagano.

Più agenti lanci e più serve chi controlla

Il gradino più alto assomiglia a una piccola fabbrica. C’è un agente che fa da manager e si attiva quando arriva un compito, distribuisce il lavoro agli altri agenti, ne segue l’avanzamento, rilancia le parti fallite e porta all’attenzione di una persona soltanto le decisioni che richiedono davvero un occhio umano, mentre in ingresso riceve la coda del lavoro, che sia una lista di lavori da fare o un registro delle segnalazioni, e in uscita restituisce attività chiuse e proposte di modifica accompagnate dalle loro prove. Attorno a impostazioni di questo tipo stanno nascendo specifiche di orchestrazione costruite intorno a una lavagna dei compiti, in cui ogni problema riceve il proprio spazio di lavoro e il proprio agente, e la frontiera, per come la racconta Osmani, sono ormai fabbriche che non si fermano mai, con centinaia o addirittura migliaia di agenti al lavoro insieme.

A questa scala due trappole si aprono quasi da sole. La prima è un parallelismo solo apparente, che scatta quando lanci trenta agenti su porzioni di lavoro che si sovrappongono e invece di moltiplicare i risultati ti ritrovi con conflitti da risolvere e con decisioni prese due volte. La seconda è più insidiosa e riguarda noi, perché la tentazione è continuare a coordinare a mano ogni singola dipendenza mentre decine di agenti girano, un po’ come se ci ostinassimo a dirigere il traffico a un incrocio che ormai ha già i semafori. Sul mestiere del manager che passa dal gestire persone al gestire agenti ho scritto di recente, perché è lì che si decide la partita organizzativa più difficile.

Più agenti metti in campo e più diventa vitale una verifica che sia indipendente, con chi implementa tenuto separato da chi rivede, con chi prepara le prove distinto da chi ne controlla la qualità e con dei passaggi di approvazione diversi per accettare il lavoro finito. Le organizzazioni cognitive che vedo nascere si riconoscono proprio da questo, dal fatto che riescono a far lavorare molti agenti insieme e nello stesso tempo a tenere il permesso sempre revocabile, a ogni anello della catena.

Quanti agenti sai ancora fermare

Alla fine il vero collo di bottiglia resta sempre la verifica, più che l’ambizione o il numero di agenti che riusciamo a far girare, perché tutto si gioca su quanto in fretta ci accorgiamo di aver sbagliato e su quanto puliti riusciamo a tornare sui nostri passi. La postura più matura, per chi lavora con gli agenti, è un’autonomia calibrata, che sale di un gradino soltanto dopo che le prove per reggere quel gradino si sono accumulate e che accetta di restare bassa proprio là dove tornare indietro sarebbe difficile.

Mi porto dietro dai tavoli dove lavoro una convinzione che col tempo si è fatta netta. Il giorno in cui ci vanteremo di far girare mille agenti, la prova di essere davvero avanti starà tutta nella rapidità con cui possiamo ancora fermarli. Finché quella rapidità tiene il passo del lavoro che si avvia da solo il permesso resta revocabile e siamo al sicuro, e conviene costruire i processi perché resti così: il giorno in cui la lasciamo indietro avremo soltanto una fabbrica che non sappiamo più spegnere.


Lo spunto di partenza è l’articolo di Addy Osmani «Agentic Autonomy Levels». Le tre domande sulla reversibilità e la forma del contratto d’esecuzione vengono dal suo pezzo, mentre la lettura in chiave di permesso revocabile e di debito cognitivo è mia.

Harness engineering: runtime, contesto, permessi

Il modello non è quasi mai il problema. Adnan Masood, in un’analisi dell’aprile 2026 sul control plane degli agenti, riporta che il 65% dei fallimenti dei progetti AI in azienda non nasce da carenze di ragionamento del modello, ma da difetti dell’infrastruttura che gli sta intorno, dal contesto che va alla deriva agli schemi disallineati, fino allo stato che degrada nel tempo senza che nessuno se ne accorga. Lo stesso numero gira in più rassegne di settore, e dice una cosa scomoda per chi compra licenze guardando solo i benchmark. La parte che fa fallire i progetti sta altrove, in un livello, l’harness engineering, che fino a diciotto mesi fa nessuno chiamava per nome.

Adesso un nome ce l’ha. Si chiama harness engineering, ed è diventato il mestiere che separa una demo che impressiona in riunione da un agente che regge tre mesi in produzione senza che qualcuno debba riavviarlo a mano ogni venerdì.

Harness engineering, cosa c’è davvero intorno al modello

L’harness è l’infrastruttura di runtime che avvolge il loop di ragionamento di un LLM. Salesforce lo descrive bene con un’immagine edilizia: il framework, LangChain o un agent builder qualsiasi, è il progetto dell’edificio, l’harness è il cantiere dove l’agente lavora davvero. Un paper su arXiv di marzo 2026 sull’architettura degli agenti da terminale lo definisce come il livello che coordina, a runtime, la spedizione degli strumenti, la gestione del contesto, l’applicazione delle regole di sicurezza e la persistenza dello stato fra un turno e l’altro.

Tradotto per chi deve decidere: il modello è il motore, l’harness è tutto il resto dell’auto. Senza, hai un blocco di potenza che gira a vuoto.

Dentro questo livello vivono sei o sette sottosistemi che lavorano insieme. L’assemblaggio del contesto, che decide cosa entra nella finestra del modello a ogni passo. I contratti degli strumenti, gli schemi che il modello deve rispettare quando chiede un’azione. La memoria, che tiene insieme un compito lungo. L’osservabilità, che permette di capire cosa è successo quando qualcosa va storto. Il recupero degli errori e l’orchestrazione, che governano la danza tra modello, strumenti e dati. Ognuno di questi è un punto dove un prototipo elegante diventa fragile.

System design per un runtime che hallucina

C’è un’obiezione che chi ha background da systems engineer fa appena sente “harness engineering”: questo lo facciamo da decenni. Loop che persistono lo stato tra una chiamata e l’altra, validazione degli input prima dell’esecuzione, retry on failure, log per l’audit. È esattamente quello che scrivi quando avvolgi un’API esterna e pensi “forse dovrei gestire il timeout”.

Akshay Kokane, in un’analisi che gira molto tra chi costruisce sistemi agentici, mette la questione in modo diretto: l’harness engineering è al 90% system design che conosci già, applicato a un substrato nuovo. Il 10% rimanente è genuinamente diverso, perché il tuo sistema ora ha al centro un componente non deterministico che può hallucinar una tool call, restituire una risposta semanticamente sbagliata o perdere il filo dell’obiettivo dopo quaranta turni di conversazione.

La differenza concreta sta in un solo punto: con un’API tradizionale validi il formato dell’output, con un agente devi validare l’intento. La pipeline di permessi di Claude Code non controlla solo se una tool call è sintatticamente valida, controlla se il modello è autorizzato a volere quello che vuole. Il vecchio stack retry-and-log non basta più perché il problema non si trova nella risposta, si trova nella richiesta, prima che qualcosa venga eseguito.

Questo spiega anche perché il nome è arrivato adesso, e perché conviene tenerlo anche se sa di marketing. Chi entra nell’AI engineering senza anni di systems engineering alle spalle ha bisogno di un vocabolario per afferrare questi pattern. Chi conia quel vocabolario si prende conferenze, SEO e mindshare, certo, ma distribuisce anche conoscenza che altrimenti resterebbe dispersa nei thread di GitHub. Il termine vale la pena impararlo per ciò che descrive, non per chi lo promuove.

La regola che cambia tutto

C’è un principio che ricorre in ogni guida seria sull’argomento, e vale la pena fermarsi: il modello non deve mai eseguire direttamente uno strumento. Mai. Il modello restituisce una richiesta di azione strutturata, l’harness valida lo schema, controlla i permessi, esegue, e reinietta il risultato.

Sembra un dettaglio implementativo. È invece il punto in cui si gioca la sicurezza di un sistema agentico in azienda. Se l’agente può chiamare arbitrariamente comandi, basta una prompt injection ben costruita dentro un documento che l’agente legge, e quel comando viene eseguito con i permessi dell’agente. Il livello di mediazione, la validazione tra l’intenzione del modello e l’azione sul mondo, è ciò che distingue un assistente da un rischio operativo che gira con le credenziali aziendali.

Le tassonomie di rischio più mature classificano le azioni: sola lettura, finanziarie, distruttive. Per ognuna una matrice di permessi diversa. È il tipo di ingegneria noiosa che non finisce nei keynote e che decide se il progetto sopravvive al primo incidente.

Quattordicimila parole perse in un colpo solo

Avevo costruito un agente editoriale che lavora sul mio blog via MCP, e per settimane ha funzionato. Poi un giorno, su un articolo molto lungo, una singola operazione ha sovrascritto un post intero perché lo strumento che usavo riscriveva l’intero corpo invece di toccare il blocco giusto. Quattordicimila parole perse in un colpo. Il modello aveva ragionato benissimo, l’harness intorno non aveva il vincolo che serviva.

Da lì ho imparato sulla mia pelle quello che le aziende stanno scoprendo su scala enterprise: la fragilità non sta nell’intelligenza del modello, sta nell’assenza di guardrail attorno alle sue azioni. Avevo dovuto cambiare strategia, passare a edit chirurgici con verifica a vuoto prima di ogni scrittura, salvare lo stato prima di toccarlo. Harness engineering applicato a una redazione di una persona sola.

Birgitta Böckeler, in un modello mentale pubblicato ad aprile 2026, descrive l’harness come una combinazione di guide in avanti e sensori di ritorno che si autocorreggono prima che l’output arrivi sotto gli occhi di un umano. Distingue i controlli computazionali, i linter, i test, dalle verifiche inferenziali, un modello che giudica un altro modello. Chiude con una proposta netta: la harnessability, la capacità di un sistema di essere imbrigliato in modo affidabile, dovrebbe diventare un criterio di prima classe nelle decisioni di architettura. Alla pari del costo e delle prestazioni.

L’etica nascosta in un livello di software

Qui il discorso esce dall’ingegneria ed entra in un territorio che mi interessa da tempo. In Pelle Digitale ho provato a descrivere lo strato sottile dove l’umano e la macchina si toccano, la mediazione che decide cosa passa e cosa no. L’harness è esattamente questo, portato dentro l’azienda: il punto in cui decidiamo quanta autonomia diamo a un sistema, dove mettiamo i confini, cosa l’agente può fare da solo e cosa deve passare da una mano umana.

Le scelte che sembrano tecniche sono scelte di governance: quali azioni richiedono conferma, quali log conservare e per quanto tempo, visto che la memoria di un agente che processa dati personali resta soggetta a GDPR come qualsiasi altro trattamento, e chi risponde quando l’agente sbaglia. Domande che nessun modello, per quanto grande, risolve da solo: si affrontano progettando con cura il guscio che gli sta intorno.

Avevo già osservato come Anthropic abbia spostato l’esecuzione degli agenti dentro l’azienda lasciando la regia fuori, con sandbox self-hosted e tunnel MCP. Quella mossa ha senso solo se chi la riceve sa costruire l’harness dalla propria parte del confine. Il fornitore ti dà il motore e parte dell’infrastruttura, il resto è responsabilità tua.

Prodotto, non collante

La soglia di accesso a un harness funzionante è più bassa di quanto sembri. Nick T., ricercatore che ha documentato la costruzione di un harness senza toccare una riga di codice, mette la cosa in modo diretto: chiunque può aggiungere file Markdown a un repository e sentire la differenza già dalla sessione successiva. Il CLAUDE.md o l’AGENTS.md nella root del progetto viene caricato dal modello all’avvio come un briefing. Le convenzioni di naming, i comandi di build, le cose da non fare: tutto scritto una volta, disponibile a ogni sessione senza doverlo ripetere. Primo strato, non l’intero edificio, ma quello che separa il ripartire da zero ogni volta dall’avere un agente che sa già dove si trova.

Trattate l’harness come prodotto, non come collante. La tentazione è incollare insieme un framework open e qualche script. Funziona finché non smette, di solito al primo carico reale. Le aziende che scalano comprano la plumbing commodity, runtime gestiti e telemetria di base, e costruiscono in casa la parte proprietaria che riguarda i loro dati e i loro permessi.

Mettete l’osservabilità prima dell’autonomia. Un agente che fa cose senza che voi possiate ricostruire cosa ha fatto è un debito tecnico travestito da innovazione. Prima i log strutturati e i sensori, poi l’allargamento dei poteri.

Testate l’harness, non solo il modello. Le valutazioni di sicurezza serie non si limitano a controllare le risposte del modello: provano l’infrastruttura con injection, timeout, sovraccarico di strumenti. Il punto debole è quasi sempre lì.

L’harness engineering non elimina i rischi degli agenti autonomi, li rende governabili. È una differenza che conta, perché governabile significa che qualcuno può rispondere delle decisioni del sistema, e in azienda è esattamente la domanda da cui parte tutto il resto. Quanta autonomia dare a un sistema di cui capiamo fino in fondo solo il guscio è una scelta di governance, e la maturità di un’organizzazione si vede da quanto sa tenerla bassa proprio dove tornare indietro costa di più. Se l’argomento vi tocca da vicino, è il terreno su cui lavoro con CEO e CTO ogni settimana.


Spunto dall’analisi di Adnan Masood sul control plane degli agenti, dal modello mentale di Birgitta Böckeler sull’harness engineering e dall’analisi di Akshay Kokane su Agent Harness Is Just System Design With a New Name (Level Up Coding) e dall’analisi pratica di Nick T. su Harness Engineering: A Deep Dive Into the Buildable Harness via Markdown Files (AI Advances).

Manager di umani e di agenti: un mestiere che sta cambiando

A febbraio 2026 Harvard Business Review ha pubblicato un articolo a firma Suraj Srinivasan (Harvard Business School) e Vivienne Wei (Salesforce) sul nuovo ruolo del manager di agenti AI nelle aziende, intitolato To Thrive in the AI Era, Companies Need Agent Managers. Dentro c’è la giornata di Zach Stauber, support agent manager a Salesforce: comincia e finisce davanti a dashboard, scorecard e sistemi di osservabilità degli agenti. Non gestisce persone, gestisce una flotta di agenti AI che lavorano su supporto, vendite e marketing dentro Agentforce. Marc Benioff a luglio 2025 aveva già detto che Salesforce è passata da 9.000 a 5.000 ruoli nel customer support, riallocando il resto in vendite e customer success, e che gli agenti chiudono autonomamente l’85% dei ticket clienti.

Sembra una notizia di Silicon Valley, ed effettivamente il caso Salesforce è estremo. La categoria di lavoro che descrive però, quella del manager di agenti che orchestra un gruppo misto di umani e di sistemi automatizzati, sta arrivando a velocità inattesa anche dentro aziende italiane molto meno radicali. Lo vedo nei progetti di advisory che seguo, lo sto vivendo addosso io stesso nel modo in cui lavoro, e ho la sensazione che molti CEO italiani non abbiano ancora messo a fuoco quanto profondamente questo cambierà l’organigramma reale delle loro aziende entro 24 mesi.

A casa di chi costruisce AI, questo è già il presente

Lo studio Anthropic How AI Is Transforming Work at Anthropic, pubblicato il 4 dicembre 2025, ha analizzato 132 ingegneri e ricercatori interni, 53 interviste qualitative e i dati di uso di Claude Code. Un numero solo, fra i tanti che il paper mette sul tavolo, mi è rimasto in mente: il 27% del lavoro fatto con assistenza AI è lavoro che senza AI non sarebbe stato fatto affatto. Esperimenti che restavano nel cassetto, dashboard nice-to-have, documentazione interna sempre rinviata, strumenti che sarebbero costati troppo da prototipare a mano. Tutto questo adesso si fa, perché il costo marginale di iniziare è crollato.

Sotto quel 27% c’è una conseguenza meno raccontata, ma evidente nelle interviste: gli ingegneri Anthropic descrivono se stessi sempre più come supervisori, persone che danno indicazioni e controllano output, che indirizzano il lavoro invece di farlo direttamente. La quota di lavoro che dicono di poter “fully delegate” all’AI resta intorno al 10-20%, ma il restante 80-90% è collaborazione attiva, con il loro tempo che scivola dall’esecuzione diretta al controllo, dalla scrittura del codice alla revisione del codice scritto da Claude. Anthropic è il caso estremo perché Claude è il loro prodotto, ma la curva che descrivono è la stessa che vedo nei team di sviluppo italiani che hanno adottato Claude Code o Cursor o equivalenti negli ultimi sei mesi.

“Il McKinsey” che ha messo sul tavolo i numeri

A gennaio 2026, sul podcast All In, Bob Sternfels (global managing partner McKinsey) ha dichiarato che la sua azienda ha 60.000 dipendenti totali, di cui 25.000 agenti AI a fianco di 40.000 umani, con l’obiettivo di parità entro fine anno. Sul valore reale di quei 25.000 agenti il dibattito è aperto, e i concorrenti EY e PwC hanno fatto notare che una manciata di agenti ben fatti spesso produce più valore di una flotta numerosa. La notizia più seria di quella conferenza, come ho scritto in maggio, era però un’altra: McKinsey sta spostando una quota maggiore della remunerazione dei partner da cash a equity, perché i ricavi diventano volatili e il vecchio modello non regge più.

Una conseguenza che né McKinsey né i suoi concorrenti hanno ancora interiorizzato è questa: se metà della tua workforce è composta da agenti, hai bisogno di una struttura manageriale che gestisca gli agenti come si gestiscono le persone, ma con strumenti diversi.

Servono ruoli di accountability per le performance degli agenti, persone che ne misurino la qualità, che li riallenino quando deragliano, che decidano quando un caso va escalato a un umano. È esattamente quello che fa Stauber a Salesforce, ed è il primo abbozzo di una professione che fino a 18 mesi fa non esisteva.

Come sto vivendo io questo cambiamento

Mi è capitato negli ultimi mesi di trovarmi a fare il lavoro che fino a 24 mesi fa avrei diviso fra tre o quattro junior. Brief di scoping per un cliente, ricerca preliminare di mercato, prima stesura di un’offerta tecnica, analisi di documenti corposi, audit di una codebase. Quattro cose che richiedevano persone diverse, tempi distribuiti su settimane, riunioni di coordinamento. Adesso le orchestro da solo, con Claude Code che lavora sulla parte tecnica, Claude o GPT che mi preparano i deck e le bozze, RSS Intelligence che mi setaccia le fonti, MCP server che leggono i miei progetti aziendali su Biztrack e li trasformano in materiale per il cliente. Non è perfetto, non sempre regge, ma il salto di efficienza è reale.

Ed è qui che inizia il dubbio, quello che lo studio Anthropic intercetta nelle sue interviste e che condivido. Se il junior che avrebbe fatto la ricerca di mercato per me non lo faccio più assumere, perché un agente la fa decentemente in venti minuti, dove lo formerà la prossima generazione di consulenti e advisor? E se la prima bozza di un’offerta tecnica la scrive un agente che ho istruito sui miei pattern, quando avrò ancora il tempo e l’occasione di fare quel lavoro io stesso, con la lentezza che serve per capirlo davvero?

Su questo voglio essere chiaro: non sto facendo argomenti contro l’adozione dell’AI, su cui sono fra i più convinti. Sto argomentando per adottarla con la consapevolezza che ogni nuova efficienza implica una scelta di cosa non sviluppiamo più come capacità umana. La supervisione di un agente richiede competenza profonda dello stesso dominio che l’agente ha automatizzato. Se quella competenza non si forma più sul campo, fra due cicli generazionali la supervisione diventa nominale.

Il ruolo del manager si sta sdoppiando

Quello che osservo nelle aziende italiane medie con cui lavoro, fra le tecnologiche di Roma e le manifatturiere del Nord, è che la figura del manager si sta sdoppiando in due direzioni che convivono nella stessa persona.

Una direzione resta quella tradizionale, fatta di relazione umana fra persone: motivare un collega che attraversa un momento complicato, costruire e mantenere fiducia, gestire i conflitti che nascono inevitabilmente in ogni team, prendere decisioni su altre persone. Questa parte non viene erosa dall’AI, anzi: con team più piccoli e più senior, ogni decisione su una persona pesa di più, ogni riunione conta di più, ogni colloquio di sviluppo diventa più strategico. Il manager di umani non scompare, diventa più importante per quei pochi umani che resteranno nel team.

L’altra direzione è completamente nuova. Si tratta di definire i task degli agenti, scegliere il modello adatto al singolo carico, versionare i prompt come si versionano i contratti, monitorare derive e performance, decidere quando portare un agente da pilot a produzione e quando spegnerlo. Sono attività che assomigliano al lavoro di un product manager più che a quello di un people manager, ma vivono dentro lo stesso perimetro di responsabilità.

Il risultato è che il manager italiano del 2027 dovrà essere bilingue. Parlare la lingua delle persone e la lingua dei sistemi agentici. E queste due lingue si imparano in scuole molto diverse.

Ambizione, giudizio, creatività: cosa cerca davvero Sternfels

A Las Vegas, sempre a gennaio, Sternfels ha indicato che McKinsey cerca oggi nei candidati junior tre qualità precise: ambizione, giudizio, creatività. Sembra una lista da ufficio HR, ma se la leggi con la lente del lavoro che descrive Stauber a Salesforce, ti accorgi che è la descrizione esatta del manager di agenti.

L’ambizione conta perché chi gestisce agenti non ha più la routine del controllo gerarchico stretto, ha invece il problema di decidere cosa far fare di nuovo a un sistema che fa molto da solo. Il giudizio conta perché la quasi totalità delle decisioni operative la prendono gli agenti, e l’umano interviene proprio nei casi limite dove non ci sono regole chiare. Sulla creatività poggia tutto il resto, dato che definire bene un agente significa immaginare casi d’uso e prompt che non sono nel playbook esistente.

Tutte e tre queste organizzazioni stanno cercando le stesse tre competenze, e stanno cercandole in nuovi ruoli mentre tagliano in quelli vecchi. È lo scenario che le aziende italiane medie devono interiorizzare, perché succederà anche da loro, con due-tre anni di ritardo e a una scala più piccola, ma con la stessa logica.

Come imposto i progetti dove serve un manager di agenti

Quando un CEO italiano mi chiede come si prepara la sua azienda al manager di agenti, gli rispondo che non si prepara con un master di sei mesi né con un progetto di consulenza chiavi in mano. Si prepara mettendo subito un piccolo gruppo di manager attuali in condizione di lavorare quotidianamente con agenti veri, su task veri, e di imparare sul campo cosa va e cosa non va.

Praticamente significa scegliere un caso d’uso non strategico ma reale, dove il rischio è basso e l’apprendimento alto: drafting di prime risposte commerciali, analisi periodica di documentazione regolatoria, gestione della knowledge base interna. Poi serve dare al manager interno tutto lo stack per orchestrare l’agente, dall’accesso ai modelli alla dimestichezza con MCP e tool calling, fino al controllo dei prompt e alle dashboard di monitoraggio. Infine, e qui è il passaggio che vedo più trascurato, quel manager va valutato non sull’output diretto ma sulla qualità con cui gestisce l’agente, esattamente come Stauber a Salesforce.

Questa logica funziona meglio quando si appoggia su un’architettura AI dentro al perimetro aziendale, perché un manager italiano che orchestra agenti su dati di clientela o su documentazione sensibile non può farlo bene se gli agenti girano su infrastruttura americana sotto Cloud Act. Senza sovranità del dato, il manager diventa supervisore di un sistema di cui non controlla i confini, e la sua funzione si svuota.

Il rischio che non discutiamo abbastanza

C’è una parte del lavoro manageriale che la sostituzione con agenti rischia di erodere, e credo valga la pena nominarla con calma. È il mentoring informale, quello che succede quando un giovane fa una domanda a un collega più anziano in corridoio, quando un junior osserva un senior gestire una telefonata difficile, quando un team-leader passa mezz’ora con un nuovo assunto per capire come ragiona.

Quel sapere tacito, che le aziende trasmettono per contagio quotidiano, ha bisogno di numero. Servono junior che facciano domande e senior che rispondano, e servono spazi fisici e mentali dove l’asimmetria di esperienza si trasforma in relazione di apprendimento. Se gli agenti rispondono prima e meglio, i junior smettono di chiedere ai colleghi e i senior smettono di formare, e l’azienda smette di trasferire memoria operativa. È una perdita che non si vede nei KPI trimestrali, si vede nel decennio.

In Pelle Digitale ho provato a descrivere il modo in cui l’interfaccia digitale media le nostre relazioni e modifica anche quello che credevamo di sapere su noi stessi. Vale lo stesso, in modo più specifico, dentro le organizzazioni. Un’azienda dove l’interlocutore di prima istanza è un agente, e non più il collega di stanza, è un’organizzazione diversa nella sostanza, non solo nelle prestazioni. Il buon manager di agenti del 2027 dovrà difendere attivamente gli spazi dove l’apprendimento informale avviene fra umani, perché non avverrà più da solo.

La domanda da porsi

Settembre 2026 sarà probabilmente il primo trimestre in cui molte aziende italiane medie metteranno in piedi i primi prototipi seri di agentic adoption, dopo la prova generale del 2025 e i pilot del 2026. Per chi guida quelle aziende, e per chi guida funzioni dentro quelle aziende, una domanda che vale la pena tenere davanti è semplice. Quale manager della mia organizzazione è già di fatto un orchestratore di agenti senza ancora averlo dichiarato, e quale invece sta rifiutando di diventarlo perché ne percepisce l’aliquota di disagio? Perché il primo va riconosciuto e formalizzato in fretta, prima che lo riconosca un concorrente. E il secondo va ascoltato, perché la sua diffidenza spesso vede cose che chi è già dentro non vede più.

Guerra dei prezzi AI: la difendibilità si sposta sul controllo dell’inferenza

Il 13 giugno il Wall Street Journal ha raccontato la fuga verso i modelli cinesi: aziende e startup, sfiancate dal conto dei token, che spostano i carichi di lavoro su alternative più economiche e quasi sempre open source. Bradley Olson racconta di strumenti che fanno rimbalzare il lavoro da un modello all’altro, Claude o ChatGPT per i compiti che lo meritano, modelli aperti per tutto il resto. OpenAI e Anthropic, tutte e due con il fascicolo per la quotazione già depositato, stanno valutando di tagliare i prezzi.

Sotto la cronaca del taglio c’è un movimento più lento, e per chi quei sistemi li mette in produzione conta molto di più. La guerra dei prezzi AI sta spaccando il mercato in due, e le due metà non si difendono allo stesso modo. Da una parte i volumi, che scivolano verso il basso costo. Dall’altra il valore, che resta in alto, dove le capacità di frontiera sono ancora poche e ancora difficili da replicare.

I volumi seguono i modelli cinesi

Il pavimento dei prezzi lo ha colato DeepSeek, e da lì in giù si è mosso tutto il resto. Su OpenRouter, la piattaforma di instradamento che migliaia di sviluppatori usano per scegliere a chi mandare le proprie richieste, i modelli cinesi pesano oggi intorno al 46% del traffico identificato. Anthropic, Google e OpenAI messe insieme stanno sotto al 36. Un anno fa i cinesi erano sotto il due per cento. Qwen, DeepSeek, Kimi, GLM, MiniMax: nomi che fino a poco fa nessun ufficio acquisti pronunciava, e che adesso girano dentro metà dei flussi agentici del pianeta.

La ragione è prosaica, e la dice bene un investitore citato nel pezzo, Tommy Shaughnessy di Delphi: il modello è il costo più grosso per chi vende inferenza, e questi se lo ritrovano gratis. I laboratori cinesi rilasciano modelli di livello frontiera come pesi aperti, chi fa inferenza li serve a costo quasi azzerato, e il prezzo finale crolla a una frazione, da sette a cinquanta volte meno a seconda del confronto che si fa. Per moltissimo lavoro quotidiano, una sintesi o una classificazione o una bozza da rifinire, la differenza di qualità tra i modelli cinesi e quelli di punta semplicemente non si vede in busta paga. E nel frattempo i conti dei token diventano insostenibili: c’è chi, come Uber, ha bruciato l’intero budget AI dell’anno entro aprile.

Il prezzo basso ha un indirizzo

Un modello che costa quasi niente è comodo, fino al momento in cui ti accorgi da dove arriva, e che quel quasi niente per chi lo produce ha una funzione. GLM-5 di Zhipu è addestrato e servito su silicio Huawei Ascend, niente NVIDIA: per le imprese e gli enti cinesi quell’indipendenza dall’hardware americano vale più di un punto di benchmark. Distribuire frontiera come open weight, a costo zero per il mondo, è anche una mossa di quota e di influenza, un loss leader giocato su scala geopolitica.

Negli Stati Uniti la cosa ha già smesso di essere teorica. Ad aprile la commissione della Camera sul Partito Comunista Cinese ha aperto un’indagine su Airbnb e Anysphere per l’uso di modelli cinesi, segno che dentro un’app che usi ogni giorno può girare inferenza che a qualcuno, a Washington, non piace affatto. E l’Europa, in questa mappa, è quasi un buco: tanti utilizzatori, pochissimi produttori, con Mistral come eccezione più citata che strutturale. Dipendere da una sola sponda è un rischio già scomodo. Appoggiare il proprio lavoro su due sponde lontane, e su nessun pezzo di casa, è una postura che vale la pena guardare prima che diventi un vincolo.

Il routing come punto di controllo

Lo strumento che il Wall Street Journal descrive, quello che smista il lavoro tra modello esterno, sistema interno e open source self-hosted, è la cosa più importante dell’articolo, e quasi nessuno la nomina. Nel momento in cui i modelli diventano intercambiabili e quasi gratuiti, il pezzo di valore si sposta su chi decide dove va ogni richiesta, con quali regole, con quali dati, dentro quali confini. Orchestrazione, routing, inferenza locale: qui si gioca il margine, e qui si gioca la difendibilità.

È lo stesso filo che avevo provato a tirare quando una direttiva americana ha spento Fable 5 e Mythos 5 in tutto il mondo: in produzione vince meno il modello migliore e vince di più chi controlla l’instradamento e tiene l’inferenza vicina. Per chi compra in azienda, e ancora di più per una pubblica amministrazione o un settore regolato, questo livello smette di essere un dettaglio da architetti e diventa oggetto di governance, e materia da mettere a gara: la domanda da scrivere nel capitolato diventa chi orchestra, dove gira il carico, cosa esce dal perimetro, più che quale modello ci sia in fondo. È esattamente la direzione di prodotto su cui lavoro con LocalAI, inferenza che resta dentro casa.

La frontiera resta un permesso, non una proprietà

L’altra metà del cielo, quella del valore, ha una sua fragilità che il prezzo basso ci fa dimenticare. Le capacità di punta restano accessibili a condizioni decise da altri. Anthropic ha pubblicato la classe Mythos con due nomi e due regole: Fable con i guardrail, che dirotta le richieste su cyber, bio e chimica verso un modello più sorvegliato, e Mythos vero e proprio, senza freni pubblici, riservato a un programma ristretto. Sopra questa scelta industriale è arrivata la geopolitica, con il blocco all’export che ha staccato i modelli di frontiera dal resto del mondo da un giorno all’altro.

Chi costruisce sopra una API di frontiera costruisce sopra un permesso. Un permesso ottimo, potente, conveniente finché dura, e revocabile per ragioni che non dipendono da te: una direttiva o una decisione di sicurezza nazionale presa in un fuso orario lontano. Tenere tutto il valore della propria azienda dentro quel permesso è una scommessa che in pochi farebbero a occhi aperti, se la guardassero per quello che è.

Costruire da qui con quello che si controlla

Da questa biforcazione non si esce scegliendo una metà contro l’altra. La frontiera serve, per i compiti dove la differenza si vede e si paga. L’open economico serve, per il volume. Quello che cambia è dove si mette il proprio baricentro, e quanto del proprio destino si lascia in mano a un listino o a un permesso altrui.

Per un’organizzazione che parte adesso, e parte da qui, il punto fermo viene prima della tecnologia. Prima il metodo, la mappa di quello che quel processo fa davvero, di quali dati non possono uscire, di dove la frontiera vale il prezzo e dove i modelli cinesi aperti bastano e avanzano. Poi la tecnologia, scelta su quella mappa: orchestrazione propria, inferenza che si può portare in casa, libertà di cambiare modello senza riscrivere l’azienda. In Pelle Digitale avevo descritto la tecnologia come una superficie che ci portiamo addosso, e una pelle si sceglie con cura, non si appalta al primo che la regala. La velocità di mettere AI in produzione, ormai, ce l’avranno tutti. La difendibilità, quella, resta di chi controlla il proprio stack.

Senza dubbio la domanda che lascio aperta è semplice: del valore che la tua azienda affida all’AI, quanta parte vive su qualcosa che puoi spegnere tu, e quanta su qualcosa che possono spegnere altri?

Come usiamo l’AI nel 2026: l’uso emotivo che sorpassa il tecnico

Il primo giugno 2026 Harvard Business Review ha pubblicato la terza edizione di “How People Are Really Using AI”, la ricerca che Marc Zao-Sanders porta avanti dal 2023 dentro il progetto AI in the Wild. Quest’anno ha analizzato oltre dodicimila casi d’uso reali, raccolti per dodici mesi da post pubblici sui social, dieci volte il campione dell’edizione precedente. Il dato che resta in testa dopo aver chiuso la pagina non riguarda il coding né la produttività, riguarda noi, e in particolare un uso emotivo che ha superato quello tecnico.

In cima alla classifica, per il secondo anno consecutivo, c’è la terapia e la compagnia. Non l’automazione di un processo, non la generazione di codice, non l’analisi di dati. Le persone aprono un modello di linguaggio per parlare di sé, e lo fanno più di prima.

La voce numero uno è emotiva

Zao-Sanders riporta che terapia e compagnia oggi valgono circa l’11% di tutto il dataset, contro il 5% di dodici mesi fa. In un anno l’uso emotivo è raddoppiato in peso relativo, mentre gli usi tecnici scivolavano verso il basso della classifica. Generare codice per professionisti, che nel 2025 stava al quinto posto, lascia spazio a categorie come l’intrattenimento, i consigli sulle relazioni, perfino l’astrologia e le letture dei tarocchi.

C’è una lettura comoda di questo dato, quella che lo derubrica a curiosità statistica. La gente si annoia, chiacchiera con il chatbot, niente di serio. Io credo che sia il contrario, e che dentro quel raddoppio ci sia il fenomeno culturale più interessante degli ultimi anni. La macchina che avevamo costruito per scrivere email e risolvere problemi tecnici è diventata, per milioni di persone, un interlocutore sulle cose che contano davvero, la solitudine, il senso, le relazioni.

In Pelle Digitale avevo provato a descrivere la tecnologia come estensione cognitiva, una superficie che si appoggia alla mente e ne allarga il raggio. Quello che vedo nei dati di Zao-Sanders è qualcosa di più intimo, l’estensione ha smesso di toccare solo il pensiero e ha iniziato a toccare l’affetto.

Fonte: elaborazione su dati Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review.

Thinkslop, quando deleghiamo il pensiero

L’edizione di quest’anno introduce un termine che vale la pena tenere, thinkslop. La preoccupazione non è più che la macchina scriva al posto nostro, quella battaglia è persa da tempo e a conti fatti non era nemmeno così grave. La preoccupazione è che le deleghiamo il pensiero stesso, le decisioni, le idee, le intenzioni, cioè proprio le funzioni in cui restiamo, almeno per ora, insostituibili.

Qui mi fermo, perché è il punto dove la mia esperienza personale si scontra con il dato. Uso modelli ogni giorno, in ICONICO e in ZeroFive.AI, e ho imparato a riconoscere il momento esatto in cui smetto di pensare e comincio solo a copiare. È un attrito che sparisce senza che te ne accorga, una scivolata morbida verso la risposta pronta. Il debito cognitivo di cui ho scritto altrove funziona così, non lo contrai con una decisione, lo accumuli rinunciando ogni volta a un piccolo sforzo che sembrava superfluo.

Eppure la stessa ricerca lascia aperta la porta opposta. Uno degli utenti citati nello studio descrive l’AI come uno specchio, non un genio. La differenza la fa chi la usa, se la interroga come oracolo da cui ricevere la verità o come sparring partner contro cui mettere alla prova le proprie ipotesi. Lo strumento è identico, l’esito è opposto.

Gli agenti entrano in classifica, ma da sotto

Per la prima volta nella storia di questa ricerca compaiono nell’elenco le operazioni autonome di agenti AI, al sesto posto tra gli usi del 2026. È un ingresso simbolico, perché di agenti si parla da due anni come della prossima frontiera, e finalmente la frontiera lascia una traccia nei comportamenti reali delle persone, non solo nei comunicati dei vendor.

Lascia una traccia piccola, però. Zao-Sanders è cauto, e fa bene, gli agenti restano esperimenti su scala ridotta, l’AI che fa invece di consigliare è ancora più promessa che pratica diffusa. È esattamente la tensione che racconto in un altro pezzo del blog sul manager di umani e di agenti, il ruolo esiste già nei framework di HBR e di Anthropic, mentre nelle aziende italiane medie sta appena cominciando a materializzarsi.

Al lavoro vince la Shadow AI

Un dato che a chi guida aziende dovrebbe togliere il sonno, sessantatré dei cento usi principali sono professionali, ma quasi sempre nascono dal basso, spesso di nascosto. Uno degli utenti racconta di chiudere i ticket al doppio della velocità grazie all’AI, e aggiunge che nessuno in azienda sa che la usa.

La Shadow AI è la versione contemporanea di un fenomeno antico, le persone trovano lo strumento utile prima che l’organizzazione lo approvi, e lo adottano in silenzio per non doverne rispondere. Il problema per l’azienda è doppio, perde la mappa di come il lavoro viene realmente svolto, e perde il controllo sui dati che finiscono nei prompt. Per questo continuo a insistere sulla sovranità tecnologica e sull’AI privata, non come slogan ma come precondizione, se non sai dove passa l’informazione non puoi governare nulla, nemmeno l’entusiasmo dei tuoi.

I benefici aziendali, intanto, restano marginali. Efficienza sì, qualche crescita nelle vendite, pochissima trasformazione vera dei processi. Tre anni e mezzo dopo l’esplosione generativa, la distanza tra l’adozione individuale, intensa e affettiva, e la trasformazione organizzativa, lenta e cauta, è il vero dato politico di questa ricerca.

L’attaccamento alle macchine è una frontiera fragile

C’è un ultimo segnale che mi tocca più degli altri, cresce l’attaccamento emotivo. Persone che danno un nome al modello, che gli assegnano un genere, che provano qualcosa di simile al lutto quando un modello viene dismesso e sostituito. Lo abbiamo visto succedere davvero, ogni volta che un laboratorio ritira una versione e gli utenti protestano per la voce che hanno perso.

Da osservatore che lavora dentro questa trasformazione, e non da spettatore distante, trovo la cosa affascinante e fragile insieme. Affascinante perché conferma che la relazione uomo-macchina è entrata in un territorio che credevamo riservato agli umani. Fragile perché un affetto rivolto a un sistema che può cambiare, scadere o essere spento da remoto è un affetto esposto, costruito su una base che non controlli.

La ricerca di Zao-Sanders, edizione dopo edizione, racconta una cosa sola sotto le classifiche che cambiano. L’AI è entrata nelle nostre teste e nei nostri cuori prima ancora di entrare davvero nei nostri uffici. Custodire la capacità di pensare con la propria voce, e di sentire senza delegare anche quello, sta diventando una scelta quotidiana, qualcosa che va difeso ogni mattina invece di darlo per acquisito. Senza dubbio è la domanda che mi porto dietro chiudendo l’articolo, quanto di noi siamo disposti a far gestire alla macchina prima di accorgerci che gestirlo era il nostro mestiere di esseri umani?


Fonte: Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review, 1 giugno 2026.

Nadella e il learning loop: i tre piani della sovranità dell’AI

Ieri Satya Nadella ha pubblicato su X un testo lungo, intitolato «A frontier without an ecosystem is not stable». Io avevo appena scritto del blocco con cui il governo americano ha spento Fable 5 e Mythos 5 per tutti, partendo da una previsione di Ethan Mollick. Nadella arriva sullo stesso nervo da un’altra altezza, parla del futuro dell’impresa e usa una parola che mi segue da tempo, sovranità.

Messi in fila, questi interventi disegnano un quadro a strati. E al centro c’è il learning loop.

Nadella sposta il valore sul ciclo di apprendimento

Il ragionamento di Nadella è che il vantaggio competitivo, nell’AI, si costruisce sopra i modelli, più che scegliendo il modello migliore. Introduce due capitali. Il human capital, fatto di conoscenza, giudizio, relazioni e intuizione delle persone, e il token capital, la capacità di AI che l’azienda costruisce e possiede. Il primo, dice, non perde valore quando cresce il secondo, anzi ne guadagna, perché è l’iniziativa umana a guidare la crescita del token capital. Senza una direzione umana, hai solo calcolo che gira a vuoto.

Da qui il cuore del testo. L’opportunità sta nel costruire un learning loop sopra i modelli, un sistema che impara dai dati e dai processi dell’azienda e migliora a ogni uso. Il modello è il motore, la conoscenza dell’azienda è il carburante. E aggiunge una frase che condivido: deleghi un compito, persino un intero lavoro, ma non deleghi mai quello che impari facendolo. Quel ciclo diventa l’IP nuova dell’impresa, una macchina che accumula valore nel tempo e che gli altri faticano a replicare.

Il testo indica anche tre tasselli pratici. Valutazioni fatte in casa, misurate sugli esiti che contano per il business più che sui benchmark pubblici. Ambienti di reinforcement learning privati, dove il modello migliora sulle tracce reali dell’organizzazione. Una knowledge base che rende interrogabile la memoria aziendale e l’uso dei token più efficiente. La chiama una macchina che scala la collina, e a differenza di gran parte degli asset fa compounding, perché ogni processo migliorato produce segnale migliore, che accelera l’accumulo di sapere tacito unico dell’impresa.

Il test che propone centra il problema. Devi poter sostituire il modello «generalista» senza perdere l’esperienza da «veterano» costruita dentro il tuo sistema di apprendimento. Lo chiama, testualmente, la prova del tuo controllo e della tua sovranità nell’era che arriva.

Tre piani dello stesso problema

Mi sembrano tre pezzi della stessa discussione, su tre piani diversi, e non si contraddicono, si tengono.

Mollick guarda il piano dei modelli, e prevede la fine dei modelli di frontiera open weights, perché un modello al vertice ha un footprint di calcolo che uno Stato può vedere e spegnere.

Nel mio articolo di ieri ho guardato il piano sotto. Un’API che ti spengono in una sera è un single point of failure, e in produzione la difendibilità si sposta dal modello migliore al controllo di routing e inferenza. Ci ero arrivato già dal primo post sul blocco, dove scrivevo che l’accesso ai modelli di frontiera è un permesso, non una proprietà.

Nadella aggiunge il piano sopra. Sul modello, qualunque sia, accumuli la conoscenza che diventa il vantaggio che nessuno ti può copiare. Tre altezze diverse, una stessa domanda di fondo, di chi è davvero quello che fai girare.

Il learning loop regge solo se possiedi l’inferenza

Qui sta la parte che aggiungo al suo ragionamento. Il test di Nadella è giusto, e funziona a una condizione precisa. Puoi cambiare il modello «generalista» senza perdere il «veterano» solo se possiedi il livello sotto, l’inferenza e il routing. Un learning loop che gira su un’API revocabile resta esposto, e sposta soltanto il lock-in di un piano più in alto. La conoscenza che accumuli vale finché la macchina che la fa girare resta accesa e sotto il tuo controllo.

Possedere l’inferenza vuol dire decidere tu dove gira il modello, su quale hardware, con quali dati che non escono di casa, e poter scambiare il motore senza riscrivere quello che hai costruito sopra. È la differenza tra un sistema che impara per te e un sistema che impara dentro l’infrastruttura di qualcun altro, che un domani può cambiare prezzo, condizioni o disponibilità.

Nella pratica è quello che ho descritto costruendo un ecosistema di AI privata, dove il modello è un componente sostituibile e la knowledge base, gli embedding e gli agenti con memoria restano dentro casa. Il loop, lì, poggia su un’infrastruttura che governi tu.

La parte che un hyperscaler lascia in ombra

C’è un dettaglio nel pezzo di Nadella che vale una nota. Microsoft è un hyperscaler, e la visione del learning loop la puoi seguire benissimo sopra il suo stack. In quel caso, però, il loop poggia su un’inferenza che affitti, e la sovranità di cui parla resta a metà strada. Diversi osservatori hanno letto il testo come un posizionamento, Microsoft come piattaforma che distribuisce valore sopra i modelli, contro la scommessa di chi punta sul dominio del singolo modello di frontiera.

Quando Nadella scrive «frontier ecosystem, not just a frontier model» ha ragione, e l’argomento diventa più solido se lo strato di inferenza sotto il loop lo possiedi tu. Si può condividere l’obiettivo e aggiungere la fondazione che a un fornitore di cloud conviene non mettere in prima fila. Le due tesi non competono. La sua si appoggia sulla mia.

Da Zero a Loop, su un’inferenza tua

Il loop, per me, è un filo che tiro da tempo, al punto da averci intitolato un libro, Da Zero a Loop. L’idea è semplice. Il valore sta nel ciclo che, uso dopo uso, trasforma il lavoro di un’azienda in un sistema che migliora, più che nel singolo modello del momento. Nadella lo chiama learning loop e gli dà la dignità della strategia, e fa una certa impressione sentirlo dire da chi guida un’azienda da tremila miliardi di capitalizzazione.

Quello che aggiungo è dove quel ciclo deve poggiare. Su un’inferenza che tieni tu, perché un loop costruito su un fornitore lontano è esposto allo stesso interruttore che venerdì ha spento due modelli per tutti, in una sera. Possedere l’esecuzione dei modelli conta ormai più che possedere il modello migliore.

Tre piani, una sola posta in gioco, continuare a possedere quello che impari. Senza dubbio è lì che si gioca la sovranità nei prossimi anni, e la domanda da tenere sul tavolo resta semplice, su quale strato stai costruendo il tuo vantaggio?


Fonte: Satya Nadella, «A frontier without an ecosystem is not stable», X, 14 giugno 2026. La discussione nasce dal post di Ethan Mollick e prosegue i miei due articoli precedenti sul blocco di Anthropic.

Anthropic spegne Fable 5 e Mythos 5: open weights di frontiera e sovranità tecnologica

Venerdì sera, ora di Washington, Anthropic ha disattivato i suoi due modelli più capaci, Claude Fable 5 e Claude Mythos 5, per tutti i clienti del mondo, e il dibattito sugli open weights è ripartito di colpo. A tre giorni dal lancio. La causa è una direttiva di export control del governo americano, che vieta l’accesso a qualsiasi cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa azienda. Una conformità selettiva era impossibile, l’interruttore è stato abbassato per chiunque, ovunque, e in molti hanno letto il blocco come la spinta che mancava verso i modelli open weights. I due modelli erano disponibili da pochi giorni, ed è la prima volta che una direttiva di questo tipo colpisce così, in una sera, i modelli di punta di un laboratorio americano.

Ethan Mollick, su LinkedIn, ha scritto una previsione che va nella direzione opposta.

Il blocco non porterà più modelli a pesi aperti. Semmai, scrive Mollick, vedremo la fine dei modelli di frontiera open weights. Il ragionamento è lineare: se un modello di classe Mythos è considerato rischioso, neanche la Cina avrà interesse a lasciarlo aperto, e un modello del genere non lo costruisci senza una concentrazione di calcolo che sta dentro un Paese, visibile e regolabile.

Ho lasciato un commento sotto il suo post, e provo qui ad allargarlo.

Sul meccanismo Mollick ha ragione, per la punta assoluta. Sulla conclusione servono due correzioni, e tutte e due portano esattamente dove passo le mie giornate, l’inferenza locale e la sovranità tecnologica, il lavoro che faccio in LocalAI.

La logica del footprint tiene

Un modello al vertice della capacità oggi nasce da una concentrazione di GPU che occupa data center fisici, dentro una giurisdizione precisa, con consumi, forniture e contratti tracciabili. La definizione che gira da tempo nei documenti regolatori è quella di calcolo regolabile, regulatable compute: un addestramento al vertice lascia tracce fisiche, il consumo elettrico fuori scala, le dimensioni dei data center, l’acquisto di decine di migliaia di acceleratori, e tutto questo uno Stato lo identifica e lo raggiunge. Le stesse restrizioni americane sull’export dei chip più avanzati esistono perché quel calcolo si vede, si conta, si può fermare a monte. Venerdì lo Stato lo ha fatto, in una sera.

Un modello aperto da sette o settanta miliardi di parametri, invece, una volta scaricato vive di vita propria, e una copia su un portatile non si richiama indietro con una direttiva. È la differenza che molti hanno colto subito, chi tiene i pesi in locale non se li vede togliere da nessun governo. Mollick anticipa l’obiezione cinese, e fa bene. Al vertice vero, quello dei modelli più potenti in assoluto, nessuno dei due blocchi ha convenienza a far circolare i pesi liberamente. Su questo gli concedo tutto, il tetto si chiude su entrambi i lati.

Dall’1,2% a quasi il 30% in un anno

La parola «frontiera», però, nel suo post indica il soffitto, la classe Mythos. La capacità che muove davvero l’adozione sta un gradino sotto, nel near-frontier, più che sufficiente per quasi tutto quello che le aziende fanno ogni giorno: estrarre dati da un contratto, classificare richieste, alimentare un sistema RAG, scrivere bozze, far girare agenti su compiti delimitati. Per questi lavori la distanza dal soffitto si è assottigliata fino a diventare irrilevante, e il modello più potente in assoluto non cambia l’esito di un’estrazione di campi o dello smistamento di un ticket. E lì la Cina accelera, in chiaro.

Qwen di Alibaba, Kimi di Moonshot, GLM di Zhipu, DeepSeek, e da inizio giugno MiniMax con il suo M3, presentato come primo modello di frontiera open weights che tiene insieme coding di alto livello, un milione di token di contesto e input multimodale. I numeri raccontano lo spostamento meglio di qualsiasi tesi. Uno studio di OpenRouter su centomila miliardi di token, ripreso insieme ad Andreessen Horowitz, misura la quota dei modelli open source cinesi sull’uso globale degli LLM salita da circa l’1,2% di fine 2024 a quasi il 30% un anno dopo. Il paper della Commissione USA-Cina di marzo riporta una stima di un partner di a16z secondo cui intorno all’ottanta per cento delle startup americane costruisce su modelli base cinesi, e segnala che tra novembre e dicembre 2025 sette dei dieci modelli più scaricati su Hugging Face venivano da laboratori cinesi. I modelli proprietari occidentali restano davanti, intorno al settanta per cento dell’uso complessivo, ma la pendenza della curva aperta è tutta da una parte. L’adozione poi si autoalimenta, più sviluppatori scaricano un modello e più nascono strumenti, integrazioni e materiali intorno, e più quel modello diventa la scelta ovvia per il progetto successivo. È un volano che lavora a favore di chi pubblica i pesi, e in questo momento a pubblicarli con più aggressività è la Cina.

Fine del frontier open weights occidentale

A chiudersi, allora, non è il layer aperto, è la sua sponda occidentale. Se gli Stati Uniti regolano chiuso il proprio gradino alto e l’Europa continua a scivolare fuori dai vertici, con Mistral che esce dai primi posti tra i laboratori di punta, lo strato aperto del near-frontier non sparisce, passa di mano. Passa ai laboratori cinesi, che lo tengono aperto proprio perché l’apertura è una leva competitiva contro le API chiuse americane, un modo per entrare negli stack di tutto il mondo mentre l’alternativa si blinda.

Il blocco ha messo in chiaro un contrasto che diversi osservatori hanno colto subito. Un modello di frontiera open weights come M3 lo scarichi e lo fai girare sul tuo hardware, e nessun governo te lo spegne a distanza, mentre due modelli di punta serviti da un endpoint centralizzato sono spariti per chiunque nel giro di una sera. La parte scomoda della previsione di Mollick è questa: una chiusura del vertice occidentale dettata dalla sicurezza può consegnare lo standard aperto a Pechino, e regalare a un concorrente sistemico la posizione di default su cui costruiscono sviluppatori e imprese.

Per l’Europa la posta è alta. Se lo strato aperto che entra negli stack diventa cinese, l’autonomia digitale che il continente insegue da anni si ritrova a poggiare su modelli sviluppati sotto un’altra giurisdizione, con un’altra catena di fornitura e un altro sistema di valori a monte. Mistral resta la carta europea più seria, e proprio per questo il suo arretramento dai vertici pesa oltre il singolo laboratorio. La sovranità tecnologica, in questo scenario, smette di essere una parola da convegno e diventa una scelta su quale ecosistema di modelli vuoi poter usare anche tra cinque anni.

Una sera è bastata a spegnere due modelli

Qui arriva la parte che vedo meglio dal mio mestiere. Per il valore che conta in produzione, la capacità di frontiera non è mai stata l’elemento che fa la differenza. In produzione la differenza la fa la continuità del servizio, e una sera come quella di venerdì la mette alla prova più di qualsiasi benchmark. Due modelli spariti per direttiva, a tre giorni dal lancio, con Amazon a cui è stato chiesto di revocare l’accesso in tutte le regioni, e nessuno dei clienti che ci aveva costruito sopra un processo ha avuto voce in capitolo.

È una traiettoria, più che un episodio isolato. Il Dipartimento della Difesa aveva già etichettato Anthropic come rischio per la catena di fornitura, e l’azienda ha aperto un contenzioso contro quella classificazione. Quando un fornitore si trova in mezzo a una tensione del genere, la volatilità regolatoria smette di essere un’ipotesi da slide e diventa una variabile operativa. E c’è un secondo lato, speculare, se l’ottanta per cento delle startup americane gira su modelli cinesi quell’esposizione un domani può diventare a sua volta oggetto di una direttiva: la dipendenza da un fornitore lontano è un rischio qualunque sia la bandiera del fornitore. La lezione che le aziende portano a casa questa settimana è architetturale, serve un disegno capace di reggere il momento in cui un down o un blocco arrivano davvero. Ne avevo scritto guardando alle opzioni di self-hosting con Mistral, e quel ragionamento oggi vale per chiunque appoggi un processo critico su un solo fornitore lontano.

Routing e inferenza locale, il livello che resta tuo

L’architettura che regge a tutto questo è agnostica rispetto al modello: un livello di astrazione e di routing che, nel momento esatto in cui qualcosa a monte si rompe, sposta il traffico da un’API di frontiera a un modello aperto che gira in casa. È quello che costruiamo in LocalAI, un motore open source che funziona come sostituto diretto delle API di OpenAI e di Anthropic, così lo stesso codice che ieri chiamava Fable 5 oggi può chiamare un Qwen o un DeepSeek sul tuo hardware, CPU compresa, senza che i dati escano dalla tua infrastruttura, con agenti, RAG e supporto MCP già dentro. In termini concreti cambi l’indirizzo dell’endpoint e la chiave, non l’applicazione che ci sta sopra.

La spinta verso questo disegno non arriva solo da chi vende inferenza locale. VentureBeat, commentando proprio questo blocco, indica come via più resiliente un’architettura a fallback attivo, con sistemi pensati per essere agnostici rispetto al modello e livelli di routing intelligenti che spostano il traffico da un modello di frontiera a un fallback a pesi aperti nell’istante in cui arriva un’interruzione o un divieto. Nello stesso caso Anthropic, per non lasciare tutto fermo, ha dirottato le richieste sopravvissute su Opus 4.8, un modello meno capace ma ancora acceso. Lo ha fatto perché quando il vertice si spegne serve comunque un posto dove ricadere, e quel posto, se è davvero tuo, non te lo toglie nessuno.

Compatibilità diretta vuol dire usare gli stessi SDK e la stessa struttura di chiamata, e il livello di routing decide richiesta per richiesta dove mandare il lavoro, in base a quanto è sensibile il dato, al costo e a quanto serve davvero la potenza del modello più grande. Una bozza interna resta in casa su un modello locale, una sintesi complessa può salire sul cloud di frontiera, e se quel cloud non risponde il traffico ricade sul locale senza che l’utente se ne accorga. Per banche, sanità e pubblica amministrazione lo stesso motore gira on premise o in ambienti isolati dalla rete, dove il dato non ha proprio il permesso di uscire.

Il lock-in vero, quello che fa fallire le migrazioni, vive oltre il modello, negli embedding, nel database vettoriale, nella logica di orchestrazione che hai cucito addosso a un fornitore. Possedere il livello di astrazione significa poterli sostituire un pezzo alla volta, senza riscrivere tutto. E sul costo cambia la natura della spesa, l’inferenza locale ha un costo prevedibile legato all’hardware, più che una bolletta a consumo che cresce con l’uso e che un fornitore può ritoccare quando vuole. È la stessa famiglia di strumenti, da LocalAI a LocalAGI fino a LocalRecall, di cui avevo raccontato il senso più ampio parlando di pelle digitale e di agenti autonomi.

Gli agenti rendono il problema più grave

C’è un livello in cui tutto questo pesa il doppio, ed è quello degli agenti. Un agente che dipende da una sola API di frontiera per pianificare i passi e chiamare gli strumenti si ferma del tutto nel momento in cui quell’API viene tagliata, e non si ferma una funzione, si ferma il processo che gli avevi delegato per intero. Più l’agente è autonomo e incastrato nei flussi di lavoro, più alto è il costo di un’interruzione improvvisa, perché hai spostato sul modello non una risposta ma una catena di decisioni.

Un livello di routing con fallback locale è quello che permette a un agente di degradare con grazia, passando a un modello che gira in casa e continuando a lavorare, magari un po’ più lento, invece di spegnersi a metà. È una delle ragioni per cui LocalAGI sta sopra LocalAI, l’orchestrazione degli agenti vale finché sotto c’è un’inferenza che non puoi perdere da un momento all’altro.

La difendibilità si sposta dal modello al controllo

Da mesi insisto su una tesi che questa settimana trova una conferma sgradevole. Quando la capacità di frontiera diventa una merce che si affitta, finché non te la spengono, «avere il modello migliore» smette di essere un fossato difensivo. L’asset che resta difendibile è il controllo, sull’inferenza, sul luogo dove vivono i dati, sul livello di routing che tiene in piedi tutto il resto. La capacità la noleggi in un pomeriggio, il controllo te lo costruisci, e per questo vale di più.

Per l’Italia e per l’Europa la cosa non è teorica. Gli obblighi dell’AI Act per i sistemi ad alto rischio arrivano in pieno il 2 agosto 2026, con gestione del rischio, governance del dato, tracciamento e sorveglianza umana da dimostrare, il GDPR rende il luogo del dato una questione legale prima ancora che tecnica, e la spinta sul cloud sovrano sta già ridisegnando quali fornitori possono servire i progetti pubblici. Uno stack che possiedi risponde alle tre cose insieme, compliance, residenza del dato e continuità, e lo fa senza dover sperare che il fornitore a monte non cambi idea.

In pratica si parte mappando le dipendenze AI che hai, processo per processo, per sapere cosa si ferma se un fornitore sparisce. Da lì si introduce un livello di astrazione e di routing tra le applicazioni e i modelli, si tiene pronto un fallback locale per i carichi critici e per i dati sensibili, e si comincia a trattare l’inferenza come si tratta l’energia di un’azienda, con una fornitura principale e una riserva che non dipende da lei. Nessuno di questi passi richiede di rinunciare ai modelli di frontiera quando servono davvero, chiede solo di non restarne prigionieri.

La cosa che mi resta addosso, finita questa settimana, non è la geopolitica del calcolo. È quanta parte della nostra intelligenza operativa giri già su un interruttore tenuto da qualcun altro. Ci siamo affezionati a capacità che non possediamo, che possono cambiare, scadere o essere spente da lontano, e in Pelle Digitale avevo provato a dire che la tecnologia che ci estende è anche la tecnologia che ci espone, ogni volta che rinunciamo a governarla. Possedere il livello che ti tiene acceso sta diventando una scelta quotidiana, da rifare ogni mattina invece di darla per acquisita. Senza dubbio è la domanda che porto in ogni tavolo in queste settimane, quanta della tua intelligenza operativa sei disposto a lasciare su un interruttore che non tieni in mano?


Fonte: Ethan Mollick, post su LinkedIn, 12 giugno 2026. Sui fatti del blocco: comunicato di Anthropic, CNBC, Tom’s Hardware, VentureBeat. Sui dati di mercato: OpenRouter e Andreessen Horowitz, paper della Commissione USA-Cina (USCC).

Sovranità dell’AI: quando un governo può spegnere un modello

Venerdì 12 giugno 2026, ore 17:21 a New York. Anthropic riceve una lettera dal governo degli Stati Uniti e nel giro di poche ore disattiva i suoi due modelli più potenti, Fable 5 e Mythos 5, per l’intera base clienti, ovunque nel mondo. La motivazione, dichiarata nel comunicato ufficiale dell’azienda, è un export control per ragioni di sicurezza nazionale che vieta l’accesso a qualunque cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa Anthropic.

Screenshot

Non discuto qui chi abbia ragione. Mi interessa una cosa più semplice, e più scomoda, che fino a quella sera in molti trattavano come un dettaglio tecnico: l’accesso ai modelli di frontiera è un permesso, e un permesso lo concede qualcuno che può anche ritirarlo.

Un export control ha messo offline un modello di frontiera

La direttiva è arrivata venerdì pomeriggio, alle 17:21 ora della costa Est. Secondo NBC News a firmarla è stato il Segretario al Commercio Howard Lutnick, con i funzionari del Bureau of Industry and Security, l’ufficio che negli Stati Uniti gestisce le restrizioni all’export. È lo stesso strumento con cui negli anni Novanta Washington trattava la crittografia come un’arma da guerra, soggetta alle regole sull’export militare. Anthropic ha scelto di spegnere i modelli per tutti, perché applicare il divieto ai soli stranieri avrebbe comunque tagliato fuori una parte enorme di utenti, inclusi i suoi stessi dipendenti non statunitensi.

L’azienda si adegua, ma dichiara di non essere d’accordo. Sostiene che la vulnerabilità contestata sia minore, che la prova ricevuta sia finora soltanto verbale, e che la stessa capacità sia già reperibile in altri modelli pubblici, incluso GPT-5.5 di OpenAI, e usata ogni giorno da chi i sistemi li difende. È, per quanto se ne sa, la prima volta che un’azienda AI di primo piano mette offline un modello già distribuito al pubblico per effetto di un intervento federale.

Il contesto pesa più della singola lettera. A febbraio l’amministrazione aveva provato a escludere i prodotti Anthropic dalle agenzie federali, l’azienda aveva fatto causa e un giudice le aveva dato ragione. La settimana scorsa è emerso che la National Security Agency stava usando Mythos per operazioni cyber offensive. E il 2 giugno è stato firmato un ordine esecutivo sull’AI che, tra le altre cose, prevede un meccanismo per dare al governo accesso anticipato, su base volontaria, ai modelli più potenti. Lo stesso modello che lo Stato vuole usare per la propria sicurezza è anche quello che lo Stato può decidere di spegnere, per la stessa ragione.

Permesso, non proprietà

Quando paghi l’abbonamento a un modello hai l’impressione di possederne l’uso. L’accesso non è un bene che possiedi, è un permesso che ti concedono, condizionato, che vive su infrastruttura di qualcun altro e sotto la legge di qualcun altro.

In Pelle Digitale ho provato a raccontare come il digitale sia diventato una seconda pelle, qualcosa che indossiamo senza più accorgercene finché funziona. La dipendenza più profonda è quella invisibile. La vedi solo il giorno in cui qualcuno la stacca, e venerdì centinaia di milioni di persone hanno visto la propria.

Il controllo dell’AI è verticale

Girano decine di schemi dello stack dell’AI. Alcuni lo disegnano come un mercato, con applicazioni e modelli e dati e infrastruttura, altri come un’architettura tecnica a livelli, altri ancora come una pila di governance che sale dalla sicurezza fino al consiglio di amministrazione. Linguaggi diversi per lo stesso oggetto.

Quasi nessuno mette in evidenza la dimensione che venerdì è diventata lampante. Il controllo è verticale. C’è una pila che parte dal silicio e arriva alla governance, con in mezzo il cloud, i pesi del modello, il runtime di inferenza, l’orchestrazione, le applicazioni. Puoi avere model card, audit trail e comitati etici impeccabili in cima, e perdere comunque l’accesso al modello perché una lettera, in un’altra capitale, ha deciso così. Una policy perfetta vale poco se il fondo della pila vive sotto la giurisdizione di un altro Stato.

Dove può intervenire davvero un’azienda privata?

Qui la domanda si fa concreta, e la risposta cambia da livello a livello.

Sul silicio un’azienda privata non interviene. Non progetta i chip, non controlla i grandi produttori, e l’export sui semiconduttori è una leva che si muove tra governi. È il piano geopolitico del controllo, quello su cui un’impresa, per quanto grande, resta sostanzialmente spettatrice.

Dal cloud in su la situazione si ribalta. L’infrastruttura puoi sceglierla, on-premise oppure su un cloud sovrano in giurisdizione europea. Il runtime di inferenza gira su software aperto, dentro il tuo perimetro. Per orchestrazione e agenti esistono standard aperti come MCP. Le applicazioni le disegni o le ospiti tu, e la governance, in cima, è per definizione tua.

In mezzo c’è il livello che decide tutto, il modello e i suoi pesi. Con pesi aperti, scaricati e ospitati sulla tua infrastruttura, il modello è tuo e nessuno te lo spegne da remoto. Con un’API proprietaria, per quanto eccellente, dipendi dalla continuità di servizio di chi te la fornisce, ed è esattamente lì che venerdì è caduta la direttiva.

Controllare l’intera pila, dal chip all’applicazione, è impraticabile per quasi qualunque organizzazione, e costoso anche solo provarci. La scelta sensata non sta nel possedere tutto, ma nel decidere, livello per livello, cosa tenere dentro il perimetro e cosa affittare sapendo bene che cosa si sta affittando.

Il metodo viene prima della tecnologia

Decidere quali livelli controllare è prima di tutto un esercizio di metodo: mappare le dipendenze reali, valutare la maturità dell’organizzazione, architettare quali strati portare in casa e con quale priorità, mettere governance e conformità, con l’AI Act in testa, dentro il progetto dall’inizio e non come timbro finale. È il lavoro che con ZeroFive provo a fare con un framework a cinque fasi, che parte dall’allineamento strategico e dalla valutazione della maturità, passa per l’architettura delle priorità e l’attivazione della governance, e arriva alla misurazione del valore nel tempo, con un’idea fissa, portare metodo dove l’industria porta hype.

Il metodo dice quali livelli pesano per te. Poi serve la tecnologia per tenerli davvero in mano, e sul livello che fa da bivio, il modello e il runtime, la risposta tecnica ha un nome preciso, l’open source. LocalAI è un motore di inferenza aperto, compatibile con le API di OpenAI e indipendente dal modello, pensato per far girare modelli a pesi aperti dentro il perimetro dell’azienda, senza che il dato esca e senza che l’accesso dipenda da una decisione presa da un’altra parte. È il progetto su cui lavoro, e lo cito per quello che è in questo discorso, un modo concreto per riportare il modello dalla parte di chi lo usa. Vale anche per chi si occupa di AI generativa in azienda: la scelta della pila viene prima della scelta del fornitore.

La direttiva del 12 giugno rientrerà quasi certamente, Anthropic stessa la legge come un malinteso, e l’accesso a Fable e Mythos tornerà. La lezione però resta anche dopo. Per chi costruisce in Europa la prossima domanda da portare in consiglio di amministrazione non riguarda quale modello sia il più bravo, ma quanta parte del proprio stack continuerebbe a funzionare il mattino dopo una lettera. Voi quanta parte ne avete?


Fonte primaria: Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic, 12 giugno 2026. Ricostruzione del meccanismo governativo: NBC News. Contesto regolatorio: ordine esecutivo del 2 giugno 2026.

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna

Anthropic sposta l’esecuzione dentro l’azienda, la regia resta fuori

Il 19 maggio, al primo Code with Claude tenuto a Londra, Anthropic ha annunciato due funzionalità che spostano in modo concreto dove vivono gli agenti AI dentro le aziende. La prima si chiama self-hosted sandboxes ed è in public beta. La seconda si chiama MCP tunnels ed è in research preview. Messe vicine valgono più di quanto sembrino a una lettura veloce della release note, e provo a dire perché.

Il punto di partenza tecnico è semplice. Claude Managed Agents è l’infrastruttura ospitata di Anthropic per far girare sessioni agentiche lunghe e tool-heavy. Fino a maggio, tutto stava lì: l’agent loop con orchestrazione e gestione del contesto, l’esecuzione dei tool, la connessione ai servizi esterni. Adesso una parte di quello stack può uscire da Anthropic e rientrare dentro il perimetro del cliente, mentre l’altra resta dove era. La regia rimane su Anthropic. L’azione si sposta a casa tua.

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna
Fonte: Anthropic, schema del MCP tunnel.

L’esecuzione si sposta a casa tua

Quando un agente esegue un tool, esegue codice. Apre file, installa pacchetti, chiama API, scarica risorse. Fino a ieri tutto questo avveniva nei sandbox gestiti da Anthropic. Da oggi puoi configurare l’agente perché esegua quegli stessi tool dentro la tua infrastruttura, oppure presso un provider gestito a tua scelta (Cloudflare, Daytona, Modal, Vercel sono i nomi citati). I tuoi file sensibili, le repository di codice, i pacchetti privati, i segreti di configurazione non lasciano più la tua rete. E il logging di audit, le policy di sicurezza, gli strumenti di monitoring che hai già sul tuo perimetro continuano a vedere e regolare quello che fa l’agente.

L’orchestrazione, invece, resta su Anthropic. L’agent loop, la gestione del contesto, la recovery dagli errori, la pianificazione delle azioni successive sono tutti gestiti dall’API di Claude. Cambia solo dove materialmente vengono eseguite le chiamate. Se l’agente decide di lanciare uno script Python per processare un file, lo script gira sul tuo sandbox, non sul loro.

Un canale che parla solo verso l’esterno

Gli MCP tunnels affrontano il problema speculare. Come fa un agente a parlare con i tuoi sistemi interni senza che tu debba esporli a internet? Il Model Context Protocol è lo standard aperto che Anthropic ha promosso lo scorso anno per far dialogare gli agenti con sorgenti dati e servizi esterni. Funziona bene quando i servizi sono pubblici, meno bene quando sono dentro un network privato.

Il meccanismo che hanno introdotto è un gateway leggero, che il cliente dispiega dentro la propria rete, e che apre una singola connessione outbound verso Anthropic, cifrata end-to-end. Nessuna porta inbound da aprire. Nessun endpoint pubblico. Nessuna modifica al firewall. Sopra quel canale possono passare conversazioni MCP verso server interni che ospitano database, knowledge base, ticketing system, API private. L’agente di colpo può chiamare quei sistemi come fossero tool standard, ma il traffico non transita mai sull’internet pubblico.

Dove finisce l’azienda, dove comincia il modello

A una lettura superficiale è un aggiornamento di sicurezza e compliance. Per le aziende regolate è una notizia importante perché toglie uno dei blocchi tipici all’adozione, quel “non possiamo far uscire i dati” che ferma centinaia di progetti ogni anno. Per chi vende AI in enterprise è una mossa competitiva contro i player che offrono già installazioni on-premise complete.

C’è anche un altro livello. Anthropic sta dichiarando, in modo molto operativo, dove finisce l’azienda e dove comincia il modello. Per anni la domanda “dove vive un’AI aziendale” ha avuto due risposte estreme: o tutto in cloud sul provider, oppure tutto on-premise con uno stack auto-ospitato. Adesso ne sta diventando praticabile una terza, più sottile. La testa pensante del sistema, l’agent loop, resta fuori dall’azienda perché lì sta l’innovazione che si muove troppo veloce per essere replicata internamente. Le mani che toccano i dati e i tool tornano dentro perché lì stanno le regole, la responsabilità, il perimetro legale e culturale.

È una decomposizione interessante. Non è cloud, non è on-prem, è un terzo modello in cui l’autorità decisionale dell’agente è separata dall’autorità esecutiva. Anthropic decide come ragiona. Tu decidi cosa può toccare. La superficie di contatto fra i due livelli è codificata in due primitive ben definite, il sandbox e il tunnel.

Cambia anche il modo di comprarla

In Pelle Digitale avevo provato a descrivere come la mediazione tra noi e le macchine stesse cambiando forma. Quello che vedo qui è una variante infrastrutturale dello stesso fenomeno. La pelle non è più solo l’interfaccia in cui parliamo col modello. È anche la membrana tecnica che decide cosa passa e cosa no, cosa esce dall’azienda e cosa rientra, cosa il modello può sapere e cosa no. La progettano gli ingegneri di Anthropic disegnando le primitive del sistema. La progettiamo noi configurando policy, tunnel, sandbox.

Chi sta portando agenti AI in produzione dentro un’azienda strutturata, con questa architettura, deve mettere in conto tre cose che fino a ieri non c’erano.

Sul piano contrattuale e legale il discorso “i miei dati attraversano i server del fornitore” diventa meno semplice da fare, perché in molti scenari non è più vero. Tool execution e dati restano dentro, l’agente fuori vede solo quello che il sandbox gli restituisce. Vanno aggiornati i template di DPIA, le clausole nei contratti con i fornitori, le policy di data residency.

Sul piano organizzativo bisogna decidere chi gestisce un agente AI con questa architettura. Lo sviluppo software perché esegue codice. L’infrastruttura perché ospita sandbox e gateway. Il security perché definisce le policy del perimetro. Il data team perché decide quali sistemi interni esporre via MCP. Sono quattro funzioni che fino a ieri non lavoravano insieme su questo tipo di progetti, e bisognerà costruire workflow nuovi per farle convivere.

Sul piano strategico, Anthropic dichiara con queste mosse di voler diventare l’infrastruttura di default per gli agenti enterprise. Non un fornitore di modelli sotto, ma un layer di orchestrazione che si integra dentro le aziende mantenendo i confini tecnici e di sicurezza che le aziende vogliono. Per chi compra è una scelta strategica diversa rispetto a scegliere un fornitore di LLM più una soluzione di agentic framework messa su a parte. Per chi vende prodotti AI on top, conviene capire dove si posiziona la propria offerta rispetto a questo stack che si sta consolidando.

Il debug a cavallo del confine

C’è una cosa che la documentazione di Anthropic non risolve, e che secondo me sarà il punto di osservazione più interessante nei prossimi mesi. Quando l’agent loop sta fuori e i tool girano dentro, il debugging di un comportamento anomalo dell’agente diventa un esercizio distribuito. Il log dell’orchestrazione lo vede Anthropic. Il log dell’esecuzione lo vedi tu. La correlazione fra una decisione presa dal modello e un’azione fatta sul tuo sandbox passa attraverso due piani di osservabilità separati. Per capire perché un agente ha cancellato un file di troppo, serviranno entrambi.

Vedere come si organizza questa osservabilità a cavallo del confine sarà uno degli indicatori migliori per capire se il pattern decolla davvero, o se resta confinato ai casi d’uso più semplici. La promessa tecnica c’è, la direzione mi sembra giusta. Resta da vedere quanto in fretta le aziende, anche quelle non super-tech, riusciranno ad attrezzarsi per giocare a questo gioco con la maturità che richiede.


Articolo di riferimento: New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels, Anthropic, 19 maggio 2026.