Consolidazione dei vendor AI: la guida enterprise 2026

La realtà del 2026: la maggior parte delle aziende ha 8–15 vendor AI. Il CFO ha appena fatto i conti.

A due anni dalla corsa all’acquisto di AI generativa, il quadro all’interno della maggior parte delle aziende post-IPO è lo stesso: ChatGPT Enterprise convive con Microsoft 365 Copilot, accanto a un tenant Claude che engineering ha messo a budget in sordina, accanto a Glean per la ricerca, Cursor per l’IDE, Perplexity Enterprise per la research, un cluster n8n che fa “AI workflow” e due o tre piattaforme LLM interne che data science ha tirato su perché nessuno riusciva a mettersi d’accordo su un default. Il CFO ha estratto il report nel Q1 e la cifra era più alta di quanto chiunque volesse ammettere.

Questo è il punto di partenza della consolidazione dei vendor AI ed è la domanda di procurement dominante del 2026 per aziende tra 500 e 5.000 dipendenti. La fase di land grab dell’hype cycle è finita. Il consiglio ha smesso di chiedere “stiamo facendo AI?” e ha cominciato a chiedere “perché paghiamo otto fatture diverse per farlo?”

I numeri dietro questo disagio sono reali. Gartner stima la spesa mondiale in GenAI a 644 miliardi di dollari nel 2025, in crescita del 76% anno su anno, con il grosso che si concentra su software e servizi enterprise più che su infrastruttura — il che significa che è il numero di vendor, non il compute, a essere la voce in crescita. Il tracker AI 2025 di IDC colloca la media di vendor software AI a 11,4 per organizzazione nella fascia 1.000+ dipendenti, in salita da 4,2 di inizio 2024. Lo State of AI 2025 di McKinsey ha rilevato che il 78% delle aziende utilizza ormai AI in almeno una funzione, ma solo il 27% ha una qualche forma di governance formale sui vendor.

Traduzione: ogni CFO di questo segmento sta per ricevere un mandato di consolidazione. Questa guida è per chi quel mandato lo deve eseguire.

Perché consolidare non è solo tagliare costi

La maggior parte dei memo di consolidazione si legge come un esercizio da foglio Excel: si allineano le fatture, si eliminano quelle ridondanti, si contano i risparmi. È un inquadramento che svaluta ciò che è davvero in gioco.

L’argomento onesto a favore della razionalizzazione dei vendor AI è architetturale, non finanziario. Quando la tua capability AI vive su otto tenant separati, hai otto audit trail separati, otto perimetri di data residency separati, otto set di prompt e fine-tune che non puoi condividere tra sistemi e zero capacità di porre una domanda che li attraversi. Hai comprato la stessa capability otto volte e hai rinunciato all’unica cosa che l’avrebbe resa più del semplice somma delle parti.

Il pattern è familiare a chiunque abbia visto una grande azienda consolidare i payment provider. Prima del consolidamento, un marketplace con Stripe in una regione, Datatrans in un’altra e Adyen in una terza ha tre flussi di riconciliazione, tre modelli antifrode, tre superfici di reporting. Dopo, il taglio dei costi è reale ma poco interessante. La mossa interessante è che il fraud modeling può ora girare su dati combinati, il settlement può essere compensato tra regioni e i pattern di chargeback diventano visibili a livello di gruppo per la prima volta. Consolidare su un unico provider non era una somma di tre fatti separati. Era una sola decisione architetturale che ha abilitato un nuovo livello.

La consolidazione del tooling AI a livello enterprise abilita lo stesso tipo di livello:

