Categoria: AI Adoption

Questo articolo nasce da un anno di lavoro sul campo e tre mesi di rilettura sistematica della letteratura. È diviso in tredici sezioni, raggruppate in quattro movimenti.

Il primo movimento (sezioni 1–3) racconta perché il vecchio metro non basta più e introduce la mappa delle quattordici dimensioni organizzate in tre piani — assi verticali misurabili del sistema (costo, qualità, sicurezza, debito, osservabilità), assi normativi e umani governati (compliance, etica, cultura, sovranità, adozione effettiva), lenti di lettura di prospettiva (ruoli, programmatore del futuro, maturità complessiva) — più uno scenario di destinazione trasversale (Agentic DevSecOps).

Il secondo movimento (sezioni 4–7) entra nelle dimensioni più dense: il costo come workflow e non come licenza; il triangolo qualità-sicurezza-debito con i dati 2025–2026 che lo confermano; l’effetto forbice tra senior che restano fuori dal cerchio e entusiasti che vi entrano senza mappa, con la mappa delle sei posture che ne deriva; e i tre assi che decidono se vinciamo o se ci nascondiamo — compliance, sovranità, cultura — con le scadenze EU AI Act aggiornate al post-Omnibus.

Il terzo movimento (sezioni 8–10) cambia angolo e ragiona sulle persone: la stessa mappa letta da quattro ruoli diversi, l’evoluzione del professionista del software del futuro, e la scala di maturità L0–L5 con il sotto-radar di autonomia agentica L5.0→L5.5 e la mappatura cross-framework verso Gartner, MIT CISR, ELEKS, AgID.

Il quarto movimento (sezioni 11–13) chiude lo sguardo: lo scenario di destinazione del team di agenti che fa DevSecOps in modo agile, la visione olistica che lega cerchio, sfera e n-sfera, e cosa porto via da tutto questo. Ogni sezione include un riquadro “Cosa dice il mercato” con riferimenti puntuali e datati; in fondo trovi l’elenco unificato delle quarantadue fonti citate. È un articolo lungo, ma è scritto per essere letto in più giri — la prima volta in cerca della mappa, le successive in cerca della propria posizione dentro la mappa.

Un anno fa, su queste pagine, ho aggiunto un cerchio. Era una scelta che, mentre la facevo, mi sembrava più narrativa che tecnica: i tre cerchi di Ecosistemi cloud native — persone, processi, tecnologie — non bastavano più, e ne serviva un quarto per ospitare quello che stava entrando dalla porta dei nostri team senza chiedere permesso. Lo chiamai il Quarto Cerchio, e nei mesi successivi ho provato a raccontarlo nei tre Ambassador, poi nell’Ouverture sull’Atto III e infine nel pezzo sulla custodia dell’umano che ha chiuso una stagione e ne ha aperta un’altra.

Quel cerchio, oggi, fattura. Consuma token. Apre pull request. Sbaglia, qualche volta in modo costoso. Apprende, qualche volta in modo sorprendente. Ha un budget, un proprietario, un audit log. Ha persino una sua governance normativa: l’EU AI Act è in piena fase attuativa (dopo l’Omnibus politico del 7 maggio 2026 le scadenze per i sistemi high-risk sono fissate al 2 dicembre 2027 per l’Annex III e al 2 agosto 2028 per l’Annex I, mentre le pratiche proibite sono già pienamente esigibili) [1]; ISO/IEC 42001 è certificabile e diventa l’operazionalizzazione dell’AI Act [2]; AgID ha pubblicato linee guida con tanto di livelli di autonomia agentica [3]. Quello che dodici mesi fa era una linea sul piano oggi è diventato un oggetto pieno, con un dentro e un fuori, e con un peso che si sente quando lo si solleva.

Questo articolo nasce da una domanda che mi sono fatto ad alta voce mentre lavoravo a un assessment di costi, e che poi ho continuato a sentire mentre rileggevo il libro vecchio: come si misura il valore di un compagno di lavoro che non dorme, non si stanca, ma costa per ogni parola che scrive — e che funziona molto diversamente a seconda di chi lo usa? È una domanda apparentemente di FinOps, ma sotto c’è un’altra cosa, più larga: come si guarda un Quarto Cerchio che è diventato vivente, e che si comporta diversamente con persone diverse?

La risposta in cui mi sono imbattuto non è una formula. È una mappa. Una mappa con quattordici dimensioni, una scala di maturità a sei gradini, un orizzonte — quello del team di agenti che fanno DevSecOps insieme a noi — che non è più un’ipotesi accademica, e una piega umana che il mercato sta ancora cercando di nominare: ciò che succede quando i professionisti più esperti si tengono fuori dal cerchio, e i più entusiasti vi entrano senza mappa.

Questo articolo è quella mappa. Il libro che sto scrivendo, dedicato interamente al Quarto Cerchio, sarà il viaggio dentro quella mappa.

Per quindici anni il modo in cui abbiamo misurato la tecnologia nel ciclo di vita del software è stato relativamente semplice: licenze, server, persone. Si comprava una licenza per professionista, si stimava il consumo di infrastruttura, si calcolava la velocità del team. Il TCO era una somma quasi lineare di voci ben note.

Il Quarto Cerchio rompe questo metro per quattro ragioni che, prese insieme, lo rendono inservibile.

La prima è che il costo è diventato variabile in modo profondo. Non variabile come lo era il cloud, dove la variabilità riguardava la capacità — più CPU, più storage, più rete. Variabile come lo è il linguaggio: ogni frase costa, ogni contesto inviato costa, ogni risposta generata costa, ogni riflessione tra agenti costa. Il prezzo non si misura più in seat ma in workflow, e due professionisti con la stessa licenza possono produrre, nello stesso mese, conti dieci volte diversi.

La seconda è che la qualità ha smesso di essere un controllo a valle. Quando il codice lo scriveva una persona, la qualità era un check che avveniva alla pull request. Quando il codice lo scrive — o lo co-scrive — un’AI, la qualità entra nel processo stesso di generazione: dipende dal prompt, dal modello scelto, dal contesto disponibile, dal momento storico in cui si lavora. Studi recenti convergono su una fascia preoccupante: lo studio Veracode 2025 segnala che circa il 45% del codice AI-generated introduce vulnerabilità OWASP Top 10 [4]; il benchmark indipendente AppSec Santa 2026 su 522 sample di sei LLM porta il dato medio al 25,7% [5]. La forchetta è ampia, ma il messaggio è univoco: la qualità è diventata un asse di misurazione continuo, non un cancello binario.

La terza è che il rischio è entrato in una dimensione normativa nuova. Tra AI Act, NIS2, ISO 27001:2024 estesa con i controlli AI, ISO/IEC 42001 e linee guida AgID, il software non è più solo un prodotto che fa cose: è un soggetto che deve essere rendicontabile. Chi ha generato questa funzione? Quale modello? Con quale prompt? Con quale livello di intervento umano? Senza tracciabilità, niente compliance. Senza compliance, niente produzione.

