AI Center of Excellence vs Distribuito: Guida 2026

Se guidi la Strategia di Gruppo, l'ufficio del CIO o la funzione di trasformazione in un'azienda multi-business-unit — un gruppo marketplace tipo Ricardo + IAZI + Homegate, un gruppo multi-verticale come Enel o Eni, oppure qualsiasi azienda da 2.000 a 20.000 dipendenti con tre o più P&L — quella riunione l'hai già fatta. Una parte vuole un AI center of excellence centrale. L'altra vuole che ogni business unit gestisca autonomamente la propria capability AI. Entrambe citano lo stesso deck McKinsey. Nessuna delle due ha torto, ed è esattamente questo il problema.

Questa guida sostiene che il dibattito AI center of excellence vs modello distribuito è un falso binario, illustra cosa ciascun modello effettivamente presidia e descrive l'architettura Hub-and-Spoke su cui la maggior parte delle aziende serie finisce per convergere — indipendentemente dal punto di partenza.

Il dibattito CoE vs Distribuito è un falso binario

La questione viene posta come una scelta: costruiamo un AI center of excellence centrale che gestisca l'AI per l'intero gruppo, oppure federiamo la capability così che ogni business unit lavori sulla propria roadmap? Formulato così, il dibattito è irrisolvibile, perché entrambe le posizioni difendono qualcosa di reale.

Il fronte pro-CoE difende economie di scala, baseline di sicurezza e riuso dei pattern. Hanno visto tre BU firmare tre contratti con tre fornitori di modelli, costruire tre eval harness e rilasciare tre versioni leggermente diverse dello stesso workflow di fraud detection. Vogliono fermare lo spreco. Hanno ragione.

Il fronte pro-distribuito difende il contesto di dominio, la velocità di delivery e l'accountability sul P&L della BU. Hanno visto un team centrale scrivere un documento di 60 pagine "Standard AI di Gruppo" che nessuno nella BU operativa ha tempo di leggere, mentre un product manager junior in uno dei verticali rilascia un assistente funzionante in tre settimane con una carta di credito e ChatGPT Enterprise. Vogliono preservare quella velocità. Hanno ragione anche loro.

La risposta onesta su cui finisce quasi ogni azienda seria — IBM, JPMorgan, BMW e la maggior parte dei gruppi mid-cap pubblicamente documentati — è Hub-and-Spoke. Un AI CoE centrale presidia la piattaforma, gli standard, la libreria di pattern riutilizzabili e il coordinamento cross-BU. I practitioner AI embedded nelle BU presidiano contesto di dominio, deployment customer-facing e delivery sui risultati di business. Il lavoro interessante non è scegliere uno dei due fronti. È decidere, tipo di workflow per tipo di workflow, dove tracciare la linea di centralizzazione.

Tracciala bene e ottieni compounding: ogni pattern rilasciato in una BU diventa un asset riutilizzabile per le altre. Tracciala male in una delle due direzioni e ottieni il peggio dei due mondi — un CoE collo di bottiglia, BU isolate e una libreria di pattern che nessuno cura.

Cosa presidia davvero un AI Center of Excellence

Un AI center of excellence ben dimensionato non è "il team che fa l'AI". È il team che presidia le condizioni perché l'AI possa essere fatta bene, ripetutamente, attraverso le business unit. Concretamente, si articola in cinque domini.

1. Il layer di piattaforma

È il pavimento infrastrutturale duro. Un CoE serio presidia:

• Un LLM gateway — un unico entry point gestito per tutte le chiamate ai modelli (OpenAI, Anthropic, Mistral, Llama, in-house). Gestione centralizzata delle chiavi, rate limiting, attribuzione dei costi per BU, fallback dei modelli e audit logging.
• Infrastruttura di retrieval — uno stack di vector store condiviso, pipeline di ingestion dei documenti, standard di chunking, selezione del modello di embedding e lo scaffolding di eval per testare la qualità del retrieval.
• Un evaluation harness — framework riutilizzabile per eval offline, golden dataset, test di regressione sui cambi di prompt e infrastruttura A/B per il shadow-launching dei nuovi modelli.
• Guardrail e tooling di sicurezza — oscuramento PII, jailbreak detection, difese contro prompt injection, filtri di policy sugli output. Una sola implementazione, auditata una volta, usata ovunque.
• Observability — latenza, costo per token, tasso di allucinazioni, segnali di feedback utente convogliati in una sola dashboard che vedono sia il CoE sia i practitioner di BU.