• Retrieval cross-sistema. Se il tuo corpus RAG vive dentro Glean ma la chat vive dentro ChatGPT Enterprise, non puoi ancorare le risposte ai tuoi dati senza un ponte fragile. Stesso vendor, problema scomparso.
• Audit trail unico. I revisori non vogliono otto export di log in otto schemi diversi. SOC 2, ISO 42001 e EU AI Act presuppongono tutti un unico record difendibile di cosa ha fatto il modello e perché.
• Catalogo unificato di prompt e tool. Un prompt che funziona in un tenant è un artefatto privato. Un prompt gestito in un’unica piattaforma è un asset organizzativo.
• Leva sul fine-tuning. I dati che useresti per fare fine-tuning a un modello sono oggi frammentati su vendor che ne vedono solo una fetta. Consolida e quella fetta diventa un corpus.
• Perimetro identità unico. SCIM, SSO, deprovisioning e DLP funzionano solo se c’è un solo perimetro su cui applicarli. Otto tenant significano otto modalità di fallimento.

La riduzione dei costi è il beneficio meno importante della consolidazione dei vendor AI. È il beneficio che metti nella board deck perché chiude la conversazione, ma è l’unlock architetturale che giustifica il costo della migrazione.

Le 5 categorie di sovrapposizione tra vendor AI

Prima di poter razionalizzare, bisogna nominare la forma dello sprawl. Nel nostro lavoro con clienti enterprise impegnati in esercizi di AI vendor replacement assessment, ricorrono sempre gli stessi cinque cluster di sovrapposizione.

Categoria	Vendor tipici nello sprawl	Sintomo di sovrapposizione	Leva di consolidazione
Chat assistant	ChatGPT Enterprise, Copilot Chat, Claude for Work, Gemini Enterprise	Ogni dipendente loggato su 2–3; nessuno sa quale sia quello “ufficiale”	Scegli un default + una specialità; deprovisiona il resto
Coding assistant	GitHub Copilot, Cursor, Codeium, Tabnine, JetBrains AI	Engineering ne ha comprato uno, singoli team ne hanno messo a budget un altro	Standardizza sull’IDE-native; consenti un’alternativa per i power user
Enterprise search e RAG	Glean, Perplexity Enterprise, Elastic AI, LLM interno su Confluence	Stesso corpus indicizzato 3 volte, risposte discordanti	Un solo retrieval layer; le chat lo richiamano via tool
Piattaforme workflow / agent	n8n, Zapier AI, Make, Relevance AI, stack LangChain interno	Stesse automazioni ricostruite 2–3 volte su piattaforme diverse	Una piattaforma di orchestrazione + agent registry governato
Add-on di dominio	Harvey/Ironclad (legal), Gong/Clari AI (sales), ThoughtSpot/Hex AI (BI)	Ogni BU ha comprato il proprio; le capability si sovrappongono sempre più con gli strumenti orizzontali	Mantieni dove c’è regolamentazione/specializzazione; taglia dove ormai basta il general-purpose

Le prime tre categorie sono quelle da cui arriva il 70% dei risparmi di consolidazione dei vendor AI. Le ultime due sono quelle in cui si gioca la discussione strategica.

Come mappare il footprint vendor AI attuale

L’inventario è la parte che i team di procurement sottostimano sistematicamente. La lista vendor ufficiale ti mostrerà forse il 60% del footprint reale. L’altro 40% vive in note spese, trial in ombra e acquisti per-seat che non sono mai passati dal legal. Ecco il processo in 6 step che eseguiamo negli ingaggi di assessment.