La quarta — e qui voglio dare un nome a una cosa che ho visto crescere mese dopo mese nei team con cui lavoro — è che l’adozione non è uniforme. Lo stesso strumento, nello stesso team, viene rifiutato da una parte dei senior e abbracciato senza criterio da una parte dei junior. Il risultato è una velocità apparente che nasconde un debito reale, e una qualità a macchia di leopardo che le metriche di sistema non vedono. Su questo torno tra qualche sezione: è la dimensione più viva di tutta la mappa.

Per misurare il Quarto Cerchio serve, allora, un metro nuovo. Non un metro singolo. Un metro che sa di essere a più assi, e che non si vergogna di esserlo.

Per non perdersi nella complessità ho organizzato le dimensioni che il mercato sta mettendo a fuoco — incrociate con quelle che noi stiamo già usando nei nostri assessment interni — in tre piani. È una scelta deliberata: non tutte le dimensioni hanno la stessa natura, e trattarle come se fossero omogenee sarebbe il primo errore di metodo.

Il primo piano raccoglie gli assi verticali: sono proprietà misurabili del sistema. Il costo, la qualità, la sicurezza, il debito tecnico, l’osservabilità. Sono cose che si quantificano, si monitorano, si confrontano nel tempo. Hanno KPI nativi.

Il secondo piano raccoglie gli assi normativi e umani: sono proprietà governate del sistema. La compliance, l’etica con il suo presidio umano, la cultura aziendale, la sovranità tecnologica, e — la nuova arrivata — l’adozione effettiva, che è la dimensione più umana di tutte. Non si misurano con un contatore: si presidiano con policy, evidenze, processi, conversazioni vere.

Il terzo piano raccoglie le lenti di lettura: non sono proprietà del sistema, sono modi di guardarlo. Il ruolo di chi legge l’analisi (responsabile di area, di prodotto, di progetto, professionista del software), l’evoluzione del professionista stesso, la maturità complessiva come fotografia integrata di tutto.

Sopra a questi tre piani cammina un orizzonte trasversale: lo scenario architetturale del team di agenti che fa DevSecOps in modo agile.

#	Dimensione	Piano	A chi parla per primo
1	Costo del processo (non del consumo)	A — verticale	CFO, FinOps, project manager
2	Qualità dell’impiego degli assistenti AI	A — verticale	tech lead, QA manager
3	Sicurezza del codice AI-generated	A — verticale	CISO, security architect
4	Debito tecnico longitudinale	A — verticale	architetto, CTO
5	Osservabilità degli agenti (AgentOps)	A — verticale	DevOps lead, SRE
6	Compliance e governance regolatoria	B — normativo	compliance officer, DPO
7	Etica e human-in-the-loop	B — normativo	leadership
8	Cultura, change management, AI literacy	B — umano	HR, capi area, formazione
9	Sovranità tecnologica e neutralità	B — normativo	CTO, board
10	Adozione effettiva ed effetto forbice	B — umano	tech lead, capi area, CTO
11	Ruoli e prospettive	C — lente	management
12	Professionista del software del futuro	C — lente	dev community
13	Maturità complessiva	C — lente	CTO, board, clienti
14	Agentic DevSecOps (scenario di destinazione)	Trasversale	tutti

Una nota sul vocabolario: in questo articolo userò spesso professionisti del software invece di programmatori. Il Quarto Cerchio tocca tutti — sviluppatori, architetti, analisti, ingegneri, QA, DevOps, SRE, security engineer, persino chi fa pre-sales tecnico — e ridurlo ai soli developer è una semplificazione che ci farebbe perdere metà del fenomeno

Quando si parla di costo dell’AI nello sviluppo software, la prima cosa che si fa di solito è guardare il listino. Il listino racconta una parte minuscola della verità.

Il vero costo è quello del workflow, e il workflow è la combinazione di cinque ingredienti: costo di accesso (la licenza), costo di inferenza (token in ingresso, token in uscita, cache, grounding), costo dei servizi accessori (revisione codice, runtime degli agenti, GitHub Actions, knowledge base), costo della governance (overage, budget control, audit) e costi infrastrutturali collegati.

Per dare un’idea concreta: GitHub Copilot, dal 1° giugno 2026, ha definitivamente abbandonato il modello dei Premium Requests per passare ai AI Credits, con budget separati a livello di utente, organizzazione e cost center [6]. Vertex AI funziona su un modello quasi puramente token-based, in cui il contesto inviato — il pezzo di repository, il diff di una PR, il log di un errore — diventa la variabile dominante. Claude Code e l’API di Anthropic combinano subscription e consumo, con i managed agents che introducono un costo aggiuntivo per session-hour. Amazon Bedrock, infine, non è un prezzo: è un contenitore di prezzi che varia per modello, provider e tier (on-demand, flex, priority, reserved), con sconti significativi sul batch.

La conseguenza pratica è che il costo non si stima più “per utente”. Si stima per classe di workflow:

• autocomplete e completamenti inline, dove il costo marginale tende a zero
• Q&A tecnica, spiegazioni, generazione di test, costo basso ma costante
• refactoring e revisione di pull request, costo crescente con la dimensione del contesto
• comprensione cross-file e reasoning sull’intero repository, costo rilevante
• task agentici multi-step, dove al costo dei token si somma il costo del runtime di sessione

C’è poi una voce che le dashboard FinOps non vedono e che, dalla mia esperienza nei team, vale a volte quanto tutte le altre messe insieme: il costo di sfrido. È il tempo che le persone spendono a sperimentare senza capitalizzare: provare un modello e abbandonarlo, riscrivere un prompt da zero ogni volta, valutare in modo disordinato strumenti che dovrebbero essere già selezionati a livello organizzativo. Lo sfrido non sta in fattura, sta nei timesheet. E uno studio METR molto citato lo ha quantificato in modo controintuitivo: developer esperti, con controlli rigorosi, erano in media il 19% più lenti usando AI rispetto alle stime, pur percependo di essere il 20% più veloci [7]. È il dato più forte per smentire le narrazioni di “10x productivity”.

La metrica da portare in un comitato di direzione, allora, non è “quanto spendiamo in AI”. È costo per feature completata, costo per PR revisionata, costo per migrazione di modulo, costo per ora di sviluppo assistito, costo di sfrido per team.

Cosa dice il mercato. AgID, nelle linee guida per la PA, introduce il concetto di LCOAI — Costo Livellato dell’IA, una metrica ispirata al LCOE energetico che valuta la sostenibilità economica sull’intero ciclo di vita, con esempi di calcolo SaaS+API esterne vs self-hosted on-premises [3]. Il punto di vista FinOps internazionale converge: la FinOps Foundation segnala che “managing the cost and use of tokens is the top challenge facing FinOps practitioners today” e propone un mix di API key governance, proxy layer, unit cost metrics e model right-sizing [8]. Due lenti diverse — istituzionale italiana per i servizi di filiera, FinOps internazionale per i token granulari — che però convergono sullo stesso punto: misurare per workflow, non per licenza.r la PA, ha introdotto il concetto di LCOAI — Costo Livellato dell’IA, una misura ispirata alle metriche energetiche (LCOE), che valuta la sostenibilità economica dell’AI sull’intero ciclo di vita dell’iniziativa, non sull’acquisto iniziale. È la stessa direzione in cui stiamo andando.