Nulla di tutto questo è BU-specifico. Costruirlo cinque volte è il failure mode canonico che un AI center of excellence esiste per prevenire.

2. Standard e pattern

Gli standard sono il modo in cui il CoE trasforma una buona decisione in molte. Quelli ad alta leva:

• Prompt pattern — una libreria curata di system prompt, strutture few-shot e template chain-of-thought che hanno superato gli eval gate.
• Criteri di valutazione — soglia minima per accuratezza, faithfulness, sicurezza e latenza prima che qualsiasi workflow AI-touched arrivi al cliente.
• Baseline di sicurezza — quali classi di dati possono raggiungere quali fornitori di modelli, quando lo human-in-the-loop è obbligatorio, come gestire la classificazione high-risk dell'EU AI Act.
• Playbook di procurement — lista fornitori validati, template contrattuali con le clausole sui model provider già negoziate, DPA riutilizzabili tra le BU.

3. La libreria di pattern riutilizzabili (il lift-and-shift Ricardo)

È la cosa a più alta leva che un CoE fa e quella cronicamente più sotto-finanziata. Quando una BU risolve un problema — fraud detection sugli annunci, content moderation su larga scala, ricerca semantica su un catalogo long-tail, triage di customer care assistito da agenti — il compito del CoE è astrarre il pattern in un kit riutilizzabile e portarlo nella BU successiva che ne ha bisogno. Torniamo su questo punto in una sezione dedicata perché è l'argomento centrale.

4. Relazioni con vendor e contratti

Contratti a livello di gruppo con hyperscaler e fornitori di modelli. Un enterprise agreement con OpenAI, Anthropic, AWS Bedrock o Azure OpenAI batte quasi sempre cinque contratti BU-level sul prezzo, sulle clausole di data handling e sul carico di review legale. L'AI CoE è anche la casa naturale per le relazioni con fornitori specialistici (eval tooling, observability, vendor di guardrail) su cui nessuna singola BU ha volumi sufficienti per negoziare bene da sola.

5. Coordinamento cross-BU e capability building

Community of practice interna, demo mensili tra BU, canali Slack condivisi, un programma di job rotation per AI engineer, un curriculum di upskilling per product manager e analyst di BU. Il CoE è il tessuto connettivo. Senza di esso, ogni BU riscopre le stesse lezioni a sei mesi di distanza.

Cosa presidia il modello AI Distribuito/Federato

La domanda speculare è cosa devono presidiare i practitioner di BU — non perché il CoE non vorrebbe, ma perché centralizzarlo distrugge attivamente valore. L'argomento del distributed AI model enterprise è più forte in cinque aree.

• Contesto di dominio. Il CoE non sa che il team annunci di Homegate ha un edge case peculiare di duplicate detection legato a un artefatto di data migration del 2008. Il CoE non sa che il team customer care di Ricardo ha una categoria di dispute sui rimborsi che non esiste su nessun'altra piattaforma. I workflow AI costruiti senza quel contesto degradano in fretta.
• Deployment customer-facing. La BU presidia la relazione con il cliente, il tono di brand, l'escalation path del supporto. Le feature AI-powered che toccano il cliente devono essere rilasciate dal team che presidia il cliente, non da un gruppo centrale che rilascia una volta e sparisce.
• Specifiche regolatorie per mercato. Un marketplace svizzero che opera in CH + DE + AT ha tre regimi di tutela del consumatore leggermente diversi. Un gruppo energetico che opera tra IT + ES + RO ha tre posture regolatorie diverse sull'AI nei canali customer-facing. Il CoE presidia la baseline; la BU presidia l'overlay market-specifico.
• Integrazione dati BU-specifica. I connettori verso CRM, ERP, ticketing, DB annunci e API partner di ciascuna BU vivono nella BU. Il CoE fornisce le primitive di retrieval; la BU le innesta nei sistemi reali.
• Misurazione sul P&L della BU. L'unica misura onesta di un workflow AI è cosa ha fatto agli unit economics della BU che lo presidia. Quel numero vive nella funzione finance di BU, non in una dashboard di gruppo.

