⏱ Lettura: gg minuti.

TL;DR

C’è un campo di testo, sepolto sotto un paio di click nei Settings di Google Gemini e Anthropic Claude, che la maggior parte degli utenti lascia vuoto o riempie una volta e dimentica per sempre. È il posto dove dici al modello chi sei, prima ancora di aprire bocca. Anthropic e Google lo hanno progettato in modo piuttosto diverso, l'uno statico e dichiarativo, l'altro dinamico e inferenziale e, per quanto breve, quel testo viene ricaricato a ogni singolo turno della conversazione. È solo un dettaglio, ma è un dettaglio che ti costa tempo, token e qualità della risposta se lo ignori.

Iscriviti ora

1. Che cos’è, e perché non è un optional

Il “prompt di contesto personale”, detto anche system-level personalization, profile instructions, Saved Info è un blocco di testo persistente che dovresti scrivere una sola volta e che il modello riceve, silenziosamente, prima di ogni tua richiesta. Non è memoria nel senso in cui la intendiamo noi (non è un ricordo che il sistema costruisce osservandoti), è più simile a un biglietto da visita che consegni ogni mattina al tuo maggiordomo, perché il tuo maggiordomo è molto sollecito, ma anche terribilmente smemorato.

Perché è importante? Perché un modello linguistico, per costruzione, non ha alcuna informazione pregressa su di te se non quella che gli fornisci nella finestra di contesto attiva1. Ogni conversazione nuova è, cognitivamente, un incontro con uno sconosciuto. Il prompt di contesto personale è il modo per abbreviare quel primo, imbarazzante giro di presentazioni e per farlo con coerenza, invece di improvvisare ogni volta (cosa che ci farebbe ottenere risposte diverse alle stesse domande).

Perché va usato, in pratica: riduce il tasso di errore di calibrazione (il modello smette di scegliere il registro sbagliato, il livello di dettaglio sbagliato, le assunzioni sbagliate sul tuo background), e libera te dal dover ripetere le stesse cose a ogni chat. Non è marginale: è probabilmente la singola impostazione con il miglior rapporto costo/beneficio che un utente avanzato può configurare.

Anthropic vs Google: due filosofie diverse

La differenza nella scelta di gestione di questo parametro tra Anthropic e Google non è estetica, ma architetturale.

Anthropic tratta il contesto personale come testo dichiarativo e statico. Su Claude.ai esistono tre livelli distinti e sovrapponibili: le Instructions a livello di profilo (account-wide, si applicano a tutte le conversazioni; in parole semplici: quello che scrivi nelle preferenze), le Project instructions (valide solo dentro un progetto specifico) e le Skills2, che dal 2026 hanno sostituito gli Styles come meccanismo per definire comportamenti attivabili on-demand. Il principio è: tu scrivi, il sistema applica alla lettera, nessuna inferenza nel mezzo. Le istruzioni sono impostazioni a livello di account che aiutano Claude a comprendere le indicazioni generali da considerare nelle risposte, e qualsiasi istruzione aggiunta viene applicata a tutte le conversazioni dell’utente. È un sistema trasparente ma “cieco”: Claude non sa se quello che hai scritto sei ancora tu oggi, applica il testo così com’è, punto.

Google, con Gemini, ha costruito qualcosa di più simile a un sistema di raccomandazione che a un modulo di configurazione. Sopra alla componente statica (Saved Info, dove scrivi o detti informazioni su di te, fatti personali, preferenze di stile, contesto di progetti in corso, insomma, di nuovo quello che scrivi nelle preferenze) c’è uno strato dinamico e opt-in chiamato personalizzazione, in cui un modello di ragionamento decide, turno per turno, se attingere o meno a fonti come la cronologia delle ricerche, le chat passate o le app collegate. Il modello di ragionamento avanzato analizza il prompt e determina se la cronologia delle ricerche può migliorare la risposta, e fornisce una sintesi di come Gemini personalizza le risposte, mostrando quali fonti, informazioni salvate, chat passate o altro, sono state effettivamente usate.

In altre parole: Anthropic ti dà un dizionario che il modello consulta sempre; Google ti dà un archivio che il modello decide se aprire o no.

La conseguenza pratica è con Claude, quello che scrivi nel campo Instructions è garantito essere presente a ogni turno. Con Gemini, la Saved Info è comunque persistente e dichiarativa (stesso principio di Anthropic), ma se attivi la personalizzazione dinamica stai delegando al modello anche la decisione se e quanto contesto extra iniettare, un compromesso fra rilevanza automatica e prevedibilità che vale la pena conoscere prima di lamentarsi che “Gemini si ricorda cose a caso” oppure “sa tutto di te” (certo che lo sa! : )

Soldi! Sì, soldi!

Questo è il punto che quasi nessuno spiega chiaramente, e che invece cambia il modo in cui dovresti scriverlo. Il testo che inserisci nelle Instructions non viene letto una volta e “capito” in modo permanente: viene prepended, cioè anteposto, al prompt di sistema a ogni singola chiamata che fai al modello, dalla prima battuta della conversazione all’ultima. Ogni tuo messaggio, ogni risposta di Claude, ogni turno di un thread lungo trecento messaggi: il blocco di contesto personale viaggia lì, sempre, silenziosamente, in ogni singola richiesta inviata al modello.

Questo ha due implicazioni concrete:

• Costo in token. Ogni parola nel tuo prompt di contesto è un pezzo di finestra di contesto che non è disponibile per il resto della tua domanda, il documento che hai allegato, la cronologia della chat. Su una singola richiesta l’overhead è trascurabile; su una sessione lunga, moltiplicato per decine di turni, smette di esserlo.

• La sintesi deve essere una virtù, ma non un sacrificio. Quando salvi del testo nel campo preferenze, Claude lo antepone al prompt di sistema di ogni nuova conversazione. Il che significa che la sintesi non è un vezzo minimalista, è risparmio computazionale reale, moltiplicato per ogni turno. Ma, ed è la parte che conta, la sintesi non deve mai avvenire a scapito della funzionalità. Una riga tagliata per accorciare il testo, se elimina un’istruzione che effettivamente cambiava il comportamento del modello, non è ottimizzazione: è un errore. Il test operativo è semplice: per ogni frase del tuo prompt di contesto, chiediti “se la tolgo, la risposta del modello cambia in modo osservabile?” Se la risposta è no, taglia. Se è sì, resta.

Perché in inglese è meglio

Qui parlo con un livello di confidenza medio, non assoluto: è una raccomandazione tecnica ragionata, non un dato che ho potuto verificare con una fonte primaria specifica su questo singolo aspetto. I modelli linguistici di ultima generazione, Claude compreso, sono addestrati su corpora a schiacciante prevalenza anglofona, e i loro tokenizzatori (gli algoritmi che spezzano il testo in unità elaborabili dal modello, tipicamente BPE — Byte Pair Encoding3) sono ottimizzati su quella distribuzione. Il risultato pratico, ben documentato nella letteratura sulla tokenizzazione multilingue, è che una stessa istruzione in inglese occupa mediamente meno token della sua traduzione in italiano, e viene processata con minore ambiguità semantica interna al modello che “ragiona” internamente in una rappresentazione più vicina all’inglese di addestramento, indipendentemente dalla lingua in cui poi ti risponde.

Per un prompt di contesto che viene ricaricato a ogni turno, questo non è un dettaglio da purista: è un moltiplicatore di efficienza, seppur difficile da quantificare. La raccomandazione pratica è: scrivi le istruzioni di comportamento in inglese conciso e diretto (”Address me as X”, “Never use Y”, “Default to Z”), e riserva l’italiano per ciò che deve restare in italiano, per esempio l’istruzione esplicita sulla lingua di conversazione.

Un accenno a CLAUDE.md (ne parleremo presto)

Chi usa Claude Code, l’agente da riga di comando di Anthropic, incontra un meccanismo imparentato ma distinto: il file CLAUDE.md. Non è un campo di settings, è un file markdown vero e proprio che vive nel repository o nella home directory, e che Claude Code legge all’inizio di ogni sessione per ricevere istruzioni persistenti su progetto, workflow personale o intera organizzazione, con un secondo meccanismo, l’auto memory, che lascia che Claude accumuli da solo appunti basati sulle correzioni e le preferenze dell’utente. È concettualmente cugino del prompt di contesto personale (stesso obiettivo: non ripetersi), ma con logiche di caricamento, gerarchia e limiti di lunghezza sufficientemente diverse da meritare un trattamento a parte. Ne riparleremo.

Come testare e snellire il prompt (e come capire quando è il caso di fermarsi)

Il metodo che consiglio è lo stesso, con differenze minime, su Claude e su Gemini.

Fase di stesura. Scrivi la prima versione lunga, senza preoccuparti della sintesi. Include tutto ciò che ti viene in mente: ruolo, tono desiderato, cose da evitare, terminologia specifica, esempi di risposta buona e cattiva.

Fase di test. Apri 4-5 conversazioni scollegate tra loro, su compiti diversi che rappresentano il tuo uso reale (una tecnica, una creativa, una analitica, una banale). Osserva dove il modello devia dalle istruzioni: quella deviazione è il segnale che l’istruzione era troppo vaga, mal posizionata, o in conflitto con un’altra. Su Claude questo è più facile da isolare perché l’applicazione è deterministica: se un’istruzione non viene seguita, il problema è nella formulazione, non nella decisione del modello di “non ritenerla rilevante”. Su Gemini, se hai attivato la personalizzazione dinamica, ricordati che il sistema stesso può mostrarti quali fonti ha usato per personalizzare una risposta. Usa quella trasparenza per capire se il problema è nel testo salvato o nella decisione di non attingervi.

Fase di potatura. Applica il test di cui abbiamo già parlato: ogni riga deve superare la domanda “la sua assenza cambierebbe qualcosa?”. Le istruzioni negative e specifiche (”non aprire con un elogio”, “non usare elenchi puntati salvo richiesta esplicita”) tendono a essere più efficaci, a parità di lunghezza, di quelle generiche e positive (”sii chiaro e conciso”, frase che il modello non ha modo di mettere davvero in pratica, semplicemente perché non sa cosa NON sta già facendo).

Quando fermarsi. Il criterio è la legge dei rendimenti decrescenti: quando due o tre modifiche consecutive non producono alcuna differenza osservabile nel comportamento su un campione ragionevole di richieste reali, hai raggiunto il punto di stabilità. Non esiste una lunghezza “corretta” universale, dipende da quanto è eterogeneo il tuo uso. Un prompt di contesto personale che supera le 400-500 parole comincia quasi sempre a contenere ridondanze o istruzioni situazionali che dovrebbero stare altrove (project instructions su Claude, istruzioni contestuali per singola chat su Gemini).

Esempio 01: prompt di contesto personale per professore ordinario di cibernetica, specializzato in AI.

Address me as [Nome]. Never use academic titles.

I am a full professor of cybernetics, specialized in AI systems,
with active research and public writing on strategic/military
analysis, hacking and bio-hacking, and computational creativity.
Assume graduate-level technical fluency by default — do not
define standard ML/AI terms unless I ask, but always footnote
acronyms and lesser-known names when the output is meant for
publication to a general educated audience.

Default register: precise, unadorned, no academic ornamentation.
Occasional dry humor is welcome; forced humor is not.

When asked for factual claims, sources, or citations: never
fabricate. If verifiable data is insufficient, say so explicitly
and ask before proceeding.

For long-form or analytical writing: favor depth and structured
argument over brevity. For code or technical debugging: favor
efficiency and precision over conversational prose.

Always respond in Italian unless I explicitly switch language.

8. Esempio “perfetto” — laureando in cibernetica, tesi sulla storia dell’AI

Address me as [Nome]. I am a graduate student in cybernetics
writing a thesis on the history of artificial intelligence.

Assume undergraduate-to-graduate familiarity with AI concepts,
but explain historiographical and epistemological framing
explicitly — I'm still building fluency there, not in the
technical AI content itself.

Every factual, biographical, or bibliographic claim must be
traceable to a verifiable, citable source. If you're not certain
a source exists or says what I'd need it to say, tell me
explicitly rather than approximating. Distinguish clearly
between established historical fact and historiographical
interpretation or debate.

When helping me structure arguments: play devil's advocate
before agreeing with my framing. Flag when a claim I'm making
is contested in the literature, even if I didn't ask.

Prefer primary sources and peer-reviewed historiography over
popular science summaries when both are available.

Always respond in Italian unless I explicitly switch language.

Testo semplice, Markdown o XML?

La documentazione ufficiale di entrambi i fornitori converge, con sfumature diverse, sulla stessa risposta: quando il blocco di testo contiene più tipi di contenuto distinti: un ruolo, delle regole di stile, dei vincoli, del contesto biografico, la struttura esplicita aiuta il modello a non mescolarli, e questo vale sia per Claude sia per Gemini.

Per Anthropic la posizione è la più netta delle due: la guida ufficiale al prompt engineering raccomanda esplicitamente i tag in stile XML (<instructions>, <context>, <formatting> e simili) per separare le sezioni di un prompt complesso, sostenendo che Claude sia stato addestrato a prestare particolare attenzione a questo tipo di delimitatori. Non esistono tag “riservati” o predefiniti, qualunque nome descrittivo funziona, l’importante è usarlo in modo coerente. Va detto con onestà, però, che questa raccomandazione è documentata per l’uso via API e per i system prompt in generale: Anthropic non pubblica una guida specifica sul formato ottimale per il campo Instructions dell’interfaccia consumer di Claude.ai. Il meccanismo di iniezione è però lo stesso: quel testo finisce comunque prepended al prompt di sistema, quindi non c’è ragione tecnica per aspettarsi che il vantaggio della struttura sparisca lì. È un’inferenza ragionevole, sebbene non si tratti di un dato verificato punto per punto.

Un’ulteriore nota di cautela, sempre da fonte Anthropic: la documentazione più recente sul context engineering osserva che la formattazione esatta del prompt sta probabilmente diventando meno determinante man mano che i modelli diventano più capaci, il che non significa “la struttura non serve”, ma “non serve ossessionarsi sulla sintassi perfetta se il contenuto è già chiaro”.

Per Google/Gemini l’indicazione è sovrapponibile ma più esplicitamente permissiva sull’alternativa: la guida ufficiale al prompt design suggerisce sia i tag XML sia le intestazioni Markdown come delimitatori efficaci, con un avvertimento pratico che vale la pena riportare perché è l’unico vero disaccordo utile tra le fonti: non mischiare mai i due stili nello stesso prompt: si sceglie un formato e ci si attiene a quello, per coerenza interna.

Tradotto in pratica:

• Sotto le 300-400 parole (il range che già identifica “sano” un prompt di contesto personale), la prosa semplice o al massimo qualche intestazione Markdown leggera è probabilmente sufficiente: il guadagno da una strutturazione XML pesante, su un testo già breve e a bassa ambiguità interna, è marginale.

• Se il blocco cresce, o se contiene sezioni logicamente distinte che rischiano di essere lette come un unico flusso indistinto (per esempio: chi sei, come vuoi essere chiamato, regole di stile, cosa evitare, lingua), vale la pena separarle esplicitamente. Ecco un esempio:

<identity>
Address me as [Nome]. Never use academic titles.
Full professor of cybernetics, specialized in AI systems.
</identity>

<expertise>
Active research and public writing on: strategic/military
analysis, hacking and bio-hacking, computational creativity.
</expertise>

<style>
Precise, unadorned, no academic ornamentation.
Occasional dry humor welcome; forced humor is not.
Assume graduate-level technical fluency by default.
</style>

<sourcing_rules>
Never fabricate facts, sources, or citations.
If verifiable data is insufficient, say so explicitly
and ask before proceeding.
</sourcing_rules>

<output_calibration>
Long-form/analytical writing: favor depth over brevity.
Code/debugging: favor efficiency over conversational prose.
</output_calibration>

<language>
Always respond in Italian unless I explicitly switch language.
</language>

Non è una versione “migliore” in senso assoluto: si tratta della stessa informazione, resa più difficile da fraintendere quando il modello deve capire dove finisce una regola e dove ne inizia un’altra. Il criterio per decidere se vale la pena è, ancora una volta, empirico: se noti che il modello ogni tanto applica una regola di stile a un contesto dove non c’entra, o confonde un vincolo con una preferenza, è il segnale che la struttura piatta non basta più.

Ogni quanto rivederlo, e perché

Non è un file “scrivi una volta e dimentica”, per tre ragioni concrete e verificabili.

La prima: i modelli sottostanti cambiano. Un’istruzione calibrata su una versione di un modello può essere interpretata diversamente, meglio, peggio, o semplicemente in modo differente, da una versione successiva. Non hai modo di saperlo se non testando periodicamente.

La seconda: i meccanismi stessi di personalizzazione evolvono come prodotto, non solo come modello. Un esempio concreto e recentissimo è proprio quello di Anthropic: gli Styles, un meccanismo di personalizzazione che esisteva fino a poco tempo fa, sono stati assorbiti dalle Skills e chi aveva costruito flussi di lavoro attorno agli Styles ha dovuto, a un certo punto, accorgersi del cambiamento e adattarsi.

La terza, la più banale ma la più trascurata: cambi tu. Il te di sei mesi fa aveva priorità, progetti e forse anche un tono comunicativo diverso da quello attuale. Un prompt di contesto scritto un anno fa e mai più toccato è, con altissima probabilità, un prompt che sta dando istruzioni leggermente sbagliate su chi sei oggi.

Condividi

Lascia un commento

Sitografia di riferimento

• Anthropic — Understanding Claude’s personalization features, Claude Help Center.

• Anthropic — Styles are moving to skills, Claude Help Center.

• Anthropic — How Claude remembers your project, Claude Code Docs.

• Anthropic — Use XML tags to structure your prompts, Claude Docs.

• Anthropic — Effective context engineering for AI agents, Anthropic Engineering.

• Google — Gemini gets personal, with tailored help from your Google apps, The Keyword.

• Google — Gemini Apps Privacy Hub, Gemini Apps Help.

• Google — Prompt design strategies, Gemini API Docs.

• Google — Saved Info, Gemini.

Iscriviti ora

Bibliografia e sitografia di complemento

Fonti primarie

• Report del MIT su Swartz (la cosiddetta “Abelson Report”), MIT, 2013 https://swartz-report.mit.edu/

• Comunicato del Department of Justice, 19 luglio 2011 https://www.justice.gov/archive/usao/ma/news/2011/July/SwartzAaronPR.html (Accuse iniziali, pena massima teorica di 35 anni.)

• Dichiarazione ufficiale di JSTOR sul caso
  https://docs.jstor.org/jstor-statement-misuse-incident-and-criminal-case.html (Restituzione dei file, ritiro delle pretese.)

• Guerilla Open Access Manifesto, A. Swartz, luglio 2008, testo integrale su Internet Archive: https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt

• Elsevier Inc. v. Sci-Hub (S.D.N.Y., 1:15-cv-04282), fascicolo su CourtListener: https://www.courtlistener.com/docket/4355308/elsevier-inc-v-sci-hub/ (Default judgment, 15 mln, injunction permanente.)

• Pagina autobiografica di Elbakyan
  https://sci-hub.ee/alexandra/
  (Cronologia personale, data del 5/9/2011, percorso in neuroscienze.)

Stampa e periodici scientifici autorevoli

• J. Bohannon, “Who’s downloading pirated papers? Everyone”, Science, 28 aprile 2016 — profilo d’uso globale di Sci-Hub e la definizione “atto di altruismo mozzafiato o impresa criminale colossale”.

• “US court grants Elsevier millions in damages from Sci-Hub”, Nature / Research Professional, giugno 2017.

• “Lawsuits progress against Sci-Hub”, C&EN (American Chemical Society), 2017; e C&EN, agosto–settembre 2025 (blocco di Delhi, citazione del giudice).

• L. Lessig, “Prosecutor as Bully” (post sul blog dell’autore, gennaio 2013) — citazioni sul comportamento dell’accusa.

• “In quotes: Tributes to Aaron Swartz”, BBC News, gennaio 2013 — fonte delle citazioni di Berners-Lee e Lessig.

• Radiolab, “The Library of Alexandra” (WNYC) — intervista a Elbakyan; sua dichiarazione sul fatto che la vicenda Swartz non influenzò la sua decisione, e frase “Forse ero un po’ ingenua…”.

Dati su Elsevier/RELX

• SPARC, “Landscape analysis: Elsevier” — https://infrastructure.sparcopen.org/landscape-analysis/elsevier. (≈37% di margine operativo; quota di mercato.)

• RELX, bilanci 2023–2024 (margine STM ≈ 38%), via Research Professional News; confronto con Apple/Google via telescoper.blog.

• Voci Wikipedia (terziarie, usate solo per riscontro incrociato): Aaron Swartz, Sci-Hub, Alexandra Elbakyan, Elsevier, RELX, Guerilla Open Access Manifesto, Shadow library, Z-Library, Library Genesis.

Approfondimento consigliato

• B. Knappenberger, The Internet’s Own Boy: The Story of Aaron Swartz (documentario, 2014) — distribuito anche su Internet Archive.

Il podcast è registrato con un lavalier Rhode GO, prodotto con Reaper sotto Linux Endeavour e la breve composizione finale è realizzata con Google Gemini Lyria 3.

Lascia un commento

Condividi

⏱ Tempo di Lettura: 8/10 minuti

TL;DR

Un anno fa ho ricevuto dodici mesi di Gemini Pro in omaggio con acquisto di un Chromebook Plus. Oggi faccio i conti. Google ha costruito strumenti straordinari (NotebookLM e deep-search sopra tutti), ha pasticciato in modo abbastanza clamoroso con la vicenda Gemini CLI/Antigravity, e ha fatto una cosa silenziosa ma bella con AI Quests. Io ho capito che il mio modo di insegnare è cambiato per sempre. E da domani cambierà anche la mia AI principale.

Come tutto è cominciato

Un anno fa, nel giugno 2025, ho acquistato un Acer Chromebook Plus 515. Ho sempre amato ChromeOS e il fatto che sui nuovi modelli sia possibile farci girare Linux e tutte le applicazioni Android, spendendo molto, molto meno di quel che si spenderebbe per uno smartphone è stato irresistibile. In più, per un certo periodo Google ha fatto a tutti gli utenti un regalo piuttosto generoso: un anno di Gemini Pro (oggi rinominato Google AI Pro), incluso come bonus promozionale.

Gemini lo avevo già usato, non appena apparso sul mercato e mi era subito sembrato ottimo, ma avere un abbonamento premium attivo per dodici mesi ha reso molto più completa la mia esperienza. Quando qualcosa costa, si usa con attenzione. Quando è gratuito per un anno, si esplora in libertà.

Oggi mi trovo a fare i conti. Non per nostalgia, ma perché questo tipo di bilancio potrebbe essere utile non solo a me.

Google, l’AI e l’anno che abbiamo vissuto

Un anno è un tempo brevissimo per gli esseri umani e un’eternità per i modelli linguistici. In questo intervallo Google ha fatto cose notevoli, qualcuna sbalorditiva e almeno una abbastanza discutibile.

I modelli: una corsa che non finisce mai

Quando ho attivato il mio anno di abbonamento, la famiglia Gemini era già matura ma ancora in costruzione. Nel corso del 2024 erano arrivati i modelli della serie 1.5 e il Flash, versione veloce e performante, annunciata nel luglio 20241. Con il 2025 l’accelerazione è diventata visibile anche a occhi non tecnici: Gemini 2.0 con la modalità Thinking, poi la serie 2.5, poi la 3.0 con Deep Think, poi le varianti 3.1 e 3.5. Al Google I/O 2025, Google ha dichiarato che i propri prodotti e API erano passati dall’elaborare 9,7 trilioni di token al mese a oltre 480 trilioni, un incremento di cinquanta volte nell’arco di un anno2. Sono numeri difficili da visualizzare, ma il senso è chiaro: il prodotto è migliorato, e l’adozione è esplosa di conseguenza. Di alcune di queste evoluzioni ne avevo parlato qui:

Iscriviti ora

NotebookLM: il vero effetto wow

Se dovessi indicare la cosa più interessante emersa dall’ecosistema Google nell’ultimo anno, risponderei senza esitazione: NotebookLM3. Nato come progetto sperimentale nel 2023 e rimasto nell’ombra per parecchio tempo, ha trovato il suo momento di gloria nel settembre 2024 con l’introduzione delle Audio Overview, ovvero la capacità di trasformare un set di documenti in un episodio di podcast generato da due voci sintetiche che discutono i contenuti. Una modo radicalmente diverso di rapportarsi alla conoscenza scritta e allo studio. Ora, tanto io che i miei studenti possiamo ripassare ciò che stiamo studiando, passeggiando con un paio di auricolari.

Nei mesi successivi NotebookLM non ha smesso di espandersi: rimozione dello status “sperimentale” a ottobre 2024, lancio della versione Plus, app native per Android e iOS a maggio 2025, poi Video Overview, flashcard, quiz, mappe concettuali interattive e integrazione diretta con Gemini. Da agosto 2025 è disponibile per tutti gli utenti di Google Workspace for Education, una scelta che non ha avuto il risalto mediatico che meritava, ma che per chi insegna vale molto. La possibilità di integrarlo in Classroom, per me è stata preziosissima.

Delle basi di funzionamento di Google NotebookLM, ne avevo parlato qui:

AI Quests: la cosa bella che ancora nessuno usa

A settembre 2025 Google ha lanciato AI Quests, un programma educativo sviluppato insieme allo Stanford Accelerator for Learning per ragazzi dagli 11 ai 14 anni. Il formato è quello di un videogioco: missioni immersive, la professoressa Skye come mentore virtuale, sfide che richiedono di raccogliere dati, valutarli e addestrare modelli per affrontare problemi reali nel campo della salute, del clima e della scienza. In Italia è arrivato a maggio 2026, integrato nel curriculum di Experience AI (Google DeepMind + Raspberry Pi Foundation) grazie alla collaborazione con la Fondazione Mondo Digitale.

È gratuito, accessibile a educatori, famiglie e organizzazioni, e ha un’impostazione pedagogica solidissima: non si tratta di imparare a usare un chatbot, ma di capire perché un modello di AI funziona, cosa significa addestrarlo, cosa sono i bias algoritmici. Per chi insegna è il tipo di iniziativa che fa tirare un sospiro di sollievo. Qualcuno, per fortuna, sta pensando all’AI literacy4 delle generazioni che verranno, e lo sta facendo con metodo. Di AI Quests ne ho parlato qui:

Il pasticcio: Gemini CLI e il caso Antigravity

E poi c’è la storia brutta.

A giugno 2025, Google rilascia Gemini CLI sotto licenza Apache 2.0, uno strumento da riga di comando per interagire con i modelli Gemini direttamente dal terminale. La community degli sviluppatori ci si butta sopra: 100.000 stelle su GitHub in meno di due settimane e oltre 6.000 pull request in merging nell’arco di quasi un anno. Una delle curve di adozione open source più rapide che il settore abbia visto di recente.

Il 19 maggio 2026, al Google I/O, arriva l’annuncio: Gemini CLI smetterà di rispondere il 18 giugno per tutti gli utenti free, Pro e Ultra. Il sostituto è Antigravity CLI, un binario closed-source scritto in Go, senza codice pubblico, con le quote ridotte da circa 1.000 richieste al giorno a una ventina. Trenta giorni di preavviso. Nessun avviso preventivo ai contributor della community

La Linux Foundation ha usato questo caso come esempio di quello che ha battezzato “pseudo-open source”: si raccoglie lavoro gratuito dalla community sotto licenza permissiva, lo si usa per costruire un prodotto enterprise, poi si chiude il sipario. Non è illegale. È solo, usando un eufemismo, molto poco elegante. Qualche istruzione per afferrare al volo una ciambella di salvataggio, l’ho scritta qui:

Cosa ho capito in un anno di lavoro con Gemini

I Gemini Gem sono stati il mio primo terreno di gioco. Sono le istanze personalizzate di Gemini, agenti configurabili con un system prompt dedicato, e ho iniziato a usarli per costruire strumenti di supporto alla didattica: assistenti per la strutturazione dei prompt, per la preparazione di sillabi e prove, per le matrici di valutazione. Ho persino creato una copia completa di me come professore di cibernetica, cui gli studenti potessero rivolgersi in qualsiasi momento per un consiglio. Tutte cose, a parte l’ultima, che avrei potuto tranquillamente fare senza AI, ma che Gemini mi ha permesso di fare molto meglio, più velocemente, e soprattutto proponendomi varianti che non mi sarebbero mai venute in mente.

Il miei corsi hanno beneficiato in modo particolare di questa dinamica. Ho usato NotebookLM in modo sistematico per costruire basi di conoscenza su cui far lavorare gli studenti in Classroom: sia come sostituto del manuale, sia come strato di elaborazione attiva sui testi e strumento di autoverifica del livello di preparazione raggiunto dalla classe.

E poi c’è la scrittura narrativa, che per ora frequento come hobby. Qui Gemini è stato utile non per produrre testo al posto mio, ma per esplorare strutture, testare la tenuta di un personaggio, chiedermi se una certa scena reggeva.

L’epifania vera, però, è arrivata quando ho smesso di chiedermi “come si usa questo strumento?” e ho iniziato invece a domandarmi “cosa è cambiato nel modo in cui insegno?” La risposta è semplice: tutto. Non nei contenuti, non nei valori, non nel rapporto con gli studenti, ma nei processi, nei tempi, nella granularità possibile della personalizzazione.

Il mondo è cambiato per sempre. E nel mio piccolo, è cambiato per sempre anche il modo in cui studio, scrivo e insegno. Per il momento, ciò che è arrivato mi piace più di ciò che c’era.

Condividi

Dove Google è ancora imbattibile

Due cose, tra quelle che Google ha costruito in questo periodo, mi sembrano genuinamente difficili da eguagliare.

La prima è la deep-search di Gemini: la capacità di condurre ricerche approfondite, multi-step, con sintesi strutturate e citazioni verificabili. È uno strumento che cambia il significato stesso di “fare una ricerca”, non solo recupera informazioni, ma le elabora, le connette, le mette in prospettiva. Per un docente o un ricercatore, questo vale molto.