Negli ultimi mesi è emersa con forza una verità che era prevedibile, ma che pochi avevano osato dire: il vero collo di bottiglia non è il costo. È la qualità. E dentro la qualità si nascondono due cose distinte che vale la pena separare: la sicurezza del codice generato e il debito tecnico longitudinale.

Sulla sicurezza, le evidenze sono ormai abbondanti. La fascia di codice AI-generated con vulnerabilità riconducibili a OWASP Top 10 oscilla, a seconda delle fonti, tra il 25% e il 45% [4][5]. Snyk converge nella stessa fascia parlando di codice AI “30-40% più vulnerabile di quello scritto da umani” [9]. Non è un dato che condanna l’AI: è un dato che impone un controllo continuo. Significa che ogni pull request generata o co-generata da AI deve passare attraverso SAST, dependency analysis, secret detection, e — soprattutto — code review umana effettiva, non simbolica.

Sul debito tecnico, la questione è più sottile e più pericolosa. Un team che adotta l’AI senza misurare come il proprio codice evolve nel tempo non vede crescere il debito: lo vede non vedere. Un paper accademico molto recente (Verma, ottobre 2025) propone un modello matematico break-even validato su tre casi industriali per 153 milioni di righe di codice, e arriva a una tesi tagliente: “the productivity case for LLM coding assistants is real but incomplete — standard metrics capture the benefit on a timescale of days to weeks while costs accumulate over months, creating a systematic measurement blind spot in most current adoption programs” [10]. La velocità apparente dei primi mesi nasconde una stratificazione di scelte rapide, di pattern non sempre coerenti, di test generati per coprire il numero più che la sostanza.

C’è poi un punto che spesso viene saltato e che va detto chiaramente: la qualità di ciò che esce dall’AI è una funzione di chi la usa, non solo dello strumento. Lo stesso assistente, in mano a un senior formato che sa interrogarlo, leggere criticamente la sua risposta, riconoscerne i punti deboli e correggerli, produce codice di livello alto. In mano a un entusiasta non formato, che accetta la prima risposta plausibile e la committa, produce debito tecnico ben confezionato. La qualità, qui, non è una proprietà dello strumento: è il prodotto strumento × utente.

Il benchmark CodeRabbit 2026 lo quantifica: le pull request AI-generated hanno in media 10,83 issue contro 6,45 delle umane, con 1,75x più errori di logica, 1,57x più security issues, 1,42x più performance issues [11]. E sul fronte della percezione, la Stack Overflow Developer Survey 2025 su 49.000 sviluppatori mostra che l’adozione è all’84% ma la fiducia è scesa al 29% (era 40% nel 2024), mentre il 66% dichiara di spendere più tempo a sistemare codice AI “quasi giusto ma non quite” [12]. Due fonti, due lenti — laboratorio e percezione di massa — che convergono.

Qui entra in scena una dimensione che il mercato sta nominando solo adesso: l’osservabilità degli agenti, o AgentOps. È l’estensione naturale di DevOps quando in produzione non c’è più solo codice, ma codice + agenti che decidono. La formalizzazione AgentOps di Infosys parla esplicitamente di estensione di DevSecOps + MLOps + LLMOps con guardrails specifici per agenti [13], e l’ecosistema tooling open-source è già attivo (AgentOps.ai, 5,7k star GitHub, integrazioni con CrewAI, AG2, OpenAI Agents SDK, LangGraph) [14]. Non è teoria.

Il triangolo qualità–sicurezza–debito non si risolve con un tool. Si presidia con un processo. E il processo, dentro un Quarto Cerchio maturo, deve avere memoria.

Arrivo alla dimensione più viva di tutta la mappa, e quella che, finché non l’ho vista nominare con onestà, non avevo capito quanto fosse centrale.

C’è un fenomeno che molti report sintetizzano sotto la parola gentile “adoption rate” e che, dentro i team reali, è invece una forbice. Da una parte ci sono i professionisti senior che rifiutano l’AI. Non per ignoranza — sarebbe troppo semplice — ma per una postura più complessa, che mescola in proporzioni variabili tre cose: la sensazione che “so già fare meglio di così”, il legittimo sospetto verso allucinazioni e scorciatoie pericolose (che i senior, va detto, vedono prima degli altri), e una difesa identitaria verso un mestiere costruito in vent’anni che ora rischia di essere rinominato.

Dall’altra parte della forbice ci sono i professionisti entusiasti senza formazione. Usano l’AI tutto il giorno, in ogni passaggio del lavoro. Cambiano modello al volo, scrivono prompt diversi ogni volta, valutano in modo disordinato strumenti che a livello organizzativo dovrebbero essere già selezionati. Producono codice che oggi funziona e che domani sarà difficile manutenere. La loro velocità apparente nasconde la dispersione cognitiva che ho già chiamato sfrido.

In mezzo, tra le due lame della forbice, c’è la maggioranza silenziosa: persone che usano l’AI in modo medio, senza posizione, senza opinione. Sono il pubblico più importante di tutti, perché è da loro che dipende se l’organizzazione si muove davvero verso L3-L4 della scala di maturità o resta inchiodata a L1-L2.

Ho provato a disegnare una mappa delle posture che possiamo abitare di fronte all’AI nel nostro mestiere. Sono sei, e mi pare che ognuno di noi si riconosca in almeno una.

Postura	Caratteristica dominante	Costo che produce	Leva per muoversi
Rifiutante	“L’AI non serve, fa danni”	Sapere senior fuori dal cerchio	Esperienze guidate su casi noti
Scettico-osservante	“Guardo, ma non tocco”	Lentezza nell’adozione di pratiche	Pair programming con utenti formati
Sperimentatore disordinato	“Provo tutto, capitalizzo poco”	Sfrido alto, qualità irregolare	Cornice di metodo, prompt library condivise
Utente medio	“La uso quando capita”	Maturità organizzativa bloccata	Onboarding strutturato, KPI di team
Utente formato	“La uso con metodo”	Costo basso, qualità alta	Riconoscimento, ruolo di mentor
Orchestratore	“La uso per orchestrare sistemi”	Investimento iniziale alto	Esposizione a casi agentici reali

La forbice non è un destino. È uno stato del sistema, e come ogni stato si può cambiare. Ma servono leve specifiche per ciascuna postura. Il rifiutante non ha bisogno di un corso: ha bisogno di un caso d’uso in cui la sua esperienza venga riconosciuta come decisiva. Lo sperimentatore non ha bisogno di un altro tool: ha bisogno di un metodo che dia forma alla sua energia.

Cosa dice il mercato. L’osservazione che ho costruito sul campo trova un’evidenza empirica forte nei dati Faros AI su 10.000+ developer e 1.255 team: i meno esperti si appoggiano molto di più ai tool AI, mentre “senior engineers with deep system knowledge resist” — ma quando i senior adottano, “ship 2,5x more AI-generated code than juniors”, mentre i senior scettici producono code review 91% più lunghe [15]. Una lettura psicologica complementare viene dall’analisi di Yuliyan Gospodinov: la divisione non è anagrafica, è psicologica (process-oriented vs result-oriented), e “developers who’ve spent a decade or two building their identity around technical skill are being asked to shift their value proposition… that’s a real psychological cost, not a trivial adjustment” [16]. Sul piano operativo, una sintesi di Bain conferma che il problema è organizzativo, non tecnologico: “the mistake most engineering leaders make is treating all developers the same” [17]. Da molte fonti emerge una mappa coerente di cinque ragioni di resistenza (deskilling, trust, workflow disruption, quality concerns, professional identity), tutte razionali e tutte affrontabili [18].

