Il confronto tra sviluppo interno e acquisto non è una novità nel mondo IT. Lo stesso dilemma, infatti, per decenni ha accompagnato le scelte sui software aziendali, dal gestionale su misura alle piattaforme standard. Con l’intelligenza artificiale, e in particolare con il “fenomeno” della GenAI, la questione si è ripresentata con un’urgenza nuova, perché riguarda non solo l’efficienza operativa ma il controllo sulla logica di business e sul dato che alimenta i modelli.
Indice degli argomenti
Cos’è il dilemma AI build vs buy e perché preoccupa i CIO
La pressione sui CIO a muoversi rapidamente sull’AI è alta, ma i dati raccontano un divario tra ambizione ed esecuzione.
Una survey di Deloitte indica che le sfide organizzative (citata dal 48% degli intervistati), le pressioni normative (48%) e la carenza di talenti (40%) sono tra i principali ostacoli ai piani aziendali di adozione dell’AI. In questo contesto, la scelta di build vs buy diventa dirimente nel definire come impiegare i talenti AI disponibili, chi controlla la logica di business e se l’organizzazione sarà davvero in grado di sostenere nel tempo ciò che ha implementato.
Perché non è (più) una decisione solo tecnica
Il primo errore che accomuna la maggior parte delle implementazioni fallite è trattare il build vs buy come una questione puramente tecnologica. Darshan Naik, Chief Growth Officer per le business unit Telecom, Media, High Tech, Semiconductors, Oil and Gas, Utilities, and Resources di Capgemini, osserva che «uno degli sbagli più comuni è proprio ridurre la scelta a un problema di infrastruttura, quando in realtà è una decisione che riguarda persone, processi e governance insieme». Sulla stessa linea, Jim Rowan, Responsabile AI per gli Stati Uniti di Deloitte Consulting, sottolinea che «il tema va inquadrato come un investimento nella trasformazione organizzativa, non come un evento di procurement una tantum».
Anche i dati KPMG confermano questa lettura: secondo uno studio recente, metà delle organizzazioni acquista o noleggia la propria AI generativa da fornitori esterni, il 29% adotta una strategia mista tra sviluppo interno, acquisizione e partnership, mentre solo il 12% sviluppa soluzioni internamente. È un segnale chiaro di quanto il mercato si sia orientato verso approcci misti piuttosto che verso scelte nette.
Quando conviene sviluppare l’AI internamente
Non tutte le funzionalità AI devono essere obbligatoriamente acquistate da un vendor. Per alcune organizzazioni, lo sviluppo interno resta la strada giusta, soprattutto quando l’obiettivo è la differenziazione competitiva.
Gli elementi che spingono verso il «build»
Il caso più solido per lo sviluppo custom emerge quando le soluzioni disponibili sul mercato non riescono a soddisfare requisiti di business molto specifici. I prodotti AI standard, per loro natura, devono funzionare per molte aziende ed esigenze diverse, e questo li porta a sacrificare quella specializzazione che genera vantaggio competitivo reale. Oscar Marin, Managing Director di EY Technology Consulting, invita i CIO a «chiedersi se stanno comprando davvero intelligenza o soltanto standardizzazione in un’area dove il business richiederebbe invece specializzazione» nel valutare quale strada percorrere.
Anche l’analisi di KPMG conferma questa direzione: quando una soluzione AI rappresenta un elemento di differenziazione, possedere la proprietà intellettuale diventa la scelta più sensata, perché consente di costruire capacità uniche invece di affidarsi a prodotti generici disponibili anche ai concorrenti. È il principio che EY, tramite Vamsi Duvvuri, Direttore Generale per le Americhe della practice AI per i settori Tech, Media e TLC, definisce come «capacità industry native. Possedere dati e intelligenza, invece di acquistarli o prenderli in affitto, preserva una differenziazione che nessun prodotto preconfezionato potrà mai replicare», ha osservato il manager.
I rischi e le criticità del build
Costruire internamente comporta tempi di sviluppo più lunghi e investimenti iniziali più alti di quanto la maggior parte delle organizzazioni preveda. A questo si aggiungono manutenzione continua, aggiornamenti dei modelli e il costo di acquisizione e mantenimento dei talenti, che spesso viene sottostimato proprio nella componente umana del progetto.
Le competenze necessarie, tra Machine Learning, MLOps, data science e ingegneria del software, sono sempre più richieste, ma restano scarse.
Quando conviene acquistare una piattaforma AI
Acquistare da un vendor resta la scelta giusta per una parte consistente dei casi d’uso aziendali, in particolare quando la priorità è la velocità di implementazione.
Gli elementi che spingono verso il «buy»
Il buy ha senso quando velocità e affidabilità comprovata sono i requisiti principali di un progetto. Per le organizzazioni con competenze AI limitate, acquistare consente di accedere a prestazioni di modello che difficilmente potrebbero replicare internamente.
Per i casi d’uso più standardizzati, come l’elaborazione delle fatture o la previsione dell’abbandono clienti, una soluzione esterna può generare valore rapidamente senza richiedere sviluppo interno approfondito.
I rischi e le criticità del buy
L’acquisto comporta, però, rischi di dipendenza dal fornitore, limiti di personalizzazione e minor controllo sul dato. Una ricerca Zapier mostra che quasi tre organizzazioni su quattro segnalano un impatto negativo sull’operatività quotidiana in caso di perdita del proprio fornitore AI principale e solo il 6% potrebbe farne a meno senza conseguenze. Questa evidenza dovrebbe far riflettere i CIO sull’assoluta necessità di definire in anticipo le criticità nella relazione con il vendor e quale sia il piano di uscita in caso di rallentamento del servizio, includendo nei contratti clausole esplicite di portabilità dei dati.
Va inoltre considerato che, come indicato da Bharat Bhushan, Partner Tech & Data di KPMG, «convincere un fornitore a sviluppare una funzionalità specifica può garantire un periodo di esclusiva, ma una volta trascorso quel periodo la stessa funzionalità diventa disponibile per l’intero settore, azzerando il vantaggio competitivo temporaneo».
Il modello ibrido, la scelta prevalente
Sempre più implementazioni AI in produzione non discriminano in modo netto tra build e buy, ma combinano e fondono insieme il meglio di entrambi gli approcci. La domanda decisiva non è se sviluppare o acquistare, ma quali componenti dello stack AI convenga comprare e quali costruire per preservare specificità e differenziazione.
I principali approcci ibridi
Tra i modelli più diffusi c’è quello che parte da un fornitore per validare rapidamente il valore di un caso d’uso, per poi passare a uno sviluppo interno una volta compresa la logica del problema e formati i team.
Un secondo approccio, definito componibile, prevede l’uso di API o modelli standard per funzioni comuni come riconoscimento vocale o elaborazione del linguaggio naturale, mantenendo però internamente la logica decisionale e i flussi di lavoro critici.
Un terzo modello, più orientato alla governance del dato, mantiene interna tutta la gestione delle informazioni sensibili mentre affida a servizi esterni l’esecuzione dei modelli tramite API sicure.
Anche un’analisi di Gartner descrive uno scenario in cui l’AI arriva ormai “da ogni dove” –integrata nel software esistente (ERP, CRM, strumenti di gestione), soluzioni “Bring Your Own AI” scelte autonomamente dai singoli reparti e AI costruita o combinata internamente dai team di ingegneria. La combinazione incontrollata di queste fonti può generare sovrapposizioni, costi inutili e debito tecnico, da cui l’importanza di un livello di governance centralizzato basato su fiducia, rischio e sicurezza (TRiSM).
Conviene sempre puntare su un approccio ibrido tra build e buy?
L’approccio ibrido è la direzione verso cui si sta orientando la maggior parte delle organizzazioni mature. Funziona bene quando l’azienda vuole ridurre il rischio di dipendenza da un singolo fornitore mantenendo, però, margini di controllo sui componenti più critici per il proprio vantaggio competitivo.
Per le organizzazioni agli inizi del percorso AI, partire con soluzioni vendor e sviluppare capacità interne in un secondo momento resta spesso la strada più sostenibile.
I sette criteri che orientano la decisione
Lo studio Capgemini individua alcune discriminanti fondamentali in grado di indirizzare la scelta verso l’una o l’altra opzione.
- Il primo criterio è l’allineamento strategico. Se la capacità AI definisce il modo in cui l’azienda compete, acquistarla da un vendor significa condividere lo stesso vantaggio con tutti i concorrenti che hanno accesso alla stessa piattaforma.
- Il secondo è la complessità tecnica. Più l’AI deve integrarsi in flussi di lavoro proprietari o in una logica decisionale unica, meno un prodotto preconfezionato riesce a rispondere davvero al bisogno.
- Il terzo riguarda la disponibilità di risorse e talenti interni, che resta la discriminante più rilevante del successo di un progetto di sviluppo custom.
- Il quarto è il time-to-market. Quando la velocità è determinante, l’acquisto vince quasi sempre, anche considerando che, secondo i dati Deloitte, il 75% delle organizzazioni fatica ancora a portare un progetto AI dal Proof of Concept alla scala aziendale, indipendentemente dal percorso scelto.
- Il quinto criterio è il costo totale di proprietà (TCO), che va valutato a livello di portfolio e non caso per caso, perché è proprio a quel livello che si concentrano i maggiori vantaggi di riutilizzo e velocità.
- Il sesto è la scalabilità. Strumenti che funzionano bene per un pilota o un singolo team possono diventare inefficienti quando la governance cresce in modo non lineare.
- Il settimo, infine, è la tolleranza al rischio, legata alla presenza di framework di governance costruiti fin dall’inizio del progetto e non aggiunti in un secondo momento. La sicurezza a posteriori può compromettere l’adozione della soluzione e creare vulnerabilità che un’impostazione corretta fin dall’avvio avrebbe evitato.
Quali dati servono per valutare correttamente un fornitore AI
Oltre alle capacità tecniche della piattaforma, è necessario valutare la stabilità del fornitore, le clausole contrattuali su portabilità dei dati e piani di uscita, e l’esposizione al rischio in caso di interruzione del servizio o di aumento dei prezzi.
Diversificare i fornitori e mantenere piani di contingenza sono pratiche sempre più diffuse tra le aziende, proprio per limitare questo tipo di rischio.
Build vs buy nell’AI: perché non è una scelta una tantum
La scelta build vs buy andrebbe trattata come una disciplina operativa continua, con revisioni periodiche dei fornitori e criteri di uscita definiti fin dall’inizio, piuttosto che come una decisione di procurement definitiva.
Ogni decisione di questo tipo, infatti, non è “incisa sulla pietra” ma va rivalutata periodicamente. Le capacità dei fornitori e le tecnologie AI evolvono rapidamente e la decisione di sviluppare internamente presa oggi potrebbe avere un’alternativa competitiva più standardizzata ed economica fornita da un vendor già nell’arco di pochi mesi.
Partecipa alla community