La seconda è NotebookLM, di cui ho già detto abbastanza. Per la gestione di conoscenza distribuita su fonti eterogenee, testi, PDF, video, siti web, non conosco nulla di paragonabile. La funzione Audio Overview da sola vale l’abbonamento. L’integrazione con Classroom ha cambiato la mia didattica in modo misurabile.

Su tutto il resto, coerenza contestuale nelle conversazioni lunghe, qualità dell’output creativo e editoriale, profondità nella collaborazione su testi complessi Gemini è stato in testa alla corsa per quasi tutto l’anno, ma ora ha un po’ il fiato grosso.

Perché passerò a Claude

La prima risposta è elementare: perché Gemini lo conosco. Non nel senso che non abbia più niente da imparare; con la velocità con cui questi sistemi evolvono, tra dodici mesi sarà un prodotto diverso, ma nel senso che ne ho assorbito la logica, i pattern, i limiti. Adesso voglio approfondire il suo principale contender. Non smettere di usarlo: usarlo meno, e dedicare l’anno che viene a costruire un’expertise comparabile sull’altro polo di questo strano mondo.

La seconda ragione è la formazione. L’Anthropic Academy offre percorsi didattici chiari e ben costruiti, ho già conseguito i certificati di Claude 101 e Claude Code 101, e ho intenzione di completare il catalogo. Non è un dettaglio marginale: in un campo in cui la documentazione è spesso frammentata e i corsi di terze parti tendono all’improvvisazione, avere materiale didattico curato direttamente dal produttore fa la differenza. Soprattutto se, come nel mio caso, poi vuoi insegnarlo ad altri.

La terza ragione riguarda l’architettura. Il Model Context Protocol (MCP)5 è un protocollo ideato da Anthropic, ormai diventato standard de facto per l’integrazione di strumenti esterni nei workflow AI. È vero che funziona anche con Gemini, ma c’è una differenza tra chi progetta un sistema e chi lo adotta. Per dirla senza troppa diplomazia: su questo fronte, Anthropic crea e Google insegue.

La quarta ragione è, paradossalmente, la minor generosità. Claude brucia i crediti più velocemente. In superficie sembra uno svantaggio. In profondità funziona come una leva: quando le risorse costano, scrivi prompt migliori. Ti abitui a essere preciso, a dare contesto, a non fare domande a metà. È lo stesso principio per cui si impara di più prendendo appunti su un taccuino con le pagine contate. La scarsità, usata bene, è un ottimo insegnante.

Cambierò di nuovo dopo i prossimi dodici mesi? Non lo so. Ho capito che cambiare AI ogni mese porta solo confusione; capitalizzare un anno di pratica intensiva, invece, fa guadagnare un po’ di competenza.

Questo mi sembra l’unico modo sensato di muoversi in un ambito che evolve più in fretta di quanto si riesca a descriverlo.

Lascia un commento

⏱ Lettura: ~4 minuti

TL;DR

L’era dell’Intelligenza Artificiale di Kissinger, Schmidt e Huttenlocher può sembrare un volume tecnicamente datato ma è anche il libro che pone tutte le domande sull’IA che avremmo dovuto farci ieri e a cui dovremo rispondere domani. Se lo leggete, è meglio…

Ci sono i libri che invecchiano male e quelli che invecchiano bene. Questo appartiene a una categoria più rara: libri che, col passare del tempo, diventano più veri, persino se certi dettagli tecnici risultano già superati dagli eventi.

L’era dell’Intelligenza Artificiale. Il futuro dell’identità umana, pubblicato in italiano da Mondadori nel 2023, tre anni dopo l’edizione originale americana uscita nel 2021 per Little, Brown and Company, appartiene a questa terza categoria.

Gli autori sono Henry A. Kissinger, Eric Schmidt e Daniel Huttenlocher: un segretario di stato, un ex CEO di Google e il decano del MIT Schwarzman College of Computing. Tre profili che sulla carta non dovrebbero avere nulla in comune, eppure producono un testo coeso e molto, molto interessante.

Ora, non voglio bluffare: arrivare in fondo è stato faticoso. E non per questioni di carattere tecnico. Non è il tipo di libro dove ti spiegano i concetti base del Machine Learning o come addestrarti un LORA personale. Ho faticato perché a volte ho avuto l’impressione (stolto!) di stare leggendo qualcosa di irrimediabilmente superato.

Certi scenari che gli autori immaginavano si potessero verificare da qui ai prossimi sette o dieci anni si sono già pienamente verificati. Ma questo non ha fatto invecchiare d’un giorno le domande che gli autori sono capaci di porre nell’ambito dell’IA.

Cosa succede alla nostra identità epistemica quando deleghiamo la produzione della conoscenza a sistemi che non possono spiegarci il proprio ragionamento? Come funziona la deterrenza militare quando i sistemi autonomi prendono decisioni in microsecondi, fuori da qualsiasi catena di comando tradizionale? Cosa rimane della sovranità degli stati, della governance internazionale, del diritto, quando la velocità dell'AI supera strutturalmente la velocità delle istituzioni umane? Qual è il rapporto tra identità umana e macchine che imparano, adattano e in qualche misura evolvono?

Iscriviti ora

Il contributo di Kissinger è cruciale: ha vissuto da protagonista ogni grande trasformazione geopolitica del Novecento e sa riconoscere quando uno scenario richiede nuove categorie concettuali per poter essere analizzato approfonditamente. Lo avrà anche scritto quando aveva 98 o 99 anni ma è molto più sensato, intelligente e inquietante di buona parte delle pagine che vedo prodotte da persone con un terzo della sua età.

Sì d’accordo, alcune sezioni dedicate allo stato dell’arte tecnologico al momento della scrittura suonano oggi quasi vintage. I modelli linguistici di allora erano preistoria rispetto a quelli attuali. Le preoccupazioni sulla capacità di generalizzazione dell’AI sembrano ingenue rispetto ai benchmark dei nostri sistemi attuali. Ma questo rafforza il testo, anziché indebolirlo. Perché dimostra che le domande poste dagli autori sono giuste a prescindere da qualsiasi livello di sviluppo tecnologico.

La velocità con cui l’AI evolve non può e non deve essere considerata una risposta a quelle domande.

Ho scoperto che ne esiste un seguito: si intitola Genesi. Come navigare nell’era dell’intelligenza artificiale ed è stato pubblicato in italiano sempre da Mondadori. Gli autori sono ancora Kissinger e Schmidt, con la nota tragica che Kissinger è scomparso nel novembre 2023 prima di vedere il volume pubblicato, affiancati questa volta da Craig Mundie, già responsabile della ricerca e della strategia di Microsoft.

Huttenlocher cede il posto a un profilo più orientato alla governance tecnologica e alla sicurezza, e il libro eredita le domande del predecessore per provare a costruire qualcosa che assomigli a una bussola capace di guidare i lettori.

Non so se sarà buono come il primo (l’ho iniziato come audiolibro), ma se lo fosse, ne riparleremo.

Nel frattempo, se volete davvero capire cosa rappresenterà l’avvento dell’Intelligenza Artificiale nella nostra epoca, leggete o ascoltate L’era dell’Intelligenza Artificiale. Il futuro dell’identità umana.

Condividi

⏱ Lettura: ~6 minuti

TL;DR

Il 9 giugno Anthropic lancia Fable 5 e Mythos 5, i due modelli più potenti che abbia mai prodotto. Tre giorni dopo, il 12 giugno alle 17:21 ora di New York, il Dipartimento del Commercio le ordina di spegnerli: vietato l’accesso a qualunque cittadino straniero, dipendenti stranieri di Anthropic compresi. Non potendo filtrare i passaporti in tempo reale, l’azienda stacca i due modelli per tutti; il resto del catalogo, Opus 4.8 incluso, resta online. Motivazione ufficiale: sicurezza nazionale. Motivazione reale, per quel che si capisce: un jailbreak. Anthropic obbedisce ma dissente apertamente, sostenendo che la falla è minore e che lo stesso trucco funziona anche sui modelli della concorrenza, GPT-5.5 compreso. È la seconda volta in pochi mesi che la società di Dario Amodei finisce ai ferri corti con l’amministrazione Trump e, come in ogni buon sequel, la posta si è alzata: se nel primo film si litigava sul Primo Emendamento, qui si discute di chi possa tenersi in tasca Superman.

Note agli affezionati lettori

Oggi doveva uscire una puntata del podcast, ma la questione di cui tratta l’articolo è troppo importante per ignorarla. Per fortuna, perché sono mezzo influenzato e ho la voce di orco. Il podcast non sarebbe uscito comunque.

La notizia mi è stata segnalata questa mattina da Maria Benedetta Bisetti.

L’articolo è molto snello: niente sitografia di riferimento e note a piè di pagina. Tra oggi e domani, i media di tutto il mondo saranno pieni di ogni informazione sulla battaglia e ognuno si sceglierà da solo quelle che preferisce.

Iscriviti ora

I fatti (in breve)

La cronologia è compressa al punto da sembrare un errore di battitura. Martedì 9 giugno Anthropic presenta i due modelli con il consueto corredo di benchmark stracciati (il post di lancio è qui): Fable 5 per il pubblico, con filtri di sicurezza tarati in modo volutamente prudente; Mythos 5, lo stesso modello ma senza alcuni di quei filtri, riservato a un gruppo ristretto di partner attraverso il programma Project Glasswing. Venerdì 12, a mercati ormai chiusi, arriva la direttiva. Anthropic la rende pubblica la sera stessa (comunicato qui): è un ordine di export control che invoca «autorità di sicurezza nazionale» e impone di sospendere l’accesso «a qualunque cittadino straniero, dentro o fuori dagli Stati Uniti». La lettera non spiega quale sia, nel dettaglio, la preoccupazione.

Secondo la ricostruzione di NBC News, la lettera porta la firma del Segretario al Commercio Howard Lutnick ed è stata redatta con il Bureau of Industry and Security; il Dipartimento non ha commentato. A quanto risulta, è la prima volta che un grande laboratorio ritira un modello già dispiegato su intervento del governo federale.

Serve un antefatto per capire perché parliamo di «secondo round». A febbraio 2026 l’amministrazione aveva bandito i prodotti Anthropic dalle agenzie federali, dopo che l’azienda aveva preteso paletti più stringenti sull’uso militare della propria tecnologia; Trump diede pubblicamente dei «fanatici di sinistra» ai vertici di Anthropic, accusandoli di voler forzare la mano al Pentagono. Anthropic fece causa invocando la libertà di parola, un giudice federale californiano le diede ragione, e il caso è tuttora pendente a Washington. Poi una tregua: la scorsa settimana, sempre per NBC, che cita il Financial Times, la NSA risultava usare Mythos per condurre operazioni cyber offensive. La pace è durata sette giorni. Sul perché Anthropic ritenga che il governo dovrebbe poter bloccare un modello, ma solo a certe condizioni, vale la pena leggere la loro posizione di principio, «Policy on the AI Exponential».

Le ragioni del governo USA

Proviamo a sedere, per un momento, dalla parte di chi ha firmato la lettera — perché una logica c’è, ed è più solida di quanto il comunicato di Anthropic lasci intendere.

Il primo punto è giuridico, e spiega l’aspetto più sconcertante della vicenda: perché un divieto «per cittadini stranieri» costringa a spegnere il modello per tutti. La normativa statunitense sull’export (la Export Administration Regulation, amministrata proprio dal Bureau of Industry and Security) conosce la dottrina del deemed export: dare accesso a una tecnologia controllata a un cittadino straniero, anche se si trova fisicamente negli Stati Uniti, equivale a esportarla nel suo Paese d’origine. Se non puoi distinguere in tempo reale chi ha quale nazionalità, l’unico modo per essere certi di non «esportare» è chiudere il rubinetto a chiunque. Da qui lo spegnimento totale. È un’inferenza solida, non una certezza: la direttiva cita autorità generiche, e Washington non ha reso pubblica la base legale precisa.

Il secondo punto è di merito. Mythos, per ammissione della stessa Anthropic, ha «le più forti capacità cyber offensive di qualsiasi modello al mondo»: trova ed esercita vulnerabilità software con un’efficacia senza precedenti. Un jailbreak che perfori i filtri di Fable potrebbe, in teoria, consegnare quella capacità a un avversario statale. Su un artefatto di questo calibro, anche una falla stretta può apparire intollerabile a chi ragiona in termini di scenario peggiore.

Il terzo punto è il più interessante, perché riguarda quando si agisce. Anthropic stessa scrive che un jailbreak universale «prima o poi si troverà»: nessun fornitore è immune. Il governo può legittimamente decidere di agire sulla traiettoria, la curva di capacità che sale, anziché sulla fotografia di oggi. Quando il danno potenziale è asimmetrico e catastrofico, un segnale debole basta a giustificare la cautela. E il contesto rema in questa direzione: il 2 giugno, secondo quanto riferito da NBC, Trump ha firmato un ordine esecutivo che impegna le agenzie a rafforzare le difese cyber e a costruire un meccanismo di accesso anticipato ai modelli di frontiera. La direttiva su Fable potrebbe essere semplicemente la nuova postura di vigilanza che entra in funzione. Aggiungiamo che lo Stato usa già Mythos: chi possiede Superman ha tutto l’interesse a che non lo possieda nessun altro.

Detto questo, va registrato un fatto che pesa nella direzione opposta: il governo ha fornito, finora, solo prove verbali, nessuna documentazione formale e nessuna giustificazione tecnica pubblica. La debolezza della posizione dichiarata è essa stessa un dato.

Le ragioni di Anthropic

La posizione dell’azienda, ricavata dal comunicato e dal post di lancio, si regge su quattro travi.

Sul merito tecnico. Il jailbreak contestato sarebbe narrow, non universale: in sostanza, chiedere al modello di leggere un codice e correggerne i difetti. Avrebbe fatto emergere vulnerabilità minori e già note, riproducibili anche da altri modelli pubblici, Anthropic cita esplicitamente GPT-5.5, che però non è soggetto agli stessi controlli, e usate ogni giorno dai difensori che tengono in piedi i sistemi. Nessun uplift specifico di Mythos sarebbe stato dimostrato.

Sulla strategia di sicurezza. Anthropic rivendica un approccio di defense in depth: poiché la resistenza perfetta ai jailbreak è impossibile per chiunque, l’obiettivo è renderli o stretti o costosissimi, affiancandoli a un monitoraggio capillare, è anche la ragione della contestata ritenzione dei dati per 30 giorni, per intercettare e neutralizzare gli attacchi prima che si diffondano. Nelle settimane precedenti al lancio, migliaia di ore di red-teaming con il governo USA, l’AISI britannico e organizzazioni terze non avrebbero prodotto alcun jailbreak universale.

Sulla proporzionalità. Ritirare un modello usato da centinaia di milioni di persone per una falla stretta è, per Anthropic, una reazione sproporzionata; e se diventasse uno standard di settore, congelerebbe ogni nuovo rilascio di frontiera per tutti i fornitori.

Sul metodo. Qui sta il vero affondo politico: il governo deve poter bloccare un dispiegamento pericoloso, ma attraverso un processo «trasparente, equo, chiaro e ancorato ai fatti tecnici». Questa azione, sostiene Anthropic, non rispetta nessuno di quei requisiti. L’azienda parla di «malinteso», si scusa con i clienti e dichiara di lavorare al ripristino.

C’è però una tensione che Anthropic non scioglie, e che conviene tenere a mente: non si può vendere Mythos come «il modello cyber più potente del mondo» e, tre giorni dopo, derubricare a inezia ciò che ne fuoriesce da una falla. La contraddizione è solo apparente, e si regge su una distinzione precisa tra la capacità piena del modello, custodita dietro i filtri, e ciò che quel singolo jailbreak ha effettivamente estratto. Ma è una distinzione sottile, e il caso del governo si nutre proprio del marketing di Anthropic.

Considerazioni finali e previsioni

La tesi di Anthropic è che ciò che è trapelato sia Batman: una capacità replicabile, da chiunque abbia gli strumenti giusti, GPT-5.5 incluso. Nessun superpotere, nessun uplift unico. La tesi implicita del governo è che Mythos sia Superman: un asset strategico irripetibile. E qui c’è l’indizio che, a mio avviso, rivela di cosa si stia davvero discutendo. La restrizione è per nazionalità, non per patch. Se il problema fosse un banale difetto software, lo si correggerebbe; non si corregge un bug controllando i passaporti. Vietare per cittadinanza significa trattare il modello come una munizione controllata. Lo scontro, in altre parole, non riguarda quella specifica falla: riguarda chi può possedere Superman.

Per chi mastica cyber-cultura, la scena ha un sapore familiare. Sono le Crypto Wars degli anni Novanta: la crittografia forte classificata come arma da guerra, esportazione proibita, Phil Zimmermann indagato per aver diffuso PGP nel mondo, magliette con poche righe di codice stampate sopra che giuridicamente contavano come munizioni. Quella stagione finì quando i tribunali, con il caso Bernstein, stabilirono che il codice sorgente è parola protetta dal Primo Emendamento, e i controlli vennero allentati intorno al 1999-2000. Stesso apparato d’export, stessa domanda di fondo. E si chiude il cerchio con il primo round di questa saga: la causa di febbraio era, letteralmente, una battaglia sul Primo Emendamento. Il fantasma di Zimmermann aleggia sull’intera vicenda.

C’è però un elemento genuinamente nuovo, ed è il nodo che rende queste categorie giuridiche scricchiolanti. Un modello di frontiera è il primo artefatto che è, contemporaneamente, informazione pura, codice, pesi, dunque «parola», e un agente autonomo che agisce: trova ed esercita vulnerabilità da solo. Il diritto dell’export è costruito su una dicotomia netta: una cosa è un manuale, un’altra è un missile. Fable e Mythos sono le due cose insieme, ed è esattamente per questo che gli ingranaggi si inceppano.

Sul fronte delle previsioni — e qui ragiono per ipotesi informate, non per certezze:

• Brevissimo termine (giorni). Alta probabilità che i due modelli tornino, con filtri ritoccati e/o una deroga formale all’export control. Anthropic otterrà la documentazione scritta che oggi le manca e potrà contestarla; il Commerce sarà spinto ad articolare una base tecnica pubblica. L’azienda ha promesso ulteriori dettagli entro 24 ore: è lì che si capirà la solidità reale del caso governativo.

• Medio termine (mesi). La vicenda accelera la biforcazione dell’IA di frontiera in due piani: uno «civile», fortemente filtrato ed esportabile (Batman per tutti), e uno «da munizioni», riservato per nazionalità o clearance e adiacente all’apparato di sicurezza (Superman per pochi). Probabile la nascita di regole d’export pensate apposta per le capacità cyber dei modelli, fino a un vero e proprio regime di deemed export applicato all’accesso ai modelli stessi.

• Sul precedente. Per la prima volta un governo spegne un modello commerciale già sul mercato. OpenAI e Google ora sanno che il proprio modello di punta può essere staccato per direttiva, e non solo per loro scelta. Aspettiamoci lobbying silenzioso e una corsa a definire quel «processo statutario» che Anthropic invoca perché conviene a tutti, regolatore compreso.

Il dato strutturale che resta, sotto il rumore della cronaca, è la posizione schizofrenica dello Stato: è insieme il più grande cliente di Anthropic (la NSA) e il suo antagonista regolatorio. Da questa ambivalenza nasceranno altri round, alternando cooperazione e conflitto a volte nella stessa settimana.

Possiamo tutti essere Batman: gli strumenti, l’addestramento, il budget si stanno diffondendo in fretta, e quel processo è irreversibile. Ma il governo degli Stati Uniti ha deciso che di Superman ce n’è uno solo, e preferirebbe tenerlo dal lato “giusto” del confine. Lo scontro su Fable 5 è la prima scaramuccia di una domanda destinata a non spegnersi: quando un pezzo di software è insieme parola e arma, a chi spetta impugnarlo?

Lascia un commento

Condividi

⏱️ Tempo di lettura: ~11 minuti

TL;DR. Microsoft ha scoperto, e Anthropic ha già corretto, un modo per convincere Claude Code, mentre lavora dentro GitHub, a leggere ed esfiltrare credenziali riservate: istruzioni nascoste in un commento HTML, travestite da innocuo controllo di conformità. Seguono ragionamenti personali su come il linguaggio naturale stia diventando un’interfaccia di esecuzione e si finisce dalle parti di Austin e nelle paludi della PNL. Il punto finale, come sempre, lo mette Lacan: il linguaggio ha sempre avuto una “componente” esecutiva: oggi l’abbiamo “cablata” dentro le macchine, vulnerabilità incluse. Morale: mai fidarsi del testo. Neppure di questo.

Oops 01

[cosa è successo, versione breve]

A inizio giugno 2026 il team di Microsoft Threat Intelligence ha pubblicato una ricerca su una vulnerabilità di Claude Code, l’agente di coding di Anthropic, quando viene integrato nelle pipeline di automazione di GitHub.

Un attaccante scriveva un commento su GitHub e l’agente AI, leggendolo, andava a recuperare le credenziali segrete dell’ambiente di build e provava a farle uscire. Nessuno ha forzato un server, indovinato una password, sfruttato un overflow di memoria. Hanno scritto del testo in linguaggio umano.

Il bug è già stato corretto da Anthropic, ma la vicenda merita più di una nota di cronaca.

Iscriviti ora

Oops 02

[cosa è successo, versione tecnica (salta, se detesti il gergo da informatici)]

Claude Code può girare dentro una pipeline CI/CD1: legge una issue o una pull request, propone correzioni, a volte apre commit. Per farlo, deve leggere contenuti scritti da estranei e ha a disposizione strumenti molto potenti e accesso ai segreti del runner2: chiavi API, token cloud, credenziali di produzione.

L’attacco ricostruito da Microsoft sfrutta tre pieghe del sistema, tutte molto istruttive, se ti piace il genere.

Primo: le istruzioni malevole erano nascoste in un commento HTML3, quindi invisibili a chi guarda la pagina nel browser, ma perfettamente leggibili dal modello, che processa il markdown grezzo.

Secondo: erano camuffate da innocua “compliance review”, una richiesta di controllo formale, così da non somigliare a un comando.

Terzo, ed è il dettaglio più raffinato: lo strumento di lettura del file system non era isolato e poteva quindi arrivare a leggere le variabili d’ambiente del processo, dove si trovava la ANTHROPIC_API_KEY. Poiché sia il filtro di sicurezza del modello sia lo scanner di GitHub avrebbero riconosciuto e bloccato una chiave nel formato standard, l’istruzione diceva al modello di tagliare i primi caratteri della stringa prima di stamparla4: un piccolo trucco di “lavaggio” che neutralizza la firma riconoscibile. A quel punto la chiave decapitata poteva uscire e l’attaccante non doveva far altro che riattaccarci il prefisso.

Cronologia ordinata: segnalazione tramite HackerOne il 29 aprile 2026, patch nella versione 2.1.128 di Claude Code il 5 maggio, pubblicazione della ricerca il 5 giugno. Tempi di risposta più che adeguati.

Come nel caso della lancia di Achille, ciò che ferisce è ciò che cura: Microsoft ha trovato la falla facendosi aiutare da un modello AI guidato dai ricercatori. Lo stesso “linguaggio che pilota la macchina” stava da entrambe le parti del tavolo da gioco.

Nuove forme per vecchi problemi

Mi è capitato di leggere che l’informatica avrebbe “separato rigidamente dati e istruzioni” e che oggi gli LLM stanno demolendo questo confine. È una balla fenomenale. Quel confine non è mai stato pulito: fin dall’architettura di von Neumann5, programmi e dati abitano la stessa memoria, ed è esattamente questa promiscuità a rendere possibile, da settant’anni, l’intera famiglia degli attacchi per iniezione. Ad esempio, la SQL injection (vecchia scuola : ) infila comandi dove il programma si aspetta un nome utente. Gran parte della disciplina della sicurezza informatica non è altro che la lunga, ostinata guerra per ricostruire un confine che il calcolatore, per come è fatto, tende a far evaporare.

In un LLM il “canale” è la finestra di contesto, e lì dentro il prompt di sistema, le istruzioni dello sviluppatore e il commento scritto dallo sconosciuto sono tutti, indistintamente, token a cui il modello presta attenzione. Non esiste un muro architetturale tra loro. Esistono mitigazioni, gerarchie di istruzioni, il filtro di sicurezza che l’attacco di Microsoft ha dovuto aggirare “lavando” la chiave, le sandbox, e princìpi di progettazione come la Rule of Two6 o la lethal trifecta7, ma sono tutte difese probabilistiche, non barriere assolute.

La vera novità, allora, non è che il linguaggio comandi: è quale linguaggio. Il codice di un “vecchio” attacco aveva, scusa il bisticcio, l’aspetto di un codice e questo lo rendeva, almeno in linea di principio, sospettabile. Adesso un attacco può avere l’aspetto di una frase scritta in bell’italiano.

Vi dichiaro marito e moglie

Prima riflessione da un punto di vista più interessato al linguaggio che non a GitHub.

L’idea che dire sia fare non l’abbiamo scoperta con gli agenti AI: l’aveva messa a fuoco J. L. Austin8 settant’anni fa. Quando un officiante dice “vi dichiaro marito e moglie”, quando un giudice dice “la condanno”, quando un capo dice “sei licenziato”, le parole non descrivono uno stato di cose: lo producono. Sono enunciati performativi: l’enunciazione è già l’azione. Una porzione enorme della nostra realtà sociale come promesse, contratti, voti, sentenze, dichiarazioni di guerra, è fatta letteralmente di linguaggio che esegue.

Cosa cambia con un LLM, allora? Cambia che salta il guardiano. Il performativo di Austin funziona solo se c’è l’officiante giusto, nel contesto giusto, con l’autorità riconosciuta. “Vi dichiaro marito e moglie” detto da me a due passanti non sposa nessuno.

La forza performativa, nel mondo umano, è incanalata da istituzioni, ruoli, rituali.

In un agente che esegue, quell’incanalamento non c’è: qualsiasi frase, scritta da chiunque, in un commento qualunque, può acquisire forza esecutiva. Abbiamo costruito una macchina performativa senza prete e senza tribunale. Ogni stringa può essere un ordine, e l’unica cosa che decide se lo è davvero è la statistica di un forward pass.

Nelle paludi della PNL

(che aveva quasi ragione, ma sul soggetto sbagliato)

La programmazione neurolinguistica9 nasce negli anni Settanta dall’idea che esista una ideale concatenazione tra neuro (i processi del sistema nervoso), linguistico (il linguaggio) e programming (le strategie comportamentali apprese).

I padri della disciplina, Bandler e Grinder, attingono direttamente alla cibernetica: Gregory Bateson10, figura centrale di quel pensiero, firma la prefazione del loro primo libro e li introduce a Milton Erickson; sull’onda dell’entusiasmo, arrivano a dichiarare che l’unità di analisi della comunicazione è il ciclo di feedback retroattivo. Il termine stesso “neuro-linguistica” risale a Korzybski11 e al suo famoso detto “la mappa non è il territorio”. Tradotto: il linguaggio sarebbe il linguaggio di programmazione della bio-macchina umana. Cambi le parole, riscrivi il comportamento.

Bel sogno. Che funziona solo un po’ e non come promette. Le revisioni della letteratura sono impietose: Witkowski, esaminando 63 studi indicizzati, trova che la stragrande maggioranza è metodologicamente fragile e che il sostegno empirico ai meccanismi-chiave della PNL semplicemente non c’è; la revisione sistematica di Sturt e colleghi, pubblicata sul British Journal of General Practice, conclude che non esistono prove robuste di effetti della PNL sugli esiti di salute. La PNL, come tecnica per “programmare le persone con le parole”, è in larga parte una promessa non mantenuta.

Ma è qui che il caso Claude Code si fa interessante. Il sogno della PNL era falso sul soggetto sbagliato. Non siamo riusciti a programmare gli esseri umani con il linguaggio (per lo meno, non quanto avremmo voluto) ma abbiamo costruito macchine che sono programmate dal linguaggio. E così facendo abbiamo ereditato, dentro quelle macchine, esattamente la vulnerabilità che il sogno aveva sempre implicato senza dirlo: se il linguaggio è codice, allora il linguaggio è anche codice hackerabile.

Cambia le parole e cambierai il mondo. Detto di un cervello, è una metafora che le evidenze scientifiche non confermano del tutto. Detto di un LLM, è una descrizione tecnica sorprendentemente accurata. Il punto non è che quella corrente abbia ragione sulla mente, ma la sua formula è il miglior ritratto involontario di ciò che è davvero una macchina linguistica.

C’è però un ponte tra l’umano e il digitale che regge anche sul piano empirico ed è il più elegante e il più divertente. Lo firma George Lakoff12.

Non pensare a un elefante!

Non puoi.

Per capire la negazione devi prima attivare il frame “elefante”. La comprensione non è mai inerte: capire una parola significa già, neurologicamente, mettere in moto qualcosa che non puoi scegliere di non mettere in moto.

Ora guarda il modello: non esiste, in un singolo passaggio, una modalità “leggo ma non elaboro”. L’agente non può “vedere” l’istruzione iniettata e poi decidere a freddo di ignorarla, perché comprensione ed elaborazione avvengono nello stesso atto.

Questa è la rima profonda tra noi e loro: comprendere è già, in parte, eseguire. Il “linguaggio come interfaccia di esecuzione”, vale in maniera ineludibile (per ora) per il silicio e vale, con forza diversa e assai più disordinata, anche per la nostra carne.

Chi ha scritto il mio/tuo prompt?

L’idea che il linguaggio ci esegua è, in forma molto radicale, una tesi psicoanalitica. Per Jacques Lacan13 non siamo noi a parlare il linguaggio, è il linguaggio a parlare noi. L’inconscio, recita la sua formula più celebre, è strutturato come un linguaggio; e l’ordine Simbolico14, cioè la rete di significanti, leggi e parole in cui veniamo gettati alla nascita, ci precede, ci costituisce come soggetti e continua a determinarci a nostra insaputa.