1. Export da procurement. Estrai ogni contratto vendor attivo taggato “AI”, “ML”, “analytics”, “automation”, “LLM”, “copilot”, “assistant” o “generative”. Poi rifai l’estrazione filtrando per categoria “SaaS” con rinnovo negli ultimi 18 mesi, perché metà degli strumenti AI sono stati acquistati prima che il tagging fosse irrigidito.
2. Log SSO e IdP. Okta, Entra o Google Workspace sa su quali app i tuoi dipendenti accedono davvero. Filtra per app con keyword AI/ML/LLM nei metadati e poi incrocia con la lista procurement. Il delta è il tuo footprint di shadow AI.
3. Scansione delle note spese. Passa gli ultimi 12 mesi di dati delle carte aziendali contro una lista di nomi vendor AI noti (ChatGPT, Claude, Cursor, Perplexity, Replicate, Together, Anthropic, OpenAI, Mistral, Hugging Face, Pinecone, Weaviate, LangChain, ecc.). Le singole sottoscrizioni da 20 e 200 dollari sommate fanno una fetta sorprendente del conto.
4. Inventario IT + telemetria endpoint. Gli strumenti MDM ed EDR vedono ogni app desktop e ogni estensione browser. Inventaria ChatGPT desktop, Claude desktop, Cursor, Continue e la lunga coda di estensioni browser che chiamano API AI da dentro altri strumenti.
5. Egress API e log DNS. La telemetria di rete mostrerà il traffico verso api.openai.com, api.anthropic.com, generativelanguage.googleapis.com e endpoint simili. Così intercetti app interne e notebook che stanno bruciando spesa modello senza comparire mai in procurement.
6. Deduplica cross-BU. Una volta avuta la lista grezza, raggruppa per capability (chat, coding, search, workflow, dominio). Lo stesso vendor compare spesso sotto contratti BU diversi — legal ha comprato Harvey, finance ha comprato OpenAI direttamente, marketing ha comprato ChatGPT Enterprise tramite agenzia. Consolidare il contratto è la vittoria più semplice di tutto l’esercizio.

L’output di questa fase è un unico foglio: vendor, BU proprietaria, durata contrattuale, spesa annua, seat attivi, stato SSO, data residency, capability primaria. Senza questo artefatto, ogni conversazione a valle è opinione. Con esso, la conversazione diventa deterministica.

Il framework decisionale di consolidazione

Una volta mappato il footprint, ogni vendor ha bisogno di un verdetto: keep, consolidate, sandbox o kill. Il framework qui sotto è quello che usiamo negli ingaggi di AI vendor replacement assessment. Ogni vendor riceve un punteggio da 1 a 5 su sei dimensioni; il composito ti dice in che secchio finisce.

Dimensione	Cosa significa “5”	Cosa significa “1”	Peso
Profondità di utilizzo	Daily active >60% dei seat provisionati	Daily active <10%; shelf-ware	25%
Flessibilità contrattuale	Termine mensile, nessun minimo, uscita semplice	Termine 36 mesi, prepagato, penale di uscita elevata	15%
Costo di switching	Nessun prompt/workflow custom; utenti migrabili in una settimana	Anni di prompt custom, fine-tune, integrazioni	20%
Dipendenza regolatoria	Nessun lock-in normativo specifico	Richiesto per workflow attestati HIPAA/PCI/EU AI Act	15%
Costo affondato di integrazione	SaaS standalone, footprint integrativo basso	Integrazioni profonde in 5+ sistemi di business	15%
Moat strategico	Il vendor offre una capability che nessuna piattaforma consolidata può eguagliare	Pura commodity; capability disponibile ovunque	10%

La mappa dei verdetti è lineare:

• Composito 4,0–5,0: Keep. Questo vendor si guadagna il suo slot.
• Composito 2,5–3,9: Consolidate. Migra i carichi su una piattaforma strategica al rinnovo.
• Composito 1,5–2,4: Sandbox o kill. O lo si giustifica come sandbox di innovazione (criteri più sotto), oppure si taglia al prossimo rinnovo.
• Composito <1,5: Kill immediato. Negozia un’uscita anticipata se possibile.

Esempio applicato a 10 vendor rappresentativi che una tipica azienda da 2.000 dipendenti si porta dietro:

Vendor	Categoria	Composito	Verdetto
ChatGPT Enterprise (intera org)	Chat	4,4	Keep (piattaforma strategica)
Copilot Chat (bundle M365)	Chat	3,6	Consolidate (downgrade alla sola baseline M365)
Claude Teams (solo engineering)	Chat	3,9	Consolidate (instradare via API gateway)
Gemini Enterprise (pilot)	Chat	1,7	Sandbox o kill
GitHub Copilot	Coding	4,6	Keep
Cursor (power user engineering)	Coding	3,1	Consolidate (cap sui seat)
Glean	Search/RAG	4,2	Keep (retrieval layer strategico)
Perplexity Enterprise	Search/RAG	2,3	Kill al rinnovo
n8n self-hosted	Workflow	4,0	Keep
Zapier AI	Workflow	2,1	Kill, migra i flussi su n8n