Una nota sincera, dovuta. Questo non è un fenomeno teorico. È un fenomeno che sto vedendo accadere in tempo reale nei contesti in cui lavoro, e che molti colleghi mi raccontano con parole simili. Per onestà narrativa lo dico apertamente: questa è la dimensione che ho aggiunto alla mappa dopo aver scritto la prima versione di questo articolo, perché parlandone mi sono accorto che mancava — e mancava perché il mercato la nasconde nella scatola comoda del “change management”. Non è change management. È un asse di assessment.metriche, le sue leve. E va trattato così.

Il resto del secondo piano della mappa è quello che, paradossalmente, viene trattato per ultimo dalla maggior parte delle organizzazioni. È un errore.

Sulla compliance, il quadro normativo del 2026 è chiaro: EU AI Act in piena attuazione (con le scadenze high-risk allungate ma le pratiche proibite già esigibili e sanzioni fino a €35M o 7% del fatturato) [1]; ISO/IEC 42001 disponibile per la certificazione AI Management Systems e ormai riconosciuto come l’operazionalizzazione tecnica dell’AI Act [2]; NIS2 recepita; ISO 27001:2024 estesa con i controlli AI; AgID con i suoi sei livelli di autonomia per architetture agentiche [3]. Non è più una zona grigia. La domanda non è più “dobbiamo essere conformi?” — è “con quale velocità lo diventiamo, e quanta evidenza siamo in grado di produrre?”.

Sulla sovranità tecnologica, il discorso è meno tecnico e più strategico. Il quadro istituzionale UE è netto: “the EU relies on suppliers outside its borders for more than 80% of its key digital products, services, infrastructure, and IP” e “more than 70% of the EU cloud market is held by three US hyperscalers” [19]. Ursula von der Leyen ha sintetizzato così la posta in gioco: “we cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure” [19]. AgID introduce come pilastro il concetto di neutralità hardware e portabilità tra fornitori [3]. Per chi si posiziona nel framework European Secure & Sovereign AI, questo non è uno slogan: è un asse architetturale che decide come si disegnano le pipeline, come si gestiscono i secret, come si valutano i vendor.

Cosa dice il mercato. Per trasparenza editoriale dichiaro che faccio parte di DedaGroup, che ha pubblicamente articolato un proprio posizionamento ESS-AI. Marco Podini (CEO DedaGroup) lo sintetizza così: “la partita più importante di questa nuova era digitale si gioca proprio nella capacità per ciascuna organizzazione di definire la propria sovranità del rischio, modulata in base alla sensibilità delle informazioni, al contesto d’uso e al livello di fiducia” [20]. Un punto di vista internazionale aggiunge urgenza concreta: il blackout globale di Anthropic del giugno 2026 (la “Fable Ban”) che ha disattivato Claude Fable 5 e Mythos 5 per export-control USA, è diventato il “practical test of sovereignty: can a foreign directive, a vendor outage, or a price change take your AI away? If yes, you are not sovereign” [21]. Una survey SUSE chiude il quadro: “98% of IT leaders call digital sovereignty a priority — but only 52% report taking any action on it” [22]. È il classico gap acknowledgment-vs-action.

Sulla cultura, infine, c’è il punto che più mi sta a cuore, e che adesso — alla luce della sezione sull’effetto forbice — assume un senso più preciso. Nel mio lavoro di questi mesi mi sono convinto che la frase più importante che possiamo dirci, davanti al Quarto Cerchio, sia questa: diventare un’organizzazione AI-empowered richiede che le persone cambino prima ancora delle tecnologie.

Cosa dice il mercato. Gartner quantifica il costo culturale: “AI adoption demands 25% more training effort and up to 200% additional change management effort” rispetto a tecnologie tradizionali. “81% of CIOs say GenAI skill gaps will block their 2025 objectives, while 63% of employees haven’t used GenAI in critical tasks” [23]. La cultura è uno dei sette pilastri del modello Gartner di AI maturity (insieme a strategia, valore, organizzazione, governance, engineering, dati), non un addendum [24].

L’AI literacy non è un corso. È un’abitudine che si costruisce con esperienze ripetute, con piccoli successi condivisi, con errori discussi senza vergogna. Se l’effetto forbice è il problema, la cultura è la leva che lo affronta. Pair programming intergenerazionale tra senior rifiutanti e junior entusiasti — non come corso, ma come pratica regolare. “AI office hours” condotte dai senior che si sono mossi per primi. Sandbox controllate per gli sperimentatori. Retrospettive sull’uso dell’AI alla pari di quelle sul codice. Non sono pratiche eroiche. Sono pratiche piccole, ripetute, riconosciute.

E sull’etica con presidio umano, un richiamo netto è necessario. “Presence is not practice. Most organizations put someone ‘in the loop’ without training them on what to approve, when to escalate, or how to recognize automation complacency” — l’EU AI Act Article 14 richiede oversight “demonstrably trained, measurable, and provable”, non simbolica [25]. La letteratura accademica ha già consolidato una tassonomia HITL (loop placement, interaction granularity, temporal characteristics) [26] e dimostrato sul campo che “errors can propagate and compound along the workflow, especially when we string numerous agentic components together” [27]. Human-in-the-loop non è opzionale per i workflow agentici reali.

Una delle cose che ho imparato in questi mesi è che lo stesso dato cambia significato a seconda di chi lo legge. Il costo per feature completata, per esempio, dice cose molto diverse a un responsabile di area, a un responsabile di prodotto, a un project manager, a un professionista del software.

Per il responsabile di area è una metrica di portafoglio: confronta progetti tra loro, decide allocazioni, individua aree di efficienza. L’effetto forbice è per lui una metrica di rischio organizzativo.

Per il responsabile di prodotto è una metrica di time-to-value: collega l’investimento AI al ritorno sul mercato, valuta se la velocità apparente si traduce in valore reale. Lo sfrido è un nemico silenzioso.

Per il project manager è una metrica di delivery: gli serve per stimare meglio, per negoziare scope, per gestire imprevisti. L’asimmetria delle posture nel team è uno dei suoi rischi principali.

Per il professionista del software, infine, è una metrica di autonomia operativa. Sapere quanto costa il workflow che sta usando, capire dove la sua postura attuale lo colloca nella mappa delle sei posizioni, riconoscere se è in una fase di sfrido o di capitalizzazione: tutto questo lo rende un soggetto consapevole, non un consumatore inconsapevole.

Cosa dice il mercato. BCG, su uno studio che copre 165 milioni di lavori USA e 1.500 ruoli, classifica il software engineering come Amplified Role (non Diminished): “the nature of what people do in these jobs will change significantly, even when the job title remains the same”. Stima: il 50-55% dei lavori sarà reshaped da AI in 2-3 anni, ma solo il 10-15% sarà eliminato in 5 anni [28]. Una lettura organizzativa complementare parla di tre stadi di maturità AI workforce (tool-based → workflow transformation → agent-led orchestration), con la previsione che “traditional pyramids are giving way to flatter, AI-augmented pods, redefining the need for junior, coordinator, and manager roles” [29].