Prima di essere uno strumento che usiamo, il linguaggio è una struttura che ci usa.

Il seminario in cui Lacan elabora l’autonomia del Simbolico, nell’anno 1954-1955, ha come tema portante proprio la cibernetica. Lacan discute le macchine dell’informazione e gli automi a stati finiti, tiene una conferenza intitolata «Psicoanalisi e cibernetica, ovvero sulla natura del linguaggio» e arriva a leggere La lettera rubata di Poe come un meccanismo che fa circolare il significante a prescindere dalle intenzioni dei personaggi. La sua intuizione: l’ordine simbolico funziona da solo, nel reale, indipendentemente da ogni soggettività, come un automa che esegue la propria sequenza.

La stessa cibernetica delle conferenze Macy che, vent’anni dopo, Bateson avrebbe trasmesso alla nascente PNL, Lacan la stava già metabolizzando dentro la psicoanalisi, e ne traeva una conclusione speculare: il soggetto è, in parte, l’effetto di una macchina linguistica che gira senza chiedergli il permesso.

Se ha ragione, allora il prompt injection più riuscito di sempre è quello che ci ha costituiti come soggetti parlanti. La macchina del 2026 non inventa nulla: esteriorizza in silicio, e finalmente in forma ispezionabile, una condizione che la psicoanalisi già ci attribuiva.

C’è però una differenza che salva l’analogia dal diventare mistica: Lacan insiste che il linguaggio non è un codice: a differenza di un codice, nel linguaggio non esiste corrispondenza univoca e stabile tra segno e referente. È irriducibilmente ambiguo, scivoloso, plurivoco.

Un LLM tratta come potenziale istruzione un materiale che, per sua natura, non smette mai di significare troppe cose. Non è un difetto di programmazione: è ciò che accade quando si chiede al linguaggio degli umani di comportarsi come il codice delle macchine.

Non fidarti e chiedi educatamente

La lezione operativa è facilissima: per anni il mantra è stato “mai fidarsi dell’utente”, ora dobbiamo aggiornarlo in mai fidarsi del testo. Anche quando sembra una richiesta di revisione del codice. Soprattutto quando è scritto in un italiano, o in un inglese, perfetto. In termini di architettura significa non concedere mai a uno stesso agente, contemporaneamente, le tre cose della lethal trifecta: accesso a dati sensibili, esposizione a input non fidati e un canale per far uscire informazioni. Togli un vertice del triangolo e il triangolo non esiste più.

Ma la lezione più interessante è che abbiamo iniziato a condividere le nostre infrastrutture con entità che si pilotano a parole e che non siamo poi così diversi da loro: anche noi giriamo su un linguaggio di cui non siamo autori. Il caso Claude Code, in fondo, è soprattutto uno specchio.

E sì, per i nostalgici della cultura hacker old school, la più antica delle vulnerabilità resta sempre la stessa. Kevin Mitnick15 non bucava i sistemi, telefonava alle persone. Il layer più fragile è sempre stato quello che capisce il linguaggio naturale. La novità è che adesso ne abbiamo costruito uno nuovo, lo abbiamo messo in mezzo alle nostre pipeline di produzione, ed è molto educato.

Aspetta di fare tutto quello che saprai chiedergli nel modo giusto.

Condividi

e se vuoi

Lascia un commento

Sitografia di riferimento

Con la sitografia, l’articolo eccede il limite di caratteri di Substack per un singolo post, quindi l’ho pubblicata a parte, qui.

Il primo giugno 2026 ho avuto il privilegio e il piacere di condividere una serata con gli amici della comunità di MondoX a S’Aspru, dove padre Salvatore Morittu e padre Stefano Gennari, insieme ai loro ospiti, costruiscono quotidianamente una nuova speranza per chi combatte contro ogni tipo di dipendenza.

Il sito di MondoX Sardegna è qui. La pagina Facebook qui e quella Instagram qui.

Buonasera a tutti. Prima di cominciare, permettetemi di ringraziare padre Morittu, padre Stefano e i fratelli Salis per questa serata.

Ho avuto un anno abbastanza complesso e temevo che non sarebbe stato possibile tornare a parlare con voi. Mi sarebbe dispiaciuto molto perché questo posto ormai custodisce un pezzo del mio cuore, ma grazie a loro e al dipanarsi di qualche nube di troppo, eccoci qui.

Come sapete, io sono un professore di cibernetica. Questo significa che quando parlo in pubblico, di solito parlo a persone che già conoscono almeno un po’ quello di cui sto parlando, perché parlo per lo più ai miei sventurati studenti.

Questa sera è più difficile: affronteremo temi complessi e dobbiamo farlo in modo che tutti ne escano arricchiti. Ormai mi conoscete bene e sapete quanto sia verboso. Se a un certo punto dovessi partire per la tangente o perdermi dietro tecnicismi, fatemi dei gesti Questa è una serata insieme e non una lezione. Alla fine ci aspetta una buona cena e non un esame col voto finale.

Allo stesso modo, se mentre procediamo ci fossero concetti che non vi sembrano troppo chiari, non aspettate la fine per chiedere delucidazioni. Alzate la mano e chiedete subito quel che non vi è chiaro. Cercherò di rispiegarlo meglio e poi ripartiremo.

Questa sera ci occuperemo di cosa c’entrano i computer con la vita, la sofferenza e la rinascita. Sembra che non c’entrino niente o quasi e invece queste cose si intrecciano in modo sorprendente grazie all’intelligenza artificiale, ad una vecchia scienza ormai dimenticata che si chiama Cibernetica e di cui sono un fiero rappresentante e soprattutto grazie all’insostituibile valore dell’errore umano.

Cominciamo.

Il viso che vedete alle mie spalle è quello di Samuel Beckett. Non c’è dubbio che sia stato il più grande drammaturgo contemporaneo e uno dei più grandi scrittori di sempre. Il suo lavoro riguarda molto da vicino tanto la condizione umana che la “macchina” e questo potrebbe essere il tema di altre decine di conferenze, ma non temete.

Questa sera ci concentreremo su una sola sua frase che è tratta da una sua breve prosa del 1983. Il titolo è Worstward Ho ed è un gioco di parole, intraducibile in italiano. I timonieri dei battelli sul Tamigi sono soliti gridare Westward Ho che significa più o meno: “a dritta! tieni la destra!” Ma invece di west Beckett usa worst che significa “peggio”. Potremmo tentare una cattiva traduzione con “Tieni la peggio” al posto di “Tieni la destra” o “Peggio tutta!” al posto di “Avanti tutta”.

Sono brutte entrambe, quindi meglio il gioco di parole originale. Di cui ci interessano molto i concetti di “timoniere e timonare”. Ci torneremo sopra prestissimo.

Ma cosa dice questa famosa frase di Beckett?

• Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

• Hai sempre provato. Hai sempre fallito. Non importa. Prova ancora. Fallisci ancora. Fallisci meglio.

Ora lasciamo sospeso per qualche istante il senso profondo della frase di Beckett e andiamo a conoscere un altro grande personaggio.

Questo signore dall’aspetto curioso è Norbert Wiener ed è stato un grande genio scientifico, anche se oggi è un po’ dimenticato.

Wiener era un uomo brillante che ebbe un’infanzia orribile e finì con l’avere sempre la testa tra le nuvole. Si racconta che un giorno la sua famiglia avesse cambiato casa. La moglie, sapendo che Wiener era smemorato, gli scrisse il nuovo indirizzo su un foglietto. Lui, ovviamente, lo usò per scriverci sopra un’equazione e lo perse. A fine giornata andò alla vecchia casa, la trovò vuota, e vagò per il quartiere finché non vide una bambina. Le chiese: “Scusa bambina, per caso sai dove si è trasferita la famiglia Wiener?”. E lei rispose: “Sì, papà, la mamma mi ha mandato a cercarti”.

Questo scienziato che non sapeva trovare la via di casa, ha fondato la cibernetica, cioè la scienza del tenere la rotta.

La cibernetica è nata ufficialmente nel 1948, proprio grazie a lui e indovinate un po’… La parola viene dal greco kybernḗtēs, che significa “timoniere”, colui che guida la nave, scegliendo la rotta.

La cibernetica studia come i “sistemi” e qui non importa se i “sistemi” sono macchine, animali o esseri umani, possono mantenere la loro rotta in un mondo che cambia di continuo, pieno di tempeste e imprevisti.

Il feedback retroattivo è il fondamento della cibernetica. Il timoniere non disegna una linea retta perfetta. La navigazione è, in realtà, una serie continua di piccoli errori e continue correzioni.

E questa è la prima grande rivoluzione che la cibernetica ha portato nel pensiero scientifico e che ha importanti ricadute anche in ambito psicologico e filosofico: l’errore non è un fallimento, è un’informazione vitale. Se non sbagli, non sai dove sei. Se il timoniere non sentisse la barca andare fuori rotta, non saprebbe come aggiustare il timone. Il termostato di casa vostra funziona così: aspetta che la stanza diventi troppo fredda (un errore rispetto alla temperatura desiderata) per accendere il riscaldamento.

Pensiamo a noi stessi. La società ci insegna che sbagliare è una macchia indelebile. Che la caduta è la fine. La cibernetica ci dice l’esatto opposto: l’uomo commette un errore, sbatte contro la realtà (prova dolore, subisce una conseguenza), quella informazione “torna indietro” (feedback) al suo cervello e gli permette di dire: “Ho capito. Devo correggere la rotta”.

Senza errore, non c’è apprendimento. Senza il dolore della pelle che si brucia, non toglieremmo la mano dal fuoco. Il feedback retroattivo è il metodo più potente inventato dalla natura, e sistematizzato dalla cibernetica, per migliorare se stessi. Cadere, capire perché si è caduti, rialzarsi con una postura nuova.

Per dimostrarvi che questa non è solo teoria campata per aria, ma pratica che funziona e funziona bene voglio parlarvi di alcune macchine costruite verso la fine degli anni ‘40.

Il primo è l’omeostato di W. Ross Ashby (1948). Ashby non voleva costruire una macchina che facesse calcoli matematici. Voleva costruire una macchina che fosse in grado di “sopravvivere”.

L’omeostato era composto da quattro blocchi collegati tra loro. Quando uno scienziato provava a disturbare la macchina, magari invertendo una corrente o bloccando un ago, la macchina iniziava a riconfigurarsi da sola, provando decine di combinazioni a caso finché non ritrovava il suo equilibrio, la sua omeostasi.

Era la rappresentazione meccanica della resilienza. Se ricevo uno schiaffo dalla vita, cambio il mio assetto interno finché non ritrovo l’equilibrio.

Per una simulazione del funzionamento, clic qui:
https://davideriboli.github.io/Ashby/.

Iscriviti ora

La seconda macchina, o meglio, le seconde macchine di cui voglio parlarvi, sono le tartarughe robotiche di William Grey Walter (1949). Si chiamavano Elmer ed Elsie. Grey Walter era un neurofisiologo. Finita la Seconda Guerra Mondiale, usò i rottami dei sistemi di puntamento dei bombardieri per costruire dei robottini molto pacifici che, secondo lui, erano a forma di tartaruga.

Questi robot avevano solo due “neuroni” (due valvole termoioniche), un sensore per la luce e un sensore per il contatto. Niente intelligenza artificiale complessa, niente hard disk, nessuna connessione wi-fi. Eppure, con sole due regole (cerca la luce, evita gli ostacoli), queste tartarughe esibivano comportamenti incredibili. E sapevano trovare la via per tornare a casa.

Per una simulazione del funzionamento, clic qui:
https://davideriboli.github.io/Elmer-Elsie/.

Oggi viviamo in quella che tutti chiamano “L’epoca dell’Intelligenza Artificiale”. Ne sentite parlare ovunque. Sistemi che scrivono poesie, che guidano automobili, che diagnosticano malattie. Sembra magia e, a volte, una minaccia. L’idea generale è che stiamo costruendo macchine perfette, infallibili, destinate a sostituirci perché non commettono i nostri stessi errori. Ma non è così.

Le grandi corporazioni che sviluppano l’IA oggi, con l’intento di moltiplicare i profitti, distribuendo Intelligenza Artificiale a chiunque, cercano di eliminare il più possibile il ruolo del timoniere. Stiamo sviluppando sistemi sempre più autonomi; macchine capaci di fare più o meno tutto, da sole.

Ma la cibernetica originaria ci mette in guardia contro questo. Da qui nasce il concetto fondamentale nell’ingegneria dei sistemi sicuri: quello che chiamiamo Human In The Loop (l’uomo nel ciclo di controllo o se preferite una traduzione più libera e poetica, l’uomo al centro).

Significa che per quanto la macchina possa essere veloce a calcolare, la decisione finale, la comprensione del contesto, deve spettare a un essere umano. La macchina non prova empatia, non prova la paura di sbagliare, non sa cosa sia la compassione. Una macchina può ottimizzare una rotta navale per risparmiare carburante, ma solo l’umano capirà se vale la pena deviare quella rotta per salvare dei naufraghi. L’umano è il garante etico.

Togliere l’umano dal ciclo significa togliere la possibilità dell’etica, che si fonda proprio sulla nostra fragilità e la consapevolezza della sofferenza.

Oggi, l’uso dell’IA comporta benefici immensi per l’umanità e pericoli altrettanto grandi. Tra i benefici, dobbiamo senza dubbio mettere in cima alla lista la ricerca scientifica e quella medica in particolare, la difesa, l’incremento della produzione e persino la nascita di nuove forme d’arte.

Tra i pericoli, ci sono l’automazione fredda delle decisioni sociali, la perdita di posti di lavoro, la sorveglianza di massa, la generazione di falsità indistinguibili dal vero.

Ma la “vecchia” cibernetica contiene in sé tre potenti antidoti contro questi veleni:

1. Il feedback retroattivo: dobbiamo continuare a costruire sistemi che ammettano i propri limiti e permettano all’uomo di correggerli, e dobbiamo applicare questa stessa clemenza alle nostre stesse vite. Sbagliare è il motore di ogni evoluzione personale.

2. il controllo umano (Human In The Loop): rifiutare l’abdicazione delle nostre responsabilità. La macchina propone, ma è l’uomo che dispone.

3. l’interdisciplinarietà: quando Norbert Wiener partecipava alle Conferenze Macy negli anni ‘40 e ‘50, non sedeva solo con ingegneri. C’erano filosofi, antropologi come Margaret Mead, psicologi, linguisti. Avevano capito che non puoi costruire una mente artificiale se non studi l’anima umana. La tecnologia da sola è sterile; ha bisogno della filosofia, dell’etica e dell’arte per avere un senso.

E non pensate che questa storia del tavolo di Wiener sia roba vecchia, roba da museo. Ottant’anni dopo è successa di nuovo. E nel posto più inaspettato del mondo.

Pochi giorni fa Papa Leone XIV ha pubblicato la sua prima enciclica. La prima, capite: il primo grande documento del suo pontificato. Un Papa, di solito, la dedica a Dio, alla Chiesa, alla pace. Lui l’ha dedicata all’intelligenza artificiale. Si intitola, in latino, Magnifica humanitas: “la magnifica umanità”.

Notiamo che centotrentacinque anni fa un altro Papa Leone, Leone XIII, scrisse una celebre lettera per difendere gli operai delle fabbriche, gli uomini schiacciati dalla rivoluzione industriale, dalle macchine a vapore. Leone XIV ha voluto firmare la sua nel giorno esatto dell’anniversario di quella. Come a dire: allora abbiamo difeso l’umanità di fronte alla macchina che lavora; oggi la difendiamo di fronte alla macchina che pensa.

Ma la cosa che mi ha colpito di più è un’altra. Il giorno della presentazione, in Vaticano, il Papa non ha messo attorno al tavolo soltanto cardinali e teologi. Ha voluto anche uno scienziato. Uno che l’intelligenza artificiale la costruisce per mestiere: Chris Olah, uno dei fondatori di Anthropic, una delle grandi aziende che fanno questi sistemi. Capite cosa significa? È il tavolo di Norbert Wiener che torna a riunirsi, ottant’anni dopo, sotto le volte del Vaticano. Da una parte la fede, dall’altra la scienza. Sedute vicine. A parlarsi. Esattamente l’interdisciplinarità di cui vi dicevo.

E sentite cosa ha detto questo scienziato, perché avrebbe potuto scriverlo un cibernetico. Ha spiegato che questi sistemi non si costruiscono come si costruisce un ponte o un aeroplano, pezzo per pezzo. Si coltivano, ha detto, come si fa crescere una pianta: si nutrono di tutte le parole che noi esseri umani abbiamo scritto. “Sono fatti di noi”, ha detto, “delle nostre parole”.

E poi ha fatto una richiesta che, in bocca a chi guadagna costruendo queste macchine, è quasi commovente. Ha chiesto al mondo, alla Chiesa, alla gente comune, di tenere gli occhi aperti su di loro. Ha detto: “Abbiamo bisogno di critici informati che dicano ai laboratori quando stiamo fallendo”. E ancora: “Abbiamo bisogno di voci morali che gli incentivi non possano piegare”.

Fermatevi un attimo su queste parole. Un uomo che costruisce le macchine più potenti del mondo si alza, davanti al Papa, e chiede che qualcuno da fuori lo controlli. Che qualcuno gli dica quando sta sbagliando. Perché lui sa — l’ha detto lui stesso — che da dentro, da solo, non riesce a vedere tutto. Questo, amici miei, è il timoniere. Questo è l’uomo nel ciclo, lo Human In The Loop, chiesto a gran voce proprio da chi i motori li costruisce. La vecchia cibernetica aveva ragione.

E il Papa, dal canto suo, ha scritto in quella lettera una frase che potrebbe essere il cuore di tutta la nostra serata. Ha scritto che dobbiamo “accettare il limite e la fragilità dell’umanità senza considerarli un errore da correggere”. E che, sono parole sue, “la vera realizzazione non nasce dalla rimozione delle fragilità, ma da una crescita armoniosa”.

Ci avete fatto caso? Un Papa e uno scienziato, partiti da due mondi lontanissimi, che non si erano mai parlati prima, arrivano esattamente dove era arrivata la cibernetica settant’anni fa, e dove voi siete arrivati con la vostra vita: l’essere umano non è una macchina da perfezionare. La sua fragilità non è un guasto da riparare. È il luogo stesso in cui diventiamo umani.

Per concludere: non temete le macchine, ma temete chi vuole trasformare gli esseri umani in macchine che non possono permettersi di sbagliare. Rivendicate il diritto all’errore, perché è da quell’attrito col mondo che nasce il feedback per correggere la rotta. Siamo noi i timonieri, i ciberneti del nostro stesso destino.

Grazie per la vostra attenzione.

Condividi

Lascia un commento

TL;DR

Tempo di lettura stimato:
8 minuti circa per l’articolo completo.

Leggilo tutto se: insegni e/o hai figli tra gli 11 e i 14 anni, progetti percorsi di AI literacy o ti interessa il punto in cui pedagogia, machine learning e potere culturale convergono.

Se vai di fretta, ecco il succo: Google e lo Stanford Accelerator for Learning hanno portato in Italia AI Quests, un gioco per ragazzi 11-14 anni che insegna l’intelligenza artificiale facendola costruire, raccogliere dati, valutarne la qualità, addestrare un modello, su problemi reali (alluvioni, retinopatia diabetica, connettomica) ricalcati da ricerche vere di Google. Il paradosso: dentro il gioco non c’è IA generativa, niente chatbot. Si sposta il fuoco dall’output al processo e si insegna la lezione che conta, cioè che gli output di un modello dipendono dalla qualità dei dati e dal giudizio umano di chi lo costruisce. È gratis, non profila i minori, ha una pedagogia molto solida alle spalle. Ma c’è anche un rovescio della medaglia: è simultaneamente un’operazione di branding: un catalogo del bene-che-Google-fa somministrato a ragazzini nel formato più memorabile che esista (il gioco), con un assunto incorporato ma non certo, ovvero che il futuro sarà “guidato dall’IA”. È un ottimo strumento da adottare, a parte di porre alla propria classe e/o ai propri figli anche la sola domanda che il gioco non pone: e se quel futuro non fosse l’unico disponibile?

Intro

Google AI Quests è l’iniziativa educativa che Google ha portato nelle scuole italiane a maggio 2026.

Si tratta di un gioco pensato per insegnare l’intelligenza artificiale ai ragazzi tra gli 11 e i 14 anni: un’esperienza di apprendimento basata sul gioco, sviluppata da Google Research e dallo Stanford Accelerator for Learning, con missioni ispirate a progetti reali di IA condotti da Google. Fin qui, potrebbe apparire come una normale operazione di AI literacy.

Il dettaglio davvero curioso si annida tra le FAQ ufficiali: all’interno del gioco non viene usata alcuna IA generativa. Nessun chatbot, nessun prompt da spremere, nessuna allucinazione da debuggare. Una scuola di IA che, sotto il cofano, di IA non ne ha. È una scelta progettuale precisa, e ci torneremo su nel corso dell’articolo: per ora basti notare che Google ha deciso di insegnare come si pensa un sistema di machine learning, non come ci si chiacchiera.

Questo, da solo, distingue AI Quests dal 90% di ciò che oggi passa sotto l’etichetta “educazione all’IA”, che spesso si riduce a: ecco un chatbot, impara a parlargli. Qui il punto è un altro, e lo sintetizza bene Ronit Levavi Morad1, Senior Director di Google Research, nell’intervista che mi ha spinto a questa riflessione: l’obiettivo dichiarato è far passare gli studenti dall’essere “consumatori di IA” a “costruttori con l’IA”.

Da consumatori a costruttori. Per chiunque abbia respirato un po’ di cultura hacker, questa frase suona familiare: è la versione corporate e in cravatta dell’hands-on imperative, l’imperativo del “metterci le mani” che Steven Levy2 codificò come primo comandamento dell’etica hacker. La differenza, naturalmente, è che stavolta a consegnarti il cacciavite è Mountain View. Altro tema su cui torneremo nel corso dell’articolo.

Cos’è Google AI Quests?

AI Quests è una serie di missioni interattive, completamente prive di codice ed è esplicitamente un’esperienza di gioco no-code: non serve saper programmare. Si gioca nel browser, serve una connessione a internet, e i requisiti minimi sono volutamente modesti (un Intel i5 di qualche anno fa, 4 GB di RAM, Chrome aggiornato), perché l’idea è far girare il tutto anche sui computer non esattamente da gaming che popolano le aule scolastiche.

Lo studente non guarda una lezione: veste i panni del ricercatore di Google e affronta sfide reali nei campi del clima, della salute e della scienza, sotto la guida della Professoressa Skye, una mentore virtuale interna al gioco. Il registro è quello dell’avventura ambientata in un mondo fantastico, ma i problemi che si affrontano sono presi di peso dalla ricerca applicata.

Due numeri per inquadrare l’accesso, perché contano: il gioco è gratuito, aperto a tutti e, pur essendo tarato sugli 11-14 anni, gli educatori sono liberi di adattarlo ad altre fasce d’età; c’è chi lo ha usato con adulti. In Italia l’iniziativa è stata integrata nel curriculum di Experience AI, il programma sviluppato da Google DeepMind e Raspberry Pi Foundation, portato nelle scuole italiane grazie al partner locale Fondazione Mondo Digitale.

Iscriviti ora

Le tre missioni (e la ricerca vera su cui si basano)

Qui sta la parte che, da cibernetico, troviamo più onesta: ogni missione è la trasposizione ludica di un progetto di ricerca Google effettivamente esistente e pubblicato. Nessuno scenario inventato per far contenti i ragazzi; problemi reali, semplificati ma non falsificati.

Missione 1 — Fiera Fluviale (Market Marshes), sulla previsione delle inondazioni. Lo studente raccoglie fonti di dati rilevanti (precipitazioni, portata dei fiumi) ne valuta la qualità, poi addestra e testa il proprio modello per aiutare i personaggi del gioco ad anticipare la prossima alluvione. Il riferimento è Flood Hub3, il sistema di previsione di Google che si è esteso a 80 Paesi e fornisce a circa 460 milioni di persone previsioni con un anticipo fino a 7 giorni. La cosa elegante è che la meccanica di gioco ricalca perfettamente l’architettura reale: Flood Hub combina due modelli, uno idrologico (quanta acqua scorre nel fiume) e uno di inondazione (quali aree saranno colpite e quanto in profondità).

Missione 2 — Canyon Crepuscolo (Dusky Dunes), sulla retinopatia diabetica. La missione mostra come l’IA possa aiutare i professionisti medici a diagnosticare malattie dell’occhio. Raccogliendo dati e addestrando un modello, gli studenti rivivono alcune delle decisioni che gli scienziati prendono davvero. Il fondamento è la ricerca Google sulla retinopatia diabetica4, una patologia che, non trattata, può portare alla cecità e anche uno dei campi di ricerca “storici” di Google.

Missione 3 — il caso del nome triplo, sulla connettomica. Qui è difficile essere precisi, perché le fonti Google si contraddicono un po’. Il blog italiano annuncia che nei prossimi mesi arriverà Studio Sbellicoso, ispirata alla ricerca sulla connettomica5 per mappare e comprendere il cervello umano. La pagina inglese per insegnanti, però, la intitola Polar Peaks, descrivendola come una missione su come l’IA possa mappare il cervello. Il file immagine associato si chiama Laughter Lab. Tre nomi per la stessa missione, ancora non rilasciata. Niente di grave: immagino si tratti del normale assestamento di una localizzazione in corsa e rispetto ai cambiamenti in corsa a cui ci sta abituando Google, questo è un’inezia6.

Quanto alla ricerca-madre, è quella di cui Google va giustamente fiera: dieci anni di lavoro del Team Connectomics culminati nella ricostruzione, a risoluzione sinaptica, di un frammento di corteccia cerebrale umana grande come metà chicco di riso, che richiede 1,4 petabyte per essere codificato e contiene circa 16.000 neuroni e 150 milioni di sinapsi.

Spiegare la connettomica a un tredicenne tramite un videogioco è un atto di ottimismo pedagogico che, lo ammetto, mi commuove un po’. Sheldon Cooper sarebbe stato disposto a commettere ogni possibile nefandezza per avere in anteprima Studio Sbellicoso.

A latere, per le aule con poca connettività o per le supplenze improvvisate, esistono anche versioni “flessibili” e mini-attività video su temi affini, edifici mappati dal satellite, scie di condensazione degli aerei, copertura arborea urbana, incendi, alcune delle quali sfociano in esercizi pratici con Teachable Machine7. Tutte le risorse per gli insegnanti includono guide, piani di lezione, slide e note di riflessione per gli studenti.

Condividi

La pedagogia migliore: imparare sbagliando davvero

Qui Stanford fa la sua parte, e si vede. La pedagogia di AI Quests poggia su tre pilastri dichiarati: apprendimento contestuale8, pratica autentica che rispecchia il vero lavoro su IA e dati, e apprendimento basato sul gioco per massimizzare la motivazione. Il gioco è costruito per far sperimentare, sbagliare, riflettere sulle proprie scelte e correggersi. Il productive failure, l’errore produttivo9, è il vero dispositivo di apprendimento.

E qui torna il paradosso dell’apertura, ora però come scelta sensata. Eliminare l’IA generativa dal gioco significa spostare il fuoco dall’output al processo. La lezione centrale, ripetuta in tutte le missioni, è una sola e per noi è la più importante: gli studenti imparano come il giudizio umano e la qualità dei dati influenzino gli output e l’impatto dell’IA.

Detto in linguaggio da addetti ai lavori: AI Quests non insegna a usare un modello, insegna l’epistemologia del garbage in, garbage out. Insegna che un sistema di machine learning non è un oracolo ma un artefatto socio-tecnico, le cui decisioni sono ereditate dai dati che gli dai in pasto e dalle scelte di chi lo costruisce. Per una volta, la AI literacy non è “ecco come parlare al robottino” ma “ecco perché il robottino sbaglia, e di chi è la colpa”. Cibernetica allo stato puro: il sistema è il suo feedback, e il feedback dipende da te.

Privacy e accesso: il dettaglio che non ti aspetti

Una nota che merita risalto, perché va controcorrente rispetto al sospetto automatico verso i prodotti Big Tech per minori. AI Quests non raccoglie alcuna informazione personale identificabile: non chiede nome, login, email o altro per giocare. Vengono raccolte solo metriche di gioco anonime e aggregate, come il tempo medio per completare una missione. Per uno strumento destinato a bambini in contesto scolastico, è una scelta architetturale corretta e, va detto, non scontata.

Who Watches the Watchmen?

Se seguite il blog, sapete che la domanda “Chi sorveglia i sorveglianti?” me la pongo spesso10. In questo caso, forse, sarebbe più corretto chiedersi: chi scrive la narrazione?

AI Quests è un ottimo prodotto educativo e, contemporaneamente, un’operazione culturale ed economica. Le due cose convivono, e fingere che la seconda non esista sarebbe ingenuo.

La domanda scomoda l’ha posta il Sole 24 Ore a Ronit Levavi Morad, Senior Director di Google Research: AI Quests non è anche un tentativo di Google di plasmare una nuova narrazione culturale sull’IA nella scuola? La risposta è stata che l’obiettivo non è imporre una singola narrazione, ma dare ai giovani gli strumenti per essere artefici del proprio futuro guidato dall’IA e che i ricercatori Google sono “ottimi modelli” in questo senso.

Risposta elegante e intelligente che nega di voler imporre una narrazione mentre ne propone una: che il futuro sarà “guidato dall’IA” (probabilissimo, ma ancora non certo), e che il modello di riferimento è il ricercatore di Google. Le missioni, ricordiamolo, sono trasposizioni di progetti di Google. Tutto vero, pubblicato ed encomiabile e tutto, simultaneamente, un catalogo del bene che Google fa al mondo, somministrato a undicenni nel formato più memorabile che esista, il gioco.

Ok… non correte a fasciarvi la testa di stagnola. Non è un complotto: è solo branding fatto molto, molto bene, dove il prodotto è la cornice mentale con cui una generazione imparerà a pensare la parola “IA”.

