La nuova esperienza di Copilot Studio può consumare Copilot Credits senza che te ne accorga

Una cosa che mi ha fatto preoccupare

Negli ultimi giorni stavo lavorando alla creazione di alcuni nuovi agenti in Copilot Studio e ho deciso di attivare la nuova esperienza introdotta da Microsoft.

A prima vista sembra semplicemente una revisione dell’interfaccia: grafica più moderna, percorso di creazione più lineare, un’esperienza di authoring molto più vicina a quella a cui ci ha abituato GitHub Copilot negli ultimi mesi. Niente di clamoroso, mi sono detto. Un restyling, come ce ne sono stati tanti altri in Microsoft 365 negli ultimi anni.

Poi mi sono fermato un attimo a guardare meglio la schermata iniziale.

Nuova esperienza di Copilot Studio

Le opzioni maggiormente in evidenza sono Agent e Workflow. Poco sopra, un badge piuttosto discreto: Uses Copilot Credits.

Il messaggio, tecnicamente, c’è. Non si può dire che Microsoft l’abbia nascosto. Ma è proprio la sua discrezione a preoccuparmi: in un’interfaccia pensata per essere il più possibile fluida e naturale, un badge di quattro parole rischia di essere semplicemente ignorato da chi non sa nemmeno cosa siano i Copilot Credits, né in che modo il proprio tenant li stia gestendo. E qui ho deciso di andare più a fondo, prima leggendo la documentazione, poi testando io stesso il comportamento della piattaforma.

Questo articolo racconta esattamente questo percorso: cosa ho scoperto, cosa ho verificato con test diretti, e quale strategia di governance ritengo oggi la più efficace per gestire questo cambiamento.

Non è soltanto una nuova interfaccia

La tentazione, guardando la schermata iniziale, è quella di archiviare tutto come un aggiornamento estetico. In realtà Microsoft ha introdotto una nuova modalità per creare agenti e workflow che utilizza un modello di consumo completamente diverso da quello a cui molti amministratori erano abituati.

Due comunicazioni sul Message Center raccontano bene la cronologia di questo cambiamento.

La prima, MC1446644, annuncia la disponibilità generale della nuova modalità di creazione a partire dal 3 agosto 2026. Il messaggio è chiaro: gli agenti creati con questa modalità utilizzano un modello di billing basato sui Copilot Credits, mentre gli agenti tradizionali e quelli pensati per estendere Microsoft 365 Copilot Chat mantengono i rispettivi modelli di licensing invariati. Viene anche specificato un dettaglio cruciale: per gli agenti creati prima del rilascio generale era previsto un periodo di tolleranza, ma dal 1° settembre 2026 anche questi hanno iniziato a consumare crediti a tutti gli effetti.

La seconda comunicazione, MC1461678, è proprio l’annuncio di quella scadenza: il billing per gli agenti creati con questa modalità, inclusi quelli nati durante la fase di anteprima, entra in vigore dal 1° settembre 2026.

Messe una accanto all’altra, queste due comunicazioni raccontano una storia precisa: un periodo di grazia pensato per permettere alle organizzazioni di adattarsi, seguito da un’attivazione del billing che riguarda anche ciò che era stato creato mesi prima, magari in fase sperimentale, magari dimenticato in un angolo di un ambiente Power Platform.

Non stiamo quindi parlando di un semplice redesign del designer. Stiamo parlando di una nuova modalità di sviluppo, più potente e più immediata, ma legata a un modello di consumo che deve essere monitorato con la stessa attenzione che riserviamo, ad esempio, a una sottoscrizione Azure a consumo.

Il percorso più naturale potrebbe non essere quello atteso

La situazione si fa ancora più interessante nel momento in cui si seleziona New agent.

Nel menu compaiono due possibilità. La prima, Agent, è quella più in evidenza, accompagnata dal badge Uses credits, e permette di creare un agente basato sulla nuova modalità. La seconda, Agent (Standard), consente di creare il classico agente conversazionale basato su topic e flussi predefiniti, lo stesso che conosciamo da anni.

Mettiamoci per un attimo nei panni di un maker che accede a Copilot Studio per la prima volta, magari dopo aver ricevuto una licenza M365 Copilot pochi giorni prima. Quale delle due opzioni sceglierà?

Nella grandissima maggioranza dei casi, la prima. Non perché conosca le differenze funzionali ed economiche tra le due modalità, ma perché è quella proposta in alto, quella con la grafica più curata, quella che sembra “il modo giusto e moderno” di procedere.