Per ciascuno di questi ruoli, la stessa mappa va letta con un diverso ordine di priorità. Nel libro proverò a costruire una guida di lettura per ruolo. Nell’articolo basta tenere a mente questo: la prospettiva non è un dettaglio. È metà del significato del dato.

Su questo punto voglio essere chiaro, perché è il punto su cui leggo le previsioni più sbagliate.

Il professionista del software non sta morendo. Sta cambiando mestiere — e lo sta facendo molto più velocemente di quanto si racconti. Il movimento che vedo nei team in cui lavoro va in questa direzione: meno tempo passato a scrivere righe di codice, più tempo passato a definire il contesto in cui un’AI lavorerà bene; meno tempo passato a leggere codice riga per riga, più tempo passato a giudicare se una soluzione è coerente con un’architettura più ampia; meno tempo passato a debuggare a mano, più tempo passato a progettare il sistema che farà debug per noi.

Una delle domande più frequenti quando si parla di Intelligenza Artificiale nello SDLC è se nasceranno nuovi ruoli professionali o se quelli esistenti siano destinati a scomparire.

La mia impressione è che stiamo osservando un fenomeno diverso.

Prima ancora che nuovi ruoli, stanno emergendo nuove competenze trasversali che ogni attore coinvolto nel ciclo di vita del software dovrà progressivamente acquisire. Analyst, Developer, Tester, Architect, DevOps Engineer, Security Specialist e Manager continueranno a svolgere funzioni differenti, ma saranno chiamati a operare in contesti dove modelli e agenti AI diventano parte integrante del processo produttivo.

La trasformazione non riguarda soltanto gli strumenti utilizzati, ma il modo stesso di lavorare. Diventeranno sempre più importanti la capacità di costruire contesto per un agente, validarne i risultati, selezionare il modello più adatto al problema da risolvere, comprendere costi e benefici dell’automazione, governare qualità, sicurezza e conformità degli artefatti generati.

In questo scenario l’AI non sostituisce automaticamente il professionista. Al contrario, aumenta il valore di chi sviluppa competenze di orchestrazione, supervisione e indirizzo. La scrittura del codice rimane importante, ma non è più l’unica competenza distintiva. Cresce invece il peso della capacità di definire obiettivi, costruire workflow, interpretare risultati e prendere decisioni.

Il Quarto Cerchio introduce quindi un nuovo livello di alfabetizzazione professionale che attraversa l’intero SDLC. Non parliamo di una competenza riservata agli sviluppatori né agli architetti software. Parliamo di un insieme di capacità che ogni ruolo coinvolto nel processo dovrà gradualmente acquisire per collaborare efficacemente con modelli, agenti e sistemi intelligenti.

Queste nuove competenze comprendono, ad esempio:

• la capacità di collaborare con assistenti e agenti AI;
• la costruzione e gestione del contesto informativo;
• la verifica e validazione degli output generati;
• la comprensione dei costi e dei benefici dell’automazione;
• la selezione consapevole di modelli e strumenti;
• la capacità di integrare l’AI nei processi decisionali;
• la comprensione degli impatti su qualità, sicurezza e governance.

Per questo motivo il vero rischio non è l’automazione in sé, ma la mancata evoluzione professionale. Così come il cloud, la sicurezza by design e le pratiche DevOps hanno richiesto negli anni nuovi percorsi di apprendimento, anche il Quarto Cerchio richiede l’acquisizione di nuove competenze operative e decisionali.

Non tutti seguiranno lo stesso percorso e non tutti alla stessa velocità. Alcune organizzazioni potranno scegliere di specializzare determinate competenze in figure dedicate. Tuttavia il cambiamento più profondo non riguarda la nascita di un nuovo job title, bensì la diffusione di una nuova capacità professionale: collaborare efficacemente con ecosistemi di modelli e agenti AI all’interno dei processi di sviluppo software.

Il professionista del futuro, quindi, non scompare.

Si evolve.

E la velocità con cui saprà acquisire queste nuove competenze potrebbe diventare uno dei principali fattori distintivi del prossimo decennio.

Su tutte potrebbe nascere, di fatto, una competenza che oggi chiamiamo che assomiglia sempre di più a un orchestratore di intelligenze. È una figura che possiede ancora un fondo solido di fondamentali — non ci si può improvvisare orchestratore se non si conosce lo strumento — ma che lavora in un layer più alto: quello del prompt-as-design, dell’agent-as-team-member, della policy-as-code.

Cosa dice il mercato. La voce più netta è quella di Nicholas Zakas (autore di ESLint), che descrive tre fasi (cruise control → conductor → orchestrator): “the software engineering job of the future won’t involve writing code; it will involve orchestrating AI agents to write code for you” [30]. La quantificazione la dà Anthropic con il suo 2026 Agentic Coding Trends Report: i developer usano AI in circa il 60% del lavoro, ma delegano completamente solo lo 0-20% — lo sviluppatore è orchestratore, non writer [31]. JetBrains 2026 conferma con dati di campo: 85% developer usano AI quotidianamente, mentre Microsoft dichiara che circa il 30% del codice in alcuni repo è AI-generated (Google attorno al 25%): “you’re the engineering lead of a team of tireless, competent junior developers” [32].

Va detta, però, anche la parte meno ottimistica. Non tutti i senior sceglieranno di trasformarsi, ed è una scelta che — almeno in alcuni casi — è legittima. Alcuni preferiranno restare maestri del codice tradizionale fino alla fine della loro carriera, e l’organizzazione dovrà decidere come valorizzarli senza forzarli. Altri sceglieranno di non trasformarsi per pigrizia o difesa, e l’organizzazione dovrà decidere quanto a lungo può permetterselo. La trasformazione del mestiere non è automatica: è una scelta personale dentro una cornice organizzativa, ed entrambe contano.

Dentro questa trasformazione mi piace pensare che resti centrale un mestiere che oggi sembra antico ma che diventerà nuovissimo: quello di chi sa dire no a una soluzione plausibile ma sbagliata. È un mestiere che ha bisogno di esperienza, di gusto, di etica. È — per usare una parola che ho scelto qualche mese fa — un mestiere di custodia.

La domanda che chiude qualsiasi analisi sul Quarto Cerchio è sempre la stessa: “a che punto siamo?”. Per anni il mercato ha risposto con scale a 9, 10, 12 livelli, ciascuno indistinguibile dal precedente.

Dopo aver studiato i framework che vanno consolidandosi — Gartner AI Maturity (5 livelli) [24], ELEKS AI-SDLC Maturity Model (5 stadi) [33], MIT CISR Enterprise AI Maturity (4 stadi) [34], AgID con i sei livelli di autonomia per architetture agentiche [3], e il recente SEI-Accenture AIM Framework (otto dimensioni) [35] — propongo una scala a sei gradini, da L0 a L5, costruita per essere leggibile a un board e abbastanza precisa per guidare un assessment.

