Gli agenti AI creano lavoro: come governare consumi e capacità nel Service Desk

Il segnale: l’AI si compra e si governa a consumo

L’aggiornamento del 3 agosto 2026 della documentazione Microsoft Copilot Studio rende visibile un passaggio che riguarda direttamente i responsabili di Service Desk. La capacità degli agenti viene espressa in Copilot Credits e il consumo dipende dal disegno dell’agente, dal volume delle interazioni e dalle funzioni utilizzate. Una risposta generativa, un’azione, il grounding sul tenant, un flusso e il reasoning non pesano nello stesso modo.

La conseguenza manageriale è più importante del listino. L’automazione agentica non è un costo fisso da assegnare una volta per tutte: è una risorsa variabile che cresce con le decisioni prese dall’agente. Microsoft indica inoltre soglie di enforcement: in determinate configurazioni, l’esaurimento della capacità può bloccare nuovi flussi o disabilitare gli agenti successivi. Il budget diventa quindi anche una dipendenza di continuità del servizio.

Per l’ITSM cambia la domanda da porre. Non basta sapere quanti utenti possono usare il canale. Bisogna prevedere quante risposte, ricerche, azioni e iterazioni può produrre ogni bisogno e quanto di quel consumo conduce davvero a un risultato.

Nasce una domanda sintetica, invisibile alla coda

Il ticket tradizionale nasce da una persona o da un evento tecnico ben riconoscibile. Un agente autonomo può invece attivarsi su una nuova e-mail, un’anomalia, una scadenza o il cambiamento di un record; può consultare più fonti, richiamare altri agenti e aprire azioni senza che qualcuno abbia compilato un modulo. È domanda sintetica: lavoro richiesto dai sistemi ai sistemi.

Questa domanda non è necessariamente negativa. Può prevenire incidenti, aggiornare conoscenza e risolvere attività ripetitive prima che raggiungano il supporto. Ma può anche moltiplicarsi senza che i cruscotti ITSM la vedano. Un singolo evento può generare verifiche ridondanti, tentativi ripetuti, notifiche, casi tecnici ed escalation. Il numero dei ticket umani diminuisce mentre il carico complessivo aumenta.

La prima regola è quindi rendere ogni esecuzione attribuibile. L’agente deve dichiarare servizio, intento, evento di origine, versione, strumenti invocati, consumo e outcome. Senza questa catena, Finance vede una fattura aggregata, Operations vede traffico anomalo e il Service Owner non sa quale decisione lo abbia prodotto.

Il costo cresce per catene, non per conversazioni

Una metrica come costo medio per chat presuppone che la chat sia l’unità di lavoro. Nell’orchestrazione agentica non è più vero. Una richiesta può produrre una risposta, tre interrogazioni, due azioni, un ragionamento avanzato, un controllo e un retry. La documentazione Microsoft mostra che le diverse componenti hanno pesi distinti e che una singola interazione può sommare più tipologie di consumo.

Il rischio più serio è il loop economicamente silenzioso. L’agente non riceve la conferma attesa, interpreta l’assenza come errore, ripete l’azione e genera ulteriore lavoro a valle. Oppure due agenti si scambiano aggiornamenti che riattivano reciprocamente lo stesso processo. Anche quando ogni chiamata costa poco, la moltiplicazione può diventare materiale e saturare capacità o API.

Per questo il controllo deve stare nel disegno: identificatore idempotente per impedire duplicati, limite massimo di passi, timeout, budget per esecuzione, backoff sui retry e circuit breaker quando costo o anomalie superano la soglia. Non sono dettagli da sviluppatori: sono clausole operative del servizio digitale.

Dal budget mensile al budget per outcome

Un tetto mensile protegge la spesa, ma interviene troppo tardi e non distingue valore da spreco. La FinOps Foundation suggerisce di collegare il costo tecnologico a unità di business: non soltanto costo per token o richiesta, ma costo per assistenza, azione o caso risolto. Nel supporto la misura utile è il costo per outcome verificato.

Il numeratore deve includere crediti o token, integrazioni, osservabilità, supervisione umana, gestione delle eccezioni e lavoro generato a valle. Il denominatore conta soltanto esiti confermati: accesso ripristinato, software installato, richiesta completata senza riapertura, knowledge aggiornata e utilizzabile. Una risposta elegante non è un outcome; un’azione eseguita senza verifica non lo è ancora.

È utile assegnare un budget unitario diverso per intento. Una consultazione semplice deve fermarsi presto se non trova una fonte affidabile. Un incidente critico può sostenere più ragionamento e controlli. Una modifica con rischio elevato richiede approvazione, non un budget più largo. Il limite economico diventa così parte della policy di autonomia.

Capacity management per una forza lavoro digitale

Se la capacità esaurita può fermare agenti e flussi, il capacity management deve includere anche la forza lavoro digitale. Servono una previsione basata su volumi reali, scenari di picco, riserva per eventi critici e priorità tra servizi. Microsoft mette a disposizione un estimatore che separa conoscenza, azioni e flussi, raccomanda scenari di volume e il confronto tra consumo stimato e reale.

La priorità non può essere first come, first served. In caso di pressione, l’agente che prepara un report non dovrebbe consumare la stessa riserva necessaria per sbloccare identità o ripristinare un servizio. Pool distinti, quote per ambiente e degradazione controllata permettono di conservare le funzioni essenziali. Il fallback deve essere progettato: risposta deterministica, creazione del ticket, trasferimento umano o sospensione sicura.

La review settimanale dovrebbe unire quattro viste: domanda umana, domanda sintetica, consumo e outcome. Le anomalie più utili non sono soltanto gli aumenti di spesa, ma i rapporti che peggiorano: più azioni per caso risolto, più retry per intento, più costo senza riduzione delle riaperture.

Un patto operativo tra Service Management, Engineering e FinOps

La domanda sintetica non appartiene a un solo team. Il Service Owner definisce outcome e priorità; Engineering rende osservabili esecuzioni e limiti; FinOps collega consumo e valore; Security stabilisce permessi e condizioni di arresto; il fornitore deve esporre dati sufficienti per attribuzione, previsione e audit.

Prima di scalare un agente, chiederei cinque evidenze: costo massimo per esecuzione, outcome verificabile, comportamento in caso di capacità esaurita, prova di idempotenza e proprietario autorizzato a fermarlo. Aggiungerei una soglia di apprendimento: se il costo unitario o il tasso di eccezione peggiorano oltre il limite, l’autonomia si riduce automaticamente e il caso torna sotto controllo umano.

La maturità non consiste nel far lavorare gli agenti senza persone. Consiste nel sapere quale domanda creano, quale capacità assorbono e quale risultato restituiscono. Nel Service Desk agentico il budget non è un allegato finanziario: è un meccanismo di affidabilità. Governare il consumo significa proteggere insieme costo, continuità e valore del servizio.

• Attribuire ogni esecuzione a evento, servizio, versione, consumo e outcome.
• Inserire idempotenza, limiti di passi, retry controllati e circuit breaker.
• Definire budget unitari diversi per intento e rischio.
• Riservare capacità agli outcome critici e progettare un fallback sicuro.
• Portare domanda sintetica e costo per outcome nelle service review.