Negli ultimi due anni molte aziende hanno integrato l’intelligenza artificiale nei propri processi con una velocità impressionante: un chatbot qui, un’automazione là, un assistente interno collegato ai documenti aziendali. Quasi sempre, però, la scelta del fornitore è avvenuta in fretta, guardando alla demo più convincente. Il risultato è un rischio che emerge solo dopo mesi: il vendor lock-in AI, cioè la dipendenza da un unico fornitore di modelli o piattaforme, tanto forte da rendere costoso, lento o impossibile cambiare strada.
In questo articolo spiego come ragiono quando progetto soluzioni AI per le aziende, in modo che restino portabili: quali segnali indicano un lock-in, quali scelte architetturali lo riducono e quali clausole contrattuali conviene verificare prima di firmare.
Cos’è il vendor lock-in AI e perché è diverso dal solito
Il lock-in non è una novità: chi ha migrato un gestionale o un servizio email lo conosce bene. Con l’AI, però, la dipendenza si crea su più livelli contemporaneamente:
- Il modello: prompt, istruzioni e comportamenti vengono ottimizzati su un LLM specifico. Cambiando modello, le risposte cambiano.
- I dati: embedding, indici vettoriali, cronologie di conversazione e file caricati restano spesso nel formato proprietario della piattaforma.
- Le integrazioni: agenti e workflow costruiti con strumenti chiusi, con logica non esportabile.
- Il prezzo: listini che cambiano, modelli deprecati con pochi mesi di preavviso, limiti di utilizzo rivisti unilateralmente.
Il mercato dei modelli si muove ogni pochi mesi: quello che oggi è il migliore rapporto qualità/prezzo domani potrebbe non esserlo più. Un’azienda legata a un solo fornitore non può approfittarne.
I segnali che il tuo progetto AI è già in lock-in
Quando analizzo un progetto esistente, faccio alcune domande molto pratiche:
- Se domani il fornitore raddoppiasse i prezzi, quanto tempo servirebbe per passare a un’alternativa?
- Possiamo esportare tutti i dati (documenti, embedding, log, conversazioni) in un formato standard?
- I prompt e la logica degli agenti sono versionati nel nostro repository o vivono solo nell’interfaccia del fornitore?
- Esiste un contratto che definisce dove vengono trattati i dati e con quale preavviso vengono ritirati i modelli?
Se la risposta a più di una domanda è “non lo sappiamo”, il rischio è concreto. Non significa che si debba rifare tutto, ma che conviene introdurre delle vie di uscita prima che servano.
Architettura portabile: come ridurre il vendor lock-in AI
La regola che applico è semplice: il fornitore di AI deve essere un componente sostituibile, non il cuore del sistema. In pratica questo si traduce in alcune scelte tecniche.
1. Un livello di astrazione tra applicazione e modello
L’applicazione non chiama direttamente l’API di un singolo provider, ma passa da un piccolo strato intermedio (un gateway o una libreria interna) che espone un’interfaccia uniforme. Cambiare modello diventa una modifica di configurazione, non una riscrittura. Lo stesso approccio permette di fare model routing, scegliendo il modello AI giusto per ogni attività, e di confrontare i fornitori sui propri casi reali.
2. I dati restano tuoi, nel tuo formato
Documenti originali, chunk di testo e metadati vanno conservati in un database sotto il controllo dell’azienda. Gli embedding si possono sempre rigenerare con un altro modello, ma solo se la sorgente è disponibile. Per questo preferisco vector database open source o estensioni di database standard, invece di archivi vettoriali gestiti e chiusi.
3. Prompt e logica sotto versionamento
Prompt di sistema, definizioni dei tool, regole di business degli agenti: tutto va nel repository Git del progetto, con test automatici. Quando si cambia modello, si rilanciano i test e si vede subito cosa si comporta diversamente. È lo stesso principio che descrivo parlando di testing degli agenti AI prima del lancio.
4. Standard aperti per le integrazioni
Per collegare l’AI ai sistemi aziendali uso, dove possibile, protocolli aperti come il Model Context Protocol e workflow su strumenti self-hosted come n8n. Un connettore scritto su uno standard aperto funziona con più modelli e più client, invece di restare prigioniero di un singolo ecosistema.
5. Un piano B self-hosted
Non sempre serve, ma per i processi critici valuto la possibilità di avere un modello open source di riserva, anche meno potente, in esecuzione su infrastruttura propria. Ne ho parlato nell’articolo su LLM open source self-hosted per un’AI privata in azienda: oltre alla continuità operativa, offre maggiore controllo sui dati.
Le clausole contrattuali da verificare
La parte tecnica non basta. Prima di scegliere un fornitore di intelligenza artificiale conviene leggere con attenzione i termini di servizio e, per le aziende, il contratto di trattamento dati (DPA). Questi i punti che controllo sempre:
- Uso dei dati per l’addestramento: i dati inviati vengono usati per migliorare i modelli? Deve essere escluso in modo esplicito.
- Localizzazione del trattamento: dove vengono elaborati e conservati i dati, e con quali sub-responsabili.
- Conservazione e cancellazione: per quanto tempo restano log e input, e come si ottiene la cancellazione.
- Deprecazione dei modelli: con quanto preavviso un modello viene ritirato.
- Esportazione dei dati: in quale formato e con quali tempi si possono recuperare i propri dati alla fine del rapporto.
- Variazioni di prezzo: preavviso e diritto di recesso in caso di modifiche.
Questi aspetti si collegano direttamente agli obblighi di governance: una DPIA per l’intelligenza artificiale fatta bene deve già tenere conto di chi tratta i dati e dove.
Portabilità non significa rinunciare ai modelli migliori
Un equivoco frequente: pensare che evitare il lock-in voglia dire usare solo strumenti open source o rinunciare ai modelli commerciali più avanzati. Non è così. Si possono usare i migliori modelli sul mercato, purché l’architettura permetta di sostituirli. Il costo di questa flessibilità, se pensata dall’inizio, è minimo: qualche giorno di progettazione in più, che si ripaga la prima volta che un fornitore cambia listino o ritira un modello.
C’è anche un vantaggio negoziale: un’azienda che può cambiare fornitore in pochi giorni ha molto più potere contrattuale di una che ha costruito tutto attorno a una singola piattaforma.
Da dove partire
Se hai già progetti AI in produzione, il primo passo è una ricognizione: quali fornitori usi, dove sono i dati, cosa succederebbe se uno di loro sparisse domani. Da lì si decide cosa rendere portabile subito e cosa può aspettare. Se invece stai partendo ora, è il momento migliore per impostare le fondamenta nel modo giusto.
Progetto e realizzo soluzioni di intelligenza artificiale, agenti AI e automazioni per aziende, con un’attenzione particolare a portabilità, sicurezza e controllo dei dati: dall’infrastruttura self-hosted all’integrazione con i sistemi esistenti. Se vuoi valutare la tua situazione o avviare un progetto AI senza legarti a un solo fornitore, contattami per una prima analisi oppure scopri di più su cornelcaba.com.