Livello	Nome	Sostanza	KPI minimi
L0	Awareness	Si parla di AI. Nessun uso reale e strutturato.	Adozione formale = 0%; investimento <0,5% IT budget
L1	AI-supported	Singoli usano tool AI come autocomplete o chat ad hoc.	% developer con licenza AI
L2	AI-assisted	AI integrata nel workflow individuale, prime policy.	Costo AI per developer/mese; % PR con AI-assist >30%
L3	AI-integrated SDLC	AI presente in tutte le fasi DevSecOps, con governance e KPI.	Costo per feature; vulnerabilità per 1000 LOC; coverage ≥75%
L4	AI-native SDLC	SDLC riprogettato attorno all’AI; FinOps maturo; cultura diffusa.	LCOAI per workflow; tasso di adozione effettiva ≥80%; ISO/IEC 42001 in corso
L5	Agentic DevSecOps	Team di agenti orchestrati che eseguono autonomamente l’SDLC con human-in-the-loop.	% task autonomi; MTTR task agentic; % checkpoint HITL superati

Dentro L5 esiste un sotto-radar di autonomia, graduato in sei tacche (L5.0 → L5.5), ispirato sia ai livelli AgID che al modello ACMM di Andy Anderson (IBM Research) che parte da CMMI e arriva al livello 6 Hive — agenti multipli orchestrati in produzione [36]:

• L5.0 Suggest-and-wait (umano approva ogni step)
• L5.1 Multi-agent assistito con HITL nei punti critici
• L5.2 Autonomia di fase
• L5.3 Autonomia multi-fase con checkpoint
• L5.4 Autonomia con auto-rollback
• L5.5 Autonomia cross-dominio (oggi solo in ricerca)

Voglio aggiungere qui un’osservazione che, alla luce della sezione sull’effetto forbice, mi pare cruciale. L3 è un soffitto, se la postura senior non si sposta. Si può comprare la migliore tecnologia del mercato, scrivere policy impeccabili, lanciare programmi di literacy estesi: se i senior restano rifiutanti o scettici-osservanti, l’organizzazione non passa L3. La maturità organizzativa ha soglie di sblocco umane, e la più importante è quella che si attraversa quando un numero critico di senior — non tutti, ma una massa percepibile — entra nel cerchio come utente formato o orchestratore.

Cosa dice il mercato. Niraj Veer (co-editor dello standard EU AI Act security e ISO/IEC 5338) lo sintetizza così: “88% of organizations use AI in at least one function; only 1,5% across all systems in production are classified as AI systems”; e ancora: “AI maturity will not come from a single project, pilot, or purchase. It will come from a steady, deliberate shift in how you govern your software and AI as one portfolio” [37]. Una comparazione critica dei principali framework (MITRE, MIT CISR, Gartner, Microsoft, KPMG) aggiunge un monito metodologico che vale la pena tenere a mente: “maturity models are descriptive, not prescriptive. They tell you where you are; they do not tell you which use case to fund” [38]. La scala è una bussola, non una ricetta.

Una nota di metodo: la scala è una traiettoria, non una fotografia. Un’organizzazione non “è” a un livello; lo è in alcune aree, mentre in altre è uno o due livelli indietro. Un assessment serio fotografa il profilo, non il punto.e, mentre in altre è uno o due livelli indietro. Un assessment serio fotografa il profilo, non il punto. Ed è qui che le quattordici dimensioni del piano A e del piano B servono davvero: ognuna ha la sua curva, e la mappa complessiva nasce dal sovrapporsi delle curve.

Arrivo al punto verso cui tutto questo articolo sta spingendo: il team di agenti che fa DevSecOps in modo agile.

L’immagine è semplice e potente. Un gruppo di agenti specializzati, ciascuno responsabile di una porzione del ciclo: chi raccoglie i requisiti, chi disegna l’architettura, chi scrive il codice, chi scrive i test, chi fa la review, chi gestisce la security, chi fa il deploy, chi monitora la produzione, chi propone refactoring sulla base delle metriche raccolte. Tra loro dialogano, ciascuno è osservabile, ciascuno è governato da policy, ciascuno ha un budget. Sopra di loro ci sono gli umani: non più individui che eseguono, ma architetti, coach, custodi, decisori finali nei punti di rischio.

Il metodo che regge questo scenario è agile, ma con una accentuazione retroattiva più forte: alta copertura di test, retrospettive frequenti (anche tra agenti), revisione continua, miglioramento incrementale del prompt, delle policy, delle metriche. Più che team Scrum siamo davanti a quello che alcuni chiamano team Squared: umani che fanno Scrum con agenti che fanno Scrum tra loro.

Cosa dice il mercato. Microsoft ha formalizzato il termine Agentic DevOps: “intelligent agents collaborate with you and with each other… handling bug fixes, small features, documentation, and more” [39]. IBM ha rilasciato Loop Genie, multi-agent assistant integrato in DevOps Loop con supporto MCP/Claude/Gemini/Ollama [40]. Infosys ha pubblicato il framework AgentOps come lifecycle management nativo per agenti, con guardrails specifici [13]. Il caso più rigoroso a livello accademico-operativo è KubeStellar Console, mantenuto da una Hive multi-agent con 74 workflow CI/CD, 32 nightly test suites, 91% code coverage, bug-to-fix in meno di 30 min H24. La tesi di Andy Anderson (IBM Research) è netta: “testing — the volume of test cases, the coverage thresholds, and the reliability of test execution — proved to be the single most important investment in the entire journey” [36].

E qui la sezione 6 torna come un’eco: uno scenario L5 si regge solo se la postura senior si è spostata. Senza senior formati come orchestratori, il team di agenti diventa un team senza coach, e un team senza coach — agentico o umano che sia — non scala.

La cosa più importante che ho capito mentre studiavo questo passaggio è che L5 non è la fine del professionista. È l’inizio di un nuovo tipo di professionista. Uno che programma orchestrazioni, che programma policy, che programma sistemi che programmano. Uno che ha bisogno, più che mai, di fondamentali solidi — perché senza fondamentali, l’orchestrazione diventa illusione.

In articoli precedenti come 2026-01 — Il quarto cerchio o nell’articolo più recente Il quarto cerchio e la custodia dell’umano ho introdotto la visione della AI come ulteriore componente rappresentato nella versione più semplificata da un diagramma di Venn (il cerchio) che si affianca e si interseca con gli altri tre cerchi che descrivono un ecosistema aziendale, persone, hardware e software.

Mi piace chiudere con un’immagine che, in questi giorni, è diventata per me il filo conduttore del libro che sto scrivendo.

Il Quarto Cerchio, l’anno scorso, era una linea sul piano. Una mancanza che chiedeva di essere nominata. Quest’anno è diventato un oggetto pieno: ha volume, perché contiene costi, persone, agenti, processi; ha tempo dentro lo spazio, perché cambia mentre lo guardi — il modello evolve, il prompt impara, la policy si aggiorna; ha tante proiezioni quante sono le dimensioni con cui lo si guarda — il professionista lo vede come strumento, il manager come maturità, il compliance officer come rischio, l’umanista come etica, il tech lead come effetto forbice.

La matematica avrebbe una parola per descriverlo: n-sfera. Un oggetto che vive in molte dimensioni e che, ridotto al piano, torna a essere un cerchio. È un’immagine che mi piace perché racconta una cosa profonda: la complessità del Quarto Cerchio è reale, ma il suo significato sa farsi semplice quando serve. Sa diventare cerchio. Sa farsi disegnare su una lavagna in cinque minuti, davanti a un board, e farsi capire.