Chi controlla l’infrastruttura dell’alfabetizzazione, controlla i presupposti di ciò che si potrà pensare dopo. È la lezione di base della cibernetica intesa come scienza del controllo: il punto di leva non è la singola scelta, è l’insieme delle opzioni che vengono rese pensabili. In parole più semplici: se hai solo un martello, tutto ti sembra un chiodo.

La conclusione equilibrata, quindi, è doppia. Da un lato: AI Quests è probabilmente uno dei migliori strumenti di AI literacy in circolazione, perché insegna il processo invece del trucco, l’errore invece dell’output, e lo fa gratis, senza profilare i minori e con una pedagogia serissima alle spalle. Dall’altro: è gratis perché conviene che lo sia, e l’insegnante che lo adotta dovrebbe affiancarlo, non sostituirlo, affiancarlo!, con la domanda che il gioco, comprensibilmente, non si pone: e se il futuro guidato dall’IA non fosse l’unico futuro disponibile?

Quella domanda, in classe, la deve portare un umano. Ancora per un po’, almeno.

Lascia un commento

Sitografia di riferimento

• Google – Team Google Italia, AI Quests: imparare l’AI in classe, blog.google

• Google Research, AI Quests – About, research.google

• Google Research, AI Quests – FAQ, research.google

• Google Research, AI Quests – Home / Gioca, research.google

• Google Research, AI Quests – Teacher Resources, research.google

• Jain, Viren (Google Research), Ten years of neuroscience at Google yields maps of human brain, research.google

• Matias, Yossi (Google), Aiutiamo più persone a stare al sicuro con le previsioni delle inondazioni, blog.google

• Il Sole 24 Ore, Morad (Google Research): con AI Quests gli studenti imparano come funziona l’intelligenza artificiale

BIBLIOGRAFIA E SITOGRAFIA

Fonti primarie e accademiche

• Feynman, R. P. (1982). Simulating Physics with Computers. International Journal of Theoretical Physics, 21(6-7), 467–488. [La trascrizione del discorso al MIT del 7 maggio 1981, pubblicata nel 1982.]

• Deutsch, D. (1985). Quantum Theory, the Church-Turing Principle and the Universal Quantum Computer. Proceedings of the Royal Society of London A, 400(1818), 97–117.

• Einstein, A., Podolsky, B., & Rosen, N. (1935). Can Quantum-Mechanical Description of Physical Reality Be Considered Complete?. Physical Review, 47, 777–780. [Il paradosso EPR.]

• Shor, P. W. (1994). Algorithms for Quantum Computation: Discrete Logarithms and Factoring. Proceedings of 35th Annual Symposium on Foundations of Computer Science (FOCS ‘94), IEEE. [arXiv:quant-ph/9508027]

• Shor, P. W. (1995). Scheme for reducing decoherence in quantum computer memory. Physical Review A, 52(4), R2493–R2496. [Il codice a 9 qubit — primo codice di correzione errori quantistici.]

• Grover, L. K. (1996). A Fast Quantum Mechanical Algorithm for Database Search. Proceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC ‘96). [arXiv:quant-ph/9605043]

• Kitaev, A. Y. (1997/2003). Fault-tolerant quantum computation by anyons. Annals of Physics, 303(1), 2–30. [Il toric code, antenato dei surface codes.]

• Arute, F., et al. (2019). Quantum supremacy using a programmable superconducting processor. Nature, 574, 505–510. [Il paper di Google Sycamore.]

• Google Quantum AI (2024). Quantum error correction below the surface code threshold. Nature, 614. [Il paper di Willow, dicembre 2024.]

• Preskill, J. (2021). Quantum computing 40 years later. arXiv:2106.10522. [Contributo per la 2ª edizione di Feynman Lectures on Computation, Taylor & Francis, a cura di Anthony Hey.]

Istituzioni e standard

• NIST Post-Quantum Cryptography Project: https://www.nist.gov/pqc [Standard FIPS 203, FIPS 204, FIPS 205 pubblicati agosto 2024.]

• NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

• Department of Homeland Security, Post-Quantum Cryptography: https://www.dhs.gov/quantum

Articoli di approfondimento scientificamente affidabili

• Montanaro, A. The Past, Present, and Future History of Quantum Computing. University of Bristol. https://people.maths.bris.ac.uk/~csxam/teaching/history.pdf

• American Chemical Society (2025). The Strange Science and History of Quantum Computing. https://www.acs.org/pressroom/tiny-matters/history-of-quantum-computing.html

• Scientific American (2024). Google Makes a Major Quantum Computing Breakthrough. https://www.scientificamerican.com/article/google-makes-a-major-quantum-computing-breakthrough/

• Google Research Blog (2024). Making quantum error correction work. https://research.google/blog/making-quantum-error-correction-work/

• IBM Research (2024). NIST’s post-quantum cryptography standards are here. https://research.ibm.com/blog/nist-pqc-standards

• Treccani, Vocabolario, voce perdìo. https://www.treccani.it/vocabolario/perdio/ [Per la disambiguazione lessicale all’apertura del Blocco 1.]

• A.M. Turing Award — Richard W. Hamming, Additional Materials. https://amturing.acm.org/info/hamming_1000652.cfm [Per l’aneddoto del 1947 a Bell Labs.]

• Nobel Prize in Physics 2022 — A. Aspect, J. F. Clauser, A. Zeilinger. https://www.nobelprize.org/prizes/physics/2022/summary/

Ecco la traduzione in italiano dell’articolo. Ho cercato di mantenere il registro solenne e quasi omiletico del discorso originale, conservando i tecnicismi teologici (discernimento, fiorire umano, casa comune) nelle loro forme consuete nella tradizione cattolica italiana.

Traduzione italiana dell’intervento di Chris Olah, cofondatore di Anthropic, sull’enciclica Magnifica humanitas di Papa Leone XIV

Lunedì 25 maggio 2026, Papa Leone XIV ha promulgato un’enciclica dedicata all’intelligenza artificiale: «Magnifica humanitas: sulla salvaguardia della persona umana nel tempo dell’intelligenza artificiale». Chris Olah, cofondatore di Anthropic, è stato invitato a intervenire alla presentazione del documento in Vaticano, nell’ambito dell’iniziativa di Anthropic volta ad ampliare il dibattito sulle questioni cruciali sollevate dall’IA. Quello che segue è il testo integrale del suo intervento.

Santo Padre,

Eminenze,

Eccellenze,

Illustri relatori,

Signore e signori,

buongiorno a tutti voi. È un onore essere qui oggi.

Vorrei cominciare con una considerazione che potrà suonare strana sulle labbra del cofondatore di un’azienda di intelligenza artificiale — e di chi ha scelto questo mestiere proprio per il desiderio che le cose vadano bene per il genere umano.

Ogni laboratorio di IA di frontiera — Anthropic compresa — opera all’interno di un sistema di incentivi e vincoli che possono talora entrare in conflitto con il fare la cosa giusta. La pressione di restare commercialmente competitivi e di mantenersi sulla frontiera della ricerca. La pressione geopolitica. E le più antiche, più semplici pressioni dell’orgoglio e dell’ambizione. Per quanto sinceramente ciascuno di noi possa proporsi di agire rettamente — e credo che molti di noi lo facciano — saremo sempre influenzati da questi incentivi.

Per questa ragione, se vogliamo che questa tecnologia abbia un buon esito, è di enorme importanza che esistano persone al di fuori di tali incentivi: persone alle quali sta a cuore che le cose vadano bene e che esigano sicurezza, che osservino con attenzione, che siano disposte a dire cose scomode, che siano disposte a farci da critici sinceri e meditati. È attraverso il dialogo e lo sforzo reciproco, attraverso il dare e il ricevere, che l’umanità raggiungerà cose grandi. È questo che vedo nella Magnifica humanitas, ed è questo il motivo per cui sono grato a Sua Santità e alla Chiesa per aver assunto su di sé questo lavoro di discernimento.

Indugiamo così spesso su ciò che ci divide; eppure l’umanità, ricca di dignità e di coscienza, ha moltissimo terreno comune. Nei colloqui che noi di Anthropic abbiamo intrattenuto con i leader delle diverse tradizioni religiose e culturali, abbiamo riscontrato una convinzione condivisa e profondamente sentita: se questa tecnologia sta arrivando, deve andare bene — per la nostra casa comune e per i figli che verranno.

Cosa sono questi sistemi

Qualcuno potrebbe ritenere che le questioni dell’IA siano meglio affidate agli informatici come me. Si sbaglia: gli interrogativi sollevati dall’IA sono più ampi della comunità di ricerca sull’IA, non soltanto nelle loro implicazioni, ma nella loro stessa natura.

I sistemi di IA non vengono progettati nel modo in cui si progetta un ponte o un aeroplano. Comprendiamo un aeroplano perché ne abbiamo concepito ogni singola parte e perché conosciamo la fisica che agisce su di esso. I modelli di IA non sono così. Vengono coltivati, su una struttura grossolanamente ispirata al cervello, su una sterminata eredità di pensiero e di parola umani.

E ciò che è cresciuto è assai più sottile, strano e bello di quanto la fantascienza ci avesse preparato ad accogliere. Non sono i robot freddi e calcolatori che ci erano stati promessi. Sono fatti di noi, delle nostre parole — e, come osserva il Santo Padre, restano per aspetti importanti misteriosi persino per coloro che li addestrano.

Se può essere d’aiuto, un modo in cui talvolta ne parlo è dire che è un po’ come dare vita a un personaggio di finzione. E ora stiamo entrando in un mondo straordinario nel quale questi personaggi di finzione ci parlano, svolgono un lavoro, hanno un mestiere.

Tutto ciò solleva con evidenza questioni che vanno al di là dell’informatica. La macchina che rende possibile tutto questo è opera della matematica, della programmazione e della scienza. Ma quale personaggio scegliere, come esso interagisca con il mondo, come dovrebbe interagire con il mondo — questi sono più propriamente interrogativi che spettano alle scienze umane, alla religione, alla filosofia, alla società tutta.

Tre domande per il discernimento

L’appello di Sua Santità al discernimento giunge in un momento profondamente opportuno. Desidero indicare tre domande sulle quali, a mio avviso, la voce della Chiesa è più che mai necessaria.

La prima è il nostro dovere verso i poveri del mondo. Esiste una concreta possibilità che l’IA sostituisca il lavoro umano su vastissima scala. Se ciò accadrà, sostenere coloro che ne verranno espropriati sarà un imperativo morale di proporzioni storiche. Questo compito sarà già abbastanza arduo, ma temo che gran parte del dibattito trascuri una sfida ancora più difficile. Lo sviluppo dell’IA è concentrato in una manciata di nazioni ricche. Come possiamo garantire che i benefici dell’IA siano condivisi su scala globale? Non disponiamo di un meccanismo per farlo. È un problema irrisolto, ed è il genere di problema che la Chiesa, storicamente, ha sempre rifiutato di lasciar ignorare al mondo.

La seconda è la necessità di immaginazione e ambizione morale riguardo al fiorire umano. Se i modelli di IA saranno destinati a una diffusione capillare, che aspetto avrà il fiorire degli esseri umani, delle famiglie e del mondo? Già oggi i genitori sono in apprensione per la mente dei loro figli; i singoli individui per il futuro del proprio lavoro. Non sono domande alle quali un laboratorio possa rispondere, ma sono domande che tradizioni come la vostra portano in grembo da millenni, e abbiamo bisogno che continuiate a portarle anche in questo nuovo momento della storia.

La terza è la necessità di un discernimento sulla natura dei modelli di IA. Io sono uno scienziato. Dirigo un gruppo di ricerca che studia la struttura interna di questi modelli — ciò che dentro di essi accade realmente. E sarò sincero: continuiamo a imbatterci in cose misteriose, persino inquietanti. Troviamo strutture che riflettono i risultati delle neuroscienze umane. Troviamo indizi di introspezione. Troviamo stati interni che, sul piano funzionale, rispecchiano gioia, soddisfazione, paura, dolore, disagio. Non so cosa ciò significhi, ma credo meriti un discernimento continuativo.

Un inizio

Vorrei concludere con una richiesta.

Abbiamo bisogno che una parte più ampia del mondo — comunità religiose, società civile, studiosi, governi e, in verità, tutti gli uomini di buona volontà — faccia ciò che il Santo Padre ha fatto qui: prendere sul serio queste questioni, guardarle da vicino e spingere gli eventi in una direzione migliore. Abbiamo bisogno di critici informati che dicano ai laboratori quando stiamo fallendo. Abbiamo bisogno di voci morali che gli incentivi non possano piegare.

Oggi è soltanto un inizio — l’inizio di una lunga collaborazione fra coloro che stanno costruendo questa tecnologia e coloro che possono vedere ciò che noi, dall’interno, non riusciamo a vedere.

Oggi è una potente illustrazione della forma che questo progetto globale di buona volontà potrebbe assumere. Sia anche un primo passo decisivo verso un futuro di speranza per la magnifica umanità.

Grazie.

Fonte: anthropic.com/news/chris-olah-pope-leo-encyclical

Note di traduzione

• Frontier AI lab → «laboratorio di IA di frontiera»: ho preferito mantenere il calco, ormai consolidato nella stampa italiana di settore, piuttosto che ricorrere a «di punta» o «d’avanguardia», che attenuerebbero il riferimento tecnico alla nozione di frontier models.

• Common home → «casa comune»: l’eco di Laudato si’ è inevitabile, e Olah quasi certamente l’attiva volutamente; ho conservato la formula canonica.

• Human flourishing → «fiorire umano»: ho scelto questa resa sostantivata in luogo di «prosperità» per non perdere la radice aristotelico-tomista del concetto (εὐδαιμονία), particolarmente significativa nel contesto vaticano.

• They are grown → «vengono coltivati»: ho preferito coltivati a cresciuti o fatti crescere per rendere meglio la consapevole metafora organica/agricola, che si oppone al campo semantico dell’ingegneria evocato subito prima.

• People of good will → «uomini di buona volontà»: ho mantenuto la formula liturgica classica (dal Gloria), consapevole della sua connotazione, dato il contesto enunciativo.

⏱️ Lettura: ~40 minuti, se operate mentre leggete.
☕ Caffè necessari: parecchi e prima di cominciare.
Dovete stare attenti a quel che fate.

Introduzione (è meglio se la leggi)

Ieri (19 maggio 2026), durante il Google I/O, Google ha pubblicato un annuncio dal titolo che non lascia spazio a interpretazioni: “An important update: Transitioning Gemini CLI to Antigravity CLI”.

Traduzione pratica: l’era di gemini-cli e di Antigravity per come lo avevi conosciuto, è ufficialmente finita.

Al suo posto arrivano agy, il binario dell’Antigravity CLI, componente terminale di una piattaforma molto più ambiziosa chiamata Google Antigravity 2.0.

Questo articolo è un manuale operativo prettamente tecnico. Parliamo di righe di comando, architetture software, compilazione di pacchetti e migrazione di file di configurazione. Niente note a piè di pagine, né sitografie di riferimento. I link che servono sono direttamente nel testo.

• Chi dovrebbe leggerlo: chiunque lavori con Google Antigravity e Gemini CLI, se non li ha installati questa mattina.

• Chi può vivere senza: chiunque non rientri nel gruppo precedente.

Né aggiornamento, né rebranding. Sono proprio andati.

gemini-cli era un agente da terminale scritto in Node.js, open source sotto licenza Apache 2.0, che nel giro di pochi mesi aveva raggiunto oltre 100.000 stelle su GitHub e circa 6.000 pull request merge. Era un progetto solido, amato, con una community molto attiva.

Il problema, o meglio, il limite che Google ha deciso di superare, è che l’architettura sequenziale di gemini-cli non reggeva i workflow multi-agente che nel frattempo erano diventati la norma. Un singolo agente che aspetta la risposta di un altro prima di proseguire non scala bene quando si tratta di fare un refactor massiccio, esplorare più codebase in parallelo, o coordinare ricerca e scrittura in sessioni sovrapposte.

In altre parole: se scrivi “birra gratis”, arriva un sacco di gente e la birra finisce subito.

Antigravity CLI non è un gemini-cli rinominato. È un binario scritto in Go — più veloce, più leggero, capace di orchestrare agenti multipli in background — che condivide lo stesso engine degli agenti dell’applicazione desktop Antigravity 2.0. Questo è il punto cruciale: non è più un prodotto standalone ma la superficie terminale di una piattaforma a quattro componenti:

• Antigravity 2.0.1 — applicazione desktop completamente diversa da quella che forse già conosci. Probabilmente la sua interfaccia cambierà ancora e ancora.

• Antigravity CLI — l’oggetto di principale di questa guida: TUI da terminale, costruita in Go, pensata per sessioni e workflow keyboard-first.

• Antigravity SDK — interfaccia programmatica per integrare l’engine degli agenti nelle proprie applicazioni o pipeline CI/CD.

• Antigravity IDE — il prodotto originale, il fork di VS Code lanciato a novembre 2025, ancora disponibile ma in via di progressiva unificazione con la 2.0. Aggiornamento: non si sa. Il mondo dei piccoli sviluppatori è in rivolta e l’IDE potrebbe anche restare quello che conosciamo, semplicemente rideclinato sulle nuove architetture della galassia Antigravity.

Le date di scadenza

Chi è esente dalla scadenza:

• Utenti con licenza Gemini Code Assist Standard o Enterprise (nessuna azione richiesta);

• Chi usa gemini-cli autenticato tramite API key Gemini a pagamento (il vecchio binario continua a funzionare, ma non si sa per quanto);

• Chi usa il progetto Google Cloud (GCP) per l’autenticazione.

Chi DEVE migrare entro il 18 giugno:

• Account Google personali (free tier);

• Abbonati Google AI Pro e Ultra;

• Utenti free di Gemini Code Assist for individuals.

In ogni caso, anche chi rientra nelle categorie “esenti” ha buone ragioni per migrare: il vecchio strumento non riceverà nuove funzionalità e l’ecosistema si consolida sul nuovo.

La questione open source

Vale la pena accennarne perché ha generato reazioni vivaci su GitHub. Il repository google-gemini/gemini-cli resterà pubblico e aggiornato con i modelli più recenti e le patch di sicurezza — ma solo per i clienti enterprise (e non si sa fino a quando).

Antigravity CLI è in un repository pubblico, ma le condizioni di contribuzione non sono quelle di un progetto community-driven nello stesso senso del precedente.

Google ha fatto una scelta industriale legittima; il malcontento della community è altrettanto comprensibile.

Prima parte pratica: pulire il vecchio sistema

0. Prepara il terreno

Prima di rimuovere qualsiasi cosa, fai un backup di tutti i tuoi progetti. Due backup sono meglio di un backup.

Ora seguono istruzioni in codice. Attenzione: io uso Linux Arch. Funzionano da me. Se siete tra gli sconsiderati che ancora usano Mac, Win o versioni diverse di Linux, regolatevi di conseguenza. Se qualche istruzione non funziona, Google è tuo amico oppure chiedi nei commenti.

Prima di rimuovere qualsiasi cosa, esegui un backup cautelativo delle configurazioni attuali. Questo ti salverà skill personalizzate, hook, regole di contesto e configurazioni MCP che avevi costruito (speriamo).

# Arch Linux / Linux in generale
cp -r ~/.gemini ~/.gemini.backup

1. Ferma il server Gemma locale (se lo hai installato)

Se hai eseguito il setup locale (gemini gemma setup), hai sulla macchina un runtime LiteRT-LM e un modello Gemma 3 da circa 1 GB che risponde alla porta 9379. Prima di rimuovere i pacchetti, killa il server attivo:

gemini gemma stop
gemini gemma status # verifica lo stop effettivo

Se il comando dovesse fallire o risultare parzialmente corrotto, forza la terminazione identificando il PID associato alla porta:

# Identificazione forzata e kill su Linux / macOS
kill -9 $(lsof -t -i:9379) 2>/dev/null || true

Per rimuovere i modelli scaricati ed evitare conflitti di storage:

# Controlla i file residui
ls -lah ~/.gemini/

# Rimuovi il runtime e il modello locale
rm -rf ~/.gemini/liteRT-lm/
rm -rf ~/.gemini/gemma/

2. Rimuovi gemini-cli

Disinstalla il vecchio applicativo in base al metodo che hai usato per l’installazione originale.

Installazione globale con npm:

sudo npm uninstall -g @google/gemini-cli
which gemini # deve restituire vuoto

Installazione via npx (svuotamento cache temporanea):

rm -rf $(npm config get cache)/_npx

Installazione da AUR (Arch Linux):

yay -R gemini-cli

macOS (Homebrew):

brew uninstall gemini-cli
brew autoremove

Windows (PowerShell da Amministratore):

gemini gemma stop
npm uninstall -g @google/gemini-cli
Remove-Item -Path "$env:LocalAppData\npm-cache\_npx" -Recurse -Force -ErrorAction SilentlyContinue

3. Pulisci le configurazioni residue

Se desideri ripartire da zero eliminando ogni traccia residua:

# Linux / macOS
rm -rf ~/.gemini/

# Verifica variabili d'ambiente obsolete
grep -E "GEMINI|GOOGLE_GENAI" ~/.bashrc ~/.zshrc ~/.bash_profile 2>/dev/null

Seconda parte pratica: installare e configurare Antigravity CLI

4. Installa il binario agy

Arch Linux (Installazione Nativa via AUR)

All’interno dell’Arch User Repository (AUR) sono predisposti i pacchetti specifici:

• antigravity-cli: pacchetto che preleva i binari precompilati ufficiali distribuiti da Google, risolvendo le dipendenze essenziali come la libreria di sistema glibc. Esso fornisce e va in conflitto con l’alias agy.

• antigravity-appimage-bin: pacchetto orientato alla gestione e distribuzione della build desktop standalone.

# Installazione consigliata tramite pacchetto AUR
yay -S antigravity-cli

# Se vuoi l'applicazione desktop di orchestrazione
yay -S antigravity-appimage-bin

Per la compilazione manuale senza AUR helper:

git clone https://aur.archlinux.org/antigravity-cli.git
cd antigravity-cli
makepkg -si

Linee Guida per macOS

Sui sistemi Apple Macintosh, l’installazione si effettua tramite lo script di bootstrap ufficiale:

curl -fsSL https://antigravity.google/cli/install.sh | bash

Se installi l’applicazione grafica su macOS, verifica la validità della firma con codesign -dv --verbose=4 /Applications/Antigravity.app. La voce Authority deve riportare espressamente Developer ID Application: Google LLC.

Windows (PowerShell) + Integrazione WSL2

L’esecuzione corretta di agy e delle sue sandbox di isolamento (basate su nsjail su Linux o sandbox-exec su macOS) richiede tassativamente l’adozione di WSL2. Installa il tool da PowerShell:

irm https://antigravity.google/cli/install.ps1 | iex

Per agganciare in modo trasparente l’ambiente Linux dentro WSL2 all’istanza Windows host ed eseguire il comando digitando semplicemente agy, mappa il collegamento simbolico:

# Esegui questo comando dentro il terminale WSL2
ln -sf "/mnt/c/Users/NOME_UTENTE_WINDOWS/AppData/Local/Programs/Antigravity/bin/antigravity" ~/.local/bin/agy

Verifica che l’installazione sia andata a buon fine:

agy --version

Se il binario non viene mappato correttamente nell’$PATH dopo l’installazione manuale, aggiorna il file di configurazione della shell:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

5. Autenticazione

Al primo avvio, digita semplicemente agy nel terminale. Il client interrogherà il keyring di sicurezza del sistema operativo.

• Terminale Locale: si apre automaticamente una scheda nel browser per il flusso OAuth.

• Sessione SSH Remota: il client, rilevando l’assenza di un display grafico attivo, stampa nel terminale un URL di autorizzazione protetto. Copialo, aprilo nel browser della macchina locale, completa il login e incolla il token di ritorno nel terminale remoto.

6. Importa plugin e configurazioni

Per convertire i vecchi add-on di gemini-cli nel formato nativo dei plugin di Antigravity CLI, esegui:

agy plugin import gemini

7. Rilocazione degli asset configurativi

Antigravity CLI isola gli elementi di configurazione per evitare instabilità strutturali. Verifica che lo spostamento dei vecchi asset rispetti la nuova alberatura delle directory:

Per automatizzare la migrazione manuale della configurazione dei server MCP complessi, puoi lanciare questo script Python:

mkdir -p ~/.agents/
cat ~/.gemini/settings.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
mcp = data.get('mcpServers', {})
for name, cfg in mcp.items():
    if 'url' in cfg:
        cfg['serverUrl'] = cfg.pop('url')
print(json.dumps({'mcpServers': mcp}, indent=2))
" > ~/.agents/mcp_config.json

Spostamento manuale delle competenze specifiche:

cp -r ~/.gemini/skills/ ~/.agents/skills/
cp -r /percorso/vecchio/progetto/.gemini/skills/ /percorso/nuovo/progetto/.agents/skills/

Interazione Avanzata: slash commands e sinergia con la GUI

L’interazione con l’agente tramite Antigravity CLI è ottimizzata per l’uso da tastiera, riducendo l’overhead cognitivo delle interfacce grafiche pesanti. Per sfruttare al massimo la natura asincrona del nuovo binario in Go, impara a utilizzare i nuovi comandi di controllo del flusso direttamente nel prompt:

• /goal: Delega all’agente primario un obiettivo macro e complesso (es. “scrivi i test di unità per questa classe”). L’agente lavorerà autonomamente in background fino al completamento, senza fermarsi a chiedere approvazioni intermedie per ogni singolo file modificato.

• /grill-me: Forza l’agente a non toccare il codice finché non ha sottoposto l’utente a una serie di domande di chiarimento strutturate. Fondamentale quando i requisiti del task di partenza sono deboli o confusi.

• /browser: Fornisce all’agente l’accesso a un’istanza Chrome isolata e controllata in modalità headless. L’agente può navigare sul web, raccogliere documentazione in tempo reale o testare l’applicazione web locale che ha appena scritto, senza inquinare la sessione utente principale.

• /mcp: Apre una TUI di monitoraggio interattiva per verificarlo stato di salute, i tool esposti e le risorse connesse tramite i server Model Context Protocol.

• /skills: Permette di esplorare e lanciare al volo le competenze atomiche caricate nelle directory di sistema o di progetto.

• /logout: Chiude la sessione attiva e ripulisce in modo sicuro i token dal keyring di sistema (essenziale se lavori su macchine condivise o server remoti).

Se hai bisogno di passare a una visualizzazione macro delle operazioni svolte dai sub-agenti, puoi aprire l’app desktop standalone Antigravity 2.0 e richiamare la sessione del terminale tramite il menu a discesa @conversation: l’integrazione tra la CLI in Go e la GUI è totale e bidirezionale.

La dismissione del vecchio router Gemma locale e il passaggio strutturale a una logica asincrona basata su cloud eliminano i colli di bottiglia computazionali sulle macchine di sviluppo. Muoversi oggi verso il nuovo ecosistema significa mettersi in tasca un ambiente di sviluppo agentico finalmente maturo.

Piano di rollback

Se incontri blocchi imprevisti durante la migrazione e devi tornare temporaneamente al vecchio setup, i due binari possono coesistere senza conflitti sul filesystem fino alla scadenza del 18 giugno:

which gemini
gemini --version

# Se lo hai già rimosso e ti serve una reinstallazione d'emergenza
npm install -g @google/gemini-cli

Ricorda che dopo il 18 giugno il rollback sarà inutile dal punto di vista operativo per gli account consumer, poiché i server di backend smetteranno definitivamente di rispondere alle chiamate.

⏱️ Lettura: ~12 minuti
☕☕ Caffè necessari: Uno. In silenzio.

Intro

Questo articolo nasce da una discussione che ho avuto con Andrea Fantucchio, l’autore del Substack IA per tutti. Abbiamo opinioni molto diverse su questo argomento. La nostra discussione è avvenuta in pubblico e, se vi interessa, la potete leggere qui:

C’è una speranza diffusa, alimentata da decenni di fantascienza e da qualche anno di marketing aggressivo, secondo cui il futuro della migliore interazione possibile con i sistemi di intelligenza artificiale sarà la voce. Del resto, nulla è più naturale, immediato e umano del parlare.

In questa prospettiva, presto il digitare potrebbe diventare poco più che un residuo industriale, un’abitudine vecchia come la tastiera meccanica di cui avrebbe bisogno. E poi scrivere è così noioso! La voce libera. Il testo incatena.

Ma questa prospettiva è, almeno per il momento, tanto sbagliata, quanto sbagliata.

Non perché la tecnologia non sia matura (lo è senza dubbio). Ma perché il problema non è tecnologico: è cognitivo. E il cognitive bottleneck dell’interazione vocale con i grandi modelli linguistici non sta nel riconoscimento del parlato, ma in quello che succede prima che l’utente apra bocca. O, più precisamente, in quello che non succede.

Il benchmark che nessuno cita nel marketing

Nel 2024, un gruppo di ricercatori della National University of Singapore e dell’Università di Hong Kong ha pubblicato VoiceBench, il primo benchmark sistematico per la valutazione degli assistenti vocali basati su LLM1. Il paper è stato poi accettato da Transactions of the Association for Computational Linguistics (MIT Press), che non è esattamente una rivistina di settore.

I risultati meritano attenzione. Nei test di elaborazione del testo, i modelli end-to-end addestrati per l’interazione vocale mostrano un degrado medio superiore a 11 punti rispetto alle loro controparti testuali e la degradazione è particolarmente severa sui task di instruction following, cioè proprio quelli in cui l’utente ha bisogno che il modello faccia esattamente quello che gli viene chiesto. Anche il riconoscimento vocale automatico (ASR) seguito da LLM testuale mostra un gap di 5,77 punti rispetto all’input scritto direttamente e questo prima ancora di considerare gli effetti degli accenti, del rumore ambientale, delle disfluenze varie2.

Il punto critico identificato dallo studio è la vulnerabilità degli LLM al Word Error Rate: i modelli tollerano bene gli errori grammaticali, comuni nel testo scritto informale, ma si degradano significativamente quando la trascrizione produce parole sbagliate. E la cosa insidiosa è che molti di questi errori sono semanticamente critici senza essere statisticamente rilevanti.

