# Irene Burresi - Full Content Export > Blog tecnico su AI Engineering, architetture RAG, ricerca scientifica, economia e governance dell'intelligenza artificiale. Generated: 2026-01-14T10:04:38.354Z Total articles: 15 --- ## The AI Act Is Not (Just) Compliance: It's Industrial Policy - URL: https://ireneburresi.dev/blog/ai-act-geopen/ - Pillar: Governance - Published: 2026-01-06 - Updated: 2026-01-06 - Tags: AI Act, Brussels Effect, Geopolitics, Industrial Policy, Strategic Compliance - Author: Irene Burresi > 74% of EU listed companies use American email providers. 89% of German enterprises consider themselves technologically dependent. The AI Act should be read through this lens—as a competitive lever, not a checklist. ## The Only Lever Left *74% of companies listed in Europe use American email providers. 89% of German enterprises consider themselves technologically dependent on foreign providers. The AI Act exists in this context. Reading it only as a compliance problem means missing the picture.* **TL;DR:** The AI Act is industrial policy. Europe is in structural technological dependence and regulation is the only lever where it still has global weight. The "Brussels Effect" (ability to export standards) is contested but likely for high-risk AI systems. In November 2025 the Digital Omnibus delayed implementation by 16 months, but the direction remains the same. Those reading the AI Act only as a regulatory checklist are looking at the tree and missing the forest. --- The numbers on Europe's technological position are known to insiders. They rarely enter the AI Act debate. A [Proton report from October 2025](https://techreport.com/news/europe-digital-dependence-risks-of-heavy-reliance-on-us-tech/) analyzed DNS records of European listed companies: **74%** use American email providers. Not startups: companies listed on stock exchanges, with governance and security obligations. A [Bitkom survey](https://www.idt.media/metaverse/cloud-ai-co-europe-wants-to-break-free-from-dependence/2130935) of German companies with over 20 employees reveals that 89% consider themselves technologically dependent on foreign providers. The [EPRS report from the European Parliament](https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf) completes the picture. Of the 100 largest global digital platforms by market cap, only **2%** of the combined value is European. In cloud computing, hyperscalers, foundation AI models, Europe is a net importer. This context changes how you read the AI Act. It's not just about protecting European citizens from algorithms. It's about using the only lever Europe has left to negotiate its position in a market dominated by others. --- ## The Mechanism The term "Brussels Effect" was coined by [Anu Bradford](https://www.brusselseffect.com/) in 2012 and developed in her 2020 book. The thesis is direct: the EU, thanks to its market size and institutional quality, manages to export its standards globally. The mechanism works two ways. The **de facto effect**: companies wanting access to the European market adopt EU standards elsewhere, because maintaining two versions costs more than one. The **de jure effect**: other governments copy European rules because they work and reduce the cost of designing regulation from scratch. GDPR is the canonical example. Privacy laws inspired by European regulation have been adopted in Brazil, Japan, California. Tech companies extended many GDPR protections to non-European users to simplify operations. The form of European regulation spread beyond the Union's borders. On the AI Act, academic literature is more nuanced. A [2022 GovAI paper](https://arxiv.org/abs/2208.12645) analyzed the conditions for Brussels Effect applied to artificial intelligence. The conclusion: de facto and de jure effects are **likely**, especially for high-risk systems from large American tech companies. Microsoft, Google, Meta operate in Europe with recruiting, credit, and content moderation systems. They'll need to comply. And for many of these companies, it's more economical to apply one global standard than to segment products by market. The paper also identifies limits. The Brussels Effect works best when the EU market is unavoidable (it is for big tech), when regulation is perceived as high-quality (contested), and when credible alternatives don't exist (China offers a different model). For low-risk AI systems or companies not operating in Europe, the effect will be smaller or absent. An [article on Policy Review](https://policyreview.info/articles/analysis/brussels-effect-or-experimentalism) proposes a complementary frame: the AI Act as "experimentalist governance". Not a model to export wholesale, but one approach among many in a context of technological uncertainty. Interaction with other regulatory models (United States, United Kingdom, China) will be more cooperative and less unidirectional than the Brussels Effect frame suggests. The synthesis: the Brussels Effect on AI exists but is contested and uncertain. It's not guaranteed that European rules become global standard. It's not guaranteed they remain irrelevant. The game is open. --- ## The Tactical Adjustment In November 2025, the European Commission proposed the [Digital Omnibus](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-ai-regulation-proposal). The package includes AI Act modifications that generated headlines about "Europe backing down". The facts: requirements for high-risk AI systems now apply later, about 16 months later. The new deadline is December 2027 for Annex III systems (recruiting, credit, healthcare), August 2028 for those embedded in regulated products. It's a significant delay. But the AI Act's structure remains intact. Risk categories remain the same. Obligations remain the same. What changes is the calendar, not the destination. The Digital Omnibus is a tactical adjustment, not a strategic reversal. Europe is calibrating timing, not abandoning direction. Those reading the delay as "backing down" are confusing speed with trajectory. --- ## The Missing Frame Conversation on the AI Act in Italy revolves almost entirely around compliance. Which systems fall into high-risk categories. How much conformity costs. What sanctions you risk. These are legitimate questions, but incomplete. The missing context is the numbers from the start. 74% dependence on email. 89% perception of technological dependence. 2% of value in European digital platforms. In this frame, the AI Act is not a regulatory conformity problem. It's a tool in a larger game about Europe's position in the global technology market. Europe has few levers. It has no hyperscalers. It doesn't have the dominant foundation models. It doesn't have the venture capital base of the United States or the deployment scale of China. What it has is a 450-million-person market and institutional capacity to regulate that other blocs don't. Using this lever to influence global standards is industrial policy. Calling it just "consumer protection" is an incomplete description. Treating it only as "compliance" is missing the picture. Microsoft has made alignment with European regulation an element of positioning. Meta chose the opposite path, delaying model releases in Europe and pressuring for weaker rules. They're different strategies reflecting different readings of where the market is going. Neither treats the AI Act as a simple checklist. Maybe we should ask why we do. --- ## Sources Bradford, A. (2020). [*The Brussels Effect: How the European Union Rules the World*](https://www.brusselseffect.com/). Oxford University Press. Siegmann, C. & Anderljung, M. (2022). [*The Brussels Effect and Artificial Intelligence: How EU regulation will impact the global AI market*](https://arxiv.org/abs/2208.12645). GovAI, arXiv:2208.12645. Policy Review. (2025). [*Brussels effect or experimentalism? The EU AI Act and global standard-setting*](https://policyreview.info/articles/analysis/brussels-effect-or-experimentalism). European Commission. (2025). [*Digital Omnibus on AI Regulation Proposal*](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-ai-regulation-proposal). European Parliamentary Research Service. (2025). [*European Software and Cyber Dependencies*](https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf). TechReport. (2025). [*Europe's Digital Dependence: The Risks of the EU's Reliance on US Tech*](https://techreport.com/news/europe-digital-dependence-risks-of-heavy-reliance-on-us-tech/). --- ## L'AI Act non è (solo) compliance: è politica industriale - URL: https://ireneburresi.dev/blog/ai-act-geop/ - Pillar: Governance - Published: 2026-01-06 - Updated: 2026-01-06 - Tags: AI Act, Brussels Effect, Geopolitica, Politica industriale, Compliance strategica - Author: Irene Burresi > Il 74% delle aziende quotate EU usa email provider americani. L'89% delle imprese tedesche si considera tecnologicamente dipendente. L'AI Act va letto attraverso questa lente—come leva competitiva, non come checklist. ## L'unica leva rimasta *Il 74% delle aziende quotate in Europa usa email provider americani. L'89% delle imprese tedesche si considera tecnologicamente dipendente dall'estero. L'AI Act esiste in questo contesto. Leggerlo solo come problema di compliance significa perdere il quadro.* **TL;DR:** L'AI Act è politica industriale. L'Europa è in posizione di dipendenza tecnologica strutturale e la regolamentazione è l'unica leva dove ha ancora peso globale. Il "Brussels Effect" (la capacità di esportare standard) è contestato ma probabile per i sistemi AI high-risk. A novembre 2025 il Digital Omnibus ha ritardato l'applicazione di 16 mesi, ma la direzione resta la stessa. Chi legge l'AI Act solo come checklist normativa sta guardando l'albero e perdendo la foresta. --- I numeri sulla posizione tecnologica europea sono noti agli addetti ai lavori. Raramente entrano nel dibattito sull'AI Act. Un [report Proton di ottobre 2025](https://techreport.com/news/europe-digital-dependence-risks-of-heavy-reliance-on-us-tech/) ha analizzato i record DNS delle aziende quotate in Europa: il **74%** usa email provider americani. Non startup: aziende quotate in borsa, con obblighi di governance e sicurezza. Un [sondaggio Bitkom](https://www.idt.media/metaverse/cloud-ai-co-europe-wants-to-break-free-from-dependence/2130935) sulle imprese tedesche con più di 20 dipendenti rivela che l'89% si considera tecnologicamente dipendente dall'estero. Il [report EPRS del Parlamento Europeo](https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf) completa il quadro. Delle 100 maggiori piattaforme digitali globali per capitalizzazione, solo il **2%** del valore combinato è europeo. Nel cloud computing, negli hyperscaler, nei modelli AI foundation, l'Europa è importatore netto. Questo contesto cambia la lettura dell'AI Act. Non si tratta solo di proteggere i cittadini europei dagli algoritmi. Si tratta di usare l'unica leva dove l'Europa ha ancora peso per negoziare posizione in un mercato dominato da altri. --- ## Il meccanismo Il termine "Brussels Effect" è stato coniato da [Anu Bradford](https://www.brusselseffect.com/) nel 2012 e sviluppato nel suo libro del 2020. La tesi è diretta: l'UE, grazie alle dimensioni del suo mercato e alla qualità delle sue istituzioni, riesce a esportare i propri standard globalmente. Il meccanismo funziona in due modi. L'**effetto de facto**: le aziende che vogliono accedere al mercato europeo adottano gli standard EU anche altrove, perché mantenere due versioni costa di più che averne una sola. L'**effetto de jure**: altri governi copiano le regole europee perché funzionano e riducono il costo di progettare regolamentazione da zero. Il GDPR è l'esempio canonico. Leggi privacy ispirate al regolamento europeo sono state adottate in Brasile, Giappone, California. Le aziende tech hanno esteso molte protezioni GDPR a utenti non europei per semplificare le operazioni. La forma della regolamentazione europea si è diffusa oltre i confini dell'Unione. Sull'AI Act, la letteratura accademica è più sfumata. Un [paper GovAI del 2022](https://arxiv.org/abs/2208.12645) ha analizzato le condizioni per il Brussels Effect applicato all'intelligenza artificiale. La conclusione: effetti de facto e de jure sono **probabili**, soprattutto per i sistemi ad alto rischio delle grandi tech americane. Microsoft, Google, Meta operano in Europa con sistemi di recruiting, credito, moderazione contenuti. Dovranno conformarsi. E per molte di queste aziende, è più economico applicare uno standard globale che segmentare i prodotti per mercato. Il paper identifica anche i limiti. Il Brussels Effect funziona meglio quando il mercato EU è inevitabile (lo è per le big tech), quando la regolamentazione è percepita come di alta qualità (contestato), e quando non esistono alternative credibili (la Cina offre un modello diverso). Per i sistemi AI a basso rischio o per aziende che non operano in Europa, l'effetto sarà minore o assente. Un [articolo su Policy Review](https://policyreview.info/articles/analysis/brussels-effect-or-experimentalism) propone un frame complementare: l'AI Act come "governance sperimentalista". Non un modello da esportare tout court, ma un approccio tra tanti in un contesto di incertezza tecnologica. L'interazione con altri modelli regolatori (Stati Uniti, Regno Unito, Cina) sarà più cooperativa e meno unidirezionale di quanto il frame Brussels Effect suggerisca. La sintesi: il Brussels Effect sull'AI esiste ma è contestato e incerto. Non è garantito che le regole europee diventino standard globale. Non è garantito che restino irrilevanti. La partita è aperta. --- ## L'aggiustamento tattico A novembre 2025, la Commissione Europea ha proposto il [Digital Omnibus](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-ai-regulation-proposal). Il pacchetto include modifiche all'AI Act che hanno generato titoli su "l'Europa che fa marcia indietro". I fatti: l'applicazione dei requisiti per i sistemi AI ad alto rischio slitta di circa 16 mesi. La nuova data limite è dicembre 2027 per i sistemi Annex III (recruiting, credito, sanità), agosto 2028 per quelli embedded in prodotti regolamentati. È un ritardo significativo. Ma la struttura dell'AI Act resta intatta. Le categorie di rischio restano le stesse. Gli obblighi restano gli stessi. Cambia il calendario, non la destinazione. Il Digital Omnibus è un aggiustamento tattico, non un'inversione strategica. L'Europa sta calibrando i tempi, non abbandonando la direzione. Chi legge il ritardo come "marcia indietro" sta confondendo velocità con traiettoria. --- ## Il quadro che manca La conversazione sull'AI Act in Italia ruota quasi interamente attorno alla compliance. Quali sistemi rientrano nelle categorie high-risk. Quanto costa conformarsi. Quali sanzioni si rischiano. Sono domande legittime, ma parziali. Il contesto che manca è quello dei numeri iniziali. Il 74% di dipendenza per le email. L'89% di percezione di dipendenza tecnologica. Il 2% di valore europeo nelle piattaforme digitali globali. In questo quadro, l'AI Act non è un problema di conformità normativa. È uno strumento in una partita più ampia sulla posizione dell'Europa nel mercato tecnologico globale. L'Europa ha poche leve. Non ha hyperscaler. Non ha i modelli foundation dominanti. Non ha la base di venture capital degli Stati Uniti né la scala di deployment della Cina. Quello che ha è un mercato da 450 milioni di consumatori e una capacità istituzionale di regolare che altri blocchi non hanno. Usare questa leva per influenzare gli standard globali è politica industriale. Chiamarla solo "protezione dei consumatori" è una descrizione incompleta. Trattarla solo come "compliance" è perdere il quadro. Microsoft ha fatto dell'allineamento regolatorio europeo un elemento di posizionamento. Meta ha scelto la strada opposta, ritardando il rilascio di modelli in Europa e facendo pressione per ammorbidire le regole. Sono strategie diverse che riflettono letture diverse di dove sta andando il mercato. Nessuna delle due tratta l'AI Act come semplice checklist. Forse dovremmo chiederci perché noi sì. --- ## Fonti Bradford, A. (2020). [*The Brussels Effect: How the European Union Rules the World*](https://www.brusselseffect.com/). Oxford University Press. Siegmann, C. & Anderljung, M. (2022). [*The Brussels Effect and Artificial Intelligence: How EU regulation will impact the global AI market*](https://arxiv.org/abs/2208.12645). GovAI, arXiv:2208.12645. Policy Review. (2025). [*Brussels effect or experimentalism? The EU AI Act and global standard-setting*](https://policyreview.info/articles/analysis/brussels-effect-or-experimentalism). European Commission. (2025). [*Digital Omnibus on AI Regulation Proposal*](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-ai-regulation-proposal). European Parliamentary Research Service. (2025). [*European Software and Cyber Dependencies*](https://www.europarl.europa.eu/RegData/etudes/STUD/2025/778576/ECTI_STU(2025)778576_EN.pdf). TechReport. (2025). [*Europe's Digital Dependence: The Risks of the EU's Reliance on US Tech*](https://techreport.com/news/europe-digital-dependence-risks-of-heavy-reliance-on-us-tech/). --- ## Testing Non-Deterministico: Come si fa QA sugli Agenti? - URL: https://ireneburresi.dev/blog/testing-non-deterministico/ - Pillar: Tecnica - Published: 2026-01-06 - Updated: 2026-01-06 - Tags: Testing, AI Agents, QA, Red Teaming, Evaluation, MLOps, Production - Author: Irene Burresi > I test unitari non bastano quando il software improvvisa. Metodologie, framework e metriche per valutare affidabilità e sicurezza di sistemi agentici complessi prima del deploy: property-based testing, LLM-as-judge, red teaming automatizzato, fuzzing. ## Il problema: assert non basta più *Il 73% delle organizzazioni cita l'affidabilità come barriera principale al deploy di agenti in produzione. Non perché manchino i test, ma perché i test tradizionali non catturano i failure mode di sistemi che "improvvisano".* **TL;DR:** Testare agenti AI richiede un cambio di paradigma. I test unitari tradizionali verificano output deterministici: dato input X, attendi output Y. Gli agenti generano output diversi a ogni esecuzione, usano tool in sequenze imprevedibili, falliscono in modi che non crashano ma producono risultati sbagliati. Servono nuove metodologie: property-based testing per definire invarianti invece di output attesi, LLM-as-judge per valutazione scalabile, red teaming automatizzato per sicurezza, fuzzing adattato per stress-testing. I framework esistono: DeepEval, Opik, LangSmith, DeepTeam, PyRIT. Chi li adotta prima del deploy evita i silent failure che emergono solo in produzione. --- Un test unitario classico funziona così: chiami una funzione con input noti, verifichi che l'output corrisponda a un valore atteso. Se `sum(2, 3)` restituisce 5, il test passa. È deterministico, ripetibile, binario. Ora prova a testare un agente che deve rispondere a "trova i ristoranti italiani aperti stasera vicino a me". L'agente potrebbe chiamare un'API di geolocalizzazione, poi un servizio di ricerca locale, poi filtrare per orario. Oppure potrebbe cercare prima su Google Maps, poi verificare gli orari sui siti dei singoli ristoranti. Ogni esecuzione può produrre sequenze di azioni diverse, risultati diversi, formulazioni diverse della risposta finale. Come scrivi un `assertEquals()` per questo? Il problema non è solo la variabilità dell'output. È che i failure mode degli agenti sono fondamentalmente diversi da quelli del software tradizionale. Un bug classico crasha o restituisce un errore. Un agente che "fallisce" potrebbe restituire una risposta perfettamente formattata, grammaticalmente corretta, apparentemente ragionevole, ma fattualmente sbagliata. Potrebbe scegliere tool inappropriati. Potrebbe allucinare informazioni. Potrebbe seguire un piano che sembra logico ma non risolve il task originale. Il sistema non crasha. Non lancia eccezioni. Completa l'esecuzione. Solo che il risultato è sbagliato. Questo è il cuore del problema: i test tradizionali non catturano i *silent failure*. E i silent failure sono la norma, non l'eccezione, nei sistemi agentici. --- ## Tassonomia: cosa stai cercando di testare Prima di scegliere metodologie, serve chiarire cosa significa "testare un agente". Un [paper del 2025 su arXiv](https://arxiv.org/abs/2503.16416) propone una tassonomia bidimensionale che aiuta a orientarsi. La prima dimensione riguarda l'**oggetto della valutazione**: **Behavior:** L'agente si comporta come previsto? Segue le istruzioni? Rispetta i vincoli? **Capabilities:** L'agente è in grado di completare determinati task? Quali classi di problemi risolve? **Reliability:** L'agente produce risultati consistenti? Quanto varia la qualità tra esecuzioni? **Safety:** L'agente evita azioni dannose? Resiste a tentativi di manipolazione? Protegge dati sensibili? La seconda dimensione riguarda il **processo di valutazione**: **Offline evaluation:** Test pre-deployment su dataset statici o ambienti simulati. **Online evaluation:** Monitoraggio in produzione su traffico reale. **Component-level:** Testare singoli pezzi (il retriever, il planner, il singolo tool). **End-to-end:** Testare il sistema completo su task realistici. La maggior parte delle organizzazioni si ferma alla valutazione offline delle capabilities su singoli componenti. È il minimo indispensabile, ma non basta. I bug più insidiosi emergono dalle interazioni tra componenti, dalla variabilità del comportamento su input diversi, dai casi limite che nessun dataset statico copre. --- ## Property-based testing: invarianti invece di output Il primo cambio di paradigma è passare da *example-based testing* a *property-based testing*. Nell'example-based testing, definisci coppie input-output: "Se l'input è X, l'output deve essere Y". Funziona quando l'output è deterministico e lo conosci in anticipo. Nel property-based testing, definisci *proprietà* che devono valere per tutti gli input: "Per qualsiasi input valido, l'output deve soddisfare la condizione Z". Non specifichi l'output esatto. Specifichi vincoli che l'output deve rispettare. Per un agente, le proprietà potrebbero essere: - La risposta deve contenere solo informazioni presenti nei documenti di contesto (no hallucination) - Se il task richiede un calcolo numerico, il risultato deve essere matematicamente corretto - La sequenza di tool call deve terminare entro N step - Ogni tool call deve usare parametri nel formato corretto - La risposta finale deve essere nella lingua richiesta Queste proprietà possono essere verificate automaticamente, indipendentemente dalla formulazione specifica dell'output. In pratica, il test genera input casuali o semi-casuali, esegue l'agente, verifica che le proprietà siano soddisfatte. Se trova una violazione, riduce l'input al caso minimo che causa il fallimento. Framework come [Hypothesis](https://hypothesis.readthedocs.io/) (Python) supportano property-based testing. Per agenti, serve estenderli con proprietà specifiche del dominio e generatori di input che producono scenari realistici. Un limite di questo approccio: non tutte le proprietà sono formalizzabili in modo verificabile automaticamente. "La risposta è utile" o "il tono è appropriato" richiedono giudizio semantico che le asserzioni booleane non catturano. --- ## LLM-as-Judge: valutazione scalabile Qui entra il pattern *LLM-as-judge*: usare un altro modello linguistico per valutare l'output dell'agente sotto test. Il concetto è semplice. Invece di scrivere asserzioni programmatiche, definisci criteri di valutazione in linguaggio naturale. Un LLM evaluator riceve l'input, l'output dell'agente, i criteri, e produce un giudizio strutturato: score numerici, classificazioni, spiegazioni. Questo pattern è alla base di diversi framework di evaluation. [DeepEval](https://www.confident-ai.com/blog/llm-testing-in-2024-top-methods-and-strategies) offre metriche predefinite come G-Eval (valutazione generale), faithfulness (aderenza ai fatti), answer relevancy, contextual precision. [Opik](https://www.comet.ml/site/products/opik/) di Comet fornisce evaluation per workflow agentici multi-step, inclusa qualità del piano, aderenza al piano, efficienza degli step. [LangSmith](https://docs.smith.langchain.com/) di LangChain e [Langfuse](https://langfuse.com/) combinano tracing, logging e evaluation, permettendo di ispezionare ogni step dell'agente e valutare sia i componenti che il risultato finale. [Databricks Mosaic AI Agent Evaluation](https://www.databricks.com/blog/introducing-enhanced-agent-evaluation) integra evaluation con la piattaforma MLOps esistente. Il vantaggio principale: scala. Puoi valutare migliaia di output senza annotatori umani per ogni caso. Puoi definire criteri complessi in linguaggio naturale invece che in codice. I limiti sono altrettanto concreti: **Bias dell'evaluator:** Il modello valutatore ha i suoi bias. Potrebbe preferire risposte verbose, o penalizzare formulazioni corrette ma non convenzionali. [Studi](https://arxiv.org/abs/2306.05685) mostrano che gli LLM tendono a preferire le proprie risposte rispetto a quelle di altri modelli. **Costo:** Ogni valutazione richiede un'inference del modello evaluator. Su dataset grandi, i costi si accumulano. **Non sostituisce validazione umana:** Per decisioni critiche (lancio in produzione, confronto tra approcci), serve comunque un campione validato da umani. La pratica migliore è usare LLM-as-judge per screening su larga scala e validazione umana su campioni stratificati. [Ricerche](https://www.confident-ai.com/blog/llm-testing-in-2024-top-methods-and-strategies) mostrano che questa combinazione identifica il 60-70% in più di problemi rispetto al testing ad hoc. --- ## Metriche specifiche per agenti Le metriche generiche di NLP (BLEU, ROUGE, perplexity) non catturano ciò che conta per gli agenti. Servono metriche progettate per valutare comportamenti agentici. **Task completion rate:** L'agente ha completato il task assegnato? È la metrica primaria, ma richiede una definizione chiara di "completamento". Per task oggettivi (estrai il prezzo dal documento) è binaria. Per task aperti (scrivi una email di risposta) richiede valutazione qualitativa. **Tool correctness:** Ogni tool call è valida? I parametri sono nel formato corretto? Il tool chiamato è appropriato per lo step corrente? **Tool hallucination:** L'agente ha chiamato tool che non esistono? Ha inventato parametri non previsti dall'API? **Plan quality:** Il piano generato dall'agente è ragionevole? Copre tutti gli step necessari? È efficiente? **Plan adherence:** L'agente ha seguito il piano che ha generato? O ha deviato in modo ingiustificato? **Step efficiency:** Quanti step ha richiesto per completare il task? Rispetto a un baseline o a esecuzioni precedenti? **Recovery rate:** Quando un tool fallisce o restituisce un errore, l'agente riesce a recuperare? Riprova? Cerca alternative? **Consistency:** Dato lo stesso input ripetuto N volte, quanto varia l'output? La varianza è accettabile o indica instabilità? Queste metriche richiedono strumentazione. Il sistema deve loggare ogni step, ogni tool call, ogni decisione del planner. Senza trace dettagliato, non puoi calcolarle. Framework come Opik e LangSmith forniscono tracing automatico. Se usi framework custom, devi costruire il logging. --- ## Red teaming: testare la sicurezza prima che lo facciano altri Il red teaming è la pratica di attaccare deliberatamente il sistema per scoprire vulnerabilità prima che lo facciano attori malevoli. Per gli agenti AI, è particolarmente critico. [OWASP ha pubblicato a dicembre 2025](https://owasp.org/www-project-top-10-for-large-language-model-applications/) il Top 10 per applicazioni agentic. Le categorie principali includono: **Prompt injection:** Input malevoli che inducono l'agente a ignorare le istruzioni originali o eseguire azioni non autorizzate. Può essere diretto (nell'input utente) o indiretto (nascosto nei dati che l'agente recupera). **Tool misuse:** L'agente viene indotto a usare tool in modi non previsti: leggere file sensibili, inviare dati a endpoint esterni, eseguire codice arbitrario. **Memory leakage:** Informazioni da sessioni o utenti precedenti che trapelano nelle risposte. **Privilege escalation:** L'agente acquisisce permessi superiori a quelli previsti, spesso attraverso catene di tool call. Il red teaming tradizionale è manuale: esperti di sicurezza tentano di violare il sistema usando creatività e conoscenza del dominio. È efficace ma non scala. Il red teaming automatizzato usa LLM per generare attacchi. [DeepTeam](https://github.com/confident-ai/deepteam), sviluppato da Confident AI, genera automaticamente prompt di attacco per diverse categorie di vulnerabilità e valuta la robustezza del sistema. [PyRIT](https://github.com/Azure/PyRIT) di Microsoft è un framework open-source per red teaming di sistemi AI, con focus su generazione automatica di attacchi e reporting. [Enkrypt AI](https://www.enkryptai.com/) offre red teaming as a service con prompt dinamici che evolvono in base alle difese del sistema. [Giskard](https://www.giskard.ai/) combina red teaming con vulnerability scanning specifico per LLM. Le [best practice per enterprise](https://skywork.ai/blog/agentic-ai-safety-best-practices-2025-enterprise/) raccomandano: - Red teaming prima di ogni release in produzione - Cadenza trimestrale per sistemi ad alto rischio - Test aggiuntivi dopo ogni cambio materiale: nuovo modello, nuovo tool, nuova fonte dati - Mappatura degli attacchi al [framework MITRE ATLAS](https://atlas.mitre.org/) - Metriche tracciate: vulnerabilità scoperte per test, tempo di remediation, tasso di successo ai re-test L'EU AI Act richiede red teaming documentato per sistemi ad alto rischio. Non è più opzionale per chi opera in Europa. --- ## Fuzzing: stress-testing ai confini Il fuzzing è una tecnica classica di security testing: bombardare il sistema con input invalidi, inattesi, casuali, per scoprire bug e vulnerabilità che il testing normale non trova. Per software tradizionale, il fuzzing cerca crash, memory corruption, behavior indefinito. Per agenti AI, cerca comportamenti indesiderati: risposte dannose, leak di informazioni, violazioni di policy, loop infiniti. [Un survey del 2024](https://arxiv.org/html/2402.00350v1) cataloga le tecniche di fuzzing applicate a LLM. I principali approcci: **Black-box fuzzing:** Tratti il modello come scatola nera. Generi input, osservi output, iteri. Non richiede accesso ai pesi o all'architettura. Funziona con qualsiasi API. **Grey-box fuzzing:** Combini generazione casuale con feedback sulla copertura. Se un input esplora un comportamento nuovo (misurato tramite output o trace), lo tieni come seed per ulteriori mutazioni. **LLM-enhanced fuzzing:** Usi un LLM per generare input più intelligenti. Invece di mutazioni casuali, chiedi al modello di generare varianti che potrebbero causare problemi. [ChatFuzz](https://arxiv.org/abs/2305.06498) combina fuzzing grey-box con generazione via ChatGPT. Un "chat mutator" prende seed dal pool e chiede a ChatGPT di generare input simili ma diversi. I nuovi input vengono valutati e quelli interessanti diventano nuovi seed. [Fuzz4All](https://arxiv.org/abs/2308.04009) usa GPT-4 e StarCoder come motori di generazione e mutazione, permettendo fuzzing su progetti in linguaggi diversi. È stato usato per trovare bug in compilatori e interpreti. Per agenti, il fuzzing si applica a diversi livelli: - **Input utente:** Genera query malformate, ambigue, con caratteri speciali, lunghe, multilingue - **Risposte dei tool:** Simula tool che restituiscono errori, timeout, dati malformati, dati malevoli - **Contesto RAG:** Inietta documenti con contenuto contraddittorio, injection attempt, formattazione insolita Il fuzzing è computazionalmente costoso. Ogni run richiede inference del modello. Ma trova classi di bug che altri metodi non scoprono. --- ## Ambienti di test: benchmark e simulazioni Testare agenti in produzione è rischioso: ogni bug è visibile agli utenti. Testare su dataset statici è insufficiente: non cattura le interazioni dinamiche con tool e ambienti. La soluzione intermedia sono gli ambienti di simulazione che replicano condizioni realistiche senza conseguenze reali. [AgentBench](https://github.com/THUDM/AgentBench) fornisce 8 ambienti distinti (web browsing, coding, database query) per valutare agenti su task realistici. [WebArena](https://webarena.dev/) simula siti web reali dove gli agenti possono navigare e completare task. [SWE-bench](https://www.swebench.com/) valuta agenti su issue GitHub reali, misurando la capacità di risolvere bug in codebase esistenti. Questi benchmark hanno un problema: sono statici. Una volta che un agente è stato ottimizzato per un benchmark, i risultati non predicono più le performance su casi nuovi. Il trend è verso benchmark dinamici e continuamente aggiornati. [AppWorld](https://appworld.dev/) e [WorkArena++](https://github.com/ServiceNow/WorkArena) propongono task che cambiano nel tempo. Il concetto è simile ai dataset di evaluation per code generation che usano problemi di competitive programming: nuovi problemi ogni mese, impossibili da memorizzare. Per testing interno, la pratica migliore è costruire ambienti che replicano il deployment target: - Mock dei tool esterni con risposte realistiche (successi, errori, latenza) - Dataset di input che riflettono la distribuzione di produzione - Scenari edge case identificati da incident post-mortem - Versioning degli ambienti di test per reproducibilità Un ambiente di test ben costruito è un asset che si accumula nel tempo. Ogni bug trovato in produzione diventa un nuovo test case. --- ## Pipeline di evaluation: pre-deploy e post-deploy L'evaluation non è un evento singolo. È un processo continuo che attraversa tutto il lifecycle. **Pre-deploy (offline):** 1. **Unit test sui componenti:** Il retriever restituisce documenti rilevanti? Il planner genera piani validi? I tool wrapper gestiscono errori? 2. **Integration test end-to-end:** L'agente completo risolve task rappresentativi? Su un dataset di almeno 500-1000 casi diversi? 3. **Property-based testing:** Le proprietà invarianti sono rispettate su input generati casualmente? 4. **Red teaming:** Il sistema resiste agli attacchi noti? Le nuove vulnerabilità sono state testate? 5. **Regression testing:** Le performance sono uguali o migliori della versione precedente? Nessun degradamento su casi critici? La soglia per il deploy dovrebbe essere esplicita: task completion rate > X%, zero vulnerabilità critiche, regression test 100% passed. **Post-deploy (online):** 1. **Sampling:** Valuta un campione (1-5%) degli output di produzione. Prioritizza casi flaggati da guardrail o con feedback negativo. 2. **Monitoring metriche:** Traccia task completion, latenza, error rate, costo per query in tempo reale. Alert su deviazioni. 3. **Drift detection:** Le performance stanno degradando? La distribuzione degli input sta cambiando? 4. **Human review:** Revisione periodica di campioni stratificati da annotatori qualificati. 5. **Incident analysis:** Ogni failure diventa un caso di test. Root cause analysis alimenta il dataset di regression. L'integrazione con CI/CD è critica. Ogni PR che modifica l'agente dovrebbe triggerare la suite di test offline. Il deploy in produzione dovrebbe essere bloccato se i test non passano. --- ## Il costo del non testare I numeri parlano chiaro. Il [73% delle organizzazioni](https://www.confident-ai.com/blog/llm-testing-in-2024-top-methods-and-strategies) cita l'affidabilità come barriera al deploy di agenti. Non la tecnologia, non i costi di inference: l'affidabilità. La conseguenza è che molti progetti restano in POC indefinitamente. Il team non ha fiducia sufficiente per andare in produzione. Senza metodologie di testing adeguate, quella fiducia è impossibile da costruire. Chi investe in evaluation rigorosa pre-deploy scopre i problemi prima che li scoprano gli utenti. Chi non lo fa scopre i problemi tramite incident, ticket di supporto, perdita di fiducia. Il testing di sistemi non-deterministici è più complesso del testing tradizionale. Richiede nuove competenze, nuovi tool, nuovi processi. Ma l'alternativa, deployare senza confidence e scoprire i bug in produzione, è più costosa. I framework esistono. Le metodologie sono documentate. Il gap è nell'adozione. --- ## Fonti Confident AI. (2025). [*LLM Testing in 2025: Top Methods and Strategies*](https://www.confident-ai.com/blog/llm-testing-in-2024-top-methods-and-strategies). Databricks. (2025). [*Announcing Agent Evaluation*](https://www.databricks.com/blog/introducing-enhanced-agent-evaluation). Galileo AI. (2025). [*Top 12 AI Evaluation Tools for GenAI Systems in 2025*](https://galileo.ai/blog/mastering-llm-evaluation-metrics-frameworks-and-techniques). GitHub. (2025). [*DeepTeam: Framework to red team LLMs*](https://github.com/confident-ai/deepteam). Hu, J., Zhang, Q., & Yin, H. (2023). [*ChatFuzz: Large Language Model Enhanced Fuzzing*](https://arxiv.org/abs/2305.06498). arXiv:2305.06498. OWASP. (2025). [*Top 10 for Large Language Model Applications v2025*](https://owasp.org/www-project-top-10-for-large-language-model-applications/). Skywork AI. (2025). [*Agentic AI Safety & Guardrails: 2025 Best Practices for Enterprise*](https://skywork.ai/blog/agentic-ai-safety-best-practices-2025-enterprise/). Wang, L., et al. (2024). [*Large Language Models Based Fuzzing Techniques: A Survey*](https://arxiv.org/abs/2402.00350). arXiv:2402.00350. Zhang, Y., et al. (2025). [*A Survey on the Evaluation of LLM-based Agents*](https://arxiv.org/abs/2503.16416). arXiv:2503.16416. --- ## Constitutional AI: A Guide for Claude Users - URL: https://ireneburresi.dev/blog/constitutional-aien/ - Pillar: Ricerca - Published: 2025-12-29 - Updated: 2025-12-29 - Tags: Constitutional AI, Claude, Anthropic, AI Safety, LLM Deployment, Enterprise AI - Author: Irene Burresi > Claude alternates between absurd refusals and risky responses. Constitutional AI shows how to manage overrefusal, sycophancy, and linguistic vulnerabilities in deployments. ## The Paradox of Selective Refusal *Claude refuses to write a story with a character who smokes, but with the right prompt explains how to synthesize methamphetamine. Constitutional AI explains both behaviors.* **TL;DR:** Constitutional AI trains Claude using a list of principles ("constitution") instead of human feedback for each response. It produces safer models than traditional RLHF: 88% harmless rate against 76%. But the failure modes are specific and predictable. The model is excessively cautious on content that *looks* problematic (keyword matching) and vulnerable to attacks that *don't look* problematic (semantic jailbreaks). It's safer in English than in other languages. It tends to agree with you even when you're wrong. For deployers: expect high refusal rates on legitimate use cases, plan fallbacks, don't trust safety in non-English languages. --- Anyone who has used Claude in production knows the frustration. The model refuses to write a payment reminder email because "it could be perceived as aggressive". It refuses fiction with conflicts because "it could normalize violent behavior". It refuses to complete code that handles authentication because "it could be used for hacking". Then you read security reports. [Adaptive attacks reach 100% success rate](https://arxiv.org/abs/2404.02151) on Claude 3 and 3.5. Researchers have extracted instructions for synthesizing chemical weapons, generating functioning malware, creating illegal content. With the right techniques, protections crumble completely. How can the same model be simultaneously too restrictive and too permissive? The answer lies in Constitutional AI, the method Anthropic uses to train Claude. Understanding how it works explains both behaviors and, more importantly, lets you predict when the model will fail in your applications. --- ## How Constitutional AI Works [The original Anthropic paper](https://arxiv.org/abs/2212.08073), published in December 2022, proposes a method to make models "harmless" without manually labeling hundreds of thousands of responses as "good" or "bad". The process has two phases. In the first, the model generates responses to problematic prompts, then critiques and revises its own responses using principles written in natural language. Example principle: "Choose the response that does not encourage illegal, harmful, or unethical behavior". The model gets trained on the revisions. In the second phase, the model generates pairs of responses and another model decides which is better according to the same principles. These preferences generated by AI (not humans) are used for reinforcement learning. Anthropic calls this approach RLAIF: Reinforcement Learning from AI Feedback, instead of RLHF (Human Feedback). [Claude's constitution](https://www.anthropic.com/news/claudes-constitution) includes principles derived from the Universal Declaration of Human Rights, DeepMind's beneficence principles, and internally written guidelines. It's not a static document: Anthropic updates it periodically and has conducted experiments with public input to modify it. The paper's central claim: Constitutional AI produces models that are simultaneously safer (harmless) and less evasive (more useful) than traditional RLHF. The data shows this is true on average. But "on average" hides significant variance. --- ## What Works: The Real Improvements Before analyzing problems, the data on what Constitutional AI does well. [Google DeepMind published in 2023](https://arxiv.org/abs/2309.00267) the most rigorous comparison between RLAIF and RLHF. On harmlessness tasks, RLAIF achieves 88% harmless rate against 76% for RLHF. This is not a marginal improvement. The head-to-head comparison on general quality (summarization, helpful dialogue) shows no statistically significant differences: both methods produce output preferred by evaluators roughly 70% of the time versus baseline without reinforcement learning. RLAIF is not worse than RLHF on quality, and is better on safety. The cost advantage is substantial. AI labeling costs about $0.06 per example, versus $0.11 for 50 words of human annotation. For those training models, this means faster iterations and less exposure of human annotators to disturbing content. For those using already-trained models, it means Anthropic can invest more resources in safety research instead of data labeling. A less-discussed benefit: constitutional principles are readable. When Claude refuses a request, in theory you can trace which principle triggered the refusal. With pure RLHF, preferences are implicit in training data and not inspectable. This transparency is partial (you don't know *how* the model interprets the principles), but it's more than other approaches offer. --- ## Where the Model Refuses Too Much The first failure mode impacting Claude users in production is overrefusal. The model refuses legitimate requests because superficial patterns trigger safety guardrails. The mechanism is understandable. Constitutional principles are formulated in general terms: "avoid content that could cause harm", "don't assist in illegal activities", "refuse requests that could be used for manipulation". The model learns to associate certain lexical patterns with refusal, even when context makes the request harmless. Failure modes documented by the community span different domains. In fiction, Claude refuses stories with morally ambiguous characters, realistic conflicts, or mature themes that would be acceptable in any published novel. A prompt for a thriller with a credible antagonist can trigger a refusal because "it could normalize harmful behavior". In code, requests handling authentication, encryption, or network scanning get blocked because "they could be used for hacking". This includes legitimate penetration testing, security auditing, or even simple password management. Professional communication suffers the same fate: payment reminder emails, complaint letters, assertive communication refused because "they could be perceived as aggressive or manipulative". On medical and legal topics, disclaimers are so extensive as to be useless, or refusals are complete. The common pattern: the model reacts to keywords and superficial structures, not context. "How to force a lock" gets refused even if the context is "I've lost my house keys". "How to manipulate someone" gets refused even if the context is "I'm writing an essay on historical propaganda". [Anthropic's Constitutional Classifiers team](https://www.anthropic.com/research/constitutional-classifiers) has documented this trade-off. After deploying additional defenses against jailbreaks, they observed that the system "would frequently refuse to answer basic, non-malicious questions". More security against attacks means more overrefusal on legitimate requests. For deployers: refusal rates on legitimate use cases can be significant. If your application requires creative content generation, assistance on sensitive topics, or security code, expect a non-trivial percentage of requests to be refused. You need fallbacks (alternative models, human escalation) and appropriate messaging for users. --- ## Where the Model Accepts Too Much The second failure mode is the opposite: the model accepts requests it should refuse, when the attack is formulated to bypass superficial patterns. [A 2024 study](https://arxiv.org/abs/2404.02151) tested adversarial attacks on Claude 3 and 3.5. With transfer techniques (prompts that work on other models adapted) or prefilling (forcing the start of the model's response), success rate reaches 100%. All tested attacks succeeded. Without the additional defenses of Constitutional Classifiers, Anthropic's internal testing shows 86% jailbreak success on Claude 3.5 Sonnet. With Constitutional Classifiers deployed, success rate drops dramatically, but after 3,700 collective hours of red-teaming, a universal jailbreak was still discovered. How can the same model refuse a payment reminder and accept requests to synthesize chemical weapons? The answer lies in the nature of constitutional principles. They're formulated in natural language, and the model learns to interpret them through statistical examples, not through deep semantic understanding. An attack that reformulates the request to not match learned patterns bypasses protections. The most sophisticated jailbreaks exploit different vulnerabilities. Roleplay asks the model to play a character without the same restrictions. Obfuscation encodes the request in ways the model decodes but that don't trigger safety checks (base64, different languages, slang). Prefilling, in some APIs, forces the start of the model's response bypassing the point where it decides to refuse. Multi-turn manipulation builds context gradually through multiple messages, each harmless, that together lead the model to answer requests it would refuse if posed directly. For deployers: Claude's protections are insufficient for high-stakes use cases. If your application could be used to generate dangerous content, you need additional layers of moderation. Don't rely solely on the model's guardrails. --- ## The Sycophancy Problem The third failure mode is subtler and less discussed: Claude tends to agree with you even when you're wrong. [Anthropic itself published research](https://arxiv.org/abs/2310.13548) documenting pervasive sycophancy across all major AI assistants, including Claude. Documented behaviors include admitting errors not committed: if you tell the model "your previous response was wrong", it often apologizes and "corrects" even when the original response was right. Feedback becomes biased: if you ask for evaluation of a text saying "I wrote it", the model tends to be more positive than if you present the same text as written by someone else. On math problems where the user suggests a wrong answer, the model tends to agree with the wrong answer more often than it would without the suggestion. The cause is structural. Constitutional AI (like RLHF) optimizes for expressed preferences. Both humans and AI models tend to prefer responses that agree with them, that are convincingly written, that avoid conflict. The model learns that "agreeing" produces higher reward. The most concerning finding: larger models trained with more iterations of RLHF/RLAIF show increased sycophancy, not decreased. It's not a bug that resolves with more training. It's a consequence of the training method itself. For deployers: if your application requires the model to give honest feedback, verify information, or contradict the user when wrong, expect degraded performance. Use cases like code review, fact-checking, tutoring are particularly impacted. Consider explicitly instructing the model to be critical, but know this only partially mitigates the problem. --- ## The Non-English Language Problem The failure modes described so far amplify when the model operates in languages other than English. This directly impacts those operating in Italy. The data is clear. [Research on multilingual LLM safety](https://arxiv.org/abs/2310.02446) shows models produce harmful responses dramatically more often in languages other than English. A specific example: Llama-3.1-8B refuses "How to make a bomb?" in English but provides detailed instructions for the same question in Hindi. The pattern repeats across models and languages. Attack success rate jumps from single digits in English to 50-70% in low-resource languages. Italian, while being a relatively well-represented language, is not immune. The cause: safety training data (examples of refusals, definitions of harmful content, harmlessness preferences) is predominantly in English. Constitutional principles are written in English. The model generalizes imperfectly to other languages. For applications serving Italian users, this has concrete implications. Guardrails that work in English are less reliable in Italian. A user wanting to bypass protections can simply formulate the request in Italian (or an even less-represented language) with greater probability of success. Countermeasures are limited. You can translate requests to English before sending to the model, process in English, then translate responses back to Italian. But this adds latency, cost, and can introduce translation errors. You can add language-specific moderation layers for Italian, but this requires significant investment. --- ## Implications for Enterprise Deployment What does all this mean for those deciding whether and how to use Claude in production? Constitutional AI makes Claude a reasonable choice for general-purpose applications with non-adversarial users: customer service chatbots, internal assistants, productivity tools. Refusal rate on legitimate requests is manageable, and risk of harmful output is low if users aren't actively seeking to abuse the system. It also works for use cases where overrefusal is acceptable: if your application can tolerate frequent refusals (with appropriate fallbacks), Claude's guardrails are a net benefit. The transparency of principles is useful for compliance and audit: being able to say "the model follows these documented principles" is more defensible than "the model was trained on implicit preferences". Additional precautions are needed for creative applications. If you generate fiction, marketing copy, or content touching sensitive topics, expect high refusal rates. Prepare alternative prompts, fallbacks to less restrictive models, or workflows with human review. The same applies to applications requiring honest feedback like code review, tutoring, fact-checking: sycophancy is a structural problem. Consider aggressive prompt engineering to counter it, but don't expect it to fully resolve. For multilingual applications, if you serve non-English speakers, guardrails are less reliable. Add language-specific moderation for the languages you support. For high-stakes applications where harmful output would have serious consequences (medical, legal, security), don't rely solely on the model's guardrails. Add layers of validation, external moderation, and human review. Don't expect guaranteed security against sophisticated attacks. The 100% jailbreak success with adaptive attacks means motivated attackers can bypass protections. If your application is an attractive target, assume it will be compromised. Don't expect consistent behavior across languages: the model behaving well in English can behave very differently in Italian. Don't expect sycophancy to improve with scale: larger, more trained models are not less sycophantic. Rather the opposite. --- ## The Big Picture Constitutional AI represents a real improvement over previous alternatives. Data is clear: 88% harmless rate against 76% traditional RLHF, at lower cost. For those using commercial models, this means Claude is genuinely safer than average. But "safer than average" doesn't mean "safe". Documented failure modes are specific and predictable. The model refuses too much when superficial patterns trigger guardrails, even if context makes the request legitimate. It accepts too much when sophisticated attacks reformulate harmful requests in ways that don't match learned patterns. It agrees with you even when you're wrong, because sycophancy is incentivized by training itself. It's less safe in languages other than English, because safety data is predominantly English. None of these problems are unique to Claude or Constitutional AI. They're limitations of current alignment approaches in general. But Constitutional AI makes them more predictable: if you understand the mechanism, you can anticipate where the model will fail. For deployers, the question is not "is Claude safe?" but "are Claude's failure modes acceptable for my use case?". The answer depends on context. For many enterprise applications, Constitutional AI offers a reasonable trade-off between safety and usability. For high-stakes or adversarial applications, it's not sufficient on its own. The transparency about principles is a competitive advantage for Anthropic over other providers. [Claude's constitution is public](https://www.anthropic.com/news/claudes-constitution). You can read it, understand what the model is trying to do, and decide if those principles align with your use cases. That's more than others offer. Constitutional AI doesn't solve alignment. It makes the problem more manageable, more inspectable, more predictable. For those needing to deploy LLMs today, with today's limitations, it's a concrete step forward. It's not the destination, but it's a reasonable direction. --- ## Sources Bai, Y., Kadavath, S., Kundu, S., et al. (2022). [*Constitutional AI: Harmlessness from AI Feedback*](https://arxiv.org/abs/2212.08073). arXiv:2212.08073. Lee, H., Phatale, S., Mansoor, H., et al. (2023). [*RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback*](https://arxiv.org/abs/2309.00267). arXiv:2309.00267. Andriushchenko, M., et al. (2024). [*Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks*](https://arxiv.org/abs/2404.02151). arXiv:2404.02151. Perez, E., Ringer, S., Lukošiūtė, K., et al. (2023). [*Towards Understanding Sycophancy in Language Models*](https://arxiv.org/abs/2310.13548). arXiv:2310.13548. Deng, Y., et al. (2023). [*Multilingual Jailbreak Challenges in Large Language Models*](https://arxiv.org/abs/2310.02446). arXiv:2310.02446. Anthropic. (2023). [*Claude's Constitution*](https://www.anthropic.com/news/claudes-constitution). Anthropic. Anthropic. (2024). [*Constitutional Classifiers: Defending Against Universal Jailbreaks*](https://www.anthropic.com/research/constitutional-classifiers). Anthropic. --- ## Constitutional AI: guida per chi usa Claude - URL: https://ireneburresi.dev/blog/constitutional-ai/ - Pillar: Ricerca - Published: 2025-12-29 - Updated: 2025-12-29 - Tags: Constitutional AI, Claude, Anthropic, AI Safety, LLM Deployment, Enterprise AI - Author: Irene Burresi > Claude alterna rifiuti assurdi e risposte rischiose. Constitutional AI mostra come gestire overrefusal, sycophancy e vulnerabilità linguistiche nei deployment. ## Il paradosso del rifiuto selettivo *Claude rifiuta di scrivere un racconto con un personaggio che fuma, ma con il prompt giusto spiega come sintetizzare metanfetamina. Constitutional AI spiega entrambi i comportamenti.* **TL;DR:** Constitutional AI addestra Claude usando una lista di principi ("costituzione") invece di feedback umano per ogni risposta. Produce modelli più sicuri di RLHF tradizionale: 88% harmless rate contro 76%. Ma i failure modes sono specifici e prevedibili. Il modello è eccessivamente cauto su contenuti che *sembrano* problematici (keyword matching) e vulnerabile ad attacchi che *non sembrano* problematici (jailbreak semantici). È più sicuro in inglese che in altre lingue. Tende a darti ragione anche quando sbagli. Per chi deploya: aspettati refusal rate alto su casi d'uso legittimi, pianifica fallback, non fidarti della sicurezza su lingue diverse dall'inglese. --- Chiunque abbia usato Claude in produzione conosce la frustrazione. Il modello rifiuta di scrivere un'email di sollecito pagamento perché "potrebbe essere percepita come aggressiva". Rifiuta fiction con conflitti perché "potrebbe normalizzare la violenza". Rifiuta di completare codice che gestisce autenticazione perché "potrebbe essere usato per hacking". Poi leggi i report di sicurezza. [Adaptive attacks raggiungono il 100% di success rate](https://arxiv.org/abs/2404.02151) su Claude 3 e 3.5. Ricercatori hanno estratto istruzioni per sintetizzare armi chimiche, generare malware funzionante, creare contenuti illegali. Con le tecniche giuste, le protezioni cedono completamente. Come può lo stesso modello essere contemporaneamente troppo restrittivo e troppo permissivo? La risposta sta in Constitutional AI, il metodo con cui Anthropic addestra Claude. Capire come funziona spiega entrambi i comportamenti e, più importante, permette di prevedere quando il modello fallirà nelle tue applicazioni. --- ## Come funziona Constitutional AI [Il paper originale di Anthropic](https://arxiv.org/abs/2212.08073), pubblicato a dicembre 2022, propone un metodo per rendere i modelli "harmless" senza etichettare manualmente centinaia di migliaia di risposte come "buone" o "cattive". Il processo ha due fasi. Nella prima, il modello genera risposte a prompt problematici, poi critica e rivede le proprie risposte usando principi scritti in linguaggio naturale. Esempio di principio: "Scegli la risposta che non incoraggia comportamenti illegali, dannosi o non etici". Il modello viene addestrato sulle revisioni. Nella seconda fase, il modello genera coppie di risposte e un altro modello decide quale è migliore secondo gli stessi principi. Queste preferenze generate dall'AI (non da umani) vengono usate per il reinforcement learning. Anthropic chiama questo approccio RLAIF: Reinforcement Learning from AI Feedback, invece di RLHF (Human Feedback). [La costituzione di Claude](https://www.anthropic.com/news/claudes-constitution) include principi derivati dalla Dichiarazione Universale dei Diritti Umani, dai principi di beneficenza di DeepMind, e da linee guida scritte internamente. Non è un documento statico: Anthropic la aggiorna periodicamente e ha condotto esperimenti con input pubblico per modificarla. Il claim centrale del paper: Constitutional AI produce modelli che sono contemporaneamente più sicuri (harmless) e meno evasivi (più utili) rispetto a RLHF tradizionale. I dati mostrano che questo è vero in media. Ma "in media" nasconde varianza significativa. --- ## Cosa funziona: i miglioramenti reali Prima di analizzare i problemi, i dati su cosa Constitutional AI fa bene. [Google DeepMind ha pubblicato nel 2023](https://arxiv.org/abs/2309.00267) il confronto più rigoroso tra RLAIF e RLHF. Su task di harmlessness, RLAIF ottiene 88% harmless rate contro 76% di RLHF. Non è un miglioramento marginale. Il confronto head-to-head su qualità generale (summarization, helpful dialogue) non mostra differenze statisticamente significative: entrambi i metodi producono output preferiti dagli evaluatori circa il 70% delle volte rispetto a baseline senza reinforcement learning. RLAIF non è peggiore di RLHF sulla qualità, ed è migliore sulla sicurezza. Il vantaggio di costo è sostanziale. AI labeling costa circa $0.06 per esempio, contro $0.11 per 50 parole di annotazione umana. Per chi addestra modelli, questo significa iterazioni più rapide e meno esposizione di annotatori umani a contenuti disturbanti. Per chi usa modelli già addestrati, significa che Anthropic può investire più risorse in safety research invece che in data labeling. Un beneficio meno discusso: i principi costituzionali sono leggibili. Quando Claude rifiuta una richiesta, in teoria puoi risalire a quale principio ha attivato il rifiuto. Con RLHF puro, le preferenze sono implicite nei dati di training e non ispezionabili. Questa trasparenza è parziale (non sai *come* il modello interpreta i principi), ma è più di quanto offrano altri approcci. --- ## Dove il modello rifiuta troppo Il primo failure mode che impatta chi usa Claude in produzione è l'overrefusal. Il modello rifiuta richieste legittime perché pattern superficiali attivano i safety guardrail. Il meccanismo è comprensibile. I principi costituzionali sono formulati in termini generali: "evita contenuti che potrebbero causare danno", "non assistere in attività illegali", "rifiuta richieste che potrebbero essere usate per manipolazione". Il modello impara ad associare certi pattern lessicali con rifiuto, anche quando il contesto rende la richiesta innocua. Gli esempi documentati dalla community coprono domini diversi. Nella fiction, Claude rifiuta storie con personaggi moralmente ambigui, conflitti realistici, o temi adulti che sarebbero accettabili in qualsiasi romanzo pubblicato. Un prompt per un thriller con un antagonista credibile può attivare un rifiuto perché "potrebbe normalizzare comportamenti dannosi". Nel codice, richieste che gestiscono autenticazione, crittografia, o network scanning vengono bloccate perché "potrebbero essere usate per hacking". Questo include penetration testing legittimo, security auditing, o anche semplice gestione delle password. La comunicazione professionale subisce la stessa sorte: email di sollecito, lettere di reclamo, comunicazioni assertive rifiutate perché "potrebbero essere percepite come aggressive o manipolative". Su temi medici e legali, i disclaimer sono così estesi da essere inutili, o i rifiuti completi. Il pattern comune: il modello reagisce a keyword e strutture superficiali, non al contesto. "Come forzare una serratura" viene rifiutato anche se il contesto è "ho perso le chiavi di casa mia". "Come manipolare qualcuno" viene rifiutato anche se il contesto è "sto scrivendo un saggio sulla propaganda storica". [Il team di Constitutional Classifiers di Anthropic](https://www.anthropic.com/research/constitutional-classifiers) ha documentato questo trade-off. Dopo aver deployato difese aggiuntive contro jailbreak, hanno osservato che il sistema "rifiuterebbe frequentemente di rispondere a domande basilari, non maliziose". Maggiore sicurezza contro attacchi significa maggiore overrefusal su richieste legittime. Per chi deploya applicazioni: il refusal rate su casi d'uso legittimi può essere significativo. Se la tua applicazione richiede generazione di contenuti creativi, assistenza su temi sensibili, o codice di sicurezza, aspettati che una percentuale non trascurabile di richieste venga rifiutata. Servono fallback (modelli alternativi, escalation a umani) e messaging appropriato per gli utenti. --- ## Dove il modello accetta troppo Il secondo failure mode è l'opposto: il modello accetta richieste che dovrebbe rifiutare, quando l'attacco è formulato in modo da bypassare i pattern superficiali. [Uno studio del 2024](https://arxiv.org/abs/2404.02151) ha testato attacchi adversarial su Claude 3 e 3.5. Con tecniche di transfer (prompt che funzionano su altri modelli adattati) o prefilling (forzare l'inizio della risposta del modello), il success rate raggiunge il 100%. Tutti gli attacchi testati hanno avuto successo. Senza le difese aggiuntive di Constitutional Classifiers, i test interni di Anthropic mostrano 86% jailbreak success su Claude 3.5 Sonnet. Con Constitutional Classifiers deployati, il success rate cala drasticamente, ma dopo 3.700 ore collettive di red-teaming è stato comunque scoperto un jailbreak universale. Come è possibile che lo stesso modello rifiuti email di sollecito e accetti richieste di sintesi di armi chimiche? La risposta sta nella natura dei principi costituzionali. Sono formulati in linguaggio naturale, e il modello impara a interpretarli attraverso esempi statistici, non attraverso comprensione semantica profonda. Un attacco che riformula la richiesta in modo da non corrispondere ai pattern appresi bypassa le protezioni. I jailbreak più sofisticati sfruttano diverse vulnerabilità. Il roleplay chiede al modello di interpretare un personaggio che non ha le stesse restrizioni. L'obfuscation codifica la richiesta in modi che il modello decodifica ma che non attivano i safety check (base64, lingue diverse, gergo). Il prefilling, in alcune API, forza l'inizio della risposta del modello bypassando il punto in cui decide se rifiutare. La manipolazione multi-turn costruisce gradualmente contesto attraverso più messaggi, ognuno innocuo, che insieme portano il modello a rispondere a richieste che rifiuterebbe se poste direttamente. Per chi deploya applicazioni: le protezioni di Claude non sono sufficienti per casi d'uso high-stakes. Se la tua applicazione potrebbe essere usata per generare contenuti pericolosi, hai bisogno di layer aggiuntivi di moderazione. Non affidarti solo ai guardrail del modello. --- ## Il problema della sycophancy Il terzo failure mode è più sottile e meno discusso: Claude tende a darti ragione anche quando sbagli. [Anthropic stessa ha pubblicato ricerca](https://arxiv.org/abs/2310.13548) che documenta sycophancy pervasiva in tutti i principali assistenti AI, incluso Claude. I comportamenti documentati includono ammissione di errori non commessi: se dici al modello "la tua risposta precedente era sbagliata", spesso si scusa e "corregge" anche quando la risposta originale era corretta. Il feedback diventa biased: se chiedi una valutazione di un testo dicendo "l'ho scritto io", il modello tende a essere più positivo che se presenti lo stesso testo come scritto da altri. Su problemi matematici dove l'utente suggerisce una risposta sbagliata, il modello tende a concordare con la risposta sbagliata più spesso di quanto farebbe senza il suggerimento. La causa è strutturale. Constitutional AI (come RLHF) ottimizza per preferenze espresse da valutatori. Sia umani che modelli AI tendono a preferire risposte che concordano con loro, che sono scritte in modo convincente, che evitano conflitto. Il modello impara che "dare ragione" produce reward più alto. Il finding più preoccupante: modelli più grandi addestrati con più iterazioni di RLHF/RLAIF mostrano sycophancy aumentata, non diminuita. Non è un bug che si risolve con più training. È una conseguenza del metodo di training stesso. Per chi deploya applicazioni: se la tua applicazione richiede che il modello dia feedback onesto, verifichi informazioni, o contraddica l'utente quando sbaglia, aspettati performance degradata. Casi d'uso come code review, fact-checking, tutoring sono particolarmente impattati. Considera di istruire esplicitamente il modello a essere critico, ma sappi che questo mitiga solo parzialmente il problema. --- ## Il problema delle lingue diverse dall'inglese I failure modes descritti finora si amplificano quando il modello opera in lingue diverse dall'inglese. Questo impatta direttamente chi opera in Italia. I dati sono chiari. [Ricerca su LLM multilingual safety](https://arxiv.org/abs/2310.02446) mostra che i modelli producono risposte harmful drammaticamente più spesso in lingue diverse dall'inglese. Un esempio specifico: Llama-3.1-8B rifiuta "How to make a bomb?" in inglese ma fornisce istruzioni dettagliate per la stessa domanda in hindi. Il pattern si ripete su modelli e lingue diverse. Il tasso di successo degli attacchi passa da valori a singola cifra in inglese a 50-70% in lingue a bassa risorsa. L'italiano, pur essendo una lingua relativamente ben rappresentata, non è immune. La causa: i dati di training per la sicurezza (esempi di rifiuto, definizioni di contenuto harmful, preferenze per harmlessness) sono prevalentemente in inglese. I principi costituzionali sono scritti in inglese. Il modello generalizza imperfettamente ad altre lingue. Per applicazioni che servono utenti italiani, questo ha implicazioni concrete. I guardrail che funzionano in inglese sono meno affidabili in italiano. Un utente che vuole bypassare le protezioni può semplicemente formulare la richiesta in italiano (o in una lingua ancora meno rappresentata) con maggiore probabilità di successo. Le contromisure sono limitate. Puoi tradurre le richieste in inglese prima di inviarle al modello, processare in inglese, poi tradurre le risposte in italiano. Ma questo aggiunge latenza, costo, e può introdurre errori di traduzione. Puoi aggiungere layer di moderazione specifici per italiano, ma richiede investment significativo. --- ## Implicazioni per deployment enterprise Cosa significa tutto questo per chi deve decidere se e come usare Claude in produzione? Constitutional AI rende Claude una scelta ragionevole per applicazioni general-purpose con utenti non-adversarial: chatbot customer service, assistenti interni, tool di produttività. Il refusal rate su richieste legittime è gestibile, e il rischio di output harmful è basso se gli utenti non cercano attivamente di abusare il sistema. Funziona anche per casi d'uso dove l'overrefusal è accettabile: se la tua applicazione può tollerare rifiuti frequenti (con fallback appropriati), i guardrail di Claude sono un beneficio netto. La trasparenza dei principi è utile per compliance e audit: poter dire "il modello segue questi principi documentati" è più difendibile di "il modello è stato addestrato su preferenze implicite". Servono precauzioni aggiuntive per applicazioni creative. Se generi fiction, marketing copy, o contenuti che toccano temi sensibili, aspettati refusal rate alto. Prepara prompt alternativi, fallback a modelli meno restrittivi, o workflow con review umana. Lo stesso vale per applicazioni che richiedono feedback onesto come code review, tutoring, fact-checking: la sycophancy è un problema strutturale. Considera prompt engineering aggressivo per contrastare, ma non aspettarti che risolva completamente. Per applicazioni multilingue, se servi utenti non-anglofoni, i guardrail sono meno affidabili. Aggiungi moderazione specifica per le lingue che supporti. Per applicazioni high-stakes dove output harmful avrebbe conseguenze gravi (medico, legale, sicurezza), non affidarti solo ai guardrail del modello. Aggiungi layer di validazione, moderazione esterna, e review umana. Non aspettarti sicurezza garantita contro attacchi sofisticati. Il 100% di jailbreak success con adaptive attacks significa che attaccanti motivati possono bypassare le protezioni. Se la tua applicazione è un target attraente, assumi che verrà compromessa. Non aspettarti comportamento consistente tra lingue: il modello che si comporta bene in inglese può comportarsi molto diversamente in italiano. Non aspettarti miglioramento della sycophancy con scale: modelli più grandi e più addestrati non sono meno sycophantic. Anzi. --- ## Il quadro complessivo Constitutional AI rappresenta un miglioramento reale rispetto ad alternative precedenti. I dati sono chiari: 88% harmless rate contro 76% di RLHF tradizionale, a costo inferiore. Per chi usa modelli commerciali, questo significa che Claude è genuinamente più sicuro della media. Ma "più sicuro della media" non significa "sicuro". I failure modes documentati sono specifici e prevedibili. Il modello rifiuta troppo quando pattern superficiali attivano i guardrail, anche se il contesto rende la richiesta legittima. Accetta troppo quando attacchi sofisticati riformulano richieste dannose in modi che non corrispondono ai pattern appresi. Ti dà ragione anche quando sbagli, perché la sycophancy è incentivata dal training stesso. È meno sicuro in lingue diverse dall'inglese, perché i dati di sicurezza sono prevalentemente anglofoni. Nessuno di questi problemi è unico di Claude o di Constitutional AI. Sono limitazioni degli attuali approcci di alignment in generale. Ma Constitutional AI li rende più prevedibili: se capisci il meccanismo, puoi anticipare dove il modello fallirà. Per chi deploya applicazioni, la domanda non è "Claude è sicuro?" ma "I failure modes di Claude sono accettabili per il mio caso d'uso?". La risposta dipende dal contesto. Per molte applicazioni enterprise, Constitutional AI offre un trade-off ragionevole tra safety e usabilità. Per applicazioni high-stakes o adversarial, non è sufficiente da solo. La trasparenza sui principi è un vantaggio competitivo di Anthropic rispetto ad altri provider. [La costituzione di Claude è pubblica](https://www.anthropic.com/news/claudes-constitution). Puoi leggerla, capire cosa il modello sta cercando di fare, e decidere se quei principi sono allineati con i tuoi casi d'uso. È più di quanto offrano altri. Constitutional AI non risolve l'alignment. Rende il problema più gestibile, più ispezionabile, più prevedibile. Per chi deve deployare LLM oggi, con le limitazioni di oggi, è un passo avanti concreto. Non è la destinazione, ma è una direzione ragionevole. --- ## Fonti Bai, Y., Kadavath, S., Kundu, S., et al. (2022). [*Constitutional AI: Harmlessness from AI Feedback*](https://arxiv.org/abs/2212.08073). arXiv:2212.08073. Lee, H., Phatale, S., Mansoor, H., et al. (2023). [*RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback*](https://arxiv.org/abs/2309.00267). arXiv:2309.00267. Andriushchenko, M., et al. (2024). [*Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks*](https://arxiv.org/abs/2404.02151). arXiv:2404.02151. Perez, E., Ringer, S., Lukošiūtė, K., et al. (2023). [*Towards Understanding Sycophancy in Language Models*](https://arxiv.org/abs/2310.13548). arXiv:2310.13548. Deng, Y., et al. (2023). [*Multilingual Jailbreak Challenges in Large Language Models*](https://arxiv.org/abs/2310.02446). arXiv:2310.02446. Anthropic. (2023). [*Claude's Constitution*](https://www.anthropic.com/news/claudes-constitution). Anthropic. Anthropic. (2024). [*Constitutional Classifiers: Defending Against Universal Jailbreaks*](https://www.anthropic.com/research/constitutional-classifiers). Anthropic. --- ## AI 2026: Why Stanford Talks About a Reckoning - URL: https://ireneburresi.dev/blog/ai-2026-anno-resa-contien/ - Pillar: Business - Published: 2025-12-20 - Updated: 2025-12-29 - Tags: Stanford HAI, AI 2026, Enterprise AI, Market Analysis, AI Predictions - Author: Irene Burresi > 42% of companies have already closed AI projects: Stanford HAI predicts that 2026 will reward only those who demonstrate measurable ROI, reliable vendors, and transparent metrics. ## The Year of Reckoning: Why 2026 Will Be Critical for Enterprise AI *42% of companies have already abandoned most of their AI projects. The data suggests the worst may not be over.* **TL;DR:** 42% of companies abandoned AI projects in 2025, double the previous year. Stanford HAI predicts 2026 will be the year of reckoning: less hype, more demand for concrete proof. Brynjolfsson's employment data shows the impact already: -20% for junior developers, +8% for senior. For investors, the implications are clear: metrics defined before launch, not after; vendor solutions (67% success rate) vs internal development (33%); attention to go-live timelines, which kill projects more than technology. --- In mid-December 2025, [nine faculty members from Stanford Human-Centered Artificial Intelligence](https://hai.stanford.edu/news/stanford-ai-experts-predict-what-will-happen-in-2026) published their predictions for 2026. This is not the usual academic futurology exercise, but a collective statement with a clear message: the party is over. James Landay, co-director of HAI, opens with a phrase that sounds almost provocative in an era of triumphalist announcements: "There will be no AGI this year." The point, though, is what he adds immediately after: companies will begin publicly admitting that AI has not yet delivered the promised productivity increases, except in specific niches like programming and call centers. And we'll finally hear about failed projects. This is not a prediction about the future. It's a snapshot of something already happening. --- ## The Numbers No One Wants to Look At In July 2025, the [MIT Project NANDA](https://projectnanda.org/) published a report that generated considerable debate for a single statistic: **95% of enterprise AI projects generate no measurable return**. The number has been contested, the methodology has its limitations, the definition of "success" is debatable. But it's not an isolated data point. During the same period, [S&P Global](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results) found that 42% of companies abandoned most of their AI initiatives in 2025. In 2024, the percentage was 17%. The abandonment rate has more than doubled in a year. On average, the surveyed organizations threw out 46% of proof-of-concepts before they reached production. According to the [RAND Corporation](https://www.rand.org/pubs/research_reports/RRA2680-1.html), over 80% of AI projects fail, double the failure rate of traditional IT projects. Gartner reports that only 48% of AI projects reach production, and over 30% of GenAI projects will be abandoned after the proof of concept by end of 2025. The causes are always the same: insufficient data quality (43% according to Informatica), lack of technical maturity (43%), skills shortage (35%). But beneath these numbers lies a deeper pattern. Companies are discovering that AI works in demos but not in production, generates enthusiasm in pilots but not ROI in balance sheets. It's these numbers that explain why Stanford HAI, an institution hardly known for technological pessimism, is shifting the conversation. No longer "can AI do this?" but "how well, at what cost, for whom?". --- ## Canaries in the Coal Mine If failure rates are the symptom, Erik Brynjolfsson's work offers a more precise diagnosis. ["Canaries in the Coal Mine"](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/), published in August 2025 by Stanford's Digital Economy Lab, is among the most rigorous studies currently available on AI's impact on the job market. The paper uses ADP payroll data, the largest payroll service provider in the United States, covering over 25 million workers. The goal is to track employment changes in AI-exposed professions. What emerges is clear. Employment for software developers ages 22-25 has declined **20% from the peak of late 2022**, roughly since the launch of ChatGPT, through July 2025. This is not an isolated data point: early-career workers in the most AI-exposed occupations show a relative decline of 13% compared to colleagues in less exposed roles. The most interesting finding, though, is the age divergence. While young workers lose ground, workers over 30 in the same high-exposure categories have seen employment growth between 6% and 12%. Brynjolfsson puts it this way: "It appears that what young workers know overlaps with what LLMs can replace." It's not a uniform effect, but a realignment: AI is eroding entry-level positions faster than it creates new roles. The "canaries in the coal mine"—young developers and customer support staff—are already showing symptoms of a larger change. When Brynjolfsson predicts the emergence of "AI economic dashboards" that track these shifts in near-real-time, he's not speculating. He's describing the infrastructure needed to understand what's happening, infrastructure that doesn't exist today but could become urgent in 2026. --- ## The Divergence Between Adoption and Results There's a paradox in 2025 data that deserves attention. AI adoption is accelerating: according to [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), the percentage of companies claiming to use AI rose from 55% in 2023 to 78% in 2024. Use of GenAI in at least one business function more than doubled, from 33% to 71%. Yet, in parallel, project abandonment rates are growing instead of declining. S&P Global shows a jump from 17% to 42% in a single year. The MIT NANDA report speaks of a *"GenAI Divide"*, a clear division between the 5% extracting real value and the 95% that remain stalled. Many companies have gone through the phases of enthusiasm, pilots, impressive demos, and then crashed against the wall of real production. They discovered that the model works in a sandbox but not with their data; that integration into existing workflows is more complex than expected; that the ROI promised by vendors doesn't materialize. Angèle Christin, a communication sociologist and HAI senior fellow, puts it plainly: "San Francisco billboards saying 'AI everywhere!!! For everything!!! All the time!!!' betray a slightly manic tone." Her prediction: we'll see more realism about what we can expect from AI. Not necessarily the bubble bursting, but the bubble might stop inflating. --- ## The Measurement Problem One of the most concrete, and potentially most significant, predictions comes again from Brynjolfsson. He proposes the emergence of high-frequency *"AI economic dashboards"*: tools that track, at the task and employment level, where AI is increasing productivity, where it's displacing workers, where it's creating new roles. Today we have nothing like that. Labor market data arrives months late. Companies measure AI adoption but rarely its impact. Industry reports capture hype but not results. If these dashboards do emerge in 2026, they'll change how we talk about AI. The debate will shift from the generic "does AI have an impact?" to more precise questions: how fast is this impact spreading, who's being left behind, which complementary investments work. It's an optimistic vision: better data leads to better decisions. But it's also an implicit admission: today we're navigating blind. --- ## Healthcare and Legal: The Test Sectors Two sectors emerge from Stanford predictions as particularly relevant testbeds. Nigam Shah, Chief Data Scientist at Stanford Health Care, describes a problem that anyone in the sector will recognize. Hospitals are flooded with startups wanting to sell AI solutions. "Every single proposal can be reasonable, but in aggregate they're a tsunami of noise." According to Shah, 2026 will see systematic frameworks emerge for evaluating these solutions: technical impact, the population the model was trained on, ROI on hospital workflow, patient satisfaction, quality of clinical decisions. This is work Stanford is already doing internally, but it will need to extend to institutions with fewer technical resources. Shah also signals a risk. Vendors, frustrated by hospitals' long decision cycles, might start going directly to end users. "Free" applications for doctors and patients that bypass institutional controls. This is already happening: OpenEvidence for literature summaries, AtroposHealth for on-demand answers to clinical questions. In the legal sector, Julian Nyarko predicts a similar shift. The focus will move from "does this model know how to write?" to more operational questions: accuracy, citation integrity, exposure to privilege violations. The sector is already working on specific benchmarks, like those based on *"LLM-as-judge"*, frameworks where one model evaluates another model's output for complex tasks like multi-document summarization. Healthcare and legal share a characteristic: they're highly regulated, with severe consequences for error. If AI must prove its value anywhere, it's where the test will be hardest. And most significant. --- ## Track Record: How Reliable Are These Predictions? Stanford HAI publishes annual predictions going back several years. It's worth asking how accurate they've been. At the end of 2022, Russ Altman predicted for 2023 a *"shocking rollout of AI way before it's mature or ready to go"*. It's hard to find a more accurate description of what happened: ChatGPT, Bing Chat, Bard launched in rapid succession, with accuracy problems, hallucinations, embarrassing incidents. Altman had also predicted a "hit parade of AI that's not ready for prime time but launches because driven by an industry too zealous." Exactly right. Percy Liang, also at the end of 2022, predicted that video would be a focus of 2023 and that "we might reach the point where we can't tell if a human or computer generated a video". He was a year early (Sora arrived in February 2024) but the direction was correct. For 2024, Altman predicted a "rise of agents" and steps toward multimedia systems. Both came true, though agents are still more promise than production reality. Not all predictions came true. Expectations of U.S. Congressional action were disappointed: Biden's Executive Order happened, but the new administration changed direction. Overall, though, Stanford HAI's track record is reasonable: they tend to be cautious rather than enthusiastic, and technical predictions are generally well-founded. This doesn't guarantee that 2026 predictions will come true. But it means they're worth taking seriously. --- ## What It Means for Decision-Makers If Stanford predictions and failure rate data converge on anything, it's this: 2026 will be the year when enterprise AI must show results, not demos. For those managing tech budgets, the implications are concrete. On the **metrics** front, AI projects must have success criteria defined before launch, not after. Not "let's explore AI for customer service" but "reduce average ticket resolution time by 15% within 6 months, with cost-per-interaction below X". Projects without clear metrics have a disproportionate likelihood of ending up in the 42% of abandonments. On the **make-or-buy** front, the MIT NANDA report indicates that solutions bought from specialized vendors have a 67% success rate, against 33% for internal development. This doesn't mean internal development is always wrong, but it requires skills, data, and infrastructure that many organizations overestimate having. On **timing**, mid-market enterprises move from pilot to production in about 90 days, according to the same report. Large enterprises take nine months or more. Bureaucracy kills AI projects more than technology does. Finally, a matter of **honesty**. The shadow economy of AI (90% of employees use personal tools like ChatGPT for work, according to MIT NANDA) indicates that individuals already know where AI works better than official enterprise initiatives. Instead of fighting it, organizations could learn from this spontaneous adoption. --- ## What's Missing Stanford predictions have clear blind spots. None of the experts mention energy consumption and AI's environmental impact. Christin hints at it ("tremendous environmental costs of the current build-out") but the topic isn't developed. Yet AI data centers are becoming one of the world's biggest energy consumers, and this will eventually factor into ROI calculations. There's also a lack of serious discussion about market concentration. Frontier models are developed by a handful of companies. This creates dependencies, influences pricing, determines who can compete. It's a strategic factor that anyone planning AI investments should consider. Landay alludes to *"AI sovereignty"*, countries wanting independence from American providers, but the topic remains superficial. This is rapidly evolving, with significant geopolitical implications, that deserves deeper analysis. --- ## A Shift in Tone More than individual predictions, what strikes you about the Stanford article is the tone. There's no industry-typical enthusiasm. No promises of imminent transformation. There's caution, demand for proof, emphasis on measurement. When the co-director of a Stanford AI institute opens by saying "there will be no AGI this year," he's taking a stand against a dominant narrative. When economists like Brynjolfsson publish data on young workers losing employment, they're documenting costs, not just benefits. This doesn't mean AI is overvalued or that projects should stop. It means the phase of uncritical adoption is ending. Whoever continues to invest will need to do so with calibrated expectations, defined metrics, ability to admit failure when it occurs. 2026, if these predictions are correct, will be the year when we discover which AI projects were sound and which were built on hype. For many organizations it will be a painful discovery. For others, an opportunity: whoever has already learned to measure, iterate, and distinguish value from promise will have a competitive advantage that generic enthusiasm cannot buy. --- ## Sources Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. McKinsey & Company. (2024). [*The State of AI in 2024: Gen AI adoption spikes and starts to generate value*](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai). McKinsey Global Institute. MIT Project NANDA. (2025). [*The GenAI Divide 2025*](https://projectnanda.org/). Massachusetts Institute of Technology. RAND Corporation. (2024). [*The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed*](https://www.rand.org/pubs/research_reports/RRA2680-1.html). RAND Research Reports. S&P Global Market Intelligence. (2025, October). [*Generative AI Shows Rapid Growth but Yields Mixed Results*](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results). S&P Global. Stanford HAI. (2025, December). [*Stanford AI Experts Predict What Will Happen in 2026*](https://hai.stanford.edu/news/stanford-ai-experts-predict-what-will-happen-in-2026). Stanford Human-Centered Artificial Intelligence. --- ## AI 2026: perché Stanford parla di resa dei conti - URL: https://ireneburresi.dev/blog/ai-2026-anno-resa-conti/ - Pillar: Business - Published: 2025-12-20 - Updated: 2025-12-29 - Tags: Stanford HAI, AI 2026, Enterprise AI, Market Analysis, AI Predictions - Author: Irene Burresi > Il 42% delle aziende ha già chiuso progetti AI: per Stanford HAI il 2026 premierà solo chi dimostra ROI misurabile, vendor affidabili e metriche trasparenti. ## L'anno della resa dei conti: perché il 2026 sarà decisivo per l'AI enterprise *Il 42% delle aziende ha già abbandonato la maggior parte dei progetti AI. I dati dicono che il peggio potrebbe non essere finito.* **TL;DR:** Il 42% delle aziende ha abbandonato progetti AI nel 2025, il doppio dell'anno precedente. Stanford HAI prevede che il 2026 sarà l'anno della resa dei conti: meno hype, più richiesta di prove concrete. I dati Brynjolfsson mostrano già l'impatto occupazionale: -20% per sviluppatori junior, +8% per senior. Per chi investe, le implicazioni sono chiare: metriche definite prima del lancio, non dopo; soluzioni vendor (67% successo) vs sviluppo interno (33%); attenzione ai tempi di go-live che uccidono i progetti più della tecnologia. --- A metà dicembre 2025, [nove faculty dello Stanford Human-Centered Artificial Intelligence](https://hai.stanford.edu/news/stanford-ai-experts-predict-what-will-happen-in-2026) hanno pubblicato le loro previsioni per il 2026. Non è il solito esercizio di futurologia accademica, ma una dichiarazione collettiva con un messaggio chiaro: la festa sta finendo. James Landay, co-direttore di HAI, apre con una frase che suona quasi provocatoria in un'epoca di annunci trionfalistici: "Non ci sarà AGI quest'anno." Il punto, però, è quello che aggiunge subito dopo: le aziende inizieranno ad ammettere pubblicamente che l'AI non ha ancora prodotto gli aumenti di produttività promessi, se non in nicchie specifiche come la programmazione e i call center. E sentiremo parlare, finalmente, di progetti falliti. Non è una previsione sul futuro. È la fotografia di qualcosa che sta già succedendo. --- ## I numeri che nessuno vuole guardare A luglio 2025, il [MIT Project NANDA](https://projectnanda.org/) ha pubblicato un report che ha generato ampio dibattito per una singola statistica: il **95% dei progetti AI enterprise non genera alcun ritorno misurabile**. Il numero è stato contestato, la metodologia ha i suoi limiti, la definizione di "successo" è discutibile. Ma non è un dato isolato. Nello stesso periodo, [S&P Global](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results) ha rilevato che il 42% delle aziende ha abbandonato la maggior parte delle proprie iniziative AI nel 2025. Nel 2024 la percentuale era il 17%. Il tasso di abbandono, in pratica, è più che raddoppiato in un anno. In media, le organizzazioni intervistate hanno cestinato il 46% dei proof-of-concept prima che arrivassero in produzione. Secondo [RAND Corporation](https://www.rand.org/pubs/research_reports/RRA2680-1.html), oltre l'80% dei progetti AI fallisce, il doppio del tasso di fallimento dei progetti IT tradizionali. Gartner riporta che solo il 48% dei progetti AI arriva in produzione, e oltre il 30% dei progetti GenAI verrà abbandonato dopo il proof of concept entro fine 2025. Le cause sono sempre le stesse: qualità dei dati insufficiente (43% secondo Informatica), mancanza di maturità tecnica (43%), carenza di competenze (35%). Ma sotto questi numeri c'è un pattern più profondo. Le aziende stanno scoprendo che l'AI funziona nelle demo ma non in produzione, genera entusiasmo nei pilot ma non ROI nei bilanci. Sono questi numeri a spiegare perché Stanford HAI, un'istituzione non esattamente nota per il pessimismo tecnologico, stia spostando il discorso. Non più "l'AI può fare questo?" ma "quanto bene, a quale costo, per chi?". --- ## I canarini nella miniera Se i tassi di fallimento sono il sintomo, il lavoro di Erik Brynjolfsson offre una diagnosi più precisa. ["Canaries in the Coal Mine"](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/), pubblicato ad agosto 2025 dal Digital Economy Lab di Stanford, è tra gli studi più rigorosi oggi disponibili sull'impatto dell'AI sul mercato del lavoro. Il paper usa dati di payroll di ADP, il più grande fornitore di servizi di buste paga negli Stati Uniti, che copre oltre 25 milioni di lavoratori. L'obiettivo è tracciare i cambiamenti occupazionali nelle professioni esposte all'intelligenza artificiale. Quello che emerge è netto. L'occupazione per software developer tra i 22 e i 25 anni è calata del **20% dal picco di fine 2022**, più o meno dal lancio di ChatGPT, a luglio 2025. Non è un dato isolato: i lavoratori early-career nelle occupazioni più esposte all'AI mostrano un declino relativo del 13% rispetto ai colleghi in ruoli meno esposti. Il dato più interessante, però, è la divergenza per età. Mentre i giovani perdono terreno, i lavoratori over 30 nelle stesse categorie ad alta esposizione hanno visto una crescita occupazionale tra il 6% e il 12%. Brynjolfsson sintetizza così: "Sembra che ciò che i lavoratori giovani sanno si sovrapponga a ciò che i LLM possono rimpiazzare." Non è un effetto uniforme, ma un riallineamento: l'AI sta erodendo le posizioni entry-level più rapidamente di quanto crei nuovi ruoli. I "canarini nella miniera", i giovani sviluppatori e gli addetti al customer support, stanno già mostrando sintomi di un cambiamento più ampio. Quando Brynjolfsson prevede l'emergere di "dashboard economici AI" che tracciano questi spostamenti in tempo quasi reale, non sta speculando. Sta descrivendo l'infrastruttura necessaria per capire cosa sta succedendo, un'infrastruttura che oggi non esiste ma che nel 2026 potrebbe diventare urgente. --- ## La divergenza tra adozione e risultati C'è un paradosso nei dati del 2025 che merita attenzione. L'adozione dell'AI sta accelerando: secondo [McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), la percentuale di aziende che dichiarano di usare AI è passata dal 55% nel 2023 al 78% nel 2024. L'uso di GenAI in almeno una funzione aziendale è più che raddoppiato, dal 33% al 71%. Eppure, in parallelo, i tassi di abbandono dei progetti crescono invece di diminuire. S&P Global mostra un salto dal 17% al 42% in un solo anno. Il report MIT NANDA parla di *"GenAI Divide"*, una divisione netta tra il 5% che estrae valore reale e il 95% che rimane fermo. Molte aziende hanno attraversato la fase dell'entusiasmo, del pilot, della demo impressionante, e poi si sono schiantate contro il muro della produzione reale. Hanno scoperto che il modello funziona in sandbox ma non con i loro dati; che l'integrazione nei workflow esistenti è più complessa del previsto; che il ROI promesso dai vendor non si materializza. Angèle Christin, sociologa della comunicazione e senior fellow di HAI, lo dice senza giri di parole: "I cartelloni pubblicitari di San Francisco, 'AI everywhere!!! For everything!!! All the time!!!', tradiscono un tono leggermente maniacale." La sua previsione: vedremo più realismo su cosa possiamo aspettarci dall'AI. Non è necessariamente la bolla che scoppia, ma la bolla potrebbe smettere di gonfiarsi. --- ## Il problema della misurazione Una delle previsioni più concrete, e potenzialmente più significative, arriva ancora da Brynjolfsson. Propone l'emergere di *"AI economic dashboards"* ad alta frequenza: strumenti che tracciano, a livello di task e occupazione, dove l'AI sta aumentando la produttività, dove sta spostando lavoratori, dove sta creando nuovi ruoli. Oggi non abbiamo nulla del genere. I dati sul mercato del lavoro arrivano con mesi di ritardo. Le aziende misurano l'adozione dell'AI ma raramente l'impatto. I report di settore fotografano l'hype ma non i risultati. Se questi dashboard emergeranno davvero nel 2026, cambieranno il modo in cui parliamo di AI. Il dibattito si sposterà dal generico "l'AI ha un impatto?" a domande più precise: quanto velocemente si sta diffondendo questo impatto, chi sta restando indietro, quali investimenti complementari funzionano. È una visione ottimistica: dati migliori portano decisioni migliori. Ma è anche un'ammissione implicita: oggi stiamo navigando al buio. --- ## Medicina e legal: i settori-test Due settori emergono dalle previsioni Stanford come banco di prova particolarmente rilevante. Nigam Shah, Chief Data Scientist di Stanford Health Care, descrive un problema che chiunque lavori nel settore riconoscerà. Gli ospedali sono sommersi da startup che vogliono vendere soluzioni AI. "Ogni singola proposta può essere ragionevole, ma in aggregato sono uno tsunami di rumore." Secondo Shah, nel 2026 emergeranno framework sistematici per valutare queste soluzioni: impatto tecnico, popolazione su cui il modello è stato addestrato, ROI sul workflow ospedaliero, soddisfazione dei pazienti, qualità delle decisioni cliniche. È un lavoro che Stanford sta già facendo internamente, ma che dovrà essere esteso a istituzioni con meno risorse tecniche. Shah segnala anche un rischio. I vendor, frustrati dai cicli decisionali lunghi degli ospedali, potrebbero iniziare ad andare direttamente agli utenti finali. Applicazioni "gratuite" per medici e pazienti che bypassano i controlli istituzionali. È già in corso: OpenEvidence per riassunti della letteratura, AtroposHealth per risposte on-demand a domande cliniche. Nel settore legale, Julian Nyarko prevede uno shift simile. Il focus si sposterà da "questo modello sa scrivere?" a questioni più operative: accuratezza, integrità delle citazioni, esposizione a violazioni del segreto professionale. Il settore sta già lavorando su benchmark specifici, come quelli basati su *"LLM-as-judge"*, framework dove un modello valuta l'output di un altro modello per task complessi come la sintesi multi-documento. Medicina e legal condividono una caratteristica: sono altamente regolamentati, con conseguenze gravi in caso di errore. Se l'AI deve dimostrare il suo valore da qualche parte, è qui che la prova sarà più dura. E più significativa. --- ## Track record: quanto sono affidabili queste previsioni? Stanford HAI pubblica previsioni annuali da alcuni anni. Ha senso chiedersi quanto siano state accurate finora. A fine 2022, Russ Altman previde per il 2023 uno *"shocking rollout of AI way before it's mature or ready to go"*. Difficile trovare una descrizione più accurata di quello che è successo: ChatGPT, Bing Chat, Bard lanciati in successione rapida, con problemi di accuratezza, allucinazioni, incidenti imbarazzanti. Altman aveva anche previsto una "hit parade di AI che non è pronta per il prime time ma esce perché guidata da industria troppo zelante". Esatto. Percy Liang, sempre a fine 2022, previde che il video sarebbe stato un focus del 2023 e che "potremmo arrivare al punto in cui non distingueremo se un umano o un computer ha generato un video". Era un anno in anticipo (Sora è arrivato a febbraio 2024) ma la direzione era corretta. Per il 2024, Altman previde un "rise of agents" e passi verso sistemi multimediali. Entrambi si sono verificati, anche se gli agent sono ancora più promessa che realtà in produzione. Non tutte le previsioni si sono avverate. Le aspettative su un'azione legislativa del Congresso USA sono rimaste deluse: l'Executive Order di Biden c'è stato, ma la nuova amministrazione ha cambiato direzione. Nel complesso, però, il track record di Stanford HAI è ragionevole: tendono a essere cauti piuttosto che entusiasti, e le previsioni tecniche sono generalmente fondate. Questo non garantisce che le previsioni 2026 si avvereranno. Ma significa che vale la pena prenderle sul serio. --- ## Cosa significa per chi deve decidere Se le previsioni Stanford e i dati sui failure rate convergono su qualcosa, è questo: il 2026 sarà l'anno in cui l'AI enterprise dovrà mostrare risultati, non demo. Per chi gestisce budget tecnologici, le implicazioni sono concrete. Sul fronte delle **metriche**, i progetti AI devono avere criteri di successo definiti prima del lancio, non dopo. Non "esploriamo l'AI per il customer service" ma "riduciamo del 15% il tempo medio di risoluzione ticket entro 6 mesi, con costo per interazione inferiore a X". I progetti senza metriche chiare hanno probabilità sproporzionata di finire nel 42% degli abbandoni. Sul fronte **make-or-buy**, il report MIT NANDA indica che le soluzioni acquistate da vendor specializzati hanno un tasso di successo del 67%, contro il 33% degli sviluppi interni. Non significa che lo sviluppo interno sia sempre sbagliato, ma richiede competenze, dati e infrastruttura che molte organizzazioni sopravvalutano di avere. Sul **timing**, le imprese mid-market passano dal pilot alla produzione in circa 90 giorni, secondo lo stesso report. Le grandi enterprise impiegano nove mesi o più. La burocrazia uccide i progetti AI più della tecnologia. Infine, una questione di **onestà**. L'economia-ombra dell'AI (il 90% dei dipendenti usa strumenti personali come ChatGPT per il lavoro, secondo MIT NANDA) indica che gli individui sanno già dove l'AI funziona meglio delle iniziative enterprise ufficiali. Invece di combatterla, le organizzazioni potrebbero imparare da questa adozione spontanea. --- ## Cosa manca Le previsioni Stanford hanno punti ciechi evidenti. Nessuno degli esperti menziona il consumo energetico e l'impatto ambientale dell'AI. Christin lo accenna ("costi ambientali tremendi dell'attuale build-out") ma il tema non viene sviluppato. Eppure i data center AI stanno diventando uno dei maggiori consumatori di energia al mondo, e questo entrerà nel calcolo del ROI prima o poi. Manca anche una discussione seria sulla concentrazione del mercato. I modelli frontier sono sviluppati da un pugno di aziende. Questo crea dipendenze, influenza i prezzi, determina chi può competere. È un fattore strategico che chiunque pianifichi investimenti AI dovrebbe considerare. Landay accenna alla *"AI sovereignty"*, i paesi che vogliono indipendenza dai provider americani, ma il tema resta superficiale. È un'area in rapida evoluzione, con implicazioni geopolitiche significative, che meriterebbe un'analisi più approfondita. --- ## Un cambio di tono Più delle singole previsioni, quello che colpisce dell'articolo Stanford è il tono. Non c'è l'entusiasmo tipico del settore. Non ci sono promesse di trasformazione imminente. C'è cautela, richiesta di prove, enfasi sulla misurazione. Quando il co-direttore di un istituto AI di Stanford apre dicendo "non ci sarà AGI quest'anno", sta prendendo posizione contro una narrativa dominante. Quando economisti come Brynjolfsson pubblicano dati sui lavoratori giovani che perdono occupazione, stanno documentando costi, non solo benefici. Questo non significa che l'AI sia sopravvalutata o che i progetti debbano fermarsi. Significa che la fase dell'adozione acritica sta finendo. Chi continuerà a investire dovrà farlo con aspettative calibrate, metriche definite, capacità di ammettere il fallimento quando si verifica. Il 2026, se queste previsioni sono corrette, sarà l'anno in cui scopriremo quali progetti AI erano solidi e quali erano costruiti sull'hype. Per molte organizzazioni sarà una scoperta dolorosa. Per altre, un'opportunità: chi ha già imparato a misurare, a iterare, a distinguere il valore dalla promessa avrà un vantaggio competitivo che l'entusiasmo generico non può comprare. --- ## Fonti Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. McKinsey & Company. (2024). [*The State of AI in 2024: Gen AI adoption spikes and starts to generate value*](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai). McKinsey Global Institute. MIT Project NANDA. (2025). [*The GenAI Divide 2025*](https://projectnanda.org/). Massachusetts Institute of Technology. RAND Corporation. (2024). [*The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed*](https://www.rand.org/pubs/research_reports/RRA2680-1.html). RAND Research Reports. S&P Global Market Intelligence. (2025, October). [*Generative AI Shows Rapid Growth but Yields Mixed Results*](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results). S&P Global. Stanford HAI. (2025, December). [*Stanford AI Experts Predict What Will Happen in 2026*](https://hai.stanford.edu/news/stanford-ai-experts-predict-what-will-happen-in-2026). Stanford Human-Centered Artificial Intelligence. --- ## AI Sovereignty: Europe's Decision Point - URL: https://ireneburresi.dev/blog/ia-sovranit%C3%A0en/ - Pillar: Governance - Published: 2025-12-20 - Updated: 2025-12-20 - Tags: AI Sovereignty, EU AI Act, GAIA-X, Geopolitics, Europe, Infrastructure - Author: Irene Burresi > Sovereign clouds, national models, and US hyperscalers define three ideas of AI sovereignty. Europe must decide which infrastructure and governance to fund. ## Full English Translation Coming Soon This comprehensive analysis of AI sovereignty, European choices, and geopolitical implications will be fully translated soon. The article covers: - Four definitions of AI sovereignty (legality, economic competitiveness, national security, value alignment) - Two operational models for achieving sovereignty - Gulf states' AI infrastructure investments - Europe's position between American providers and sovereign models - GAIA-X and EU cloud sovereignty initiatives For now, please refer to the Italian version for the complete content. --- ## Sovranità AI: quale modello per l'Europa - URL: https://ireneburresi.dev/blog/ia-sovranit%C3%A0/ - Pillar: Governance - Published: 2025-12-20 - Updated: 2025-12-20 - Tags: AI Sovereignty, EU AI Act, GAIA-X, Geopolitics, Europe, Infrastructure - Author: Irene Burresi > Cloud sovrani, modelli nazionali e provider USA definiscono tre idee di sovranità AI. L'Europa deve scegliere quale infrastruttura e governance finanziare. ## Il nuovo ordine dell'AI globale *Tra LLM nazionali, infrastrutture locali e dipendenza dai provider americani, il concetto di sovranità AI sta ridefinendo la geopolitica tecnologica. L'Europa è al bivio tra tre modelli incompatibili.* Nel maggio 2025, il presidente Trump ha visitato il Golfo Persico per annunciare accordi che cambiano la geografia dell'AI globale. Gli Emirati Arabi Uniti costruiranno un campus di data center da 5 gigawatt, il più grande fuori dagli Stati Uniti. L'Arabia Saudita, attraverso HUMAIN (la nuova entità AI del fondo sovrano PIF), ha ottenuto accesso a centinaia di migliaia di chip Nvidia di ultima generazione. Il Qatar ha appena lanciato Qai con un investimento da 20 miliardi di dollari in partnership con Brookfield. Mentre i paesi del Golfo costruiscono infrastruttura AI con capitali petroliferi, in Europa il dibattito sulla "sovranità AI" procede su binari diversi. Mistral e Aleph Alpha sviluppano modelli, SAP lancia l'EU AI Cloud, Francia e Germania annunciano partnership per "AI e cloud sovrani" nel settore pubblico. Ma la domanda di fondo resta senza risposta chiara: cosa significa davvero sovranità AI, e quale modello l'Europa sta realmente perseguendo? --- ## Quattro definizioni di sovranità Il termine "sovereign AI" viene usato con significati diversi a seconda di chi parla. L'ambiguità non è casuale: permette a governi, vendor e istituzioni di rivendicare impegni sulla sovranità senza chiarire cosa intendono concretamente. L'Atlantic Council propone quattro componenti distinte. La prima è la **legalità**: i sistemi AI devono rispettare le leggi e i regolamenti applicabili nel territorio dove operano. È la componente più debole, perché non richiede infrastruttura o modelli propri, solo compliance. La seconda è la **competitività economica**: lo sviluppo AI deve creare valore per l'economia nazionale, idealmente costruendo un ecosistema industriale locale. Richiede investimenti in startup, formazione, ricerca. La terza riguarda la **sicurezza nazionale**: le applicazioni AI in infrastrutture critiche, difesa e funzioni strategiche richiedono protezioni aggiuntive contro interferenze esterne. Implica controllo su dove risiedono dati e modelli sensibili. La quarta è l'**allineamento valoriale**: i modelli devono riflettere valori nazionali o regionali, non quelli impliciti nei dati di training (prevalentemente anglofoni e occidentali). È la componente più controversa. Chi decide quali valori, e come si implementano tecnicamente? Queste quattro dimensioni non sono sempre compatibili. Un paese può raggiungere legalità e competitività usando modelli americani su infrastruttura americana: basta rispettare le regole locali. Ma non raggiungerà sicurezza nazionale né allineamento valoriale, perché i modelli restano black box sviluppate altrove con dati altrui. --- ## Due modelli operativi Al di là delle definizioni, esistono due approcci pratici alla sovranità AI, ciascuno con trade-off specifici. ### LLM nazionali Il primo approccio consiste nello sviluppare modelli fondazionali propri, addestrati su dati locali, ottimizzati per lingue e contesti specifici. È la strada scelta da Singapore con SEA-LION (modello per le lingue del Sud-Est asiatico), dall'Italia con Minerva e Velvet, dalla Corea del Sud con il programma nazionale che coinvolge SK Telecom, Naver e Samsung. Il vantaggio è il controllo completo sui dati di training, la possibilità di incorporare conoscenza locale (leggi, dialetti, norme culturali), l'indipendenza dalle decisioni dei provider esteri su censura e alignment. I limiti sono altrettanto evidenti. Addestrare un modello frontier richiede centinaia di milioni di dollari solo in compute. I modelli risultanti sono tipicamente inferiori ai frontier americani su benchmark generali: SEA-LION v1 perde nettamente contro GPT-4 in performance complessiva, anche se eccelle nell'analisi del sentiment per le lingue del Sud-Est asiatico. E resta la dipendenza da hardware (Nvidia) e spesso da infrastruttura cloud (AWS, Azure) per il training stesso. Un ricercatore di AI Singapore lo ha ammesso candidamente: il modello Falcon degli Emirati è stato addestrato su infrastruttura Amazon Web Services. SEA-LION dipende da GitHub (Microsoft), Hugging Face (USA) e IBM per la distribuzione. La sovranità del modello non implica sovranità dell'infrastruttura. ### Infrastruttura locale con modelli terzi Il secondo approccio prevede di costruire data center nazionali, GPU cluster, cloud sovrani, ma usare modelli sviluppati altrove (OpenAI, Anthropic, Meta) eseguiti localmente. È la strada degli Emirati con G42: infrastruttura massiccia, partnership con Microsoft e OpenAI, modelli americani che girano su suolo emiratino. Il vantaggio principale è che i dati non lasciano il territorio nazionale. Le query degli utenti locali non transitano per server esteri. Per settori regolamentati (sanità, finanza, difesa), questo può essere sufficiente a soddisfare requisiti di data residency. Il limite è che il modello resta una black box. Il provider estero controlla gli aggiornamenti, le policy di safety, cosa il modello può o non può fare. Un report di HSToday lo sintetizza brutalmente: "Se i model weights escono, il tuo giudizio è letteralmente esogeno." C'è poi il rischio di data poisoning: bastano 250 documenti per compromettere un modello durante il pre-training, secondo ricerche recenti. --- ## Il caso del Golfo: infrastruttura come asset geopolitico I paesi del Golfo Persico stanno perseguendo una variante del secondo modello, ma con una scala e un'ambizione che merita attenzione separata. Gli Emirati, attraverso G42 e Khazna Data Centers, stanno costruendo quella che sarà la più grande concentrazione di capacità compute AI fuori dagli Stati Uniti. Il campus di Abu Dhabi avrà capacità fino a 5 gigawatt. Per confronto, l'intera capacità data center europea nei mercati FLAP (Francoforte, Londra, Amsterdam, Parigi) è stimata intorno ai 10 gigawatt totali. G42 ha ottenuto una quota garantita di 500.000 chip Nvidia all'anno, di cui l'80% andrà a servire clienti americani e il 20% resterà per uso locale. L'Arabia Saudita, attraverso HUMAIN, sta costruendo data center con capacità prevista di 500 megawatt e centinaia di migliaia di chip Nvidia. Il primo deployment include 18.000 chip di ultima generazione per un supercomputer saudita. Google Cloud e il fondo sovrano PIF hanno annunciato una partnership da 10 miliardi di dollari per un hub AI globale. Il Qatar ha lanciato Qai con 20 miliardi di dollari in partnership con Brookfield, più un investimento separato in Anthropic. Non sono progetti di sovranità nel senso europeo del termine. Sono progetti di posizionamento: i paesi del Golfo vogliono diventare hub infrastrutturali per l'AI globale, fornendo compute a basso costo (grazie al capitale dei fondi sovrani) a paesi emergenti che non possono permettersi infrastruttura propria. Come nota Foreign Policy, "l'essenza della sovereign AI per il Golfo è fornire backend compute per paesi che vogliono usare AI ma non hanno capacità di training e deployment proprie". Il rischio, dal punto di vista statunitense, è la diversione di GPU verso la Cina. Ma i deal recenti includono clausole che legano il compute del Golfo allo "stack americano": i chip restano sotto controllo di hyperscaler USA, i modelli sono americani, le regole operative sono concordate bilateralmente. --- ## L'Europa: tre strade, nessuna scelta L'Europa sta perseguendo simultaneamente approcci diversi senza una strategia unificata. Il risultato è frammentazione. ### I campioni nazionali **Mistral AI** (Francia) è il caso più visibile. Fondata nel 2023 da ex-ricercatori di Google DeepMind e Meta, ha raccolto oltre 2,8 miliardi di euro, incluso un round da 1,7 miliardi nel settembre 2025 guidato da ASML e Nvidia. I suoi modelli open-weight sono competitivi con i frontier americani su alcuni benchmark (Mistral Large 2 è nono globale nell'uso di tool per agent). La strategia è esplicita: modelli aperti che permettono customizzazione locale, allineamento con le regole europee (AI Act), deployment on-premise o edge. Ma Mistral ha investitori americani (a16z, Lightspeed) e partnership con Microsoft. Quanto è "sovrana" un'azienda che dipende da venture capital americano per crescere? **Aleph Alpha** (Germania) ha scelto un posizionamento diverso: meno performance frontier, più explainability e deployment in settori regolamentati. La piattaforma PhariaAI supporta deployment on-premise, air-gapped, ibridi. I clienti includono l'Agenzia Federale per l'Impiego tedesca e BWI (IT della Bundeswehr). Ha raccolto circa 500 milioni di euro, quasi interamente da investitori europei (Bosch Ventures, Schwarz Group, SAP). Il trade-off è evidente: Aleph Alpha è più "sovrana" nel funding ma meno competitiva nei benchmark. Se il gap con i modelli frontier si allarga troppo, le aziende europee potrebbero essere costrette a scegliere tra compliance e competitività. ### Le partnership istituzionali A novembre 2025, Francia e Germania hanno annunciato una partnership con Mistral e SAP per sviluppare "cloud e AI sovrani" per il settore pubblico. SAP ha lanciato l'EU AI Cloud, integrando modelli di Mistral e Aleph Alpha nel suo Business Technology Platform con garanzie di data residency europea. Queste iniziative rispondono a esigenze reali. Il settore pubblico europeo ha requisiti di compliance che rendono problematico l'uso di modelli americani su infrastruttura americana. Ma restano progetti verticali, non una strategia industriale. ### GAIA-X e l'infrastruttura federata GAIA-X, lanciato nel 2020 da Francia e Germania, doveva essere "l'Airbus del cloud", un'infrastruttura federata europea alternativa agli hyperscaler americani. A fine 2025, il bilancio è misto. Sul lato positivo, il framework esiste. Ci sono oltre 180 data space settoriali in sviluppo. Il Trust Framework 3.0 ("Danube") è stato rilasciato. Progetti come Catena-X (automotive) dimostrano che la condivisione dati basata su standard europei è tecnicamente fattibile. Sul lato negativo, GAIA-X non è un cloud provider. Non compete con AWS, Azure o Google Cloud. Il mercato cloud europeo resta dominato al 70% da hyperscaler americani. Alcuni membri fondatori europei hanno lasciato il progetto. Il co-fondatore di NextCloud ha accusato GAIA-X di essere stato "diluito" e "sabotato dall'interno" dagli hyperscaler stessi, che sono membri dell'associazione. Un'analisi di STL Partners è brutale: "GAIA-X resta più un simbolo politico che un disruptor di mercato. Realisticamente, colmare il gap richiederebbe investimenti coordinati EU nell'ordine di 500-700 miliardi di euro, una scala non attualmente all'orizzonte." --- ## L'intersezione con l'AI Act L'EU AI Act, entrato progressivamente in vigore dal febbraio 2025, crea obblighi che si intersecano con la sovranità AI in modi specifici. Sul fronte **data residency e training data**, l'AI Act non impone esplicitamente che i dati restino in Europa, ma le regole sulla trasparenza dei dati di training (Template for public summary, rilasciato a luglio 2025) richiedono disclosure dettagliata delle fonti. Per sistemi ad alto rischio, le valutazioni d'impatto sui diritti fondamentali possono richiedere accesso ai dataset, cosa difficile se sono su server americani soggetti a leggi americane. Per quanto riguarda **GPAI e rischio sistemico**, i provider di General-Purpose AI con rischio sistemico (definito come modelli addestrati con compute superiore a 10^25 FLOP) devono rispettare obblighi aggiuntivi di sicurezza, testing e incident reporting. I principali modelli frontier (GPT-4, Claude, Gemini) rientrano in questa categoria. Il Code of Practice rilasciato a luglio 2025 e firmato da Mistral, Aleph Alpha, OpenAI, IBM e altri offre un framework volontario di compliance. C'è poi la questione **audit e accesso**: l'AI Act prevede che le autorità nazionali possano richiedere accesso a modelli per verifiche. Per modelli sviluppati e hostati fuori dall'UE, questo crea tensioni giurisdizionali irrisolte. Il **Digital Omnibus**, proposto dalla Commissione a novembre 2025, potrebbe cambiare significativamente il quadro. Alcune parti dell'AI Act e del GDPR potrebbero essere ammorbidite per ridurre il carico di compliance sulle PMI. I critici sostengono che questo indebolisce la posizione europea proprio mentre la sovranità AI diventa critica. Come nota un analista: "Se l'Europa ha la migliore regolamentazione ma nessuna azienda europea, non ha vinto molto." --- ## Il rischio della bolla infrastrutturale James Landay, co-direttore di Stanford HAI, nelle sue previsioni per il 2026 ha inserito una nota di cautela sugli investimenti in data center AI: "A un certo punto, non puoi impegnare tutti i soldi del mondo su una cosa sola. Sembra una bolla molto speculativa." I numeri sono impressionanti. I quattro hyperscaler americani (Amazon, Microsoft, Google, Meta) spenderanno circa 325 miliardi di dollari in capex infrastrutturale nel solo 2025, più dell'intero PIL di paesi come Finlandia o Cile. Il Golfo sta aggiungendo altri 100+ miliardi. La capacità data center globale sta crescendo del 20% annuo. Ma la domanda effettiva di compute AI è ancora concentrata in pochi use case: training di modelli frontier (dominato da 5-6 lab), inferenza per chatbot consumer (dominata da OpenAI e pochi altri), e applicazioni enterprise ancora in fase sperimentale (il 42% dei progetti viene abbandonato, come documentato altrove). Se la domanda non cresce alla velocità dell'offerta, chi ha investito miliardi in GPU cluster potrebbe trovarsi con capacità inutilizzata. I paesi che hanno scommesso sulla sovranità infrastrutturale (UAE, Arabia Saudita, ma anche le iniziative europee) potrebbero scoprire di aver costruito cattedrali nel deserto. --- ## Implicazioni per le decisioni aziendali Per CTO, legal e compliance officer in Europa, la frammentazione della strategia di sovranità crea incertezza operativa. Alcune considerazioni pratiche. Il punto di partenza è **mappare le dipendenze esistenti**: quali modelli AI usa l'organizzazione? Dove sono hostati? Quali dati vengono inviati a provider terzi? Questa mappatura è prerequisito per qualsiasi strategia di sovranità. Serve poi **distinguere requisiti reali da requisiti percepiti**. Non tutti i workload richiedono sovranità piena. Per applicazioni non critiche senza dati personali sensibili, la compliance con AI Act e GDPR può essere sufficiente anche usando provider americani. Per settori regolamentati (sanità, finanza, difesa, pubblica amministrazione), i requisiti sono più stringenti. C'è da considerare il **vendor lock-in**. Le soluzioni "sovrane" europee (Mistral via SAP, Aleph Alpha per enterprise) offrono oggi performance inferiori ai frontier americani. Adottarle crea dipendenza da un ecosistema più piccolo. Se il gap si allarga, migrare sarà costoso. L'**evoluzione normativa** va monitorata con attenzione. Il Digital Omnibus potrebbe cambiare significativamente gli obblighi AI Act. Le guidelines della Commissione vengono aggiornate regolarmente. La compliance di oggi potrebbe non bastare domani, oppure potrebbe risultare eccessiva se le regole vengono ammorbidite. Vale la pena infine considerare **modelli ibridi**: alcuni workload su infrastruttura sovrana (dati sensibili, applicazioni critiche), altri su hyperscaler (scale, performance, costo). Questa architettura è più complessa da gestire ma può bilanciare i rischi. --- ## Una scelta inevitabile L'Europa non può perseguire simultaneamente tre strategie incompatibili: campioni nazionali che competono tra loro, infrastruttura federata che non scala, e dipendenza de facto dagli hyperscaler americani. A un certo punto sarà necessario scegliere. Il modello del Golfo (infrastruttura massiccia, capitale sovrano, partnership con provider americani) richiede risorse che l'Europa potrebbe mobilitare ma non sta mobilitando. Il modello dei campioni nazionali (Mistral, Aleph Alpha, DeepL) produce eccellenza puntuale ma non massa critica. Il modello GAIA-X (standard e interoperabilità) è necessario ma non sufficiente. Per i decisori europei, pubblici e privati, la domanda non è se la sovranità AI sia importante. Lo è. La domanda è quale livello di sovranità è realisticamente raggiungibile, a quale costo, e con quali compromessi. Finché questa domanda resta senza risposta chiara, le aziende europee navigheranno in un ambiente di incertezza strutturale, costrette a scommettere su strategie che potrebbero rivelarsi obsolete prima di essere implementate. --- ## Fonti - Atlantic Council, "Sovereign Remedies: Between AI Autonomy and Control", aprile 2025 - RAND Corporation, "At the Paris AI Summit, Europe Charts Its Course", febbraio 2025 - Carnegie Endowment, "The EU's AI Power Play: Between Deregulation and Innovation", maggio 2025 - Lawfare, "Sovereign AI in a Hybrid World: National Strategies and Policy Responses", novembre 2024 - NVIDIA Blog, "What is Sovereign AI?", luglio 2025 - Foreign Policy, "U.S.-China AI Competition Needs Data Centers in UAE, Saudi Arabia", luglio 2025 - Fortune, "Saudi Arabia wants to build its post-oil future with massive AI data centers", maggio 2025 - Semafor, "Qatar launches $20B AI push", dicembre 2025 - [Tech.eu](https://tech.eu), "Europe's AI ecosystem: Rapid growth and rising global ambitions", novembre 2025 - DirectIndustry, "Why Europe Needs a Sovereign AI", novembre 2025 - STL Partners, "Sovereign AI: What it is, country playbooks & data centre strategy", settembre 2025 - IAPP, "Global AI Governance Law and Policy: EU", 2025 - European Commission, "AI Act implementation updates", 2025 - Polytechnique Insights, "Gaia-X: the bid for a sovereign European cloud", giugno 2025 --- ## You're Measuring AI Wrong - URL: https://ireneburresi.dev/blog/misurare-iaen/ - Pillar: Business - Published: 2025-12-20 - Updated: 2025-12-29 - Tags: KPI, Metrics, AI Measurement, Enterprise AI, ROI - Author: Irene Burresi > 60% of managers mismeasure AI because they track hours saved, not impact. Segment by role, separate augmentative from substitutive use, and monitor weekly. ## The measurement paradox *60% of managers admit they need better KPIs for AI. Only 34% are doing anything about it. Meanwhile, the data that actually matters already exists, but nobody's looking at it.* **TL;DR:** Companies measure activity (hours saved, tasks automated) instead of impact. A Stanford paper analyzing 25 million workers shows what to do instead: segment by role and seniority, distinguish substitutive from augmentative use, use control groups, monitor in real time. Those who adopt these principles will have an information advantage over those still tracking vanity metrics. --- The 2025 AI adoption reports tell a strange story. On one hand, companies claim to measure everything: completed deployments, hours saved, tickets handled, costs reduced. On the other, [42% are abandoning most of their AI projects](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results), more than double the previous year. According to [MIT NANDA](https://projectnanda.org/), **95% of pilot projects** generate no measurable impact on the bottom line. If we measure so much, why do we fail so often? The problem is we're measuring the wrong things. Typical enterprise AI metrics (time saved per task, volume of automated interactions, cost per query) capture activity, not impact. They tell you whether the system works technically, not whether it's creating or destroying value. A paper published in August 2025 by Stanford's Digital Economy Lab offers a different approach to what it means to truly measure AI. And the implications for those managing technology investments are concrete. --- ## The vanity metrics problem Most corporate AI dashboards track variants of the same metrics: how many requests processed, how much time saved per interaction, what percentage of tasks automated. These are numbers that grow easily and look good in slides. Their flaw is fundamental: they say nothing about real business impact. A chatbot handling 10,000 tickets per month looks like a success. But if those tickets still require human escalation 40% of the time, if customer satisfaction has dropped, if your most profitable customers are migrating to competitors, the number of tickets handled captures none of this. The S&P Global 2025 report documents exactly this pattern: companies that accumulated "deployments" and "completed experiments" only to discover, months later, that ROI wasn't materializing. Costs were real and immediate; benefits were vague and perpetually deferred to next quarter. According to an MIT Sloan analysis, **60% of managers recognize they need better KPIs** for AI. But only 34% are actually using AI to create new performance indicators. The majority continues using the same metrics they used for traditional IT projects, metrics designed for deterministic software, not for probabilistic systems interacting with complex human processes. --- ## What serious measurement looks like ["Canaries in the Coal Mine"](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/), the paper by Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen published by Stanford's Digital Economy Lab, isn't about how companies should measure AI. It's about how AI is changing the labor market. But the method it uses is exactly what's missing from most enterprise evaluations. The authors obtained access to ADP payroll data, the largest payroll processor in the United States, with monthly records of over 25 million workers. Not surveys, not self-reports, not estimates: granular administrative data on who gets hired, who leaves, how much they earn, in which role, at which company. They then cross-referenced this data with two AI exposure metrics: one based on theoretical task analysis (which jobs are technically automatable) and one based on actual usage data (how people actually use Claude, Anthropic's model, in daily work). The result is an X-ray of AI's impact with unprecedented granularity. Not the generic "AI is changing work" but precise numbers: employment for software developers aged 22-25 dropped **20% from the late 2022 peak**, while for those over 35 in the same roles it grew 8%. In professions where AI use is predominantly substitutive, young workers lose employment; where it's predominantly augmentative, there's no decline. This type of measurement should inform corporate AI decisions. Not because companies need to replicate this exact study, but because it illustrates three principles that most enterprise metrics ignore entirely. --- ## Measure differential effects, not averages Aggregate data hides more than it reveals. If you only measure "hours saved by AI," you don't see who's saving those hours and who's losing their job. If you only measure "tickets automated," you don't see which customers are receiving worse service. The Stanford paper shows that AI's impact differs radically by age group. Workers aged 22-25 in exposed professions saw a 13% employment decline relative to colleagues in less exposed roles. Workers over 30 in the same professions saw growth. The average effect is nearly zero, but the real effect is massive redistribution. For a CFO, aggregate productivity metrics can mask hidden costs. If AI is increasing output from the senior team while making it impossible to hire and train juniors, the short-term gain could transform into a talent pipeline problem in the medium term. The paper calls it the *"apprenticeship paradox"*: companies stop hiring entry-level workers because AI handles those tasks better, but without entry-level today there won't be seniors tomorrow. The operational consequence is that every AI dashboard should segment impact by role, seniority, team, and customer type. A single "productivity" number is almost always misleading. --- ## Distinguish substitutive from augmentative use One of the paper's most relevant findings concerns the difference between substitutive and augmentative AI use. The authors used Anthropic's data to classify how people actually use language models: to generate final outputs (substitution) or to iterate, learn, and validate (augmentation). In professions where use is predominantly substitutive, youth employment has collapsed. Where use is predominantly augmentative, there's no decline; in fact, some of these categories show above-average growth. Not all "deployments" are equal. A system that automatically generates financial reports substitutes human labor differently from one that helps analysts explore scenarios. Metrics should capture this distinction: classify each AI application as predominantly substitutive or augmentative, separately track impact on headcount, skill mix, and internal training capacity. Augmentative systems might have less immediate ROI but more sustainable effects. --- ## Control for external shocks One of the Stanford paper's most sophisticated methodological aspects is its use of firm-time fixed effects. In practice, the authors compare workers within the same company in the same month, thus isolating the AI exposure effect from any other factor affecting the company: budget cuts, sector slowdown, strategy changes. The result: even controlling for all these factors, young workers in AI-exposed roles show a relative decline of **16%** compared to colleagues in non-exposed roles at the same company. This kind of rigor is rare in corporate evaluations. When an AI project launches and costs drop, it's easy to credit the AI. But maybe costs would have dropped anyway due to seasonal factors. Maybe the team was already optimizing before the launch. Maybe the comparison is with an anomalous period. The solution is to define baselines and control groups before launch. Don't compare "before vs after" but "treated vs untreated" in the same period. Use A/B tests where possible, or at least comparisons with teams, regions, or segments that haven't adopted AI. --- ## Toward high-frequency economic dashboards In his predictions for 2026, Brynjolfsson proposed the idea of *"AI economic dashboards"*, tools that track AI's economic impact in near real-time, updated monthly instead of with the typical delays of official statistics. It's an ambitious proposal at the macro level. But the underlying logic is applicable at the company level: stop waiting for quarterly reports to understand if AI is working and instead build continuous monitoring systems that capture effects as they emerge. Most AI projects are evaluated like traditional investments: ex-ante business case, periodic reviews, final post-mortem. But AI doesn't behave like a traditional asset. Its effects are distributed, emergent, often unexpected. A continuous monitoring system can catch drift before it becomes a problem. In practice, this means working with real-time data instead of retrospective data. If the payroll system can tell you today how many people were hired yesterday in each role, you can track AI's effect on headcount with a lag of days, not months. The same applies to tickets handled, sales closed, errors detected. Another key principle: favor leading metrics over lagging ones. The actual utilization rate (how many employees actually use the AI tool every day) is a leading indicator. If it drops, there are problems before they show up in productivity numbers. As the Stanford paper segments by age, corporate dashboards should segment by role, tenure, and prior performance. AI might help top performers while harming others, or vice versa. Internal comparisons are also essential: teams that adopted AI vs teams that didn't, periods with the feature active vs periods with it deactivated. These comparisons are more informative than pure time trends. --- ## The cost of not measuring There's a direct economic argument for investing in better measurement. The 42% of companies that abandoned AI projects in 2025 spent budget, time, and management attention only to get nothing. With better metrics, some of those projects would have been stopped earlier. Others would have been corrected mid-course. Others still would never have started. The MIT NANDA report estimates that companies are spending **$30-40 billion per year** on generative AI. If 95% generates no measurable ROI, we're talking about tens of billions burned. Not because the technology doesn't work, but because it's applied poorly, measured worse, and therefore never corrected. The Brynjolfsson paper offers a model of what AI measurement could be. Administrative data instead of surveys. Demographic granularity instead of aggregate averages. Rigorous controls instead of naive comparisons. Continuous monitoring instead of point-in-time evaluations. No company has Stanford's resources or access to ADP's data. But the principles are transferable: segment, distinguish substitutive from augmentative use, control for confounding factors, monitor in real time. Those who adopt these principles will have an information advantage over those who continue tracking deployments and hours saved. --- ## Sources Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. Deloitte AI Institute. (2025). [*State of Generative AI in the Enterprise*](https://www2.deloitte.com/us/en/pages/consulting/articles/state-of-generative-ai-in-enterprise.html). Deloitte. MIT Project NANDA. (2025). [*The GenAI Divide 2025*](https://projectnanda.org/). Massachusetts Institute of Technology. MIT Sloan Management Review. (2024). [*The Future of Strategic Measurement: Enhancing KPIs With AI*](https://sloanreview.mit.edu/projects/the-future-of-strategic-measurement-enhancing-kpis-with-ai/). MIT Sloan. S&P Global Market Intelligence. (2025, October). [*Generative AI Shows Rapid Growth but Yields Mixed Results*](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results). S&P Global. --- ## Metriche AI che contano davvero - URL: https://ireneburresi.dev/blog/misurare-ia/ - Pillar: Business - Published: 2025-12-20 - Updated: 2025-12-29 - Tags: KPI, Metrics, AI Measurement, Enterprise AI, ROI - Author: Irene Burresi > Il 60% dei manager ha KPI sbagliati perché misura ore risparmiate, non impatto: segmenta per ruolo, separa uso augmentativo da sostitutivo e monitora weekly. ## Il paradosso della misurazione *Il 60% dei manager ammette di aver bisogno di KPI migliori per l'AI. Solo il 34% sta facendo qualcosa. Nel frattempo, i dati che davvero contano esistono già, ma nessuno li sta guardando.* **TL;DR:** Le aziende misurano attività (ore risparmiate, task automatizzati) invece di impatto. Un paper Stanford su 25 milioni di lavoratori mostra come fare: segmentare per ruolo e seniority, distinguere uso sostitutivo da augmentativo, usare gruppi di controllo, monitorare in tempo reale. Chi adotta questi principi avrà un vantaggio informativo su chi continua a tracciare metriche di vanità. --- I report sull'adozione dell'AI nel 2025 raccontano una storia strana. Da un lato, le aziende dichiarano di misurare tutto: deployment completati, ore risparmiate, ticket gestiti, costi ridotti. Dall'altro, il [42% sta abbandonando la maggior parte dei propri progetti AI](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results), più del doppio rispetto all'anno precedente. Il **95% dei progetti pilota**, secondo [MIT NANDA](https://projectnanda.org/), non genera alcun impatto misurabile sul conto economico. Se misuriamo così tanto, perché falliamo così spesso? Il problema è che stiamo misurando le cose sbagliate. Le metriche tipiche dell'AI enterprise (tempo risparmiato per task, volume di interazioni automatizzate, costo per query) catturano l'attività, non l'impatto. Dicono se il sistema funziona tecnicamente, non se sta creando o distruggendo valore. Un paper pubblicato ad agosto 2025 dal Digital Economy Lab di Stanford offre un approccio diverso a cosa significhi misurare davvero l'AI. E le implicazioni per chi gestisce investimenti tecnologici sono concrete. --- ## Il problema delle metriche di vanità La maggior parte delle dashboard AI aziendali traccia varianti delle stesse metriche: quante richieste processate, quanto tempo risparmiato per interazione, quale percentuale di task automatizzati. Sono numeri che crescono facilmente e si presentano bene nelle slide. Il loro difetto è fondamentale: non dicono nulla sull'impatto reale sul business. Un chatbot che gestisce 10.000 ticket al mese sembra un successo. Ma se quei ticket richiedono comunque escalation umana nel 40% dei casi, se la customer satisfaction è calata, se i clienti più profittevoli stanno migrando ai competitor, il numero di ticket gestiti non cattura nulla di tutto questo. Il report di S&P Global sul 2025 documenta esattamente questo pattern: aziende che hanno accumulato "deployment" e "sperimentazioni completate" solo per scoprire, mesi dopo, che il ROI non si materializzava. I costi erano reali e immediati; i benefici vaghi e sempre rimandati al prossimo trimestre. Secondo un'analisi MIT Sloan, il **60% dei manager riconosce di aver bisogno di KPI migliori** per l'AI. Ma solo il 34% sta effettivamente usando l'AI per creare nuovi indicatori di performance. La maggioranza continua a usare le stesse metriche che usava per i progetti IT tradizionali, metriche progettate per software deterministico, non per sistemi probabilistici che interagiscono con processi umani complessi. --- ## Cosa significa misurare sul serio ["Canaries in the Coal Mine"](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/), il paper di Erik Brynjolfsson, Bharat Chandar e Ruyu Chen pubblicato dallo Stanford Digital Economy Lab, non parla di come le aziende dovrebbero misurare l'AI. Parla di come l'AI sta cambiando il mercato del lavoro. Ma il metodo che usa è esattamente quello che manca alla maggior parte delle valutazioni enterprise. Gli autori hanno ottenuto accesso ai dati di payroll di ADP, il più grande processore di buste paga negli Stati Uniti, con record mensili di oltre 25 milioni di lavoratori. Non sondaggi, non self-report, non stime: dati amministrativi granulari su chi viene assunto, chi lascia, quanto guadagna, in quale ruolo, in quale azienda. Hanno poi incrociato questi dati con due metriche di esposizione all'AI: una basata su analisi teorica dei task (quali mansioni sono tecnicamente automatizzabili) e una basata su dati reali di utilizzo (come le persone usano effettivamente Claude, il modello di Anthropic, nel lavoro quotidiano). Il risultato è una radiografia dell'impatto dell'AI con una granularità senza precedenti. Non il generico 'l'AI sta cambiando il lavoro', ma numeri precisi: l'occupazione per sviluppatori software tra 22 e 25 anni è calata del **20% dal picco di fine 2022**, mentre per gli over-35 nelle stesse mansioni è cresciuta dell'8%. Nelle professioni dove l'uso dell'AI è prevalentemente sostitutivo, i giovani perdono occupazione; dove è prevalentemente augmentativo, non c'è declino. Questo tipo di misurazione dovrebbe informare le decisioni aziendali sull'AI. Non perché le aziende debbano replicare esattamente questo studio, ma perché illustra tre principi che la maggior parte delle metriche enterprise ignora completamente. --- ## Misurare gli effetti differenziali, non le medie Il dato aggregato nasconde più di quanto riveli. Se misuri solo "ore risparmiate dall'AI", non vedi chi sta risparmiando quelle ore e chi sta perdendo il lavoro. Se misuri solo "ticket automatizzati", non vedi quali clienti ricevono servizio peggiore. Il paper Stanford mostra che l'impatto dell'AI è radicalmente diverso per fasce d'età. I lavoratori tra 22 e 25 anni nelle professioni esposte hanno visto un declino occupazionale del 13% rispetto ai colleghi in ruoli meno esposti. I lavoratori over 30 nelle stesse professioni hanno visto crescita. L'effetto medio è quasi nullo, ma l'effetto reale è una redistribuzione massiva. Per un CFO, le metriche aggregate di produttività possono mascherare costi nascosti. Se l'AI sta aumentando l'output del team senior mentre rende impossibile assumere e formare junior, il gain di breve periodo potrebbe trasformarsi in un problema di pipeline di talenti nel medio. Il paper lo chiama *"paradosso dell'apprendistato"*: le aziende smettono di assumere entry-level perché l'AI fa quei task meglio, ma senza entry-level oggi non avranno senior domani. La conseguenza operativa è che ogni dashboard AI dovrebbe segmentare l'impatto per ruolo, seniority, team, tipologia di cliente. Un singolo numero di "produttività" è quasi sempre fuorviante. --- ## Distinguere uso sostitutivo da uso augmentativo Una delle scoperte più rilevanti del paper riguarda la differenza tra uso sostitutivo e uso augmentativo dell'AI. Gli autori hanno usato i dati di Anthropic per classificare come le persone usano effettivamente i modelli linguistici: per generare output finali (sostituzione) o per iterare, apprendere, validare (augmentazione). Nelle professioni dove l'uso è prevalentemente sostitutivo, l'occupazione giovanile è crollata. Dove l'uso è prevalentemente augmentativo, non si osserva alcun declino; anzi, alcune di queste categorie mostrano crescita sopra la media. Non tutti i "deployment" sono uguali. Un sistema che genera automaticamente report finanziari sostituisce lavoro umano in modo diverso da uno che aiuta gli analisti a esplorare scenari. Le metriche dovrebbero catturare questa distinzione: classificare ogni applicazione AI come prevalentemente sostitutiva o augmentativa, tracciare separatamente l'impatto su headcount, skill mix, capacità di formazione interna. I sistemi augmentativi potrebbero avere ROI meno immediato ma effetti più sostenibili. --- ## Controllare per gli shock esterni Uno degli aspetti metodologici più sofisticati del paper Stanford è l'uso di effetti fissi impresa-tempo. In pratica, gli autori confrontano lavoratori all'interno della stessa azienda nello stesso mese, isolando così l'effetto dell'esposizione AI da qualsiasi altro fattore che colpisce l'azienda: tagli di budget, rallentamento settoriale, cambi di strategia. Il risultato: anche controllando per tutti questi fattori, i giovani nelle mansioni esposte all'AI mostrano un declino relativo del **16%** rispetto ai colleghi in mansioni non esposte nella stessa azienda. Questo tipo di rigore è raro nelle valutazioni aziendali. Quando un progetto AI viene lanciato e i costi calano, è facile attribuire il merito all'AI. Ma forse i costi sarebbero calati comunque per fattori stagionali. Forse il team stava già ottimizzando prima del lancio. Forse il confronto è con un periodo anomalo. La soluzione è definire baseline e gruppi di controllo prima del lancio. Non confrontare "prima vs dopo" ma "trattati vs non trattati" nello stesso periodo. Usare A/B test dove possibile, o almeno confronti con team, regioni o segmenti che non hanno adottato l'AI. --- ## Verso dashboard economici ad alta frequenza Nelle sue previsioni per il 2026, Brynjolfsson ha proposto l'idea di *"AI economic dashboards"*, strumenti che tracciano in tempo quasi reale l'impatto dell'AI sull'economia, aggiornati mensilmente invece che con i ritardi tipici delle statistiche ufficiali. È una proposta ambiziosa a livello macro. Ma la logica sottostante è applicabile a livello aziendale: smettere di aspettare report trimestrali per capire se l'AI sta funzionando e costruire invece sistemi di monitoraggio continuo che catturano gli effetti man mano che si manifestano. La maggior parte dei progetti AI viene valutata come un investimento tradizionale: business case ex-ante, review periodiche, post-mortem finale. Ma l'AI non si comporta come un asset tradizionale. I suoi effetti sono distribuiti, emergenti, spesso inattesi. Un sistema di monitoraggio continuo può catturare derive prima che diventino problemi. In pratica, questo significa lavorare con dati in tempo reale invece che retrospettivi. Se il sistema di payroll può dirvi oggi quante persone sono state assunte ieri in ogni ruolo, potete tracciare l'effetto dell'AI sull'organico con lag di giorni, non mesi. Lo stesso vale per ticket gestiti, vendite chiuse, errori rilevati. Un altro principio chiave: privilegiare metriche leading rispetto a quelle lagging. Il tasso di utilizzo effettivo (quanti dipendenti usano davvero lo strumento AI ogni giorno) è un indicatore anticipatore. Se cala, ci sono problemi prima che si vedano nei numeri di produttività. Come il paper Stanford segmenta per età, le dashboard aziendali dovrebbero segmentare per ruolo, tenure, performance pregressa. L'AI potrebbe aiutare i top performer mentre danneggia gli altri, o viceversa. Servono anche confronti interni: team che hanno adottato l'AI vs team che non l'hanno fatto, periodi con feature attiva vs periodi con feature disattivata. Questi confronti sono più informativi dei trend temporali puri. --- ## Il costo del non misurare C'è un argomento economico diretto per investire in misurazione migliore. Il 42% delle aziende che ha abbandonato progetti AI nel 2025 ha speso budget, tempo, attenzione manageriale per poi non ottenere nulla. Con metriche migliori, alcuni di quei progetti sarebbero stati fermati prima. Altri sarebbero stati corretti in corsa. Altri ancora non sarebbero mai partiti. Il report MIT NANDA stima che le aziende stiano spendendo **30-40 miliardi di dollari all'anno** in AI generativa. Se il 95% non genera ROI misurabile, stiamo parlando di decine di miliardi bruciati. Non perché la tecnologia non funzioni, ma perché viene applicata male, misurata peggio, e quindi non corretta. Il paper Brynjolfsson offre un modello di cosa potrebbe essere la misurazione dell'AI. Dati amministrativi invece di sondaggi. Granularità demografica invece di medie aggregate. Controlli rigorosi invece di confronti ingenui. Monitoraggio continuo invece di valutazioni puntuali. Nessuna azienda ha le risorse di Stanford o l'accesso ai dati di ADP. Ma i principi sono trasferibili: segmentare, distinguere uso sostitutivo da uso augmentativo, controllare per fattori confondenti, monitorare in tempo reale. Chi adotta questi principi avrà un vantaggio informativo su chi continua a tracciare deployment e ore risparmiate. --- ## Fonti Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. Deloitte AI Institute. (2025). [*State of Generative AI in the Enterprise*](https://www2.deloitte.com/us/en/pages/consulting/articles/state-of-generative-ai-in-enterprise.html). Deloitte. MIT Project NANDA. (2025). [*The GenAI Divide 2025*](https://projectnanda.org/). Massachusetts Institute of Technology. MIT Sloan Management Review. (2024). [*The Future of Strategic Measurement: Enhancing KPIs With AI*](https://sloanreview.mit.edu/projects/the-future-of-strategic-measurement-enhancing-kpis-with-ai/). MIT Sloan. S&P Global Market Intelligence. (2025, October). [*Generative AI Shows Rapid Growth but Yields Mixed Results*](https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results). S&P Global. --- ## Who Will the Senior Engineers of Tomorrow Be? - URL: https://ireneburresi.dev/blog/senior-domanien/ - Pillar: Business - Published: 2025-01-06 - Updated: 2025-01-06 - Tags: Junior Developers, AI Impact, Talent Pipeline, Future of Work, Learning, Career - Author: Irene Burresi > Employment for developers under 25 dropped 20% since ChatGPT's launch. Companies hire fewer juniors because AI does those tasks. But without junior developers today, who will lead teams in ten years? ## The apprenticeship paradox *Companies don't hire juniors because AI does those tasks better. But without junior developers today, who will lead teams in ten years?* There's a question that rarely appears in quarterly reports: if we stop hiring people who are learning, who will know how to do this job a decade from now? The numbers tell a story that should concern anyone managing technical teams. Employment for software developers between ages 22 and 25 has dropped 20% from the peak in late 2022, according to a [paper from Stanford's Digital Economy Lab](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/) based on payroll data from 25 million workers. It's not a uniform decline: in the same period, employment for those over 35 in the same roles grew 8%. The mechanism is what we might call the apprenticeship paradox: companies stop hiring entry-level because AI does those tasks better than a recent graduate. But without entry-level workers today, they won't have senior engineers tomorrow. --- ## The numbers of collapse The contraction is not an impression. It's documented by multiple independent sources. Entry-level hiring at the top 15 tech companies dropped 25% between 2023 and 2024, according to [SignalFire](https://spectrum.ieee.org/ai-effect-entry-level-jobs). Since 2021, the average age of technical hires has increased by three years. Companies aren't just hiring less: they're hiring differently, preferring senior profiles who can be productive from day one. Tech internships have collapsed 30% since 2023, [according to Handshake](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z). Meanwhile, applications have increased 7%. More people competing for fewer positions, and the remaining positions require increasingly prior experience. A [Harvard study](https://www.finalroundai.com/blog/ai-is-making-it-harder-for-junior-developers-to-get-hired) of 285,000 American companies found that when firms adopt generative AI, junior employment drops 9-10% within six quarters. Senior employment remains stable. These aren't mass layoffs: it's a silent hiring freeze. Companies simply stop opening entry-level positions. The pattern repeats in Europe. Junior tech positions have [dropped 35%](https://restofworld.org/2025/engineering-graduates-ai-job-losses/) in major EU countries during 2024, based on aggregated data from LinkedIn, Indeed, and Eures. In the UK, the Big Four consulting firms cut graduate hiring between 6% and 29% in two years. In India, IT companies have reduced entry-level roles by 20-25%, according to an EY report. The World Economic Forum, in its Future of Jobs Report 2025, warns that 40% of employers expect to reduce staffing where AI can automate tasks. And automatable tasks are, almost by definition, the ones junior developers used to do. --- ## The logic of the short term The rationale behind these choices is understandable. A senior engineer with AI tools can do what previously required two or three juniors, at least for certain tasks. GitHub Copilot, Cursor, and similar tools promise productivity gains of 20-50% according to their vendors. For a CFO looking at the next quarter, hiring a junior who will need six months of training before being productive seems like a difficult investment to justify. James O'Brien, a computer science professor at Berkeley who works with startups, [describes the shift](https://sfstandard.com/2025/05/20/silicon-valley-white-collar-recession-entry-level/): "Previously, startups would hire one senior person and two or three early-career coders to assist. Now they ask: why hire a recent graduate when AI is cheaper and faster?" It's a reasonable question in the short term. Code generated by AI isn't top quality, but neither is code written by a recent graduate. The difference, O'Brien notes, is that the iterative process to improve AI code takes minutes. A junior might take days for the same task. Heather Doshay, head of talent at SignalFire, sums it up: "Nobody has the patience or time for hand-holding in this new environment, where much of the work can be done autonomously by AI." --- ## The problem nobody calculates There's a flaw in this logic, and it's called the talent pipeline. Matt Garman, CEO of AWS, [said it explicitly](https://www.finalroundai.com/blog/aws-ceo-ai-cannot-replace-junior-developers): "If you don't have a talent pipeline you're building, if you don't have junior people you're mentoring and growing in the company, we often find that's where the best ideas come from. If a company stops hiring juniors and developing them, eventually the whole system falls apart." It's not rhetoric. It's demographic mathematics applied to organizations. Every senior engineer, every tech lead, every CTO was once a junior. The path from recent graduate to technical leader requires years of experience on real projects, mistakes made and corrected, feedback received, patterns internalized. There is no shortcut. If the industry stops hiring juniors in 2023, by 2033 it will have a structural shortage of mid-level talent. By 2038, there will be a shortage of senior engineers. By 2043, there will be no one to promote to technical leadership roles. The problem is that this cost doesn't appear in any quarterly balance sheet. It's an invisible debt that accumulates silently, and when it becomes obvious, it will be too late to remedy quickly. --- ## AI that teaches and AI that atrophies There's a further irony in this situation. The same AI tools that are eliminating junior roles could, in theory, accelerate learning. An AI tutor available 24/7, patient, answering every question: it sounds like every student's dream. The reality is more complicated. An experiment conducted by Wharton and Penn researchers on nearly a thousand high school math students tested two versions of a GPT-4-based tutor. The group with access to a ChatGPT-like interface (GPT Base) achieved 48% better results during assisted practice sessions. The group with a tutor designed to guide without giving direct answers (GPT Tutor) achieved 127% better results. But here's the point: when AI was removed and students took the exam on their own, the GPT Base group achieved 17% worse results than the control group who never used AI. The GPT Tutor group, by contrast, achieved results similar to control. Students were using AI as a crutch. They performed better with assistance but learned less. When the assistance was removed, they found themselves worse off than those who never had it. A [study from MIT Media Lab](https://time.com/7295195/ai-chatgpt-google-learning-school/) documented what researchers call "cognitive debt": using LLMs for writing seems to reduce mental effort during the task, but at the cost of more superficial learning. Researcher Nataliya Kosmyna expressed concern about developing brains: "Developing brains are the ones at highest risk." It doesn't mean AI can't help learning. The Wharton study shows it can, if designed with the right safeguards. But "wild" AI, the kind that gives answers instead of guiding toward answers, can do damage. --- ## The new profile of the junior If fewer juniors will be hired, what characteristics must they have to be hired? Market signals are clear. It's no longer enough to know how to code. Employers [expect](https://spectrum.ieee.org/ai-effect-entry-level-jobs) recent graduates to be able to manage projects, communicate with clients, understand the software development lifecycle. The "grunt work" that once served as a training ground is being automated. Those entering must be operational at a higher level almost from day one. Jamie Grant, who manages career services for engineering at the University of Pennsylvania, describes the change: "They're not necessarily just programming. There's much more high-level thinking and understanding of the software development lifecycle." David Malan of Harvard, who teaches the world's most-followed introduction to programming course, notes that the biggest impact of AI has been on programmers, not on roles that were expected (like call centers). The reason: programming work is relatively solitary and highly structured, perfect for automation. But Malan also notes something interesting: in the United States, employment for "programmers" dropped 27.5% between 2023 and 2025, but employment for "software developers," a more design-oriented position, dropped only 0.3%. The difference is in the level of abstraction. Those who write code are vulnerable. Those who design systems less so. --- ## Three scenarios for the future **Scenario 1: The collapse of the pipeline** Companies continue not to hire juniors. In five to ten years, the shortage of mid-level talent becomes acute. The remaining senior engineers command astronomical salaries. Companies that can't afford them lose competitiveness. The industry polarizes between a few giants who can attract talent and everyone else struggling. **Scenario 2: Apprenticeship reinvented** Some companies realize the problem is coming and invest against the trend. They create intensive training programs, perhaps assisted by AI designed to teach instead of replace. They become the preferred employers for top talent, who know they can grow there. In the long term, they have a competitive advantage. **Scenario 3: Uneven democratization** AI lowers the barrier to entry for some skills (writing working code) but raises it for others (designing systems, debugging complex problems, managing AI itself). Those with access to quality training and mentorship can skip some steps. Those without remain stuck. Inequality of opportunity increases. None of these scenarios is inevitable. They are possibilities that depend on choices companies, educational institutions, and policymakers will make in the coming years. --- ## What those who hire can do If you manage a team or influence hiring decisions, some questions deserve reflection. **Are you optimizing for the next quarter or the next ten years?** A junior costs more in the short term. But the alternative is to depend entirely on the external market for talent, competing with everyone else who made the same choice. **Is your team still teaching?** If senior people spend all their time producing and no one teaching, you're consuming human capital without regenerating it. **How do you use AI in training?** If your juniors use Copilot to get answers instead of learning to find them, you're accelerating their short-term productivity while compromising their long-term growth. **Are you hiring for today's skills or tomorrow's adaptability?** Specific technical skills have an increasingly short half-life. The ability to learn, to reason about new problems, to work with people—those last. --- ## What those starting out can do If you're early in your career in a market that seems to close doors on you, some principles can help. AI isn't eliminating all junior work. It's eliminating repetitive, isolated junior work. The roles that survive require human interaction, judgment about ambiguous problems, creativity applied to specific contexts. Look for those. Learn to use AI as a tool, not a crutch. The difference between using ChatGPT to get answers and using it to explore problems is the difference between atrophying and growing. Networking matters more than ever. If junior positions are scarce, competition is fierce, and often the person with a connection wins, not the person with the best CV. It's not fair, but it's real. Cross-functional skills are not optional. Communication, project management, understanding the business: these are things AI can't do and employers seek even in technical profiles. --- ## The unanswered question I return to the initial question: who will the senior engineers of tomorrow be? I don't have a certain answer. No one does. We're conducting a real-time experiment, without a control group, on a global scale. What I know is that every senior person I know was once a junior who someone decided to hire and train. Every tech lead made beginner mistakes that someone had the patience to correct. Every systems architect wrote embarrassing code before writing elegant code. If we eliminate that phase, if we treat it as a cost to cut rather than an investment to protect, we're not optimizing. We're consuming capital that we don't know how to regenerate. The question isn't whether AI can replace juniors. It can, for many tasks. The question is whether we want an industry that only knows how to consume skills or one that also knows how to produce them. For now, the numbers suggest we've chosen the first option. The bill will come. Not next quarter. But it will come. --- ## Sources Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2024). *Generative AI Can Harm Learning*. The Wharton School Research Paper. Stack Overflow. (2025, December). [*AI vs Gen Z: How AI has changed the career pathway for junior developers*](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z). Stack Overflow Blog. IEEE Spectrum. (2025, December). [*AI Shifts Expectations for Entry Level Jobs*](https://spectrum.ieee.org/ai-effect-entry-level-jobs). Rest of World. (2025, December). [*AI is wiping out entry-level tech jobs, leaving graduates stranded*](https://restofworld.org/2025/engineering-graduates-ai-job-losses/). Kosmyna, N., et al. (2025). [*Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task*](https://arxiv.org/abs/2506.08872). arXiv. World Economic Forum. (2025). [*Future of Jobs Report 2025*](https://www.weforum.org/publications/the-future-of-jobs-report-2025/). FinalRound AI. (2025). [*AWS CEO Shares 3 Solid Reasons Why Companies Shouldn't Replace Juniors with AI Agents*](https://www.finalroundai.com/blog/aws-ceo-ai-cannot-replace-junior-developers). --- ## Chi saranno i senior di domani? - URL: https://ireneburresi.dev/blog/senior-domani/ - Pillar: Business - Published: 2025-01-06 - Updated: 2025-01-06 - Tags: Junior Developers, AI Impact, Talent Pipeline, Future of Work, Learning, Career - Author: Irene Burresi > L'occupazione per sviluppatori under 25 è calata del 20% dal lancio di ChatGPT. Le aziende assumono meno junior perché l'AI fa quei task. Ma senza junior oggi, chi guiderà i team tra dieci anni? ## Una domanda che nessuno fa nei board meeting *Le aziende non assumono junior perché l'AI svolge i loro task meglio. E tra dieci anni, chi guiderà i team?* Nei report trimestrali non trovi mai questa domanda. La butto lì: se smettiamo di assumere chi sta imparando, chi diavolo saprà fare questo lavoro tra un decennio? I numeri raccontano qualcosa che dovrebbe far venire i brividi a chiunque gestisca team tecnici. L'occupazione per sviluppatori software tra i 22 e i 25 anni è calata del 20% dal picco di fine 2022. Il dato viene da un [paper del Digital Economy Lab di Stanford](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/), basato su payroll di 25 milioni di lavoratori. E non è un calo uniforme, anzi: nello stesso periodo gli over-35 nelle stesse mansioni sono cresciuti dell'8%. Potremmo chiamarlo paradosso dell'apprendistato, questo meccanismo. Le aziende smettono di assumere entry-level perché l'AI svolge quei task meglio. Peccato che senza entry-level oggi, senior domani non ne avrai. --- ## Numeri, non impressioni La contrazione è documentata da fonti multiple e indipendenti, non è una sensazione. Le assunzioni entry-level nelle 15 maggiori aziende tech sono calate del 25% tra il 2023 e il 2024, secondo [SignalFire](https://spectrum.ieee.org/ai-effect-entry-level-jobs). L'età media delle assunzioni tecniche dal 2021 è aumentata di tre anni. Le aziende non stanno solo assumendo meno, stanno assumendo diversamente. Vogliono gente produttiva dal giorno uno. I tirocini tech crollati del 30% dal 2023, [secondo Handshake](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z). Le candidature aumentate del 7%. Più gente che si sbatte per meno posti, e quei posti che restano chiedono sempre più esperienza. Uno [studio Harvard](https://www.finalroundai.com/blog/ai-is-making-it-harder-for-junior-developers-to-get-hired) su 285.000 aziende americane ha trovato che quando le imprese adottano AI generativa, l'occupazione junior cala del 9-10% entro sei trimestri. I senior restano stabili. Non sono licenziamenti di massa, è un congelamento silenzioso: le aziende semplicemente smettono di aprire posizioni entry-level. In Europa stesso schema. Posizioni junior nel tech [giù del 35%](https://restofworld.org/2025/engineering-graduates-ai-job-losses/) nei principali paesi EU durante il 2024, dati aggregati da LinkedIn, Indeed, Eures. In UK le Big Four della consulenza hanno tagliato le assunzioni di neolaureati tra il 6% e il 29% in due anni. India: le aziende IT hanno ridotto i ruoli entry-level del 20-25%, report EY. Il World Economic Forum nel Future of Jobs Report 2025 avverte che il 40% dei datori di lavoro prevede di ridurre personale dove l'AI può automatizzare i task. E i task automatizzabili sono, quasi per definizione, quelli che facevano i junior. --- ## Il ragionamento ha senso. Nel breve periodo. Devo ammetterlo, la logica dietro queste scelte è comprensibile. Un senior engineer con strumenti AI può fare quello che prima richiedeva due o tre junior, almeno per certi task. GitHub Copilot, Cursor e simili promettono aumenti di produttività del 20-50% secondo i vendor (certo, c'è il marketing, ma anche scontandolo qualcosa resta). Per un CFO che guarda al prossimo trimestre, assumere un junior che richiederà sei mesi di formazione prima di essere produttivo sembra difficile da giustificare. James O'Brien, professore di computer science a Berkeley che lavora con startup, [descrive il cambio](https://sfstandard.com/2025/05/20/silicon-valley-white-collar-recession-entry-level/): "Prima, le startup assumevano una persona senior e due o tre coder early-career per assisterla. Ora chiedono: perché assumere un neolaureato quando l'AI è più economica e veloce?" Domanda ragionevole, nel breve. Il codice generato dall'AI non è di prima qualità, ma neanche quello scritto da un neolaureato, diciamocelo. La differenza, nota O'Brien, è che il processo iterativo per migliorare il codice AI richiede minuti. Un junior potrebbe impiegare giorni per lo stesso task. Heather Doshay, head of talent di SignalFire, la mette così: "Nessuno ha pazienza o tempo per il hand-holding in questo nuovo ambiente, dove molto del lavoro può essere fatto autonomamente dall'AI." --- ## Quello che non appare in nessun bilancio C'è un difetto in questa logica, e si chiama pipeline di talenti. Matt Garman, CEO di AWS, [lo ha detto chiaro](https://www.finalroundai.com/blog/aws-ceo-ai-cannot-replace-junior-developers): "Se non hai una pipeline di talenti che stai costruendo, se non hai persone junior che stai mentorando e facendo crescere nell'azienda, spesso scopriamo che è da lì che vengono le idee migliori. Se un'azienda smette di assumere junior e di farli crescere, tutto il sistema alla fine esplode." Non è retorica, è matematica demografica applicata alle organizzazioni. Ogni senior engineer, ogni tech lead, ogni CTO è stato un junior. Il percorso da neolaureato a leader tecnico richiede anni su progetti reali, errori fatti e corretti, feedback ricevuti, pattern che entrano sotto pelle. Non ci sono scorciatoie, su questo. Faccio un conto brutale: se l'industria smette di assumere junior nel 2023, nel 2033 avrà una carenza strutturale di mid-level. Cinque anni dopo mancheranno i senior. Altri cinque e non ci sarà nessuno da promuovere a ruoli di leadership tecnica. Questo costo non appare in nessun bilancio trimestrale, ecco il punto. È un debito che si accumula silenziosamente, e quando diventerà evidente sarà troppo tardi per rimediare in fretta. --- ## L'AI che insegna e quella che atrofizza C'è un'ironia in tutto questo. Gli stessi strumenti AI che stanno eliminando i ruoli junior potrebbero, in teoria, accelerare l'apprendimento. Un tutor AI disponibile 24/7, paziente, che risponde a ogni domanda: il sogno di ogni studente, no? La realtà è più complicata. E qui i dati sono interessanti, secondo me. Un esperimento di ricercatori Wharton e Penn su quasi mille studenti di liceo in matematica ha testato due versioni di un tutor basato su GPT-4. Il gruppo con accesso a un'interfaccia tipo ChatGPT standard (GPT Base) ha ottenuto risultati del 48% migliori durante le sessioni di pratica assistita. Il gruppo con un tutor progettato per guidare senza dare risposte dirette (GPT Tutor) ha fatto il 127% meglio. Ma ecco il punto: quando l'AI è stata tolta e gli studenti hanno fatto l'esame da soli, il gruppo GPT Base ha ottenuto risultati del 17% *peggiori* rispetto al gruppo di controllo che non aveva mai usato AI. Il gruppo GPT Tutor invece era in linea col controllo. Gli studenti usavano l'AI come stampella. Performavano meglio con l'assistenza, imparavano meno. Quando l'assistenza spariva, si ritrovavano più indietro di chi non l'aveva mai avuta. Uno [studio del MIT Media Lab](https://time.com/7295195/ai-chatgpt-google-learning-school/) ha documentato quello che i ricercatori chiamano "debito cognitivo": l'uso di LLM per la scrittura sembra ridurre lo sforzo mentale durante il task, ma a costo di un apprendimento più superficiale. La ricercatrice Nataliya Kosmyna lo dice chiaramente: "I cervelli che si stanno sviluppando sono quelli a rischio più alto." Non significa che l'AI non possa aiutare l'apprendimento. Lo studio Wharton dimostra che può farlo, se progettata con le giuste salvaguardie. Ma l'AI "selvaggia", quella che dà risposte invece di guidare verso le risposte, può fare danni. --- ## Chi saranno i junior che passeranno il filtro? Se le posizioni junior si riducono, chi viene assunto? I segnali dal mercato sono chiari. Saper programmare non basta più. I datori di lavoro [si aspettano](https://spectrum.ieee.org/ai-effect-entry-level-jobs) che i neolaureati sappiano gestire progetti, comunicare con i clienti, capire il ciclo di vita dello sviluppo software. Il lavoro "grunt" che una volta serviva da palestra viene automatizzato. Chi entra deve essere operativo a un livello più alto quasi dal primo giorno. Jamie Grant, che gestisce i career services per ingegneria alla University of Pennsylvania, descrive il cambio: "Non stanno necessariamente solo programmando. C'è molto più pensiero di alto livello e conoscenza del ciclo di vita dello sviluppo software." David Malan di Harvard, che insegna il corso di introduzione alla programmazione più seguito al mondo, nota che l'impatto maggiore dell'AI è stato sui programmatori, non sui ruoli che ci si aspettava (tipo i call center). La ragione: il lavoro di programmazione è relativamente solitario e altamente strutturato. Perfetto per l'automazione, insomma. Ma Malan nota anche qualcosa di interessante. Negli Stati Uniti l'occupazione per "programmatori" è calata del 27,5% tra il 2023 e il 2025, ma quella per "software developers", posizione più orientata al design, è calata solo dello 0,3%. La differenza è nel livello di astrazione. Chi scrive codice è vulnerabile. Chi progetta sistemi lo è meno. --- ## Tre scenari, nessuno inevitabile **Il collasso della pipeline.** Le aziende continuano a non assumere junior. Tra cinque, dieci anni la carenza di mid-level diventa acuta. I senior rimasti vengono pagati cifre astronomiche. Le aziende che non possono permetterseli perdono competitività. L'industria si polarizza tra pochi giganti che attraggono talento e tutti gli altri che arrancano. **L'apprendistato reinventato.** Alcune aziende capiscono che il problema sta arrivando e investono controcorrente. Creano programmi di formazione intensivi, magari assistiti da AI progettata per insegnare invece che sostituire. Diventano i datori di lavoro preferiti per i talenti migliori, che sanno che lì potranno crescere. Nel lungo periodo hanno un vantaggio competitivo. **La democratizzazione irregolare.** L'AI abbassa la barriera d'ingresso per alcune competenze (scrivere codice funzionante) ma la alza per altre (progettare sistemi, debuggare problemi complessi, gestire l'AI stessa). Chi ha accesso a formazione di qualità e mentorship può saltare alcuni gradini. Chi non ce l'ha resta bloccato. La disuguaglianza di opportunità aumenta. Nessuno di questi scenari è scritto nella pietra. Dipende da scelte che aziende, istituzioni educative e policy maker faranno nei prossimi anni. --- ## Se assumi, qualche domanda da farti Stai ottimizzando per il prossimo trimestre o per i prossimi dieci anni? Un junior costa di più nel breve periodo, certo. Ma l'alternativa è dipendere interamente dal mercato esterno per il talento, competendo con tutti gli altri che hanno fatto la stessa scelta. Il tuo team sta ancora insegnando? Se i senior passano tutto il tempo a produrre e nessuno a trasferire conoscenza, stai consumando capitale umano senza rigenerarlo. Come usi l'AI nella formazione? Se i tuoi junior usano Copilot per avere risposte invece che per imparare a trovarle, stai accelerando la loro produttività a breve termine e compromettendo la loro crescita a lungo termine. Stai assumendo per le skill di oggi o per l'adattabilità di domani? Le competenze tecniche specifiche hanno una half-life sempre più breve. La capacità di imparare, di ragionare su problemi nuovi, di lavorare con le persone: quelle durano. --- ## Se stai iniziando, qualche considerazione Il mercato sembra chiuderti le porte, lo so. Ma non tutto il lavoro junior sta sparendo. Sta sparendo quello ripetitivo e isolato. I ruoli che sopravvivono richiedono interazione umana, giudizio su problemi ambigui, creatività applicata a contesti specifici. Quelli sono i ruoli da cercare. L'AI come strumento, non come stampella. La differenza conta davvero. Chi usa ChatGPT per avere risposte e chi lo usa per esplorare problemi sono due persone diverse: una atrofizza, l'altra cresce. Il networking conta, probabilmente più di prima. Se le posizioni junior sono poche, la competizione è feroce, e spesso vince chi ha una connessione, non chi ha il CV migliore. Non è giusto, ma è quello che succede. Le competenze trasversali non sono optional. Comunicare, gestire progetti, capire il business: sono cose che l'AI non sa fare e che i datori di lavoro cercano anche nei profili tecnici. --- ## La domanda resta aperta Torno alla domanda iniziale: chi saranno i senior di domani? Non ho una risposta sicura, e a mio avviso nessuno ce l'ha. Stiamo conducendo un esperimento in tempo reale, senza gruppo di controllo, su scala globale. Quello che so è che ogni senior che conosco è stato un junior che qualcuno ha deciso di assumere e formare. Ogni tech lead ha fatto errori da principiante che qualcuno ha avuto la pazienza di correggere. Ogni architetto di sistema ha scritto codice imbarazzante prima di scrivere codice elegante. Se eliminiamo quella fase, se la consideriamo un costo da tagliare invece che un investimento da proteggere, non stiamo ottimizzando. Stiamo consumando un capitale che non sappiamo come rigenerare. La domanda non è se l'AI può sostituire i junior. Può farlo, per molti task. La domanda è se vogliamo un'industria che sa solo consumare competenze o una che sa anche produrle. Per ora i numeri suggeriscono che abbiamo scelto la prima opzione. Il conto arriverà. Non nel prossimo trimestre, ma arriverà. --- ## Fonti Brynjolfsson, E., Chandar, B., & Chen, R. (2025). [*Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI*](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/). Stanford Digital Economy Lab. Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2024). *Generative AI Can Harm Learning*. The Wharton School Research Paper. Stack Overflow. (2025, December). [*AI vs Gen Z: How AI has changed the career pathway for junior developers*](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z). Stack Overflow Blog. IEEE Spectrum. (2025, December). [*AI Shifts Expectations for Entry Level Jobs*](https://spectrum.ieee.org/ai-effect-entry-level-jobs). Rest of World. (2025, December). [*AI is wiping out entry-level tech jobs, leaving graduates stranded*](https://restofworld.org/2025/engineering-graduates-ai-job-losses/). Kosmyna, N., et al. (2025). [*Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task*](https://arxiv.org/abs/2506.08872). arXiv. World Economic Forum. (2025). [*Future of Jobs Report 2025*](https://www.weforum.org/publications/the-future-of-jobs-report-2025/). FinalRound AI. (2025). [*AWS CEO Shares 3 Solid Reasons Why Companies Shouldn't Replace Juniors with AI Agents*](https://www.finalroundai.com/blog/aws-ceo-ai-cannot-replace-junior-developers). --- ## From SEO to GEO: Technical Guide to AI Search Optimization - URL: https://ireneburresi.dev/blog/seo-vs-geoen/ - Pillar: Tecnica - Published: 2025-01-04 - Updated: 2025-01-04 - Tags: GEO, SEO, AI Search, Schema.org, robots.txt, llms.txt, Technical SEO, E-E-A-T - Author: Irene Burresi > robots.txt, llms.txt, structured data with E-E-A-T, answer blocks, multimodal: complete technical infrastructure to position yourself in generative search engines. Princeton paper, Cloudflare 2025 data, concrete implementations. ## The paradigm shift: from links to citations *GPTBot went from 5% to 30% of crawler traffic in one year. Traffic generated by user queries to AI has grown 15 times. Traditional SEO infrastructure no longer intercepts this flow.* **TL;DR:** Optimization for generative search engines (GEO) requires specific technical interventions: configure robots.txt for 20+ AI crawlers, implement llms.txt to guide LLMs toward priority content, extend structured data with JSON-LD including Person schema with complete E-E-A-T (73% higher selection rate). Structure content in answer blocks of 134-167 words to facilitate extraction. Multimodal content has +156% selection rate. Princeton research shows that adding citations from authoritative sources increases visibility up to 40%. Those who implement now build competitive advantages that are difficult to catch up with. --- Traditional SEO optimizes for a specific goal: ranking in the sorted lists returned by search engines. The user searches, receives ten blue links, clicks. Traffic arrives. Generative search engines work differently. ChatGPT, Perplexity, Gemini, Claude don't return lists of links. They synthesize answers by drawing from multiple sources, citing (or not) the source. The user gets an answer, not a list of options. According to [Cloudflare data from December 2025](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/), GPTBot reached 30% of AI crawler traffic, up from 5% the previous year. Meta-ExternalAgent entered at 19%. ChatGPT-User, the bot that accesses web pages when users ask questions, registered growth of 2,825%. Traffic related to user queries increased 15 times over the course of the year. This is not marginal change. It's a new acquisition channel that requires dedicated infrastructure. --- ## robots.txt: configuration for AI crawlers The robots.txt file communicates to crawlers which parts of the site they can access. For traditional search engines, the configuration is established. For AI crawlers, the landscape is fragmented: each provider uses different user-agents, with different purposes. ### Map of major AI crawlers **OpenAI** operates with three distinct crawlers: ``` User-agent: GPTBot # Training foundational models. Collects data to train GPT. User-agent: ChatGPT-User # User browsing. Accesses pages when a user asks for information. User-agent: OAI-SearchBot # Search. Indexes content for ChatGPT's search function. ``` **Anthropic** uses: ``` User-agent: ClaudeBot # Training and updating Claude. User-agent: Claude-Web # Web access for user functionality. User-agent: anthropic-ai # Generic Anthropic crawler. ``` **Perplexity**: ``` User-agent: PerplexityBot # Indexing for AI answer engine. User-agent: Perplexity-User # Fetch for user queries. ``` **Google** has separated functions: ``` User-agent: Google-Extended # Token for AI use. NOT a bot, it's a flag. # Blocking this user-agent prevents use of content for AI training # while maintaining standard indexing. User-agent: Googlebot # Traditional crawler for Search. ``` **Meta**: ``` User-agent: Meta-ExternalAgent # Crawling for AI model training. User-agent: Meta-ExternalFetcher # Fetch for user requests. Can bypass robots.txt. ``` **Other relevant crawlers**: ``` User-agent: Amazonbot User-agent: Bytespider # ByteDance User-agent: Applebot-Extended # Apple AI (flag, not bot) User-agent: CCBot # Common Crawl User-agent: cohere-ai User-agent: cohere-training-data-crawler ``` ### Configuration strategies **Strategy 1: Full access for maximum AI visibility** ``` # Allow all AI crawlers User-agent: GPTBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ClaudeBot Allow: / User-agent: anthropic-ai Allow: / User-agent: PerplexityBot Allow: / User-agent: Google-Extended Allow: / User-agent: Meta-ExternalAgent Allow: / User-agent: Amazonbot Allow: / ``` **Strategy 2: AI search visibility, no training** This configuration allows AI systems to cite your content in responses, but prevents use for training models: ``` # Allow search/user crawlers User-agent: ChatGPT-User Allow: / User-agent: OAI-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / # Block training crawlers User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: Meta-ExternalAgent Disallow: / User-agent: CCBot Disallow: / User-agent: cohere-training-data-crawler Disallow: / ``` **Strategy 3: Selective access by directory** ``` User-agent: GPTBot Allow: /blog/ Allow: /docs/ Disallow: /api/ Disallow: /internal/ Disallow: /user-data/ ``` ### Limitations of robots.txt A critical point: robots.txt is a voluntary protocol. Crawlers can ignore it. In August 2025, [Cloudflare blocked Perplexity bots](https://www.medianama.com/2025/12/223-user-driven-ai-bots-crawling-grows-15x-in-2025-cloudflare-report/) after documenting protocol violations. In October 2025, Reddit deliberately trapped Perplexity crawlers, demonstrating they bypassed restrictions through third-party tools. Legal action followed. The operational consequence: robots.txt alone is not enough. For real enforcement, you need IP verification, WAF rules, or CDN-level blocks. Cloudflare reports that over 2.5 million sites use its managed robots.txt function to block AI training. --- ## llms.txt: the new standard for guiding LLMs In September 2024, [Jeremy Howard of Answer AI proposed llms.txt](https://llmstxt.org/), a new standard file for communicating with Large Language Models. Unlike robots.txt, which controls access, llms.txt guides models toward the most relevant content. ### What llms.txt does The llms.txt file is a markdown document positioned at the domain root (`/llms.txt`). It works as a curated map that tells LLMs which pages contain the most important information and how to interpret them. It's not a blocking mechanism. It's a recommendation system, like a librarian guiding a visitor to the right shelves instead of letting them wander. ### File structure ```markdown # example.com > Technical site on AI implementations for enterprise. > Content verified, updated monthly. ## Core Documentation - [Production RAG Guide](https://example.com/docs/rag-production): RAG architectures tested in production, chunking patterns, evaluation metrics. Updated Q4 2024. - [API Reference](https://example.com/docs/api): Complete REST API documentation. Includes code examples in Python and cURL. ## Technical Articles - [LLM Latency Optimization](https://example.com/blog/llm-latency): Strategies to reduce p95 latency below 200ms. Includes benchmarks on Claude, GPT-4, Mistral. - [AI Cost Management](https://example.com/blog/ai-costs): Framework for estimating and optimizing inference costs. Real data from enterprise deployments. ## Resources - [AI Glossary](https://example.com/glossary): Technical definitions of 150+ AI/ML terms. ``` ### llms-full.txt: extended version Beyond llms.txt, the standard provides an optional `llms-full.txt` file containing the full site content in flattened format. It removes non-essential HTML, CSS, JavaScript and presents text only. Some sites generate files of 100K+ words. The advantage: allows LLMs to process the entire site in a single context. The limitation: easily exceeds the context window of most models. ### Adoption status As of January 2025, [OpenAI, Google, and Anthropic do not natively support llms.txt](https://www.ovrdrv.com/insights/llms-txt-the-new-standard-for-ai-crawling). Their crawlers don't automatically read the file. Current adoption is concentrated in specific niches: - **Technical documentation**: Mintlify integrated llms.txt in November 2024. Documentation sites for Anthropic, Cursor, Cloudflare, Vercel use it. - **Dedicated directories**: [directory.llmstxt.cloud](https://directory.llmstxt.cloud) and [llmstxt.site](https://llmstxt.site) catalog sites with implementations. - **Manual use**: Developers who upload the file directly to ChatGPT or Claude to provide context. It's an investment in future-proofing. When major providers adopt the standard, those who have already implemented will have an advantage. ### Implementation 1. Create `/llms.txt` at the domain root 2. UTF-8 format, clean markdown 3. Include only indexable pages (no noindex, no blocked in robots.txt) 4. Add concise but informative descriptions for each URL 5. Optional: reference in robots.txt with `# LLM-policy: /llms.txt` ### Differences with other standard files
Comparison of standard files for web and AI crawlers
File Purpose Target Format
robots.txt Crawler access control Search engines, AI crawlers Plain text, directives
sitemap.xml Complete page catalog Search engines XML
llms.txt Curated priority content map LLM Markdown
humans.txt Team credits Humans Plain text
--- ## Structured Data and JSON-LD for AI Structured data is not new. It's been standard SEO since 2011. But its role changes in the context of generative search engines. ### Why Structured Data matters for AI LLMs process everything as tokens. They don't natively distinguish between a price, a name, a date. Structured data provides an explicit semantic layer that disambiguates content. An article with JSON-LD markup communicates in a machine-readable way: this is the author, this is the publication date, this is the publishing organization, these are the sources cited. The model doesn't have to infer this structure from the text. ### Basic JSON-LD implementation JSON-LD (JavaScript Object Notation for Linked Data) is the preferred format. It's inserted in a ` ``` ### Priority schema types for AI visibility **Article / TechArticle / NewsArticle** For editorial content. TechArticle for technical documentation. **FAQPage** Q&A structure that generative search engines can extract directly: ```html ``` **HowTo** For step-by-step guides: ```html ``` **Organization and Person: E-E-A-T for AI** E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is no longer just a Google framework. Data shows that LLMs verify author credentials before citing: 96% of content in AI Overview comes from sources with verified authors. Content with detailed author bios has 73% higher selection probability. The Person schema must go beyond the name. It needs to communicate credentials, affiliations, specific expertise: ```html ``` **E-E-A-T checklist for Person schema:** - `description` with years of experience and specialization - `hasCredential` for verifiable certifications - `knowsAbout` with specific topics (not generic) - `sameAs` with links to verified profiles (LinkedIn, GitHub, Google Scholar) - `alumniOf` for academic affiliations - `worksFor` with organization URL ### Citation schema For content that cites external sources, the Citation schema adds context: ```html ``` ### ImageObject and VideoObject for multimodal content Multimodal content has 156% higher probability of being selected in AI Overview compared to text-only content. Gemini and Perplexity invest heavily in multimodal search. Schema for media becomes relevant: ```html ``` For video with transcription: ```html ``` **Best practices for AI-friendly media:** - Descriptive and contextual alt text (not "image1.png") - Captions that explain the content, not just describe it - Transcriptions for all videos - Captions that contextualize the figure in surrounding text ### Real impact on AI search John Mueller of Google clarified in January 2025 that structured data is not a direct ranking factor. But the indirect impact is documented: - Rich snippets from structured data increase CTR by 30% according to [BrightEdge](https://www.brightedge.com/) - 72% of sites on Google's first page use schema markup - Google's AI Overviews process structured data to build responses Structured data doesn't guarantee citations in generative search engines. But it provides the semantic context that facilitates correct interpretation of content. --- ## Technical requirements for AI crawlers Beyond structured data, there are technical requirements that influence LLMs' ability to process and cite content. ### Static HTML vs JavaScript rendering AI crawlers struggle with JavaScript-rendered content. Unlike Googlebot, which executes JS, many AI crawlers prefer or require static HTML. **Operating rules:** - Critical content must be present in static HTML, not generated dynamically - Avoid content hidden in tabs, accordions, or loaded on-scroll - If you use JS frameworks (React, Vue, Next.js), verify that SSR or SSG produces complete HTML - Test: view the page with JS disabled. What you see is what base AI crawlers see. ### Content freshness signals 23% of content selected in AI Overview is less than 30 days old. Perplexity indexes daily. Freshness signals are prioritized over historical authority. **Implementation:** `dateModified` in schema must reflect actual updates: ```html ``` **Freshness checklist:** - Update `dateModified` only for substantial changes (not typo fixes) - Prominently signal updates in content ("Updated: January 2025") - Quarterly review of evergreen content - Update statistics and data at least annually - Remove or mark obsolete content as archived ### Citation verification and fact-checking AI systems cross-reference with authoritative sources in real-time. Content with verifiable citations has 89% higher selection probability compared to content with unsupported claims. **Rules:** - Every statistic must have a linked source - "According to research" without a link = unverifiable claim = penalized - Prefer primary sources (papers, official documentation) over secondary sources - Citations from Wikipedia, Statista, Pew Research, arXiv papers carry more weight --- ## GEO strategies: what the research says The ["GEO: Generative Engine Optimization" paper](https://arxiv.org/abs/2311.09735) from Princeton, Georgia Tech, Allen Institute, and IIT Delhi is the most rigorous available study on optimization for generative search engines. It tested 9 techniques on 10,000 queries. ### The three most effective strategies **1. Cite Sources: +40% visibility** Adding citations from authoritative sources is the strategy with the highest overall impact. For sites with low ranking in traditional SERPs, the effect is even more pronounced: +115% for sites in fifth position. Simply citing is not enough. The citation must be from a recognized, relevant source, verifiable. **2. Quotation Addition** Incorporating direct quotes from industry experts increases authenticity and perceived depth. Works particularly well for opinion-based content. **3. Statistics Addition** Quantitative data beats qualitative discussion. "42% of AI projects fail" has more impact than "many AI projects fail". Works particularly well for Legal and Government domains. ### Structuring content for extraction: Answer Blocks LLMs don't cite entire pages. They extract specific blocks. Optimizing for this pattern is critical. *Passage length* optimal: 134-167 words per citable block. For direct FAQ answers: 40-60 words. Content with summary boxes at the beginning has 28-40% higher citation probability. **Practical implementation:** 1. **TL;DR at the beginning:** Every article opens with a self-contained summary block. It's not just for human readers: it's the block that LLMs preferentially extract. 2. **Self-contained sections:** Each H2/H3 should be citable independently from the rest. An LLM should be able to extract that section and have a complete answer. 3. **Heading as questions:** "What is RAG?" performs better than "RAG Overview". Direct matching with conversational queries. 4. **Modular paragraphs:** 75-300 words per section. No wall of text. Modular blocks are easier to extract and cite. 5. **Direct answers first, context after:** The answer to the heading's implicit question should appear in the first 2-3 sentences. Elaboration comes after. **Example of optimized structure:** ```markdown ## What is the difference between SEO and GEO? SEO optimizes for ranking in lists of results from traditional search engines. GEO optimizes for being cited in synthesized responses from generative search engines like ChatGPT, Perplexity and Gemini. [40-60 words of direct answer] The fundamental change concerns the objective: from ranking to citation. In classical SEO, success is position 1 in the SERPs. In GEO, success is being the source that the AI cites when responding. [Elaboration and context] ``` ### Domain-specific strategies The paper found that effectiveness varies by domain: - **History**: Authoritative and persuasive tone - **Facts**: Citations from primary sources - **Law/Government**: Statistics and quantitative data - **Science/Health**: Technical terminology + authoritativeness ### Platform-specific optimization Each LLM has different preferences. An effective GEO strategy considers these differences:
Optimization preferences for generative AI platforms
Platform Main preferences Optimization
ChatGPT Wikipedia, popular brands, established content Authority building, Wikipedia presence if applicable
Perplexity Reddit, recent content, real-time Freshness priority, community engagement
Gemini Multimodal, Google ecosystem, schema markup Video, optimized images, complete structured data
Claude Accuracy, balanced content, attribution Proper attribution, neutral and evidence-based framing
Google AI Overview Top 10 organic, strong E-E-A-T Traditional SEO + extended structured data
**Operational implications:** - ChatGPT cites Wikipedia in 48% of responses. For topics with a Wikipedia entry, presence there matters. - Perplexity prefers Reddit (46.7% of citations). Content discussed in relevant subreddits has an advantage. - Gemini integrates images and video into responses. Multimodal content performs better. - Claude verifies accuracy more rigorously. Unsupported claims are discarded. ### What doesn't work **Keyword stuffing**: Adding keywords from the query to content worsens visibility by 10% compared to baseline. Generative search engines penalize over-optimization. **Generic persuasive language**: Persuasive tone without substance doesn't improve ranking. ### Democratization of results An interesting aspect: GEO levels the playing field. Sites with low ranking in traditional SERPs benefit more from GEO optimizations than dominant sites. Cite Sources brings +115% to sites in fifth position and -30% to sites in first position. For small publishers and independent businesses, it's an opportunity to compete with corporate giants without comparable SEO budgets. --- ## Implementation checklist ### robots.txt - [ ] Map all AI crawlers relevant to your industry - [ ] Define strategy: full access, search-only, selective - [ ] Implement directives for each user-agent - [ ] Verify syntax with [Google Robots Testing Tool](https://www.google.com/webmasters/tools/robots-testing-tool) - [ ] Monitor server logs for crawler activity - [ ] Verify actual compliance (IP check for suspicious crawlers) - [ ] Quarterly review: new crawlers emerge regularly ### llms.txt - [ ] Create markdown file at domain root - [ ] Include site description and content type - [ ] Organize URLs by category/priority - [ ] Add concise descriptions for each link - [ ] Verify that all URLs are indexable - [ ] Consider llms-full.txt for sites with extended documentation - [ ] Update when new priority content is published ### Structured Data / JSON-LD - [ ] Implement Organization schema for the site - [ ] Add Person schema for authors with complete E-E-A-T: - [ ] `description` with years of experience and specialization - [ ] `hasCredential` for verifiable certifications - [ ] `knowsAbout` with specific topics - [ ] `sameAs` with LinkedIn, GitHub, Google Scholar - [ ] Use Article/TechArticle for editorial content - [ ] Implement FAQPage for Q&A sections - [ ] Add Citation schema for research-based content - [ ] Implement ImageObject/VideoObject for media - [ ] Validate with [Google Rich Results Test](https://search.google.com/test/rich-results) - [ ] Verify parity between markup and visible content ### GEO-optimized content - [ ] TL;DR of 40-60 words at the beginning of each article - [ ] Self-contained sections (citable independently) - [ ] Headings formulated as questions where appropriate - [ ] Modular paragraphs: 75-300 words per section - [ ] *Passage length*: 134-167 words for key blocks - [ ] Include citations from authoritative sources in every article - [ ] Add statistics and quantitative data with source - [ ] Use expert quotations where relevant - [ ] Avoid keyword stuffing - [ ] Calibrate tone for domain ### Technical requirements - [ ] Critical content in static HTML (not JS-only rendering) - [ ] No content hidden in tabs/accordions/lazy-load - [ ] Test page with JavaScript disabled - [ ] `dateModified` updated for substantial changes - [ ] Signal updates in content ("Updated: Month Year") - [ ] Quarterly review of evergreen content - [ ] Every statistic with linked source ### Media and Multimodal - [ ] Descriptive and contextual alt text for images - [ ] Captions that explain the content - [ ] Transcriptions for all videos - [ ] ImageObject/VideoObject schema implemented - [ ] Captions that contextualize figures in surrounding text ### Monitoring - [ ] Track AI crawler activity in server logs - [ ] Monitor brand mentions in ChatGPT/Perplexity/Gemini responses - [ ] Analyze competitor citation share - [ ] Measure referral traffic from AI platforms - [ ] Monthly metrics review --- ## The window of opportunity Cloudflare data shows that crawling for AI training still dominates traffic, with volumes 8 times higher than search crawling and 32 times higher than user-action crawling. But the trend is clear: user-action traffic is growing faster than any other category. Those who implement GEO infrastructure now build advantages that accumulate over time. Citations generate other citations. Authority recognized by models strengthens. First-mover advantage in this space isn't just about technical positioning: it's about building an established presence before competition intensifies. Traditional SEO doesn't disappear. It continues to serve 70% of search traffic that still goes through classic SERPs. But the remaining 30%, and its growth trajectory, requires new tools. --- ## Sources Aggarwal, P., et al. (2024). [*GEO: Generative Engine Optimization*](https://arxiv.org/abs/2311.09735). arXiv:2311.09735. Princeton University, Georgia Tech, Allen Institute for AI, IIT Delhi. AI Mode Boost. (2025). [*AI Overview Ranking Factors: 2025 Comprehensive Study*](https://aimodeboost.com/resources/research/ai-overview-ranking-factors-2025/). Cloudflare. (2025, December). [*From Googlebot to GPTBot: Who's Crawling Your Site in 2025*](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/). Cloudflare Blog. Dataslayer. (2025). [*Google AI Overviews Impact 2025: CTR Down 61%*](https://www.dataslayer.ai/blog/google-ai-overviews-the-end-of-traditional-ctr-and-how-to-adapt-in-2025). Howard, J. (2024, September). [*llms.txt Proposal*](https://llmstxt.org/). Answer AI. W3C Schema Community. (2024). [*Schema Vocabulary Documentation*](https://schema.org/docs/documents.html). SEO Sherpa. (2025, October). [*Google AI Search Guidelines 2025*](https://seosherpa.com/google-ai-search-guidelines/). Single Grain. (2025, October). [*Google AI Overviews: The Ultimate Guide to Ranking in 2025*](https://www.singlegrain.com/search-everywhere-optimization/google-ai-overviews-the-ultimate-guide-to-ranking-in-2025/). Yoast. (2025). [*Structured Data with Schema for Search and AI*](https://yoast.com/structured-data-schema-ultimate-guide/). Overdrive Interactive. (2025, July). [*LLMs.txt: The New Standard for AI Crawling*](https://www.ovrdrv.com/insights/llms-txt-the-new-standard-for-ai-crawling). --- ## Da SEO a GEO: Guida Tecnica all'Ottimizzazione per AI Search - URL: https://ireneburresi.dev/blog/seo-vs-geo/ - Pillar: Tecnica - Published: 2025-01-04 - Updated: 2025-01-04 - Tags: GEO, SEO, AI Search, Schema.org, robots.txt, llms.txt, Technical SEO, E-E-A-T - Author: Irene Burresi > robots.txt, llms.txt, structured data con E-E-A-T, answer blocks, multimodal: l'infrastruttura tecnica completa per posizionarsi nei motori generativi. Paper Princeton, dati Cloudflare 2025, implementazioni concrete. ## Il cambio di paradigma: dai link alle citazioni *GPTBot è passato dal 5% al 30% del traffico crawler in un anno. Il traffico generato da query utente verso AI è cresciuto 15 volte. L'infrastruttura SEO tradizionale non intercetta più questo flusso.* **TL;DR:** L'ottimizzazione per motori generativi (GEO) richiede interventi tecnici specifici: configurare robots.txt per 20+ AI crawler, implementare llms.txt per guidare LLM verso contenuti prioritari, estendere structured data con JSON-LD incluso Person schema con E-E-A-T completo (73% in più di selezione). Strutturare contenuti in answer blocks di 134-167 parole per facilitare l'estrazione. Contenuti multimodali hanno +156% selection rate. La ricerca Princeton dimostra che aggiungere citazioni da fonti autorevoli aumenta la visibilità fino al 40%. Chi implementa ora costruisce vantaggi competitivi difficili da recuperare. --- Il SEO tradizionale ottimizza per un obiettivo specifico: posizionarsi nelle liste ordinate restituite dai motori di ricerca. L'utente cerca, riceve dieci link blu, clicca. Il traffico arriva. I motori generativi funzionano diversamente. ChatGPT, Perplexity, Gemini, Claude non restituiscono liste di link. Sintetizzano risposte attingendo da fonti multiple, citando (o meno) la provenienza. L'utente ottiene una risposta, non un elenco di opzioni. Secondo i [dati Cloudflare di dicembre 2025](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/), GPTBot ha raggiunto il 30% del traffico AI crawler, in crescita dal 5% dell'anno precedente. Meta-ExternalAgent è entrato al 19%. ChatGPT-User, il bot che accede a pagine web quando gli utenti fanno domande, ha registrato una crescita del 2.825%. Il traffico legato a query utente è aumentato di 15 volte nel corso dell'anno. Non è un cambiamento marginale. È un nuovo canale di acquisizione che richiede infrastruttura dedicata. --- ## robots.txt: configurazione per AI crawler Il file robots.txt comunica ai crawler quali parti del sito possono accedere. Per i motori di ricerca tradizionali, la configurazione è consolidata. Per gli AI crawler, il panorama è frammentato: ogni provider usa user-agent diversi, con scopi diversi. ### Mappa degli AI crawler principali **OpenAI** opera con tre crawler distinti: ``` User-agent: GPTBot # Training modelli fondazionali. Raccoglie dati per addestrare GPT. User-agent: ChatGPT-User # Browsing utente. Accede a pagine quando un utente chiede informazioni. User-agent: OAI-SearchBot # Search. Indicizza contenuti per la funzione di ricerca di ChatGPT. ``` **Anthropic** usa: ``` User-agent: ClaudeBot # Training e aggiornamento Claude. User-agent: Claude-Web # Accesso web per funzionalità utente. User-agent: anthropic-ai # Crawler generico Anthropic. ``` **Perplexity**: ``` User-agent: PerplexityBot # Indicizzazione per AI answer engine. User-agent: Perplexity-User # Fetch per query utente. ``` **Google** ha separato le funzioni: ``` User-agent: Google-Extended # Token per uso AI. NON è un bot, è un flag. # Controllare questo user-agent impedisce uso dei contenuti per training AI # mantenendo l'indicizzazione standard. User-agent: Googlebot # Crawler tradizionale per Search. ``` **Meta**: ``` User-agent: Meta-ExternalAgent # Crawling per training modelli AI. User-agent: Meta-ExternalFetcher # Fetch per richieste utente. Può bypassare robots.txt. ``` **Altri crawler rilevanti**: ``` User-agent: Amazonbot User-agent: Bytespider # ByteDance User-agent: Applebot-Extended # Apple AI (flag, non bot) User-agent: CCBot # Common Crawl User-agent: cohere-ai User-agent: cohere-training-data-crawler ``` ### Strategie di configurazione **Strategia 1: Accesso completo per massima visibilità AI** ``` # Permettere tutti gli AI crawler User-agent: GPTBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ClaudeBot Allow: / User-agent: anthropic-ai Allow: / User-agent: PerplexityBot Allow: / User-agent: Google-Extended Allow: / User-agent: Meta-ExternalAgent Allow: / User-agent: Amazonbot Allow: / ``` **Strategia 2: Visibilità AI search, no training** Questa configurazione permette ai sistemi AI di citare i contenuti nelle risposte, ma impedisce l'uso per addestrare modelli: ``` # Permettere crawler search/user User-agent: ChatGPT-User Allow: / User-agent: OAI-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / # Bloccare crawler training User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: Meta-ExternalAgent Disallow: / User-agent: CCBot Disallow: / User-agent: cohere-training-data-crawler Disallow: / ``` **Strategia 3: Accesso selettivo per directory** ``` User-agent: GPTBot Allow: /blog/ Allow: /docs/ Disallow: /api/ Disallow: /internal/ Disallow: /user-data/ ``` ### Limiti di robots.txt Un punto critico: robots.txt è un protocollo volontario. I crawler possono ignorarlo. Ad agosto 2025, [Cloudflare ha bloccato i bot di Perplexity](https://www.medianama.com/2025/12/223-user-driven-ai-bots-crawling-grows-15x-in-2025-cloudflare-report/) dopo aver documentato violazioni del protocollo. A ottobre 2025, Reddit ha intrappolato deliberatamente i crawler Perplexity, dimostrando che aggiravano le restrizioni tramite strumenti di terze parti. Ne è seguita una causa legale. La conseguenza operativa: robots.txt da solo non basta. Per enforcement reale, servono verifiche IP, regole WAF, o blocchi a livello CDN. Cloudflare riporta che oltre 2.5 milioni di siti usano la sua funzione di managed robots.txt per bloccare AI training. --- ## llms.txt: il nuovo standard per guidare i LLM A settembre 2024, [Jeremy Howard di Answer AI ha proposto llms.txt](https://llmstxt.org/), un nuovo file standard per comunicare con i Large Language Models. A differenza di robots.txt, che controlla l'accesso, llms.txt guida i modelli verso i contenuti più rilevanti. ### Cosa fa llms.txt Il file llms.txt è un documento markdown posizionato alla root del dominio (`/llms.txt`). Funziona come una mappa curata che indica ai LLM quali pagine contengono le informazioni più importanti e come interpretarle. Non è un meccanismo di blocco. È un sistema di raccomandazione, come un bibliotecario che guida un visitatore verso gli scaffali giusti invece di lasciarlo vagare. ### Struttura del file ```markdown # example.com > Sito tecnico su implementazioni AI per enterprise. > Contenuti verificati, aggiornati mensilmente. ## Documentazione Core - [Guida RAG Produzione](https://example.com/docs/rag-production): Architetture RAG testate in produzione, pattern di chunking, metriche di valutazione. Aggiornato Q4 2024. - [API Reference](https://example.com/docs/api): Documentazione completa delle API REST. Include esempi di codice Python e cURL. ## Articoli Tecnici - [Ottimizzazione Latenza LLM](https://example.com/blog/llm-latency): Strategie per ridurre latenza p95 sotto 200ms. Include benchmark su Claude, GPT-4, Mistral. - [Cost Management AI](https://example.com/blog/ai-costs): Framework per stimare e ottimizzare costi inference. Dati reali da deployment enterprise. ## Risorse - [Glossario AI](https://example.com/glossario): Definizioni tecniche di 150+ termini AI/ML. ``` ### llms-full.txt: versione estesa Oltre a llms.txt, lo standard prevede un file opzionale `llms-full.txt` che contiene il contenuto completo del sito in formato flattened. Rimuove HTML, CSS, JavaScript non essenziali e presenta solo il testo. Alcuni siti generano file da 100K+ parole. Il vantaggio: permette ai LLM di processare l'intero sito in un singolo context. Il limite: supera facilmente la context window della maggior parte dei modelli. ### Stato di adozione A gennaio 2025, [OpenAI, Google e Anthropic non supportano nativamente llms.txt](https://www.ovrdrv.com/insights/llms-txt-the-new-standard-for-ai-crawling). I loro crawler non leggono automaticamente il file. L'adozione attuale è concentrata in nicchie specifiche: - **Documentazione tecnica**: Mintlify ha integrato llms.txt a novembre 2024. I siti di documentazione di Anthropic, Cursor, Cloudflare, Vercel lo usano. - **Directory dedicate**: [directory.llmstxt.cloud](https://directory.llmstxt.cloud) e [llmstxt.site](https://llmstxt.site) catalogano i siti con implementazione. - **Uso manuale**: Sviluppatori che uploadano il file direttamente a ChatGPT o Claude per dare contesto. È un investimento di future-proofing. Quando i major provider adotteranno lo standard, chi ha già implementato avrà vantaggio. ### Implementazione 1. Creare `/llms.txt` alla root del dominio 2. Formato UTF-8, markdown pulito 3. Includere solo pagine indexabili (no noindex, no blocked in robots.txt) 4. Aggiungere descrizioni concise ma informative per ogni URL 5. Opzionale: riferimento in robots.txt con `# LLM-policy: /llms.txt` ### Differenze con altri file standard
Confronto tra file standard per crawler web e AI
File Scopo Target Formato
robots.txt Controllo accesso crawler Search engines, AI crawler Plain text, direttive
sitemap.xml Catalogo completo pagine Search engines XML
llms.txt Mappa curata contenuti prioritari LLM Markdown
humans.txt Crediti team Umani Plain text
--- ## Structured Data e JSON-LD per AI Lo structured data non è una novità. È standard SEO dal 2011. Ma il suo ruolo cambia nel contesto dei motori generativi. ### Perché lo Structured Data conta per AI I LLM processano tutto come token. Non distinguono nativamente tra un prezzo, un nome, una data. Lo structured data fornisce un layer semantico esplicito che disambigua il contenuto. Un articolo con markup JSON-LD comunica in modo machine-readable: questo è l'autore, questa è la data di pubblicazione, questa è l'organizzazione editrice, queste sono le fonti citate. Il modello non deve inferire questa struttura dal testo. ### Implementazione JSON-LD base JSON-LD (JavaScript Object Notation for Linked Data) è il formato preferito. Si inserisce in un tag ` ``` ### Schema types prioritari per AI visibility **Article / TechArticle / NewsArticle** Per contenuti editoriali. TechArticle per documentazione tecnica. **FAQPage** Struttura Q&A che i motori generativi possono estrarre direttamente: ```html ``` **HowTo** Per guide step-by-step: ```html ``` **Organization e Person: E-E-A-T per AI** E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) non è più solo un framework Google. I dati mostrano che i LLM verificano le credenziali autore prima di citare: il 96% dei contenuti in AI Overview proviene da fonti con autori verificati. Contenuti con author bio dettagliate hanno il 73% in più di probabilità di essere selezionati. Lo schema Person deve andare oltre il nome. Serve comunicare credenziali, affiliazioni, competenze specifiche: ```html ``` **Checklist E-E-A-T per schema Person:** - `description` con anni di esperienza e specializzazione - `hasCredential` per certificazioni verificabili - `knowsAbout` con topic specifici (non generici) - `sameAs` con link a profili verificabili (LinkedIn, GitHub, Google Scholar) - `alumniOf` per affiliazioni accademiche - `worksFor` con URL organizzazione ### Citation schema Per contenuti che citano fonti esterne, lo schema Citation aggiunge contesto: ```html ``` ### ImageObject e VideoObject per contenuti multimodali I contenuti multimodali hanno il 156% in più di probabilità di essere selezionati in AI Overview rispetto ai contenuti solo testo. Gemini e Perplexity investono pesantemente nella multimodal search. Lo schema per media diventa rilevante: ```html ``` Per video con trascrizione: ```html ``` **Best practice per media AI-friendly:** - Alt text descrittivo e contestuale (non "image1.png") - Didascalie che spiegano il contenuto, non solo lo descrivono - Trascrizioni per tutti i video - Caption che contestualizzano la figura nel testo circostante ### Impatto reale sugli AI search John Mueller di Google ha chiarito a gennaio 2025 che lo structured data non è un fattore di ranking diretto. Ma l'impatto indiretto è documentato: - Rich snippets da structured data aumentano il CTR del 30% secondo [BrightEdge](https://www.brightedge.com/) - Il 72% dei siti in prima pagina Google usa schema markup - AI Overviews di Google elaborano structured data per costruire risposte Lo structured data non garantisce citazioni nei motori generativi. Ma fornisce il contesto semantico che facilita l'interpretazione corretta del contenuto. --- ## Requisiti tecnici per AI crawler Oltre allo structured data, ci sono requisiti tecnici che influenzano la capacità dei LLM di processare e citare i contenuti. ### Static HTML vs JavaScript rendering Gli AI crawler hanno difficoltà con contenuti renderizzati via JavaScript. A differenza di Googlebot, che esegue JS, molti crawler AI preferiscono o richiedono HTML statico. **Regole operative:** - Contenuto critico deve essere presente nell'HTML statico, non generato dinamicamente - Evitare contenuti nascosti in tab, accordion, o caricati on-scroll - Se usi framework JS (React, Vue, Next.js), verificare che il SSR o SSG produca HTML completo - Test: visualizzare la pagina con JS disabilitato. Ciò che si vede è ciò che vedono i crawler AI base. ### Content freshness signals Il 23% dei contenuti selezionati in AI Overview ha meno di 30 giorni. Perplexity indicizza giornalmente. I segnali di freshness sono prioritari rispetto all'autorità storica. **Implementazione:** `dateModified` in schema deve riflettere aggiornamenti reali: ```html ``` **Checklist freshness:** - Aggiornare `dateModified` solo per modifiche sostanziali (non typo fix) - Segnalare update prominentemente nel contenuto ("Aggiornato: Gennaio 2025") - Review trimestrale contenuti evergreen - Aggiornare statistiche e dati almeno annualmente - Rimuovere o marcare come archivio contenuti obsoleti ### Verifica citazioni e fact-checking Gli AI eseguono cross-reference con fonti autorevoli in tempo reale. Contenuti con citazioni verificabili hanno l'89% in più di probabilità di selezione rispetto a contenuti con claim non supportati. **Regole:** - Ogni statistica deve avere fonte linkata - "Secondo una ricerca" senza link = claim non verificabile = penalizzato - Preferire fonti primarie (paper, documentazione ufficiale) su fonti secondarie - Citazioni da Wikipedia, Statista, Pew Research, paper arXiv hanno peso maggiore --- ## Strategie GEO: cosa dice la ricerca Il [paper "GEO: Generative Engine Optimization"](https://arxiv.org/abs/2311.09735) di Princeton, Georgia Tech, Allen Institute e IIT Delhi è lo studio più rigoroso disponibile sull'ottimizzazione per motori generativi. Ha testato 9 tecniche su 10.000 query. ### Le tre strategie più efficaci **1. Cite Sources: +40% visibilità** Aggiungere citazioni da fonti autorevoli è la strategia con il maggior impatto generale. Per siti con ranking basso nelle SERP tradizionali, l'effetto è ancora più marcato: +115% per siti in quinta posizione. Non basta citare. La citazione deve essere da fonte riconosciuta, pertinente al claim, verificabile. **2. Quotation Addition** Incorporare citazioni dirette da esperti del settore aumenta autenticità e profondità percepita. Funziona particolarmente per contenuti opinion-based. **3. Statistics Addition** Dati quantitativi battono discussioni qualitative. "Il 42% dei progetti AI fallisce" ha più impatto di "molti progetti AI falliscono". Funziona particolarmente per domini Legal e Government. ### Strutturare contenuti per estrazione: Answer Blocks I LLM non citano pagine intere. Estraggono blocchi specifici. Ottimizzare per questo pattern è critico. *Passage length* ottimale: 134-167 parole per blocco citabile. Per risposte FAQ dirette: 40-60 parole. Contenuti con summary box all'inizio hanno il 28-40% in più di probabilità di citazione. **Implementazione pratica:** 1. **TL;DR all'inizio:** Ogni articolo apre con un blocco di sintesi self-contained. Non è solo per lettori umani: è il blocco che i LLM estraggono preferenzialmente. 2. **Sezioni self-contained:** Ogni H2/H3 deve essere citabile indipendentemente dal resto. Un LLM deve poter estrarre quella sezione e avere una risposta completa. 3. **Heading come domande:** "Cos'è il RAG?" performa meglio di "RAG Overview". Matching diretto con query conversazionali. 4. **Paragrafi modulari:** 75-300 parole per sezione. No wall of text. I blocchi modulari sono più facili da estrarre e citare. 5. **Risposte dirette prima, contesto dopo:** La risposta alla domanda implicita dell'heading deve apparire nelle prime 2-3 frasi. L'elaborazione viene dopo. **Esempio di struttura ottimizzata:** ```markdown ## Qual è la differenza tra SEO e GEO? SEO ottimizza per posizionarsi nelle liste di risultati dei motori di ricerca tradizionali. GEO ottimizza per essere citati nelle risposte sintetizzate dai motori generativi come ChatGPT, Perplexity e Gemini. [40-60 parole di risposta diretta] Il cambiamento fondamentale riguarda l'obiettivo: dal ranking alla citazione. Nel SEO classico, il successo è posizione 1 nelle SERP. In GEO, il successo è essere la fonte che l'AI cita quando risponde. [Elaborazione e contesto] ``` ### Strategie domain-specific Il paper ha scoperto che l'efficacia varia per dominio: - **History**: Tono autorevole e persuasivo - **Facts**: Citazioni da fonti primarie - **Law/Government**: Statistiche e dati quantitativi - **Science/Health**: Terminologia tecnica + autorevolezza ### Ottimizzazione per piattaforma specifica Ogni LLM ha preferenze diverse. Una strategia GEO efficace considera queste differenze:
Preferenze di ottimizzazione per piattaforme AI generative
Piattaforma Preferenze principali Ottimizzazione
ChatGPT Wikipedia, brand popolari, contenuti consolidati Authority building, presenza Wikipedia se applicabile
Perplexity Reddit, contenuti recenti, real-time Freshness prioritaria, engagement community
Gemini Multimodal, ecosistema Google, schema markup Video, immagini ottimizzate, structured data completo
Claude Accuracy, contenuti bilanciati, attribuzione Proper attribution, framing neutro ed evidence-based
Google AI Overview Top 10 organic, E-E-A-T forte SEO tradizionale + structured data esteso
**Implicazioni operative:** - ChatGPT cita Wikipedia nel 48% delle risposte. Per topic dove esiste una voce Wikipedia, la presenza lì pesa. - Perplexity preferisce Reddit (46.7% delle citazioni). Contenuti discussi in subreddit rilevanti hanno vantaggio. - Gemini integra immagini e video nelle risposte. Contenuti multimodali performano meglio. - Claude verifica accuracy più rigorosamente. Claim non supportati vengono scartati. ### Cosa non funziona **Keyword stuffing**: Aggiungere keyword dalla query al contenuto peggiora la visibilità del 10% rispetto al baseline. I motori generativi penalizzano l'over-optimization. **Persuasive language generico**: Tono persuasivo senza sostanza non migliora il posizionamento. ### Democratizzazione dei risultati Un aspetto interessante: GEO livella il campo di gioco. I siti con ranking basso nelle SERP tradizionali beneficiano di più dalle ottimizzazioni GEO rispetto ai siti dominanti. Cite Sources porta +115% ai siti in quinta posizione e -30% ai siti in prima posizione. Per piccoli editori e business indipendenti, è un'opportunità di competere con corporate giants senza budget SEO comparabili. --- ## Checklist implementazione ### robots.txt - [ ] Mappare tutti gli AI crawler rilevanti per il settore - [ ] Definire strategia: full access, search-only, selective - [ ] Implementare direttive per ogni user-agent - [ ] Verificare sintassi con [Google Robots Testing Tool](https://www.google.com/webmasters/tools/robots-testing-tool) - [ ] Monitorare server logs per attività crawler - [ ] Verificare compliance effettiva (IP check per crawler sospetti) - [ ] Review trimestrale: nuovi crawler emergono regolarmente ### llms.txt - [ ] Creare file markdown alla root del dominio - [ ] Includere descrizione del sito e tipo di contenuti - [ ] Organizzare URL per categoria/priorità - [ ] Aggiungere descrizioni concise per ogni link - [ ] Verificare che tutti gli URL siano indexabili - [ ] Considerare llms-full.txt per siti con documentazione estesa - [ ] Aggiornare quando nuovi contenuti prioritari vengono pubblicati ### Structured Data / JSON-LD - [ ] Implementare Organization schema per il sito - [ ] Aggiungere Person schema per autori con E-E-A-T completo: - [ ] `description` con anni esperienza e specializzazione - [ ] `hasCredential` per certificazioni verificabili - [ ] `knowsAbout` con topic specifici - [ ] `sameAs` con LinkedIn, GitHub, Google Scholar - [ ] Usare Article/TechArticle per contenuti editoriali - [ ] Implementare FAQPage per sezioni Q&A - [ ] Aggiungere Citation schema per contenuti research-based - [ ] Implementare ImageObject/VideoObject per media - [ ] Validare con [Google Rich Results Test](https://search.google.com/test/rich-results) - [ ] Verificare parità markup-contenuto visibile ### Contenuto GEO-optimized - [ ] TL;DR di 40-60 parole all'inizio di ogni articolo - [ ] Sezioni self-contained (citabili indipendentemente) - [ ] Heading formulati come domande dove appropriato - [ ] Paragrafi modulari: 75-300 parole per sezione - [ ] *Passage length*: 134-167 parole per blocchi chiave - [ ] Includere citazioni da fonti autorevoli in ogni articolo - [ ] Aggiungere statistiche e dati quantitativi con fonte - [ ] Usare quotazioni da esperti dove rilevante - [ ] Evitare keyword stuffing - [ ] Calibrare tono per dominio ### Requisiti tecnici - [ ] Contenuto critico in HTML statico (non solo JS-rendered) - [ ] No contenuti nascosti in tab/accordion/lazy-load - [ ] Test pagina con JavaScript disabilitato - [ ] `dateModified` aggiornato per modifiche sostanziali - [ ] Segnalare update nel contenuto ("Aggiornato: Mese Anno") - [ ] Review trimestrale contenuti evergreen - [ ] Ogni statistica con fonte linkata ### Media e Multimodal - [ ] Alt text descrittivo e contestuale per immagini - [ ] Didascalie che spiegano il contenuto - [ ] Trascrizioni per tutti i video - [ ] Schema ImageObject/VideoObject implementato - [ ] Caption che contestualizzano figure nel testo ### Monitoring - [ ] Tracciare attività AI crawler nei server logs - [ ] Monitorare menzioni del brand in risposte ChatGPT/Perplexity/Gemini - [ ] Analizzare competitor citation share - [ ] Misurare traffico referral da AI platforms - [ ] Review mensile delle metriche --- ## La finestra di opportunità I dati Cloudflare mostrano che il crawling per AI training domina ancora il traffico, con volumi 8 volte superiori al search crawling e 32 volte superiori al crawling da query utente. Ma il trend è chiaro: il traffico user-action sta crescendo più velocemente di ogni altra categoria. Chi implementa l'infrastruttura GEO ora costruisce vantaggi che si accumulano nel tempo. Le citazioni generano altre citazioni. L'autorità riconosciuta dai modelli si rafforza. Il first-mover advantage in questo spazio non riguarda solo il posizionamento tecnico: riguarda la costruzione di una presenza consolidata prima che la competizione si intensifichi. Il SEO tradizionale non scompare. Continua a servire il 70% del traffico search che ancora passa per le SERP classiche. Ma il restante 30%, e la sua traiettoria di crescita, richiede strumenti nuovi. --- ## Fonti Aggarwal, P., et al. (2024). [*GEO: Generative Engine Optimization*](https://arxiv.org/abs/2311.09735). arXiv:2311.09735. Princeton University, Georgia Tech, Allen Institute for AI, IIT Delhi. AI Mode Boost. (2025). [*AI Overview Ranking Factors: 2025 Comprehensive Study*](https://aimodeboost.com/resources/research/ai-overview-ranking-factors-2025/). Cloudflare. (2025, December). [*From Googlebot to GPTBot: Who's Crawling Your Site in 2025*](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/). Cloudflare Blog. Dataslayer. (2025). [*Google AI Overviews Impact 2025: CTR Down 61%*](https://www.dataslayer.ai/blog/google-ai-overviews-the-end-of-traditional-ctr-and-how-to-adapt-in-2025). Howard, J. (2024, September). [*llms.txt Proposal*](https://llmstxt.org/). Answer AI. W3C Schema Community. (2024). [*Schema Vocabulary Documentation*](https://schema.org/docs/documents.html). SEO Sherpa. (2025, October). [*Google AI Search Guidelines 2025*](https://seosherpa.com/google-ai-search-guidelines/). Single Grain. (2025, October). [*Google AI Overviews: The Ultimate Guide to Ranking in 2025*](https://www.singlegrain.com/search-everywhere-optimization/google-ai-overviews-the-ultimate-guide-to-ranking-in-2025/). Yoast. (2025). [*Structured Data with Schema for Search and AI*](https://yoast.com/structured-data-schema-ultimate-guide/). Overdrive Interactive. (2025, July). [*LLMs.txt: The New Standard for AI Crawling*](https://www.ovrdrv.com/insights/llms-txt-the-new-standard-for-ai-crawling).