Exploras

Il quarto cerchio fattura. E adesso come lo misuro?

Nel precedente articolo abbiamo preso atto che il quarto cerchio è entrato nel ciclo di produzione SDLC: consuma token, apre pull request, introduce rischi, produce valore, richiede governance. Abbiamo proposto una mappa a quindici dimensioni organizzate in tre piani — assi verticali misurabili, assi normativi e umani, lenti di prospettiva — per leggere lo stesso fenomeno con occhi diversi.

Da una mappa possiamo ottenere delle funzioni di misura, operando delle scelte e nel tentativo di ridurre la complessità scegliendo quali tra le 15 dimensioni impiegare. Ogni decisore e amministratore aziendale, indipendentemente dalla posizione gerarchica occupata in azienda, oggi giorno ha davanti una domanda: ok, e adesso come lo misuro nel mio processo?

Ho introdotto il quarto cerchio come sinonimo qualificante la figura di un particolare contesto di impiego della Intelligenza Artificiale quello come quarto componente di un ecosistema aziendale che nella sua forma più semplifica rappresento con diagrammi di Vien, (semplificando ulteriormente dei cerchi). Inoltre provo personalmente un profondo fastidio a chiamare intelligenti degli algoritmi commerciali che imitano l’intelligenza pur non essendo coscienti di sé.

In questo articolo introduciamo a titolo di esempio tre workflow di misurazione, ognuno con la sua formula, ognuno agganciato a specifiche dimensioni dell’ipersfera. Poi, per ciascuno, guardiamo cosa sta scrivendo il resto del mondo — perché il pattern “domanda = funzione” sta emergendo simultaneamente in almeno quattro filoni indipendenti; senza ancora fornire una visione di insieme.
Sempre in una ottica di estrema semplificazione adotteremo funzioni somma e quindi parleremo di addendi che contribuiscono a determinare la somma.

Parte I — Le tre bussole

Ogni workflow risponde a una domanda operativa. Ogni componente della formula è un addendo misurabile. Ogni addendo mappa una o più dimensioni dell’ipersfera. Le formule non servono a calcolare un numero esatto: servono a scomporre il problema in parti che qualcuno, nell’organizzazione, deve poter analizzare, misurare, presidiare, migliorare.

WF-COST — Quanto mi costa (o quanto risparmio con) l’AI nel mio SDLC?

$C_{SDLC\_AI} = C_{accesso} + C_{consumo} + C_{umano} + C_{governance} + C_{rischio}$

Addendi

Addendo	Cosa misura	Dimensioni dell’ipersfera
$C_{accesso}$​	Licenze e seat AI: Copilot, agenti, piattaforme abilitanti	Costo
$C_{consumo}$​	Token input + token output + runtime agente + servizi accessori	Costo · Osservabilità
$C_{umano}$​	Ore uomo per ruolo SDLC × fattore AI (il fattore cambia con la maturità)	Costo · Ruoli · Adozione
$C_{governance}$​	Audit, policy, secret management, controlli compliance EU AI Act	Compliance · Sicurezza
$C_{rischio}$​	Debito tecnico atteso + costo remediation incidenti AI-attributi	Debito · Qualità · Sicurezza

La formula base della componente $C_{consumo}$​ va intesa come

“costo workflow = accesso minimo + token input (context) + token output (risposta) + servizi accessori + runtime agente”.

Qui la estendiamo dal singolo tool al processo SDLC intero, aggiungendo le componenti che il livello token-only lascia fuori: le ore umane, la governance, il rischio.

Varianti per livello di maturità.

Per interpretare al meglio la formula si deve introdurre il livello di maturità nell’impiego IA nel SDLC (vedi articolo precedente).
Questo fatto porta ad interpretazioni diverse dei risultati riportati dalla formula stessa. Questo lo possiamo tradurre applicando dei pesi ai vari addendi (omessi per semplicità nella esposizione della formula).

La struttura della formula non cambia. Cambiano i pesi.

• L5 (team di agenti dotati di ciclo di lavoro orchestrato): $C_{umano}$​ scende, $C_{consumo}$​ sale, $C_{governance}$​ diventa una voce strutturale — ed è qui che la formula rivela il suo vero mestiere, distinguere un processo che usa l’AI da uno che la subisce.