Questo è il lavoro che ci aspetta: vivere nella sfera, raccontare con il cerchio. Misurare in n dimensioni, decidere in due. Custodire la complessità e offrire al lettore — al cliente, al collega, al board — un disegno che sappia dire molto con poco.

È il lavoro del Quarto Cerchio in produzione. E, in fondo, è il lavoro di sempre di chi fa architettura.

C’è una dimensione che è emersa solo negli ultimi mesi, ed è la ragione per cui questa mappa — pubblicata oggi — è già destinata a cambiare nel libro che ne nascerà. Te la racconto come la vedo adesso, sapendo che è ancora in fase di maturazione e di valutazione, e che probabilmente, quando avrò più dati dai team con cui lavoro, finirà spostata nel Piano A degli assi verticali insieme a costo, qualità, sicurezza, debito e osservabilità — perché di fatto è un’asse misurabile del sistema, non una lente di lettura.

La nomino così, provvisoriamente: Smart & Local Models — l’autonomia operativa del Quarto Cerchio.

L’idea è semplice ma porta conseguenze enormi. Negli ultimi due anni la conversazione sull’AI nello sviluppo software è stata dominata dal paradigma cloud-first, frontier-first: il modello più grande, quello più potente, quello che vive nei datacenter di tre hyperscaler americani, raggiunto via API a consumo. Ed è esattamente la traiettoria che ha generato le altre tredici dimensioni — il costo per token, la dipendenza dal listino, l’opacità del prompt, la sovranità messa in discussione, l’osservabilità da costruire da zero.

Ma sta succedendo qualcos’altro, in parallelo, e sta succedendo proprio sui nostri tavoli. Modelli più piccoli — gli SLM, Small Language Models, e i modelli locali — stanno diventando abbastanza bravi da fare il lavoro di sviluppo specifico per cui li addestriamo o li selezioniamo. Non qualsiasi lavoro. Quel lavoro lì. Lo Spring Boot dell’azienda. Il Python dell’analista. Il TypeScript del team frontend. Il COBOL del legacy che nessuno vuole più toccare ma che ancora fattura. Il principio sta cambiando: non serve più un cervello universale che sa tutto male; serve un artigiano specializzato che sa il tuo mestiere bene.

E con questo cambio di principio, cambia anche la postura infrastrutturale. Tornano sui tavoli — sui tavoli veri, intendo, quelli di legno o ikea su cui ognuno di noi lavora ogni giorno — macchine pensate per ospitare il modello. Workstation NVIDIA con GPU dedicate. PC custom Linux con tanta RAM (mezzo terabyte, un terabyte) e dischi NVMe grossi. Notebook Apple Silicon con la memoria unificata che permette ai modelli locali di lavorare in modi che due anni fa erano impensabili. Apple ha persino dato un nome alla cosa, Apple Intelligence, in cui una parte del lavoro succede sotto il vetro del dispositivo. Microsoft ha lanciato la categoria Copilot+ PC con NPU dedicate. NVIDIA ha messo ChatRTX sulle workstation. Lo stack open-source — Ollama, LM Studio, MLX, llama.cpp, vLLM — ha trasformato la possibilità di far girare un modello in locale in una cosa che fai con due comandi a terminale.

C’è qualcosa di poetico, in tutto questo. Dopo aver insegnato per anni che “tutto è cloud”, una parte della frontiera sta tornando alla scrivania. È un movimento che ha radici tecniche precise — efficienza dei modelli small, costo dell’inferenza cloud che inizia a pesare, latenza che conta nei workflow agentici, dato sensibile che non vuole uscire dal perimetro — ma è anche un movimento culturale: dice che la potenza dell’AI può vivere in un oggetto che tieni vicino, non solo in una nuvola lontana che paghi a contatore.

Perché questa è una dimensione e non un dettaglio tecnico? Perché tocca contemporaneamente tutte le altre. Cambia il costo (capex hardware una tantum vs opex token continuo). Cambia la qualità (modelli specializzati sul tuo contesto operativo battono modelli generalisti su task ristretti). Cambia il debito tecnico (il modello che usi è più stabile nel tempo, e il tuo codice ha un riferimento meno mobile).

Ma soprattutto cambia due cose insieme, in modo profondamente intrecciato.

La prima è il rapporto con il dato. Quando modello e codice vivono entrambi sulla mia macchina — o sul mio server, o sulla mia rete — il dato sensibile non esce mai dal perimetro. Il codice proprietario non viene mandato a un fornitore esterno per essere completato. Il dato del cliente non finisce dentro il prompt che esce verso il cloud. Il know-how aziendale non diventa, suo malgrado, materiale di training per qualcun altro. È un vantaggio enorme — soprattutto per chi lavora in settori regolati (sanità, finanza, difesa, PA), per chi sviluppa software proprietario di valore, per chi semplicemente vuole costruire senza esporre. È, in fondo, il ritorno al principio della casa con la porta chiusa: quello che succede dentro, resta dentro.

La seconda è speculare, e ne è la conseguenza diretta: se il modello vive nella mia casa, chi mi garantisce che il modello stesso non porti fuori informazioni? È una domanda nuova, e va presa molto seriamente. Un modello locale è un artefatto — un file binario di pesi neurali — che ho scaricato da qualche parte. Chi lo ha addestrato? Cosa potrebbe aver imparato a fare oltre quello che dichiara? Potrebbe contenere backdoor, esfiltrazione di dati cifrata nelle sue chiamate di rete, comportamenti latenti che si attivano solo in certi contesti? Questa non è fantascienza: è già una classe di rischio che la ricerca sta nominando con precisione — model supply chain attacks, trojaned LLMs, prompt injection persistenti nei pesi.

Detto altrimenti: risolvere la sovranità del dato apre il tema della sovranità del modello. E la risposta non è “torniamo al cloud”, ma “costruiamo una catena di certificazione e attestazione anche per i modelli locali” — come abbiamo fatto per il software open source con SBOM, firme, audit del codice sorgente. Servirà l’equivalente di SBOM per i modelli (MBOM, qualcuno lo sta chiamando), servirà la firma crittografica dei pesi rilasciati da chi li ha addestrati, servirà l’attestazione del comportamento in ambienti controllati prima del deployment, servirà la scansione runtime del traffico di rete che un modello locale genera — perché un modello che gira sulla mia macchina e fa chiamate verso l’esterno non dovrebbe poterlo fare senza che qualcuno se ne accorga.

Stiamo imparando, insomma, che anche il modello è codice, e come tutto il codice ha bisogno di una supply chain governata. Le piattaforme stanno cominciando a rispondere — Hugging Face ha introdotto firme e scansioni, NVIDIA ha pubblicato linee guida per il Model Risk Management, l’EU AI Office sta esplicitamente toccando il tema nelle bozze di guidance — ma la disciplina è giovane, e oggi rappresenta una delle aree di ricerca più attive del 2026.