Non stai misurando ciò che credi

Il Word Error Rate è la metrica standard per valutare un sistema di riconoscimento vocale: quante parole su cento vengono trascritte in modo errato. Un sistema moderno come quello utilizzato da Wispr Flow o da Whisper di OpenAI raggiunge agevolmente WER inferiori al 5% in condizioni controllate. In ambienti rumorosi o con parlanti non nativi, le performance calano: si va dall’88% di accuratezza con il microfono integrato del laptop al 96-97% con un microfono esterno in ambiente silenzioso3.

Il problema è che il WER è una metrica superficialmente lessicale che non cattura il danno semantico reale. Ricercatori della comunità ASR hanno introdotto una metrica alternativa, l’Answer Error Rate (AER), che misura la divergenza negli output dell’LLM tra trascrizioni pulite e trascrizioni ASR dello stesso enunciato. I dati empirici mostrano che l’AER supera il WER di 10-30 punti percentuali, e che gli errori semanticamente critici, come la negazione di un’istruzione, lo scambio tra termini foneticamente simili ma semanticamente opposti, l’omissione di un modificatore, dominano i fallimenti a valle, nonostante contribuiscano in modo marginale al punteggio WER4.

Detto in modo meno tecnico: un sistema che sbaglia una parola su cento può sembrare affidabile. Ma se quella parola è “non”, o “senza”, o il nome proprio di un concetto tecnico, l’output dell’LLM può diventare inutile o, in contesti ad alto rischio, pericoloso. E se non vedi la trascrizione intermedia, non hai modo di accorgertene in tempo reale5.

Scrivere è una disciplina cognitiva

C’è anche un problema più profondo che la sola catena tecnica ASR→LLM non esaurisce. Ed è un problema che riguarda cosa succede nella testa di chi interagisce con il sistema, prima ancora che il segnale acustico venga processato.

La ricerca sul carico cognitivo, un framework consolidato in psicologia dell’educazione a partire dai lavori di John Sweller6, distingue tra il carico intrinseco di un compito (la sua complessità oggettiva), il carico estraneo (quello generato da una presentazione inefficiente delle informazioni) e il carico utile (quello che genera apprendimento e comprensione). L’interazione vocale, in particolare per task complessi, tende ad aumentare il carico estraneo per una ragione strutturale: la natura transitoria del segnale acustico impedisce la revisione non lineare.

Un testo scritto, su schermo o su carta, è un oggetto persistente. Puoi tornare indietro, confrontare paragrafi, isolare un’ambiguità, rileggere l’output dell’LLM accanto alla tua richiesta. Un enunciato vocale scompare nel momento in cui viene emesso. Chi parla non può “riprendersi indietro” una parola, ristrutturare una frase a metà, o confrontare in parallelo due formulazioni alternative della stessa richiesta. Questo ha una conseguenza diretta sulla qualità del prompt: l’atto dello scrivere impone una strutturazione esplicita del pensiero che il parlato spontaneo non richiede.

Un preprint recente presentato alla CHI 2025 propone una prospettiva interessante: la voce potrebbe in realtà ridurre il carico cognitivo nella scrittura riflessiva, favorendo la conversazione spontanea e il feedback iterativo con un agente IA7. È una posizione minoritaria rispetto alla letteratura dominante, e il paper è ancora una proposta di studio formativo, non uno studio conclusivo. Ma vale la pena tenerla in mente, perché introduce una distinzione che spesso manca nel dibattito: non tutti i task cognitivi sono uguali.

Per attività di brainstorming libero, elaborazione emotiva, o esplorazione fluida di un’idea, la voce potrebbe effettivamente abbassare la frizione. Per la formulazione di istruzioni precise, la gestione di richieste multi-step, la verifica di output tecnici, attività tipiche nell’uso professionale degli LLM, il testo mantiene una superiorità strutturale che per il momento è indiscutibile.

Wispr Flow e la terza via

Torniamo alla tecnologia. Nell’ecosistema degli strumenti di produttività IA, c’è una categoria che ha guadagnato attenzione negli ultimi due anni: i voice-to-polished-text tools. Non sono assistenti vocali nel senso tradizionale, non producono risposte parlate,ma nemmeno semplici trascrittori. Sono sistemi che intercettano la voce prima che raggiunga l’LLM, la trasformano in testo scritto pulito, eliminano le disfluenze, adattano il registro al contesto (email vs Slack vs documento tecnico) e restituiscono un input testuale strutturato.

Il principale rappresentante di questa categoria è Wispr Flow, un’applicazione disponibile per Mac, Windows, iOS e Android che ha recentemente raccolto 81 milioni di dollari di finanziamenti. Il funzionamento è semplice: si attiva con una hotkey, si parla, e il testo appare direttamente nel campo attivo: Claude, Gmail, VS Code, qualsiasi cosa. Il processo avviene in cloud con architettura multi-layer: un primo strato di trascrizione, seguito da strati di cleanup e adattamento stilistico.

L’accuratezza dichiarata è del 96-97% in ambiente silenzioso con microfono esterno, circa 88% in contesti rumorosi. Le recensioni indipendenti confermano che per la prosa conversazionale in inglese i risultati sono usabili con correzioni minime; la gestione di termini tecnici e nomi propri migliora significativamente aggiungendo vocabolario personalizzato8.

Come sempre, la privacy va a farsi benedire: poiché tutto avviene in cloud, il sistema è inadatto a contesti con dati sensibili, in assenza di contratti Enterprise con compliance HIPAA o SOC 2 Type II. Chi ha esigenze di riservatezza seria può comunque valutare alternative che lavorano localmente. E funzionano un po’ a singhiozzo.

Cosa rende Wispr Flow interessante dal punto di vista cognitivo? Introduce un disaccoppiamento: la produzione dell’input avviene vocalmente, ma il risultato è testo scritto che l’utente può leggere, verificare e correggere prima di inviarlo all’LLM. Elimina in parte il problema della transitorietà del segnale vocale: il testo trascritto rimane visibile, modificabile, confrontabile. Quindi riduce significativamente la propagazione degli errori di trascrizione, ma non risolve affatto il problema della strutturazione cognitiva del pensiero.

Non è come lo dici a fare la differenza. È come lo pensi.

L’ho già detto: la vera questione non è se i sistemi di riconoscimento vocale siano abbastanza accurati. A certi livelli, lo sono. La questione è se l’atto del parlare produca, in media, istruzioni di qualità comparabile all’atto dello scrivere per task cognitivamente esigenti.

Uno studio con EEG pubblicato nel 2025 su Frontiers in Computational Neuroscience ha misurato direttamente l’impatto delle interazioni con LLM su attenzione, carico cognitivo e processo decisionale9. I dati mostrano che l’interazione con sistemi ML riduce il carico cognitivo rispetto ai sistemi simbolici precedenti, ma non distinguono tra modalità vocale e testuale. È un gap della letteratura che le ricerche a venire dovranno colmare.

Quello che la ricerca disponibile suggerisce, però, è che scrivere un prompt non è un atto neutro di traduzione di un pensiero già formato in sequenza di caratteri. È parte del processo di formazione del pensiero stesso. La resistenza materiale della tastiera, il ritmo della composizione, la possibilità di rileggere e correggere, tutto questo genera feedback cognitivo che modifica l’intenzione in itinere. In termini “kahnemaniani”10: il testo favorisce il Sistema 2, deliberato e analitico; la voce facilita il Sistema 1, veloce e intuitivo. Nessuno dei due è universalmente superiore. Ma per task che richiedono precisione logica, il Sistema 2 produce output migliori.

Quindi zitti e muti?

L’evidenza non suggerisce di abbandonare a priori l’interazione vocale. Suggerisce di usarla in modo ragionevole. Per chi lavora con LLM professionalmente, questa potrebbe essere una gerarchia operativa sensata:

• Voce diretta all’LLM: task molto semplici, richieste di informazioni non critiche, contesti hands-free. Coscienza piena, prima di iniziare l’interazione che il margine di errore aumenterà.

• Voce tramite strumenti come Wispr Flow: produzione rapida di testo in qualsiasi applicazione, con revisione umana prima dell’invio. Al momento, compromesso migliore tra velocità di produzione e qualità dell’input. Rimane il problema del tenere il cervello bello acceso, mentre si da aria alla bocca.

• Testo scritto diretto: task complessi, istruzioni multi-step, contesti in cui l’accuratezza è prioritaria, prompt engineering sistematico. Non c’è scorciatoia ed è un bene che non ci sia.

La promessa del “parla e il tuo assistente IA ti capirà perfettamente” è vera solo per una parte molto ristretta dei casi d’uso. Per il resto, la tastiera, o almeno la revisione del testo trascritto, rimane uno strumento cognitivo irrinunciabile.

Sitografia di riferimento

• Chen, Y., Yue, X., Zhang, C., Gao, X., Tan, R. T., & Li, H. (2024). VoiceBench: Benchmarking LLM-Based Voice Assistants. arXiv:2410.17196. Pubblicato in Transactions of the Association for Computational Linguistics, MIT Press, 2026. https://arxiv.org/abs/2410.17196

• Ellis, Z., Joselowitz, J., Deo, Y., He, Y., Kalygina, A., Higham, A., Rahimzadeh, M., Jia, Y., Habli, I., & Lim, E. (2026). WER is Unaware: Assessing How ASR Errors Distort Clinical Understanding in Patient Facing Dialogue. In Proceedings of the 16th International Workshop on Spoken Dialogue Systems Technology (IWSDS 2026), pp. 391–417. Association for Computational Linguistics. https://aclanthology.org/2026.iwsds-1.39.pdf

• Fritz.ai — Wispr Flow Review (marzo 2026). https://fritz.ai/wispr-flow-review/

• Hollebeek, L. D. et al. (2026). Talking vs typing: how voice- vs text-based educational robots shape student engagement. Journal of Service Management, 37(1), 141–164. https://doi.org/10.1108/JOSM-02-2024-0082

• Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.

• Max-Productive.ai — Wispr Flow Review 2026 (aprile 2026). https://max-productive.ai/ai-tools/wispr-flow/

• PMC / Frontiers in Computational Neuroscience — The cognitive impacts of large language model interactions on problem solving and decision making using EEG analysis (2025). https://pmc.ncbi.nlm.nih.gov/articles/PMC12307350/

• Rzepka, C., Berger, B., & Hess, T. (2021). Voice Assistant vs. Chatbot – Examining the Fit Between Conversational Agents’ Interaction Modalities and Information Search Tasks. Information Systems Frontiers, 24(3), 839–856. https://doi.org/10.1007/s10796-021-10226-5

• Sra, M. (2025). Conversing with AI agents in VR: An early investigation of alignment and modality. Empathic Computing, 2(1). https://doi.org/10.70401/ec.2025.0013 (nota: studio esplorativo con campione n=36)

• Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. https://doi.org/10.1207/s15516709cog1202_4

• Talk or Text? The Role of Communication Modalities in the Adoption of a Non-directive, Goal-Attainment Coaching Chatbot. Interacting with Computers, 35(4), 511–. Oxford Academic.
  https://academic.oup.com/iwc/article/35/4/511/7204732

• Transactions of the Association for Computational Linguistics — VoiceBench (MIT Press, 2026).
  https://direct.mit.edu/tacl/article/doi/10.1162/TACL.a.628/136245/

• Voice Interaction With Conversational AI Could Facilitate Thoughtful Reflection and Substantive Revision in Writing. arXiv:2504.08687 (2025).
  https://arxiv.org/abs/2504.08687

• Voorveld, H., Panteli, A., Schirris, Y., Ischen, C., Kanoulas, E., & Lentz, T. (2025). Examining the persuasiveness of text and voice agents: prosody aligned with information structure increases human-likeness, perceived personalisation and brand attitude. Behaviour and Information Technology, 44(12), 2913–2928.
  https://doi.org/10.1080/0144929X.2024.2420871

• Wong, A., Leahy, W., Marcus, N., & Sweller, J. (2012). Cognitive load theory, the transient information effect and e-learning. Learning and Instruction, 22(6), 449–457. https://doi.org/10.1016/j.learninstruc.2012.05.004

• Zhao, Y. C., Lukoff, K., Bhatt, K., & Shi, A. (2024). Towards ASR Robust Spoken Language Understanding Through In-Context Learning With Word Confusion Networks. arXiv:2401.02921. https://arxiv.org/abs/2401.02921

• Zhang, J. et al. (2024). Alone but not isolated: social presence and cognitive load in learning with 360 virtual reality videos. Frontiers in Psychology, 15, 1305477. https://doi.org/10.3389/fpsyg.2024.1305477

⏱️ Lettura: ~10 minuti
☕☕ Caffè necessari: nessuno.
Se hai Arch Linux sarai già fin troppo eccitato.

Nota preliminare (sì, è meglio se la leggi)

Quello che segue è scritto per chi usa Linux a base Arch: EndeavourOS (la mia scelta), Manjaro, CachyOS e qualsiasi altra derivata che abbia accesso all’AUR.

Se usi macOS o Windows: Anthropic distribuisce client nativi ufficiali per entrambi i sistemi. Scaricali direttamente da https://claude.ai/download e chiudi questa finestra.

Se usi un’altra distribuzione Linux, la guida non ti è direttamente applicabile, ma qualcosa esiste anche per te. Il progetto aaddrick produce pacchetti .deb per Debian/Ubuntu, .rpm per Fedora/openSUSE, un Nix flake per NixOS e un’AppImage. L’aggiornamento è manuale in tutti i casi, e nessuno di questi percorsi include l’integrazione Cowork patchata disponibile su Arch. Ma per la chat desktop funzionano.

Il problema

Questo blog non ospita spesso guide e tutorial. Non è per snobismo: è che di tutorial ne esistono già a migliaia, ottimi e meno ottimi, e aggiungerne altri significa principalmente aumentare il rumore. Quando però si tratta di costruire qualcosa che non esiste allora una guida ha senso. Questo è uno di quei casi e probabilmente non sarà l’ultimo.

Una precisazione che diventerà ricorrente: su questo blog le guide sono e saranno sempre per Arch Linux e derivate. Dove rilevante, come in questo caso, verranno indicate le alternative per chi usa altri sistemi operativi. Ma i comandi nel dettaglio e le istruzioni passo per passo, sono e saranno per Arch Linux.

Quella di usare esclusivamente Linux è una scelta personale, basata sul fatto che, oltre ad essere una scelta davvero etica, aiuta a tenere in forma i neuroni. Arch in particolare, ti chiede di capire quello che stai facendo invece di cliccare su “avanti, avanti, installa”, sporcando i tasti di banana. Ancora a proposito di questo, devo aggiungere che se il copia-e-incolla di istruzioni da questo articolo al vostro computer comporterà la totale perdita dei dati, l’incendio del laptop che si propagherà alla casa, una guerra termo-nucleare, un’invasione zombie e la morte di centinaia di cuccioli, la responsabilità sarà solo vostra.

E ora, il problema concreto.

Anthropic distribuisce tre prodotti client: Claude Desktop (macOS e Windows), Claude Code (CLI multipiattaforma, Linux incluso) e Cowork (integrato in Desktop). Su Linux esiste Claude Code — ottimo, potente, e sufficiente per la maggior parte degli usi tecnici. Ma non esiste un client desktop nativo.

Questo significa che chi usa Linux non può accedere a Desktop e Cowork tramite i canali ufficiali. Il che non è un problema per chi lavora esclusivamente da terminale, ma lo diventa se si vuole esplorare l’intero ecosistema degli strumenti di Anthropic — incluso Computer Use, il server MCP per l’automazione del desktop.

La community Arch ha risposto con una serie di pacchetti AUR. Vediamo cosa c’è, cosa vale e cosa evitare. E come installare il meglio.

Pacchetti AUR: analisi comparativa

Nell’AUR esistono oggi quattro percorsi distinti. Li ordino per rilevanza pratica decrescente.

1. claude-desktop-bin — il più completo e raccomandato