• L1–L2 (AI assistita ad libitum, senza governance): $C_{umano}$​ resta alto perché il risparmio ore è marginale; $C_{rischio}$​ è alto perché il debito si accumula senza controllo; $C_{governance}$​ è basso solo perché non esiste ancora.

• L3–L4 (AI in pipeline, workflow definiti): $C_{consumo}$​ diventa prevedibile; $C_{governance}$​ cresce ma è ripagato da un $C_{rischio}$​ più contenuto.

WF-USE — Come impiego l’AI nel mio SDLC?

$I_{AI} = \sum_{f \in fasi} (P_f \times A_f \times R_f)$

dove per ogni fase DevOps (Plan, Code, Build, Test, Release, Deploy, Operate, Monitor):

Fattore	Cosa misura	Dimensioni dell’ipersfera
$P_f$	Postura AI nella fase: 0 = assente · 1 = assistita · 2 = in pipeline · 3 = agentica	Adozione effettiva
$A_f$	Attivazione reale: percentuale di attività della fase toccate da AI	Cultura · Ruoli
$R_f$	RACI-fit: l’AI è dove il RACI se la aspetta, o dove capita?	Governance · Ruoli

Il totale $I_{AI}$non è un voto. È una firma di processo. Due team con lo stesso $I_{AI}$possono avere distribuzioni radicalmente diverse per fase: uno può essere tutto AI in Code, l’altro tutto AI in Test. Il valore sta nel profilo, non nel numero.

Il fattore $R_f$ è l’aggancio esplicito ad una potenziale matrice RACI SDLC × fasi DevOps se il RACI dice che in Code l’AI è a supporto del Developer (R) e del Software Architect (C), ma nei dati vediamo l’AI comparire in Plan senza alcun ruolo assegnato, quel gap è misurabile e va misurato.

Varianti per maturità.

• L1 tende a produrre $I_{AI}$​ concentrati su una singola fase (di solito Code, il territorio dell’entusiasta), con $R_f$Rf​ basso perché l’AI è ovunque senza RACI.

• L5 produce $I_{AI}$distribuiti su tutte le fasi DevOps, con $R_f$Rf​ vicino a 1.

WF-RISK — Quanto valore netto sto generando con l’AI?

$V_{netto} = V_{generato} – (R_{qualità} + R_{sicurezza} + R_{compliance} + R_{sovranità})$

Componente	Cosa misura	Dimensioni dell’ipersfera
$V_{generato}$​	Feature, PR, servizi consegnati con AI × valore business unitario	Adozione · Qualità
$R_{qualità}$​	Difetti downstream attribuibili a codice AI: rollback, bug ratio, rework	Qualità · Debito
$R_{sicurezza}$​	Incidenti e vulnerabilità AI-related (GHAS, DAST, SAST)	Sicurezza
$R_{compliance}$​	Gap rispetto a EU AI Act post-Omnibus, ISO, NIS2	Compliance · Etica
$R_{sovranità}$​	Lock-in vendor + esposizione dati a modelli non locali	Sovranità

Tre note su questa formula.

• Primo: $V_{generato}$​ non è “ore risparmiate”. È valore business. La distinzione è importante ed è il motivo per cui una parte non trascurabile del mercato oggi si racconta un ROI che non esiste, come vedremo nel sotto-capitolo dedicato.

• Secondo: i rischi sono sottrattivi. Non sono un moltiplicatore, non sono un fattore correttivo. Sono valore che se ne va. Se un team consegna 100 di valore ma paga 30 di rework, 20 di remediation security, 10 di gap compliance e 15 di lock-in, il valore netto è 25. Non 100.

• Terzo: la formula funziona anche in negativo. Se $V_{netto} < 0$Vnetto​<0, la conversazione con il CFO cambia radicalmente.

Varianti per maturità.

Non cambia l’intensità del rischio: cambia il tipo. L1 è dominato da $R_{qualità}$​ (AI usata male, codice fragile). L3 da $R_{compliance}$​ (l’AI è nella pipeline ma la governance è indietro). L5 da $R_{sovranità}$​ (il team agentico orchestrato funziona, ma su quali modelli? in quali giurisdizioni? con quali dati?).

Parte II — Cosa ragiona il mondo

Cosa ragiona il mondo su WF-COST

Il mercato ha capito prima di tutto una cosa: il costo del token, da solo, non basta. Ci è arrivato per gradi, ed è utile ripercorrerli.