Questa singola matrice di solito libera immediatamente 3–5 vendor e apre la conversazione contrattuale su altri 2–3. I keep che restano diventano il set di piattaforme strategiche.

Lezioni dalla consolidazione dei payment provider

La conversazione sulla consolidazione AI nel 2026 assomiglia in modo notevole alla conversazione sulla consolidazione dei pagamenti che le aziende hanno fatto tra 2019 e 2022. Le stesse aziende che oggi sono atterrate su Adyen o Stripe avevano 3–5 acquirer e PSP sparsi sulle regioni, con esattamente gli stessi argomenti per tenerli: metodi di pagamento regionali, costo dell’integrazione legacy, autonomia delle BU, paura del single-vendor risk.

Tre lezioni si traducono direttamente nella consolidazione dei vendor AI:

• Il business case non è mai la voce di costo. I progetti di consolidazione dei pagamenti che vendevano “risparmiamo X bps di interchange” faticavano a essere approvati. Quelli che vendevano “segnale antifrode unificato a livello di gruppo” o “flusso di riconciliazione unico” venivano finanziati. Per l’AI vale lo stesso: parti dall’unlock architetturale, non dalla riga di risparmio.
• Il numero giusto non è sempre uno. La maggior parte delle aziende è atterrata su una struttura primary + secondary (Adyen primary, Stripe per regioni o linee di prodotto specifiche). Lo stesso pattern è sano nell’AI: una piattaforma chat strategica, una piattaforma di retrieval strategica, una piattaforma di orchestrazione, più eccezioni specialistiche limitate.
• Il vincolo è il costo di migrazione, non il fit tecnico. Entro il terzo mese di qualsiasi consolidazione dei pagamenti, la domanda smetteva di essere “quale vendor è il migliore” e diventava “quale migrazione engineering riesce davvero ad assorbire quest’anno”. L’AI segue la stessa traiettoria. Prioritizza senza pietà.

Cosa fare con i vendor da “sandbox di innovazione”

La versione onesta di un programma di consolidazione dei vendor AI ammette che non tutti i vendor devono morire. Alcuni meritano di vivere come sandbox — strumenti che si guadagnano il posto non perché sostituiscono una piattaforma strategica, ma perché mantengono l’organizzazione in apprendimento.

Criteri che un vendor deve soddisfare per qualificarsi come sandbox-allowed:

• Spesa con cap. Il budget sandbox è fisso, di solito 5–10% della spesa software AI totale, e non cresce senza esplicita approvazione del consiglio.
• Seat con cap. Tetto rigido, tipicamente 25–100 utenti a seconda della taglia dell’organizzazione. Nessuna espansione silenziosa.
• Posseduto da un solo team. Un unico owner nominato (di solito un platform team o un AI center of excellence). Non un “tutti fanno tutto”.
• Review trimestrale. O il vendor sandbox cresce fino a sostituire una piattaforma strategica, oppure viene tagliato. Uno stato di sandbox a tempo indefinito è solo sprawl mascherato.
• SSO e perimetro dati comunque applicati. Sandbox non significa non governato. Le stesse regole di identità, logging e DLP si applicano.

Lo slot sandbox onesto è ciò che impedisce a un programma di consolidazione di diventare un freeze. Vuoi che l’organizzazione continui a comprare e provare; non vuoi che ogni trial diventi una voce permanente in bilancio.

Il playbook di consolidazione a 12 mesi

Un programma di consolidazione del tooling AI enterprise completo dura circa 12 mesi end-to-end. La struttura che funziona:

