Con l’annuncio di Azure SRE Agent e dei nuovi Azure Agent Units, Microsoft ha introdotto la sesta metrica di consumo per le sue tecnologie AI. Non è un dettaglio tecnico: è il segnale che il governo delle licenze AI è diventato uno degli argomenti più complessi – e più costosi – che le organizzazioni si trovano a gestire oggi
Quando si parla di licenze Microsoft per l’AI, il rischio più comune non è pagare troppo per un singolo prodotto. È non rendersi conto di quante valute diverse si stanno usando in contemporanea, e di come ciascuna risponda a logiche proprie di consumo, previsione e ottimizzazione.
Con l’annuncio in disponibilità generale dell’Azure SRE Agent, a marzo 2026, Microsoft ha formalizzato una nuova unità di misura: gli Azure Agent Units. È la sesta metrica principale con cui le organizzazioni sono chiamate a licenziare tecnologie AI sulla piattaforma Microsoft e probabilmente non sarà l’ultima.
Questo articolo le mappa tutte, spiega come si relazionano tra loro e offre alcune considerazioni su cosa significa gestirle insieme.
Le metriche che Microsoft utilizza oggi per misurare e fatturare il consumo di tecnologie AI non sono intercambiabili, né progettate per coesistere in modo intuitivo. Rispondono a logiche diverse: alcune sono per utente, altre per interazione, altre ancora per capacità computazionale riservata o per secondi di esecuzione di un agente. La cosa più importante da capire è che coesistono all’interno dello stesso ecosistema e spesso all’interno dello stesso contratto.
1. Licenza per utente (per-seat)
È il modello più familiare. Microsoft 365 Copilot si acquista come add-on a 30 dollari/utente/mese, oppure incluso in Microsoft 365 E7 a 99 dollari insieme a E5, Entra Suite e Agent 365.
La licenza copre l’uso di Copilot nelle app M365 e la creazione di agenti in Copilot Studio. L’esecuzione degli agenti, però, consuma sempre Copilot Credits a pagamento – anche per chi ha E7. E se si usano modelli personalizzati via Azure AI Foundry, i costi di inferenza vengono fatturati separatamente su Azure, al di fuori dei Credits. È proprio questo il momento in cui la semplicità della licenza per utente finisce e inizia il mondo dei consumi variabili.
2. Copilot Credits
Dal 1° settembre 2025, la valuta operativa per l’esecuzione degli agenti in Copilot Studio sono i Copilot Credits. Ogni operazione consuma un numero variabile di credits a seconda del tipo – una risposta classica, una risposta generativa, un’azione autonoma, un grounding sul Microsoft Graph hanno tariffe diverse e si sommano all’interno della stessa interazione.
Chi ha una licenza M365 Copilot beneficia di un’esenzione parziale: le risposte classiche, generative e il grounding su Microsoft Graph non consumano credits quando l’utente interagisce tramite Teams, SharePoint o Copilot Chat. Questa esenzione però non è illimitata: i trigger autonomi consumano sempre credits, anche per questi utenti. E i modelli personalizzati via Azure AI Foundry restano completamente fuori dal contatore dei Credits, fatturati direttamente su Azure a parte.
I Credits si acquistano in tre modi. Il pay-as-you-go tramite Azure non richiede impegno anticipato e si paga 0,01 dollari per credit consumato: è la modalità più adatta per pilota e picchi stagionali. I pack mensili prepagati da 25.000 credits a 200 dollari offrono un costo prevedibile, ma i credits inutilizzati scadono a fine mese senza possibilità di riporto, meglio non sovrastimare il fabbisogno. Il Pre-Purchase Plan annuale (P3), infine, permette di acquistare in anticipo un pool di Copilot Credit Commit Units to ease the sconti a scaglioni crescenti fino al 20%, ed è pensato per organizzazioni con volumi stabili e prevedibili.
Vale la pena notare che i Copilot Credits coprono anche le funzionalità di AI Builder integrate in Power Apps e Power Automate – con una progressiva sostituzione degli AI Builder Credits tradizionali, che verranno completamente ritirati a novembre 2026.
3. AI Builder Credits (in dismissione)
Gli AI Builder Credits hanno rappresentato per anni la metrica per le funzionalità di intelligenza artificiale su Power Platform: elaborazione di documenti, riconoscimento testo, modelli predittivi. Dal novembre 2025 sono in una fase di transizione verso i Copilot Credits.
I credits “seeded” – quelli inclusi nelle licenze premium come Power Apps Premium o Power Automate Premium – restano disponibili solo per chi li aveva già prima del 1° novembre 2025: le licenze acquistate dopo quella data non li includono più. In ogni caso, tutti i credits seeded verranno rimossi definitivamente il 1° novembre 2026. Per i clienti esistenti con add-on AI Builder, il rinnovo è ancora possibile, ma anch’esso solo fino a novembre 2026, dopodiché non sarà più acquistabile né rinnovabile. Per i nuovi clienti, l’acquisto di add-on AI Builder non è già più possibile: la strada è quella dei Copilot Credits.
Per chi ha ancora credits attivi, il sistema funziona a cascata: si consumano prima gli AI Builder Credits disponibili, poi i Copilot Credits. Se nessuno dei due è disponibile, le funzionalità si bloccano.
4. Security Compute Units (SCU)
Microsoft Security Copilot vive in un mondo a sé. La sua metrica è la Security Compute Unit (SCU), senza alcuna relazione con i Copilot Credits o le altre valute dell’ecosistema. Gli SCU misurano la capacità computazionale necessaria a eseguire le analisi di sicurezza: ogni query, ogni indagine su un alert, ogni azione eseguita da un agente dentro Defender, Entra, Intune o Purview consuma SCU in misura proporzionale alla complessità dell’operazione.
Il modello di acquisto standalone è doppio. La capacità provisionata – la modalità principale – costa 4 dollari per SCU all’ora e viene fatturata mensilmente sulla base delle SCU deployate, indipendentemente dall’utilizzo effettivo. La capacità di overage, pensata per i picchi imprevisti, costa 6 dollari per SCU all’ora e si paga solo per il consumo reale.
Chi è su Microsoft 365 E5 ha un percorso alternativo, annunciato a Ignite 2025 e in rollout automatico su tutti i tenant E5 tra aprile e giugno 2026: Security Copilot è incluso con un’allocazione di 400 SCU al mese per ogni 1.000 licenze pagate, fino a un massimo di 10.000 SCU mensili.
Vale la pena notare che questo modello è più efficiente di quello provisionato: con la capacità standalone si paga per le SCU deployate ogni ora, indipendentemente da quante se ne usano davvero. Con il modello E5 inclusion, invece, si scala solo ciò che viene effettivamente consumato, ora per ora. Il rovescio della medaglia è che il pool mensile non si accumula: le SCU non utilizzate entro fine mese scadono senza riporto al mese successivo.
Superata la soglia, le richieste vengono bloccate; l’opzione di overage a $6/SCU è pianificata per il futuro, con 30 giorni di preavviso prima dell’attivazione. Lo stesso beneficio si estende automaticamente a chi adotta E7, che include E5 e porta con sé la stessa allocazione SCU.
5. Token e PTU — Microsoft Foundry (Azure OpenAI)
Chi accede ai modelli AI direttamente tramite API – per integrazioni custom, applicazioni proprietarie, soluzioni RAG, agenti sviluppati in codice – si muove nel perimetro di Microsoft Foundry, il brand con cui è stata unificata la piattaforma Azure OpenAI. Qui le metriche principali sono due, con logiche completamente diverse.
Il modello Standard (On-Demand) è pay-as-you-go per token: si paga separatamente per i token di input (il prompt, il contesto, la cronologia) e per i token di output (la risposta del modello). Le tariffe variano per modello – GPT-4o ha un costo diverso da GPT-4o mini, che ha un costo diverso da o1 o dai modelli di embedding. Non c’è impegno, non c’è capacità riservata: si paga esattamente quello che si usa.
TheProvisioned Throughput Units (PTU) rispondono a una logica opposta: si prenota una capacità computazionale espressa in PTU, e si paga quella capacità a tariffa oraria indipendentemente dall’utilizzo effettivo. In cambio si ottengono latenza prevedibile, throughput garantito e protezione dai rate limit. Le PTU sono tecnicamente model-independent – la quota può essere usata per deployare qualsiasi modello supportato da Microsoft nella regione – ma ogni modello richiede un numero diverso di PTU per lo stesso livello di throughput, quindi non sono del tutto intercambiabili. Sono disponibili con impegni mensili o annuali, con sconti crescenti per chi si vincola più a lungo.
Vale la pena menzionare una terza modalità spesso trascurata: il Batch API. Permette di inviare grandi volumi di richieste non urgenti che vengono elaborate entro 24 ore, con uno sconto del 50% rispetto al prezzo Standard. È la scelta naturale per elaborazioni offline, classificazioni massive o qualsiasi workload che non richieda risposta in tempo reale.
6. Azure Agent Units (AAU) — la novità
Con la disponibilità generale di Azure SRE Agent, annunciata a fine marzo 2026, Microsoft ha introdotto una sesta metrica: gli Azure Agent Units. L’AAU standardizza la misurazione del lavoro agentico per tutti gli agenti precostruiti ospitati su Azure – una categoria distinta dagli agenti costruiti su Copilot Studio e da quelli sviluppati tramite API su Foundry.
La struttura di billing è a doppio componente. Ogni agente attivo viene addebitato a 4 AAU all’ora come costo fisso di monitoraggio continuo (always-on flow): è il prezzo per tenere l’agente acceso e in ascolto, indipendentemente dal fatto che stia elaborando qualcosa. Quando l’agente lavora attivamente – per investigare un incidente, rispondere a un prompt, eseguire una remediation – scatta il componente variabile: dal 15 aprile 2026 l’active flow non si misura più in secondi di esecuzione ma in token LLM consumati, con tassi per milione di token che variano a seconda del modello configurato (OpenAI, Anthropic o altri). Il tempo in cui l’agente è in attesa di risposta umana non viene conteggiato.
Questa metrica non è intercambiabile con i Copilot Credits. Un’organizzazione che usa sia Copilot Studio che Azure SRE Agent si trova a gestire due valute parallele, ciascuna con le proprie regole di consumo e i propri strumenti di monitoraggio.
La moltiplicazione delle metriche ha creato un problema pratico per le organizzazioni che adottano più tecnologie AI in contemporanea. Microsoft ha risposto con il Microsoft Agent Pre-Purchase Plan (P3), lanciato il 27 novembre 2025 e aggiornato a febbraio 2026 con l’aggiunta di Microsoft Fabric e GitHub.
Il piano funziona come un portafoglio prepagato annuale: si acquistano Agent Commit Units (ACU) in uno di tre pool predefiniti – 20.000, 100.000 o 500.000 ACU – con sconti crescenti al crescere della taglia. Le ACU si consumano automaticamente per coprire l’utilizzo di Copilot Credits (Copilot Studio, Dynamics 365), PTU e token su Microsoft Foundry, Microsoft Fabric. This,GitHub. Il meccanismo è diretto: se Copilot Studio genera un costo retail di 100 dollari, vengono scalate 100 ACU dal pool. Non serve riallocare manualmente i budget tra le diverse metriche.
Vale però notare i limiti del piano: le SCU di Security Copilot e gli AAU di Azure SRE Agent restano fuori da questo perimetro, fatturati separatamente. Il P3 non è quindi un portafoglio davvero universale – copre la parte Copilot Studio + Foundry, ma non l’intera superficie AI Microsoft.
Il vantaggio principale rimane la semplificazione finanziaria per chi usa Copilot Studio e Foundry insieme: un unico impegno contrattuale, un unico pool da monitorare, una prevedibilità di spesa maggiore rispetto al pay-as-you-go distribuito. Il vincolo è che richiede una stima affidabile del consumo atteso e, come vedremo, questa è proprio la parte più difficile.
La vera complessità non sta in nessuna di queste metriche presa singolarmente. Sta nel fatto che coesistono, e che un’organizzazione di media dimensione che adotta l’ecosistema AI Microsoft si trova tipicamente a gestirne tre o quattro in parallelo: licenze per utente per chi usa Copilot nelle app M365, Copilot Credits per gli agenti sviluppati su Copilot Studio, PTU o token per le integrazioni custom su Foundry, SCU per il team di sicurezza che usa Security Copilot.
Ogni metrica ha il suo ciclo di fatturazione, i suoi strumenti di monitoraggio, la sua logica di reset mensile o di billing orario. Alcune si azzerano il primo del mese, altre no. Alcune si possono accumulare in un pool condiviso a livello di tenant, altre sono vincolate all’environment o alla subscription Azure specifica. Alcune hanno meccanismi di overage automatico, altre bloccano il servizio quando si esaurisce la capacità.
Il rischio concreto non è tanto il costo in sé, quanto la difficoltà di stimare in anticipo il consumo aggregato quando si ha a che fare con tecnologie il cui utilizzo reale si stabilizza solo nei primi 6-12 mesi di adozione. Un commitment costruito su proiezioni ottimistiche – tipicamente quelle che i team commerciali tendono a presentare – può trasformarsi in un onere difficile da gestire se l’adozione non segue la curva attesa. E con strumenti come il P3, dove cancellazioni ed exchange non sono supportati e il rinnovo è automatico per default, questo rischio è strutturale, non contingente.
Vale la pena allargare lo sguardo. La frammentazione delle metriche di licenza AI non è un’esclusiva Microsoft: è un fenomeno di settore e SAP ne è forse l’esempio più istruttivo.
A metà 2025 SAP ha ristrutturato i suoi pacchetti cloud ERP rimuovendo le funzionalità AI avanzate dal bundle RISE with SAP: Joule e gli strumenti di AI generativa sono diventati add-on opzionali a pagamento separato. Chi usa SAP S/4HANA Cloud si trova oggi a gestire contemporaneamente la licenza base ERP, gli AI Units per le funzionalità AI generative avanzate e i BTP cloud credits per le soluzioni AI custom costruite sulla Business Technology Platform. Tre metriche diverse per tre livelli dello stesso stack – un pattern identico a quello Microsoft.
Il parallelo è diretto: sia SAP che Microsoft stanno monetizzando l’AI attraverso layer sovrapposti di consumo – uno per la piattaforma, uno per le applicazioni, uno per gli agenti o le automazioni specifiche. La differenza è che SAP opera in un ecosistema in cui i contratti hanno cicli più lunghi e le variazioni di consumo sono storicamente più prevedibili. Microsoft, con la transizione verso MCA e la moltiplicazione delle metriche AI, sta comprimendo questi cicli e aumentando la variabilità.
Il segnale che emerge da entrambi i casi è lo stesso: la gestione delle licenze AI non è più un’attività amministrativa che si delega al momento del rinnovo contrattuale. È una funzione operativa permanente, che richiede monitoraggio continuo, capacità di correlazione tra metriche eterogenee e una governance finanziaria agile – la stessa logica che il framework FinOps applica ai costi cloud, estesa ora al consumo AI.
Chi non si organizza in questa direzione rischia di scoprire a fine anno che ha pagato per una capacità che non ha usato, o – scenario ugualmente problematico – che ha consumato senza saperlo risorse che non aveva preventivato. In entrambi i casi, l’impatto non è solo finanziario: è sulla credibilità dei piani di adozione AI rispetto al business.
Non esiste una risposta universale alla domanda su quale metrica scegliere o su come dimensionare il consumo. Dipende da quali prodotti si adottano, da quale sia la traiettoria di crescita dell’utilizzo, da come è strutturata la governance interna dei costi IT.
Quello che si può dire con certezza è che la complessità è prevedibile. Le sei metriche sono conosciute, documentate, con logiche di consumo analizzabili prima di prendere impegni. Gli strumenti per stimare il consumo atteso esistono – Microsoft stessa offre calcolatori per Copilot Studio e per Azure OpenAI, anche se le stime che restituiscono tendono a essere ottimistiche rispetto all’adozione reale nei primi mesi.
Il lavoro più utile che un’organizzazione può fare oggi è costruire una baseline di consumo su ciò che già usa, isolare le componenti variabili (in primo luogo quelle legate agli agenti AI), e strutturare qualsiasi impegno pluriennale in modo che le variabili restino variabili – e non vengano incorporate nella base fissa del commitment.
Su questo fronte, piattaforme ITAM come Flexera One stanno estendendo il loro perimetro tradizionale verso il governo della spesa AI. Lo fanno attraverso moduli distinti che coprono parti diverse del problema: Cloud Cost Optimization per normalizzare e correlare i costi dei servizi AI su Azure (token, PTU, Azure OpenAI); SaaS Management per tracciare utilizzo e spesa delle licenze Microsoft 365 Copilot per utente; ITAM per la gestione dei contratti e delle posizioni di licenza.
L’obiettivo è applicare al consumo AI la stessa logica di visibilità e ottimizzazione che il framework FinOps applica ai costi cloud: tracciare l’utilizzo dopo il deployment, collegare la spesa agli outcome di business, evitare che la complessità delle metriche nasconda sprechi o sovra-commitment. Non è un problema risolto – la stessa Flexera segnala nel suo AI Pulse Report 2026 che la difficoltà di prevedere pattern di utilizzo imprevedibili è tra le prime preoccupazioni dei team che gestiscono workload AI – ma è la direzione in cui si sta muovendo la disciplina.
Non è un tema solo tecnico. È un tema di governo della spesa IT in un contesto in cui i vendor hanno tutto l’interesse a far crescere il commitment, e in cui la complessità delle metriche può facilmente mascherare opportunità di ottimizzazione che vale la pena cogliere prima di firmare.
At WEGG – The Impact Factory seguiamo questi temi da vicino, come consulenti ITAM e FinOps, e lavoriamo con strumenti come Flexera One per portare visibilità concreta sul consumo AI dei nostri clienti. Se il tema ti riguarda, contattaci per approfondire.
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