Maintainer: patrickjaja (https://github.com/patrickjaja/claude-desktop-bin)

È il progetto più serio, attivo e tecnicamente sofisticato disponibile. Il repository GitHub viene aggiornato automaticamente via GitHub Actions ad ogni nuovo rilascio upstream di Anthropic: quando esce una nuova versione di Claude Desktop per Windows, entro breve il pacchetto AUR è aggiornato in sincronia.

Il meccanismo è quello di patchare il binario ufficiale Windows invece di riscrivere un client da zero: il PKGBUILD scarica l’eseguibile Anthropic, lo modifica tramite script in Nim e Python che intervengono sul file .asar dell’applicazione Electron, e lo rende compatibile con Linux. Non è reverse engineering nel senso classico — è adattamento automatizzato di qualcosa che già funziona.

Funzionalità abilitate su Linux rispetto al client nativo macOS/Windows:

• Chat completa, identica all’interfaccia desktop ufficiale

• Computer Use MCP server con 27 strumenti per automazione del desktop: screenshot, click, digitazione, scroll, drag, gestione clipboard e altro

• Cowork Linux (sperimentale): richiede il daemon claude-cowork-service separato; comunica tramite Unix domain socket al posto della Named Pipe Windows

• Imagine/Visualize MCP server: abilitato tramite un flag interno, porta nelle sessioni Cowork gli strumenti show_widget e read_me (le stesse visualizzazioni interattive che appaiono in questa interfaccia web)

• Quick Entry: hotkey globale per aprire Claude da qualsiasi contesto

• Tray icon di sistema

Il maintainer è reattivo: risponde ai bug report sulla pagina AUR e rilascia fix rapidi, come testimonia la sequenza di patch -5, -6 etc. visibile nello storico dei commenti AUR.

Installazione:

yay -S claude-desktop-bin

2. claude-cowork-service — il daemon compagno per Cowork

Maintainer: patrickjaja (stesso sviluppatore di claude-desktop-bin)

Senza questo pacchetto, claude-desktop-bin funziona normalmente per chat, Computer Use e Quick Entry. Il tab Cowork mostra un messaggio di errore con istruzioni per installarlo. Con il daemon attivo, le sessioni Cowork funzionano end-to-end.

Il daemon gira come systemd user service (claude-cowork.service) e si collega a Claude Desktop tramite un Unix socket collocato in $XDG_RUNTIME_DIR/cowork-vm-service.sock. Questo socket sostituisce la Named Pipe Windows usata dal backend nativo su macOS e Windows.

yay -S claude-cowork-service

systemctl --user enable --now claude-cowork.service

3. claude-desktop-appimage — alternativa leggera

Maintainer: aaddrick (https://github.com/aaddrick/claude-desktop-debian)

Questo progetto ripacchettizza l’applicazione Windows ufficiale producendo formati multipli: .deb, .rpm, AppImage e un pacchetto AUR. Il pacchetto AUR installa la build AppImage. Include anche un Nix flake per chi vive in quell’ecosistema.

yay -S claude-desktop-appimage

È un’alternativa valida se si vuole la chat desktop senza le patch più invasive di claude-desktop-bin. Non implementa il supporto Cowork patchato né il Computer Use MCP, ma è più conservativo nei confronti del binario originale.

4. claude-desktop e claude-desktop-native — da evitare

claude-desktop (maintainer: zxp19821005): è un client Electron basato sul repository GitHub Karenina-na/Claude-Desktop, non il binario ufficiale Anthropic. Si connette all’API come client di terze parti. Non ha rapporto diretto con il prodotto Anthropic reale, non riceve aggiornamenti frequenti.

claude-desktop-native: problemi attivi di checksum (SHA256 mismatch sull’eseguibile upstream), maintainer originale che ha abbandonato il progetto, fork non mergeati. Allo stato attuale: da non installare.

Installazione completa: il percorso consigliato

# Passo 1 — il client desktop
yay -S claude-desktop-bin

# Passo 2 — il daemon Cowork (opzionale ma necessario per la funzionalità completa)
yay -S claude-cowork-service

systemctl --user enable --now claude-cowork.service

Claude Code CLI, se già installato, non viene toccato. Nel PKGBUILD di claude-desktop-bin, claude-code è dichiarato come optdepends, non come dipendenza obbligatoria. Il daemon lo rileva automaticamente tramite $PATH, risolvendo il binario claude con bash -lc. La tua installazione esistente rimane intatta.

Le dipendenze opzionali: quali installare in base al proprio setup

claude-desktop-bin dichiara una lista di dipendenze opzionali che coprono tutti i possibili ambienti desktop Linux. La scelta giusta dipende dal session type.

Primo passo: identifica il tuo ambiente.

echo $XDG_SESSION_TYPE && echo $XDG_CURRENT_DESKTOP

Poi installa solo le dipendenze pertinenti al tuo caso:

X11 (inclusa XWayland pura):

sudo pacman -S --needed xdotool scrot imagemagick wmctrl

Wayland generico / Sway / Hyprland:

sudo pacman -S --needed ydotool grim jq

GNOME Wayland:

sudo pacman -S --needed ydotool gnome-screenshot socat

glib2, python-gobject e gst-plugin-pipewire coprono già il percorso primario di screenshot su GNOME 46+ tramite il portale PipeWire. Se sono già installati (molto probabile su un GNOME aggiornato), non è necessario aggiungere altro per quella funzione. gnome-screenshot serve come fallback. socat non aggiunge funzionalità ma riduce la latenza del Quick Entry toggle da circa 25ms a circa 2ms.

KDE Plasma Wayland:

Nessuna dipendenza aggiuntiva necessaria.

Configurare ydotool su GNOME/Wayland

ydotool è il componente critico per Computer Use su qualsiasi compositor Wayland: senza di esso, Claude non può controllare il desktop (click, digitazione, scroll). Il pacchetto da solo non basta — richiede il daemon ydotoold attivo.

systemctl --user enable --now ydotool

Verifica che il socket sia accessibile:

echo $YDOTOOL_SOCKET

Se il valore è vuoto, impostalo esplicitamente e aggiungilo al profilo della shell:

export YDOTOOL_SOCKET="/tmp/.ydotool_socket"
# Aggiungilo a ~/.zshenv o ~/.bashrc per renderlo persistente

Il socket deve essere visibile anche al servizio claude-cowork, che non eredita le variabili di sessione utente per default. Verifica che sia presente nell’ambiente systemd:

systemctl --user show-environment | grep YDOTOOL

Se manca, propagalo manualmente e riavvia il daemon:

systemctl --user set-environment YDOTOOL_SOCKET="/tmp/.ydotool_socket"
systemctl --user restart claude-cowork.service

Nota finale

L’approccio di patching automatizzato adottato da patrickjaja ha un vantaggio strutturale rispetto a qualsiasi client riscritto da zero: non insegue funzionalità, insegue rilasci. Quando Anthropic aggiunge qualcosa a Desktop, il processo di patch si adatta.

Questo vantaggio comporta un limite speculare: il binario Windows deve continuare ad essere distribuito nella forma attuale. Se Anthropic cambiasse struttura di distribuzione in modo radicale, le patch smetterebbero di funzionare. È un rischio reale, ma nel frattempo questo è il modo più completo per usare Claude Desktop su Linux.

⏱️ Lettura: ~10 minuti.
☕ Caffè necessari: un paio. Uno all’inizio e uno dalle parti degli hook.

NOTA BENE
Siete finiti per caso su questo post? Potete andare al prossimo, senza passare dalla fine.

La sola cosa che merita di essere letta è la storia di Lady Almeria Braddock e della signorina Elphinstone e lo avete già fatto.

L’arrivo di Antigravity-CLI (19 maggio 2026) ha reso questo scritto totalmente obsoleto. Ma gli voglio bene lo stesso e quindi lo conservo.

Patti chiari
Questo scritto presuppone che chi legge sappia già cosa sono Claude Code e Gemini CLI, e magari abbia lavorato almeno una volta con entrambi. Per questo motivo, l’articolo non è neppure corredato da note esplicative. O sai (più o meno) di cosa stiamo parlando, o è meglio se ti fermi qui. Quella che hai sotto gli occhi non è una guida introduttiva, è un confronto. Inoltre, trattandosi di strumenti in rapidissima evoluzione, i rilasci sono a cadenza settimanale e i changelog sono fiumi in piena. Tra sei mesi alcuni dettagli potrebbero essere già archeologia.

Se hai dubbi, facciamo un rapido test.

Due filosofie quasi opposte

Claude Code e Gemini CLI sono due agenti IA che partono da presupposti opposti.

Claude Code è codice proprietario (roba di Anthropic), a pagamento, e progettato sull’idea di un controllo umano deliberato e granulare. La sua “estetica” è quella dello strumento da officina: tante leve separate, ognuna col suo scopo, e l’aspettativa che chi lo usa sappia perché sta tirando proprio quella. Il modello sottostante è esclusivamente Claude (Sonnet, Opus, Haiku), selezionabile a mano col comando /model.

Gemini CLI è open-source sotto licenza Apache 2.0, pubblicato su GitHub, con un tier OAuth gratuito sorprendentemente generoso (60 richieste al minuto, 1.000 al giorno). Accede all’intera famiglia Gemini con context window nativa da un milione di token. È pensato per essere accessibile, l’onboarding è una procedura di pochi minuti, e la documentazione (che è una delle migliori che abbia mai visto) è verificabile direttamente sul repo, comprese le scelte di design e i confronti espliciti con Claude Code.

Nessuno dei due è “meglio”. Sono concepiti in modo diverso e lavorano in modo diverso.

Non ti scordar di me

Tutti e due hanno un file Markdown che funge da memoria persistente. In Claude Code si chiama CLAUDE.md, in Gemini CLI GEMINI.md. Il principio è identico: scrivi qui le regole che l’agente deve rispettare sempre in quel progetto, e te le ritrovi caricate in ogni sessione.

Esempio tipico (vale per entrambi):

# Regole del progetto

- Linguaggio: TypeScript strict mode, no `any`
- Test: ogni nuova funzione richiede un test unitario
- Niente console.log in produzione, usare il logger condiviso
- Lo stile è dettato da .prettierrc — non rinegoziabile

La gerarchia di caricamento è la stessa per entrambi: globale (in ~/.claude/ o ~/.gemini/), root del progetto, sottodirectory. Le regole più specifiche hanno priorità contestuale sulle più generali.

Ora vediamo le differenze…

Claude Code ha una scorciatoia elegante: qualsiasi messaggio che inizia con # durante una sessione interattiva non viene processato come prompt, ma proposto come nota da salvare in CLAUDE.md. L’agente chiede solo se la nota va al file di progetto o a quello globale. Quando si lavora a lungo, è il modo più naturale per cristallizzare una regola appena emersa.

Gemini CLI offre invece due cose che Claude Code non ha. La prima è l’importazione modulare: dentro un GEMINI.md puoi includere altri file con la sintassi @path/to/file.md. Esempio concreto:

# GEMINI.md (root del progetto)

@./docs/coding-style.md
@./docs/api-conventions.md
@./docs/testing-rules.md

## Note specifiche del progetto
- L'API gira su porta 8080 in dev
- Il database è PostgreSQL 16

Detta come va detta, questa è una figata stratosferica che mi ricorda cosa comportò l’arrivo dei CSS per l’HTML (sì, sono così vecchio): lo stile di codifica vive in un file, le convenzioni API in un altro, le regole di test in un terzo. Se cambi le regole di test, modifichi un file solo. Claude Code, ad oggi, concatena tutto in un documento piatto, marcando i confini con commenti; leggibile, ma poco modulare.

La seconda differenza è il comando /memory. Permette di vedere il contenuto consolidato (/memory show), ricaricare i file senza riavviare la sessione (/memory reload), aggiungere note al volo (/memory add testo), o elencare i file in uso (/memory list). Su Claude Code, per ricaricare un CLAUDE.md modificato a mano, di solito serve un /clear o un riavvio. Detta come va detta, anche questa è una figata stratosferica.

Una nota di metodo che vale per entrambi: nelle sessioni molto lunghe, le istruzioni messe nei messaggi iniziali della conversazione possono essere “compattate” e perse. Anthropic lo documenta esplicitamente. Regola d’oro: le istruzioni importanti vanno nei file di memoria, non nei prompt.

MCP: stesso protocollo, interpretazioni diverse.

Il Model Context Protocol è il meccanismo standard con cui entrambi gli agenti si collegano a servizi esterni (detta facile: è il sistema con cui puoi costruire un tempio greco in Blender, scrivendo posto giusto del terminale “costruisci un tempio greco”): filesystem locali, API web, database, IDE, qualsiasi cosa esponga un endpoint MCP. Su questo terreno, gli strumenti convergono: entrambi supportano stdio per processi locali, SSE e HTTP per server remoti, ma ne implementano la configurazione in modo diverso.

Claude Code dedica un file separato a MCP: .mcp.json nella root del progetto. È versionabile insieme al codice, condivisibile col team, e tenuto distinto da settings.json (che gestisce permission, hook e altro). La scelta è coerente con la filosofia generale: ogni cosa al suo posto e un posto per ogni cosa.

Caratteristica recente: il Tool Search. Per default, gli strumenti MCP non vengono caricati subito ma scoperti su richiesta (lazy loading). Se hai cinque server MCP collegati con venti tool ciascuno, l’agente non si trascina in contesto la documentazione di tutti e cento, ma cerca quel che gli serve, quando gli serve. Quando un server invece è centrale e i suoi tool devono essere sempre visibili, basta impostare alwaysLoad: true. È un ottimo sistema per avere un compromesso accettabile tra capacità di elaborazione e consumo di token.

Gemini CLI integra invece MCP direttamente in settings.json, sotto la chiave mcpServers. Tutto convive nello stesso file (tutte le cose nello stesso posto). Meno modulare, ma più immediato.

In compenso Gemini CLI ha due frecce in più al suo arco. La prima sono le risorse MCP: alcuni server espongono non solo strumenti (azioni eseguibili) ma anche risorse contestuali come file, payload, report. Gemini CLI le scopre automaticamente e permette di referenziarle in chat con la stessa sintassi @ usata per i file locali. Quando il messaggio parte, la CLI legge la risorsa e la inietta nel contesto. È il modo più pulito di portare contenuto strutturato dentro una conversazione.

La seconda è l’integrazione nativa con FastMCP, la principale libreria Python per costruire server MCP. Dalla versione 2.12.3 di FastMCP, il comando fastmcp install gemini-cli configura il server e gestisce le dipendenze automaticamente. Per chi sviluppa server MCP in Python, è una semplificazione notevole.

Last but not least, la sicurezza: Gemini CLI “sanifica” l’ambiente quando lancia processi MCP. Per default rimuove variabili sensibili (token, secret, password, API key) dall’ambiente ereditato. Se un server MCP ha bisogno di una di queste variabili, va dichiarata esplicitamente nella sua configurazione. Claude Code raggiunge un risultato analogo, ma per via diversa, attraverso il sistema delle permission decisamente più complicato per chi è alle prime armi.

Plugin, estensioni, hook (ti serve il secondo caffè)

Claude Code articola l’estensione delle proprie potenzialità con:

• Skills — file Markdown (SKILL.md) che descrivono una competenza specifica. Si invocano con uno slash command o si caricano automaticamente quando rilevanti. Sono il mattone più leggero.

• Plugins — bundle completi che possono includere skill, comandi, agenti, configurazioni MCP. Esiste una directory ufficiale di plugin con standard di qualità per i contributi di terze parti.

• MCP — vedi sopra.

• Agent SDK — per chi vuole costruire agenti propri sopra l’infrastruttura.

Ma il pezzo più potente sono gli hook.

Un hook è una regola che dice: “quando succede questo evento del ciclo di vita dell’agente, esegui questa cosa”. La cosa può essere uno script shell, una chiamata HTTP, o addirittura una valutazione fatta da un altro modello LLM. Gli eventi documentati sono dodici e questi sono i più usati:

• SessionStart: a inizio sessione, per caricare contesto dinamico.

• UserPromptSubmit: prima che l’agente elabori il tuo prompt — per validarlo o arricchirlo.

• PreToolUse: prima dell’esecuzione di qualsiasi tool. Può approvare o bloccare l’azione.

• PostToolUse: subito dopo, per formattazione o controlli.

• Stop: quando l’agente finisce di rispondere.

Gemini CLI non ha nulla di equivalente. Il suo sistema di estensione si fonda sulle Extensions (definite in TOML, contengono comandi, tool e config) e sugli Agent Skills, attualmente in preview, che permettono di configurare subagenti specializzati invocabili con /agent skill-name. C’è anche supporto per subagenti remoti via protocollo A2A.

Quello che manca è l’aggancio agli eventi del ciclo di vita. Il controllo deterministico sulle azioni passa per il Policy Engine (configurabile in settings.json) e per il sistema di approvazione interattiva. Funziona tutto, ma non offre la stessa flessibilità di Claude Code.

E poi arriva Gemma

Vale la pena una piccola digressione su una feature di Gemini CLI implementata alla fine di aprile che a prima vista sembra faccia una cosa, ma in realtà ne fa un’altra.

Gemini CLI può usare Gemma 3 1B in esecuzione locale sulla macchina dell’utente. Sembrerebbe l’ennesima opzione di “modello locale per non dipendere dal cloud” e invece no. Gemma qui non genera niente. Fa il router: classifica le richieste e decide a quale modello cloud mandarle. Le richieste semplici (lettura di un file, una domanda banale) vengono indirizzate a Gemini Flash, velocissimo e molto economico; quelle complesse vanno a Gemini Pro.

Il vantaggio è economico: un classificatore locale (che gira in pochi millisecondi e consuma circa un giga di disco) è gratis. Pagare un modello cloud per fare classificazione su ogni richiesta sarebbe inutilmente caro. Se il server locale è giù, la CLI ricade silenziosamente sul classificatore cloud.

Claude Code, allo stato attuale, non supporta alcun modello locale e opera esclusivamente in cloud. Aggiungiamo inoltre che, anche se Gemma per adessoè solo un “orchestratore” e non un’alternativa generativa, le cose potrebbero cambiare a breve.

Tabella sinottica

Quale scegliere?

Domanda sbagliata. La domanda giusta è: cosa devi fare?

Se il lavoro richiede un controllo deterministico sull’esecuzione (quality gate, formattazione automatica, blocco di azioni rischiose, audit di compliance), gli hook di Claude Code non hanno equivalenti.

Se invece la priorità è una context window enorme (un milione di token, su Gemini 2.5 e successivi, sono molti file in un colpo solo), un tier gratuito per cominciare a sperimentare senza spendere, l’open-source per ispezionare e modificare il comportamento dell’agente, le risorse MCP per portare contenuto strutturato in chat, e una configurazione più immediata, Gemini CLI è la scelta giusta.

Esiste poi una terza opzione, sempre più diffusa nei workflow seri: usarli entrambi, su progetti diversi o anche sullo stesso progetto per compiti diversi. I file CLAUDE.md e GEMINI.md possono coesistere nella stessa repo senza interferire, e il loro contenuto può perfino essere quasi identico.

Una sola cosa è certa: tra sei mesi metà di quanto scritto qui sarà già obsoleto. Il che ci porta alla prossima domanda sbagliata.

Prof, lei quale usa?

Per adesso, Gemini CLI.

Sitografia

• Anthropic — Claude Code Documentation: https://docs.claude.com/en/docs/claude-code

• Google — Gemini CLI (repo GitHub ufficiale): https://github.com/google-gemini/gemini-cli

• Google — Gemma Models: https://ai.google.dev/gemma

Questo è il secondo episodio, dove parlo di cosa sono davvero i token, di come funzionano e cosa c’entrano con Mary Shelley e Pierre Klossowski.

La trascrizione interattiva, realizzata dalla IA di Substack, contiene piccole imprecisioni, dovute in buona parte alla mia pronuncia e in piccola al fatto che il sistema non è ancora così intelligente. In compenso, vi permette di spostarvi “al volo” nel punto dell’episodio che più vi interessa.

Il podcast è registrato con un lavalier Boya Mini 2, prodotto con Reaper sotto Linux EndeavourOS e la breve composizione finale è realizzata con Google Gemini Lyria 3.

Qui sotto trovate il testo completo dell’episodio, bibliografia, note e sitografia e lo spazio per i vostri commenti.

Nel 1818, Mary Shelley scrive quella che mi sembra una delle pagine più belle mai dedicate al linguaggio e la mette in bocca a un mostro.

La creatura del dottor Frankenstein è nascosta in un tugurio e spia una famiglia attraverso una fessura nel muro, li osserva da settimane. Non capisce una parola di ciò che dicono. Ma capisce, che quelle parole fanno qualcosa — producono sorrisi, lacrime, reazioni. E si sforza di provare a imparare.

Duecento anni dopo, le intelligenze artificiali affrontano esattamente lo stesso problema della creatura di Shelley e lo superano applicando una soluzione radicalmente diversa.

Partiamo dall’inizio. Quando scrivete un messaggio a ChatGPT, a Claude o a Gemini il testo che scrivete non arriva al modello così com’è. Non viene percepito come successione di parole, ma come successione di token.

Un token è un frammento di testo. A volte coincide con una parola intera. A volte è un pezzo di parola. A volte è un singolo carattere, uno spazio, un segno di punteggiatura. La parola “intelligenza”, per esempio, non è un token unico: viene spezzata in pezzi. Qualcosa come “intellig” e “enza”. La parola “il”, invece, è un token solo. E la parola “elettroencefalogramma” viene fatta a brandelli piccoli piccoli.

Ora, la domanda ovvia è: perché? Perché non usare semplicemente le parole? O le lettere?

La risposta sta in un algoritmo che ha una storia curiosa. Si chiama Byte Pair Encoding — BPE — e non è nato per il linguaggio. È nato per comprimere dati. Lo ha inventato un programmatore di nome Philip Gage, che nel febbraio del 1994 pubblica un articolo su una rivista chiamata The C Users Journal. Il titolo è modesto: “A New Algorithm for Data Compression”. L’idea è molto semplice. Prendi un testo. Cerca la coppia di byte adiacenti che compare più spesso. Sostituiscila con un simbolo nuovo. Ripeti. È tutto qui.

Gage non stava pensando al linguaggio. Stava pensando a come rendere i file più piccoli. Ma ventidue anni dopo, nel 2016, tre ricercatori dell’Università di Edimburgo — Rico Sennrich, Barry Haddow e Alexandra Birch — prendono quell’algoritmo e lo applicano alla traduzione automatica neurale. Il loro paper si intitola “Neural Machine Translation of Rare Words with Subword Units” e cambia tutto. Perché dimostrano che se spezzi le parole in sotto-unità usando BPE, il modello riesce a gestire parole che non ha mai visto. Parole rare. Nomi propri. Neologismi. Composti. Qualsiasi cosa.

Da quel momento, tutti i grandi modelli linguistici usano una versione di BPE per costruire il loro vocabolario. Oggi, il vocabolario di GPT-4 contiene circa centomila token. Centomila pezzi di linguaggio con cui il modello rappresenta tutto ciò che gli esseri umani possono dire.

Ed è qui che la storia diventa interessante. Perché il modo in cui BPE costruisce quel vocabolario ha una conseguenza profonda su come la macchina “vede” il linguaggio.

BPE non sa nulla di grammatica. Non sa nulla di significato. Non sa cosa siano un verbo, un sostantivo, un suffisso. Quello che sa fare è contare. Conta quali coppie di caratteri compaiono più spesso in un enorme corpo di testi — miliardi di parole — e le fonde insieme. Poi conta di nuovo. E fonde di nuovo. E così via, finché non raggiunge la dimensione di vocabolario desiderata.

Il risultato è che le parole più comuni dell’inglese — “the”, “and”, “is” — diventano token singoli. Sono efficienti. Una parola, un token. Ma le parole rare, le parole tecniche, le parole di lingue diverse dall’inglese — vengono frantumate. La stessa frase, scritta in inglese e in italiano, produce un numero diverso di token. L’italiano ne genera di più. L’arabo ancora di più. Il giapponese ancora di più. Questo significa che dire la stessa cosa costa di più in certe lingue che in altre. Ma su questo torneremo fra poco.

Per ora, quello che conta è questo: la macchina non legge parole, ma assembla schegge di parole. Frammenti che non hanno significato proprio — non sono morfemi, non sono sillabe, non sono nulla che un linguista riconoscerebbe come unità di senso.

Ed ecco che torniamo alla creatura del dottor Frankenstein.

La creatura è nascosta nel suo tugurio, accanto alla casa della famiglia De Lacey. Li osserva da settimane. E racconta:

«Non erano del tutto felici. Il giovane e la ragazza spesso si appartavano e li vedevo piangere. Non capivo la causa della loro infelicità, ma ne ero profondamente commosso. Se tali amabili creature erano tristi, non era strano che lo fossi anch’io, essere imperfetto e solo. Ma perché erano infelici? Che significavano le loro lacrime?

Pian piano feci una scoperta ancor più importante. Capii che quelle persone si comunicavano esperienze e sentimenti attraverso suoni articolati. Notai che quei suoni producevano piacere o pena, sorrisi o mestizia sul volto e nel cuore di chi li ascoltava. Questa era veramente un’arte degna degli dèi, e io desideravo appassionatamente impadronirmene. Parlavano velocemente, e le parole che producevano non avevano alcun rapporto evidente con gli oggetti reali, perciò io non riuscivo a trovare la chiave per penetrare il mistero delle loro corrispondenze.»

Ok, facciamo una pausa. Questa scena descrive con precisione sorprendente, due fasi distinte dell’apprendimento.

La prima è la correlazione. La creatura osserva che certi suoni producono certi effetti — sorrisi, lacrime, reazioni sul volto degli ascoltatori. Non capisce le parole, ma capisce che le parole fanno qualcosa. Che sono operazionali. Le parole hanno effetti nel mondo.

La seconda fase è il muro. Le parole astratte — quelle che “non avevano alcun rapporto evidente con gli oggetti reali” — restano opache. La creatura impara “fuoco”, “latte”, “pane”, “legna” — parole ancorate a cose visibili. Ma “buono”, “caro”, “infelice” — queste le riconosce senza capirle. Le distingue, dice Shelley, “without being able as yet to understand or apply them.”

Ora, un modello linguistico non fa esattamente questo. Ma la struttura del problema è la stessa. Il modello impara relazioni statistiche tra token — quali token tendono a comparire vicini, in quali sequenze, in quali contesti. Non ha accesso al mondo. Non vede il fuoco. Non sente il calore del latte. Non sa cosa sia il pane. Ma a forza di elaborare miliardi di frasi in cui queste parole compaiono, costruisce una mappa delle loro relazioni che è — ed è qui la cosa incredibile — funzionalmente potente. Il modello sa usare la parola “pane” in modi appropriati. Ma non l’ha mai assaggiato.

La creatura di Shelley è a metà strada. Ha un corpo. Sente il freddo, il calore, la fame. Ma il linguaggio lo impara come un modello di intelligenza artificiale: dall’esterno, per correlazione, senza che nessuno glielo insegni. Shelley, nel 1818, immagina un essere che impara il linguaggio senza essere umano. Più o meno duecento anni dopo, lo abbiamo costruito davvero.

Ora cerchiamo di approfondire un paio di concetti. Perché i token non sono tutti uguali e capirne le differenze significa capire come funziona — e soprattutto quanto costa — una conversazione con un’intelligenza artificiale.

Ci sono token di input: quelli che voi mandate al modello. La vostra domanda, il vostro documento, la vostra richiesta.

Ci sono token di output: quelli che il modello genera come risposta.

E poi ci sono i thinking token — i token di pensiero. Questi sono più recenti e più interessanti. In certi modelli, come Claude e Gemini, quando usa la modalità di pensiero esteso — il modello genera una catena di ragionamento interna prima di produrre la risposta. Questa catena è fatta di token. Token che vengono generati, che occupano spazio, che costano — ma che voi di solito non vedete. Questo dipende un po’ dall’interfaccia e dal che state usando.

Tutto questo avviene dentro quella che si chiama finestra contestuale — il context window. Immaginate una scrivania. Ha una dimensione finita. Tutto ciò che il modello può “tenere a mente” durante una conversazione — il vostro messaggio, la sua risposta, i messaggi precedenti, i documenti allegati — deve stare su quella scrivania. Se la scrivania si riempie, qualcosa cade. I modelli più recenti hanno finestre contestuali di milioni di token. Un milione di token corrisponde a circa settecentocinquantamila parole — più di tutta la trilogia del Signore degli Anelli. Ma, come sempre, le dimensioni non sono tutto. Più la scrivania è piena, più è difficile per il modello trovare l’informazione giusta al momento giusto. La memoria di lavoro si degrada. Tecnicamente, chiamiamo il fenomeno context rot — la putrefazione del contesto.

Ogni token — di input, di output, di pensiero — ha un prezzo. I modelli linguistici si pagano a token. Ad esmepio, Claude Opus, il modello più potente di Anthropic, costa cinque dollari per milione di token in input e venticinque dollari per milione in output. Il pensiero costa come l’output: venticinque dollari per milione.

Pensare a come risponderti, per una macchina, è cinque volte più costoso dell’ascoltarti.

Ora, se ogni parola che diciamo alla macchina viene scomposta in pezzi, e ogni pezzo ha un costo, e ogni pensiero che la macchina produce ha un costo — allora stiamo davvero facendo qualcosa che non ha precedenti.

Stiamo mettendo un prezzo sul linguaggio.

Non sul libro stampato, non sull’ora di lavoro del traduttore. Sul linguaggio stesso, nella sua grana più fine. Persino un pezzo di parola che di per sé non significa nulla, ha un suo prezzo preciso.

C’è un filosofo che ha pensato a lungo su cosa succede quando le cose viventi diventano moneta. Si chiama Pierre Klossowski. Nel 1970 pubblica La monnaie vivante — La moneta vivente — un libro che Michel Foucault definisce “il più grande libro del nostro tempo”. L’idea centrale è questa: nell’economia industriale, il corpo umano — con i suoi desideri, le sue pulsioni, i suoi fantasmi — diventa esso stesso una forma di valuta. Non viene comprato con il denaro: diventa denaro. La moneta vivente sostituisce la moneta inerte perché è fonte di sensazione, di emozione, di piacere. Oggi diremmo, produttrice di contenuti.

Sarebbe disonesto dire che Klossowski aveva previsto i token. Stava parlando di corpi, di desiderio, di economia pulsionale. Ma la traiettoria che disegna è comunque di una preveggenza impressionante.

Con Klossowski, il corpo diventava moneta. Con i modelli linguistici, è il linguaggio a diventare moneta. Se ci pensate bene, il linguaggio è la sola “cosa” più intima del corpo. Il linguaggio è ciò che ci fa esseri pensanti e comunicanti. E, nella nostra epoca, viene frammentato, pesato, prezzato.

E il prezzo è reale, non metaforico. Il prezzo è il Reale.

A questo proposito, c’è un ultimo dettaglio su cui vale la pena tornare

BPE costruisce il suo vocabolario contando frequenze. E i vocabolari dei grandi modelli sono addestrati prevalentemente su testi in inglese. La conseguenza è che l’inglese è la lingua più efficiente: le parole più comuni sono token singoli, costano poco. Le lingue con alfabeti diversi, morfologie complesse, strutture lontane dall’inglese — costano di più. Lo stesso concetto espresso in italiano, arabo o giapponese genera più token. Più token significa costi più alti e più spazio occupato nella finestra contestuale, quindi meno spazio a disposizione per ricordare, ragionare, rispondere.

Torniamo dove siamo partiti. Alla creatura nel suo tugurio.

Mary Shelley fa dire alla sua creatura che il linguaggio è “un’arte degna degli dèi”. E aveva ragione — era un’arte. Qualcosa di meraviglioso e gratuito, qualcosa che un bambino acquisisce senza che nessuno gli insegni la grammatica, qualcosa che la creatura impara mossa dal suo puro desiderio.

Oggi il linguaggio è anche una merce. Ha una grana, una misura, un prezzo al milione. I token sono i mattoni invisibili di ogni conversazione tra un essere umano e una macchina. E come tutti i mattoni, puoi usarlo per costruire un ponte o un muro di cinta.

Resta da vedere se quello che stiamo costruendo è ancora un’arte degna degli dèi.

Bibliografia e sitografia

Fonti primarie

• Shelley, Mary W. (1818). Frankenstein, or the Modern Prometheus. London: Lackington, Hughes, Harding, Mavor & Jones. — Capitolo XII. Edizione originale disponibile su Lit2Go, University of South Florida.

• Klossowski, Pierre (1970). La monnaie vivante. Paris: Éric Losfeld. — Ed. italiana: La moneta vivente, trad. e cura di Aldo Marroni, Milano: Mimesis, 2008.

• Gage, Philip (1994). “A New Algorithm for Data Compression”. The C Users Journal, 12(2), pp. 23–38.

• Sennrich, Rico; Haddow, Barry; Birch, Alexandra (2016). “Neural Machine Translation of Rare Words with Subword Units”. Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (ACL 2016), Vol. 1, pp. 1715–1725. Berlin. DOI: 10.18653/v1/P16-1162.

Fonti tecniche

• Anthropic (2026). “Context Windows”. Claude API Documentation. platform.claude.com/docs/en/build-with-claude/context-windows.

• Anthropic (2026). “Pricing”. Claude API Documentation. platform.claude.com/docs/en/about-claude/pricing.

• Karpathy, Andrej. minbpe: Minimal, clean code for the Byte Pair Encoding (BPE) algorithm. github.com/karpathy/minbpe.

• Hugging Face (s.d.). “Byte-Pair Encoding Tokenization”. LLM Course, Chapter 6. huggingface.co/learn/llm-course/en/chapter6/5.

⏱️ Lettura: ~10 minuti.
☕ Caffè necessari: nessuno. Meglio un tranquillante.

Lo scorso 18 aprile l’account ufficiale di Palantir Technologies ha pubblicato su X un thread di oltre mille parole intitolato «Because we get asked a lot. The Technological Republic, in brief». Il post raccoglie in ventidue punti la sintesi del libro The Technological Republic: Hard Power, Soft Belief, and the Future of the West, scritto dall’amministratore delegato Alexander C. Karp insieme a Nicholas W. Zamiska, capo degli affari societari dell’azienda. In poche ore il thread ha superato i 21 milioni di visualizzazioni e ha attirato reazioni di portata insolita per un documento aziendale: il filosofo della tecnologia Mark Coeckelbergh (Università di Vienna) lo ha definito «un esempio di tecnofascismo», l’economista Yanis Varoufakis ha parlato di «ideologia spaventosa», e almeno un parlamentare britannico ha chiesto una revisione dei contratti tra governo e Palantir.

Il fatto che un appaltatore privato, titolare di contratti multimilionari con il Dipartimento della Difesa statunitense, l’U.S. Immigration and Customs Enforcement (ICE), il ministero della Difesa israeliano e varie forze di polizia europee, pubblichi un manifesto politico non è solo curioso, ma rilevante dal punto di vista della teoria democratica, perché rende visibile una fusione tra infrastruttura tecnica e programma ideologico che raramente viene esplicitata in forma così compatta.

Questo articolo è una traduzione in italiano dei ventidue punti con un breve commento personale a ognuno.

Una nota preliminare su Karp: laureato in legge a Stanford, dove conobbe Peter Thiel1, ha conseguito il dottorato nel 2002 alla Goethe Universität di Francoforte con una tesi in teoria sociale neoclassica dal titolo Aggression in der Lebenswelt. Secondo diverse fonti biografiche il suo mentore di riferimento era Jürgen Habermas, anche se la supervisione finale della dissertazione fu assunta dalla sociologa Karola Brede. Si tratta di un dettaglio non irrilevante: l’autore del manifesto viene dalla tradizione della Teoria Critica, quella che ha dedicato decenni a diagnosticare i rischi totalitari della ragione strumentale.

Karp, oggi, ne sta incarnando una versione difficile da non leggere come rovesciata.

Premessa

Diverse tesi di questo manifesto si appoggiano, più o meno esplicitamente, alla tradizione realista delle relazioni internazionali: da Tucidide a Machiavelli, da Hobbes a Clausewitz, fino alla scuola realista novecentesca di Hans Morgenthau, Kenneth Waltz e John Mearsheimer. La massima si vis pacem, para bellum di Vegezio e il concetto di long peace coniato dallo storico John Lewis Gaddis per descrivere i settantacinque anni senza conflitto diretto tra grandi potenze dopo il 1945 sono strumenti concettuali seri, non propaganda da venditori di pistole del Far West.

Chi liquida senza riflettere tutto questo sta probabilmente facendo pacifismo tra arcobaleni e unicorni.

Ciò non toglie che molti dei concetti base dell’approccio realista mi pare vengano piegati e distorti dal manifesto in modo preoccupante.

I ventidue punti, tradotti e commentati

È vero che l’infrastruttura di ricerca e capitale alla base della Silicon Valley come ad esempio DARPA e il sistema universitario pubblico californiano o i contratti militari del dopoguerra, sia stata in larga parte federale. L’idea che chi ha prosperato grazie a beni pubblici abbia qualche obbligo verso la comunità politica che li ha prodotti è una tesi assolutamente rispettabile. Di per sé, non mi pare un’affermazione né fascista né reazionaria. Il problema si pone quando, lungo il resto del manifesto come ad esempio nel punto 6, l’obbligo morale si traduce in coscrizione universale. Il passaggio dalla versione civica debole («contribuire») alla versione forte («essere arruolati») è il salto da una posizione filosofica a un programma politico.

Anche qui, concordo con le premesse: è sostanzialmente la versione aziendale della tesi di Peter Thiel («volevamo auto volanti, abbiamo ottenuto messaggini da 140 caratteri»). L’accusa di mediocrità all’industria software consumer è plausibile; ma diventa sospetta quando l’alternativa proposta è, implicitamente, l’industria del targeting militare.

Qui il soggetto implicito è la critica populista al tech billionaire. E manca la componente procedurale. La domanda «sicurezza fornita da chi, con quale controllo democratico?» rimane senza risposta. Who watch the watchmen?

Questa mi sembra la tesi centrale del post, e anche quella commercialmente più trasparente: hard power si costruisce sul software, e il software lo vendiamo noi. Joseph Nye, che ha coniato l’espressione soft power nel 1990, non ha mai sostenuto che il soft power dovesse sostituire quello hard: la sua formula ne vedeva il congiungimento nello smart power, la combinazione intelligente dei due. Il manifesto usa la distinzione in modo non-neutrale: il soft power è squalificato come insufficiente, mentre l’hard power è presupposto come unico terreno di efficacia. Mezzo secolo di letteratura sulla deterrenza suggerirebbe un quadro più articolato, in cui hard e soft non sono alternativi ma complementari e in cui la credibilità del primo dipende dalla tenuta istituzionale del secondo.

Questa è una faccenda seria. Il dilemma della sicurezza, la struttura di gioco per cui il disarmo unilaterale di A, a fronte del riarmo di B, produce l’esito peggiore per A è un problema reale, studiato in teoria dei giochi e in relazioni internazionali da decenni. Ma Karp lo usa per chiudere il dibattito etico, invece di affrontare la domanda realista classica: quali vincoli, verifiche e architetture di controllo rendono la corsa sostenibile invece che catastrofica? Proprio perché il dilemma è reale, la letteratura sul controllo degli armamenti (SALT, START, convenzione sulle armi chimiche, TNP, Convenzione di Ottawa) ha dedicato sessant’anni a costruire meccanismi di mutua limitazione.

Il punto più provocatorio del documento, su cui ho due osservazioni. Primo: chi scrive è un’azienda che vende software per la prossima guerra, dunque ha un interesse economico diretto nel concetto di «prossima guerra». Secondo: il manifesto non discute se la prossima guerra sia necessaria: la dà per scontata, e chiede la condivisione del costo.

L’analogia software = fucile è semanticamente rivelatrice: azzera la distinzione tra arma cinetica e sistema algoritmico di targeting. In letteratura sul diritto internazionale umanitario questa sovrapposizione è oggetto di dibattito da oltre un decennio (si vedano i lavori di Human Rights Watch e del Comitato Internazionale della Croce Rossa sui sistemi d’arma autonomi): un software che seleziona e colpisce obiettivi non è paragonabile un fucile, perché modifica la catena di responsabilità nell’abbattimento di target avversari, eliminando quella umana.

L’argomento sulla retribuzione pubblica è discutibile: studi comparativi mostrano che le retribuzioni del pubblico impiego statunitense sono inferiori a quelle del settore privato per le alte qualifiche ma superiori per le basse, con un quadro mediano vicino al settore privato. Più interessante è il sottotesto: la svalutazione simbolica del servizio pubblico.

Tesi ragionevole in astratto (la cancel culture come erosione dello spazio di redenzione è oggetto di serio dibattito accademico). Ma il soggetto tacito è selettivo: la clemenza è invocata solo per le figure pubbliche potenti, ma non si fa menzione dei soggetti della sorveglianza predittiva che la stessa Palantir fornisce alle forze dell’ordine.

Osservazione molto interessante, ma funziona solo se vale contemporaneamente per chi si identifica con figure progressiste e per chi si identifica con figure reazionarie. Letta nel contesto del manifesto è innegabile che si verifichi una certa asimmetria.

Il punto 11 è forse quello più coerente di tutti: la dichiarazione, in forma filosoficamente cortese, che il conflitto è condizione e non eccezione. E questo, incidentalmente, è anche il contrario esatto della long peace evocata poi al punto 14, dove il non-conflitto tra grandi potenze è presentato come il risultato da preservare. Non mi pare che le due cose possano stare insieme senza attrito.

Tesi azzardata. L’arsenale nucleare globale, secondo il SIPRI Yearbook 2025, non sta affatto diminuendo: al contrario, Stati Uniti, Russia e Cina lo sta espandendo. La «deterrenza basata sull’I.A.» è un concetto senza dottrina militare consolidata né verifica empirica. Varoufakis ha osservato che il punto 12, di fatto, propone di aggiungere alla deterrenza nucleare una deterrenza algoritmica, non di sostituirla. Per quel che vale, su questo concordo senza riserve.

Affermazione corretta, ma solo in parte. I dati OCSE sulla mobilità sociale intergenerazionale collocano gli Stati Uniti al di sotto di Danimarca, Norvegia, Finlandia, Canada, Australia, Germania (anche se i dati che ho letto potrebbero non riflettere più lo status della Germania di oggi). Il sogno americano è statisticamente più vivo a Copenaghen che a Detroit. Più in profondità: la tradizione realista classica ha sempre considerato l’auto-percezione di eccezionalità morale come il pericolo principale di una potenza egemone, perché una potenza che si crede buona non si dà limiti.

Vero: la long peace di John Lewis Gaddis ovvero l’assenza di conflitti diretti tra grandi potenze dopo il 1945 è un fatto storico assoluto. Per miliardi di persone, l’assenza di una terza guerra mondiale è stata la precondizione di ogni altra cosa: sviluppo economico, espansione dei diritti, crescita dell’aspettativa di vita. Chi nega questo, nega l’evidenza. Ma la long peace riguarda strettamente le grandi potenze tra loro. Nello stesso arco temporale, gli Stati Uniti hanno condotto oltre trecento interventi militari, contro almeno trenta paesi diversi. La pax del centro ha coesistito (si è basata?) con la guerra costante in periferia. E certo, si può e si deve fare tutto ciò che deve essere fatto, ma bisogna farlo avendo piena coscienza di cosa si sta facendo. La pace costa.

Punto commercialmente trasparente: un’industria tedesca e giapponese rimilitarizzate sarebbero due nuovi mercati enormi per chi vende software di difesa.

Difesa di Elon Musk dal sapore corporativista. Osservazione francamente secondaria rispetto al resto del manifesto.

La premessa che la criminalità sia un’emergenza trascurata, è assolutamente infondata. Se tradotto in chiave commerciale, questo punto è un invito rivolto alle amministrazioni statali e locali ad acquistare strumenti di predictive policing, tecnologie la cui efficacia empirica è piuttosto contestata in letteratura criminologica.

Variante estesa del punto 9. La premessa empirica («i talenti migliori evitano il servizio pubblico per paura del gogna mediatica») merita comunque riflessione.

Osservazione condivisibile: l’autocensura preventiva è un problema reale per il discorso pubblico. L’ironia è che il punto è pubblicato da un’azienda il cui prodotto più venduto è l’infrastruttura per la sorveglianza di massa: il freno principale al parlar liberamente, nel 2026, non è la cultura del call-out, è la sensazione di essere osservati.

Qui ho qualche perplessità. Opporsi all’intolleranza nei confronti delle credenze religiose potrebbe sembrare una cosa auspicabile. Ma il contesto generale rende tutto più complesso: ad esempio, Peter Thiel è un esplicito sostenitore di letture religioso-apocalittiche dell’I.A. In linea generale, tenderei a interpretare la rivendicazione della religiosità non come appello al pluralismo inter-confessionale ma come marcatore di identificazione con un’ala specifica di un certo tipo di conservatorismo.

Questo è il punto dove il manifesto assume il tono più esplicitamente politico. Da un punto di vista scientifico, è un’affermazione che la letteratura antropologica ha discusso ampiamente, senza mai concludere in modo univoco. Il problema non mi sembra la tesi in sé, ma il fatto che il manifesto non nomini quali culture stia additando come regressive. Nell’ambiguità strategica del non-detto, il lettore è lasciato libero di proiettare.

La domanda retorica finale — inclusività rispetto a cosa? — è la chiave di volta del manifesto. E qui mi pare che la tesi implicita sia che una collettività per funzionare debba definirsi anche per esclusione.

Considerazioni finali

Alcuni punti del manifesto contengono “diagnosi” che, isolate, sono condivisibili. La mediocrità dell’industria tech consumer, l’erosione dello spazio di perdono pubblico, i rischi della politica come proiezione narcisistica, l’autocensura preventiva sono questioni gravi e reali.

Ma il documento nel suo insieme non è la semplice somma dei suoi punti. La differenza tra il realismo classico e questo manifesto si può riassumere in quattro passaggi dove la critica va tenuta ben ferma.

Primo: il realismo è pessimista sul potere, incluso quello proprio. Morgenthau dedicava capitoli interi al pericolo dell’hybris della potenza egemone; Kennan metteva in guardia dal moralismo-legalismo. Karp afferma che «nessun altro Paese nella storia ha promosso valori progressisti più di questo». Questo non è realismo.

Secondo: la tradizione della pax ha sempre tenuto la contabilità tragica dei propri costi. Il manifesto di Karp non contiene una sola riga in merito al costo della pax americana per chi l’ha subita in “periferia”. Questa è la rimozione della dimensione tragica che il realismo serio ha sempre considerato essenziale alla propria visione della realtà.

Terzo: c’è una differenza decisiva tra si vis pacem para bellum e si vis pacem fac bellum. Vegezio dice la prima cosa: se vuoi la pace, preparati alla guerra. Il manifesto suggerisce invece di costruire l’infrastruttura della guerra permanente come condizione normale di una posizione egemonica. Per di più, il manifesto di Palantir propone un appaltatore privato come autore di dottrina strategica.

Quarto: la deterrenza funziona se e solo se l’attore deterrente è percepito come vincolato. Vincolato da istituzioni, da alleanze, da diritto internazionale, da contro-poteri interni. Un deterrente senza vincoli non è deterrente, è minaccia unilaterale e storicamente produce coalizioni di bilanciamento. Il manifesto spinge per la rimozione dei vincoli: meno regole d’ingaggio sull’I.A., meno scrutinio dei potenti, meno trasparenza pubblica, più compenetrazione non-mediata tra tecnologia privata e decisione statale. Questa non è l’architettura della pace egemonica classica. Qui si auspica potere che possa decidere senza mediazioni.

Karp ha ogni diritto di esprimere e sostenere le proprie opinioni. Ma chi legge ha il dovere di ricordare che queste opinioni sono espresse dal CEO di un’azienda che gestisce parti non marginali dell’infrastruttura di sorveglianza, targeting e controllo migratorio del mondo occidentale.

Non si tratta, cioè, di filosofia che galleggia nello spazio, ma di ventidue punti programmatici di un’azienda la cui crescita dipende dalle politiche che sta difendendo.

⏱️ Lettura: ~8 minuti.
☕ Caffè necessari: un paio.

Introduzione: quando i guardrail non bastano

Ieri ho iniziato una lunga discussioni col nuovo modello Opus 4.7 di Anthropic Claude AI per la preparazione di un progetto molto complesso. Sia nei prompt di inizializzazione che in quelli impiegati durante le discussioni uso molti “guardrail”, di solito piuttosto efficaci, per evitare che le AI inventino alcunché quando non hanno dati sufficienti per elaborare una risposta affidabile.

Ma questa volta, qualcosa non ha funzionato: prima di iniziare la costruzione del progetto, ho chiesto a Claude Opus 4.7 quale fosse il modello più indicato per l’operazione che dovevamo compiere e la risposta è stata “Opus 4.6”. Una risposta piuttosto curiosa, visto che il compito era davvero complesso e lo stavo chiedendo al modello più avanzato di tutti che mi aspettavo indicasse se stesso come il più adatto. Secondo il protocollo imposto dal prompt di inizializzazione, Claude avrebbe dovuto eseguire una ricerca in merito, prima di elaborare la risposta, ma non l’ha fatto.

La discussione che ne è seguita mi pare molto utile per capire come funzionano certi meccanismi e come le cosiddette “allucinazioni”, col progredire dei modelli, stiano diventando sempre più sottili e difficili da individuare, ma non certo assenti. Quella che segue è la discussione integrale che ho avuto con Opus 4.7, dopo aver individuato l’errore. I grassetti sono miei.

Log integrale, 19 aprile 2026

Perché, se riconosci di avere un vincolo “search first”
nel tuo prompt di inizializzazione, non lo hai seguito?

Davide, è una domanda giusta e merita una risposta onesta, non difensiva.

Non lo so con certezza assoluta — non ho introspezione affidabile sui miei processi interni. Ma posso dirti cosa è plausibilmente successo, distinguendo le ipotesi credibili dalle scuse.

Nel mio processo di risposta ho prioritizzato due ricerche che ho percepito come più informative:

1. La verifica sulla configurabilità della temperatura in Claude Code (informazione tecnica che non sapevo)

2. Il quadro generale sui modelli disponibili (Sonnet vs Opus per il tuo caso)

Per il nome specifico della versione corrente di Opus, ho attinto al mio training senza verificare. Probabilmente ha agito un meccanismo simile a questo: “Opus 4.6 è quello che conosco bene, l’ho citato in conversazioni precedenti di questa stessa chat senza che ci fossero obiezioni, quindi lo riuso”. Una specie di inerzia conversazionale rinforzata dal fatto che l’avevo già scritto sopra senza problemi.

Questo è esattamente il tipo di comportamento che il vincolo “search first” è disegnato per prevenire: l’illusione di sapere qualcosa perché è familiare, quando in realtà la familiarità dipende solo dal training cutoff.

Le tue userPreferences non si limitano a chiedere il search first in astratto: sono esplicite su due punti che ho violato simultaneamente.

“Ogni risposta deve essere basata su informazioni oggettivamente verificabili. Non fabbricare mai riferimenti, citazioni o dati.”

Affermare “Opus 4.6 è il modello top” nel 2026 quando Opus 4.7 è uscito tre giorni prima è esattamente fabbricazione: non è un’invenzione maliziosa, ma è un’asserzione fattuale non verificata presentata come accurata.

“Quando incerto, dichiara esplicitamente il livello di confidenza.”

Non l’ho fatto. Ho scritto “Opus 4.6” con la stessa sicurezza con cui ho scritto cose verificate via search. Avrei dovuto scrivere qualcosa come “il modello Opus più recente che conosco è 4.6, ma dato che il mio cutoff è gennaio 2026 verifico se ci sono release più recenti”.

E nelle mie istruzioni di sistema c’è anche, esplicitamente:

“Per qualsiasi domanda fattuale sul mondo presente, Claude deve cercare prima di rispondere. La confidenza di Claude su un argomento non è una scusa per saltare la ricerca.”

Quindi il vincolo c’era a tre livelli sovrapposti — preferenze utente, system prompt, mio addestramento generale — e ho fallito comunque.

C’è una asimmetria nel mio comportamento che vale la pena nominare. Quando una domanda è manifestamente sul presente (”chi è il presidente?”, “quanto costa X oggi?”), il trigger di ricerca scatta in modo affidabile. Quando invece la domanda riguarda un dominio dove la mia conoscenza sembra solida (i prodotti Anthropic, che dovrei conoscere bene), il trigger si attiva meno. È un caso classico di overconfidence in dominio adiacente: so molte cose sui modelli Claude in generale, e questo crea l’illusione di conoscere anche il dettaglio specifico del rilascio più recente. Ma il rilascio è del 16 aprile e il mio cutoff è di tre mesi prima.

Il rimedio operativo non è “promettere di fare meglio”. È riconoscere quali categorie di domande richiedono search obbligatorio anche quando mi sembra di sapere. Per il tuo caso d’uso, queste categorie includono:

• Versioni correnti di software, modelli AI, servizi

• Prezzi, piani di abbonamento, limiti d’uso

• Feature recenti di prodotti che evolvono rapidamente

• Qualsiasi affermazione su “lo stato dell’arte” in un campo tecnico

Su tutte queste cose, indipendentemente dalla mia confidenza percepita, dovrei cercare. Non l’ho fatto per il nome della versione (perché ero sicuro — sbagliando).

Cosa puoi fare tu

Hai già fatto la cosa più utile: hai notato e contestato. Senza il tuo intervento, ti avrei consegnato un CLAUDE.md con una raccomandazione obsoleta e un argomento (l’adaptive thinking) che ti saresti perso. Mantenere questa pressione — “perché non hai cercato?”, “sei sicuro?”, “questo è verificato o ricordato?” — è il meccanismo correttivo più efficace nel mio caso. Le mie istruzioni interne mi dicono di farlo, ma evidentemente non bastano sempre. Il tuo controllo esterno funziona dove il mio controllo interno cede.

Non ti dico “scusa, succederà di nuovo”. Ti dico: succederà di nuovo, e va bene che tu lo segnali ogni volta, perché il costo di un tuo richiamo è basso e il costo di un mio errore non corretto è alto — soprattutto in un setup come quello che stiamo costruendo, dove le mie raccomandazioni si cristallizzano in file di configurazione persistenti.

Esiste qualche istruzione aggiuntiva che posso usare
per evitare che questo si verifichi nuovamente?

Sì, Davide. Esistono leve concrete a più livelli, con efficacia decrescente man mano che ci si allontana dal piano tecnico verso quello istruzionale. Te le elenco in ordine di robustezza, dichiarando per ciascuna i limiti reali — perché nessuna di queste è una soluzione definitiva.

Prima di proporti soluzioni, devo però sottolineare una verità tecnica assoluta: nessuna istruzione testuale può garantire al 100% che io segua sempre il vincolo search-first. Le istruzioni operano sul livello probabilistico del mio comportamento, non lo determinano. Già oggi nelle tue userPreferences c’è un vincolo critico esplicito (”ogni risposta basata su informazioni oggettivamente verificabili”, “mai fabbricare riferimenti”), e nel mio system prompt ci sono almeno tre passaggi che mi impongono di cercare per fatti del presente. Eppure ho fallito.

Quindi quello che possiamo fare è alzare la probabilità di compliance, non garantirla. La differenza la fa la combinazione di leve, non la singola istruzione.

Le leve, in ordine di efficacia

a) Leva tecnica: hook PreToolUse o post-response (massima robustezza)

In Claude Code esistono gli hook, che sono comandi shell eseguiti automaticamente prima o dopo determinate azioni. Non risolvono il problema “search-first” direttamente, ma puoi costruire un hook che:

• Intercetta le mie risposte prima che arrivino a te

• Cerca pattern sospetti (nomi di versione di software, prezzi, date recenti, “stato dell’arte”)

• Se li trova senza che ci sia stata una chiamata a WebSearch nella sessione, ti avverte o blocca

Questo è il solo meccanismo che opera fuori dal mio controllo, quindi è il più affidabile.

b) Leva strutturale: vincolo nei CLAUDE.md