Il primo gradino è la precision economics di Deloitte, ripresa da René Antúnez in aprile 2026:“most organizations are still trying to make sense of AI costs using familiar terms like licenses, VM-hours, and static TCO frameworks. However GenAI operates on a different model, its costs are variable and continuously evolving”. La formula che propone è la cost-per-completion: [rene-ace.com]

$Cost/completion = \dfrac{T_{in} \times P_{in} + T_{out} \times P_{out}}{1.000.000}$

È — letteralmente — la stessa scomposizione del nostro $C_{consumo}$​

Il secondo gradino è NVIDIA con Rethinking AI TCO:“cost per token determines whether enterprises can profitably scale AI”. È un ragionamento infrastrutturale, denominatore vs numeratore, orientato al lato produzione. Utile ma parziale: risponde a“quanto costa produrre un token”, non a“quanto costa un processo SDLC che usa l’AI”. [blogs.nvidia.com]

Il salto arriva con la FinOps Foundation, che a giugno 2026 pubblica Token Economics: Managing AI Value in SaaS Model Token Costs. La raccomandazione operativa è netta:“implement unit cost metrics (cost per query, cost per user, cost per workflow) to make token spend legible to business stakeholders”. Il workflow, esplicitamente. Poche settimane dopo, StackPulsar formalizza il pattern con un nome che ha fatto rumore — tokenmaxxing — e con una tesi netta:“the unit of spend that the CFO actually cares about is the business process. None of those map cleanly to a model or a user. They map to a workflow”. [finops.org] [stackpulsar.com]

Il quarto gradino è la componente sottrattiva.
Rize, citando InformationWeek, propone il 40% rework discount su GitHub Copilot: gross 3 ore/settimana risparmiate diventano 1,8 ore nette. La formula è banale — $Net\_saving = Gross\_saving \times (1 – 0{,}40)$Net_saving=Gross_saving×(1−0,40) — ma il messaggio è esplosivo:“Deloitte’s State of AI report, enterprises spend 93% of their AI budget on implementation and only 7% on measurement. That imbalance explains why so many Copilot ROI claims fall apart at the team level”. [rize.io]

Chiude Keyhole Software con la sintesi che nessuno vorrebbe leggere: nel loro AI Software Development Costs 2026, il TCO effettivo è 4,2 volte il costo dei soli token, una volta contabilizzati infrastruttura, integrazione, ops e — soprattutto — human capital and organizational processes. [keyholesoftware.com]

Cosa ci portiamo a casa.
Il mondo sa che il costo del token non basta. Sa che serve il workflow. Sa che serve sottrarre il rework. Sa che il TCO reale è multiplo. Ma nessuno lo scrive come una somma unica agganciata a dimensioni misurabili del SDLC. La nostra $C_{SDLC\_AI}$​ non inventa: raccoglie, e mette in ordine.

Cosa ragiona il mondo su WF-USE

Qui la discussione è più matura e più densa.
Perché l’AI nel SDLC ha già i suoi framework di riferimento, che però l’AI stessa ha spinto in crisi.

Il punto di partenza obbligato è DORA 2025 — State of AI-assisted Software Development, pubblicato da Google Cloud in collaborazione con IT Revolution: il 90% degli sviluppatori usa AI al lavoro, media due ore al giorno.

Ma la scoperta forte del report non sono i numeri di adozione: è l’effetto “mirror and multiplier”. L’AI amplifica ciò che c’è già.“If you have strong processes and clear workflows, AI helps you move faster. But if your team already deals with messy handoffs, poor documentation, or shaky processes, AI won’t just smooth things over”. [dora.dev], [plandek.com] [plandek.com]

È esattamente il motivo per cui nel nostro $I_{AI}$IAI​ la postura $P_f$Pf​ da sola non basta. Servono anche $A_f$Af​ (attivazione reale) e $R_f$Rf​ (RACI-fit): perché la stessa postura, calata su due processi diversi, produce risultati opposti.

DORA 2025 aggiunge una quinta metrica alle quattro storiche: il rework rate. La lettura è chirurgica: dopo l’introduzione dell’AI, le altre quattro metriche tendono a migliorare quasi ovunque (più deploy, meno lead time), ma il rework rate rivela quando l’accelerazione sta lasciando dietro un’onda di correzioni. È l’aggancio empirico al nostro $R_{qualità}$Rqualitaˋ​ di WF-RISK, e vale come rinforzo a $R_f$Rf​ in WF-USE: se il RACI-fit è basso, il rework sale. [plandek.com]

