Quando un’azienda decide di cambiare il modello AI su cui ha costruito una soluzione, scopre che la domanda centrale non è quale modello scegliere, ma quanto costa abbandonare quello attualmente in uso.
Fino a poco tempo fa il tema non si poneva. I modelli disponibili non erano molti e offrivano capacità molto simili tra loro, quindi passare da uno all’altro spesso non prometteva un vantaggio tale da giustificare tutto il lavoro. Per cui la reversibilità semplicemente non era tra i criteri di progetto.
Oggi invece lo è, e non soltanto per chi deve migrare da una soluzione AI costruita anni fa, ma per chiunque ne stia progettando una. Se infatti l’architettura non è pensata per il cambio, disporre di molte alternative non basta e la possibilità di scegliere resta quindi solo teorica. A questo si aggiunge un dato di fatto: il mercato continuerà a evolvere e va messo in conto che la soluzione che oggi sembra ottimale domani potrebbe non esserlo più.
Il vendor lock-in smette così di essere una questione puramente tecnica e diventa a tutti gli effetti un rischio economico. Ecco perché è importante capire dove si forma realmente questo vincolo, quanto pesa nel momento in cui si decide di cambiare e come impostare l’architettura in modo che il modello possa essere sostituito senza trascinare con sé l’intero progetto.
Questa libertà di cambiare modello non si recupera a posteriori, si progetta prima, insieme all’architettura. È il principio su cui si basa l’approccio BNova all’AI Strategy: definire un metodo per governare l’AI in azienda, invece di costruire la strategia attorno a uno strumento destinato a cambiare.
Vendor lock-in: dove si forma davvero il vincolo?
Il vendor lock-in, in generale, si verifica quando il legame con un provider di servizi rende complesso, costoso o rischioso abbandonarlo per un’alternativa. L’AI non fa eccezione: troppo spesso le aziende continuano ad usare il provider iniziale non perché sia ancora il più adatto, ma perché abbandonarlo e passare ad un’altra soluzione è troppo oneroso.
Quindi il vincolo sta nel modello? No, anzi! Il modello è forse la parte più facile da sostituire, si cambia un endpoint. Ciò che resta difficile da migrare è tutto quello che gli è stato costruito attorno.
Ad esempio, se le integrazioni ai sistemi interni e ai vari gestionali sono state realizzate attraverso i servizi gestiti di un provider, appartengono a quell’ecosistema e non all’azienda, quindi andranno rifatti. Lo stesso vale per i criteri di valutazione e validazione delle risposte. Ed anche prompt e istruzioni, pur essendo semplici file di testo, sono stati creati ad hoc e calibrati sul comportamento di un modello specifico, quindi in realtà la loro portabilità è solo apparente.
In una soluzione RAG il vincolo è ancora più concreto. Se il corpus documentale è stato indicizzato con il modello di embedding proprietario, cambiare significa ricalcolare gli embedding di tutti i documenti e ripopolare l’indice. Se poi anche il vector store è un servizio gestito, a tutto ciò si aggiunge la migrazione dei dati. E se i controlli di accesso a dati e documenti sono affidati alle logiche di autorizzazione proprietarie anch’esse vanno ridefinite da capo.
Integrazioni, valutazioni, prompt: più questi elementi sono legati a un unico provider, più cambiare modello diventa un vero e proprio nuovo progetto. È per questo che il lock-in non dipende da quando si è scelto, ma da come si è costruito: una soluzione progettata oggi può risultare vincolata esattamente come una di qualche anno fa.
Non esiste un modello migliore in assoluto
Quando si parla di modelli analitici non è definibile il “migliore” in assoluto, non vale per i modelli di Machine Learning e, a maggior ragione, neppure per i LLM. Un modello può risultare più adatto all’elaborazione di documenti, un altro alla generazione di codice, altri alla gestione di immagini o all’uso di tool. La scelta dipende dal contesto e va fatta su criteri verificabili: tempi, qualità e affidabilità delle risposte, uso delle fonti dati autorizzate, compatibilità con i requisiti di sicurezza e, non ultimo, costo per volume di utilizzo.
Su alcuni di questi criteri la misurazione è semplice, su altri lo è molto meno: ad esempio, valutare il rispetto delle istruzioni o l’uso corretto delle fonti dati richiede un giudizio umano che deve essere messo per scritto prima di iniziare le prove.
Ci scontriamo spesso con situazioni in cui un modello che primeggia nelle classifiche generaliste finisce nel contesto aziendale per comportarsi peggio di un altro, magari più basso in classifica, ma più adatto all’esigenza specifica. La valutazione che conta è, infatti, quella condotta sui propri dati e su un insieme di casi reali.
Ridurre il vendor lock-in significa mettersi in condizione di poter fare esattamente questo: mettere due alternative a confronto sullo stesso compito, con le stesse fonti e le stesse metriche di valutazione, senza dover ogni volta rimettere in discussione l’intera soluzione.
Vanno evitate le tecnologie proprietarie? No. E non è una buona idea nemmeno cambiare modello a ogni annuncio di mercato. La libertà di scegliere serve quando esiste una ragione concreta per cambiare, che sia un cambiamento nelle esigenze aziendali o nei requisiti di sicurezza, una necessità di maggior qualità delle risposte oppure, come spesso capita, aggiornamenti delle condizioni economiche dei provider.
Quanto costa cambiare modello?
Il primo istinto è pensare che il costo di cambiare sia legato solo alle tecnologie. In realtà questa è forse la voce meno rilevante: nei sistemi RAG ad esempio ricalcolare gli embedding di un intero corpus documentale costa pochi dollari. Il costo della migrazione, quindi, non arriva dal fornitore, ma dalle giornate di lavoro necessarie. E pesa particolarmente quando (spesso) nessuno lo aveva messo a budget.
La voce più pesante è la validazione. Un modello diverso risponde in modo diverso: cambia la formulazione, cambia il modo in cui segue le istruzioni, cambiano i casi in cui sbaglia. Tutto ciò che era stato verificato va verificato di nuovo, e per farlo serve un insieme di casi di prova e un criterio di giudizio. Quando questi non esistono, vanno costruiti: questo è il momento in cui molte migrazioni si fermano, perché alla domanda “con quali criteri avevamo approvato la soluzione in uso?” spesso non sa rispondere nessuno.
Segue il lavoro di ricostruzione: le istruzioni vanno ricalibrate sul nuovo modello, le integrazioni costruite sui servizi gestiti del vecchio provider vanno rifatte e ricollaudate, le regole di accesso ai documenti vanno riprodotte e nuovamente verificate (in questo caso un errore non è solo un “fastidio”, ma un vero e proprio incidente di sicurezza). Si aggiungono poi spesso i vincoli contrattuali: impegni di spesa minima, durata residua, tempi di preavviso per l’uscita e modalità di restituzione dei dati.
C’è infine il costo del periodo di sovrapposizione: durante la transizione le due soluzioni tipicamente convivono, quindi non solo si paga due volte, ma gli utenti lavorano su uno strumento che sta cambiando sotto le loro mani.
Di per sé nessuna di queste voci è insormontabile. Il problema è che, quando la reversibilità non è un requisito iniziale, nessuna di queste era stata preventivata. Il risultato è la conclusione più frequente: il modello nuovo è senza dubbio migliore, ma cambiare costa troppo.
Progettare per il cambio: l’approccio BNova
Se il lock-in dipende da come è costruita la soluzione, la risposta sta nel metodo con cui si progetta. BNova propone un approccio all’AI che non parte dalla scelta del modello, ma da un principio: separare ciò che appartiene all’azienda, quindi dati, regole, processi e conoscenza, da ciò che per natura cambierà, cioè il modello.
L’AI Strategy si articola in quattro fasi:
- – Mappatura del Valore. Si individuano i processi in cui l’AI genera un beneficio misurabile, definendo priorità e casi d’uso prima di vincolare la strategia a una tecnologia.
- – Data & Need Discovery. Si mappano fonti informative, bisogni delle business unit e modalità di accesso ai dati per rispondere alle domande: quali informazioni il modello può utilizzare? Chi può accedervi e secondo quali regole?
- – Disegno dell’Architettura. Si progetta uno spazio AI connesso e governato, in cui istruzioni riutilizzabili, connettori approvati, procedure e dati autorizzati restano stabili, anche quando il modello cambia.
- – Governance & ROI. Si monitorano utilizzo, accessi, consumi e risultati, collegando ogni investimento a un indicatore di business.
Sia chiaro, nessun approccio rende automatica la sostituzione di un LLM. Modelli diversi hanno comportamenti e limiti diversi, quindi il cambio richiede sempre test e validazione. La differenza è che, basandosi fin dall’inizio su una metodologia strutturata, il conto si riduce a quella voce.
Categoria: INTELLIGENZA ARTIFICIALE
Da Q&A a Copilot: perché in Power BI conta sempre di più il dato
Q&A è una funzione che chi usa Power BI conosce bene. Esiste dal 2013 e permette di interrogare i dati… Leggi tutto
Come fidarsi dell’AI: audit, tracciabilità e decisioni comprensibili
L’AI entra sempre più spesso nei processi aziendali: classifica richieste, segnala anomalie, supporta gli operatori, sintetizza informazioni e propone azioni.… Leggi tutto
Dataiku Cobuild: l’agente che trasforma il linguaggio naturale in progetti AI
Negli ultimi tempi abbiamo iniziato a parlare con l’AI in linguaggio naturale: chiediamo a un assistente di “riassumere una mail”… Leggi tutto
