Vendor lock-in agenti AI: come evitarlo con il partner giusto

Nell’estate 2026 chi gestisce un agente AI in azienda ha toccato con le mani cosa significa vendor lock-in negli agenti AI: il 5 agosto Anthropic ha ritirato definitivamente Claude Opus 4.1, un modello che era stato dichiarato deprecato il 5 giugno. Due mesi esatti tra l’annuncio e lo spegnimento. Chi aveva costruito un agente con quel modello nel nome, i prompt calibrati sul suo comportamento e nessuno strato di astrazione in mezzo, ha passato agosto a rimettere in piedi qualcosa che funzionava. Non è un guasto: è la policy, pubblicata e rispettata. Il punto è che il calendario non era suo.

È esattamente qui che il lock-in smette di essere un tema da convegno e diventa una voce di bilancio. E la domanda che i decisori delle PMI italiane si stanno facendo, dopo un anno di listini che si muovono, modelli che scompaiono e piattaforme che promettono di fare tutto, non è più “quale AI scelgo”, ma “quanto mi costa cambiare idea”. Questo articolo prova a rispondere con numeri, con le fonti primarie dei fornitori, e con quello che la normativa europea vi permette già di pretendere per contratto.

In questo articolo scoprirai:

• Che cos’è il vendor lock-in negli agenti AI e perché non somiglia a quello del cloud
• Quanto costa davvero cambiare fornitore: i numeri che circolano nel 2026
• Dove si annida il lock-in: prompt, dati, memoria vettoriale e workflow
• Come si progetta un’architettura svincolata: gateway, standard aperti e MCP
• L’approccio multi-modello: perché in Mimir lavoriamo con Claude, GPT e Mistral
• Cosa potete pretendere per contratto grazie al Data Act europeo
• Le domande da fare al partner AI prima di firmare

Che cos’è il vendor lock-in negli agenti AI e perché non somiglia a quello del cloud

La definizione classica è di Shane Greenstein e risale al 1997: il lock-in si verifica quando i costi di uscita diventano proibitivi, e la dipendenza sopravvive alla convenienza. È la stessa definizione che usa la letteratura sull’AI procurement pubblicata sull’ITEA Journal, che aggiunge un dettaglio scomodo: il lock-in non è uno stato tecnico, è uno stato economico. Non sei bloccato perché non puoi migrare. Sei bloccato perché il preventivo per migrare è più alto del danno che stai subendo restando.

Con il cloud tradizionale il perimetro era leggibile: dati in un database, applicazioni su macchine virtuali, un piano di uscita che un sistemista sapeva disegnare. Con un agente AI il perimetro si moltiplica. Come mettono in fila sia l’ITEA Journal sia Kong, le applicazioni non dipendono più soltanto da database e ambienti cloud: dipendono da modelli, da formati di prompt, da protocolli di connessione agli strumenti e da memorie che l’agente si è costruito lavorando.

I quattro tipi di lock-in che riguardano davvero un agente AI

La stessa fonte accademica distingue quattro categorie, e vale la pena tenerle separate perché si combattono con contromisure diverse. Il platform lock-in lega addestramento e deployment all’ecosistema di un singolo hyperscaler attraverso servizi proprietari e API custom. Il data lock-in nasce quando dataset e pipeline di preprocessing sono ottimizzati per formati specifici del fornitore, e l’estrazione diventa un progetto a sé. Il model lock-in è la dipendenza da framework proprietari, acceleratori hardware o librerie di ottimizzazione che non si standardizzano. E poi c’è quello che nessuno mette nei preventivi: l’expertise lock-in, cioè le persone. Un team che ha imparato uno strumento specifico produce inerzia organizzativa, e quell’inerzia è capitale umano investito che nessuno vuole svalutare.

Se state ancora ragionando su cosa sia un agente e cosa sappia fare davvero, la nostra guida agli agenti AI mette in fila i concetti prima di questa discussione. Qui diamo per assunto che l’agente vi serva: la domanda è a quali condizioni.

Quanto costa davvero cambiare fornitore: i numeri che circolano nel 2026

Il dato più citato sul costo di una migrazione enterprise è di CIO Dive, novembre 2025, ripreso da Kong: 315.000 dollari di media per progetto di migrazione. È una cifra enterprise, e su una PMI italiana va scalata, ma la struttura del costo non cambia, e nemmeno la sua natura: è un costo che si paga tutto in una volta, in un momento che non hai scelto tu.

Il caso più brutale nella letteratura è quello del Dipartimento dell’Agricoltura statunitense, riportato dallo stesso ITEA Journal: 112 milioni di dollari pagati in più per restare su Microsoft Office anziché passare a Google Workspace, proprio per evitare costi di switching ancora più alti. Non è una scelta irrazionale. È il lock-in che funziona come progettato: rende razionale pagare di più.