Sul piano umano il riferimento è SPACE — Satisfaction, Performance, Activity, Communication, Efficiency — pubblicato da Nicole Forsgren e colleghi su ACM Queue nel 2021 e rivisitato in chiave AI nel 2026 su DZone:“AI coding tools boost commit metrics, but hide deeper issues”. SPACE misura correttamente le persone. Non misura però l’aggancio al processo SDLC formale, che nel nostro modello arriva via RACI. [gogloby.com], [dzone.com] [04 – SDLC-…aform_v0.2 | Word]

Il triangolo si chiude con il DX AI Measurement Framework, sviluppato con GitHub, Dropbox, Atlassian, Booking.com. Tre layer: Utilization, Impact, Cost. L’analisi su 400+ aziende dà un dato che vale mille slide di vendor marketing:“industry-wide adoption has reached 93%, but most organizations see only 5–15% gains in PR throughput”. Non i “2x, 10x” delle presentazioni. Cinque a quindici percento. [getdx.com], [getdx.com]

Il quadro si completa con due letture 2025-2026 che vale la pena tenere in una tabella comparata:

Fonte	Dato empirico	Aggancio al nostro modello
DX (2026)	Gain mediani 5-15% in PR throughput	Legittima $I_{AI}$IAI​ come firma di processo, non come voto
BCG State of GenAI across SDLC (dic. 2025)	Top decile >30% productivity, >25% quality; change management = principale barriera	Sostiene il peso di $A_f$Af​ (attivazione) e la dimensione Cultura [insights.bcg.com]
Exceeds AI (2026)	17,3% dei commit Copilot introduce issue; AI power user 4-10x più commit ma sono top performer che scelgono l’AI, non ne sono trasformati	Sostiene $R_f$Rf​ (l’AI dove serve, non ovunque) [blog.exceeds.ai]

Cosa ci portiamo a casa.

• SPACE misura le persone.
• DORA misura la pipeline (e ora anche il rework).
• DX misura l’adozione.
• BCG misura la maturità delle prassi.

Nessuno però tiene i tre livelli in un’unica firma di processo agganciata al RACI SDLC. Il nostro $I_{AI}$IAI​ è esattamente quel collante.

Cosa ragiona il mondo su WF-RISK

È il territorio più affollato e il più confuso. Perché “rischio” nell’AI vuol dire tutto: qualità del codice, sicurezza, compliance normativa, sovranità del dato, etica, reputazione. E ognuno lo misura nel proprio silo.

Il punto di partenza è brutale. Sigma Infosolutions lo chiama ROI Mirage:“most enterprises report that AI makes developers feel faster, yet fewer than a quarter can prove measurable ROI”. Il gap tra feeling faster e measurable ROI è il territorio in cui $V_{netto}$Vnetto​ opera. Se $V_{generato}$Vgenerato​ è misurato in ore risparmiate percepite, il numero è gonfio. Se è misurato in valore business consegnato, torna sobrio. [sigmainfo.net]

McKinsey nel suo State of AI 2025 offre la conferma empirica:“just 39% report EBIT impact at the enterprise level”. Meno di quattro su dieci. Il resto vive nel mirage. [mckinsey.com]

Sul rischio strutturato di maturità la referenza obbligata è Gartner AI Maturity Model — 5 livelli, 7 pilastri (strategia, dati, tecnologia, governance, talento, valore, prodotto). Il dato che vale il pezzo è questo:“only 20% of low-maturity organizations keep their AI projects operational for three years or more, compared to 45% of high-maturity organizations”. Otto low-maturity su dieci non arrivano al terzo anno. Il rischio, in $V_{netto}$Vnetto​, è massimo dove la maturità è minima. Le varianti L1→L5 delle nostre tre formule non sono un vezzo teorico: sono la conseguenza operativa di quel 20% vs 45%. [gartner.com], [puneetsinghal.com] [puneetsinghal.com]