L’agente standard non è scomparso. È semplicemente diventato la seconda scelta, quella che richiede un passo consapevole in più. E in un’interfaccia progettata per ridurre l’attrito, ogni passo in più è un passo che una parte consistente degli utenti semplicemente non farà.

Non sono solo i Copilot Credits prepagati il problema, occhio al Pay-As-You-Go

Fin qui il ragionamento si è concentrato sul consumo di un pool di Copilot Credits prepagati, derivante dall’acquisto di licenze Copilot Studio. Ma c’è uno scenario che considero ancora più delicato, ed è quello dei tenant che utilizzano un modello di pagamento Pay-As-You-Go.

In quel caso non stiamo più parlando del consumo di una capacità già acquistata e quindi, in un certo senso, già “spesa” a prescindere. Stiamo parlando di un costo che matura in tempo reale, direttamente su una sottoscrizione Azure collegata. Un utente che crea, testa e sperimenta agenti con la nuova modalità, in un tenant configurato a consumo, sta generando una spesa reale e immediata, non semplicemente “consumando” una risorsa già pagata in anticipo.

Se già il consumo di un pool prepagato può passare inosservato, in uno scenario Pay-As-You-Go il rischio economico è oggettivamente più alto, perché non esiste nemmeno il “cuscinetto” rappresentato da una capacità fissa mensile. È una delle prime cose che, come amministratori, dovremmo verificare: capire se il tenant che stiamo gestendo si affida a crediti prepagati o a un modello a consumo, perché la severità del rischio cambia sensibilmente tra i due scenari.

Altra considerazione importante: la licenza personale non copre sempre l’utilizzo

C’è poi un aspetto che ho scoperto testando io stesso la piattaforma, e che considero il punto più insidioso di tutto il ragionamento.

Per gli agenti tradizionali (standard o Copilot Chat), se un utente con licenza Copilot Studio o M365 Copilot crea un agente e lo utilizza esclusivamente per sé, senza condividerlo con persone che non dispongono di una licenza Copilot, è la sua stessa licenza a coprire l’utilizzo. Non viene intaccato né un pool di crediti condiviso né un budget Pay-As-You-Go: è un uso individuale, coperto individualmente.

Con gli agenti creati tramite la nuova modalità, questo non è più vero. Anche un agente creato e utilizzato esclusivamente in un ambiente personale, da un singolo utente, senza alcuna condivisione, consuma comunque Copilot Credits dal pool del tenant.

Questo è esattamente ciò che ho verificato analizzando il consumo di un mio agente di test:

Dettaglio consumo di un agente per canale

L’agente si trovava nel mio ambiente personale ([Personal] Ambiente di Davide Bianchi), non era condiviso con nessuno, eppure il pannello di dettaglio del consumo mostra chiaramente crediti fatturati sia sul canale M365 Copilot che sul canale pva-studio (l’ambiente di authoring/test), per un totale interamente billato.

Il problema, quindi, non è solo “un utente che condivide un agente con troppe persone”. Il problema è più sottile: un utente crea un agente pensando magari di voler semplicemente provare qualcosa per sé, o volendo realizzare un agente standard ma finendo, per i motivi di interfaccia descritti sopra, nella nuova modalità, e senza rendersene conto consuma comunque crediti condivisi del tenant, anche se l’agente non lascia mai il suo ambiente personale.

Questo smonta l’assunzione più comune, ossia “se è solo per me, tanto la copre la mia licenza”, che vale per gli agenti tradizionali, ma non per quelli creati con questa nuova modalità.

Cosa ho verificato con test diretti

Oltre a leggere la documentazione, ho voluto verificare concretamente il comportamento della piattaforma in tre scenari che consideravo critici. Ecco cosa ho trovato.

Il consumo inizia già in fase di build e test, ed è tracciabile per canale

Il primo dubbio riguardava il momento in cui inizia effettivamente il consumo: solo in produzione, o già durante lo sviluppo?

La risposta è confermata: il consumo inizia già in fase di authoring. Nel pannello di dettaglio mostrato sopra si vede chiaramente come Power Platform tenga traccia del consumo per singolo canale, distinguendo ad esempio l’utilizzo generato dal canale pva-studio (cioè l’ambiente di sviluppo/test all’interno di Copilot Studio) da quello generato da un canale di distribuzione come M365 Copilot o Teams.

Questo è un dato molto utile dal punto di vista della governance: non solo sappiamo che il consumo può partire dalla fase di test, ma abbiamo anche uno strumento nativo per distinguere quanto di quel consumo derivi dallo sviluppo e quanto dall’utilizzo reale in un canale pubblicato.