Deprecazione dei modelli: il vendor lock-in che arriva col calendario del fornitore

Sul fronte AI, però, il costo più insidioso non è la migrazione volontaria. È quella imposta. Le policy ufficiali di deprecation dei due principali fornitori sono pubbliche e vanno lette come si legge una clausola contrattuale. OpenAI dichiara almeno 6 mesi di preavviso per i modelli generalmente disponibili, 3 mesi per le varianti specializzate, e fino a sole 2 settimane per i modelli in preview. Anthropic si impegna a un minimo di 60 giorni per i modelli rilasciati pubblicamente, con un ciclo di vita in quattro stati, active, legacy, deprecated, retired, e una data di ritiro assegnata al momento della deprecazione.

Confrontate i due numeri: 6 mesi contro 60 giorni. Sono entrambe policy legittime e trasparenti, e nessuna delle due è un inganno. Ma se la vostra architettura non tollera una sostituzione di modello in 60 giorni, avete già un debito tecnico e non lo sapete. Va detto anche il rovescio: Anthropic pubblica per ogni modello attivo una data “non prima di”, Opus 4.5 non prima del 24 novembre 2026, Haiku 4.5 non prima del 15 ottobre 2026, e si è impegnata pubblicamente alla conservazione a lungo termine dei pesi dei modelli ritirati. Trasparenza c’è. Il calendario resta loro.

Dove si annida il lock-in: prompt, dati, memoria vettoriale e workflow

Il lock-in di un agente non sta in un posto solo, e questa è la ragione per cui le checklist generiche non aiutano. Conviene smontare l’agente nei suoi quattro strati portabili e chiedersi, per ciascuno, dove finisce la roba vostra e dove comincia quella del fornitore.

Prompt e fine-tuning: lo strato meno portabile di tutti

Kong lo dice senza giri di parole: i prompt calibrati sul comportamento di un modello non si trasferiscono in modo pulito, e i modelli fine-tuned sono per costruzione specifici del fornitore. Questo è il punto in cui la maggior parte delle aziende sottovaluta il problema, perché un prompt sembra testo, un file, qualcosa che si copia. In realtà un prompt di produzione è il risultato di decine di cicli di test contro un modello preciso, e cambiare modello significa rifare quel lavoro, non copiarlo. Se avete investito in prompt engineering seriamente, quello è un asset: pretendete che sia versionato in un repository vostro, in testo, non dentro l’interfaccia web di una piattaforma.

Memoria vettoriale ed embedding: chi possiede la conoscenza dell’agente

Un agente che sa qualcosa della vostra azienda lo sa perché qualcuno ha indicizzato documenti, procedure e storico in un database vettoriale, è il meccanismo che chiamiamo RAG. Qui il lock-in ha due facce. La prima è il database: se è gestito dal fornitore e non è esportabile in un formato standard, gli snapshot che i motori vettoriali serie documentano, la conoscenza dell’agente non è vostra. La seconda è più subdola: gli embedding sono legati al modello che li ha prodotti. Cambiare modello di embedding significa reindicizzare tutto, perché i vettori vecchi e nuovi non vivono nello stesso spazio, e le distanze fra loro, che sono il cuore di come una ricerca semantica trova la pagina giusta, semplicemente non significano più nulla. Il documento sorgente, quindi, va conservato sempre: è l’unico artefatto davvero portabile della catena.

Workflow e orchestrazione: quando migrare diventa un progetto di sviluppo

L’ultimo strato è quello che secondo Kong distingue il lock-in dell’AI da tutti i precedenti: gli agenti multi-step si accoppiano strettamente al framework di un singolo fornitore, e a quel punto la migrazione non è più una modifica di configurazione ma un progetto di sviluppo con budget e scadenze. Nello stesso pezzo si cita il State of AI 2026 di Deloitte: solo il 20% delle aziende ha una governance matura per gli agenti autonomi. Vale la pena leggerlo insieme alle cause per cui i POC si bloccano prima della produzione: sono spesso le stesse.

Come si progetta un’architettura svincolata: gateway, standard aperti e MCP

La buona notizia è che la contromisura è nota, condivisa dai fornitori più diversi e sorprendentemente convergente. Constellation Research la chiama “neutral enterprise control layer”: uno strato di controllo che resta neutrale rispetto ai fornitori e copre integrazione, API, accesso ai dati, identità, osservabilità, governance e model routing. La regola che ne deriva è secca e vale come criterio di acquisto: nessun fornitore deve possedere i control plane di identità, storage, routing dei modelli, orchestrazione, integrazione e governance, a meno che non ci sia una ragione di business precisa.

