Sei fasi, due ritmi diversi
Il Cloud Adoption Framework for Azure descrive l’adozione dell’AI in sei fasi: Strategy, Plan, Ready, Govern, Secure, Manage. L’errore più comune è leggerle come una cascata che si percorre una volta sola. La pagina Secure AI (/azure/cloud-adoption-framework/ai/secure) chiarisce che Govern, Secure e Manage sono processi continui da iterare regolarmente, mentre Strategy, Plan e Ready si rivisitano quando serve. Come architetto stai progettando una macchina con due ritmi: uno di impostazione e uno permanente.
In Strategy si identificano i casi d’uso partendo dai problemi di business, non dalla tecnologia. Ogni caso viene classificato come individual work (migliora il lavoro delle persone dentro gli strumenti esistenti) oppure business automation (cambia il modo in cui l’organizzazione opera), e si valuta se serve AI generativa, non deterministica, o AI non generativa, deterministica. Segue la scelta tecnologica fra quattro modelli di adozione — Copilot pronti all’uso, sviluppo SaaS low-code, sviluppo PaaS gestito, infrastruttura Azure — guidata dal Microsoft AI decision tree e pesata su quattro fattori: capabilities, dati disponibili, competenze richieste, costo. Chiudono la fase la responsible AI strategy e la data strategy.
In Plan si misura la maturità con un framework a quattro livelli che incrocia competenze e data readiness, si acquisiscono skill, si ottengono gli accessi e le licenze, si priorizzano i casi d’uso e si costruisce un proof of concept. La guida raccomanda di partire da progetti interni, non rivolti al cliente, per limitare il rischio, e di aggiungere dal 20 al 30 per cento di contingenza alle stime.
Ready è la fase in cui un architetto disegna confini. Management group separati per i workload internet-facing e per quelli solo interni, policy applicate per management group, e risorse AI collocate nelle subscription di workload — le application landing zone — invece che nelle subscription di piattaforma. Questa scelta non è estetica: mette i workload team in condizione di deployare senza attendere il platform team, ereditando comunque le policy. Govern, Secure e Manage trasformano poi le decisioni in controlli: Azure Policy e Microsoft Purview per l’enforcement, Azure Resource Graph e Microsoft Defender for Cloud per costruire l’inventario degli asset AI, deployment authority delegata ai workload team dentro confini di governance espliciti, framework operativi distinti — MLOps per il machine learning tradizionale, GenAIOps per i carichi generativi — e un ambiente di sandbox tenuto separato da dev, test e produzione.
Chi compone l’AI Center of Excellence e dove si colloca
L’AI Center of Excellence è un team interno di esperti che evita l’adozione frammentata e non governata. Il Cloud Adoption Framework lo costruisce in cinque mosse. Primo, si assicura la executive sponsorship: senza budget e autorità il CoE non può imporre standard, quindi servono un comitato di indirizzo con leader di business e IT e accesso diretto ai decisori. Secondo, si nomina un AI CoE leader come punto di contatto unico e responsabile dell’allineamento strategico. Terzo, si assembla un team multidisciplinare: leader di business che individuano i casi d’uso e valutano l’efficacia dei modelli, ed esperti tecnici che coprono dati, progettazione, training e selezione dei modelli, con figure di AI governance, AI security e AI operations.
Il quarto passo è quello che l’esame ama: la collocazione organizzativa. L’AI arriva accanto o dopo altre tecnologie e poggia su infrastruttura cloud, dati e governance già esistenti, quindi di norma si innesta su team esistenti invece di nascere isolata. Se l’organizzazione ha già un Cloud Center of Excellence, la raccomandazione è integrarvi competenze e pratiche AI; il modulo di training indica anche il gruppo Data o Enterprise Architecture come sede plausibile. Un team AI standalone si giustifica solo se i team attuali non sono in grado di sostenere l’adozione o se esistono rischi critici.
Le responsabilità sono definite in modo esplicito: definire la strategia AI, sviluppare competenze, guidare i progetti pilota, definire e far rispettare gli standard, creare processi di intake e prioritizzazione, produrre asset riusabili, misurare e riportare i risultati. La gestione operativa dei servizi AI è invece dichiarata opzionale — un dettaglio che distingue chi ha letto la fonte da chi immagina il CoE come un team di delivery permanente.
Il CoE evolve: da controllo centralizzato a advisory
Il quinto passo definisce l’operating model, ed è il punto che l’esame verifica volentieri. All’inizio del percorso un modello centralizzato conviene, perché consolida competenze e pratiche fondanti e accelera l’adozione. Con la maturità il CoE deve passare a un approccio advisory: il modello centralizzato garantisce controllo e coerenza, quello advisory garantisce flessibilità. Il modulo di training descrive la progressione in tre stadi — centralizzato, ibrido, advisory — dove nella fase ibrida il CoE mantiene standard e framework mentre product e platform team iniziano a prendersi la titolarità.
Il passaggio non è una decisione di calendario ma una risposta a segnali: ritardi nelle approvazioni, colli di bottiglia di conoscenza perché gli esperti del CoE non riescono a servire tutti i team, attrito crescente fra product team e CoE che discutono priorità invece di consegnare valore. La transizione è possibile solo a una condizione: aver prima incorporato la governance AI nelle operazioni di piattaforma. Si trasferisce la delivery ai platform team, che applicano governance coerente e deployment affidabili su tutti i workload, si distribuisce l’expertise nei product team e nei team abilitanti, e il CoE si concentra su guidance e policy invece che sul controllo diretto.
Considera un gruppo manifatturiero con un CCoE maturo, un vincolo di compliance che impone tracciabilità su ogni modello in produzione e sei business unit che hanno già avviato agenti in autonomia. La risposta non è centralizzare la delivery: è collocare l’AI CoE dentro il CCoE, spostare l’enforcement su Azure Policy e sull’inventario degli asset gestito dal platform team, e lasciare al CoE intake, standard e revisione. Il CoE che resta gatekeeper produce l’anti-pattern opposto a quello che teme: sovracentralizzazione e colli di bottiglia da un lato, shadow AI dall’altro.
Attenzione infine a non confondere i piani. La responsible AI definisce principi e standard di equità, trasparenza e accountability; la security protegge risorse, dati e canali; la governance stabilisce chi decide, con quali policy e con quali confini; la compliance verifica l’aderenza a requisiti normativi esterni. Le domande d’esame le mescolano di proposito, e nomineranno spesso il Microsoft Responsible AI Standard come riferimento di principio, non come controllo tecnico.