Bloccare un agente funziona, e permette di intervenire senza eliminarlo

Il secondo test riguardava l’efficacia del blocco di un agente. Qui la buona notizia: il blocco funziona correttamente. Un agente bloccato non è più in grado di rispondere alle richieste, come mostra chiaramente il messaggio di errore restituito in fase di test:

Agente bloccato non risponde più

“You don’t have access to this agent. Ask the agent’s owner or your admin for access, then try again.”

Questo è un risultato importante, perché significa che il blocco è una misura di contenimento realmente utilizzabile: consente di disattivare rapidamente un agente non conforme senza doverlo eliminare definitivamente, lasciando quindi la possibilità di analizzarlo con calma, contattare l’owner, e decidere in un secondo momento se riattivarlo o rimuoverlo.

Un agente in draft, mai pubblicato, può essere solo eliminato

Il terzo elemento riguarda gli agenti che restano in bozza e non vengono mai pubblicati. Qui la situazione è più delicata: un agente in questo stato non può essere gestito centralmente, né tramite Power Platform Admin Center né tramite Agent 365. L’unica azione disponibile è l’eliminazione diretta.

Questo significa che, se un utente crea un agente, lo lascia in draft e non lo pubblica mai, l’unico modo per intervenire su di esso è cancellarlo, senza la possibilità intermedia di bloccarlo o sospenderlo temporaneamente come invece accade per gli agenti pubblicati.

Un problema che ho già visto complicarsi su tenant di grandi dimensioni

Non voglio soffermarmi su un singolo caso specifico, ma posso dire con sicurezza, per esperienza diretta su più tenant enterprise, che quando Copilot Studio è disponibile e non governato in alcun modo, la situazione tende a complicarsi rapidamente man mano che il tenant cresce di dimensioni.

Più utenti hanno accesso a Copilot Studio, più aumenta il numero di agenti creati in autonomia, in ambienti personali o condivisi, spesso senza un vero processo di approvazione alle spalle. Con l’introduzione della nuova modalità basata su GitHub Copilot, questo fenomeno (già di per sé difficile da tenere sotto controllo in tenant di grandi dimensioni) si somma a un modello di consumo che, come visto, può attivarsi anche per un semplice utilizzo personale e non condiviso.

Il risultato è che la superficie da monitorare si allarga, mentre gli strumenti di controllo disponibili restano, ad oggi, parziali.

La soluzione più intelligente: non rincorrere gli agenti, governare la capacità

Dopo aver ragionato a lungo su script di inventario, alert e processi di revisione manuale, sono arrivato a una conclusione diversa da quella con cui ero partito: rincorrere gli agenti uno per uno è la strategia meno efficiente possibile. Ogni script di enumerazione, ogni notifica, ogni processo di approvazione interviene sempre un passo dopo che il consumo è già avvenuto.

La soluzione più intelligente, a mio avviso, non è tecnica nel senso di “scrivere un’automazione che elimini gli agenti sbagliati”. È molto più a monte, ed è di natura di governance: decidere chi può utilizzare Copilot Studio, e soprattutto quanta capacità economica è effettivamente disponibile a chi lo utilizza al di fuori di un perimetro controllato.

Allocare i Copilot Credits per environment, non a livello di tenant

In Power Platform Admin Center, sotto Licensing > Copilot Studio > Manage Copilot Credits, un amministratore può allocare i Copilot Credits ambiente per ambiente, invece di lasciarli semplicemente in un pool condiviso a livello di tenant. Questo vale sia per la capacità prepagata sia per i piani Pay-As-You-Go, che possono essere associati a un billing plan collegato a specifici ambienti.

Per ogni ambiente è possibile impostare un numero preciso di crediti allocati, e soprattutto configurare cosa succede quando quella soglia viene raggiunta, attraverso l’opzione Draw from the available capacity in my tenant:

se abilitata, l’ambiente esaurisce prima la propria allocazione e poi continua ad attingere dalla capacità residua non allocata del tenant;
se disabilitata, l’ambiente è vincolato esclusivamente alla propria allocazione e, una volta esaurita, non può consumare oltre.

Questo secondo comportamento è esattamente la leva che stavo cercando: se creo un ambiente dedicato, come per esempio un “Sandbox Copilot Studio” autorizzato, e poi alloco lì la capacità che voglio effettivamente mettere a disposizione, posso poi impostare tutti gli altri ambienti, incluso il Default Environment, con un’allocazione pari a zero e il draw dal tenant disattivato. Il risultato pratico è che un agente creato al di fuori del perimetro autorizzato non ha semplicemente crediti da consumare, e quindi non funziona, senza che nessuno debba intervenire manualmente per bloccarlo.