• Mesi 1–3 — Inventario e scoring. Esegui la mappa del footprint in 6 step. Applica il framework decisionale. Atterra su un’unica mappa di verdetti approvata dall’executive: keep / consolidate / sandbox / kill. Presenta al consiglio la tesi dell’unlock architetturale, non la sola riga di risparmio.
• Mesi 4–6 — Rinegoziazione e uscita. Procurement apre conversazioni con i vendor da mantenere per consolidare volumi, con i target da consolidare per finestre di migrazione ordinate, e con i vendor in kill-list per la chiusura anticipata. La maggior parte dei vendor enterprise offrirà credit verso un utilizzo allargato più che affrontare un churn pieno — usa questa leva con aggressività.
• Mesi 7–9 — Migrazione dei carichi. Engineering e operations spostano prompt, integrazioni, automazioni e utenti dai vendor in sunset alle piattaforme strategiche. È la fase in cui scivolano la maggior parte dei programmi; la disciplina che li tiene in carreggiata è un singolo migration tracker per vendor con owner nominati e review esecutiva settimanale.
• Mesi 10–12 — Validazione e cattura. Verifica le riduzioni di spesa nel general ledger reale, verifica le dismissioni di seat in SSO, esegui i carichi sbloccati che hanno giustificato l’argomento architetturale (retrieval cross-sistema, governance unificata, pipeline di fine-tuning) e presenta al consiglio i numeri realizzati vs proiettati.

La tentazione al mese 4 è saltare la disciplina di migrazione e semplicemente spegnere tutto. Resisti. I taglio netti senza migrazione causano rivolte degli utenti, riemersione di shadow IT e un danno politico che riporta indietro di anni il prossimo ciclo di consolidazione.

Riferimento di costo (esiti tipici di consolidazione 2026)

Range indicativi da programmi di consolidazione dei vendor AI enterprise che abbiamo visto eseguire tra organizzazioni da 500 a 5.000 dipendenti. I numeri variano molto per settore e punto di partenza; trattali come orientamento, non come impegno.

Taglia organizzazione	Spesa AI annua pre-consolidazione	Spesa AI annua post-consolidazione	Costo migrazione una tantum	Payback (mesi)
500–1.000 dipendenti	0,4–0,9 mln $	0,25–0,55 mln $	80–180 mila $	6–9
1.000–2.500 dipendenti	0,9–2,6 mln $	0,55–1,5 mln $	180–450 mila $	5–8
2.500–5.000 dipendenti	2,6–6,5 mln $	1,5–3,8 mln $	450 mila–1,1 mln $	4–7

Due note sui conti. Primo, i risparmi mostrati sono solo quelli sulla riga di spesa. I benefici dell’unlock architetturale (retrieval cross-sistema, audit unificato, leva sul fine-tuning) tipicamente generano un valore indiretto pari a 1,5–3 volte la riduzione di spesa nei 12 mesi successivi, ma richiedono un modello di misurazione di cui il CFO si fidi. Costruisci quel modello prima di presentarti al consiglio, non dopo. Secondo, il costo di migrazione è dominato dal tempo delle persone, non dalle fee dei vendor — se il tuo team engineering è già al massimo, questo numero raddoppia.

Dati di prima parte SUPALABS

Dagli ingaggi di assessment che SUPALABS ha condotto con clienti enterprise su footprint vendor AI e consolidazione:

• TODO_SUPALABS_FILL_IN_AVERAGE_VENDOR_COUNT_AT_ASSESSMENT_KICKOFF
• TODO_SUPALABS_FILL_IN_PERCENTAGE_OF_VENDORS_DEEMED_REDUNDANT_AT_FIRST_REVIEW
• TODO_SUPALABS_FILL_IN_AVERAGE_SHADOW_AI_FOOTPRINT_AS_PERCENT_OF_OFFICIAL
• TODO_SUPALABS_FILL_IN_TYPICAL_TIME_TO_FIRST_VENDOR_EXIT_FROM_KICKOFF
• TODO_SUPALABS_FILL_IN_AVERAGE_REALIZED_SPEND_REDUCTION_AT_MONTH_12
• TODO_SUPALABS_FILL_IN_NUMBER_OF_CONSOLIDATION_PROGRAMS_DELIVERED_IN_2025_AND_2026

FAQ

Quanti vendor AI dovrebbe avere davvero un’azienda?