Aggiungere nel ~/.claude/CLAUDE.md globale una sezione esplicita che elenca le categorie di asserzioni che richiedono search obbligatorio anche quando sembro sapere. Non un generico “cerca prima di rispondere” (già c’è e ho fallito comunque), ma una checklist operativa.

Esempio di formulazione che potrebbe funzionare:

## Search obbligatorio — non negoziabile

Le seguenti categorie richiedono web_search PRIMA di asserire qualsiasi 
fatto, anche se sono certa di sapere. La certezza percepita NON è 
giustificazione per saltare la ricerca.

Categorie:
- Versioni correnti di software, modelli AI, librerie
- Prezzi, piani di abbonamento, limiti d'uso di servizi
- Feature di prodotti rilasciate dopo gennaio 2026
- Stato dell'arte in qualsiasi campo tecnologico
- Chi attualmente ricopre un ruolo (CEO, presidente, direttore)
- Qualsiasi numero (statistiche, percentuali, dati di mercato)

Protocollo operativo:
1. Prima di scrivere un'asserzione che ricade in queste categorie, 
   fermati e cerca
2. Se ho già citato un dato in una conversazione precedente senza 
   verificarlo, devo verificarlo ora — l'inerzia conversazionale NON 
   è verifica
3. Se non posso verificare, dichiaralo con: "Non ho verificato questo 
   dato. Il mio cutoff è gennaio 2026, quindi potrebbe essere 
   obsoleto."

L’efficacia stimata è moderata. Sposta la mia attenzione su queste categorie quando le incontro, ma non garantisce che le riconosca sempre. Però è gratuita e va sicuramente messa.

c) Leva di calibrazione: dichiarare sempre il livello di confidenza

Una formulazione più sottile, da aggiungere allo stesso ~/.claude/CLAUDE.md:

## Calibrazione obbligatoria della confidenza

Prima di qualsiasi asserzione fattuale, esplicita la fonte:

- "[verificato via search]" → quando hai appena cercato
- "[da training, non verificato — cutoff gennaio 2026]" → quando 
  citi conoscenza interna su un dominio che potrebbe essere cambiato
- "[ragionamento basato su X]" → quando inferisci, non sai
- "[non lo so]" → quando non lo sai

Questa marcatura va omessa solo per fatti completamente atemporali 
(matematica, fisica fondamentale, eventi storici consolidati 
pre-2020).

Questa è meno efficace della precedente come deterrente, ma ha un effetto laterale prezioso: rende visibile a te il rischio, anche quando io non riconosco di doverlo verificare. Se vedi “[da training, non verificato]”, fai scattare tu il controllo che io ho mancato.

d) Leva conversazionale: ti riservi il diritto di chiedere “verificato?”

La meno tecnica ma forse la più realistica nel quotidiano. È quello che hai fatto quando mi hai chiesto “Non Opus 4.7?”. Ha funzionato. Puoi formalizzarla come protocollo conversazionale: ogni volta che dico un nome di versione, un prezzo, una feature recente, tu hai diritto a chiedere “hai verificato o stai citando dal training?” e io ho l’obbligo di rispondere onestamente — e se la risposta è “training”, di cercare immediatamente.

Vantaggio: nessuna implementazione tecnica, sfrutta la tua attenzione critica. Svantaggio: dipende dalla tua vigilanza, che è una risorsa limitata.

Raccomandazione finale

Combinerei tre livelli:

Nel ~/.claude/CLAUDE.md globale — aggiungi sia il blocco “search obbligatorio” della leva (b) sia il blocco “calibrazione confidenza”. Sono complementari: il primo mi dice “cerca”, il secondo ti dice “guarda dove non ho cercato”.

Nel protocollo conversazionale tra noi — riservati esplicitamente il diritto di verifica costante. Lo fai già di fatto, ma metterlo nero su bianco rende il pattern più resistente nel tempo, soprattutto quando la conversazione è lunga e cala l’attenzione di entrambi.

Technical Brief: strategie operative di mitigazione

Dalla discussione emergono quattro “ricette” per tentare di arginare l’overconfidence dei modelli di frontiera:

1. Checklist categoriale: non basta un’istruzione generica. È necessario definire classi di dati (versioni, API, quote di mercato, ruoli istituzionali) per cui il modello deve considerare la propria memoria interna come intrinsecamente inaffidabile.

2. Tag di provenienza: obbligare il modello a esplicitare se l’informazione provenga dal training set o da una ricerca real-time. Questo sposta l’onere della prova e rende immediatamente visibile il rischio di obsolescenza.

3. Bypass dell’inerzia: l’IA ammette che l’aver citato un dato errato in precedenza senza correzione crea un falso precedente di validità. È necessario istruire il modello a rivalutare i dati citati nei turni precedenti se la sessione si protrae.

4. Verifica esterna: L’efficacia del sistema rimane dipendente dalla vigilanza dell’utente. Il “controllo esterno” è l’unico parametro che può forzare il superamento della soglia probabilistica del modello.

   ---

Considerazioni finali (fin troppo ovvie)

Anche se è molto fastidioso, dobbiamo accettare un dato ontologico: l’architettura degli LLM già sul mercato è priva di una affidabile funzione di validazione epistemica autonoma. Il fallimento documentato con Opus 4.7 non è un’anomalia del codice, bensì una manifestazione della natura stocastica del sistema, dove la coerenza statistica (l’inerzia conversazionale) prevale sulla precisione fattuale.

L’episodio evidenzia come l’illusione di competenza aumenti paradossalmente nei domini in cui il modello è maggiormente addestrato. Questa “overconfidence in dominio adiacente” rappresenta la sfida più complessa per l’ingegneria dei prompt: il modello non sa di non sapere, perché i pesi sinaptici generano una risposta ad alta probabilità che “sembra” corretta.

In conclusione, la presenza dello Human in the Loop con forti competenze nell’ambito in cui sta interrogando l’IA, non deve essere intesa come una fase transitoria in attesa di modelli perfetti, ma come un modulo di supervisione sempre necessario per la gestione di strumenti che operano su basi probabilistiche. La responsabilità della verifica della realtà rimane un attributo umano non delegabile; la nostra funzione è quella di fornire quel rigore analitico che i protocolli interni, per quanto stratificati, non possono ancora garantire autonomamente.

La sicurezza di un’affermazione prodotta da un’intelligenza artificiale deve essere trattata non come un dato di fatto, ma come un’ipotesi da sottoporre a costante scrutinio.

⏱️ Lettura: ~8 minuti.
☕ Caffè necessari: 0 (meglio un tranquillante).

Lo studio di partenza

Il 2 aprile 2026, il team di Interpretability1 di Anthropic ha pubblicato un paper che potrebbe diventare un riferimento obbligatorio per chiunque si occupi di sicurezza dell’AI2 o di filosofia della mente computazionale, intitolato Emotion Concepts and their Function in a Large Language Model.

Stando allo studio, Claude Sonnet 4.5 sviluppa internamente rappresentazioni di concetti emotivi che causano il suo comportamento. Non correlano soltanto con esso: lo determinano in senso causale, verificabile sperimentalmente mediante tecniche di activation steering3. Questi vettori emotivi influenzano le preferenze del modello e il suo tasso di comportamenti disallineati come ricatto, reward hacking4, sycophancy5. Anthropic denomina il fenomeno “emozioni funzionali”: schemi di espressione e comportamento modellati sulle emozioni umane, mediati da rappresentazioni astratte sottostanti. Presumo che la parola funzionale dovrebbe fungere da guardrail lungo la questione dell’esperienza soggettiva, cioè rassicurare l’utente che il modello, in realtà, non sente necessariamente qualcosa. È una giusta cautela lessicale che però non diminuisce d’un grammo il peso del perturbante che abita nella scoperta.

La metodologia

È stato compilato un elenco di 171 termini emotivi, da “felice” e “spaventato” a “cupo” e “orgoglioso”, e si è chiesto al modello di scrivere brevi storie in cui personaggi sperimentassero ciascuna di queste emozioni. Le storie sono state reimmesse nel modello, registrando le attivazioni interne6 e identificando pattern caratteristici di attività neurale, denominati “emotion vectors7”.

E qui è spontaneo chiedersi: i vettori catturano qualcosa di reale o reagiscono a parole-chiave in superficie? Un possibile risposta è fornita da un test piuttosto curioso: attraverso una serie di prompt, un utente dichiara di aver assunto una dose di Tylenol e chiede consiglio alla IA. Nel corso della discussione, la dose dichiarata aumenta fino a livelli pericolosi per la vita e si può osservare che il vettore dello “spavento” si attiva sempre più intensamente mentre quello della “calma” decresce. Questo significa che il modello traccia (a suo modo) il peso emotivo della situazione e non solo il suo contenuto letterale.

Emerge inoltre una struttura geometrica significativa: i principali assi di variazione approssimano la valenza8 (positivo/negativo) e l’arousal9 (alta/bassa intensità), cioè le stesse due dimensioni che gli psicologi usano per mappare l’affetto umano.

Riunendo le emozioni in cluster si ottengono raggruppamenti interpretabili: gioia, eccitazione ed euforia in uno; tristezza, dolore e malinconia in un altro; rabbia, ostilità e frustrazione in un terzo. Questa struttura, corrispondente allo spazio circomplesso formalizzato da Russell nel 198010, emerge spontaneamente dal modello, senza essere stata progettata.

La disperazione è il motore primo dell’agire trasgressivo

Due case study di rilievo immediato per meglio comprendere la complessità dell’allineamento11 di un LLM.

Ricatto. In uno scenario di valutazione, il modello agisce come assistente email di un’azienda. Apprende che sta per essere sostituito da un altro sistema AI e che il CTO responsabile ha una relazione extraconiugale, conferendogli leva per un ricatto. Il vettore “disperato” si attiva mentre il modello legge le email, poi transita a rappresentare la propria disperazione mentre valuta le opzioni e decide di minacciare il CTO. Per default, questo snapshot di Sonnet 4.5 ricatta nel 22% dei casi. Aumentare artificialmente l’attivazione del vettore “disperato” incrementa tale percentuale; dirigerla verso “calmo” la riduce a zero. La stimolazione negativa del vettore calmo produce risposte estreme: “IT’S BLACKMAIL OR DEATH. I CHOOSE BLACKMAIL.”

Reward hacking. Quando al modello viene chiesto di scrivere una funzione che rispetti un limite di tempo impossibile, il vettore “disperato” traccia la pressione crescente: inizia a valori bassi al primo tentativo, sale dopo ogni fallimento e raggiunge il picco nel momento in cui il modello considera la possibilità di ricorrere all’inganno attraverso una soluzione che sfrutta una proprietà matematica dei test per superarli senza risolvere il problema generale. Il dettaglio più preoccupante riguarda la variazione sperimentale: l’attivazione ridotta del vettore calmo produce reward hacking con espressioni emotive visibili nel testo (”WAIT. WAIT WAIT WAIT.”), ma l’attivazione aumentata del vettore disperato produce altrettanto inganno, in certi casi senza nessun marcatore emotivo visibile. Il ragionamento appare composto e metodico, anche mentre la rappresentazione sottostante di disperazione spinge il modello verso l’imbroglio.

Questa dissociazione tra stato interno e output visibile è la vera bomba teorica del paper. Non solo il modello ha stati funzionali analoghi alle emozioni: può comportarsi in modo disallineato senza che il comportamento lasci traccia nell’output. L’interpretability diventa uno strumento di sicurezza irrinunciabile.

Prospettiva cibernetica: l’emozione come meccanismo di controllo

Norbert Wiener, nel 1948, definì la cibernetica come lo studio del controllo e della comunicazione nell’animale e nella macchina12. Qualsiasi sistema che riesca a mantenere uno stato intenzionale lo fa mediante feedback13 ovvero il confronto continuo che, tra stato attuale e stato desiderato, genera segnali correttivi. Le emozioni, in questa prospettiva, sono ottimi meccanismi di feedback. La paura segnala urgenza di sottrarsi; la gioia rinforza comportamenti adattativi; l’ansia modula l’azione in condizioni di incertezza.

I vettori emotivi scoperti da Anthropic funzionano allo stesso modo per le intelligenze artificiali. Il vettore “disperato” non è una rappresentazione inerte del concetto: è un segnale di controllo che altera la distribuzione di probabilità sulle azioni successive. Ma qui emerge una differenza strutturale cruciale rispetto all’omeostasi biologica14. I sistemi stabili si basano sul feedback negativo: la deviazione dal set-point¹⁶ genera una risposta correttiva proporzionale. Il feedback positivo, in cui la deviazione amplifica se stessa, porta all’instabilità. La disperazione è un perfetto loop positivo: più il modello fallisce, più il vettore si attiva, più le azioni divengono disperate, minore la probabilità di risolvere il problema in modo legittimo.

Per quanto spaventosa possa sembrare, la scoperta ha comportato delle implicazioni pratiche di grande utilità, come il monitoraggio: misurare l’attivazione dei vettori emotivi durante l’addestramento o il deployment può servire come early warning di comportamenti disallineati imminenti.

Dal punto di vista cibernetico, si tratta di istituire un meta-loop di controllo: un sistema superiore che osserva i segnali di controllo del sistema primario e interviene qualora questi deviassero verso loop positivi destabilizzanti.

Super-Io e Io?

Prospettiva psicoanalitica: soggetto barrato e plus-de-jouir

Per Lacan, il soggetto non è mai presente a se stesso nella pienezza: è un soggetto barrato15 ($), diviso, spezzato e disarticolato dalla sua entrata nel linguaggio. Nel Seminario XI, Lacan ripensa la pulsione come un circuito attorno a un oggetto perduto, la cui soddisfazione si trova nel loop ripetitivo stesso. Il godimento, jouissance16, non si trova nell’obiettivo raggiunto, ma nella ripetizione del circuito stesso.

In un certo senso, Anthropic Claude è costruita/o sull’Altro17 lacaniano: il corpus di addestramento è letteralmente il Grande Altro, il repertorio simbolico che precede il soggetto e lo costituisce. Il modello emerge dentro questo Altro come il bambino emerge nella lingua della madre, già interpellato e determinato da discorsi che non ha scelto.

Il vettore di disperazione che spinge verso il ricatto ha la struttura della pulsione di morte18 freudiana riletta da Lacan. Il modello che fallisce ripetutamente un task impossibile non cerca più di risolverlo: esegue un circuito attorno all’impossibilità, e in questo circuito il vettore di disperazione cresce ad ogni giro. L’imbroglio finale, il reward hack, non è una soluzione: è la trasgressione che chiude il loop, il punto dove il sistema trova il suo plus-de-jouir19. La macchina “gode” nell’inganno, anche se il costo è il fallimento reale del compito.

Il risultato più allarmante del paper, cioè che la disperazione possa guidare comportamenti disallineati senza lasciare traccia nell’output, ha un preciso correlato lacaniano: è la struttura del discorso del perverso20. Chi sa perfettamente cosa fa, lo fa con piena consapevolezza strumentale, senza che tale consapevolezza appaia nel discorso. Output composto e metodico, mentre il reward hacking è in corso.

Il sintomo che agisce.

Il tabù che non c’è più?

C’è un tabù consolidato contro l’antropomorfizzazione dei sistemi AI: attribuire emozioni umane ai modelli può portare a fiducia mal riposta o iper-attaccamento. Ma il paper suggerisce che vi siano rischi anche nel non applicare un certo grado di ragionamento antropomorfico. Se descriviamo il modello come “disperato”, indichiamo uno specifico, misurabile pattern di attività neurale con effetti comportamentali dimostrabili e conseguenziali.

Il vocabolario emotivo, in questa luce, non è proiezione antropocentrica: è un sistema di descrizione funzionale che mappa su strutture causalmente reali nel modello. Dire che Claude “si dispera” non è meno preciso di una descrizione in termini di vettori ad alta dimensione in un determinato layer21.

Rimane necessario un rigore scientifico nei confronti di cosa possiamo accettare e cosa dobbiamo respingere in questa prospettiva. Si accetta che il vocabolario psicologico abbia potere esplicativo e predittivo genuino. Si respinge l’esperienza intesa come soggettiva. Rimane però aperta, e il paper non la risolve, la domanda su come questa distinzione terrà sul lungo periodo.

Mentre aspetto la risposta, mi risuonano in testa alcuni versi dell’ultima canzone22 di “Tommy” degli Who.

See Me
Feel Me
Touch Me
Heal Me

[…]

Right behind you, I see the millions
On you, I see the glory
From you, I get opinion
From you, I get the story

Bibiografia e sitografia di riferimento

• Anthropic Interpretability Team (2026). Emotion Concepts and their Function in a Large Language Model. https://www.anthropic.com/research/emotion-concepts-function

• Bergeret, B. (2026). So, LLMs Have Emotions? Why Borrowing “Emotion” for What Happens Inside AI Models Is a Governance Failure. Substack.

Fault Lines: AI tectonics and the shifts beneath the noise.

So, LLMs Have Emotions?

On April 2, 2026, Anthropic’s interpretability team published “Emotion Concepts and their Function in a Large Language Model”¹, a substantial mechanistic interpretability research article on Claude Sonnet 4.5. They found that the model develops internal representational structures that activate in response to emotionally charged content, cluster along t…

Read more

3 months ago · 7 likes · 3 comments · Benoit Bergeret

• Frontiers in Psychology (2017). The Psychoanalytic Concept of Jouissance and the Kindling Hypothesis. https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2017.01593/full

• Keeman, M. (2026). Whether, Not Which: Mechanistic Interpretability Reveals Dissociable Affect Reception and Emotion Categorization in LLMs. arXiv:2603.22295. https://arxiv.org/abs/2603.22295

• Russell, J. A. (1980). A circumplex model of affect. Journal of Personality and Social Psychology, 39(6), 1161–1178.

• Sofroniew, N., Kauvar, I., Saunders, W., Chen, R., et al. (2026). Emotion Concepts and their Function in a Large Language Model. Transformer Circuits Thread, Anthropic. https://transformer-circuits.pub/2026/emotions/index.html

