L'AI doveva dare vantaggio alle aziende. Può anche creare una nuova dipendenza
Fino a pochi anni fa la discussione sul vendor lock-in riguardava principalmente il cloud, gli ERP, i database o le piattaforme tecnologiche chiave.
Le aziende si chiedevano: Possiamo spostare l'applicazione su un altro cloud provider?, Possiamo cambiare il database?, Possiamo abbandonare un sistema specifico?
Oggi a questa lista si aggiunge un nuovo elemento: l'intelligenza artificiale.
Le organizzazioni costruiscono sempre più spesso sistemi che utilizzano modelli linguistici, AI generativa, soluzioni RAG, automazione dei processi e agenti AI. I modelli diventano parte delle applicazioni, dei processi di vendita, dell'assistenza clienti, dell'analisi documentale, dei sistemi decisionali e del lavoro quotidiano dei team.
In pratica questo significa che un'azienda può cominciare a dipendere non solo da un software specifico, ma anche dal fornitore dell'intelligenza che alimenta i suoi sistemi.
Ed è qui che nasce il problema. Perché usare un servizio AI è una cosa; dipenderne è un'altra.
Questa è la differenza tra una consapevole dipendenza tecnologica e il vendor lock-in.
Cos'è esattamente l'AI Vendor Lock-in?
Vendor lock-in indica una situazione in cui un'organizzazione è così strettamente legata a un singolo fornitore di tecnologia che il passaggio a una soluzione concorrente diventa difficile, costoso, dispendioso in termini di tempo o rischioso.
Nel mondo dell'AI può assumere molte più forme rispetto alla classica dipendenza da un'API singola.
Un'azienda può dipendere da:
- un modello AI specifico,
- un fornitore di API particolare,
- un formato di comunicazione definito,
- funzionalità disponibili esclusivamente presso un fornitore,
- un sistema di agenti,
- un'infrastruttura cloud,
- un modo specifico di memorizzare i dati,
- un meccanismo di embedding particolare,
- un sistema RAG determinato,
- un modo di invocare strumenti da parte degli agenti,
- prompt ottimizzati per un modello specifico,
- competenze del team legate a un unico ecosistema.
Quindi la domanda: "Usiamo OpenAI?"
è decisamente troppo semplice.
Una domanda migliore è: "Quanto sarebbe difficile per noi cambiare fornitore di AI se dovessimo farlo tra sei mesi?"
Se la risposta è: "Non lo sappiamo." - potrebbe essere il primo segnale di allarme.
OpenAI, Anthropic, Google - la scelta del fornitore conta?
Oggi sul mercato esistono diversi ecosistemi molto forti di modelli e servizi AI, tra cui le soluzioni offerte da OpenAI, Anthropic e Google.
Ognuno di questi fornitori sviluppa propri modelli, API, strumenti e servizi aggiuntivi.
Il problema non è che uno di loro sia "cattivo". Anzi, spesso non lo è.
Usare modelli pronti e di alta qualità è spesso la scelta migliore dal punto di vista business. Non tutte le aziende dovrebbero addestrare un proprio modello. Non tutte hanno bisogno di infrastruttura GPU dedicata. Non tutte devono costruire l'intero stack AI da zero.
Affidarsi a un fornitore esterno permette di entrare più rapidamente nel mercato, contenere i costi iniziali e sfruttare tecnologie che sarebbero inaccessibili se sviluppate internamente.
Il problema sorge quando l'azienda smette di considerare il fornitore come un componente intercambiabile e progetta l'intero prodotto come se quel fornitore dovesse restare immutato per i prossimi 10 anni.
E questo non lo si può garantire...
I modelli vengono aggiornati, le versioni precedenti vengono ritirate, i prezzi cambiano, i limiti cambiano, le API si evolvono, emergono nuovi modelli, cambiano le condizioni di licenza, cambiano le capacità della concorrenza.
Questo è normale nel mercato tecnologico.
Per questo l'architettura AI dovrebbe considerare non solo: "Qual è il modello migliore oggi?"
ma anche: "Quale prezzo pagheremo se tra un anno dovremo usare un modello diverso?"
La più grande trappola - "tanto cambiamo solo l'API"
A prima vista una migrazione può sembrare banale.
Abbiamo un'applicazione. L'applicazione invia una richiesta al modello. Il modello risponde. Cambiamo fornitore. Fat t o...
Nella realtà la situazione può essere completamente diversa.
Immaginiamo un'applicazione sviluppata per due anni intorno a un singolo modello.
In questo periodo il team ha:
- creato centinaia di prompt,
- ottimizzato il loro contenuto,
- adattato il formato delle risposte,
- costruito un sistema RAG,
- configurato il tool calling,
- sviluppato agenti,
- progettato workflow,
- preparato test,
- formato gli utenti all'uso del sistema.
Dopo due anni il modello potrebbe non essere più disponibile nella stessa versione.
Oppure il prezzo potrebbe aumentare, oppure un modello concorrente potrebbe essere nettamente migliore, oppure l'azienda potrebbe voler spostare parte dei dati in un altro ambiente.
In teoria basta cambiare l'API. - in pratica potrebbe essere necessario riesaminare e ritestare tutta la logica del sistema.
Perché?
Perché i modelli non sono identici:
- Si differenziano nel modo in cui interpretano le istruzioni.
- Si differenziano nella qualità delle risposte.
- Si differenziano nel comportamento con contesti lunghi.
- Si differenziano nell'uso degli strumenti.
- Si differenziano nel supporto per structured output.
- Si differenziano nella multimodalità.
- Si differenziano nella velocità.
- Si differenziano nel prezzo.
- Si differenziano anche nel comportamento nei casi limite.
Per questo la migrazione tra modelli può somigliare più alla migrazione di un intero componente di business che alla semplice sostituzione di un URL.
Cinque livelli di AI Vendor Lock-in
Vale la pena guardare il vendor lock-in in modo più ampio.
1. Lock-in del modello
Il livello più semplice.
L'app è stata ottimizzata per un modello specifico.
Un prompt funziona molto bene con un modello, ma peggio con un altro.
Il sistema si basa su capacità specifiche di quel modello.
Cambiare richiede ritarature.
2. Lock-in dell'API
Il sistema usa direttamente funzioni di un fornitore specifico.
Più funzioni specifiche usiamo, più difficile sarà migrare.
Non si tratta solo di generare testo.
Contano anche:
- structured outputs,
- function calling,
- tool calling,
- multimodalità,
- gestione del contesto,
- meccanismi di sicurezza,
- sistemi di agenti.
3. Lock-in dei dati
I dati possono essere memorizzati in modo fortemente legato a un ecosistema specifico.
Questo riguarda anche:
- embedding,
- indici vettoriali,
- metadati,
- storia delle interazioni,
- configurazioni RAG.
La migrazione può richiedere non solo il trasferimento dei dati, ma anche il loro rielaboro.
4. Lock-in dell'architettura
Questo è un livello molto più serio.
L'intera applicazione è stata progettata attorno a un fornitore.
I suoi meccanismi sono presenti in molti punti del sistema.
In questo caso non sostituiamo un singolo componente.
Ristrutturiamo una parte dell'architettura.
5. Lock-in organizzativo
Spesso il problema più sottovalutato.
Il team conosce un solo ecosistema.
Tutte le competenze sono concentrate su una sola soluzione.
Documentazione, procedure, test e know-how sono legati a un unico fornitore.
Anche se tecnicamente è possibile cambiare modello, l'organizzazione non ha le persone che sanno come farlo.
A quel punto il vendor lock-in smette di essere solo un problema tecnologico.
Diventa un problema di business.
Il multi-model risolve il problema?
La risposta naturale è: "Se un fornitore è un rischio, usiamone diversi."
Non è sempre la strategia migliore.
L'architettura multi-model ha costi propri.
Bisogna gestire:
- molte API,
- diversi limiti,
- modelli di prezzo differenti,
- livelli di qualità variabili,
- formati di risposta diversi,
- test,
- monitoring,
- sicurezza.
Il sistema diventa più complesso.
Perciò l'obiettivo non dovrebbe essere: "Dobbiamo usare cinque fornitori."
L'obiettivo dovrebbe essere: "Dobbiamo avere la possibilità di cambiare fornitore se il business lo richiede."
Questa è la differenza cruciale.
Non tutte le aziende hanno bisogno del Multi-Model.
Tutte però dovrebbero sapere come sarebbe la migrazione verso un altro modello.
AI Gateway e Model Gateway - uno strato che separa l'applicazione dal fornitore
Una delle soluzioni per ridurre la dipendenza è introdurre uno strato intermedio.
Può assumere la forma di un AI Gateway o di un Model Gateway.
In forma semplificata l'architettura può essere così:
Applicazione di business
↓
Strato di astrazione AI
↓
Routing dei modelli
↓
Adapter del fornitore
↓
OpenAI / Anthropic / Google / modello open-weight / modello locale
Così la logica di business non deve conoscere i dettagli di ogni fornitore.
Possiamo avere uno strato che gestisce:
- selezione del modello,
- routing,
- fallback,
- controllo dei costi,
- monitoring,
- logging,
- policy di sicurezza,
- gestione dei limiti.
In caso di outage di un fornitore il sistema può tentare un altro modello.
Se i prezzi aumentano possiamo cambiare il routing.
Quando emerge un modello migliore possiamo eseguire test e decidere la migrazione.
Non significa che la migrazione sarà indolore.
Significa però che è stata progettata come una possibilità reale.
Model Router - l'AI non deve scegliere sempre lo stesso modello
Una soluzione ancora più interessante è il routing dinamico dei modelli.
Immaginiamo un sistema che riceve compiti diversi.
Compito semplice: "Riassumi questo testo."
Può essere inviato a un modello veloce ed economico.
Compito più complesso: "Analizza il documento e prepara una raccomandazione dettagliata."
Può andare a un modello più potente.
Un compito che richiede analisi di immagini può essere indirizzato a un modello multimodale.
Il sistema quindi seleziona dinamicamente il modello più adatto al compito.
Questo permette di ottimizzare:
- i costi,
- la qualità,
- i tempi di risposta,
- la disponibilità.
In questo approccio il fornitore AI smette di essere parte integrante della logica di business.
Diventa uno degli elementi dell'infrastruttura.
Ed è una modifica architetturale molto importante.
Astrarre non significa che tutti i modelli siano uguali
Qui bisogna fare attenzione a una trappola.
Si può creare una funzione interna: generateText() e pensare che il problema sia risolto.
Non è così.
I modelli non sono mattoncini LEGO intercambiabili.
Se l'applicazione sfrutta capacità specifiche di un modello, una semplice astrazione può solo nascondere il problema.
Una buona architettura dovrebbe quindi astrarre dal fornitore ma gestire consapevolmente le differenze tra modelli.
In pratica lo strato AI dovrebbe sapere che i modelli possono avere diverse:
- capacità,
- limiti,
- costi,
- livelli di qualità,
- funzionalità,
- contesti,
- parametri.
Progettare "provider-agnostic" non significa fingere che ogni modello sia uguale.
Significa che il sistema sa sfruttare consapevolmente le differenze tra i modelli.
Evals - senza di esse la migrazione AI è un azzardo
Uno degli elementi più importanti per un'architettura resistente al cambiamento sono le evals, cioè test sistematici della qualità dei modelli.
Supponiamo di avere 1000 casi d'uso reali. Li eseguiamo sul modello attuale. Poi li eseguiamo sul nuovo. Confrontiamo i risultati.
Controlliamo:
- qualità,
- correttezza,
- completezza,
- allucinazioni,
- conformità ai requisiti,
- tempo di risposta,
- costo.
Solo allora possiamo dire: "Il nuovo modello è sufficientemente buono."
Senza evals la migrazione può sembrare un esperimento. Con le evals diventa un processo ingegneristico.
Per questo le aziende che usano AI dovrebbero costruire i propri set di test. Non testare solo l'API. Testare il proprio caso d'uso di business. È una differenza enorme.
Anche i prompt possono essere fonte di vendor lock-in
I prompt spesso li trattiamo come semplici testi. In realtà possono diventare parte della logica di business.
Se per mesi il team ottimizza istruzioni per un modello specifico, il prompt può comportarsi come un pezzo di codice.
Dovrebbero quindi essere:
- versionati,
- testati,
- documentati,
- monitorati.
È utile sapere quali prompt sono critici per il funzionamento del sistema. Se cambiare modello peggiora la loro efficacia, dobbiamo sapere dove cercare il problema.
Perciò il prompt engineering nei sistemi maturi dovrebbe essere sempre più trattato come parte dell'ingegneria del software.
Modelli open-weight e modelli propri - fuga dal vendor lock-in?
I modelli open-weight e la possibilità di eseguirli su infrastruttura propria aumentano il controllo sulla tecnologia.
Ma non garantiscono automaticamente l'indipendenza completa.
Se spostiamo il modello su infrastruttura interna, continuiamo ad aver bisogno di:
- GPU,
- infrastruttura,
- MLOps,
- monitoring,
- sicurezza,
- aggiornamenti,
- competenze.
Possiamo quindi ridurre la dipendenza dal fornitore del modello, ma aumentare la dipendenza dal fornitore dell'infrastruttura. Possiamo anche usare il cloud per eseguire modelli open-weight. Allora il problema ricompare su un altro livello. Perciò è utile guardare all'indipendenza tecnologica in modo più ampio.
Non esiste un sistema completamente privo di dipendenze.
Esiste invece un sistema in cui le dipendenze sono:
- conosciute,
- controllate,
- misurabili,
- sostituibili.
La dipendenza più pericolosa può essere nelle teste del team
Immaginiamo un'azienda che usa un unico fornitore AI.
Tecnicamente potrebbe cambiare modello. Ma nessuno in azienda sa come farlo.
Il team non conosce alternative.
Non ci sono benchmark.
Non ci sono evals.
Non ci sono test.
Non c'è esperienza con altri modelli.
Tutte le soluzioni sono costruite attorno a un solo ecosistema.
Questo è lock-in organizzativo.
Perciò la resilienza al vendor lock-in richiede anche investimenti nelle competenze.
Il team dovrebbe capire:
- come funzionano i modelli,
- quali sono le differenze tra i fornitori,
- come costruire uno strato di astrazione,
- come testare i modelli,
- come misurare la qualità,
- come gestire i costi,
- come eseguire una migrazione.
Non serve che ogni sviluppatore conosca tutte le API.
Serve che l'organizzazione non sia tecnologicamente cieca rispetto a un solo ecosistema.
Quando il vendor lock-in può essere accettabile?
Il vendor lock-in non è sempre negativo.
A volte una dipendenza consapevole è una scelta business sensata.
Se:
- il fornitore offre una funzione eccezionale,
- la soluzione riduce significativamente il time-to-market,
- il costo della migrazione è noto,
- il rischio è accettabile,
- le alternative sono peggiori,
- il business ha bisogno di velocità,
allora un forte legame con un fornitore può essere giustificato.
Il problema non è il lock-in in sé. Il problema è il lock-in inconsapevole.
L'azienda dovrebbe sapere:
- da cosa dipende,
- perché dipende,
- quanto costerebbe cambiare,
- quanto durerebbe la migrazione,
- quali sono le alternative.
Solo allora si può parlare di una decisione architetturale consapevole.
Come valutare l'AI Vendor Lock-in nella tua azienda?
Vale la pena fare un semplice audit.
Poniamoci queste domande:
Possiamo cambiare modello senza rifare tutta l'applicazione?
La logica di business è indipendente dal fornitore AI?
I prompt sono versionati?
Abbiamo evals propri?
Abbiamo test di regressione per i casi d'uso più importanti?
Possiamo esportare e trasferire i dati?
Possiamo cambiare il fornitore di embedding senza perdere i dati?
Gli agenti usano uno strato di orchestrazione o sono legati direttamente a un ecosistema?
Abbiamo la possibilità di usare un modello alternativo?
Abbiamo un fallback?
Sappiamo quanto costerebbe la migrazione?
Sappiamo quanto tempo richiederebbe la migrazione?
Abbiamo persone in grado di eseguirla?
Più risposte "no", maggiore è la dipendenza.
Si può anche costruire un proprio AI Portability Score. Ad esempio valutando l'organizzazione in cinque ambiti:
Architettura - il fornitore è intercambiabile?
Dati - possiamo trasferirli?
Modelli - abbiamo alternative?
Valutazione - sappiamo confrontare i modelli?
Competenze - il team sa eseguire la migrazione?
Questo risultato non deve essere uno standard formale. Può però diventare un ottimo strumento di governance.
Perché a volte il problema non è il vendor lock-in. Il problema è che l'azienda non sa di averlo.
Come progettare un'architettura AI resistente ai cambiamenti?
Non esiste un'architettura universale. Si possono però adottare alcune regole pratiche.
Regola 1 - separa la logica di business dal fornitore AI
Non costruire l'intero sistema direttamente attorno a una singola API.
Regola 2 - usa uno strato di astrazione dove ha senso
Un AI Gateway o Model Gateway può limitare la dipendenza dell'applicazione dal fornitore.
Regola 3 - versiona i prompt
Trattali come parte del sistema, non come semplici testi volanti.
Regola 4 - costruisci le evals
Non dare per scontato che "il nuovo modello funzioni".
Verificalo.
Regola 5 - testa le alternative
Non è necessario usarle in produzione.
È utile però sapere come si comportano sui tuoi casi d'uso.
Regola 6 - controlla i dati
Non permettere che i dati di business diventino ostaggio di una piattaforma.
Regola 7 - documenta le dipendenze
Sapere dove il sistema è vincolato a un fornitore è parte della documentazione architetturale.
Regola 8 - non astrarre forzatamente
Non nascondere le differenze tra i modelli solo per ottenere una falsa portabilità.
Regola 9 - misura il costo della migrazione
Non basta dire:
"Qualcuno potrà cambiare fornitore".
Devi sapere:
"Ci vogliono tre mesi e cinque persone."
Oppure:
"Non possiamo farlo senza rifare il sistema."
Regola 10 - prendi decisioni consapevoli
A volte la scelta migliore è legarsi a un fornitore.
Ma deve essere un rischio consapevole.
Non un incidente.
La domanda che ogni CTO dovrebbe porsi
Immagina che domani il fornitore AI:
- raddoppi i prezzi,
- ritiri il modello che usiamo,
- cambi i limiti,
- limiti una funzione da cui dipende il nostro prodotto,
- smetta di soddisfare i nostri requisiti di compliance.
Cosa facciamo?
Se la risposta è: "Cambieremo fornitore."
La domanda successiva dovrebbe essere: "Quanto tempo ci vorrà?"
Un giorno?
Una settimana?
Un mese?
Sei mesi?
O magari non lo sappiamo?
Questa è la misura della nostra resilienza tecnologica.
Conclusione - non si tratta di non avere fornitori
Costruire un sistema completamente indipendente da fornitori esterni di AI può essere antieconomico, inutile o persino impossibile.
Non è questo il punto.
L'obiettivo non è l'assenza di dipendenze. L'obiettivo è la gestione consapevole delle dipendenze.
Possiamo usare OpenAI. Possiamo usare Anthropic. Possiamo usare Google. Possiamo usare modelli open-weight. Possiamo combinare soluzioni diverse.
La cosa più importante è sapere dove passa il confine tra: "usiamo la tecnologia" e "ne siamo dipendenti".
Nel mondo dell'AI questo confine può essere particolarmente difficile da vedere. Perché il vendor lock-in non nasce in un giorno. Si costruisce gradualmente. Prima integriamo un'API. Poi costruiamo una funzione. Poi aggiungiamo RAG. Poi agenti. Poi automatizziamo il processo. Poi l'intero team comincia a lavorare secondo quel sistema. E all'improvviso cambiare modello non è più cambiare un modello - è cambiare una parte dell'organizzazione.
Per questo l'architettura AI dovrebbe essere progettata pensando non solo a ciò che funziona oggi, ma anche a ciò che succederà se il mondo tecnologico cambierà domani.
Non devi costruire un sistema che funzioni senza OpenAI, Anthropic o Google. Dovresti però costruire un sistema che sappia funzionare anche quando uno di loro verrà meno.
Questa è la differenza tra usare l'AI e progettare consapevolmente la tecnologia AI.
