Il TCO non è la bolletta dei token

Il primo errore di un business case AI è confondere il costo di inferenza con il total cost of ownership. Il materiale ufficiale AB-100 struttura il TCO su cinque cost driver: infrastructure (compute per l’inferenza, storage, rete, resilienza), development and integration (design dell’agente, orchestrazione, connector, autenticazione, testing), data quality and preparation (pulizia, labeling, grounding e indicizzazione, refresh, drift), expertise and staffing (architetti, ingegneri, SME, change management) e operations and licensing (monitoring, evaluation, incident response, consumo o sottoscrizione). Una seconda lettura aggiunge due voci che quasi nessuno mette a bilancio: i change management costs e i decommissioning costs, cioè ritirare modelli superati e migrare a una nuova architettura.

Le voci dimenticate sono quasi sempre le stesse quattro. Gli ambienti non di produzione: il ciclo di vita documentato per gli agenti impone versioni immutabili, tracing (in preview) ed evaluation (in preview) prima del publish, e ognuno di questi passaggi consuma token veri. I modelli fine-tuned, addebitati in tre modi distinti — training, hosting e inference — dove l’hosting è un costo orario per modello distribuito che, come dice la documentazione sui costi, “applies even if the model is unused”. La valutazione e il monitoring continui, che non finiscono al go-live. E il lavoro umano che resta: supervisione, escalation, revisione dei casi che l’agente non chiude.

Il profilo di consumo decide il deployment type

Un carico usato a raffica per tre giorni al mese e fermo il resto — pensa alla chiusura contabile — ha un profilo di costo opposto a quello di un contact center a volume costante, e in Microsoft Foundry questa differenza si traduce in una scelta esplicita di deployment type. Per traffico variabile e bursty la doc indica Global Standard o Standard, cioè pay-per-token: nei ventisette giorni di calma non paghi capacità. Per volume alto e costante con bassa variabilità di latenza indica i tipi provisioned, che riservano capacità in provisioned throughput units (PTU): costo prevedibile, ma pagato anche quando la coda è vuota. Per lavori asincroni e non sensibili al tempo — riclassificare un archivio documentale — c’è Global Batch, con uno sconto del 50% rispetto a Global Standard, quota di token accodati separata e turnaround obiettivo di 24 ore, senza SLA real-time. Se il vincolo è di residenza dei dati, la variante Data Zone limita l’elaborazione a US, EU o APAC e va confrontata sul costo, non solo sulla compliance.

Attenzione a una confusione che l’esame sfrutta volentieri: il model router non è un deployment type. È un modello addestrato che si distribuisce come qualunque altro Foundry Model e instrada ogni prompt al modello più adatto, con routing mode Balanced (default), Cost o Quality e un model subset che limita i modelli ammessi. Serve a ridurre il costo unitario dentro una scelta di deployment già fatta; è supportato su Global Standard e Data Zone Standard. Il deployment type risponde a “come pago e dove elaboro”, il model router a “quale modello uso per questa richiesta”.

Costruire l’analisi ROI su un processo, non su una piattaforma

L’analisi ROI si costruisce su un solo processo, con un perimetro dichiarato. Definisci prima una baseline “no-AI” nel periodo di riferimento: volume dei task, average handle time, tasso di rework ed errori, backlog. Poi mappa il valore su tre leve misurabili — tempo risparmiato, aumento di qualità, capacità o throughput — e quantificale. In Microsoft Copilot Studio la funzionalità Savings stima il risparmio per run o per tool dalla pagina Analytics dell’agente; se l’amministratore disabilita il calcolo monetario, continui a tracciare il tempo e converti in valuta nel tuo modello.

Il confronto finale è banale nella forma e insidioso nelle assunzioni: Net Benefit = Annual Benefit meno Annual TCO, ROI percentuale = Net Benefit diviso Annual TCO, payback in mesi = costo una tantum diviso beneficio mensile netto. Aggiungi sempre bande di sensibilità — conservativa, attesa, ottimistica — facendo variare tasso di adozione, minuti risparmiati per run e labor rate. Un ROI presentato come numero singolo, senza banda e senza baseline, è la risposta sbagliata anche quando il numero è giusto.

Dove cambia la superficie, cambia il modello di costo

Le tre superfici hanno modelli di costo diversi e vanno confrontate su questo, non sulle funzionalità. I declarative agent di Microsoft 365 Copilot sono ospitati da Microsoft 365 Copilot e non generano costi di hosting aggiuntivi; i custom engine agent girano su orchestratore e modelli tuoi, quindi si portano dietro l’hosting su Azure. Per un utente senza licenza Microsoft 365 Copilot, un agente basato solo su istruzioni o su grounding pubblico non produce addebiti, mentre l’accesso a dati condivisi del tenant genera usage-based billing misurato in Copilot Credits. Sui SharePoint agent in pay-as-you-go il conto è esplicito: 2 messaggi per una generative answer più 10 per il tenant graph grounding, dodici messaggi per un singolo prompt complesso — mentre l’uso interattivo da parte di utenti Copilot licenziati è incluso.

Su questo punto l’esame non chiede prezzi né listini: ti chiede di selezionare i criteri e di scegliere l’opzione difendibile dato un vincolo. Riconoscere che un carico intermittente non giustifica capacità riservata, che l’hosting di un modello fine-tuned corre anche a zero traffico, e che evaluation e monitoring sono costo operativo ricorrente e non spesa di progetto, vale più di qualunque stima puntuale.