Il vendor lock-in si scopre quasi sempre nel momento peggiore: quando vuoi andartene.
Un’azienda costruisce un agente AI rivolto ai clienti su una piattaforma gestita. Il prodotto funziona. Poi accade una di queste tre cose: la piattaforma aumenta il prezzo per task del 40%; un concorrente rilascia un modello più veloce che la piattaforma non supporta; oppure la piattaforma viene acquisita e il tuo piano tariffario viene dismesso senza alcun supporto alla migrazione. A quel punto, ogni workflow realizzato nel formato proprietario della piattaforma, ogni prompt incorporato, ogni frammento di memoria conversazionale archiviato nel loro datastore — è di fatto sotto il loro controllo.
Il lock-in su piattaforme di agenti AI non è un rischio teorico. È una caratteristica strutturale del modo in cui la maggior parte delle piattaforme è progettata. Capire da dove viene — e cosa pretendere in una valutazione vendor — è la differenza tra un agente che cresce con il tuo business e uno che lo tiene in ostaggio.
Dove si manifesta concretamente il lock-in
Il lock-in per gli agenti AI non è una cosa sola. Si accumula su almeno cinque livelli distinti, e la maggior parte delle checklist di valutazione ne ignora la maggior parte.
Formati proprietari per i workflow
Molte piattaforme gestite memorizzano la logica dell’agente — la sequenza di tool call, i rami decisionali, i memory lookup e i gestori di fallback — in un formato JSON o visual-graph proprietario che funziona solo sulla loro infrastruttura. Non esiste uno standard aperto equivalente a un container Docker o a un semplice script Python. Se vuoi spostare l’agente su un runtime diverso, lo stai riscrivendo da zero, non esportando un file.
La domanda da fare a qualsiasi vendor prima di firmare: Puoi esportare una rappresentazione completamente eseguibile della logica dell’agente che funziona indipendentemente dalla tua infrastruttura? Se la risposta coinvolge il loro SDK proprietario o chiamate API ai loro server, hai già la risposta.
Prompt incorporati e memoria
Il comportamento dell’agente risiede nel suo system prompt e nel contesto di memoria che accumula nel tempo. Su alcune piattaforme, entrambi sono archiviati nei datastore della piattaforma in un formato accessibile solo tramite la loro API. Se hai 10.000 riassunti strutturati di conversazioni che l’agente usa per personalizzare le risposte, e questi si trovano in un vector store proprietario, migrarli significa un’esportazione, una conversione di formato e un re-indicizzazione — spesso con perdita di dati.
Alcune piattaforme spingono oltre: incorporano il tuning della persona e il comportamento di instruction-following in un modello fine-tuned proprietario. A quel punto l’identità del tuo agente è letteralmente codificata in un checkpoint di pesi che non puoi esportare.
Portabilità del modello — o la sua assenza
Le piattaforme gestite tendono sempre più a includere il proprio LLM anziché instradare verso modelli fondazionali. Questo crea un prodotto conveniente per loro e un rischio per te: la piattaforma controlla qualità, versioning e deprecazione del modello. Quando deprecano una versione e devi aggiornare — modificando potenzialmente il comportamento dell’agente — sei tu a sostenere i costi di test e remediation, mentre loro riscuotono la quota di abbonamento.
Un’architettura solida separa il runtime dell’agente dal modello. La piattaforma dovrebbe permetterti di specificare quale provider e versione del modello usare, e il contratto dovrebbe definire cosa succede quando un modello da cui dipendi viene deprecato. L’opacità su questo punto è già di per sé un segnale di rischio.
Variazioni di pricing e salti di costo
Gli abbonamenti flat-fee sembrano attraenti finché il volume non cresce. La maggior parte delle piattaforme ha una tariffazione aggressiva a livelli: si paga per esecuzione di task, per chiamata API, per seat o per token — a volte tutti e quattro. Quello che costa CHF 400/mese in fase pilota può arrivare a CHF 4.000/mese in produzione, senza alcuna protezione contrattuale contro ulteriori aumenti. Se uscire è costoso perché la tua logica, la memoria e il modello sono tutti proprietari, perdi potere contrattuale sul pricing. Le piattaforme lo sanno.
Prima di impegnarti, calcola il costo previsto a 3× e 10× del volume attuale, e chiedi se il contratto include clausole di stabilità del pricing.
Rischio di acquisizione e discontinuità del prodotto
Lo spazio delle piattaforme per agenti AI si sta consolidando rapidamente. I vendor più piccoli sono bersagli di acquisizione da parte di grandi cloud provider e software enterprise — e le acquisizioni si traducono spesso in riposizionamento dei prezzi, sunset del prodotto o migrazione forzata sullo stack dell’acquirente. Un vendor con prezzi generosi oggi potrebbe diventare il funnel di upsell di un attore molto più grande nel giro di 18 mesi. Includi la solidità organizzativa nella valutazione, accanto alle capacità tecniche.
Una checklist di due diligence prima di impegnarti
Applica queste domande a qualsiasi valutazione di piattaforma per agenti. Non sono pensate per escludere i vendor — servono a prezzare correttamente il rischio.
Esportazione e portabilità
- Puoi esportare la logica dell’agente in un formato eseguibile senza l’infrastruttura del vendor?
- Puoi esportare tutta la memoria, gli embedding e i dati di training in un formato standard (JSON, CSV, JSONL)?
- Esiste un’API per l’esportazione massiva dei dati, o solo il download manuale?
Flessibilità del modello
- Puoi specificare quale modello fondazionale (e quale versione) usa l’agente?
- Qual è la policy pubblica del vendor per la deprecazione dei modelli e le tempistiche di migrazione?
- Puoi portare il tuo modello fine-tuned o il tuo system prompt, o la piattaforma li sovrascrive?
Residenza e sovranità dei dati
- Dove sono archiviati geograficamente i tuoi dati? Per le aziende svizzere ed europee, questo è rilevante per la conformità a nLPD e GDPR — vedi Agenti AI e GDPR. L’EU AI Act aggiunge un ulteriore livello di compliance: gli obblighi per i sistemi AI ad alto rischio entrano in vigore dall’agosto 2026, il che rende le decisioni architetturali di oggi una questione di compliance per i deployment rivolti ai clienti di domani.
- Chi è il proprietario dei dati conversazionali? Il vendor può usarli per addestrare i propri modelli?
Condizioni commerciali
- Esiste un cap al prezzo o una clausola di stabilità nel contratto?
- Quali sono i diritti di recesso, e per quanto tempo il vendor garantisce l’accesso ai dati dopo la cancellazione?
- Qual è l’impegno di supporto alla migrazione in caso di discontinuità o acquisizione del prodotto?
Stima del costo di uscita
- Se dovessi migrare in sei mesi, quanto costerebbe? (Stima in giorni-sviluppatore, non solo in denaro.)
- Esiste un percorso di migrazione documentato verso alternative open-source?
Quando il lock-in è un compromesso accettabile
Il lock-in non è sempre la scelta sbagliata. Per una proof-of-concept o un pilota interno con un orizzonte di 90 giorni, il vantaggio in termini di velocità di deployment di una piattaforma gestita supera di solito il rischio di uscita. Per casi d’uso a bassa criticità — un semplice bot FAQ senza logica di business — il costo di migrazione è sufficientemente basso da rendere il rischio di lock-in trascurabile.
Dove diventa genuinamente pericoloso:
- L’agente gestisce un processo rivolto ai clienti o critico per i ricavi (supporto, preventivazione, onboarding)
- Ti aspetti di iterare significativamente sul comportamento dell’agente nell’arco di 12+ mesi
- Il tuo settore ha requisiti di residenza dei dati che la piattaforma potrebbe non soddisfare nel lungo periodo
- L’agente accumula memoria con valore operativo
È esattamente qui che il framework build vs buy per gli agenti AI cambia più drasticamente — la risposta giusta in fase pilota appare molto diversa da quella giusta in produzione.
Le salvaguardie architetturali che vale la pena pretendere
Se decidi che una piattaforma è il giusto punto di partenza, alcune scelte architetturali riducono significativamente la tua esposizione.
Esternalizza i tuoi prompt. Archivia i system prompt e le istruzioni sulla persona nel tuo repository versionato, non nell’interfaccia della piattaforma. L’agente dovrebbe caricarli a runtime. È una decisione da cinque minuti che preserva la piena portabilità dell’identità del tuo agente.
Controlla il tuo layer di memoria. Dove la piattaforma lo consente, instrada l’archiviazione della memoria attraverso un vector database esterno che controlli tu. Le opzioni standard self-hostabili includono Weaviate, Chroma self-hosted o Qdrant — tutti open-source e deployabili su infrastruttura di tua proprietà. Questo mantiene il contesto conversazionale accumulato portabile indipendentemente da cosa succede alla piattaforma.
Monitora prima di dipendere. Prima che un processo diventi critico per la produzione, assicurati di avere logging e osservabilità al di fuori della piattaforma. Se puoi vedere cosa ha fatto il tuo agente solo attraverso la dashboard del vendor, hai un problema di dipendenza.
Pianifica l’uscita prima di entrare. Stimare il costo di migrazione prima di impegnarti cambia ciò che negozi nel contratto. Un vendor che non vuole discutere i termini di uscita in fase di vendita sta comunicando qualcosa. Per i team pronti a crescere oltre i limiti della piattaforma, il percorso di migrazione dal prototipo allo sviluppo custom è più strutturato di quanto molti immaginino.
Il quadro completo dei costi
Il rischio di lock-in ha un valore economico, anche se raramente compare nel listino prezzi del vendor. Il calcolo: probabilità di un evento dirompente sulla piattaforma (aumento di prezzo, acquisizione, deprecazione) nel tuo orizzonte di deployment, moltiplicata per il costo di migrazione se si materializza, più il premio che paghi rispetto alle alternative perché uscire è troppo doloroso da eseguire.
Per molte organizzazioni che valutano un deployment multi-annuale di agenti, il confronto TCO custom vs piattaforma mostra che il costo fully-loaded di una soluzione custom ben architettata è più vicino all’alternativa platform di quanto suggeriscano i numeri iniziali — precisamente perché il rischio di lock-in è incluso nel calcolo anziché differito.
Se stai valutando framework open-source come LangGraph o CrewAI — dove possiedi l’infrastruttura quando deployata self-hosted — il confronto tra piattaforme open-source e proprietarie è il punto di partenza giusto. Nota che entrambi i framework offrono anche servizi di deployment cloud gestito (LangSmith Deployment per LangGraph, CrewAI Cloud per CrewAI) che reintroducono alcuni vettori di lock-in; il vantaggio in termini di portabilità si applica al percorso self-hosted. Queste opzioni cambiano significativamente il calcolo del lock-in, pur introducendo diversi trade-off in termini di complessità operativa.
Come Orange ITS affronta le valutazioni di piattaforma
Quando valutiamo una piattaforma per agenti per un cliente, eseguiamo una versione della checklist sopra e modelliamo esplicitamente il costo di uscita. Quel numero diventa parte della raccomandazione build-vs-platform, non un’appendice.
Per le organizzazioni con processi mission-critical o forti requisiti di residenza dei dati, raccomandiamo spesso framework open-source deployati su infrastruttura svizzera o europea, oppure architetture di agenti completamente custom dove il cliente è proprietario di ogni livello. Per piloti a bassa criticità, possiamo raccomandare di partire da una piattaforma gestita — con escape hatch documentati sin dal primo giorno.
Il nostro servizio di strategia AI esiste proprio per questo tipo di valutazione: aiutarti a prendere la decisione sulla piattaforma con una visione chiara del costo totale, non solo dell’abbonamento mensile.
Se stai valutando una piattaforma per agenti in questo momento — o stai riconsiderando una già deployata — una chiamata di 30 minuti è di solito sufficiente per identificare le dipendenze a più alto rischio e concordare le salvaguardie architetturali prima che diventino costose. Prenota quella conversazione con noi.