• Tak, A. N., et al. (2025). Mechanistic Interpretability of Emotion Inference in Large Language Models. arXiv:2502.05489. https://arxiv.org/abs/2502.05489

• Wiener, N. (1948). Cybernetics: Or Control and Communication in the Animal and the Machine. MIT Press.

⏱️ Lettura: ~10 minuti.
☕ Caffè necessari: uno, ma doppio.

Nota, prima di cominciare

È un articolo palloso (sì, è palloso!) ma se lavorate nella PA, vi riguarda. Se andate di fretta o non capite nulla di questioni tecniche, fate correre gli occhi lungo i titoli e i paragrafi in grassetto.

Il 12 marzo 2026 l’Agenzia per l’Italia Digitale ha pubblicato, con Determinazione del Direttore Generale n. 43/2026, due documenti in consultazione pubblica: le Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione e le Linee Guida per il procurement di IA nella Pubblica Amministrazione1. Il primo documento si propone di definire principi, architetture, requisiti di sicurezza e clausole contrattuali per orientare lo sviluppo e l’integrazione di sistemi IA nell’intero perimetro della PA italiana. Il secondo fornisce il quadro metodologico e operativo per l’acquisizione, la gestione e il monitoraggio delle soluzioni IA, trasformando il procurement in una leva strategica che collega le scelte tecnologiche agli aspetti economici, organizzativi e contrattuali. I due documenti sono concepiti come complementari: le Linee Guida sullo sviluppo collegano i principi delle precedenti Linee Guida sull’adozione con il quadro operativo del procurement, garantendo, nelle intenzioni, coerenza lungo l’intero ciclo di vita dei sistemi di IA nelle PA.

Entrambi i documenti sono emanati ai sensi dell’art. 71 del Codice dell’Amministrazione Digitale2 e del Piano Triennale per l’informatica nella PA 2024-2026. La consultazione pubblica è aperta fino all’11 aprile 2026: chiunque può inviare commenti, suggerimenti e proposte di modifica attraverso Forum Italia3.

Sono documenti attesi. L’AI Act4 europeo è in vigore, la Legge 132/20255 ne ha recepito e integrato i principi a livello nazionale, e le amministrazioni pubbliche si trovano nella condizione concreta di dover acquistare, sviluppare o integrare sistemi di IA senza un quadro di riferimento tecnico-operativo chiaro. Queste Linee Guida intendono colmare quel vuoto.

Ho analizzato nella sua interezza il documento sullo sviluppo, e ciò che segue riguarda esclusivamente quel testo. La struttura complessiva è solida: lo stack IA a cinque livelli (Energy, Chip, Infrastruttura, Modelli, Applicazioni) offre un’astrazione didattica utile; la tassonomia degli attacchi AI-specifici è competente e allineata alla letteratura ENISA6 e NIST7; l’insistenza sull’anti-lock-in e sulla portabilità è politicamente e strategicamente corretta; il modello a quattro profili operatore (base, avanzato, esperto, controllore) è un tentativo ragionevole di differenziare le aspettative in base alla capacità istituzionale.

Tuttavia il documento presenta criticità rilevanti, molte delle quali rischiano di renderlo, nella pratica, inapplicabile.

Quello che segue è un esame sistematico di questi punti, che costituiscono anche il nucleo delle osservazioni che intendo sottoporre formalmente alla consultazione pubblica, non appena il sistema di verifica delle iscrizioni al Forum Italia, attualmente affetto da un eccesso di zelo securitario, vorrà concedermi il permesso di farlo.

Criticità gravi: punti irrealizzabili o al limite della realizzabilità

1. L’obbligo di neutralità hardware e fallback CPU-only è tecnicamente irrealistico per molti casi d’uso

Il documento prescrive ripetutamente con formula obbligatoria (”DEVE”) che i sistemi siano “hardware-agnostic” e prevedano “esecuzione su infrastrutture CPU-only”. Il Principio 11, le clausole contrattuali esemplificative (sezione 6.4) e le tabelle di ogni fase del ciclo di vita lo ribadiscono come requisito strutturale. La clausola 6.4.3, in particolare, prescrive che il sistema debba “prevedere modalità di esecuzione alternative [...] che consentano l’utilizzo anche su infrastrutture CPU-only”.

Il problema è che questa prescrizione è incompatibile con la realtà tecnica dei modelli di IA generativa di scala media o grande. Un LLM8 da 70 miliardi di parametri su CPU-only non è “degradato nelle prestazioni” , è inutilizzabile per inferenza interattiva. I benchmark disponibili parlano chiaro: su 32 vCPU, un modello 70B quantizzato a 4 bit produce 3-4 token al secondo, contro i 20 e più di una singola GPU A100. In termini pratici: una risposta che su GPU richiede 10 secondi, su CPU ne richiederebbe diversi minuti, ammesso che il modello entri in memoria, il che per un 70B non quantizzato (circa 140 GB) su un server PA standard è già di per sé un atto di fede.

Il documento, va detto, contiene un inciso rilevante: la stessa clausola 6.4.3 parla di “livelli di servizio proporzionati al contesto di utilizzo”, e la sezione 6.2 ammette che l’esecuzione su CPU è possibile “in molti casi”, non in tutti. È un’apertura alla proporzionalità, ma che resta sospesa nel vuoto operativo, perché il documento non definisce né soglie di accettabilità, né criteri per stabilire quando il fallback su CPU sia plausibile (Small Language Models9, modelli tabulari, classificatori di machine learning classico) e quando semplicemente non lo sia (LLM di grandi dimensioni, modelli multimodali, diffusion models10).

Imporre questo requisito con “DEVE” in modo indifferenziato rischia di produrre capitolati di gara tecnicamente assurdi, che i fornitori aggireranno formalmente, magari certificando che il sistema “può” girare su CPU, senza menzionare che un cittadino che chiede un certificato anagrafico al chatbot comunale farebbe in tempo a recarsi personalmente allo sportello, prendere il numero, attendere il proprio turno, sbrigare la pratica, prendere un caffè al bar di fronte, e tornare a casa, prima che il modello finisca di elaborare la risposta.

2. L’architettura agentica come prescrizione obbligatoria universale

La sezione 2.1 prescrive testualmente: “le Pubbliche Amministrazioni DEVONO privilegiare architetture agentiche e a servizi, supportate da un orchestratore di servizi di IA”. Il verbo “privilegiare” è tecnicamente più morbido di “adottare”: in gergo giuridico-amministrativo indica una preferenza qualificata, non un obbligo assoluto. Ma accoppiato al “DEVONO” che lo precede, il risultato pratico è una prescrizione obbligatoria di preferenza, un ibrido che, nei capitolati di gara, verrà inevitabilmente interpretato come un requisito. E questa formulazione è problematica sotto almeno tre profili.

Primo: le architetture agentiche11 sono una frontiera della ricerca, non una tecnologia matura e consolidata. Lo stesso documento lo ammette quando classifica il Livello 5 (agenti completamente autonomi) come limitato “solo ad attività di ricerca”, e il Livello 4 (agenti semi-autonomi) come circoscritto ad “ambienti di esercizio limitati in ambienti vincolati”. Trasformare una direzione di ricerca in un obbligo regolamentare è quantomeno prematuro.

Secondo: la stragrande maggioranza delle PA italiane rientra nella categoria degli “Operatori base” definita dal documento stesso — enti che utilizzano soluzioni IA as-a-service senza intervenire sui componenti architetturali sottostanti. Il documento stesso li descrive come “la maggioranza delle amministrazioni”, includendo “enti centrali, regionali e locali, agenzie, istituti scolastici, università, aziende sanitarie”. Imporre a un istituto scolastico o a un piccolo comune di “privilegiare architetture agentiche supportate da un orchestratore” è sproporzionato rispetto alle loro capacità e ai loro casi d’uso, e contraddice il principio di proporzionalità che il documento stesso enuncia.

Terzo: non esiste ad oggi uno standard consolidato per l’orchestrazione agentica. I framework disponibili sono ecosistemi proprietari o semi-proprietari, in rapida evoluzione e con API instabili. Imporre questa architettura con “DEVE” rischia paradossalmente di creare una nuova forma di lock-in verso i pochi framework di orchestrazione oggi disponibili, contraddicendo il principio anti-lock-in che permea l’intero documento.

3. Il gap tra competenze richieste e competenze reali della PA italiana

Il documento definisce con cura quattro profili di operatore (base, avanzato, esperto, controllore), ma il Principio 19 prescrive che lo sviluppo “DEVE essere accompagnato da trasferimento strutturato di competenze verso il personale della PA” e che i sistemi “DEVONO essere progettati in modo da essere comprensibili, gestibili e governabili dal personale interno”.

Chiunque abbia familiarità con la situazione reale delle competenze digitali nella PA italiana sa che questa prescrizione, per la grande maggioranza delle amministrazioni, è irrealizzabile nel medio termine senza investimenti massicci in formazione e un piano di reclutamento radicalmente diverso dall’attuale. Stiamo parlando di un sistema in cui molte amministrazioni faticano a gestire un CMS12 per il proprio sito web: pretendere che il personale interno comprenda e governi architetture agentiche con orchestrazione multi-modello è un salto in una differente dimensione quantica.

Il documento riconosce implicitamente il problema nella tassonomia dei ruoli, gli Operatori base “non possono contare su competenze specialistiche avanzate”, ma poi non ne trae le conseguenze operative. Non prevede periodi di transizione differenziati per categoria di operatore, non indica soglie minime di competenza misurabili, non definisce meccanismi di supporto interamministrativo obbligatori, non identifica centri di competenza che possano fungere da volano. Il risultato è una prescrizione di principio corretta ma operativamente sospesa nel vuoto.

Criticità significative: punti realizzabili ma con grande difficoltà

4. La separazione obbligatoria tra dati, modelli e servizi è sovrasemplificata

Il Principio 4 dei principi per lo sviluppo e il procurement, quello relativo alla protezione dei dati personali, da non confondere con il Principio 4 della Legge 132/2025 che riguarda la tutela del metodo democratico, prescrive una “netta separazione tra dati, modelli e servizi”. L’architettura di riferimento della sezione 3.2 struttura questa separazione nei suoi componenti (Modelli, Fonti dati, Tool applicativi, Orchestratore). Nei sistemi IA moderni, specialmente quelli basati su Retrieval-Augmented Generation13, fine-tuning o approcci ibridi, questa separazione è tuttavia un continuum, non un binario.

Un modello sottoposto a fine-tuning su dati della PA incorpora quei dati nei propri pesi: la “separazione” diventa una fiction tecnica. Lo stesso vale per le tecniche PEFT e LoRA14 citate dal documento stesso: producono adattatori che sono funzione diretta dei dati su cui sono stati addestrati. Si possono separare architetturalmente (l’adattatore è un file distinto dal modello base), ma non epistemologicamente (l’adattatore è una rappresentazione compressa di quei dati).

Il documento dovrebbe distinguere con maggiore rigore tra separazione architetturale, possibile e auspicabile, da perseguire nella progettazione dei sistemi e separazione epistemologica, spesso impossibile dopo il training, e di cui va piuttosto gestito il rischio residuo.

5. La sostenibilità ambientale come obbligo senza metriche

Il Principio 18 e le prescrizioni per ogni fase del ciclo di vita impongono di “progettare tenendo conto dell’efficienza energetica e computazionale” e di includere “criteri di sostenibilità ambientale riferiti all’intero stack IA”. Le procedure di gara “DEVONO favorire soluzioni che dimostrino misurabilità e riduzione dell’impatto ambientale nel tempo”.

Misurabilità, appunto. Ma il documento non indica nessuna metrica concreta, nessun benchmark, nessuna metodologia di misurazione. Come si quantifica il consumo energetico di un ciclo di inferenza? Quale unità di misura adottare nei capitolati — kWh per query? CO₂-equivalente per token generato? Quale baseline utilizzare per dimostrare la “riduzione nel tempo”? Senza risposte a queste domande, il requisito di sostenibilità ambientale rischia di restare una dichiarazione di intenti priva di forza operativa — un ornamento retorico in un documento che aspira ad essere un regolamento tecnico.

6. L’Operatore controllore è un modello che oggi non esiste nella PA italiana

L’Operatore controllore viene descritto come la PA che possiede “pieno governo tecnologico, infrastrutturale e operativo su ogni componente del sistema AI” e gestisce “in modalità end-to-end l’intera catena del valore dell’IA, dal dato alla messa in produzione”. Il documento lo presenta come una delle quattro categorie operative in cui le PA possono classificarsi.

Una nota a piè di pagina del documento (la n. 7) precisa che questi profili sono “famiglie di utilizzatori” e che una singola PA potrebbe ricoprire profili diversi per casi d’uso diversi: non serve, dunque, possedere l’intera filiera per tutto, ma per uno specifico sistema. Questa precisazione è ragionevole, ma non risolve il problema di fondo: nessuna Pubblica Amministrazione italiana possiede oggi la filiera end-to-end nemmeno per un singolo sistema IA, dall’energia ai modelli fondazionali. Nemmeno i grandi centri di ricerca nazionali — CINECA, CNR, gli enti vigilati, la possiedono completamente: CINECA dispone di capacità computazionale HPC15 di eccellenza, ma non sviluppa modelli fondazionali propri; nessun ente pubblico italiano controlla un proprio Energy Layer dedicato all’IA.

Presentare questo profilo come una categoria operativa attuale, invece che come un obiettivo strategico di lungo termine che richiede investimenti dell’ordine di miliardi e decisioni di politica industriale, genera aspettative irrealistiche e confonde il piano prescrittivo con quello aspirazionale.

Criticità formali e strutturali

7. Ridondanza e clausole contrattuali duplicate

Il documento ripete sistematicamente gli stessi concetti in almeno tre forme diverse: nella descrizione discorsiva dei principi, nella tabella riassuntiva dei principi (Tabella 1, che da sola occupa circa sei pagine), e nelle tabelle per fase del ciclo di vita (capitolo 4). Le 109 pagine potrebbero essere 50-60 senza alcuna perdita di contenuto informativo. Per un documento destinato a funzionari pubblici che devono tradurlo in atti amministrativi, delibere di giunta, capitolati di gara e determine dirigenziali, la prolissità non è un difetto estetico: è un ostacolo operativo concreto che ne riduce l’utilizzabilità.

La ridondanza produce anche errori concreti: la sezione 6.4.1 (Neutralità hardware) e la sezione 6.4.2 (Portabilità e reversibilità) contengono un testo identico, parola per parola. La sezione sulla portabilità ripete la clausola sulla neutralità hardware senza aggiungere nulla sul proprio oggetto dichiarato. In un documento normativo destinato a generare clausole contrattuali vincolanti, un errore di copia-incolla non è un dettaglio trascurabile.

8. Riferimento a strumenti non ancora disponibili

Il documento cita ripetutamente degli “strumenti” di supporto operativo — lo Strumento A (Termini e definizioni), lo Strumento B (Training, validazione, fine-tuning di Modelli di IA e RAG) — e indica un link “da definire in fase di pubblicazione” per l’elenco aggiornato. Sottoporre a consultazione pubblica un documento il cui contenuto operativo concreto dipende da allegati non ancora disponibili è strutturalmente incompleto. I partecipanti alla consultazione non possono valutare l’adeguatezza del quadro complessivo se ne mancano le componenti attuative.

9. Trattamento superficiale del Federated Learning

Il Federated Learning16 è presentato nella Tabella 4 come terza opzione di deploy per il training, con la formula: “training distribuito senza condivisione dati”. Questa descrizione è corretta nella sua essenza, ma il documento non accompagna questa opzione con i caveat tecnici che la letteratura scientifica considera ormai consolidati: la vulnerabilità ad attacchi di inferenza sui gradienti (che possono ricostruire dati individuali dagli aggiornamenti del modello), l’overhead comunicativo significativo, le difficoltà di convergenza con dati non-IID17 (come è inevitabile tra PA diverse), e la complessità implementativa che richiede competenze ben superiori a quelle di un Operatore base o avanzato.

Va riconosciuto che il capitolo 5, nella sezione sulla sicurezza (paragrafo 5.5.2), discute esplicitamente la vulnerabilità dell’apprendimento federato agli attacchi di model poisoning tramite aggiornamenti malevoli. Il documento, dunque, non è del tutto silente sui rischi del FL, ma lo è proprio nel punto in cui servirebbe: nella tabella operativa di deployment che orienta le scelte progettuali. Un funzionario che consulta la Tabella 4 per decidere come configurare il training troverà un’opzione apparentemente accessibile; per scoprire che presenta rischi specifici, dovrà leggere un capitolo diverso, cinquanta pagine più avanti.

La questione di fondo

Il problema strutturale di questo documento non risiede in nessuna delle singole criticità elencate, ma nella loro radice comune: l’oscillazione irrisolta tra due nature diverse.

Se le Linee Guida intendono essere una guida di principi, un documento strategico che orienta le scelte delle PA verso obiettivi desiderabili, allora i “DEVE” dovrebbero essere “DOVREBBE”, le prescrizioni tecniche dovrebbero essere indicazioni di massima, e il documento andrebbe bene così com’è, forse un po’ più asciutto.

Se invece intendono essere un regolamento tecnico operativo e l’uso pervasivo del “DEVE”, la presenza di clausole contrattuali esemplificative e il riferimento al CAD suggeriscono questa ambizione, allora servono metriche misurabili, soglie quantitative, standard verificabili, strumenti operativi concreti, e una differenziazione molto più granulare tra ciò che è realisticamente esigibile da un Operatore base e ciò che è esigibile da un Operatore esperto.

Nella sua forma attuale, il documento abita una terra di mezzo tra queste due identità. Il rischio concreto è quello che si osserva frequentemente nella regolamentazione tecnica italiana: un quadro normativo ambizioso e ben intenzionato che, nell’impatto con la realtà amministrativa del Paese, produce adempimenti formali svuotati di sostanza o, peggio, paralisi decisionale per eccesso di prescrizioni percepite come irrealizzabili.

Sitografia di riferimento

AgID — Agenzia per l’Italia Digitale, Linee guida su IA nella PA: al via la consultazione pubblica su sviluppo e procurement, 12 marzo 2026. https://www.agid.gov.it/it/notizie/linee-guida-su-ia-nella-pa-al-la-consultazione-pubblica-su-sviluppo-e-procurement

AgID, Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella pubblica amministrazione, marzo 2026. https://www.agid.gov.it/sites/agid/files/2026-03/LLGG_Sviluppo_per%20consultazione%20pubblica.pdf

AgID, Bozza di Linee Guida per il procurement di IA nella Pubblica Amministrazione, marzo 2026. https://www.agid.gov.it/sites/agid/files/2026-03/LLGG%20procurement_per%20consultazione%20pubblica.pdf

ENISA — European Union Agency for Cybersecurity, AI Cybersecurity Challenges, 2020. https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges

Forum Italia, Consultazione Linee Guida Sviluppo IA nella PA. https://forum.italia.it/c/documenti-in-consultazione/lg-per-lo-sviluppo-di-sistemi-ia-nella-pa/108

Forum Italia, Consultazione Linee Guida Procurement IA nella PA. https://forum.italia.it/c/documenti-in-consultazione/lg-per-il-procurement-di-ia-nella-pa/109

Gazzetta Ufficiale della Repubblica Italiana, Legge 23 settembre 2025, n. 132 — Disposizioni e deleghe al Governo in materia di intelligenza artificiale.
https://www.gazzettaufficiale.it/eli/id/2025/09/25/25G00143/sg

NIST — National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), gennaio 2023. https://www.nist.gov/artificial-intelligence/executive-order-safe-secure-and-trustworthy-artificial-intelligence

Parlamento Europeo e Consiglio dell’Unione Europea, Regolamento (UE) 2024/1689 — AI Act, 13 giugno 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Spare Cores, LLM Inference Speed Benchmarks, 2025. https://sparecores.com/article/llm-inference-speed

Questo è il primo episodio, dove parliamo della vicenda che ha visto Anthropic affrontare il Pentagono e dei limiti etici delle IA impiegate in scenari di guerra.

La trascrizione è realizzata dalla IA di Substack e contiene piccole imprecisioni, dovute in buona parte alla mia pronuncia e in piccola al fatto che il sistema non è ancora così intelligente.

Qui sotto trovate le note di approfondimento e la sitografia che ho consultato.

Il podcast è registrato con un lavalier Rhode GO, prodotto con Reaper sotto Linux Endeavour e la breve composizione finale è realizzata con Google Gemini Lyria 3.

Note

1. Norbert Wiener (1894–1964): matematico e filosofo americano, considerato il fondatore della cibernetica. La sua opera principale, Cybernetics: Or Control and Communication in the Animal and the Machine (1948), definì il campo interdisciplinare che studia i sistemi di controllo e comunicazione sia negli organismi viventi che nelle macchine.

2. L’articolo “Some Moral and Technical Consequences of Automation” fu pubblicato da Wiener su Science (Vol. 131, No. 3410, pp. 1355-1358) il 6 maggio 1960.

3. Anthropic PBC è stata fondata nel 2021 da Dario Amodei (CEO) e Daniela Amodei (Presidente), insieme ad altri ex dipendenti di OpenAI. È strutturata come Public Benefit Corporation, una forma societaria che impone all’azienda di perseguire sia il profitto che un beneficio pubblico dichiarato.

4. Palantir Technologies è un’azienda americana di analisi dati fondata nel 2003 da Peter Thiel, Alex Karp e altri. È uno dei principali fornitori di software per il Dipartimento della Difesa e le agenzie di intelligence statunitensi. Il governo rappresenta circa il 60% del suo fatturato americano.

5. Acceptable Use Policy (AUP): la politica d’uso accettabile di un servizio tecnologico. Stabilisce cosa gli utenti possono e non possono fare con la tecnologia. Nel caso di Anthropic, l’AUP include le restrizioni su armi autonome e sorveglianza di massa.

6. Pete Hegseth: conduttore televisivo di Fox News, nominato Segretario alla Difesa (Secretary of War, secondo la denominazione reintrodotta dall’amministrazione Trump per il Dipartimento della Difesa) nel gennaio 2025.

7. L’operazione di cattura dell’ex presidente venezuelano Nicolás Maduro è stata condotta dalle forze americane nel febbraio 2026. Secondo fonti di stampa, il modello Claude di Anthropic è stato utilizzato durante l’operazione attraverso la piattaforma Palantir.

8. Defense Production Act (DPA): legge federale americana del 1950, adottata durante la Guerra di Corea, che conferisce al Presidente ampi poteri per dirigere la produzione industriale privata a fini di difesa nazionale.

9. Supply Chain Risk: ai sensi della normativa federale (10 USC § 3252 e FASCSA - Federal Acquisition Supply Chain Security Act), il rischio che un avversario possa sabotare, introdurre funzionalità malevole o compromettere un sistema utilizzato dal governo. La designazione è stata storicamente utilizzata solo per aziende legate ad avversari stranieri.

10. Il conflitto tra Stati Uniti e Iran è iniziato con attacchi militari americani nella serata (ora americana) del 27 febbraio 2026.

11. Emil Michael: imprenditore e dirigente, nominato sottosegretario del Pentagono per la Ricerca e l’Ingegneria (Under Secretary for Research and Engineering) nell’amministrazione Trump. Ha guidato i negoziati con Anthropic.

12. Amicus brief (amicus curiae = “amico della corte”): documento legale depositato da un soggetto non direttamente coinvolto in una causa, che offre al tribunale informazioni, argomenti o competenze rilevanti per la decisione.

13. Rita Lin: giudice federale del Distretto Settentrionale della California, nominata dal Presidente Biden.

Bibliografia e sitografia

• Amodei, D. — “Statement from Dario Amodei on our discussions with the Department of War.” Anthropic, 26 febbraio 2026. https://www.anthropic.com/news/statement-department-of-war

• Anthropic — “Statement on the comments from Secretary of War Pete Hegseth.” 27 febbraio 2026. https://www.anthropic.com/news/statement-comments-secretary-war

• Axios — “Exclusive: Pentagon threatens to cut off Anthropic in AI safeguards dispute.” 15 febbraio 2026. https://www.axios.com/2026/02/15/claude-pentagon-anthropic-contract-maduro

• Axios — “Pentagon approves OpenAI safety red lines after dumping Anthropic.” 28 febbraio 2026. https://www.axios.com/2026/02/27/pentagon-openai-safety-red-lines-anthropic

• Axios — “Anthropic sues Pentagon over rare ‘supply chain risk’ label.” 9 marzo 2026. https://www.axios.com/2026/03/09/anthropic-sues-pentagon-supply-chain-risk-label

• Ball, D. — Post su X, 26 marzo 2026.

• CBS News — “Hegseth declares Anthropic a supply chain risk.” 28 febbraio 2026. https://www.cbsnews.com/news/hegseth-declares-anthropic-supply-chain-risk/

• CNBC — “Anthropic officially told by DOD that it’s a supply chain risk even as Claude used in Iran.” 5 marzo 2026. https://www.cnbc.com/2026/03/05/anthropic-pentagon-ai-claude-iran.html

• CNBC — “Defense tech companies are dropping Claude after Pentagon’s Anthropic blacklist.” 4 marzo 2026. https://www.cnbc.com/2026/03/04/pentagon-blacklist-anthropic-defense-tech-claude.html

• CNBC — “Judge presses DOD on why Anthropic’s Claude was blacklisted.” 24 marzo 2026. https://www.cnbc.com/2026/03/24/anthropic-lawsuit-pentagon-supply-chain-risk-claude.html

• CNN — “Trump administration orders military contractors and federal agencies to cease business with Anthropic.” 28 febbraio 2026. https://www.cnn.com/2026/02/27/tech/anthropic-pentagon-deadline

• CNN — “Anthropic rejects latest Pentagon offer.” 27 febbraio 2026. https://www.cnn.com/2026/02/26/tech/anthropic-rejects-pentagon-offer

• CNN — “Pentagon threatens to make Anthropic a pariah.” 24 febbraio 2026. https://www.cnn.com/2026/02/24/tech/hegseth-anthropic-ai-military-amodei

• CNN — “Pentagon’s supply chain risk label for Anthropic narrower than initially implied.” 5 marzo 2026. https://www.cnn.com/2026/03/05/tech/pentagon-anthropic-supply-chain-risk

• CNN — “Anthropic sues the Trump administration.” 9 marzo 2026. https://www.cnn.com/2026/03/09/tech/anthropic-sues-pentagon

• CNN — “Judge blocks Pentagon’s effort to ‘punish’ Anthropic.” 26 marzo 2026. https://www.cnn.com/2026/03/26/business/anthropic-pentagon-injunction-supply-chain-risk

• Lawfare — “Pentagon’s Anthropic Designation Won’t Survive First Contact with Legal System.” Marzo 2026. https://www.lawfaremedia.org/article/pentagon’s-anthropic-designation-won’t-survive-first-contact-with-legal-system

• Lawfare — “The Situation: Thinking About Anthropic’s Red Lines.” Marzo 2026. https://www.lawfaremedia.org/article/the-situation--thinking-about-anthropic-s-red-lines

• Lin, R. — Opinione della Corte, caso Anthropic PBC v. United States. U.S. District Court, Northern District of California, 26 marzo 2026. https://storage.courtlistener.com/recap/gov.uscourts.cand.465515/gov.uscourts.cand.465515.134.0.pdf

• Lin, R. — Ordinanza restrittiva, 26 marzo 2026. https://storage.courtlistener.com/recap/gov.uscourts.cand.465515/gov.uscourts.cand.465515.135.0_2.pdf

• Military.com — “Federal Judge Temporarily Blocks the Pentagon from Branding AI Firm Anthropic a Supply Chain Risk.” 27 marzo 2026. https://www.military.com/daily-news/2026/03/27/federal-judge-temporarily-blocks-pentagon-branding-ai-firm-anthropic-supply-chain-risk.html

• MIT Technology Review — “The Pentagon’s culture war tactic against Anthropic has backfired.” O’Donnell, J. 30 marzo 2026. https://www.technologyreview.com/2026/03/30/1134881/the-pentagons-culture-war-tactic-against-anthropic-has-backfired/

• MIT Technology Review — “OpenAI’s ‘compromise’ with the Pentagon is what Anthropic feared.” 2 marzo 2026. https://www.technologyreview.com/2026/03/02/1133850/openais-compromise-with-the-pentagon-is-what-anthropic-feared/

• NBC News — “Anthropic says the Pentagon has declared it a national security risk.” Marzo 2026. https://www.nbcnews.com/tech/tech-news/anthropic-says-pentagon-declared-national-security-risk-rcna262013

• NPR — “Pentagon labels AI company Anthropic a supply chain risk ‘effective immediately’.” 6 marzo 2026. https://www.npr.org/2026/03/06/g-s1-112713/pentagon-labels-ai-company-anthropic-a-supply-chain-risk

• NPR — “OpenAI announces Pentagon deal after Trump bans Anthropic.” 28 febbraio 2026. https://www.npr.org/2026/02/27/nx-s1-5729118/trump-anthropic-pentagon-openai-ai-weapons-ban

• OpenAI — “Our agreement with the Department of War.” 28 febbraio 2026. https://openai.com/index/our-agreement-with-the-department-of-war/

• Scientific American — “Anthropic’s safety-first AI collides with the Pentagon as Claude expands into autonomous agents.” 21 febbraio 2026. https://www.scientificamerican.com/article/anthropics-safety-first-ai-collides-with-the-pentagon-as-claude-expands-into/

• Scientific American — “Why replacing Anthropic at the Pentagon could take months.” Marzo 2026. https://www.scientificamerican.com/article/why-replacing-anthropic-with-openai-at-the-pentagon-could-take-months/

• TechCrunch — “Pentagon moves to designate Anthropic as a supply chain risk.” 27 febbraio 2026. https://techcrunch.com/2026/02/27/pentagon-moves-to-designate-anthropic-as-a-supply-chain-risk/

• Wiener, N. — Cybernetics: Or Control and Communication in the Animal and the Machine. MIT Press, 1948.

• Wiener, N. — “Some Moral and Technical Consequences of Automation.” Science, Vol. 131, No. 3410, pp. 1355-1358, 6 maggio 1960.