McKinsey chiude il cerchio con la AI Trust Maturity Survey 2026, sviluppata tra dicembre 2025 e gennaio 2026 su circa 500 organizzazioni. Cinque dimensioni RAI: strategia, risk management, dati e tecnologia, governance, e — novità 2026 — agentic AI governance and controls. È l’esatta ragione per cui $R_{sovranità}$Rsovranitaˋ​ nella nostra formula pesa sempre di più mano a mano che si sale verso L5: perché il team agentico che funziona è anche quello che espone di più.“Organizations can no longer concern themselves only with AI systems saying the wrong thing; they must also contend with systems doing the wrong thing”. [mckinsey.com] [mckinsey.com]

E chiudiamo con la nota più politica del pezzo, che arriva — non a caso — dallo stesso team DORA.
A giugno 2026 pubblicano un insight dedicato al tokenmaxxing:“a new trend has emerged in software development: ‘tokenmaxxing’, where organizations track and reward raw AI token consumption via internal leaderboards to spur adoption. While this gamification can nudge AI-hesitant developers to experiment, treating token spend as a performance indicator is a dangerous trap”. [dora.dev]

Traduzione operativa: chi misura il consumo di token come KPI di successo, sta preparando il proprio $V_{netto}$Vnetto​ negativo. È il tipo di trappola che vale un cautionary tale, ed è il posto giusto per raccontarlo.

📦 Boxout · Il caso dei 47.000 dollari in 11 giorni

Novembre 2025. Due agenti LangChain, in produzione, entrano in un loop conversazionale che nessuno intercetta. Runano ininterrottamente per undici giorni. Il conto finale, riportato dall’analisi Zylos Research 2026: 47.000 dollari in fee API. È uno dei numerosi episodi che ha portato la community a formalizzare che“an unconstrained agent solving a software engineering task can cost $5–8 per task in API fees alone” e che gli agenti fanno“3–10x more LLM calls than simple chatbots”. [zylos.ai], [zylos.ai]

Nel modello WF-RISK questo caso pesa contemporaneamente su tre addendi: $R_{qualità}$Rqualitaˋ​ (loop di ragionamento non validato), $R_{sicurezza}$Rsicurezza​ (nessun budget-control), $R_{sovranità}$Rsovranitaˋ​ (dati che escono dal perimetro ad ogni chiamata). E riduce a zero, anzi a negativo, il $V_{generato}$Vgenerato​ di quel workflow.

Il messaggio non è “non usare agenti”. È: misurateli come somma.

Cosa ci portiamo a casa.
Il mondo misura il rischio in silo: Sigma vede la percezione, Gartner la maturità, McKinsey la governance agentic, DORA il tokenmaxxing.
Il nostro $V_{netto}$Vnetto​ li tratta come addendi di una sola sottrazione.
E rende visibile un fatto che altrimenti resta implicito: il rischio non è un costo separato. È valore che se ne va.

Cosa porto via, cosa porto avanti (takeaway)

Tre take-away per chiudere.

1. Il mondo sta convergendo sul workflow come unità di misura.
FinOps Foundation lo raccomanda esplicitamente, StackPulsar lo formalizza sotto l’etichetta tokenmaxxing — nel senso critico del termine. Il nostro contributo è agganciare il workflow alle dimensioni dell’ipersfera, non lasciarlo come pura unità di attribuzione contabile. [finops.org] [stackpulsar.com]

2. Le formule non servono a calcolare, servono a scomporre.
Ogni addendo è una domanda. Ogni domanda è una dimensione. Ogni dimensione è una responsabilità.
Se il tuo $C_{governance}$​ è vuoto, non è perché non lo paghi: è perché non sai chi lo paga.
Se il tuo $R_{sovranità}$​ è vuoto, non è perché non c’è: è perché non l’hai ancora guardato in faccia.

3. La maturità cambia i pesi, non la formula.
Da L1 a L5, la struttura resta la stessa — cambiano i coefficienti.
Ed è qui che la Gartner AI Maturity incontra il Quarto Cerchio: non due modelli concorrenti, ma due sezioni della stessa ipersfera.
Una guarda alle organizzazioni, l’altra al ciclo di vita del software. Insieme, danno la profondità che nessuna delle due, da sola, riesce a produrre. [puneetsinghal.com] [exploras.cloud]

Il quarto cerchio fattura. Adesso sappiamo scomporre la fattura in addendi. Non è la fine del lavoro: è finalmente l’inizio.

Note e riferimenti