AWS arriva alla stessa conclusione partendo da un altro lato, nel suo articolo sui pattern enterprise per scalare l’AI agentica senza lock-in: si standardizza sotto il livello applicativo, identità, enforcement delle policy, osservabilità, routing, e si lascia flessibilità su come gli agenti vengono costruiti ed eseguiti. Il termine tecnico è disaccoppiare la governance dall’esecuzione. Tradotto per un imprenditore: le regole sono di casa vostra, il motore è sostituibile.

Tre appigli concreti contro il vendor lock-in: gateway, formati standard, MCP

Sul piano pratico, i tre appigli concreti sono questi. Primo, parlare ai modelli attraverso un’astrazione e mai direttamente, è la raccomandazione centrale di TrueFoundry, che misura il costo di quello strato in circa 3-5 millisecondi di latenza aggiuntiva e oltre 350 richieste al secondo su una singola vCPU. È un prezzo trascurabile per la libertà che compra. Secondo, usare formati API standard: la compatibilità con il formato OpenAI è diventata di fatto la lingua franca, e permette di riusare gli SDK esistenti quando si cambia fornitore. Terzo, gli standard aperti per la connessione agli strumenti. Il Model Context Protocol si descrive come “una porta USB-C per le applicazioni AI” ed è supportato trasversalmente da Claude, ChatGPT, VS Code e Cursor: si costruisce l’integrazione una volta e la si riusa altrove. Se volete capire come funziona sotto il cofano, abbiamo una guida dedicata agli MCP Server. È la differenza fra un’integrazione che è vostra e un’integrazione che è dentro la piattaforma di qualcun altro.

L’approccio multi-modello: perché in Mimir lavoriamo con Claude, GPT e Mistral

La strategia multi-modello non è una posa da fornitore neutrale: è la conseguenza operativa di tutto quello che precede. Se l’architettura è disaccoppiata, usare più modelli non costa quasi niente in più, e se non è disaccoppiata, non riuscite a usarne più di uno nemmeno volendo. Il multi-modello è il test che dice se l’astrazione funziona davvero, non un obiettivo a sé: è la stessa tesi che sostiene AvePoint nella sua analisi sulla strategia multi-modello.

In Mimir gli agenti sono progettati per lavorare con Claude di Anthropic, i modelli GPT di OpenAI e Mistral, e la scelta si fa per compito, non per fedeltà: un modello di frontiera dove serve ragionamento complesso, un modello piccolo e rapido dove serve classificare o smistare, con il routing dinamico che AWS descrive come allineamento fra compito e risorsa su costo, latenza e accuratezza. Sul risparmio che questo produce abbiamo scritto i conti in chiaro parlando di quando le API convengono rispetto all’abbonamento.

Modelli a pesi aperti: la via d’uscita dal lock-in che nessuno può togliervi

Mistral merita una nota a parte, e non per patriottismo europeo. Sull’organizzazione ufficiale Mistral su Hugging Face sono pubblicati oltre settanta modelli con i pesi scaricabili, da Ministral 3 da 8 miliardi di parametri fino a Mistral Large 3. Un modello di cui potete scaricare i pesi è l’unica forma di uscita che nessun fornitore può togliervi: anche se non lo mettete in produzione, la sua esistenza cambia la vostra posizione negoziale, perché una via d’uscita che esiste vale anche quando non la percorrete. È la ragione per cui in una valutazione seria un modello a pesi aperti va tenuto nel perimetro almeno come piano B testato, non come slide.

Il rovescio della medaglia va detto con la stessa onestà: il multi-modello aggiunge complessità. Servono valutazioni comparabili fra modelli, un sistema di test che dica se la sostituzione ha peggiorato le risposte, e qualcuno che quelle valutazioni le guardi. È lavoro, e chi vi dice il contrario vi sta vendendo qualcosa. È anche il motivo per cui la scelta fra agente custom e soluzione off-the-shelf, e più a monte fra soluzione su misura e SaaS generalista, non si decide sulla funzionalità ma sull’architettura che ci sta sotto.

Il Data Act cambia le carte: cosa potete pretendere dal contratto già oggi

Questo è il pezzo che nella letteratura in lingua inglese quasi non compare, e che per un’azienda italiana è il più utile. L’Unione Europea ha deciso che il lock-in non è solo un problema di architettura ma anche di diritto contrattuale, e il Data Act contiene un capo dedicato al cambio di fornitore che vale per i servizi di trattamento dati, e, come chiarisce l’analisi di Alston & Bird, la definizione copre IaaS, PaaS e anche il SaaS, per i servizi forniti a clienti nell’Unione indipendentemente da dove abbia sede il fornitore.

Le scadenze concrete sono tre, e le riassume anche l’analisi di Latham & Watkins sui nuovi obblighi di switching. Il preavviso massimo che vi si può imporre per avviare il passaggio è di due mesi. La finestra entro cui il fornitore deve completare il passaggio è di 30 giorni dalla richiesta, estendibile solo dove tecnicamente infattibile. E dal 12 gennaio 2027 gli oneri di switching sono in linea generale vietati: nel periodo transitorio aperto il 12 settembre 2025 possono essere solo ridotti e non superiori ai costi effettivamente sostenuti per il passaggio.