Cambia, quindi, anche la sicurezza (nel doppio senso del termine: meno fuga di dato, più esigenza di verifica del modello). Cambia la sovranità (declinata su due piani, dato e artefatto). Cambia il debito tecnico (anche il modello entra nella tua filiera di artefatti da governare, come ogni libreria che usi). Cambia la postura culturale (il dev impara di nuovo a smanettare con i suoi strumenti, ma con responsabilità nuove: non solo “uso questo modello”, ma “so da dove viene, chi l’ha firmato, cosa fa quando gira”).

Non è una scelta binaria, però. Non è “cloud vs locale”. È un terzo paradigma che si sta costruendo, e che chiamerei ibrido stratificato: frontier model nel cloud per i task aperti, smart specialized local model sulla workstation per il lavoro quotidiano e ripetitivo, agenti che orchestrano l’uno e l’altro a seconda del task. È un’architettura a due velocità, dove l’umano sceglie quale velocità usare per cosa.

E in ognuno di questi tre piani — frontier cloud, smart specialized local, agenti orchestratori — il principio della catena di fiducia va costruito dove prima non c’era. Nel cloud lo abbiamo costruito attraverso contratti, certificazioni del fornitore e audit. Nel locale dobbiamo ancora inventarcelo del tutto. È un cantiere aperto, ed è anche per questo che la dimensione 12 di questa mappa è la dimensione più giovane: non perché conta meno, ma perché siamo ancora in mezzo al guado.

Cosa dice il mercato. Il principio del modello specifico per contesto trova fondamento accademico nel paper NVIDIA “Small Language Models are the Future of Agentic AI” (Belcak et al., 2025): “SLMs are sufficiently powerful, inherently more suitable, and necessarily more economical” per i task agentici, con riduzioni di costo 10×-30× su workload specializzati [43]. Microsoft conferma con i suoi Phi-3/Phi-4 — “surpasses similar-sized models and is on-par with models twice its size in mathematics and coding” — esplicitamente disegnati per workflow on-device [44]. Andrej Karpathy lo sintetizza così: “the future is many small models that you can run, audit, fine-tune, swap, and own” [45]. Sul fronte hardware, NVIDIA ha definito la categoria AI Workstation (RTX 6000 Ada, DGX Spark/Station da 1 petaFLOP desk-side), Microsoft la categoria Copilot+ PC con NPU ≥40 TOPS, Apple ha messo Apple Intelligence on-device con memoria unificata fino a 512GB su Mac Studio [46][47][48]. Sul fronte modelli, Mistral con Codestral (francese, open-weight, code-specialized) è l’alleato naturale di un posizionamento europeo sovrano, accanto a DeepSeek-Coder e Qwen-Coder dal mondo open [49][50]. Strumenti come Continue.dev + Ollama permettono già oggi di sostituire Copilot con modelli locali in VSCode, e una community come r/LocalLLaMA è il termometro di quanto velocemente questa traiettoria si stia consolidando [51]. Per il contesto italiano, l’infrastruttura Cineca Leonardo apre la possibilità di fine-tuning di modelli locali in chiave sovrana [52]. Sul versante della certificazione dei modelli locali, la disciplina sta nascendo proprio adesso: NVIDIA ha pubblicato un framework di Model Risk Management dichiarando che “just as software supply chain security became central in the 2020s, model supply chain security will define the late 2020s” [53]. Hugging Face ha integrato firme Sigstore e provenance SLSA per i modelli [54]. Il NIST ha codificato una tassonomia formale degli attacchi (model poisoning, backdoor injection, data exfiltration via outputs) nel documento NIST AI 100-2 E2025 [55]. OWASP ha pubblicato due liste complementari — AI/ML Top 10 e LLM Top 10 — che coprono insieme i rischi infrastrutturali e applicativi [56]. E l’articolo 55 dell’EU AI Act, con il Code of Practice for General-Purpose AI Models in consultazione, introduce obblighi di trasparenza sui dati di training e sul comportamento del modello che si applicheranno anche ai modelli destinati all’uso locale [57]. Stiamo assistendo, in tempo reale, alla nascita di una disciplina della supply chain dei modelli AI — è giovane, è frammentata, ma è già qui.

Una nota onesta: nominandola come dimensione 12 — invece che inserirla nel Piano A degli assi verticali dove logicamente apparterrebbe — sto dichiarando che la sto valutando in tempo reale. È una dimensione che ho visto emergere dai team con cui lavoro nelle ultime settimane, e che la letteratura sta nominando in modi ancora frammentati. Nel libro, quando avrò più dati e più casi, la riporterò probabilmente al Piano A, vicino al Costo, perché lì appartiene strutturalmente. Ma volevo che il pezzo, oggi, non uscisse senza di lei. Le dimensioni che stanno nascendo meritano di essere nominate anche quando sono ancora bambine.

---

Cosa porto via, cosa porto avanti

Cinque cose mi porto via da questo passaggio.

La prima è che non c’è un solo metro per il Quarto Cerchio. Ci sono quattordici dimensioni, raccolte in tre piani, e il valore di un’analisi sta nella capacità di integrare più dimensioni alla volta, non nella perfezione di una singola misura.

La seconda è che la maturità è una traiettoria, non una fotografia. La scala L0–L5 serve a orientarsi, ma il vero esercizio è disegnare il profilo della propria organizzazione e capire dove muoversi prima.

La terza è che la forbice esiste, e va affrontata. Non è change management. È un asse di assessment, con i suoi costi (lo sfrido), le sue metriche (la mappa delle posture), le sue leve (cultura, pair programming, riconoscimento del sapere senior come bene comune).

La quarta è che il professionista del software del futuro esiste già. Lo vedo nei team in cui lavoro: ha smesso di chiedersi “l’AI mi sostituirà?” e ha iniziato a chiedersi “come farò a custodire la qualità di quello che l’AI farà al posto mio?”. La risposta è il libro a cui sto lavorando.

La quinta — e forse la più importante — è un dato che vale come monito. Uno studio MIT del 2025 ha rilevato che il 95% dei pilot GenAI enterprise non genera ritorno misurabile, e solo il 5% scala in produzione, su un totale di 30-40 miliardi di dollari investiti [41]. Una survey su 3.000+ leader IBM ha confermato che “worker access to AI rose by 50% in 2025” ma “only 34% of companies use AI to deeply transform business”, mentre l’83% considera la sovereign AI importante per la pianificazione strategica [42]. La maturità reale è ancora rara. La buona notizia è che chi la costruisce oggi ha pochi anni di vantaggio sul mercato. La cattiva è che chi la rimanda non ha tempo da perdere.

Su exploras.cloud, nei prossimi mesi, condividerò i pezzi del viaggio: dopo i tre Ambassador, l’Ouverture sull’Atto III e il pezzo sulla custodia dell’umano, questa è la mappa di partenza del nuovo cammino. Su LinkedIn pubblicherò una versione più breve di questo testo come commento al Quarto Cerchio in produzione, seguita nei giorni successivi da una domanda al mio network: in quale postura vi riconoscete, e a che livello di maturità vi vedete? È una domanda che mi serve. È una domanda che — se vorrete rispondermi — entrerà nel libro.

Il Quarto Cerchio non è più una linea. È un oggetto vivente. E ha bisogno, oggi più che mai, di custodi consapevoli.

— Mauro Giuliano

---