È lo stesso principio con cui gestiamo da anni le quote di storage o le sottoscrizioni Azure: non si rincorre chi supera il limite, si stabilisce a monte quanto quel perimetro può effettivamente spendere.

Governare anche chi può accedere a Copilot Studio

L’allocazione della capacità è la parte economica del ragionamento, ma va affiancata da un secondo livello di controllo: chi può effettivamente creare agenti. Se un gruppo ristretto di maker autorizzati ha accesso a Copilot Studio, tramite ruoli di sicurezza sull’ambiente, security group dedicati o, più semplicemente, restringendo chi ha accesso agli ambienti con capacità assegnata, il problema si ridimensiona ulteriormente, perché il numero di persone che possono anche solo tentare di creare un agente con la nuova modalità si riduce drasticamente.

Combinando i due livelli, la logica complessiva diventa:

Ambiente "Copilot Studio Sandbox"
  → Maker autorizzati: gruppo ristretto
  → Copilot Credits allocati: quantità definita e monitorata
  → Draw from tenant capacity: abilitato solo se necessario

Tutti gli altri ambienti (incluso il Default Environment)
  → Copilot Credits allocati: 0
  → Draw from tenant capacity: disabilitato
  → Risultato: nuovi agenti creati fuori dal perimetro non hanno crediti da consumare

Non si tratta di impedire tecnicamente la creazione dell’agente. L’interfaccia continuerà a proporla, come abbiamo visto, ma di rendere quell’agente economicamente inerte se creato fuori dal perimetro autorizzato. Un maker può anche creare un agente nel Default Environment, ma se quell’ambiente non ha crediti allocati e non può attingere al pool del tenant, l’agente semplicemente non sarà utilizzabile.

Cosa resta comunque utile fare

Anche adottando questa strategia come misura primaria, non eliminerei del tutto le altre attenzioni discusse finora. Continuerei comunque a:

monitorare periodicamente il consumo per ambiente, che in Power Platform Admin Center è già disponibile con storico giornaliero fino a tre mesi e mensile fino a dodici, per verificare che l’allocazione scelta sia coerente con l’uso reale;
utilizzare il blocco per gli agenti già pubblicati che, nonostante tutto, si rivelassero non autorizzati o problematici, visto che ho verificato che funziona correttamente;
comunicare agli utenti perché esiste questo perimetro, evitando che la restrizione venga percepita come un blocco ingiustificato all’innovazione piuttosto che come una misura di controllo dei costi.

La differenza sostanziale è che questi diventano controlli di secondo livello, di verifica e affinamento, mentre il vero argine al rischio economico si trova a monte, nell’allocazione della capacità.

In sintesi

La nuova esperienza di Copilot Studio rappresenta un passo avanti importante dal punto di vista dell’usabilità. Creare agenti è diventato più semplice e più accessibile, indipendentemente dalla seniority tecnica di chi lo fa. Proprio per questo, però, il cambio di modello di consumo che si porta dietro rischia di passare inosservato, ed è più insidioso di quanto sembri a prima vista.

Non parliamo solo di un pool di crediti prepagati che si consuma più velocemente del previsto: nei tenant configurati a consumo, il rischio si traduce in una spesa reale e immediata. E non parliamo nemmeno solo di condivisione incontrollata: come ho verificato direttamente, anche un utilizzo personale e mai condiviso di un agente creato con questa modalità consuma crediti del tenant, smontando l’idea diffusa che “se è solo per me, ci pensa la mia licenza”.

Le buone notizie sono due: il blocco di un agente funziona davvero, ed è tracciabile con precisione da dove arrivi il consumo, canale per canale. Ma la notizia più importante è che non serve inseguire ogni singolo agente per governare questo rischio: allocando i Copilot Credits per environment e restringendo la capacità economica disponibile fuori da un perimetro controllato, il problema si affronta a monte, in modo strutturale, invece che rincorrendo i sintomi uno alla volta.

Il consiglio con cui chiudo è lo stesso con cui ho iniziato a scrivere questo articolo: verificate quanti agenti sono già stati creati attraverso la nuova esperienza nei vostri tenant, capite se il modello di billing è a crediti prepagati o Pay-As-You-Go, e valutate se sia il momento di ridisegnare l’allocazione della capacità per ambiente, invece di limitarvi a inseguire ogni nuovo agente che compare.