Buy, extend, build: le domande vanno poste in quest’ordine
La scelta di approvvigionamento di un componente AI determina costo, time-to-value, rischio, scalabilità e sostenibilità della soluzione nel tempo. Il Cloud Adoption Framework la riduce a una prima domanda secca: un SaaS agent già pronto soddisfa i requisiti funzionali? Se sì, si adotta e la progettazione finisce lì. Gli agenti pronti sono quelli che Microsoft distribuisce dentro i propri prodotti — gli agenti in Microsoft 365 Copilot come App Builder, Workflows e Researcher, i GitHub Copilot agents, i Microsoft Fabric data agents, gli agenti di Dynamics 365, quelli di Security Copilot. Costano poco in ingegneria, ma la personalizzazione è limitata.
Solo quando nessun SaaS agent copre il caso d’uso si apre il secondo bivio, quello fra extend e build. Extend significa far adottare a una piattaforma esistente la logica interna dell’organizzazione: declarative agent, API plugin, Copilot connector e knowledge source sull’estensibilità di Microsoft 365 Copilot, oppure agenti low-code in Microsoft Copilot Studio con i suoi connettori pronti e i guardrail di responsible AI integrati. Build significa Microsoft Foundry: un prompt agent dichiarativo, un hosted agent con codice e framework propri dentro un runtime gestito dal Microsoft Foundry Agents service, o all’estremo modelli su GPU e container in IaaS, quando servono isolamento e controllo totali sullo stack.
I criteri sono espliciti. Si costruisce quando la capacità AI è il vantaggio competitivo, quando le soluzioni pronte non reggono i vincoli regolamentari, quando la sensibilità del dato impone controllo interno pieno e il team ha davvero competenza di AI engineering. Si compra quando il processo è standardizzato, la maturità AI interna è bassa e il time-to-value conta più della personalizzazione — accettando lock-in e feature gap. Si estende quando il modello di base funziona già ma va adattato con conoscenza di dominio, connettori e grounding data.
Il TCO ha cinque domini, e uno tradisce
L’analisi va condotta su cinque domini di costo: infrastruttura (compute di inferenza, storage, rete, resilienza), sviluppo e integrazione, preparazione e qualità del dato, competenze, e operazioni continuative. Nella tabella di confronto ufficiale c’è una riga contro-intuitiva che l’esame ama: la preparazione del dato è alta sia per build sia per extend. Estendere non esonera dal lavoro su grounding, indicizzazione, retriever e monitoraggio del drift — sposta solo il costo di runtime, non quello del dato.
Sul lato licenze, la distinzione operativa è fra chi ospita cosa. Un declarative agent è ospitato da Microsoft 365 Copilot e non genera costi di hosting aggiuntivi; un custom engine agent gira sul vostro orchestratore e sui vostri modelli, quindi si porta dietro i costi di Microsoft Foundry, Azure App Service o Azure Bot Service. Per gli utenti senza licenza add-on, l’accesso ad agenti che toccano dati condivisi del tenant (SharePoint, Copilot connector) è fatturato a consumo in Copilot Credits tramite Copilot Studio, mentre gli agenti basati su sole istruzioni o grounding su siti pubblici non generano addebito. Sul lato Foundry, il modello fine-tuned è la trappola classica: si paga il training, l’inferenza e l’hosting orario finché il deployment esiste, anche se nessuno lo chiama. In fase preview, l’attribuzione dei costi a livello di progetto usa un tag project per il chargeback fra business unit.
Il model router: una leva di costo che è anche una leva di qualità
Il model router è un modello di machine learning addestrato — non un LLM — che analizza ogni prompt in tempo reale e lo instrada al modello più adatto fra quelli del pool. Si distribuisce come qualunque altro modello Foundry e presenta un endpoint unico: l’applicazione non cambia quando il pool evolve. La leva che l’architetto imposta non è una regola if-then, ma due impostazioni. La routing mode — Balanced come default, Cost per volumi alti e budget stretto, Quality per output critici — governa il compromesso costo/qualità. Il model subset dichiara quali modelli possono partecipare, ed è il vero cancello di conformità: i modelli nuovi non entrano finché non li aggiungete esplicitamente. Un subset di almeno due modelli è necessario, perché il failover automatico ricade sul subset stesso.
Due vincoli architetturali da ricordare. La finestra di contesto effettiva è quella del modello più piccolo del pool, quindi un prompt lungo va gestito riducendo il contesto o restringendo il subset ai modelli capienti. E il campo model della risposta dichiara sempre chi ha servito la richiesta: è il segnale di osservabilità primario, da loggare. Sul piano di governance, il router onora la stessa policy predefinita Foundry model deployments should only use approved models, applicata al subset in fase di deployment su portale, REST API, CLI e template ARM; definizioni aggiuntive specifiche per il router (regioni, logging) sono in public preview.
Non confondere routing mode e deployment type
È la distinzione che l’esame verifica più spesso in questo obiettivo. Il deployment type risponde a una domanda diversa: dove viene elaborata la richiesta e come la si paga. Global Standard elabora in qualunque regione Azure a consumo; Data Zone Standard resta dentro la data zone US, EU o APAC; Standard resta nella singola regione; le varianti Provisioned riservano capacità in PTU per latenza prevedibile; Global Batch e Data Zone Batch trattano lavori asincroni; il tipo Developer serve solo a valutare modelli fine-tuned, ha vita di 24 ore e nessuna garanzia di SLA o di residenza. Il model router supporta Global Standard e Data Zone Standard.
Tradotto in scenario: se il vincolo è “i dati non devono uscire dal confine UE”, la risposta è Data Zone Standard, non Cost. Se il vincolo è “la spesa esplode perché classificazioni banali e analisi complesse vanno allo stesso modello di frontiera”, la risposta è il router in Balanced, non un cambio di deployment type. Il pattern ibrido raccomandato usa entrambi: router come percorso di default, deployment diretto dove serve lo stesso identico modello a ogni richiesta. Da tenere separata, infine, la scelta del modello in Copilot Studio, che è un’altra superficie con i suoi tag Deep, Auto e General e i suoi modelli experimental non adatti alla produzione.