Centralizzare uno qualsiasi di questi punti è il failure mode che produce il "CoE centrale che nessuno in BU rispetta". Se la BU non può muoversi senza il sign-off di gruppo su una modifica di workflow, la modifica non avviene.

L'architettura Hub-and-Spoke in pratica

Il modello su cui converge la maggior parte delle aziende multi-BU — dopo essersi scottate su uno dei due estremi puri — è Hub-and-Spoke. Un piccolo AI center of excellence centrale (l'hub) più practitioner embedded all'interno di ciascuna BU (gli spoke). Per un gruppo di circa 2.000 dipendenti e 4–8 business unit, lo schema di staffing di riferimento è questo.

Ruolo	Posizione	Headcount	Mandato principale
Head of AI CoE	Hub (Gruppo)	1	Presidia piattaforma, standard, libreria pattern; presiede l'AI council cross-BU
Platform engineer	Hub	3–5	LLM gateway, infra di retrieval, eval harness, observability
Applied AI / patterns engineer	Hub	2–4	Costruiscono e consolidano kit riutilizzabili dai successi di BU; li portano nelle BU successive
Lead AI security & governance	Hub	1	Compliance EU AI Act, policy model-risk, postura di audit
Lead enablement / community	Hub	1	Curriculum di upskilling, community of practice, cadenza demo
BU AI lead	Spoke (per BU)	1 per BU	Traduce la roadmap di BU in backlog di workflow AI; interfaccia primaria verso il CoE
BU AI engineer / product	Spoke (per BU)	1–2 per BU	Costruiscono e rilasciano workflow BU-specifici sulla piattaforma del CoE
Analyst in linea tratteggiata	Spoke (per BU)	Su richiesta	Analyst esistenti riqualificati, non nuove assunzioni nette — supporto all'uso e adozione

Si tratta di un hub centrale di 8–15 FTE e di un'impronta spoke di 2–3 practitioner AI dedicati per BU. Totale: 20–40 FTE per un'azienda da 2.000 persone su 4–8 BU. L'hub riporta al Chief Data Officer, al CTO o direttamente al COO a seconda dell'organizzazione. Gli spoke di BU riportano alla leadership di BU con una linea tratteggiata verso il Head dell'AI center of excellence. Quella linea tratteggiata è ciò che fa funzionare il modello — dà al CoE occhi e orecchie in ogni BU senza assumersi l'accountability dei risultati di BU.

L'insight della libreria di pattern (lift-and-shift Ricardo)

È l'argomento che converte gli scettici del dibattito CoE-vs-distribuito in entrambe le direzioni. La singola cosa a più alta leva che un AI center of excellence centrale può fare è gestire una libreria di pattern — e il lift-and-shift tra BU di un gruppo marketplace è il caso da manuale.

Immagina un gruppo marketplace in stile svizzero con tre verticali: un marketplace consumer orizzontale (forma Ricardo), un verticale real estate (forma Homegate) e un business di dati di valutazione immobiliare (forma IAZI). Ogni BU ha la propria roadmap AI. Ognuna incontra problemi riconoscibili:

• Il marketplace orizzontale costruisce un modello di fraud detection per annunci sospetti. Funziona.
• Il verticale real estate ha un problema quasi identico: annunci falsi, broker che aggirano il filtro duplicati. Dominio diverso, stesso pattern.
• Il business di valutazione ha un classificatore di qualità contenuti che valuta le data submission in ingresso. Funzionalmente simile al classificatore di annunci.

In un modello puramente distribuito, ogni BU ricostruisce il pattern da zero — nuova selezione vendor, nuovo eval harness, nuova iterazione di prompt, nuova scoperta dei failure mode. Diciotto mesi di lavoro duplicato. In un modello puramente CoE, il CoE costruisce centralmente "Group Fraud AI", lo rilascia e scopre che non funziona perfettamente per nessuna delle tre BU perché è stato costruito senza sufficiente contesto di dominio.

In un modello Hub-and-Spoke con una libreria di pattern funzionante, la sequenza è diversa:

1. Il marketplace orizzontale rilascia per primo il proprio workflow di fraud detection, presidiandolo end-to-end. Il CoE fornisce la piattaforma (LLM gateway, eval, observability) ma la BU presidia la delivery.
2. Una volta che funziona in produzione, gli applied-AI engineer del CoE astraggono il pattern. Rimuovono le parti BU-specifiche (lo schema annunci, la tassonomia di categoria marketplace-specifica) e documentano il kit riutilizzabile: l'architettura, i prompt pattern, la rubrica di eval, i failure mode visti in produzione, le soglie raccomandate di human-in-the-loop.
3. Quando il verticale real estate solleva il proprio problema di frode sei mesi dopo, la conversazione non parte con "valutiamo i vendor". Parte dall'entry della libreria di pattern. La BU real estate forka il kit, sovrappone i propri dati di dominio e la propria logica di categoria, e rilascia in settimane invece che in trimestri.
4. L'entry della libreria viene aggiornata con ciò che la BU real estate ha imparato. Il business di valutazione eredita entrambi i corpi di conoscenza quando arriva il suo turno.

Questo è il pattern di compounding del lift-and-shift. Ogni pattern rilasciato diventa più economico per la BU successiva. Un AI CoE serio si misura anche su questa metrica: quanti pattern sono in libreria, quante implementazioni BU derivano da un'entry di libreria invece che da greenfield e qual è il lead-time-to-second-BU per ciascun pattern. La maggior parte delle aziende non lo misura. Quelle che lo fanno compongono molto più in fretta.

Anti-pattern dell'Hub-and-Spoke

L'architettura è corretta sulla carta e facile da eseguire male nella pratica. I cinque failure mode che vediamo ripetutamente:

• Il CoE diventa un collo di bottiglia. Ogni BU deve aprire un ticket e aspettare che il CoE approvi, fornisca o costruisca. Il CoE ha 12 persone e una coda di 80 richieste. La velocità di BU scende sotto il livello pre-CoE. Fix: la piattaforma deve essere self-service per l'80% del lavoro che le BU fanno di routine; il CoE controlla solo il 20% genuinamente nuovo o rischioso.
• I practitioner di BU sono isolati tra loro. Il CoE parla con ciascuna BU bilateralmente; le BU non si parlano mai tra loro. La libreria di pattern è affamata di feedback. Fix: una demo mensile cross-BU con partecipazione obbligatoria da parte di ogni spoke; un canale Slack condiviso gestito attivamente dal lead enablement del CoE; rotazioni tra team di BU.
• Nessuna ownership chiara della libreria di pattern. Tutti concordano che la libreria di pattern è importante; il bonus di nessuno specifico dipende da essa. Marcisce. Fix: un applied-AI lead nominato all'interno del CoE il cui KPI primario sia patterns-shipped-and-reused, non models-deployed.
• Gli standard diventano burocrazia. Il CoE scrive 60 pagine di standard che le BU non riescono a operazionalizzare. La compliance è performativa. Fix: ogni standard deve essere rilasciato con un'implementazione di riferimento. Se il CoE non riesce a mostrarti come si presenta la compliance nel codice, non ha finito di scrivere lo standard.
• Nessun percorso di escalation per i conflitti BU-CoE. Una BU vuole rilasciare qualcosa con cui il lead security del CoE non si sente a proprio agio. Non esiste un meccanismo di arbitrato definito. Le cose si arenano o vengono bypassate politicamente. Fix: un AI council trimestrale (CTO di gruppo, COO o CFO, MD di BU, Head del CoE) con diritti decisionali espliciti per risolvere i conflitti entro due settimane.

Come decidere cosa va in centrale e cosa in BU

La risposta onesta a "dove esattamente tracciamo la linea" è workflow per workflow. Quando definiamo lo scope dell'operating model per un cliente, usiamo una matrice decisionale a quattro dimensioni. Assegna un punteggio a ciascun tipo di workflow candidato su ogni dimensione; il risultato ti dice se appartiene all'hub, allo spoke o a un ibrido deliberato.

Dimensione	Punteggio alto → centralizza (hub)	Punteggio alto → distribuisci (spoke)
Frequenza di ricorrenza cross-BU	Workflow riconoscibile in 3+ BU (fraud detection, content moderation, rilevanza di ricerca, eval harness, infra RAG)	Workflow specifico del mercato o prodotto di una sola BU (ottimizzazione tariffe energetiche, modello di valutazione immobiliare)
Variazione regolatoria tra mercati	Stessa classe regolatoria su tutte le BU (es. tool di produttività interna, GDPR di gruppo)	Regolazione market-specifica pesante (tutela consumatori in CH vs DE vs IT; regolatori di settore)
Complessità di integrazione	Superficie di integrazione generica (LLM gateway, observability, eval tooling)	Integrazione profonda nei sistemi BU-specifici (CRM di BU, DB annunci di BU, ERP di BU)
Giudizio business-specifico	Decisioni difendibili con principi generici (sicurezza, costo, selezione modello)	Decisioni che richiedono giudizio di dominio della BU (quando escalare a un umano, tono di brand, policy per tier cliente)

I workflow che ottengono punteggi alti sulle dimensioni 1–2 e bassi su 3–4 appartengono all'hub. I workflow con punteggi opposti appartengono allo spoke. I casi genuinamente difficili sono quelli con punteggi misti — di solito si risolvono meglio come "kit": l'hub rilascia un componente riutilizzabile, lo spoke lo cabla nella BU. La matrice decisionale non è magia. È una forcing function per rendere la conversazione specifica invece che ideologica.

Sequenziamento: Distribuito → CoE → Hub-and-Spoke (o viceversa)

La maggior parte delle aziende arriva all'Hub-and-Spoke percorrendo uno dei due path di fallimento prevedibili. Sapere su quale path sei rappresenta metà della battaglia.

Path A: Partiti distribuiti, overcorretti verso CoE puro

È il path più comune. L'azienda ha lasciato che le BU sperimentassero liberamente per 18–24 mesi. Sono state rilasciate cose buone. Sono state rilasciate cose imbarazzanti. L'uso di shadow AI era dilagante. I costi sono esplosi perché ogni BU ha comprato il proprio contratto LLM. Un incidente a livello board (un'allucinazione finita sulla stampa, una data leak attraverso uno strumento non autorizzato) ha innescato il panico. L'ufficio del CIO ha istituito un AI center of excellence centrale con il mandato esplicito di "mettere tutto sotto controllo". Sei mesi dopo la velocità di BU è collassata, il CoE ha una coda di approvazione di 90 giorni e il capo della BU più profittevole è apertamente ostile. La soluzione è mantenere il CoE per piattaforma + standard + pattern e ridistribuire aggressivamente l'autorità di delivery alle BU, con la piattaforma come substrato self-service.

Path B: Partiti con un CoE puro, nessuna trazione in BU

Meno comune ma più doloroso quando accade. L'azienda ha assunto un Chief AI Officer e un team centrale di 20 persone prima che alcuna BU ne avesse fatto richiesta. Il CoE ha costruito una piattaforma bellissima che nessuno usa, perché nessun practitioner di BU è stato coinvolto nei requisiti. Le BU continuano silenziosamente a usare ciò che usavano prima. La soluzione è integrare gli engineer del CoE all'interno di ciascuna BU in rotazione, costringere il CoE a portare valore visibile una BU alla volta e strumentare l'adozione (chiamate gateway per BU, pattern riutilizzati per BU) come KPI primario del CoE.

Lo stato di regime

Entrambi i path convergono sull'Hub-and-Spoke se glielo lasci fare. Il playbook di sequenziamento onesto per un'azienda da 2.000–5.000 dipendenti:

• Mesi 0–3: nomina il Head del CoE, fai l'inventario dei workflow tra le BU, scegli una BU come lighthouse per la prima entry della libreria di pattern.
• Mesi 3–9: avvia la piattaforma (LLM gateway, eval harness, observability) e rilascia il primo pattern riutilizzabile con la BU lighthouse.
• Mesi 9–18: innesta gli spoke in altre 2–3 BU; fai il lift-and-shift del primo pattern su una seconda BU; avvia la prima cadenza di demo cross-BU.
• Mesi 18+: la libreria di pattern ha 5–10 entry, ciascuna usata da 2+ BU. A quel punto l'operating model funziona in modo auto-evidente e il dibattito politico si chiude.

Riferimento di costo

Riferimento di ordine di grandezza per un'azienda da 2.000–5.000 dipendenti su 4–8 business unit. I numeri sono run-rate fully loaded che includono persone, piattaforma e contratti vendor. Esclude gli ingaggi di discovery in stile Phase I.

Modello	Run-rate annuale	Headcount	Punti di forza / failure mode
CoE centrale puro	€2–5M / anno	15–30 FTE centrali, ~0 in BU	Governance e piattaforma forti; alto rischio failure-to-adopt se le BU non sono state partner di co-design
Distribuito puro	€3–8M / anno (variabilità ampia)	0 centrali, 2–5 per BU	Alta velocità di BU; costo totale alto per duplicazione di tooling, contratti vendor e pattern; postura di sicurezza di gruppo debole
Hub-and-Spoke (raccomandato)	€1,5–4M centrali + €300K–1M per BU	8–15 centrali + 2–3 per BU	Compone tramite libreria di pattern; richiede governance esplicita; failure mode è il collo di bottiglia
Esternalizzato ("lasciamo che lo presidi un partner")	€1–3M / anno in fee	0 interni, 5–15 partner	Avvio rapido; costoso a regime; la conoscenza istituzionale non atterra mai dentro l'azienda

La lettura onesta: il distribuito puro è quasi sempre il modello più costoso su base total-cost anche se sembra il più economico riga per riga, perché nessuno sta ammortizzando la piattaforma o il lavoro sui pattern. Il CoE puro sembra disciplinato sulla carta e sotto-performa nella pratica se le BU non hanno partecipato al design. L'Hub-and-Spoke costa più o meno quanto un CoE puro per il layer centrale più una sottile impronta spoke per BU — ed è l'unico dei quattro modelli che effettivamente compone.

Dati proprietari SUPALABS

FAQ

Serve un Chief AI Officer per gestire un AI center of excellence?

Quasi mai come prerequisito di Phase zero. Il Head dell'AI center of excellence è di solito un ruolo a livello Director o VP che riporta al CTO, CDO o COO — non un pari di quei ruoli. La maggior parte delle aziende mid-cap e large ha già il talento distribuito su team esistenti (Head of Data Engineering, Group Security & Trust, leadership ML esistente) e la mossa giusta è elevare e connettere ciò che esiste invece di costruire una funzione C-suite parallela. Un Chief AI Officer diventa appropriato quando l'AI è genuinamente una leva strategica a livello board e il CEO vuole un singolo executive accountable — di solito 18–24 mesi dentro un programma serio, non prima.

Quante persone servono davvero in un AI CoE?

Per un'azienda da 2.000–5.000 dipendenti con 4–8 business unit, l'hub centrale conta tipicamente 8–15 FTE: un Head of CoE, 3–5 platform engineer, 2–4 applied-AI/patterns engineer, un lead AI security & governance e un lead enablement. In aggiunta servono 2–3 practitioner AI dedicati embedded in ciascuna BU (gli spoke) che riportano alla leadership di BU con linea tratteggiata verso il CoE. Sotto quella soglia di staffing, il CoE non riesce a stare dietro alla domanda di BU e il modello degrada in collo di bottiglia. Significativamente sopra quella soglia, il CoE deriva verso una funzione IT parallela, che è un failure mode a sé.

Qual è la differenza tra un AI CoE e un Data CoE che abbiamo già?

Un Data CoE presidia tipicamente la piattaforma dati, la governance e il tooling di analytics. Un AI center of excellence presidia il layer AI-specifico che sta sopra (e dipende dalla) piattaforma dati: LLM gateway, evaluation harness, librerie di prompt e pattern, guardrail e observability AI-specifici e postura di compliance EU AI Act. Nella maggior parte delle aziende i due sono gestiti come funzioni sorelle sotto lo stesso CDO o CTO, condividendo infrastruttura dove ha senso (i vector store spesso vivono nella piattaforma dati; il layer eval e gateway AI-specifico di solito no). Se hai già un Data CoE forte, sei circa sei mesi avanti nello stand-up di un AI CoE efficace.

L'approccio distributed AI model enterprise è mai la risposta giusta da solo?

Raramente, e solo in due situazioni. Primo, portafogli molto piccoli — un'azienda con una o due business unit dove l'overhead di un hub separato non è giustificato; qui il "CoE" è di fatto un piccolo platform team dentro la singola BU dominante. Secondo, strutture di holding company dove le business unit sono deliberatamente gestite a distanza, spesso con quote di proprietà diverse, regimi regolatori diversi o eventuali cessioni in vista; qui puoi gestire una funzione di standard di gruppo molto sottile e lasciare che ciascuna società presidi il proprio stack AI in autonomia. Per il tipico gruppo operativo multi-BU, il distribuito puro è il modello più costoso su base total-cost ed espone il gruppo a rischi di sicurezza e reputazionali che compongono silenziosamente.

Come misuriamo se il CoE sta davvero funzionando?

Quattro KPI separano un AI CoE funzionante da uno di facciata. (1) Cadenza della libreria di pattern: quanti pattern riutilizzabili sono stati rilasciati e quante implementazioni di BU derivano da essi invece che da greenfield. (2) Lead time di lift-and-shift: quando la seconda BU adotta un pattern esistente, quanto tempo passa fino alla produzione. (3) Adozione della piattaforma: percentuale di chiamate LLM del gruppo instradate attraverso il gateway, percentuale di workflow AI-touched che superano l'eval harness standard prima della produzione. (4) Soddisfazione di BU: un punteggio trimestrale in stile NPS dai BU AI lead sulla responsività e utilità del CoE. Metriche come "modelli deployati" o "use case identificati" misurano attività, non valore, e premiano esattamente i comportamenti sbagliati.

Come si lega al dibattito "AI center of excellence vs federato" di cui leggo ovunque?

Il framing AI center of excellence vs federato è essenzialmente lo stesso dibattito di CoE vs distribuito, solo con vocabolario diverso — "federato" di solito enfatizza che ciascuna BU ha pari dignità e non esiste un'unica autorità centrale. In pratica, vince la stessa risposta Hub-and-Spoke, perché la federazione pura soffre degli stessi problemi di costo e sicurezza in compounding del distribuito puro, e la centralizzazione pura soffre degli stessi problemi di adozione. La decisione interessante non è centrale-vs-federato come slogan ma il line-drawing per workflow descritto nella matrice decisionale. Tratta chi risponde "centralizzato" o "federato" senza chiedere di che tipo di workflow stai parlando come qualcuno che non ha mai fatto questo lavoro prima.

Fonti e riferimenti