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 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”.
\nI numeri parlano chiaro e arrivano dal Bureau of Labor Statistics (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”, figure focalizzate sulla scrittura e il test del codice, il cui impiego è previsto in contrazione del 6%. Dall’altro i “software developers”, 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.
\nL’AI sta trasformando la sintassi in una commodity, ma sta rendendo la semantica il vero asset strategico.
\nPer 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”. 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.
\n“Le narrative popolari tendono a ridurre il software engineering a un esercizio da studente universitario”, spiega Solar-Lezama. 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”.
\nGli 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.
\nIl 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.
\nL’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.
\nInoltre, 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.
\nEd è qui che scatta l’inganno. Spesso vediamo benchmark trionfali (come 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.
\nLa 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.
\nSe 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.
\nSiamo 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.
\nLa 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.
\nChi 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à.
\nPer 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é.
\nBLS: Computer Programmers Outlook 2024-2034 — Le proiezioni ufficiali del governo USA: -6% di occupazione, con automazione e AI tra le cause principali.
\nBLS: Software Developers Outlook 2024-2034 — L’altro lato della medaglia: +15% di crescita trainata da AI, IoT e sicurezza informatica.
\nMIT: Challenges and Paths Towards AI for Software Engineering (arXiv) — Il paper completo (75 pagine) con tassonomia dei task, bottleneck e direzioni di ricerca.
\nMIT News: Can AI really code? — L’articolo divulgativo con citazioni dirette di Solar-Lezama e Gu.
\nSWE-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.
\nJensen Huang: “Don’t learn to code” (TechRadar) — Il discorso del CEO Nvidia al World Government Summit (febbraio 2024) che ha scatenato il dibattito.
\nSovrastimiamo 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.
\nPer capire dove stiamo andando, dobbiamo rispolverare la saggezza di 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.”
\nCinquant’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.
\nIl 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.
\nQuesto 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. 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.
\nNon 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.
\nE allora, dove siamo con l’AI generativa? E cosa significa per chi deve prendere decisioni nei prossimi due, tre anni?
\nLa 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 è.
\nA 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.
\nQui 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.
\nIl 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.
\nIl pattern si ripete. Tre casi lo illustrano.
\nInternet 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.
\nE 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.
\nL’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.
\nIl 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.
\nNegli 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.
\nGeoffrey 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.
\nMezzo secolo dal primo hype al breakthrough. Cinquant’anni per completare il ciclo.
\nGuida 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.
\nSiamo 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.
\nIl pattern è sempre lo stesso: la risposta a “funzionerà?” era corretta. La domanda “quando?” era sbagliata — di anni, a volte di decenni.
\nE la GenAI? Stesso copione, atto in corso.
\nIl Gartner Hype Cycle for AI 2025 posiziona GenAI nel Trough of Disillusionment. Dopo un anno passato al picco delle aspettative, la discesa incombe — o ci siamo già dentro.
\nMa 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.
\nSull’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.
\nI numeri raccontano quanto sia stato sovrastimato questo secondo binario. S&P Global 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%.
\nE poi c’è il dato MIT NANDA. Il 95% dei pilot non genera impatto economico misurabile. Diciannove su venti.
\nQuest’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.
\nIl 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.
\nGartner 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.
\nQualche primissimo segnale di maturazione, comunque, c’è. Ma è anche in corso una presa di coscienza.
\nThomas Davenport e Randy Bean, su MIT Sloan Management Review, 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.”
\nInsomma, ci stiamo avviando verso il punto di minimo. La domanda è: e adesso?
\nLa 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.
\nChi 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.
\nIl 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.
\n“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.
\nLa 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.
\nPer chi deve decidere oggi, la domanda non è se investire. È come calibrare le aspettative — e quanto fiato tenere.
\nAmara ci aveva avvisati cinquant’anni fa. A noi spetta solo decidere se ascoltarlo.
\nMIT NANDA: The GenAI Divide (2025) — Il report che ha fatto tremare Wall Street: metodologia, dati completi e il “learning gap” che spiega i fallimenti.
\nGartner Hype Cycle for AI 2025 — Dove Gartner posiziona GenAI, AI agents e le altre tecnologie emergenti nel ciclo.
\nS&P Global: Voice of the Enterprise (2025) — Survey su 1.000+ aziende: tassi di abbandono, soddisfazione CEO e confronto 2024-2025.
\nDavenport & Bean: Five Trends in AI for 2026 — L’articolo che cita esplicitamente Amara per spiegare la fase attuale.
\nRoy Amara (Wikipedia) — Chi era il futurista che ha formulato la legge nel 1978.
\nIl 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”.
\nTL;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.
\nUn 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.
\nCome 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.
\nUn 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.
\nIl sistema non crasha. Non lancia eccezioni. Completa l’esecuzione. Solo che il risultato è sbagliato.
\nQuesto è 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.
\nPrima di scegliere metodologie, serve chiarire cosa significa “testare un agente”. Un paper del 2025 su arXiv propone una tassonomia bidimensionale che aiuta a orientarsi.
\nLa prima dimensione riguarda l’oggetto della valutazione:
\nBehavior: L’agente si comporta come previsto? Segue le istruzioni? Rispetta i vincoli?
\nCapabilities: L’agente è in grado di completare determinati task? Quali classi di problemi risolve?
\nReliability: L’agente produce risultati consistenti? Quanto varia la qualità tra esecuzioni?
\nSafety: L’agente evita azioni dannose? Resiste a tentativi di manipolazione? Protegge dati sensibili?
\nLa seconda dimensione riguarda il processo di valutazione:
\nOffline evaluation: Test pre-deployment su dataset statici o ambienti simulati.
\nOnline evaluation: Monitoraggio in produzione su traffico reale.
\nComponent-level: Testare singoli pezzi (il retriever, il planner, il singolo tool).
\nEnd-to-end: Testare il sistema completo su task realistici.
\nLa 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.
\nIl primo cambio di paradigma è passare da example-based testing a property-based testing.
\nNell’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.
\nNel 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.
\nPer un agente, le proprietà potrebbero essere:
\nQueste proprietà possono essere verificate automaticamente, indipendentemente dalla formulazione specifica dell’output.
\nIn 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.
\nFramework come Hypothesis (Python) supportano property-based testing. Per agenti, serve estenderli con proprietà specifiche del dominio e generatori di input che producono scenari realistici.
\nUn 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.
\nQui entra il pattern LLM-as-judge: usare un altro modello linguistico per valutare l’output dell’agente sotto test.
\nIl 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.
\nQuesto pattern è alla base di diversi framework di evaluation. DeepEval offre metriche predefinite come G-Eval (valutazione generale), faithfulness (aderenza ai fatti), answer relevancy, contextual precision. Opik di Comet fornisce evaluation per workflow agentici multi-step, inclusa qualità del piano, aderenza al piano, efficienza degli step.
\nLangSmith di LangChain e Langfuse 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 integra evaluation con la piattaforma MLOps esistente.
\nIl 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.
\nI limiti sono altrettanto concreti:
\nBias dell’evaluator: Il modello valutatore ha i suoi bias. Potrebbe preferire risposte verbose, o penalizzare formulazioni corrette ma non convenzionali. Studi mostrano che gli LLM tendono a preferire le proprie risposte rispetto a quelle di altri modelli.
\nCosto: Ogni valutazione richiede un’inference del modello evaluator. Su dataset grandi, i costi si accumulano.
\nNon sostituisce validazione umana: Per decisioni critiche (lancio in produzione, confronto tra approcci), serve comunque un campione validato da umani.
\nLa pratica migliore è usare LLM-as-judge per screening su larga scala e validazione umana su campioni stratificati. Ricerche mostrano che questa combinazione identifica il 60-70% in più di problemi rispetto al testing ad hoc.
\nLe metriche generiche di NLP (BLEU, ROUGE, perplexity) non catturano ciò che conta per gli agenti. Servono metriche progettate per valutare comportamenti agentici.
\nTask 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.
\nTool correctness: Ogni tool call è valida? I parametri sono nel formato corretto? Il tool chiamato è appropriato per lo step corrente?
\nTool hallucination: L’agente ha chiamato tool che non esistono? Ha inventato parametri non previsti dall’API?
\nPlan quality: Il piano generato dall’agente è ragionevole? Copre tutti gli step necessari? È efficiente?
\nPlan adherence: L’agente ha seguito il piano che ha generato? O ha deviato in modo ingiustificato?
\nStep efficiency: Quanti step ha richiesto per completare il task? Rispetto a un baseline o a esecuzioni precedenti?
\nRecovery rate: Quando un tool fallisce o restituisce un errore, l’agente riesce a recuperare? Riprova? Cerca alternative?
\nConsistency: Dato lo stesso input ripetuto N volte, quanto varia l’output? La varianza è accettabile o indica instabilità?
\nQueste metriche richiedono strumentazione. Il sistema deve loggare ogni step, ogni tool call, ogni decisione del planner. Senza trace dettagliato, non puoi calcolarle.
\nFramework come Opik e LangSmith forniscono tracing automatico. Se usi framework custom, devi costruire il logging.
\nIl red teaming è la pratica di attaccare deliberatamente il sistema per scoprire vulnerabilità prima che lo facciano attori malevoli. Per gli agenti AI, è particolarmente critico.
\nOWASP ha pubblicato a dicembre 2025 il Top 10 per applicazioni agentic. Le categorie principali includono:
\nPrompt 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).
\nTool misuse: L’agente viene indotto a usare tool in modi non previsti: leggere file sensibili, inviare dati a endpoint esterni, eseguire codice arbitrario.
\nMemory leakage: Informazioni da sessioni o utenti precedenti che trapelano nelle risposte.
\nPrivilege escalation: L’agente acquisisce permessi superiori a quelli previsti, spesso attraverso catene di tool call.
\nIl red teaming tradizionale è manuale: esperti di sicurezza tentano di violare il sistema usando creatività e conoscenza del dominio. È efficace ma non scala.
\nIl red teaming automatizzato usa LLM per generare attacchi. DeepTeam, sviluppato da Confident AI, genera automaticamente prompt di attacco per diverse categorie di vulnerabilità e valuta la robustezza del sistema. PyRIT di Microsoft è un framework open-source per red teaming di sistemi AI, con focus su generazione automatica di attacchi e reporting.
\nEnkrypt AI offre red teaming as a service con prompt dinamici che evolvono in base alle difese del sistema. Giskard combina red teaming con vulnerability scanning specifico per LLM.
\nLe best practice per enterprise raccomandano:
\nL’EU AI Act richiede red teaming documentato per sistemi ad alto rischio. Non è più opzionale per chi opera in Europa.
\nIl 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.
\nPer 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.
\nUn survey del 2024 cataloga le tecniche di fuzzing applicate a LLM. I principali approcci:
\nBlack-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.
\nGrey-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.
\nLLM-enhanced fuzzing: Usi un LLM per generare input più intelligenti. Invece di mutazioni casuali, chiedi al modello di generare varianti che potrebbero causare problemi.
\nChatFuzz 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.
\nFuzz4All 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.
\nPer agenti, il fuzzing si applica a diversi livelli:
\nIl fuzzing è computazionalmente costoso. Ogni run richiede inference del modello. Ma trova classi di bug che altri metodi non scoprono.
\nTestare agenti in produzione è rischioso: ogni bug è visibile agli utenti. Testare su dataset statici è insufficiente: non cattura le interazioni dinamiche con tool e ambienti.
\nLa soluzione intermedia sono gli ambienti di simulazione che replicano condizioni realistiche senza conseguenze reali.
\nAgentBench fornisce 8 ambienti distinti (web browsing, coding, database query) per valutare agenti su task realistici. WebArena simula siti web reali dove gli agenti possono navigare e completare task. SWE-bench valuta agenti su issue GitHub reali, misurando la capacità di risolvere bug in codebase esistenti.
\nQuesti 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.
\nIl trend è verso benchmark dinamici e continuamente aggiornati. AppWorld e 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.
\nPer testing interno, la pratica migliore è costruire ambienti che replicano il deployment target:
\nUn ambiente di test ben costruito è un asset che si accumula nel tempo. Ogni bug trovato in produzione diventa un nuovo test case.
\nL’evaluation non è un evento singolo. È un processo continuo che attraversa tutto il lifecycle.
\nPre-deploy (offline):
\nUnit test sui componenti: Il retriever restituisce documenti rilevanti? Il planner genera piani validi? I tool wrapper gestiscono errori?
\nIntegration test end-to-end: L’agente completo risolve task rappresentativi? Su un dataset di almeno 500-1000 casi diversi?
\nProperty-based testing: Le proprietà invarianti sono rispettate su input generati casualmente?
\nRed teaming: Il sistema resiste agli attacchi noti? Le nuove vulnerabilità sono state testate?
\nRegression testing: Le performance sono uguali o migliori della versione precedente? Nessun degradamento su casi critici?
\nLa soglia per il deploy dovrebbe essere esplicita: task completion rate > X%, zero vulnerabilità critiche, regression test 100% passed.
\nPost-deploy (online):
\nSampling: Valuta un campione (1-5%) degli output di produzione. Prioritizza casi flaggati da guardrail o con feedback negativo.
\nMonitoring metriche: Traccia task completion, latenza, error rate, costo per query in tempo reale. Alert su deviazioni.
\nDrift detection: Le performance stanno degradando? La distribuzione degli input sta cambiando?
\nHuman review: Revisione periodica di campioni stratificati da annotatori qualificati.
\nIncident analysis: Ogni failure diventa un caso di test. Root cause analysis alimenta il dataset di regression.
\nL’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.
\nI numeri parlano chiaro. Il 73% delle organizzazioni cita l’affidabilità come barriera al deploy di agenti. Non la tecnologia, non i costi di inference: l’affidabilità.
\nLa 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.
\nChi 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.
\nIl 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.
\nI framework esistono. Le metodologie sono documentate. Il gap è nell’adozione.
\nConfident AI. (2025). LLM Testing in 2025: Top Methods and Strategies.
\nDatabricks. (2025). Announcing Agent Evaluation.
\nGalileo AI. (2025). Top 12 AI Evaluation Tools for GenAI Systems in 2025.
\nGitHub. (2025). DeepTeam: Framework to red team LLMs.
\nHu, J., Zhang, Q., & Yin, H. (2023). ChatFuzz: Large Language Model Enhanced Fuzzing. arXiv:2305.06498.
\nOWASP. (2025). Top 10 for Large Language Model Applications v2025.
\nSkywork AI. (2025). Agentic AI Safety & Guardrails: 2025 Best Practices for Enterprise.
\nWang, L., et al. (2024). Large Language Models Based Fuzzing Techniques: A Survey. arXiv:2402.00350.
\nZhang, Y., et al. (2025). A Survey on the Evaluation of LLM-based Agents. arXiv:2503.16416.
\n", "date_published": "2026-01-06T00:00:00.000Z", "date_modified": "2026-01-06T00:00:00.000Z", "tags": [ "Testing", "AI Agents", "QA", "Red Teaming", "Evaluation", "MLOps", "Production" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [] } }, { "id": "https://ireneburresi.dev/blog/governance/ai-act-geop/", "url": "https://ireneburresi.dev/blog/governance/ai-act-geop/", "title": "L'AI Act non è (solo) compliance: è politica industriale", "summary": "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.", "content_html": "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.
\nTL;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.
\nI numeri sulla posizione tecnologica europea sono noti agli addetti ai lavori. Raramente entrano nel dibattito sull’AI Act.
\nUn report Proton di ottobre 2025 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 sulle imprese tedesche con più di 20 dipendenti rivela che l’89% si considera tecnologicamente dipendente dall’estero.
\nIl report EPRS del Parlamento Europeo 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.
\nQuesto 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.
\nIl termine “Brussels Effect” è stato coniato da Anu Bradford 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.
\nIl 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.
\nIl 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.
\nSull’AI Act, la letteratura accademica è più sfumata.
\nUn paper GovAI del 2022 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.
\nIl 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.
\nUn articolo su Policy Review 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.
\nLa 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.
\nA novembre 2025, la Commissione Europea ha proposto il Digital Omnibus. Il pacchetto include modifiche all’AI Act che hanno generato titoli su “l’Europa che fa marcia indietro”.
\nI 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.
\nMa 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.
\nIl 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.
\nLa 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.
\nIl 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.
\nL’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.
\nUsare questa leva per influenzare gli standard globali è politica industriale. Chiamarla solo “protezione dei consumatori” è una descrizione incompleta. Trattarla solo come “compliance” è perdere il quadro.
\nMicrosoft 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.
\nForse dovremmo chiederci perché noi sì.
\nBradford, A. (2020). The Brussels Effect: How the European Union Rules the World. Oxford University Press.
\nSiegmann, C. & Anderljung, M. (2022). The Brussels Effect and Artificial Intelligence: How EU regulation will impact the global AI market. GovAI, arXiv:2208.12645.
\nPolicy Review. (2025). Brussels effect or experimentalism? The EU AI Act and global standard-setting.
\nEuropean Commission. (2025). Digital Omnibus on AI Regulation Proposal.
\nEuropean Parliamentary Research Service. (2025). European Software and Cyber Dependencies.
\nTechReport. (2025). Europe’s Digital Dependence: The Risks of the EU’s Reliance on US Tech.
\n", "date_published": "2026-01-06T00:00:00.000Z", "date_modified": "2026-01-06T00:00:00.000Z", "tags": [ "AI Act", "Brussels Effect", "Geopolitica", "Politica industriale", "Compliance strategica" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/governance/ai-act-geop/", "title": "The AI Act Is Not (Just) Compliance: It's Industrial Policy" } ] } }, { "id": "https://ireneburresi.dev/blog/research/constitutional-ai/", "url": "https://ireneburresi.dev/blog/research/constitutional-ai/", "title": "Constitutional AI: guida per chi usa Claude", "summary": "Claude alterna rifiuti assurdi e risposte rischiose. Constitutional AI mostra come gestire overrefusal, sycophancy e vulnerabilità linguistiche nei deployment.", "content_html": "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.
\nTL;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.
\nChiunque 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”.
\nPoi leggi i report di sicurezza. Adaptive attacks raggiungono il 100% di success rate 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.
\nCome può lo stesso modello essere contemporaneamente troppo restrittivo e troppo permissivo?
\nLa 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.
\nIl paper originale di Anthropic, pubblicato a dicembre 2022, propone un metodo per rendere i modelli “harmless” senza etichettare manualmente centinaia di migliaia di risposte come “buone” o “cattive”.
\nIl 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.
\nNella 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).
\nLa costituzione di Claude 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.
\nIl 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.
\nPrima di analizzare i problemi, i dati su cosa Constitutional AI fa bene.
\nGoogle DeepMind ha pubblicato nel 2023 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.
\nIl 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.
\nIl 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.
\nUn 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.
\nIl primo failure mode che impatta chi usa Claude in produzione è l’overrefusal. Il modello rifiuta richieste legittime perché pattern superficiali attivano i safety guardrail.
\nIl 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.
\nGli 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”.
\nNel 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.
\nLa 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.
\nIl 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”.
\nIl team di Constitutional Classifiers di Anthropic 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.
\nPer 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.
\nIl secondo failure mode è l’opposto: il modello accetta richieste che dovrebbe rifiutare, quando l’attacco è formulato in modo da bypassare i pattern superficiali.
\nUno studio del 2024 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.
\nSenza 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.
\nCome è possibile che lo stesso modello rifiuti email di sollecito e accetti richieste di sintesi di armi chimiche?
\nLa 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.
\nI 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.
\nPer 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.
\nIl terzo failure mode è più sottile e meno discusso: Claude tende a darti ragione anche quando sbagli.
\nAnthropic stessa ha pubblicato ricerca 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.
\nLa 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.
\nIl 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.
\nPer 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.
\nI failure modes descritti finora si amplificano quando il modello opera in lingue diverse dall’inglese. Questo impatta direttamente chi opera in Italia.
\nI dati sono chiari. Ricerca su LLM multilingual safety 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.
\nIl 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.
\nLa 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.
\nPer 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.
\nLe 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.
\nCosa significa tutto questo per chi deve decidere se e come usare Claude in produzione?
\nConstitutional 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”.
\nServono 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.
\nNon 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.
\nConstitutional 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.
\nMa “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.
\nNessuno 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à.
\nPer 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.
\nLa trasparenza sui principi è un vantaggio competitivo di Anthropic rispetto ad altri provider. La costituzione di Claude è pubblica. 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.
\nConstitutional 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.
\nBai, Y., Kadavath, S., Kundu, S., et al. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073.
\nLee, H., Phatale, S., Mansoor, H., et al. (2023). RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback. arXiv:2309.00267.
\nAndriushchenko, M., et al. (2024). Jailbreaking Leading Safety-Aligned LLMs with Simple Adaptive Attacks. arXiv:2404.02151.
\nPerez, E., Ringer, S., Lukošiūtė, K., et al. (2023). Towards Understanding Sycophancy in Language Models. arXiv:2310.13548.
\nDeng, Y., et al. (2023). Multilingual Jailbreak Challenges in Large Language Models. arXiv:2310.02446.
\nAnthropic. (2023). Claude’s Constitution. Anthropic.
\nAnthropic. (2024). Constitutional Classifiers: Defending Against Universal Jailbreaks. Anthropic.
\n", "date_published": "2025-12-29T00:00:00.000Z", "date_modified": "2025-12-29T00:00:00.000Z", "tags": [ "Constitutional AI", "Claude", "Anthropic", "AI Safety", "LLM Deployment", "Enterprise AI" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/research/constitutional-ai/", "title": "Constitutional AI: A Guide for Claude Users" } ] } }, { "id": "https://ireneburresi.dev/blog/business/ai-2026-anno-resa-conti/", "url": "https://ireneburresi.dev/blog/business/ai-2026-anno-resa-conti/", "title": "AI 2026: perché Stanford parla di resa dei conti", "summary": "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.", "content_html": "Il 42% delle aziende ha già abbandonato la maggior parte dei progetti AI. I dati dicono che il peggio potrebbe non essere finito.
\nTL;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.
\nA metà dicembre 2025, nove faculty dello Stanford Human-Centered Artificial Intelligence 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.
\nJames 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.
\nNon è una previsione sul futuro. È la fotografia di qualcosa che sta già succedendo.
\nA luglio 2025, il MIT Project NANDA 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.
\nNello stesso periodo, S&P Global 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.
\nSecondo RAND Corporation, 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.
\nLe 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.
\nSono 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?”.
\nSe i tassi di fallimento sono il sintomo, il lavoro di Erik Brynjolfsson offre una diagnosi più precisa. “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.
\nIl 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.
\nQuello 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.
\nIl 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.”
\nNon è 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.
\nQuando 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.
\nC’è un paradosso nei dati del 2025 che merita attenzione. L’adozione dell’AI sta accelerando: secondo McKinsey, 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%.
\nEppure, 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.
\nMolte 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.
\nAngè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.
\nUna 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.
\nOggi 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.
\nSe 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.
\nÈ una visione ottimistica: dati migliori portano decisioni migliori. Ma è anche un’ammissione implicita: oggi stiamo navigando al buio.
\nDue settori emergono dalle previsioni Stanford come banco di prova particolarmente rilevante.
\nNigam 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.”
\nSecondo 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.
\nShah 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.
\nNel 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.
\nMedicina 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.
\nStanford HAI pubblica previsioni annuali da alcuni anni. Ha senso chiedersi quanto siano state accurate finora.
\nA 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.
\nPercy 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.
\nPer 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.
\nNon 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.
\nQuesto non garantisce che le previsioni 2026 si avvereranno. Ma significa che vale la pena prenderle sul serio.
\nSe 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.
\nPer chi gestisce budget tecnologici, le implicazioni sono concrete.
\nSul 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.
\nSul 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.
\nSul 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.
\nInfine, 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.
\nLe previsioni Stanford hanno punti ciechi evidenti.
\nNessuno 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.
\nManca 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.
\nLanday 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.
\nPiù 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.
\nQuando 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.
\nQuesto 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.
\nIl 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.
\nBrynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.
\nMcKinsey & Company. (2024). The State of AI in 2024: Gen AI adoption spikes and starts to generate value. McKinsey Global Institute.
\nMIT Project NANDA. (2025). The GenAI Divide 2025. Massachusetts Institute of Technology.
\nRAND Corporation. (2024). The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. RAND Research Reports.
\nS&P Global Market Intelligence. (2025, October). Generative AI Shows Rapid Growth but Yields Mixed Results. S&P Global.
\nStanford HAI. (2025, December). Stanford AI Experts Predict What Will Happen in 2026. Stanford Human-Centered Artificial Intelligence.
\n", "date_published": "2025-12-20T00:00:00.000Z", "date_modified": "2025-12-29T00:00:00.000Z", "tags": [ "Stanford HAI", "AI 2026", "Enterprise AI", "Market Analysis", "AI Predictions" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/business/ai-2026-anno-resa-conti/", "title": "AI 2026: Why Stanford Talks About a Reckoning" } ] } }, { "id": "https://ireneburresi.dev/blog/business/misurare-ia/", "url": "https://ireneburresi.dev/blog/business/misurare-ia/", "title": "Metriche AI che contano davvero", "summary": "Il 60% dei manager ha KPI sbagliati perché misura ore risparmiate, non impatto: segmenta per ruolo, separa uso augmentativo da sostitutivo e monitora weekly.", "content_html": "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.
\nTL;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à.
\nI 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, più del doppio rispetto all’anno precedente. Il 95% dei progetti pilota, secondo MIT NANDA, non genera alcun impatto misurabile sul conto economico.
\nSe misuriamo così tanto, perché falliamo così spesso?
\nIl 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.
\nUn 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.
\nLa 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.
\nUn 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.
\nIl 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.
\nSecondo 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.
\n“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.
\nGli 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.
\nHanno 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).
\nIl 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.
\nQuesto 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.
\nIl 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.
\nIl 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.
\nPer 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.
\nLa 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.
\nUna 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).
\nNelle 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.
\nNon 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.
\nUno 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.
\nIl 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.
\nQuesto 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.
\nLa 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.
\nNelle 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.
\nÈ 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.
\nLa 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.
\nIn 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.
\nUn 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à.
\nCome 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.
\nServono 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.
\nC’è 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.
\nIl 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.
\nIl 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.
\nNessuna 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.
\nBrynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.
\nDeloitte AI Institute. (2025). State of Generative AI in the Enterprise. Deloitte.
\nMIT Project NANDA. (2025). The GenAI Divide 2025. Massachusetts Institute of Technology.
\nMIT Sloan Management Review. (2024). The Future of Strategic Measurement: Enhancing KPIs With AI. MIT Sloan.
\nS&P Global Market Intelligence. (2025, October). Generative AI Shows Rapid Growth but Yields Mixed Results. S&P Global.
\n", "date_published": "2025-12-20T00:00:00.000Z", "date_modified": "2025-12-29T00:00:00.000Z", "tags": [ "KPI", "Metrics", "AI Measurement", "Enterprise AI", "ROI" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/business/misurare-ia/", "title": "You're Measuring AI Wrong" } ] } }, { "id": "https://ireneburresi.dev/blog/governance/ia-sovranit%C3%A0/", "url": "https://ireneburresi.dev/blog/governance/ia-sovranit%C3%A0/", "title": "Sovranità AI: quale modello per l'Europa", "summary": "Cloud sovrani, modelli nazionali e provider USA definiscono tre idee di sovranità AI. L'Europa deve scegliere quale infrastruttura e governance finanziare.", "content_html": "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.
\nNel 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.
\nMentre 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?
\nIl 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.
\nL’Atlantic Council propone quattro componenti distinte.
\nLa 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.
\nLa 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.
\nLa 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.
\nLa 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?
\nQueste 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.
\nAl di là delle definizioni, esistono due approcci pratici alla sovranità AI, ciascuno con trade-off specifici.
\nIl 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.
\nIl 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.
\nI 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.
\nUn 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.
\nIl 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.
\nIl 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.
\nIl 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.
\nI paesi del Golfo Persico stanno perseguendo una variante del secondo modello, ma con una scala e un’ambizione che merita attenzione separata.
\nGli 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.
\nL’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.
\nIl Qatar ha lanciato Qai con 20 miliardi di dollari in partnership con Brookfield, più un investimento separato in Anthropic.
\nNon 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”.
\nIl 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.
\nL’Europa sta perseguendo simultaneamente approcci diversi senza una strategia unificata. Il risultato è frammentazione.
\nMistral 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.
\nMa Mistral ha investitori americani (a16z, Lightspeed) e partnership con Microsoft. Quanto è “sovrana” un’azienda che dipende da venture capital americano per crescere?
\nAleph 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).
\nIl 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à.
\nA 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.
\nQueste 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.
\nGAIA-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.
\nSul 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.
\nSul 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.
\nUn’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.”
\nL’EU AI Act, entrato progressivamente in vigore dal febbraio 2025, crea obblighi che si intersecano con la sovranità AI in modi specifici.
\nSul 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.
\nPer 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.
\nC’è 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.
\nIl 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.”
\nJames 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.”
\nI 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.
\nMa 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).
\nSe 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.
\nPer CTO, legal e compliance officer in Europa, la frammentazione della strategia di sovranità crea incertezza operativa. Alcune considerazioni pratiche.
\nIl 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à.
\nServe 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.
\nC’è 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.
\nL’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.
\nVale 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.
\nL’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.
\nA 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.
\nPer 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.
\nIl 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.
\nTre mesi dopo, Marco se n’è andato. È arrivato Luca. Il team non funziona ancora.
\nLa 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.
\nLa 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.
\nJ. 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). Quando un team non funziona, il problema più probabile non è chi ci lavora dentro. È come è stato progettato.
\nPrima di cambiare le persone, conviene verificare le condizioni.
\nHackman 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.
\nLe 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.
\n1. 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.
\n2. 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?
\n3. Una struttura abilitante. Ruoli, norme, competenze. Il minimo di infrastruttura perché le persone non debbano rinegoziare tutto da zero ogni settimana.
\n4. 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.
\n5. 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.
\nL’istinto di chi gestisce team è partire dal fondo: coaching, facilitazione, dinamiche interpersonali. Hackman dice: parti dall’alto.
\nEcco 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.
\nAlcune di queste mappature sono ancorabili direttamente alla ricerca di Hackman. Altre sono la mia traduzione nel contesto software, e le segnalo.
\nÈ un problema di Marco, si dice. Manca di drive, di ownership, forse non è la persona giusta per il ruolo.
\nPiù 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.
\nNon guardare a Marco. Guarda al mandato del team. Se non riesci a spiegare in una frase perché quel lavoro conta, il problema è lì.
\nDove 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?
\nLa 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.
\nLa reazione classica: team building, esercizi di vulnerabilità, un offsite per conoscersi meglio.
\nLa 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.
\nQuante volte è cambiata la composizione nell’ultimo anno? Se la risposta è “spesso”, il deficit di fiducia non è un problema relazionale. È turnover strutturale.
\nQui 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).
\nLa diagnosi abituale: mancano le soft skill. Mandiamolo a un corso di leadership.
\nIl 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.
\nLa 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.
\nQui 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.
\nMa 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.
\nLa 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.
\nSe le condizioni strutturali contano così tanto, perché il default è sempre “colpa di qualcuno”?
\nLa 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): 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.
\nLa 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.
\nLa 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.
\nLa 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.
\nProva 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à.
\nNon è una differenza da poco. È la differenza tra debuggare il codice e debuggare il compilatore.
\nLo 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.
\nSe ti riconosci, non sei solo. Il 17th State of Agile Report di 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, o almeno la versione che le organizzazioni ne hanno fatto. Dave Thomas, un altro firmatario, ha dichiarato che Agile è morto, svuotato di significato dal marketing e dalla certificazione di massa.
\nLa 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?
\nMa 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.
\nJ. 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.
\nLe 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.
\nNel 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.
\nHackman non sarebbe d’accordo. In Leading Teams definisce un “real team” attraverso tre proprietà minime, tutte necessarie.
\nLa 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.
\nLa 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.
\nLa 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.
\nIl 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.
\nNon è un insulto. È una diagnosi. E la diagnosi è il primo passo per smettere di applicare gli strumenti sbagliati.
\nHackman non si è fermato alla definizione. Ha studiato cosa rende un team efficace, e la risposta è meno intuitiva di quanto sembri.
\nLa 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?
\nLa 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.
\nUna 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.
\nMa 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). Non il 20%, non il 50%. L’80%.
\nUno studio precedente di Wageman (2001) su 43 team autogestiti a Xerox aveva già mostrato lo stesso pattern: le attività di design del leader influenzavano la performance del team. Le attività di coaching quotidiano, no.
\nL’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à.
\nMa la prima di quelle cinque condizioni, “essere un team reale”, apre una domanda che nel software quasi nessuno si pone.
\nVa 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.
\nUn 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.
\nUn 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.
\nIl danno nasce quando confondi le due cose.
\nUn 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.
\nIl 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.
\nHo 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).
\nLa 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.
\nTorniamo 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à.
\nSono tutti strumenti che presuppongono interdipendenza. Senza, perdono senso.
\nOra 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.
\nSe 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.
\nI 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.
\nNe 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.
\nQuesto 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.
\nRiprendiamo 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.
\nLa 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.
\nNon è una questione di esecuzione. È una questione di struttura.
\nLa 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.
\nLe aziende non assumono junior perché l’AI svolge i loro task meglio. E tra dieci anni, chi guiderà i team?
\nNei 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?
\nI 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, 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%.
\nPotremmo 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.
\nLa contrazione è documentata da fonti multiple e indipendenti, non è una sensazione.
\nLe assunzioni entry-level nelle 15 maggiori aziende tech sono calate del 25% tra il 2023 e il 2024, secondo SignalFire. 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.
\nI tirocini tech crollati del 30% dal 2023, secondo Handshake. Le candidature aumentate del 7%. Più gente che si sbatte per meno posti, e quei posti che restano chiedono sempre più esperienza.
\nUno studio Harvard 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.
\nIn Europa stesso schema. Posizioni junior nel tech giù del 35% 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.
\nIl 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.
\nDevo ammetterlo, la logica dietro queste scelte è comprensibile.
\nUn 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.
\nJames O’Brien, professore di computer science a Berkeley che lavora con startup, descrive il cambio: “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?”
\nDomanda ragionevole, nel breve.
\nIl 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.
\nHeather 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.”
\nC’è un difetto in questa logica, e si chiama pipeline di talenti.
\nMatt Garman, CEO di AWS, lo ha detto chiaro: “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.”
\nNon è retorica, è matematica demografica applicata alle organizzazioni.
\nOgni 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.
\nFaccio 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.
\nQuesto 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.
\nC’è 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?
\nLa realtà è più complicata. E qui i dati sono interessanti, secondo me.
\nUn 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.
\nMa 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.
\nGli 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.
\nUno studio del MIT Media Lab 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.”
\nNon 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.
\nSe le posizioni junior si riducono, chi viene assunto?
\nI segnali dal mercato sono chiari. Saper programmare non basta più. I datori di lavoro si aspettano 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.
\nJamie 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.”
\nDavid 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.
\nMa 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.
\nIl 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.
\nL’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.
\nLa 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.
\nNessuno di questi scenari è scritto nella pietra. Dipende da scelte che aziende, istituzioni educative e policy maker faranno nei prossimi anni.
\nStai 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.
\nIl 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.
\nCome 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.
\nStai 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.
\nIl 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.
\nL’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.
\nIl 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.
\nLe 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.
\nTorno alla domanda iniziale: chi saranno i senior di domani?
\nNon 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.
\nQuello 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.
\nSe 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.
\nLa 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.
\nPer ora i numeri suggeriscono che abbiamo scelto la prima opzione.
\nIl conto arriverà. Non nel prossimo trimestre, ma arriverà.
\nBrynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine: Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab.
\nBastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2024). Generative AI Can Harm Learning. The Wharton School Research Paper.
\nStack Overflow. (2025, December). AI vs Gen Z: How AI has changed the career pathway for junior developers. Stack Overflow Blog.
\nIEEE Spectrum. (2025, December). AI Shifts Expectations for Entry Level Jobs.
\nRest of World. (2025, December). AI is wiping out entry-level tech jobs, leaving graduates stranded.
\nKosmyna, N., et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. arXiv.
\nWorld Economic Forum. (2025). Future of Jobs Report 2025.
\nFinalRound AI. (2025). AWS CEO Shares 3 Solid Reasons Why Companies Shouldn’t Replace Juniors with AI Agents.
\n", "date_published": "2025-01-06T00:00:00.000Z", "date_modified": "2025-01-06T00:00:00.000Z", "tags": [ "Junior Developers", "AI Impact", "Talent Pipeline", "Future of Work", "Learning", "Career" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/business/senior-domani/", "title": "Who Will the Senior Engineers of Tomorrow Be?" } ] } }, { "id": "https://ireneburresi.dev/blog/engineering/seo-vs-geo/", "url": "https://ireneburresi.dev/blog/engineering/seo-vs-geo/", "title": "Da SEO a GEO: Guida Tecnica all'Ottimizzazione per AI Search", "summary": "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.", "content_html": "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.
\nTL;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.
\nIl 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.
\nI 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.
\nSecondo i dati Cloudflare di dicembre 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.
\nNon è un cambiamento marginale. È un nuovo canale di acquisizione che richiede infrastruttura dedicata.
\nIl 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.
\nOpenAI opera con tre crawler distinti:
\nUser-agent: GPTBot\n# Training modelli fondazionali. Raccoglie dati per addestrare GPT.\n\nUser-agent: ChatGPT-User\n# Browsing utente. Accede a pagine quando un utente chiede informazioni.\n\nUser-agent: OAI-SearchBot\n# Search. Indicizza contenuti per la funzione di ricerca di ChatGPT.\nAnthropic usa:
\nUser-agent: ClaudeBot\n# Training e aggiornamento Claude.\n\nUser-agent: Claude-Web\n# Accesso web per funzionalità utente.\n\nUser-agent: anthropic-ai\n# Crawler generico Anthropic.\nPerplexity:
\nUser-agent: PerplexityBot\n# Indicizzazione per AI answer engine.\n\nUser-agent: Perplexity-User\n# Fetch per query utente.\nGoogle ha separato le funzioni:
\nUser-agent: Google-Extended\n# Token per uso AI. NON è un bot, è un flag.\n# Controllare questo user-agent impedisce uso dei contenuti per training AI\n# mantenendo l'indicizzazione standard.\n\nUser-agent: Googlebot\n# Crawler tradizionale per Search.\nMeta:
\nUser-agent: Meta-ExternalAgent\n# Crawling per training modelli AI.\n\nUser-agent: Meta-ExternalFetcher\n# Fetch per richieste utente. Può bypassare robots.txt.\nAltri crawler rilevanti:
\nUser-agent: Amazonbot\nUser-agent: Bytespider # ByteDance\nUser-agent: Applebot-Extended # Apple AI (flag, non bot)\nUser-agent: CCBot # Common Crawl\nUser-agent: cohere-ai\nUser-agent: cohere-training-data-crawler\nStrategia 1: Accesso completo per massima visibilità AI
\n# Permettere tutti gli AI crawler\nUser-agent: GPTBot\nAllow: /\n\nUser-agent: ChatGPT-User\nAllow: /\n\nUser-agent: OAI-SearchBot\nAllow: /\n\nUser-agent: ClaudeBot\nAllow: /\n\nUser-agent: anthropic-ai\nAllow: /\n\nUser-agent: PerplexityBot\nAllow: /\n\nUser-agent: Google-Extended\nAllow: /\n\nUser-agent: Meta-ExternalAgent\nAllow: /\n\nUser-agent: Amazonbot\nAllow: /\nStrategia 2: Visibilità AI search, no training
\nQuesta configurazione permette ai sistemi AI di citare i contenuti nelle risposte, ma impedisce l’uso per addestrare modelli:
\n# Permettere crawler search/user\nUser-agent: ChatGPT-User\nAllow: /\n\nUser-agent: OAI-SearchBot\nAllow: /\n\nUser-agent: PerplexityBot\nAllow: /\n\nUser-agent: Perplexity-User\nAllow: /\n\n# Bloccare crawler training\nUser-agent: GPTBot\nDisallow: /\n\nUser-agent: ClaudeBot\nDisallow: /\n\nUser-agent: Google-Extended\nDisallow: /\n\nUser-agent: Meta-ExternalAgent\nDisallow: /\n\nUser-agent: CCBot\nDisallow: /\n\nUser-agent: cohere-training-data-crawler\nDisallow: /\nStrategia 3: Accesso selettivo per directory
\nUser-agent: GPTBot\nAllow: /blog/\nAllow: /docs/\nDisallow: /api/\nDisallow: /internal/\nDisallow: /user-data/\nUn punto critico: robots.txt è un protocollo volontario. I crawler possono ignorarlo.
\nAd agosto 2025, Cloudflare ha bloccato i bot di Perplexity 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.
\nLa 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.
\nA settembre 2024, Jeremy Howard di Answer AI ha proposto llms.txt, 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.
\nIl 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.
\n# example.com\n\n> Sito tecnico su implementazioni AI per enterprise.\n> Contenuti verificati, aggiornati mensilmente.\n\n## Documentazione Core\n\n- [Guida RAG Produzione](https://example.com/docs/rag-production):\n Architetture RAG testate in produzione, pattern di chunking,\n metriche di valutazione. Aggiornato Q4 2024.\n\n- [API Reference](https://example.com/docs/api):\n Documentazione completa delle API REST. Include esempi\n di codice Python e cURL.\n\n## Articoli Tecnici\n\n- [Ottimizzazione Latenza LLM](https://example.com/blog/llm-latency):\n Strategie per ridurre latenza p95 sotto 200ms.\n Include benchmark su Claude, GPT-4, Mistral.\n\n- [Cost Management AI](https://example.com/blog/ai-costs):\n Framework per stimare e ottimizzare costi inference.\n Dati reali da deployment enterprise.\n\n## Risorse\n\n- [Glossario AI](https://example.com/glossario):\n Definizioni tecniche di 150+ termini AI/ML.\nOltre 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.
\nA gennaio 2025, OpenAI, Google e Anthropic non supportano nativamente llms.txt. I loro crawler non leggono automaticamente il file.
\nL’adozione attuale è concentrata in nicchie specifiche:
\nÈ un investimento di future-proofing. Quando i major provider adotteranno lo standard, chi ha già implementato avrà vantaggio.
\n/llms.txt alla root del dominio# LLM-policy: /llms.txt| File | \nScopo | \nTarget | \nFormato | \n
|---|---|---|---|
| robots.txt | \nControllo accesso crawler | \nSearch engines, AI crawler | \nPlain text, direttive | \n
| sitemap.xml | \nCatalogo completo pagine | \nSearch engines | \nXML | \n
| llms.txt | \nMappa curata contenuti prioritari | \nLLM | \nMarkdown | \n
| humans.txt | \nCrediti team | \nUmani | \nPlain text | \n
Lo structured data non è una novità. È standard SEO dal 2011. Ma il suo ruolo cambia nel contesto dei motori generativi.
\nI 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.
\nUn 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.
\nJSON-LD (JavaScript Object Notation for Linked Data) è il formato preferito. Si inserisce in un tag <script> senza mescolarsi con l’HTML del contenuto:
<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"TechArticle\",\n \"@id\": \"https://example.com/rag-production-guide\",\n \"headline\": \"RAG in Produzione: Pattern e Anti-Pattern\",\n \"description\": \"Guida tecnica all'implementazione RAG enterprise con metriche reali\",\n \"author\": {\n \"@type\": \"Person\",\n \"name\": \"Nome Autore\",\n \"url\": \"https://example.com/team/nome-autore\",\n \"jobTitle\": \"AI Team Leader\",\n \"knowsAbout\": [\"RAG\", \"LLM\", \"Vector Databases\", \"AI Engineering\"]\n },\n \"datePublished\": \"2025-01-04\",\n \"dateModified\": \"2025-01-04\",\n \"publisher\": {\n \"@type\": \"Organization\",\n \"name\": \"Example.com\",\n \"url\": \"https://example.com\",\n \"logo\": {\n \"@type\": \"ImageObject\",\n \"url\": \"https://example.com/logo.png\"\n }\n },\n \"mainEntityOfPage\": {\n \"@type\": \"WebPage\",\n \"@id\": \"https://example.com/rag-production-guide\"\n },\n \"articleSection\": \"Engineering\",\n \"keywords\": [\"RAG\", \"Production\", \"Enterprise AI\", \"Vector Search\"],\n \"wordCount\": 3500,\n \"inLanguage\": \"it\"\n}\n</script>\nArticle / TechArticle / NewsArticle
\nPer contenuti editoriali. TechArticle per documentazione tecnica.
\nFAQPage
\nStruttura Q&A che i motori generativi possono estrarre direttamente:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"FAQPage\",\n \"mainEntity\": [\n {\n \"@type\": \"Question\",\n \"name\": \"Qual è la differenza tra SEO e GEO?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"SEO ottimizza per liste di risultati dei motori di ricerca tradizionali. GEO ottimizza per essere citati nelle risposte sintetizzate dai motori generativi come ChatGPT e Perplexity.\"\n }\n },\n {\n \"@type\": \"Question\",\n \"name\": \"llms.txt sostituisce robots.txt?\",\n \"acceptedAnswer\": {\n \"@type\": \"Answer\",\n \"text\": \"No. robots.txt controlla l'accesso dei crawler. llms.txt guida i LLM verso contenuti prioritari. Hanno funzioni complementari.\"\n }\n }\n ]\n}\n</script>\nHowTo
\nPer guide step-by-step:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"HowTo\",\n \"name\": \"Come configurare robots.txt per AI crawler\",\n \"step\": [\n {\n \"@type\": \"HowToStep\",\n \"position\": 1,\n \"name\": \"Identificare AI crawler target\",\n \"text\": \"Mappare gli user-agent dei crawler AI che vuoi permettere o bloccare.\"\n },\n {\n \"@type\": \"HowToStep\",\n \"position\": 2,\n \"name\": \"Definire strategia di accesso\",\n \"text\": \"Decidere se permettere training, solo search, o bloccare completamente.\"\n },\n {\n \"@type\": \"HowToStep\",\n \"position\": 3,\n \"name\": \"Implementare direttive\",\n \"text\": \"Aggiungere le regole User-agent e Allow/Disallow al file robots.txt.\"\n }\n ]\n}\n</script>\nOrganization e Person: E-E-A-T per AI
\nE-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.
\nLo schema Person deve andare oltre il nome. Serve comunicare credenziali, affiliazioni, competenze specifiche:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"Person\",\n \"name\": \"Mario Rossi\",\n \"url\": \"https://example.com/team/mario-rossi\",\n \"image\": \"https://example.com/images/mario-rossi.jpg\",\n \"jobTitle\": \"Senior AI Engineer\",\n \"description\": \"10+ anni di esperienza in ML/AI, specializzato in sistemi RAG enterprise\",\n \"worksFor\": {\n \"@type\": \"Organization\",\n \"name\": \"TechCorp Italia\",\n \"url\": \"https://techcorp.it\"\n },\n \"alumniOf\": {\n \"@type\": \"CollegeOrUniversity\",\n \"name\": \"Politecnico di Milano\"\n },\n \"hasCredential\": [\n {\n \"@type\": \"EducationalOccupationalCredential\",\n \"credentialCategory\": \"certification\",\n \"name\": \"AWS Machine Learning Specialty\"\n },\n {\n \"@type\": \"EducationalOccupationalCredential\",\n \"credentialCategory\": \"certification\",\n \"name\": \"Google Cloud Professional ML Engineer\"\n }\n ],\n \"knowsAbout\": [\n \"Retrieval-Augmented Generation\",\n \"Large Language Models\",\n \"Vector Databases\",\n \"MLOps\",\n \"AI Engineering\"\n ],\n \"sameAs\": [\n \"https://linkedin.com/in/mariorossi\",\n \"https://github.com/mariorossi\",\n \"https://scholar.google.com/citations?user=xxx\"\n ]\n}\n</script>\nChecklist E-E-A-T per schema Person:
\ndescription con anni di esperienza e specializzazionehasCredential per certificazioni verificabiliknowsAbout con topic specifici (non generici)sameAs con link a profili verificabili (LinkedIn, GitHub, Google Scholar)alumniOf per affiliazioni accademicheworksFor con URL organizzazionePer contenuti che citano fonti esterne, lo schema Citation aggiunge contesto:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Analisi Paper GEO Princeton\",\n \"citation\": [\n {\n \"@type\": \"ScholarlyArticle\",\n \"name\": \"GEO: Generative Engine Optimization\",\n \"author\": [\"Pranjal Aggarwal\", \"et al.\"],\n \"datePublished\": \"2024\",\n \"publisher\": {\n \"@type\": \"Organization\",\n \"name\": \"Princeton University\"\n },\n \"url\": \"https://arxiv.org/abs/2311.09735\"\n }\n ]\n}\n</script>\nI 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:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"ImageObject\",\n \"contentUrl\": \"https://example.com/images/architettura-rag.png\",\n \"name\": \"Architettura sistema RAG enterprise\",\n \"description\": \"Schema architetturale che mostra il flusso dati tra vector store, retriever e LLM in un sistema RAG di produzione\",\n \"author\": {\n \"@type\": \"Person\",\n \"name\": \"Mario Rossi\"\n },\n \"datePublished\": \"2025-01-04\",\n \"encodingFormat\": \"image/png\"\n}\n</script>\nPer video con trascrizione:
\n<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"VideoObject\",\n \"name\": \"Deploy RAG in produzione: walkthrough\",\n \"description\": \"Video tutorial su deployment di sistema RAG su AWS con monitoring\",\n \"thumbnailUrl\": \"https://example.com/video/rag-deploy-thumb.jpg\",\n \"uploadDate\": \"2025-01-04\",\n \"duration\": \"PT12M30S\",\n \"transcript\": \"https://example.com/video/rag-deploy-transcript.txt\",\n \"author\": {\n \"@type\": \"Person\",\n \"name\": \"Mario Rossi\"\n }\n}\n</script>\nBest practice per media AI-friendly:
\nJohn Mueller di Google ha chiarito a gennaio 2025 che lo structured data non è un fattore di ranking diretto. Ma l’impatto indiretto è documentato:
\nLo structured data non garantisce citazioni nei motori generativi. Ma fornisce il contesto semantico che facilita l’interpretazione corretta del contenuto.
\nOltre allo structured data, ci sono requisiti tecnici che influenzano la capacità dei LLM di processare e citare i contenuti.
\nGli AI crawler hanno difficoltà con contenuti renderizzati via JavaScript. A differenza di Googlebot, che esegue JS, molti crawler AI preferiscono o richiedono HTML statico.
\nRegole operative:
\nIl 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.
\nImplementazione:
\ndateModified in schema deve riflettere aggiornamenti reali:
<script type=\"application/ld+json\">\n{\n \"@context\": \"https://schema.org\",\n \"@type\": \"TechArticle\",\n \"headline\": \"Guida RAG Produzione\",\n \"datePublished\": \"2024-06-15\",\n \"dateModified\": \"2025-01-04\"\n}\n</script>\nChecklist freshness:
\ndateModified solo per modifiche sostanziali (non typo fix)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.
\nRegole:
\nIl paper “GEO: Generative Engine Optimization” 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.
\n1. Cite Sources: +40% visibilità
\nAggiungere 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.
\nNon basta citare. La citazione deve essere da fonte riconosciuta, pertinente al claim, verificabile.
\n2. Quotation Addition
\nIncorporare citazioni dirette da esperti del settore aumenta autenticità e profondità percepita. Funziona particolarmente per contenuti opinion-based.
\n3. Statistics Addition
\nDati 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.
\nI LLM non citano pagine intere. Estraggono blocchi specifici. Ottimizzare per questo pattern è critico.
\nPassage 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.
\nImplementazione pratica:
\nTL;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.
\nSezioni self-contained: Ogni H2/H3 deve essere citabile indipendentemente dal resto. Un LLM deve poter estrarre quella sezione e avere una risposta completa.
\nHeading come domande: “Cos’è il RAG?” performa meglio di “RAG Overview”. Matching diretto con query conversazionali.
\nParagrafi modulari: 75-300 parole per sezione. No wall of text. I blocchi modulari sono più facili da estrarre e citare.
\nRisposte dirette prima, contesto dopo: La risposta alla domanda implicita dell’heading deve apparire nelle prime 2-3 frasi. L’elaborazione viene dopo.
\nEsempio di struttura ottimizzata:
\n## Qual è la differenza tra SEO e GEO?\n\nSEO ottimizza per posizionarsi nelle liste di risultati dei motori\ndi ricerca tradizionali. GEO ottimizza per essere citati nelle\nrisposte sintetizzate dai motori generativi come ChatGPT, Perplexity\ne Gemini. [40-60 parole di risposta diretta]\n\nIl cambiamento fondamentale riguarda l'obiettivo: dal ranking alla\ncitazione. Nel SEO classico, il successo è posizione 1 nelle SERP.\nIn GEO, il successo è essere la fonte che l'AI cita quando risponde.\n[Elaborazione e contesto]\nIl paper ha scoperto che l’efficacia varia per dominio:
\nOgni LLM ha preferenze diverse. Una strategia GEO efficace considera queste differenze:
\n| Piattaforma | \nPreferenze principali | \nOttimizzazione | \n
|---|---|---|
| ChatGPT | \nWikipedia, brand popolari, contenuti consolidati | \nAuthority building, presenza Wikipedia se applicabile | \n
| Perplexity | \nReddit, contenuti recenti, real-time | \nFreshness prioritaria, engagement community | \n
| Gemini | \nMultimodal, ecosistema Google, schema markup | \nVideo, immagini ottimizzate, structured data completo | \n
| Claude | \nAccuracy, contenuti bilanciati, attribuzione | \nProper attribution, framing neutro ed evidence-based | \n
| Google AI Overview | \nTop 10 organic, E-E-A-T forte | \nSEO tradizionale + structured data esteso | \n
Implicazioni operative:
\nKeyword stuffing: Aggiungere keyword dalla query al contenuto peggiora la visibilità del 10% rispetto al baseline. I motori generativi penalizzano l’over-optimization.
\nPersuasive language generico: Tono persuasivo senza sostanza non migliora il posizionamento.
\nUn 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.
\nPer piccoli editori e business indipendenti, è un’opportunità di competere con corporate giants senza budget SEO comparabili.
\ndescription con anni esperienza e specializzazionehasCredential per certificazioni verificabiliknowsAbout con topic specificisameAs con LinkedIn, GitHub, Google ScholardateModified aggiornato per modifiche sostanzialiI 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.
\nChi 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.
\nIl 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.
\nAggarwal, P., et al. (2024). GEO: Generative Engine Optimization. arXiv:2311.09735. Princeton University, Georgia Tech, Allen Institute for AI, IIT Delhi.
\nAI Mode Boost. (2025). AI Overview Ranking Factors: 2025 Comprehensive Study.
\nCloudflare. (2025, December). From Googlebot to GPTBot: Who’s Crawling Your Site in 2025. Cloudflare Blog.
\nDataslayer. (2025). Google AI Overviews Impact 2025: CTR Down 61%.
\nHoward, J. (2024, September). llms.txt Proposal. Answer AI.
\nW3C Schema Community. (2024). Schema Vocabulary Documentation.
\nSEO Sherpa. (2025, October). Google AI Search Guidelines 2025.
\nSingle Grain. (2025, October). Google AI Overviews: The Ultimate Guide to Ranking in 2025.
\nYoast. (2025). Structured Data with Schema for Search and AI.
\nOverdrive Interactive. (2025, July). LLMs.txt: The New Standard for AI Crawling.
\n", "date_published": "2025-01-04T00:00:00.000Z", "date_modified": "2025-01-04T00:00:00.000Z", "tags": [ "GEO", "SEO", "AI Search", "Schema.org", "robots.txt", "llms.txt", "Technical SEO", "E-E-A-T" ], "language": "it", "authors": [ { "name": "Irene Burresi" } ], "_localization": { "primary": "it", "translations": [ { "locale": "en", "url": "https://ireneburresi.dev/en/blog/engineering/seo-vs-geo/", "title": "From SEO to GEO: Technical Guide to AI Search Optimization" } ] } } ] }