Clausole anti lock-in da mettere nel capitolato

Ma la parte che conviene usare subito, prima ancora del 2027, è quella sugli obblighi contrattuali. Il fornitore deve supportare la vostra strategia di uscita con assistenza ragionevole, deve specificare chiaramente quali dati e asset digitali sono esportabili e portabili, e deve dichiarare per iscritto restrizioni e limiti tecnici del passaggio. Tradotto in una richiesta operativa da mettere in un capitolato: chiedete l’elenco nominativo degli artefatti esportabili, prompt, configurazioni, log, documenti sorgente, embedding, definizioni di workflow, e il formato in cui vi arrivano. Un fornitore che quell’elenco non lo sa scrivere vi sta dicendo qualcosa di importante su come è fatta la sua piattaforma. Su questa linea si muove anche uno studio del 2025 sull’AI procurement, che raccomanda contratti modulari, doppia fonte per i componenti critici e clausole esplicite sui diritti relativi a dati, pesi dei modelli e parametri di addestramento. È lo stesso spirito con cui il AI Act impone documentazione: ciò che non è scritto non è governabile.

Le domande da fare al partner AI prima di firmare (e da dove parte l’onboarding)

Tutto quello che precede si condensa in una manciata di domande che si fanno prima della firma, non dopo. Chi possiede i prompt e in quale repository vivono. In quale formato mi restituite gli embedding e conservate i documenti sorgente. Con quanti modelli diversi l’agente può girare oggi, in produzione, senza toccare il codice applicativo. Chi tiene le chiavi API e a nome di chi sono intestate. Che cosa succede operativamente il giorno in cui il modello che stiamo usando viene deprecato con 60 giorni di preavviso, una domanda che chi costruisce agenti portabili si pone in fase di progetto, non di incidente. Ne abbiamo messe in fila una lista più lunga nelle 10 domande da fare al partner prima di firmare, e i criteri di selezione più generali stanno in 7 criteri per scegliere un partner di agenti AI.

Evitare il vendor lock-in nelle prime due settimane di onboarding

La ragione per cui in Mimir l’assistenza dedicata all’onboarding parte dalla progettazione dell’architettura, e non dal primo caso d’uso, è precisamente questa: il lock-in non si rimuove a posteriori, si evita nelle prime due settimane. Nella pratica significa decidere subito dove vivono i prompt, quale astrazione sta davanti ai modelli, in che formato si conserva la memoria vettoriale e chi è intestatario degli account presso i fornitori. Sono decisioni che costano poche ore all’inizio e centinaia di migliaia di euro dopo, è la stessa asimmetria che raccontiamo nella guida pratica all’onboarding in azienda. È anche la ragione per cui insistiamo che il servizio conti più del modello: il modello cambierà comunque, il servizio è ciò che vi accompagna attraverso il cambio. La manutenzione post-deployment non è un costo accessorio, è l’assicurazione contro il calendario di qualcun altro.

Se state valutando un agente AI per la vostra azienda e la domanda che avete in testa è “come faccio a non restare incastrato”, è la domanda giusta e vale la pena farla a voce. Cosa aspettarsi da una consulenza sugli agenti AI lo abbiamo scritto per esteso: guardiamo insieme i vostri processi, l’architettura che serve e cosa vi servirebbe per poter cambiare idea fra due anni senza ricominciare da zero. Nessun impegno, e se la risposta è che vi conviene una soluzione chiavi in mano anziché self-service, ve lo diciamo.

Fonti:

• ITEA Journal — Avoid vendor lock-in in AI procurement
• arXiv 2509.23471 — ricerca su AI procurement e lock-in
• Kong — Vendor lock-in (learning center)
• Constellation Research — How to avoid vendor lock-in in the AI age
• AWS — Scaling agentic AI: enterprise patterns without vendor lock-in
• TrueFoundry — Vendor lock-in prevention e costo del gateway
• BlueBag — Avoid LLM vendor lock-in
• MindStudio — How to build an AI agent avoiding vendor lock-in
• AvePoint — AI vendor lock-in e strategia multi-modello
• Model Context Protocol — documentazione ufficiale
• OpenAI — policy ufficiale di deprecation delle API
• Anthropic — Model deprecations (Claude Platform)
• Mistral — documentazione sui pesi dei modelli
• Mistral AI su Hugging Face — modelli con pesi pubblicati
• Mixpeek — Embedding portability e versioning
• Qdrant — snapshot ed export di un database vettoriale
• Alston & Bird — EU Data Act: switching requirements per i servizi cloud
• Latham & Watkins — EU Data Act, i nuovi obblighi di switching