Non esiste un numero universale, ma il pattern che si afferma nelle aziende post-IPO atterrate bene dopo un programma di consolidazione è di circa 3–5 piattaforme strategiche (una chat, una coding, una retrieval/RAG, una workflow/agent, opzionalmente uno strumento di dominio regolamentato) più 1–2 slot sandbox con budget capped. Qualsiasi cifra sopra i 7–8 vendor AI attivi in un’organizzazione da 1.000–5.000 dipendenti è sprawl, non strategia. L’inquadramento corretto per il CFO non è “quanto pochi”, ma “quanto pochi possono garantire l’unlock architetturale”.

Consolidazione dei vendor AI e razionalizzazione dei vendor AI sono la stessa cosa?

In sostanza sì, con una sfumatura. La consolidazione dei vendor AI si riferisce di solito all’atto di ridurre il numero di vendor e indirizzare i carichi verso un set ridotto di piattaforme strategiche. La razionalizzazione dei vendor AI è il termine procurement leggermente più ampio che include la consolidazione ma copre anche la ristrutturazione contrattuale, il right-sizing dei seat e la rinegoziazione senza necessariamente tagliare vendor. La maggior parte dei mandati CFO usa i termini in modo intercambiabile; la maggior parte dei team procurement tratta la razionalizzazione come programma ombrello e la consolidazione come una delle sue workstream.

Qual è l’errore più grande che le aziende fanno nei programmi di consolidazione dei vendor AI?

Tagliare i vendor di netto prima di aver migrato i carichi. L’orologio dei risparmi parte il giorno in cui spegni un contratto, quindi finance spinge per cancellazioni veloci. Ma se gli utenti avevano workflow reali sullo strumento in sunset e non c’è ancora un percorso di migrazione attivo, succedono due cose: la produttività scende in modo misurabile e una riacquisto in shadow compare sulla carta personale di qualcuno entro 30 giorni. La disciplina è migrare prima, validare la migrazione poi, e solo a quel punto spegnere il contratto — anche se significa portarsi dietro due mesi di doppia spesa.

Come gestiamo i vendor AI a livello di BU che il programma centrale non possiede?

Trattali come scope, non come eccezioni. Ogni vendor di proprietà di una BU consuma comunque superficie di dati, identità e compliance dall’organizzazione centrale, quindi appartiene all’inventario e al framework decisionale anche se il contratto è in mano alla BU. La mossa negoziale che funziona: dai alle BU un budget sandbox con tetto chiaro che controllano interamente, in cambio del fatto che qualsiasi vendor sopra la scala sandbox passi nel procurement centrale. La maggior parte dei leader di BU accetta lo scambio perché offre velocità senza rischio politico.

Dovremmo aspettare che il mercato AI si stabilizzi prima di consolidare?

No. L’argomento per aspettare è che il set di piattaforme strategiche potrebbe cambiare in 18 mesi e non vuoi farti lock-in. L’argomento contro aspettare è più forte: più aspetti, più vendor si radicano, più abitudini utente si formano, più il costo di switching sale. Consolidare ora con l’opzione di sostituire una piattaforma strategica tra 18 mesi è più economico che consolidare più tardi partendo da una situazione più radicata. Costruisci il programma di consolidazione con pattern portabili (gateway di routing, prompt esportati, retrieval astratto) così che i cambi di piattaforma restino trattabili.

Chi dovrebbe possedere la consolidazione dei vendor AI — procurement, IT o l’AI center of excellence?

Tutti e tre, con ruoli chiari. Procurement possiede la negoziazione contrattuale, i termini di uscita e i tempi di rinnovo. IT possiede il perimetro di identità, il sunset delle integrazioni e gli standard di piattaforma. L’AI center of excellence (o la funzione strategia equivalente) possiede il framework decisionale e la tesi dell’unlock architetturale che giustifica il programma al consiglio. Il CFO è lo sponsor esecutivo perché possiede la riga di spesa. La modalità di fallimento più grande è lasciare che uno solo di questi possieda il programma da solo — i programmi solo-procurement tagliano troppo, i programmi solo-IT ignorano la leva commerciale, i programmi solo-strategia non spediscono mai.

Fonti e riferimenti