# Irene Burresi - Full Content Export > Blog tecnico su AI Engineering, architetture RAG, ricerca scientifica, economia e governance dell'intelligenza artificiale. Generated: 2026-03-15T16:26:22.573Z Total articles: 21 --- ## L'AI sta uccidendo la 'programmazione' per salvare l'ingegneria del software - URL: https://ireneburresi.dev/blog/others/ai-uccide-programmazione/ - Pillar: Altro - Published: 2026-02-01 - Tags: ai-coding, software-engineering, labor-market - Author: Irene Burresi > Nuovi dati del governo USA e uno studio del MIT svelano una biforcazione netta nel mercato del lavoro tech: i computer programmer sono in declino del 6%, i software developer crescono del 15%. La "morte del programmatore" è stata annunciata così tante volte, e con tale insistenza, da essere diventata quasi un genere letterario della Silicon Valley. Da [Jensen Huang di Nvidia](https://www.techradar.com/pro/nvidia-ceo-predicts-the-death-of-coding-jensen-huang-says-ai-will-do-the-work-so-kids-dont-need-to-learn) che invita a non imparare più il C++, fino ai CEO delle startup che promettono intere app generate da un prompt. L'hype è visibile, accecante. Quello che si vede meno, però, è una frattura silenziosa che si sta aprendo sotto i piedi dell'industria tech. Una biforcazione che distingue, forse per la prima volta in modo davvero netto, chi "scrive codice" da chi "costruisce software". I numeri parlano chiaro e arrivano dal [Bureau of Labor Statistics](https://www.bls.gov/emp/) (BLS) degli Stati Uniti, l'ente che monitora il polso del mercato del lavoro americano. Nelle proiezioni per il decennio 2024-2034 emerge una divergenza brutale. Da un lato abbiamo i ["computer programmers"](https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm), figure focalizzate sulla scrittura e il test del codice, il cui impiego è previsto in contrazione del 6%. Dall'altro i ["software developers"](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm), coloro che progettano, mantengono e architettano sistemi: per loro si prevede un boom del 15%, un tasso di crescita definito "molto più veloce della media" di tutte le altre professioni, trainato da investimenti in sicurezza, IoT e automazione. L'AI sta trasformando la sintassi in una commodity, ma sta rendendo la semantica il vero asset strategico. ## Il cortocircuito dello studente Per capire questa forbice occorre addentrarsi nella "scatola nera" di come l'intelligenza artificiale approccia lo sviluppo. Ed è qui che entra in gioco un paper pubblicato a marzo 2025 dal MIT, intitolato ["Challenges and Paths Towards AI for Software Engineering"](https://arxiv.org/abs/2503.22625). Lo studio, firmato tra gli altri da Armando Solar-Lezama, scardina una delle narrative più popolari: l'idea che l'AI possa sostituire l'ingegnere del tutto. "Le narrative popolari tendono a ridurre il software engineering a un esercizio da studente universitario", [spiega Solar-Lezama](https://news.mit.edu/2025/can-ai-really-code-study-maps-roadblocks-to-autonomous-software-engineering-0716). Il professore si riferisce a quello scenario idealizzato dove qualcuno ti fornisce una specifica perfetta per una singola funzione isolata e tu devi solo implementarla. Quello che solitamente viene testato alle interview tecniche per le posizioni da dev. "Ma questa è solo una frazione infinitesimale del lavoro reale". Gli attuali Large Language Models (LLM) eccellono nella code generation (ad esempio nel produrre snippet di codice sintatticamente corretti) ma faticano ancora enormemente nel software engineering. Manca loro quello che i ricercatori chiamano "long-horizon planning": la capacità di ragionare su come una decisione presa a riga 10 influenzerà la stabilità del sistema a riga 10.000, sei mesi dopo. ## Oltre la linea di codice Il problema è strutturale, non solo di potenza di calcolo. Alex Gu, primo autore dello studio del MIT, sottolinea come la scrittura di software reale richieda di navigare compromessi complessi: performance contro memoria, velocità di sviluppo contro manutenibilità, debito tecnico contro feature immediate. L'AI attuale non "ragiona" in questi termini; predice il prossimo token. L'interazione tra sviluppatore e AI oggi avviene attraverso una "linea di comunicazione sottilissima": l'AI restituisce codice opaco, senza spiegare il suo livello di confidenza o le alternative scartate. Se richiedi spiegazioni, la sycophancy prende subito il sopravvento. È come lavorare con un programmatore junior velocissimo ma muto, che ti consegna il compito senza dirti se è sicuro al 100% o se ha tirato a indovinare. Inoltre, c'è il problema della memoria e del contesto. Nonostante le finestre di contesto (context window) dei modelli si stiano allargando a dismisura, l'AI non possiede un vero modello mentale della codebase completa. Non "ricorda" l'evoluzione storica del progetto, non sa perché tre anni fa è stata fatta quella scelta architetturale specifica che magari ora sembra strana ma serviva a evitare un bug critico col database. ## L'illusione dei benchmark Ed è qui che scatta l'inganno. Spesso vediamo benchmark trionfali (come [SWE-bench](https://www.swebench.com/SWE-bench/)) dove l'AI risolve problemi complessi. Ma questi test toccano solitamente poche centinaia di righe di codice o repository contenute. Il refactoring di un sistema legacy con milioni di righe, l'integrazione di sistemi distribuiti, o la riscrittura di core business logic su sistemi già in produzione: questi sono i terreni dove l'ingegnere umano non ha rivali, e dove l'AI tende ad avere il fiato corto. La contrazione del 6% dei ruoli di pura programmazione rilevata dal BLS è la cronaca di questa obsolescenza annunciata. Chi si limita a tradurre istruzioni in C++ o Python sta vedendo il proprio valore eroso dall'automazione. Ma quel +15% per gli sviluppatori e ingegneri racconta l'altra faccia della medaglia: la complessità non sta sparendo, si sta solo spostando più in alto, verso l'astrazione. ## Dal coding all'orchestrazione Se la scrittura del codice diventa "cheap" e abbondante, il valore si sposta sulla capacità di giudizio. L'ingegnere del software del futuro assomiglierà sempre meno a chi scrive codice e sempre più a chi decide quale codice ha senso scrivere. L'obiettivo, suggerisce lo studio del MIT, dovrebbe essere liberare gli umani dai compiti di routine per concentrarsi su decisioni critiche e design di alto livello. Siamo di fronte a un cambio di paradigma. Fino a ieri, il collo di bottiglia era la velocità di scrittura: quante righe di codice un umano poteva ragionevolmente produrre in una giornata lavorativa. Domani, il collo di bottiglia sarà la capacità di validare, integrare e dare senso strategico a una mole infinita di codice generato dalle macchine. La posta in gioco è la qualità stessa del futuro digitale. Se deleghiamo totalmente la costruzione del software a sistemi che non sanno ragionare sul lungo termine, rischiamo di costruire grattacieli digitali con fondamenta di argilla. Chi non ha mai imparato a ragionare sui trade-off architetturali, con l'AI non diventa un senior engineer: diventa solo un generatore di debito tecnico ad alta velocità. Per questo i dati ci dicono che non stiamo andando verso la fine dello sviluppo software, ma verso la sua fase adulta. Non ci serve più chi sa parlare la lingua delle macchine (per quello ora abbiamo le macchine), ci serve chi sa decidere cosa dire. E, soprattutto, perché. --- ## Per approfondire - [BLS: Computer Programmers Outlook 2024-2034](https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm) — *Le proiezioni ufficiali del governo USA: -6% di occupazione, con automazione e AI tra le cause principali.* - [BLS: Software Developers Outlook 2024-2034](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm) — *L'altro lato della medaglia: +15% di crescita trainata da AI, IoT e sicurezza informatica.* - [MIT: Challenges and Paths Towards AI for Software Engineering (arXiv)](https://arxiv.org/abs/2503.22625) — *Il paper completo (75 pagine) con tassonomia dei task, bottleneck e direzioni di ricerca.* - [MIT News: Can AI really code?](https://news.mit.edu/2025/can-ai-really-code-study-maps-roadblocks-to-autonomous-software-engineering-0716) — *L'articolo divulgativo con citazioni dirette di Solar-Lezama e Gu.* - [SWE-bench](https://www.swebench.com/SWE-bench/) — *Il benchmark più usato per valutare AI su task di software engineering. Utile per capire cosa misurano (e cosa no) le metriche che leggiamo.* - [Jensen Huang: "Don't learn to code" (TechRadar)](https://www.techradar.com/pro/nvidia-ceo-predicts-the-death-of-coding-jensen-huang-says-ai-will-do-the-work-so-kids-dont-need-to-learn) — *Il discorso del CEO Nvidia al World Government Summit (febbraio 2024) che ha scatenato il dibattito.* --- ## La legge di Amara e il ciclo dell'hype: dove siamo con l'AI generativa - URL: https://ireneburresi.dev/blog/business/amara-hype-cycle/ - Pillar: Business - Published: 2026-01-26 - Tags: hype-cycle, ai-strategy, genai - Author: Irene Burresi > La Legge di Amara spiega perché sovrastimiamo le tecnologie nel breve termine e le sottostimiamo nel lungo. Con la GenAI stiamo recitando lo stesso copione di internet, degli inverni AI e della guida autonoma. Sovrastimiamo il breve termine, sottostimiamo il lungo termine. Non sono due errori distinti, bensì lo stesso sbaglio che si manifesta in due tempi diversi. E con l'AI generativa stiamo recitando il copione alla perfezione. ## Un pattern, non un'anomalia Per capire dove stiamo andando, dobbiamo rispolverare la saggezza di [Roy Amara](https://en.wikipedia.org/wiki/Roy_Amara). Un ricercatore e futurista che, mentre il mondo del 1968 guardava all'oggi, fondava l'Institute for the Future. Nel 1978 formulò quella che oggi chiamiamo Legge di Amara: "Tendiamo a sovrastimare l'effetto di una tecnologia nel breve termine e a sottostimarlo nel lungo termine." Cinquant'anni di storia tecnologica in una frase. Prima ci esaltiamo. Poi, delusi, abbandoniamo. Chi resta in campo mentre gli altri se ne vanno raccoglie i frutti — e chi aveva abbandonato rimpiange la scelta. Il problema non è la tecnologia in sé. Come recita Amara, ciò che sovrastimiamo e poi sottostimiamo è l'effetto della stessa. Non ci manca la capacità di comprendere la tecnologia; quello in cui siamo carenti è la capacità di stimare con accuratezza le conseguenze che avrà sul business e sul mondo. Questo pattern di eccessi — in una direzione e poi nell'opposta — ricorre con tale regolarità che nel 1995 Jackie Fenn di Gartner lo ha trasformato in una mappa: l'[Hype Cycle](https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence). Una montagna russa in cinque atti che parte dal Technology Trigger, esplode nel Peak of Inflated Expectations e precipita inesorabilmente nel Trough of Disillusionment. Solo chi sopravvive alla caduta può risalire la Slope of Enlightenment e approdare, infine, al Plateau of Productivity. Non tutte le tecnologie completano il giro. Alcune si fermano nel punto di minimo, morte e sepolte. Ma quelle che sopravvivono seguono la traiettoria con regolarità quasi inquietante. E allora, dove siamo con l'AI generativa? E cosa significa per chi deve prendere decisioni nei prossimi due, tre anni? ## Come funziona il gioco La prima fase, quella delle aspettative, la conosciamo fin troppo bene: l'abbiamo appena vissuta con le nuove frontiere della GenAI. Demo che colpiscono, previsioni ambiziose, ondate di investimenti. I risultati? Sempre dietro l'angolo. I problemi di scaling? Dettagli, li affronteremo dopo. "Questa volta è diverso" diventa il mantra — finché qualcuno non si accorge che no, non lo è. A quel punto arriva il raffreddamento. Le aspettative non si concretizzano, i progetti naufragano uno dietro l'altro, il consenso si ribalta con la stessa velocità con cui si era formato. Da "cambierà tutto" a "era solo fuffa" il passo è breve, spesso più di quanto ci piacerebbe pensare. Chi ci aveva creduto pesantemente perde; chi si era approcciato con maggior moderazione viene trascinato giù nella corrente negativa. Qui emerge un fenomeno cruciale. Mentre il pubblico e gli investitori si ritirano, la tecnologia continua a svilupparsi, nascosta, ormai lontana dai riflettori. I problemi tecnici si risolvono uno alla volta, l'infrastruttura matura, i costi calano. Chi ha abbandonato nel momento peggiore perde la fase successiva; chi è rimasto, magari ridimensionando le aspettative, si ritrova in pole position quando il plateau finalmente arriva. Il punto chiave, quello che la Legge di Amara cattura in due frasi: la tecnologia era reale. Erano le tempistiche e i modelli di business a essere sbagliati. ## Tre giri completi e uno in corso Il pattern si ripete. Tre casi lo illustrano. **Internet Bubble, 1995-2005.** Probabilmente il ciclo più estremo, almeno fino ad ora. Il picco delle aspettative gonfiate in versione parossistica. Il NASDAQ quadruplica, i rapporti prezzo/utili perdono ogni contatto con la realtà, "la profittabilità non conta" diventa saggezza convenzionale. Poi il crash, il Trough, violentissimo. Amazon crolla da oltre 100 dollari ad azione a meno di 6. E dopo, la lenta ma altrettanto incredibile risalita. Vent'anni dopo Amazon capitalizza oltre 2.000 miliardi. E-commerce, cloud computing, streaming hanno ridisegnato interi settori. La tecnologia era reale; erano le tempistiche attese a essere sbagliate, e di parecchio. **L'AI stessa, 1956-2012.** Due inverni, li chiamano. Un ciclo diverso da quello di internet — non un crash improvviso, ma una discesa lenta, fatta di delusioni accumulate e fondi che si prosciugano anno dopo anno. Più complesso, più lungo, meno spettacolare. Ma il pattern è lo stesso. Il primo picco arriva negli anni '60: la traduzione automatica sembra imminente, le promesse si moltiplicano. Poi i risultati non arrivano, i governi tagliano i fondi, le cattedre si svuotano. Primo Trough. Negli anni '80, una breve risalita. I sistemi esperti sembrano la soluzione, gli investimenti tornano. Ma anche quella bolla scoppia — troppo rigidi, troppo costosi, impossibili da scalare. Secondo inverno, secondo Trough. Le reti neurali tornano nel dimenticatoio. Geoffrey Hinton, Yann LeCun, Yoshua Bengio continuano a lavorarci mentre il consenso è altrove. Sono considerati dei romantici, nella migliore delle ipotesi. Nel 2012 AlexNet vince ImageNet, e il resto è storia. Chi aveva abbandonato le reti neurali non immaginava cosa stava perdendo — e chi era uscito nel momento sbagliato non rientra mai alle stesse condizioni. Mezzo secolo dal primo hype al breakthrough. Cinquant'anni per completare il ciclo. **Guida autonoma, 2015-oggi.** Un ciclo ancora in corso, e siamo nel mezzo del Trough. Nel 2015 ogni CEO del settore automotive prediceva veicoli senza conducente entro il 2020. Tesla, Uber, Google, tutti convintissimi. Aspettative alle stelle, investimenti a pioggia — il picco classico. Siamo nel 2026 e Waymo opera in poche città americane, con espansione graduale. Le robotaxi esistono, ma non hanno ridisegnato la mobilità urbana come previsto. Non è un fallimento — è la fase di disillusione, quella in cui le aspettative si ridimensionano mentre la tecnologia, in silenzio, continua a maturare. Il plateau arriverà, ma nessuno sa ancora quando. Il pattern è sempre lo stesso: la risposta a "funzionerà?" era corretta. La domanda "quando?" era sbagliata — di anni, a volte di decenni. E la GenAI? Stesso copione, atto in corso. ## GenAI oggi: dove siamo nel giro Il [Gartner Hype Cycle for AI 2025](https://www.gartner.com/en/newsroom/press-releases/2025-08-05-gartner-hype-cycle-identifies-top-ai-innovations-in-2025) posiziona GenAI nel Trough of Disillusionment. Dopo un anno passato al picco delle aspettative, la discesa incombe — o ci siamo già dentro. Ma quali aspettative, esattamente? Ce ne sono due tipi, e viaggiano su binari separati. Da un lato l'hype sulle capability tecniche: cosa sa fare il modello, in concreto. Claude Code scrive codice, MidJourney genera immagini, Sora produce video. Funzionano, magari non perfettamente e non sempre, ma funzionano. Queste fondamenta sono reali. Sull'altro binario c'è l'hype sul valore di business: l'aumento di produttività tanto atteso, i risparmi sui task che si riescono ad automatizzare. Qui il quadro si complica, perché una tecnologia può funzionare benissimo ma non generare valore economico. Almeno, non nei tempi e nei modi che ci si aspettava. I numeri raccontano quanto sia stato sovrastimato questo secondo binario. [S&P Global](https://www.spglobal.com/market-intelligence/en/news-insights/research/ai-experiences-rapid-adoption-but-with-mixed-outcomes-highlights-from-vote-ai-machine-learning) riporta che il 42% delle aziende sta abbandonando la maggior parte dei progetti AI. I CEO soddisfatti del ritorno sugli investimenti sono meno del 30%. E poi c'è il dato [MIT NANDA](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/). Il 95% dei pilot non genera impatto economico misurabile. Diciannove su venti. Quest'ultimo numero merita una precisazione. Lo studio definisce questo "impatto misurabile" in modo preciso, perfettamente in linea con la Legge di Amara: un effetto quantificabile su ricavi, costi o produttività a livello di business unit. Non basta che lo strumento funzioni (perché di solito funziona), deve anche muovere un indicatore finanziario. Il 95% è un dato severo, che deve far riflettere. Ma non significa che quei progetti fossero inutili: molti hanno generato apprendimento organizzativo, competenze, infrastruttura. Cose che non si traducono in guadagno immediato, ma che restano e diventano le fondamenta per lo sviluppo futuro. Gartner sostiene che raggiungeremo il Plateau of Productivity fra due o cinque anni. La maturazione potrebbe quindi arrivare entro il 2028-2030. Ma i cicli precedenti insegnano una cosa: queste stime tendono a essere ottimistiche. Qualche primissimo segnale di maturazione, comunque, c'è. Ma è anche in corso una presa di coscienza. Thomas Davenport e Randy Bean, su [MIT Sloan Management Review](https://sloanreview.mit.edu/article/five-trends-in-ai-and-data-science-for-2026/), tirano in ballo proprio Amara: "Pensiamo che l'AI sia e resterà una parte importante dell'economia globale, ma ci siamo lasciati andare alla sovrastima di breve termine. L'industria AI e il mondo trarrebbero beneficio da una piccola, lenta perdita nella bolla." Insomma, ci stiamo avviando verso il punto di minimo. La domanda è: e adesso? ## Cosa farsene La Legge di Amara non vuole essere un consiglio di investimento. Non dice "compra" né dice "aspetta". Dice qualcosa di più sottile: il consenso attuale è probabilmente sbagliato, come lo era nel picco. Chi nel 2001 guardò deluso i dati su internet e concluse "è finita" aveva ragione a disperarsi sui dati. Torto marcio sulla previsione. Chi nel 1999 guardò gli stessi dati e concluse "questa volta è diverso" aveva torto su entrambi i fronti. Il punto di minimo è un momento strano, a pensarci. I concorrenti scappano, le competenze iniziano a costare meno (per forza: nessuno le cerca), e finalmente cominci a capire cosa ci puoi fare davvero, con questa tecnologia. È il momento in cui la tecnologia matura nel silenzio, lontano dai riflettori, mentre tutti guardano altrove. Il rischio, però, è scambiare un passaggio per la fine del viaggio. "Non funziona" e "non funziona ancora" sembrano quasi la stessa frase. Ma non lo sono. La prima ti fa abbandonare il progetto. La seconda ti lascia uno spiraglio. Quello giusto, se hai la pazienza di tenerlo aperto. La tecnologia è reale. Le fondamenta ci sono e si rinforzeranno negli anni. Il valore di business arriverà, ma seguirà i suoi tempi, non quelli dettati dalle prime pagine dei giornali. Per chi deve decidere oggi, la domanda non è se investire. È come calibrare le aspettative — e quanto fiato tenere. Amara ci aveva avvisati cinquant'anni fa. A noi spetta solo decidere se ascoltarlo. --- ## Per approfondire - [MIT NANDA: The GenAI Divide (2025)](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) — *Il report che ha fatto tremare Wall Street: metodologia, dati completi e il "learning gap" che spiega i fallimenti.* - [Gartner Hype Cycle for AI 2025](https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence) — *Dove Gartner posiziona GenAI, AI agents e le altre tecnologie emergenti nel ciclo.* - [S&P Global: Voice of the Enterprise (2025)](https://www.spglobal.com/market-intelligence/en/news-insights/research/ai-experiences-rapid-adoption-but-with-mixed-outcomes-highlights-from-vote-ai-machine-learning) — *Survey su 1.000+ aziende: tassi di abbandono, soddisfazione CEO e confronto 2024-2025.* - [Davenport & Bean: Five Trends in AI for 2026](https://sloanreview.mit.edu/article/five-trends-in-ai-and-data-science-for-2026/) — *L'articolo che cita esplicitamente Amara per spiegare la fase attuale.* - [Roy Amara (Wikipedia)](https://en.wikipedia.org/wiki/Roy_Amara) — *Chi era il futurista che ha formulato la legge nel 1978.* --- ## Testing Non-Deterministico: Come si fa QA sugli Agenti? - URL: https://ireneburresi.dev/blog/engineering/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. --- ## The AI Act Is Not (Just) Compliance: It's Industrial Policy - URL: https://ireneburresi.dev/blog/governance/ai-act-geop/ - 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/governance/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/). --- ## Constitutional AI: A Guide for Claude Users - URL: https://ireneburresi.dev/blog/research/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 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/research/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/business/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 > 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/business/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. --- ## You're Measuring AI Wrong - URL: https://ireneburresi.dev/blog/business/misurare-ia/ - 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/business/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. --- ## AI Sovereignty: Europe's Decision Point - URL: https://ireneburresi.dev/blog/governance/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 > 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/governance/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 --- ## Why replacing people doesn't fix the team - URL: https://ireneburresi.dev/blog/methodology/debugging-organizzativo-hackman/ - Pillar: Metodologia - Published: 2025-03-22 - Tags: Team Design, Hackman, Organizational Design, Team Effectiveness, Fundamental Attribution Error, Diagnostics - Author: Irene Burresi > Not "who isn't working" but "what in the structure isn't working." Six misdiagnoses flipped using Hackman's framework. The first debug is on the structure. Marco's team isn't working. Everyone knows it. The diagnosis comes fast: "Marco isn't motivated." "Sara doesn't communicate." The plan: a one-on-one with Marco to figure out what's blocking him, a team building workshop, and if things don't improve, swap someone out. Three months later, Marco is gone. Luca replaced him. The team still isn't working. The scene keeps repeating because the diagnosis is wrong. Not wrong in an obvious way — wrong in a plausible way, which is worse. "Marco isn't motivated" sounds reasonable. Everyone nods. Too bad the problem isn't Marco. Social psychology has a name for this: *fundamental attribution error*. Ross described it in 1977: when we observe behavior, we tend to attribute it to personal traits (laziness, poor collaboration) while underestimating the weight of the situation the person is in. J. Richard Hackman spent forty years studying teams: flight crews, orchestras, intelligence squads. The bottom line of his research: structural conditions explain up to 80% of variance in team effectiveness ([Wageman, Hackman & Lehman, 2005](https://doi.org/10.1177/0021886305281984)). When a team isn't working, the most likely problem isn't who's in it. It's how it was designed. Before replacing people, check the conditions. --- ## The five conditions: a checklist, not a theory Hackman didn't produce an abstract model. He produced a checklist. Five conditions that, when present, make it likely a team will work. When absent, make it likely it won't. He validated them empirically across hundreds of teams in different contexts. They work as a diagnostic tool long before they work as theory. Here's a quick translation into software context. For the full picture, start with the [previous piece on Hackman's team vs. working group distinction](/blog/methodology/hackman-real-team-software/). **1. Being a real team.** Clear boundaries, stable composition, real interdependence. If even one of these three is missing, you don't have a team. You have a group of people with a shared manager. **2. A compelling direction.** A clear, challenging, meaningful objective. Not "close the sprint stories" — that's a unit of measurement, not a direction. A compelling direction answers the question: why does this work matter? **3. An enabling structure.** Roles, norms, skills. The minimum infrastructure so people don't have to renegotiate everything from scratch every week. **4. A supportive organizational context.** Does the team have the information it needs? The resources? Does the reward system incentivize group outcomes or individual performance? This is the condition the team can't give itself. It depends on the organization around it. **5. Competent process coaching.** Not technical mentoring: someone who helps the team work better *together*. How they make decisions, handle disagreements, distribute work. It's the condition that matters least of the five (the 10% in Hackman's 60/30/10), but it's the one everyone focuses on. The instinct when managing teams is to start at the bottom: coaching, facilitation, interpersonal dynamics. Hackman says: start at the top. --- ## The table that flips the diagnosis This is the core of the argument. Six phrases I hear repeated constantly. For each one: the usual diagnosis, the most likely structural cause, and where to look instead. Some of these mappings are directly anchored to Hackman's research. Others are my translation into the software context, and I flag them as such. ### "Marco isn't motivated" It's Marco's problem, people say. He lacks drive, ownership. Maybe he's not right for the role. More likely, the team lacks a **compelling direction** (condition 2). If the team's objective is vague, purely administrative, or changes every two weeks, motivation isn't a trait of Marco's. It's a rational response to a context that gives no reason to invest energy. I've seen brilliant developers seem disengaged because their team's mandate was "support the product" — which in practice meant answering tickets endlessly with no vision of where things were heading. Don't look at Marco. Look at the team's mandate. If you can't explain in one sentence why the work matters, that's your problem. ### "Sara doesn't communicate" Where to look here is at work design. If everyone works on a separate feature and interactions are limited to the occasional comment on a pull request, there's no structural reason to communicate more. Sara isn't uncollaborative. She's rational: why would she update others on work that doesn't affect them? The cause is a lack of **real interdependence** (condition 1). You can run all the communication workshops you want: if the work structure doesn't create mutual dependencies, communication will remain an empty ritual. ### "The team doesn't trust each other" The classic response: team building activities, vulnerability exercises, an offsite to get to know each other better. Trust in a team doesn't come from an afternoon workshop. It comes from working together long enough to predict how the other person will behave. Hackman saw this with flight crews: crews that had flown together for a while made fewer errors than newly formed ones, even with less experienced pilots. The most likely problem is **unstable composition** (condition 1). If you rotate people between teams every quarter, you restart from zero each time. How many times has the team's composition changed in the past year? If the answer is "often," the trust deficit isn't a relationship problem. It's structural turnover. ### "Retros don't produce anything" Here the question comes before the answer: is there a shared process to improve? Retrospectives assume a team that collaborates on a common outcome and wants to improve how they do it. If everyone has their own workflow, priorities, and blockers, the retro has no object. The format is irrelevant. The cause is that the group isn't a **real team** (condition 1). ### "The lead can't guide the team" The usual diagnosis: they lack soft skills. Send them to a leadership course. The lead might be excellent. But if the team doesn't have access to the information it needs, if resources get cut without notice, if the evaluation system rewards individual performance and ignores group outcomes, the lead is in an impossible position. It's like asking a pilot to land well with a poorly designed airplane — you can send them to every flight course there is, but if the flaps don't work, the problem isn't their technique. The cause is the **organizational context** (condition 4). Does the lead have the authority to make decisions? Are priorities stable enough to allow a plan? If not, the leverage is in the organization, not the person. ### "Too much conflict" Here the answer is less straightforward. Conflict in a team can be a good sign: if the team is real and negotiating norms for working together (condition 3), some friction is physiological. Hackman says it clearly: the best teams aren't conflict-free. They're teams that have learned to manage conflict. But conflict can also signal **unclear boundaries** (condition 1): who decides what? Who has authority over which part of the system? If two people both think they're responsible for the same area, the conflict isn't relational. It's structural. The useful distinction: if the conflict is about *how* to do things, it's probably healthy. If it's about *who* should do what, it's a boundary problem. And if it's chronic despite everyone's best intentions, it's almost certainly not a people problem. --- ## Why we keep getting the diagnosis wrong If structural conditions matter this much, why does the default remain "someone's fault"? The first reason is that **structure is invisible**. You see people. You see behaviors. You don't see the conditions in which those behaviors emerge. Hackman pressed this point in the last paper of his career, "From causes to conditions" ([Hackman, 2012](https://onlinelibrary.wiley.com/doi/full/10.1002/job.1774)): research on teams has focused too much on internal causes (who does what, how they behave) and too little on external conditions (how the team is designed, what context it operates in). The same applies to people managing teams in practice. The second is that **replacing people feels easier**. Giving Marco feedback, sending Sara to a workshop, swapping the lead: these are all actions a manager can take tomorrow morning. Redesigning the team's mandate, stabilizing composition, changing the incentive system — those require time, authority, and often negotiation with someone above. The interpersonal diagnosis is attractive because it has solutions at hand. Too bad they're the wrong solutions. The third is more insidious, and I've seen it up close: **the organization incentivizes individual diagnosis**. Performance reviews evaluate people, not conditions. PIPs apply to people. "Cultural fit" is an attribute of people. The entire management apparatus is built around the idea that performance is an individual trait. Admitting the problem is structural means admitting the system is poorly designed — and the person who designed the system is often the one making the diagnosis. --- Next time someone says "the problem is Marco," pause for a moment. Not because Marco is necessarily innocent: sometimes the problem really is the person. But it's less common than we think, and the interpersonal diagnosis is so intuitive we always get there first. Try reframing. Not "who isn't working?" but "what in the structure isn't working?" Move from person to condition. Then ask yourself: is this condition under my control? If yes, that's where the energy goes. If not, at least you know that no team building workshop will fix it. It's not a small difference. It's the difference between debugging the code and debugging the compiler. --- ## Sources - Hackman, J.R. (2002). *Leading Teams: Setting the Stage for Great Performances*. Harvard Business School Press. - Hackman, J.R. (2011). *Collaborative Intelligence: Using Teams to Solve Hard Problems*. Berrett-Koehler. - Hackman, J.R. (2012). [From causes to conditions in group research](https://onlinelibrary.wiley.com/doi/full/10.1002/job.1774). *Journal of Organizational Behavior*, 33, 428-444. - Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). [Team Diagnostic Survey: Development of an Instrument](https://doi.org/10.1177/0021886305281984). *Journal of Applied Behavioral Science*, 41(4), 373-398. - Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), *Advances in Experimental Social Psychology* (Vol. 10, pp. 173-220). Academic Press. --- ## Perché cambiare le persone non cambia il team - URL: https://ireneburresi.dev/blog/methodology/debugging-organizzativo-hackman/ - Pillar: Metodologia - Published: 2025-03-22 - Tags: Team Design, Hackman, Organizational Design, Team Effectiveness, Fundamental Attribution Error, Diagnostica - Author: Irene Burresi > Non "chi non funziona" ma "cosa nella struttura non funziona". Sei diagnosi ribaltate col framework di Hackman. Il primo debug è sulla struttura. Il team di Marco non funziona. Lo sanno tutti. La diagnosi arriva in fretta: "Marco non è motivato". "Sara non comunica". Si decide: un one-on-one con Marco per capire cosa lo blocca, un workshop di team building, e se le cose non migliorano si cambia qualcuno. Tre mesi dopo, Marco se n'è andato. È arrivato Luca. Il team non funziona ancora. La scena si ripete perché la diagnosi è sbagliata. Non sbagliata in modo ovvio — sbagliata in modo plausibile, che è peggio. "Marco non è motivato" suona ragionevole. Tutti annuiscono. Peccato che il problema non sia Marco. La psicologia sociale ha un nome per questo: *fundamental attribution error*. Ross lo ha descritto nel 1977: quando osserviamo un comportamento, tendiamo ad attribuirlo a tratti della persona (pigrizia, scarsa collaboratività) sottovalutando il peso della situazione in cui quella persona si trova. J. Richard Hackman ha studiato team per quarant'anni: equipaggi di volo, orchestre, squadre di intelligence. Il punto fermo della sua ricerca: le condizioni strutturali in cui un team opera spiegano fino all'80% della varianza nella sua efficacia ([Wageman, Hackman & Lehman, 2005](https://doi.org/10.1177/0021886305281984)). Quando un team non funziona, il problema più probabile non è chi ci lavora dentro. È come è stato progettato. Prima di cambiare le persone, conviene verificare le condizioni. --- ## Le cinque condizioni: una checklist, non una teoria Hackman non ha prodotto un modello astratto. Ha prodotto una checklist. Cinque condizioni che, se presenti, rendono probabile che un team funzioni. Se assenti, rendono probabile il contrario. Le ha validate empiricamente su centinaia di team in contesti diversi, e funzionano come strumento diagnostico molto prima che come teoria. Le riassumo con una traduzione rapida nel contesto software. Chi vuole il quadro completo può partire dal [pezzo precedente su Hackman e la distinzione team/gruppo di lavoro](/blog/methodology/hackman-real-team-software/). **1. Essere un team reale.** Confini chiari, composizione stabile, interdipendenza reale. Se manca anche solo una di queste tre, non hai un team. Hai un gruppo di persone con un manager in comune. **2. Una direzione convincente.** Un obiettivo chiaro, sfidante e significativo. Non "chiudere le story dello sprint", che è un'unità di misura, non una direzione. Una direzione convincente risponde alla domanda: perché questo lavoro conta? **3. Una struttura abilitante.** Ruoli, norme, competenze. Il minimo di infrastruttura perché le persone non debbano rinegoziare tutto da zero ogni settimana. **4. Un contesto organizzativo che supporta.** Il team ha le informazioni che gli servono? Le risorse? Il sistema di reward incentiva il risultato di gruppo o la performance individuale? Questa è la condizione che il team non può darsi da solo. Dipende dall'organizzazione intorno. **5. Un coaching competente sul processo.** Non mentoring tecnico: qualcuno che aiuta il team a lavorare meglio *insieme*. Come prendono decisioni, come gestiscono i disaccordi, come distribuiscono il lavoro. È la condizione che conta meno delle altre quattro (il 10% del 60/30/10 di Hackman), ma è quella su cui tutti si concentrano. L'istinto di chi gestisce team è partire dal fondo: coaching, facilitazione, dinamiche interpersonali. Hackman dice: parti dall'alto. --- ## La tabella che ribalta la diagnosi Ecco il nucleo del discorso. Sei frasi che sento ripetere in continuazione, e per ciascuna la diagnosi abituale, la causa strutturale più probabile, e dove conviene guardare. Alcune di queste mappature sono ancorabili direttamente alla ricerca di Hackman. Altre sono la mia traduzione nel contesto software, e le segnalo. ### "Marco non è motivato" È un problema di Marco, si dice. Manca di drive, di ownership, forse non è la persona giusta per il ruolo. Più probabilmente manca una **direzione convincente** (condizione 2). Se l'obiettivo del team è vago, puramente gestionale o cambia ogni due settimane, la motivazione non è un tratto di Marco. È una risposta razionale a un contesto che non dà ragioni per investire energia. Ho visto sviluppatori brillanti sembrare svogliati perché il mandato del loro team era "supportare il prodotto", che in pratica significava rispondere a ticket senza fine e senza una visione di dove si stava andando. Non guardare a Marco. Guarda al mandato del team. Se non riesci a spiegare in una frase perché quel lavoro conta, il problema è lì. ### "Sara non comunica" Dove guardare, in questo caso, è al design del lavoro. Se ogni persona lavora su una feature separata e le interazioni si limitano a qualche commento su una pull request, non c'è motivo strutturale per comunicare di più. Sara non è poco collaborativa. È razionale: perché dovrebbe aggiornare gli altri su un lavoro che non li riguarda? La causa è la mancanza di **interdipendenza reale** (condizione 1). Puoi organizzare tutti i workshop di comunicazione che vuoi: se la struttura del lavoro non genera dipendenze reciproche, la comunicazione resterà un rituale vuoto. ### "Il team non si fida" La reazione classica: team building, esercizi di vulnerabilità, un offsite per conoscersi meglio. La fiducia in un team non nasce da un workshop di un pomeriggio. Nasce dal lavorare insieme abbastanza a lungo da poter prevedere come si comporterà l'altro. Hackman lo ha visto con gli equipaggi di volo: quelli che volavano insieme da tempo commettevano meno errori di quelli appena formati, anche con piloti meno esperti. Il problema più probabile è la **composizione instabile** (condizione 1). Se ogni trimestre ruoti le persone tra team, riparti da zero ogni volta. Quante volte è cambiata la composizione nell'ultimo anno? Se la risposta è "spesso", il deficit di fiducia non è un problema relazionale. È turnover strutturale. ### "Le retro non producono nulla" Qui la domanda viene prima della risposta: c'è un processo condiviso da migliorare? Le retrospettive presuppongono un team che collabora su un risultato comune e vuole migliorare il modo in cui lo fa. Se ognuno ha il suo flusso, le sue priorità e i suoi blocchi, la retro non ha un oggetto. Il formato non c'entra. La causa è che il gruppo non è un **team reale** (condizione 1). ### "Il lead non riesce a guidare il team" La diagnosi abituale: mancano le soft skill. Mandiamolo a un corso di leadership. Il lead può essere bravissimo, ma se il team non ha accesso alle informazioni che gli servono, se le risorse vengono tagliate senza preavviso, se il sistema di valutazione premia la performance individuale e ignora quella di gruppo, il lead è in una posizione impossibile. È come chiedere a un pilota di atterrare bene con un aereo progettato male — puoi mandarlo a tutti i corsi di volo che vuoi, ma se i flap non funzionano, il problema non è la sua tecnica. La causa è il **contesto organizzativo** (condizione 4). Il lead ha l'autorità per prendere decisioni? Le priorità sono stabili abbastanza da permettere un piano? Se no, la leva è nell'organizzazione, non nella persona. ### "Troppi conflitti" Qui la risposta è meno lineare. Il conflitto in un team può essere un buon segno: se il team è reale e sta negoziando le norme su come lavorare insieme (condizione 3), un certo grado di attrito è fisiologico. Hackman lo dice chiaramente: i team migliori non sono quelli senza conflitti, sono quelli che hanno imparato a gestirli. Ma il conflitto può anche essere il sintomo di **confini poco chiari** (condizione 1): chi decide cosa? Chi ha autorità su quale parte del sistema? Se due persone pensano entrambe di essere responsabili della stessa area, il conflitto non è relazionale. È strutturale. La distinzione utile: se il conflitto è su *come* fare le cose, probabilmente è sano. Se è su *chi* dovrebbe fare cosa, è un problema di confini. E se è cronico nonostante le buone intenzioni di tutti, quasi certamente non è un problema di persone. --- ## Perché continuiamo a sbagliare diagnosi Se le condizioni strutturali contano così tanto, perché il default è sempre "colpa di qualcuno"? La prima ragione è che **la struttura è invisibile**. Le persone le vedi. I comportamenti li vedi. Le condizioni in cui quei comportamenti emergono, no. Hackman ha insistito su questo punto nell'ultimo paper della sua carriera, "From causes to conditions" ([Hackman, 2012](https://onlinelibrary.wiley.com/doi/full/10.1002/job.1774)): la ricerca sui team si è concentrata troppo sulle cause interne (chi fa cosa, come si comportano) e troppo poco sulle condizioni esterne (come il team è progettato, in che contesto opera). Lo stesso vale per chi gestisce team nella pratica. La seconda è che **cambiare le persone sembra più facile**. Dare un feedback a Marco, mandare Sara a un workshop, sostituire il lead: sono tutte azioni che un manager può fare domani mattina. Ridisegnare il mandato del team, stabilizzare la composizione, cambiare il sistema di incentivi richiedono tempo, autorità e spesso negoziazione con chi sta sopra. La diagnosi interpersonale è attraente perché ha soluzioni a portata di mano. Peccato che siano le soluzioni sbagliate. La terza è più insidiosa, e l'ho vista da vicino: **l'organizzazione incentiva la diagnosi individuale**. Le performance review valutano le persone, non le condizioni. I PIP si applicano alle persone. Il "fit culturale" è un attributo delle persone. L'intero apparato di gestione è costruito attorno all'idea che la performance sia un tratto individuale. Ammettere che il problema è strutturale significa ammettere che il sistema è progettato male, e chi ha progettato il sistema è spesso chi sta facendo la diagnosi. --- La prossima volta che qualcuno dice "il problema è Marco", fermati un momento. Non perché Marco sia necessariamente innocente: a volte il problema è davvero la persona. Ma è meno frequente di quanto pensiamo, e la diagnosi interpersonale è così intuitiva che ci arriviamo sempre per prima. Prova a riformulare. Non "chi non funziona?" ma "cosa nella struttura non funziona?". Passa dalla persona alla condizione. Poi chiediti: questa condizione è sotto il mio controllo? Se sì, è lì che va l'energia. Se no, almeno sai che nessun workshop di team building la risolverà. Non è una differenza da poco. È la differenza tra debuggare il codice e debuggare il compilatore. --- ## Fonti - Hackman, J.R. (2002). *Leading Teams: Setting the Stage for Great Performances*. Harvard Business School Press. - Hackman, J.R. (2011). *Collaborative Intelligence: Using Teams to Solve Hard Problems*. Berrett-Koehler. - Hackman, J.R. (2012). [From causes to conditions in group research](https://onlinelibrary.wiley.com/doi/full/10.1002/job.1774). *Journal of Organizational Behavior*, 33, 428-444. - Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). [Team Diagnostic Survey: Development of an Instrument](https://doi.org/10.1177/0021886305281984). *Journal of Applied Behavioral Science*, 41(4), 373-398. - Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), *Advances in Experimental Social Psychology* (Vol. 10, pp. 173-220). Academic Press. --- ## Frustrated with Agile? Maybe your team isn't actually a team - URL: https://ireneburresi.dev/blog/methodology/hackman-real-team-software/ - Pillar: Metodologia - Published: 2025-03-15 - Tags: Team Design, Agile, Hackman, Team vs Working Group, Scrum, 60-30-10 - Author: Irene Burresi > Hackman's distinction between real teams and working groups explains why standups, retros, and planning feel pointless. The problem isn't Agile — it's a structural mismatch. The standup takes twelve minutes. Five people, each reciting their update while staring at some vague point on the screen. Nobody comments on what anyone else says, because there's no reason to: everyone is working on their own feature, in a different corner of the codebase. The standup ends, everyone goes back to doing exactly what they would have done without it. Then the retro. Three sticky notes come out of it: "improve communication," same as last month. And sprint planning, which is really just individual task assignment with a two-week timer. If this sounds familiar, you're not alone. The [17th State of Agile Report](https://digital.ai/resource/state-of-agile-report/) by [Digital.ai](https://digital.ai/) (2024) found that only 11% of practitioners report being "very satisfied" with Agile practices in their organization. The frustration runs deep enough that two original signatories of the Agile Manifesto have publicly turned against what Agile has become: Ron Jeffries, co-creator of Extreme Programming, wrote that developers should [abandon Agile](https://ronjeffries.com/articles/018-01ff/abandon-1/), or at least the version organizations have made of it. Dave Thomas, another signatory, declared that [Agile is dead](https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html), hollowed out by marketing and mass certification. The most common diagnosis is that Agile has become bureaucracy: too many rituals, too much process, not enough code. It makes sense. Who hasn't thought that at least once, walking out of yet another endless planning session? But there's another possibility. One that has nothing to do with Agile itself, but with something more fundamental: the structure you're applying it to. J. Richard Hackman spent 40 years studying real teams: flight crews, orchestras, intelligence teams, surgical teams. His research, condensed in *Leading Teams* (2002) and *Collaborative Intelligence* (2011), arrives at a distinction that almost nobody in software makes: the distinction between a **team** and a **working group**. They are different things. They work differently. And they require different tools. Agile practices are designed for teams. Apply them to a working group and you get exactly the frustration you're feeling. The problem isn't the method. It's a structural mismatch. --- ## The most overused word in software In software, "team" is the default word for any group of people working on the same project. Five developers sharing a Jira board? Team. Two backend engineers, a frontend dev, and a designer reporting to the same manager? Team. Eight people across three time zones who meet at the 9 AM standup? Team. Hackman would disagree. In *Leading Teams* he defines a "real team" through three minimum properties, all required. The first is **clear boundaries**: everyone knows who is on the team and who is not. Sounds obvious, but in software practice it isn't. The designer "shared" across three teams — in or out? The developer "on loan" for two sprints — a member? If you can't make the list without hesitating, the boundaries aren't clear. The second is **stable composition**. People stay the same long enough to develop shared ways of working. Hackman studied flight crews: NASA data, which he reports in *Leading Teams*, showed that newly formed crews made more errors than those who had been flying together for a while, even when the newer crews had more experienced pilots. In software, quarterly rotation of people between teams destroys this effect. Every time, you start from zero. The third, and most underrated, is **real interdependence**. The team's output depends on collaboration between members — it's not the sum of individual contributions. This is where most software "teams" fall apart. Five developers working on five independent features, with five cross-reviews done as a formality, are not interdependent. One person's work doesn't change another's. If you removed all the meetings and put them in separate rooms, the result would be the same. The test is brutal in its simplicity: if you eliminated standups, retros, and planning tomorrow, and everyone worked on their own, would the final product suffer? If the answer is no — if the result would be identical, maybe even faster without the interruptions — then what you have is not a team. It's a group of individuals with a shared manager. That's not an insult. It's a diagnosis. And the diagnosis is the first step toward stopping the use of the wrong tools. --- ## Structural conditions: the 60/30/10 Hackman didn't stop at the definition. He studied what makes a team effective, and the answer is less intuitive than you'd think. Research by Hackman and his collaborator Ruth Wageman identifies five conditions that enable team performance: being a real team, having a compelling direction, an enabling structure, a supportive organizational context, and competent coaching. I won't go deep on all of them here — each deserves its own article. The relevant point is different: how much do these conditions matter compared to what a leader does day to day? Hackman's answer, laid out in *Collaborative Intelligence* (2011), is the **60/30/10**: 60% of a team's effectiveness depends on design — the structural conditions put in place before the team starts working. 30% depends on launch — how the team is kicked off, the first days, the initial norms. The remaining 10% on ongoing coaching. A clarification: Hackman presents this split as a "best estimate," not as the result of a single study yielding those exact percentages. It's a heuristic that synthesizes decades of research. Not a precise data point. But the order of magnitude has solid empirical grounding. The Team Diagnostic Survey (TDS), developed by Wageman, Hackman, and Lehman and published in 2005, was administered to 2,474 people across 321 teams. The finding: structural conditions explain up to 80% of the variance in team effectiveness ([Wageman, Hackman & Lehman, 2005](https://doi.org/10.1177/0021886305281984)). Not 20%. Not 50%. Eighty percent. An earlier study by Wageman (2001) on [43 self-managing teams at Xerox](https://doi.org/10.1287/orsc.12.5.559.10094) had already shown the same pattern: a leader's design activities influenced team performance. Day-to-day coaching activities did not. The implication for software is direct. When a team isn't working, the instinctive reaction is to work on dynamics: facilitate retros better, improve communication, do team building. Hackman's framework suggests the most powerful lever is upstream. Who is on the team? What is the mandate? How is the work designed? Does the organizational context support it? If these conditions aren't there, no amount of facilitation will compensate. But the first of those five conditions — "being a real team" — opens a question that almost nobody in software asks. --- ## Team or working group: the distinction that changes everything A point Hackman makes often, and that gets misunderstood just as often: the distinction between team and working group is not a value judgment. It's not "team = good, working group = bad." They are two different organizational modes, each with its own strengths. A **working group** is a set of people reporting to the same manager who may coordinate, but whose output is primarily individual. Everyone has their own goals, responsibilities, deliverables. The manager coordinates, assigns, removes obstacles. Deep interdependence is not required. A **team** produces collective output. The result cannot be decomposed into the sum of individual contributions: it requires continuous collaboration, shared decisions, mutual adjustment. The cost is higher — you need stable boundaries, shared norms, time to develop ways of working together. But for certain kinds of problems, it's the only configuration that works. The damage comes from confusing the two. A working group managed as a team generates overhead without benefit. Coordination meetings exist, but there's nothing substantial to coordinate. Retrospectives don't produce actions because there's no shared process to improve: everyone has their own workflow, priorities, blockers. The Agile ceremony becomes a fixed cost on work that doesn't require it. The damage goes both ways, though. A real team managed as a working group is equally dysfunctional. If you have people who need to collaborate on a complex problem and treat them as individual contributors — assigning separate tasks, evaluating them individually, without protecting time for joint work — you're undermining the one thing that makes that team effective: interdependence. I've seen both scenarios. The first is more common in software, because the default organization tends to be the working group (developers assigned to individual features), while the process infrastructure is almost always that of a team (Scrum, Kanban with standups, retros, planning). The operational question isn't "how do I improve my team?" It's more fundamental: is what I'm leading a team or a working group? The answer changes everything that follows. --- ## The Agile mismatch: right tools, wrong structure Back to the frustration we started with. Agile practices — Scrum in particular — didn't emerge in a vacuum. They're designed around a specific assumption: that a small group of people works interdependently toward a shared goal, iterating together. The sprint assumes a common goal. The standup assumes that knowing what others are doing changes your work. The retro assumes a shared process to inspect. Planning assumes collective prioritization decisions. These are all tools that assume interdependence. Without it, they lose their point. Now look at the typical "team" setup in many software organizations. People are assigned — often rotated — to a "team" that is really an organizational container. Everyone works on their own user story, with interactions limited to code review and the occasional Slack question. The "sprint goal" is the sum of individual stories. Interdependence is minimal or absent. Apply team tools to this structure and the result is predictable. The standup becomes a round of updates nobody listens to. The retro produces generic complaints. Planning becomes bureaucracy. Not because Scrum is bureaucracy — but because you're using it on a structure it wasn't designed for. The Manifesto signatories say as much, in different words. Jeffries talks about "Dark Scrum" — organizations using Agile rituals as control mechanisms, draining them of collaboration. Thomas says "Agile" was turned into a commercial noun when it was meant to be an adjective describing a way of working. Their critique is legitimate. But the diagnosis they offer — "organizations have corrupted Agile" — is incomplete. Hackman's framework provides a more structural one: many organizations haven't corrupted Agile. They've applied it to structures that aren't teams. I bring this up because I've seen it happen more times than I'd like to admit, including in contexts with competent people and good intentions. The standard response to the malaise was always the same: change the facilitator, try a different retro format, add a ceremony. Hackman's framework gave me the vocabulary for what I felt but couldn't articulate: the problem wasn't the execution. It was the premise. This changes the diagnosis and the solutions. If the problem is "Agile has become bureaucracy," the answer is less process, fewer rituals, more autonomy. Sometimes that's right. But if the problem is a structural mismatch, the answer is different: either transform the structure into a real team — with the costs that entails — or accept that you have a working group and adopt tools consistent with that reality. Both options are legitimate. What doesn't work is staying in the middle. --- Back to the twelve-minute standup we started with. Five people, five updates, no interaction. The obvious diagnosis is that the standup is poorly facilitated, or that Scrum doesn't work, or that the team needs to "work on communication." These are all responses that address the symptom. Hackman's question is different, and it comes first: do those five people need to talk to each other every morning to do their work? If each person's work doesn't depend on the others', the standup isn't poorly facilitated. It's useless by design. The retro doesn't produce actions because there's no shared process to improve. Planning is bureaucracy because there are no collective decisions to make. It's not a question of execution. It's a question of structure. Next time you think "Agile doesn't work," try reframing. Don't ask how to improve the process. Ask whether what you're leading is a team or a working group. The answer isn't a judgment. It's a diagnosis. And from the diagnosis, everything else follows. --- ## Sources - Hackman, J.R. (2002). *Leading Teams: Setting the Stage for Great Performances*. Harvard Business School Press. - Hackman, J.R. (2011). *Collaborative Intelligence: Using Teams to Solve Hard Problems*. Berrett-Koehler. - Wageman, R. (2001). [How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching](https://doi.org/10.1287/orsc.12.5.559.10094). *Organization Science*, 12(5), 559-577. - Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). [Team Diagnostic Survey: Development of an Instrument](https://doi.org/10.1177/0021886305281984). *Journal of Applied Behavioral Science*, 41(4), 373-398. - [Digital.ai](https://digital.ai/) (2024). [17th State of Agile Report](https://digital.ai/resource/state-of-agile-report/). - Jeffries, R. (2018). [Developers Should Abandon Agile](https://ronjeffries.com/articles/018-01ff/abandon-1/). - Thomas, D. (2014). [Agile is Dead (Long Live Agility)](https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html). --- ## L'Agile ti sembra frustrante? Forse perché il tuo team non è un team - URL: https://ireneburresi.dev/blog/methodology/hackman-real-team-software/ - Pillar: Metodologia - Published: 2025-03-15 - Tags: Team Design, Agile, Hackman, Team vs Working Group, Scrum, 60-30-10 - Author: Irene Burresi > La distinzione di Hackman tra team e gruppo di lavoro spiega perché standup, retro e planning sembrano inutili. Il problema non è Agile: è un mismatch strutturale. Lo standup dura dodici minuti. Cinque persone, ognuna recita il suo aggiornamento guardando un punto imprecisato dello schermo. Nessuno commenta quello che dicono gli altri, perché non c'è motivo: ognuno lavora sulla propria feature, in un angolo diverso del codebase. Finisce lo standup, tutti tornano a fare esattamente quello che avrebbero fatto senza. Poi c'è la retro. Ne escono tre post-it con "migliorare la comunicazione", gli stessi del mese scorso. E lo sprint planning, che in pratica è un'assegnazione di task individuali con un timer di due settimane. Se ti riconosci, non sei solo. Il [17th State of Agile Report](https://digital.ai/resource/state-of-agile-report/) di [Digital.ai](https://digital.ai/) (2024) riporta che solo l'11% dei praticanti si dichiara "molto soddisfatto" delle pratiche Agile nella propria organizzazione. La frustrazione è così diffusa che due firmatari del Manifesto Agile originale hanno preso posizioni pubbliche contro ciò che Agile è diventato: Ron Jeffries, co-creatore di Extreme Programming, ha scritto che gli sviluppatori dovrebbero [abbandonare Agile](https://ronjeffries.com/articles/018-01ff/abandon-1/), o almeno la versione che le organizzazioni ne hanno fatto. Dave Thomas, un altro firmatario, ha dichiarato che [Agile è morto](https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html), svuotato di significato dal marketing e dalla certificazione di massa. La diagnosi più comune è che Agile sia diventato burocrazia: troppi rituali, troppo processo, troppo poco codice. Ha senso. Chi non l'ha pensato almeno una volta, uscendo dall'ennesimo planning infinito? Ma c'è un'altra possibilità. Una che non ha a che fare con Agile in sé, ma con qualcosa di più basilare: la struttura su cui lo stai applicando. J. Richard Hackman ha passato 40 anni a studiare team reali: equipaggi di volo, orchestre, team di intelligence, squadre chirurgiche. La sua ricerca, condensata in *Leading Teams* (2002) e *Collaborative Intelligence* (2011), arriva a una distinzione che nel mondo software quasi nessuno fa: quella tra un **team** e un **gruppo di lavoro**. Sono cose diverse. Funzionano in modi diversi. E richiedono strumenti diversi. Le pratiche Agile sono progettate per team. Se le applichi a un gruppo di lavoro, il risultato è esattamente la frustrazione che stai provando. Il problema non è il metodo. È un mismatch strutturale. --- ## La parola più abusata nel software Nel mondo del software "team" è la parola predefinita per qualsiasi gruppo di persone che lavora nello stesso progetto. Cinque sviluppatori che condividono una board Jira? Team. Due backend, un frontend e un designer che riportano allo stesso manager? Team. Otto persone sparse su tre fusi orari che si vedono allo standup delle 9? Team. Hackman non sarebbe d'accordo. In *Leading Teams* definisce un "real team" attraverso tre proprietà minime, tutte necessarie. La prima è avere **confini chiari**: tutti sanno chi fa parte del team e chi no. Sembra banale, ma nella pratica software non lo è. Il designer "condiviso" tra tre team è dentro o fuori? Lo sviluppatore "in prestito" per due sprint, è un membro? Se non riesci a fare una lista senza esitare, i confini non sono chiari. La seconda è una **composizione stabile**. Le persone restano le stesse abbastanza a lungo da sviluppare modi di lavorare condivisi. Hackman studiava equipaggi di volo: i dati della NASA, che lui riporta in *Leading Teams*, mostravano che gli equipaggi appena formati commettevano più errori di quelli che volavano insieme da tempo, anche con piloti meno esperti. Nel software, la rotazione trimestrale delle persone tra team distrugge questo effetto. Ogni volta si ricomincia da zero. La terza, e la più sottovalutata, è l'**interdipendenza reale**. Il risultato del team dipende dalla collaborazione tra i membri, non è la somma di contributi individuali. Questo è il punto dove la maggior parte dei "team" software crolla. Cinque sviluppatori che lavorano su cinque feature indipendenti, con cinque code review incrociate per formalità, non sono interdipendenti. Il lavoro di uno non cambia il lavoro dell'altro. Se togliessi tutte le riunioni e li mettessi in stanze separate, il risultato sarebbe lo stesso. Il test è brutale nella sua semplicità: se domani eliminassi standup, retro e planning, e ognuno lavorasse per conto suo, il prodotto finale peggiorerebbe? Se la risposta è no, se il risultato sarebbe identico, magari persino più veloce senza le interruzioni, allora quello che hai non è un team. È un gruppo di individui con un manager in comune. Non è un insulto. È una diagnosi. E la diagnosi è il primo passo per smettere di applicare gli strumenti sbagliati. --- ## Le condizioni strutturali: il 60/30/10 Hackman non si è fermato alla definizione. Ha studiato cosa rende un team efficace, e la risposta è meno intuitiva di quanto sembri. La ricerca di Hackman e della sua collaboratrice Ruth Wageman identifica cinque condizioni che abilitano la performance di un team: essere un team reale, avere una direzione convincente, una struttura abilitante, un contesto organizzativo di supporto e un coaching competente. Non le approfondisco tutte qui, ognuna meriterebbe un articolo a sé. Il punto rilevante è un altro: quanto contano queste condizioni rispetto a quello che un leader fa giorno per giorno? La risposta di Hackman, formulata in *Collaborative Intelligence* (2011), è il **60/30/10**: il 60% dell'efficacia di un team dipende dal design, le condizioni strutturali messe in piedi prima che il team cominci a lavorare. Il 30% dipende dal lancio: come il team viene avviato, i primi giorni, le norme iniziali. Il restante 10% dal coaching in corso d'opera. Una precisazione: Hackman presenta questa ripartizione come una "best estimate", non come il risultato di un singolo studio con quelle percentuali esatte. È un'euristica che sintetizza decenni di ricerca. Non un dato puntuale. Ma l'ordine di grandezza ha un ancoraggio empirico solido. Il Team Diagnostic Survey (TDS), sviluppato da Wageman, Hackman e Lehman e pubblicato nel 2005, è stato somministrato a 2.474 persone in 321 team. Il risultato: le condizioni strutturali spiegano fino all'80% della varianza nell'efficacia dei team ([Wageman, Hackman & Lehman, 2005](https://doi.org/10.1177/0021886305281984)). Non il 20%, non il 50%. L'80%. Uno studio precedente di Wageman (2001) su [43 team autogestiti a Xerox](https://doi.org/10.1287/orsc.12.5.559.10094) aveva già mostrato lo stesso pattern: le attività di design del leader influenzavano la performance del team. Le attività di coaching quotidiano, no. L'implicazione per chi lavora nel software è diretta. Quando un team non funziona, la reazione istintiva è lavorare sulle dinamiche: facilitare meglio le retro, migliorare la comunicazione, fare team building. Il framework di Hackman suggerisce che la leva più potente è a monte. Chi fa parte del team? Qual è il mandato? Come è disegnato il lavoro? Il contesto organizzativo lo supporta? Se queste condizioni non ci sono, nessuna quantità di facilitazione compenserà. Ma la prima di quelle cinque condizioni, "essere un team reale", apre una domanda che nel software quasi nessuno si pone. --- ## Team o gruppo di lavoro: la distinzione che cambia tutto Va chiarito un punto che Hackman ripete spesso e che viene frainteso altrettanto spesso: la distinzione tra team e gruppo di lavoro non è un giudizio di valore. Non è "team = bene, gruppo di lavoro = male". Sono due modalità organizzative diverse, ognuna con i suoi vantaggi. Un **gruppo di lavoro** è un insieme di persone che riportano allo stesso manager e possono coordinarsi, ma il cui output è principalmente individuale. Ognuno ha i suoi obiettivi, le sue responsabilità, i suoi deliverable. Il manager coordina, assegna, rimuove ostacoli. Non c'è bisogno di interdipendenza profonda. Un **team** produce un output collettivo. Il risultato non è scomponibile nella somma dei contributi individuali: richiede collaborazione continua, decisioni condivise, aggiustamento reciproco. Il costo è più alto, servono confini stabili, norme condivise, tempo per sviluppare modi di lavorare insieme. Ma per certi tipi di problemi, è l'unica configurazione che funziona. Il danno nasce quando confondi le due cose. Un gruppo di lavoro gestito come team genera overhead senza beneficio. Le riunioni di coordinamento esistono, ma non c'è nulla di sostanziale da coordinare. Le retrospettive non producono azioni perché non c'è un processo condiviso da migliorare: ognuno ha il suo flusso, le sue priorità, i suoi blocchi. Il cerimoniale Agile diventa un costo fisso su un'attività che non lo richiede. Il danno, però, è bidirezionale. Un team reale gestito come un gruppo di lavoro è altrettanto disfunzionale. Se hai persone che devono collaborare su un problema complesso e le tratti come contributori individuali, assegnando task separati, valutandoli singolarmente, senza proteggere il tempo per il lavoro congiunto, stai sabotando l'unica cosa che rende quel team efficace: l'interdipendenza. Ho visto entrambi gli scenari. Il primo è più comune nel software, perché l'organizzazione predefinita tende ad essere il gruppo di lavoro (sviluppatori assegnati a feature individuali), ma l'infrastruttura di processo è quasi sempre quella del team (Scrum, Kanban con standup, retro, planning). La domanda operativa non è "come migliorare il mio team?". È più basilare: quello che guido, è un team o un gruppo di lavoro? La risposta cambia tutto ciò che viene dopo. --- ## Il mismatch Agile: strumenti giusti, struttura sbagliata Torniamo alla frustrazione di partenza. Le pratiche Agile, Scrum in particolare, non sono nate nel vuoto. Sono progettate attorno a un'assunzione precisa: che un piccolo gruppo di persone lavori in modo interdipendente su un obiettivo condiviso, iterando insieme. Lo sprint presuppone un goal comune. Lo standup presuppone che sapere cosa fanno gli altri cambi il tuo lavoro. La retro presuppone un processo condiviso da ispezionare. Il planning presuppone decisioni collettive sulla priorità. Sono tutti strumenti che presuppongono interdipendenza. Senza, perdono senso. Ora guarda la configurazione tipica di un "team" di sviluppo in molte organizzazioni. Le persone vengono assegnate, spesso ruotate, a un "team" che è in realtà un contenitore organizzativo. Ognuno lavora sulla propria user story, con interazioni limitate al code review e a qualche domanda su Slack. Il "goal dello sprint" è la somma delle story individuali. L'interdipendenza è minima o assente. Se applichi strumenti da team a questa struttura, il risultato è prevedibile. Lo standup diventa un giro di aggiornamenti che nessuno ascolta. La retro produce lamenti generici. Il planning diventa burocrazia. Non perché Scrum sia burocrazia, ma perché lo stai usando su una struttura per cui non è progettato. I firmatari del Manifesto lo dicono, anche se con parole diverse. Jeffries parla di "Dark Scrum", organizzazioni che usano i rituali Agile come strumenti di controllo, svuotandoli di collaborazione. Thomas dice che "Agile" è stato trasformato in un sostantivo commerciale, quando era pensato come un aggettivo che descrive un modo di lavorare. La loro critica è legittima. Ma la diagnosi che propongono, "le organizzazioni hanno corrotto Agile", è incompleta. Il framework di Hackman ne offre una più strutturale: molte organizzazioni non hanno corrotto Agile. Lo hanno applicato a strutture che non sono team. Ne parlo perché l'ho visto accadere più volte di quante vorrei ammettere, anche in contesti con persone competenti e buone intenzioni. La risposta standard al malessere era sempre la stessa: cambiamo facilitatore, proviamo un altro formato di retro, aggiungiamo una cerimonia. Il framework di Hackman mi ha dato un vocabolario per dire quello che sentivo ma non riuscivo a formulare: il problema non era l'esecuzione. Era la premessa. Questo cambia la diagnosi e le soluzioni. Se il problema è "Agile è diventato burocrazia", la risposta è meno processo, meno rituali, più autonomia. A volte è giusto. Ma se il problema è un mismatch strutturale, la risposta è diversa: o trasformi la struttura in un team reale, con i costi che questo comporta, o accetti che hai un gruppo di lavoro e adotti strumenti coerenti con quella realtà. Entrambe le opzioni sono legittime. Quello che non funziona è restare nel mezzo. --- Riprendiamo lo standup di dodici minuti da cui siamo partiti. Cinque persone, cinque aggiornamenti, nessuna interazione. La diagnosi ovvia è che lo standup sia mal facilitato, o che Scrum non funzioni, o che il team abbia bisogno di "lavorare sulla comunicazione". Sono tutte risposte che agiscono sul sintomo. La domanda di Hackman è diversa, e viene prima: quelle cinque persone hanno bisogno di parlarsi ogni mattina per fare il loro lavoro? Se il lavoro di ciascuno non dipende dagli altri, lo standup non è mal facilitato. È inutile per design. E la retro non produce azioni perché non c'è un processo condiviso da migliorare. E il planning è burocrazia perché non ci sono decisioni collettive da prendere. Non è una questione di esecuzione. È una questione di struttura. La prossima volta che pensi "Agile non funziona", prova a riformulare. Non chiederti come migliorare il processo. Chiediti se quello che guidi è un team o un gruppo di lavoro. La risposta non è un giudizio. È una diagnosi. E dalla diagnosi dipende tutto il resto. --- ## Fonti - Hackman, J.R. (2002). *Leading Teams: Setting the Stage for Great Performances*. Harvard Business School Press. - Hackman, J.R. (2011). *Collaborative Intelligence: Using Teams to Solve Hard Problems*. Berrett-Koehler. - Wageman, R. (2001). [How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching](https://doi.org/10.1287/orsc.12.5.559.10094). *Organization Science*, 12(5), 559-577. - Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). [Team Diagnostic Survey: Development of an Instrument](https://doi.org/10.1177/0021886305281984). *Journal of Applied Behavioral Science*, 41(4), 373-398. - [Digital.ai](https://digital.ai/) (2024). [17th State of Agile Report](https://digital.ai/resource/state-of-agile-report/). - Jeffries, R. (2018). [Developers Should Abandon Agile](https://ronjeffries.com/articles/018-01ff/abandon-1/). - Thomas, D. (2014). [Agile is Dead (Long Live Agility)](https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html). --- ## Who Will the Senior Engineers of Tomorrow Be? - URL: https://ireneburresi.dev/blog/business/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 > 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/business/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/engineering/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 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/engineering/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).