Il vero lock-in non è il modello, ma l’architettura che gli costruisci intorno

Nel mondo AI si parla moltissimo di modelli.

Quale LLM usare. Quale provider scegliere. Quale framework agentico adottare. Quale vector database integrare. Quale modello usare per embedding, reranking, classificazione, reasoning o generazione.

È normale.

Il modello è la parte più visibile. È quello che produce la risposta. È quello che impressiona durante una demo. È quello che fa percepire immediatamente il salto rispetto alle applicazioni tradizionali.

Ma quando una soluzione AI smette di essere una demo e diventa un prodotto, la domanda cambia.

Non è più solo:

Quale modello uso?

La domanda più importante diventa:

Quanto il mio prodotto dipende dal modello, dal provider, dal framework o dal runtime scelto oggi?

Questa è la domanda vera.

Perché nel mondo AI quasi nulla resterà fermo.

Cambieranno i modelli. Cambieranno i provider. Cambieranno i costi. Cambieranno le policy. Cambieranno le capacità dei framework. Cambieranno i vincoli dei clienti. Cambieranno i requisiti di privacy. Cambieranno le aspettative sulla qualità. Cambieranno le architetture.

Nei prossimi anni molte aziende non avranno un solo modello, un solo provider o un solo stack AI. Avranno combinazioni diverse: LLM SaaS, modelli open source, runtime interni, agenti, RAG, embedding differenti, policy per cliente, vincoli sui dati, modelli scelti in base a costo, qualità, latenza o compliance.

In questo scenario, il vantaggio non sarà soltanto scegliere oggi il componente migliore.

Il vantaggio sarà costruire prodotti capaci di cambiare componenti senza perdere identità.

Il rischio, quindi, non è avere dipendenze. Ogni prodotto reale ha dipendenze.

Il rischio è costruire il cuore del prodotto dentro una dipendenza che domani potresti voler sostituire.

Confondere acceleratore e fondazione

Usare servizi già pronti è spesso la scelta più corretta.

Se devo validare un caso d’uso, ha senso usare un LLM esposto via API. Se devo costruire una prima versione di un assistente, ha senso usare un framework che accelera lo sviluppo. Se devo fare una demo RAG, ha senso usare un vector database managed. Se devo sperimentare agenti, tool calling e workflow, ha senso appoggiarsi a componenti già disponibili.

Nella fase iniziale tutto questo riduce il tempo, abbassa il costo di sperimentazione e permette di capire rapidamente se l’idea ha valore.

Il problema nasce dopo.

Nasce quando la demo viene usata davvero. Quando il primo cliente chiede una variante. Quando il secondo cliente ha policy diverse. Quando il terzo non vuole che certi dati escano dal suo perimetro. Quando i costi dei token iniziano a pesare. Quando un modello migliore arriva sul mercato. Quando il framework scelto all’inizio non copre più tutti i casi. Quando serve auditabilità. Quando bisogna spiegare perché una risposta è stata generata. Quando bisogna cambiare provider senza riscrivere mezzo prodotto.

A quel punto si scopre cosa è stato costruito davvero.

Un prodotto AI.

Oppure un wrapper ben confezionato intorno a un endpoint.

La differenza è enorme.

Un wrapper funziona finché il contesto resta semplice.

Un prodotto, invece, deve poter evolvere. Deve poter cambiare modello, provider, policy, strategia di retrieval, configurazioni cliente, livelli di isolamento, metriche di costo e modalità di esecuzione senza perdere coerenza architetturale.

Il punto non è evitare gli acceleratori.

Il punto è non trasformare un acceleratore nella fondazione del prodotto.

Il modello è una capacità, non il prodotto

Un prodotto AI non coincide con il modello che usa.

Il modello è una capacità fondamentale, ma non è il prodotto.

Un assistente documentale, per esempio, non vale perché “chiama un LLM”. Quello lo fanno tutti.

Il valore sta in altro.

Sta nel modo in cui gestisce i documenti. Nel modo in cui rispetta i permessi. Nel modo in cui costruisce il contesto. Nel modo in cui applica policy diverse. Nel modo in cui misura qualità, costi e utilizzo. Nel modo in cui isola clienti diversi. Nel modo in cui integra sistemi aziendali. Nel modo in cui traccia le risposte. Nel modo in cui controlla quali dati possono essere inviati a quale provider. Nel modo in cui permette di cambiare modello senza riscrivere la logica applicativa.

Questo è il prodotto.

Il modello è una capacità che il prodotto consuma.

Se questa distinzione non è chiara, l’architettura diventa fragile.

Fragile perché il codice applicativo inizia a dipendere direttamente dalle API di un provider. Fragile perché prompt, tool, agenti, retrieval e metriche finiscono accoppiati a uno specifico framework. Fragile perché cambiare modello significa cambiare logica di prodotto. Fragile perché ogni cliente diventa una variante manuale. Fragile perché le policy sui dati sono sparse nel codice. Fragile perché i costi sono visibili solo a posteriori. Fragile perché l’osservabilità dipende da quello che il vendor decide di esporre.

La vera debolezza non è usare un provider esterno.

La vera debolezza è non sapere più dove finisce il prodotto e dove inizia il provider.

Il lock-in dell’AI non è solo tecnico

Quando si parla di lock-in, si pensa quasi sempre al cloud provider.

AWS. Azure. Google Cloud.

Nel mondo AI, però, il lock-in è più sottile.

Può nascere dal modello. Dal provider LLM. Dal framework agentico. Dal vector database. Dal runtime di inferenza. Dal sistema di prompt management. Dal modo in cui vengono definiti i tool. Dal modo in cui viene fatto retrieval. Dagli embedding. Dal reranking. Dal sistema di logging. Dal modo in cui vengono attribuiti i costi. Dal modo in cui vengono distribuite configurazioni diverse per clienti diversi.

È un lock-in che spesso non si vede all’inizio, perché nella fase di prototipo l’obiettivo è arrivare a una demo. E in una demo il lock-in non pesa. Anzi, spesso accelera.

Il problema emerge quando il prodotto deve vivere nel tempo.

Quando devi confrontare provider diversi. Applicare policy diverse. Servire clienti diversi. Dimostrare dove sono andati i dati. Capire perché una richiesta è costata troppo. Cambiare modello per ragioni di qualità, costo, latenza o compliance.

In quel momento scopri se hai costruito un prodotto.

Oppure se hai costruito una dipendenza molto ben presentata.

Il punto non è eliminare ogni forma di lock-in. Sarebbe ingenuo. Il punto è evitare il lock-in sbagliato: quello che non riguarda solo un componente tecnico, ma il modo stesso in cui il prodotto ragiona, decide, misura, integra, osserva e viene venduto.

Il centro del prodotto deve restare tuo

Un prodotto AI dovrebbe avere un proprio centro architetturale.

Dentro quel centro dovrebbero stare le parti che definiscono il valore del prodotto:

• dominio;
• workflow;
• UX;
• regole di business;
• policy applicative;
• gestione dei permessi;
• gestione dei dati;
• integrazioni aziendali;
• metriche di valore;
• logiche cliente-specifiche;
• controllo dei costi;
• auditabilità.

Fuori da quel centro, o almeno separati con confini chiari, dovrebbero stare i componenti che potresti voler cambiare nel tempo:

• LLM provider;
• modello;
• embedding model;
• framework agentico;
• vector database;
• runtime di inferenza;
• servizio di osservabilità;
• cloud provider;
• servizi managed.

Non perché questi componenti siano secondari. Al contrario, sono importantissimi.

Ma proprio perché sono importanti devono poter evolvere senza trascinare con sé tutto il prodotto.

Se il dominio applicativo è mischiato con le primitive specifiche di un framework agentico, cambiare framework diventa costoso. Se le policy sui dati sono sparse nelle chiamate al provider, introdurre data residency diventa difficile. Se il routing verso i modelli è scritto dentro i singoli servizi, confrontare provider diversi diventa complicato. Se le metriche di costo sono recuperabili solo dal portale del vendor, attribuire margini per cliente diventa fragile.

La distinzione centrale è questa:

Il prodotto deve usare componenti AI. Non deve diventare la somma disordinata dei componenti AI che usa.

Il model gateway non è un dettaglio tecnico

Per evitare che il prodotto parli in modo rigido con un solo modello o un solo provider, in molte architetture AI diventa utile introdurre un layer intermedio.

Possiamo chiamarlo model gateway, inference gateway, model router o policy layer. Il nome conta meno del ruolo.

Il model gateway non serve a rendere tutto astratto per principio. Serve a spostare le decisioni critiche fuori dal codice applicativo e dentro un livello governabile.

Decisioni come costo, privacy, qualità, latenza, fallback, auditabilità, data residency e compliance non dovrebbero essere disperse dentro ogni servizio applicativo.

Dovrebbero stare in un punto in cui il prodotto decide come usare i modelli.

Per esempio:

• se il cliente A usa il provider X, instrada verso X;
• se il cliente B richiede data residency, usa un runtime dedicato;
• se il dato è sensibile, non inviarlo a un provider esterno;
• se il costo supera una soglia, usa un modello più economico;
• se serve maggiore qualità, usa un modello più potente;
• se il provider non risponde, applica fallback;
• se la richiesta è low-risk, usa un modello veloce;
• se la richiesta richiede audit, traccia input, output e decisione;
• se una policy vieta un certo modello, impedisci la chiamata.

L’architettura diventa quindi qualcosa di questo tipo:

Questo non significa che bisogna sempre costruire tutto in casa.

Non significa che bisogna sempre self-hostare modelli.

Spesso non conviene.

Molto spesso la scelta migliore sarà continuare a usare provider esterni.

Ma cambia una cosa fondamentale:

Il provider diventa una scelta di esecuzione, non il centro del prodotto.

Questa è la differenza tra usare un modello e dipendere architetturalmente da un modello.

Nel primo caso il prodotto mantiene controllo.

Nel secondo caso il prodotto eredita i limiti del componente intorno a cui è stato costruito.

Policy, dati e costi devono stare sopra il modello

In un prodotto AI reale, la scelta del modello non può essere solo una decisione tecnica.

Deve essere anche una decisione di policy.

Che tipo di dato sto trattando? A quale cliente appartiene? In quale regione può essere processato? Può uscire dal mio perimetro? Può essere inviato a un provider SaaS? Deve essere anonimizzato? Deve essere loggato? Deve essere escluso dai log? Quanto posso spendere per questa richiesta? Quale livello di qualità serve? Quale latenza è accettabile? Serve fallback? Serve audit?

Queste decisioni non dovrebbero essere nascoste dentro il codice applicativo.

Dovrebbero appartenere a un livello esplicito dell’architettura.

Un livello in cui il prodotto decide come usare i modelli, non si limita a invocare il modello scelto all’inizio.

Questo punto diventerà sempre più importante, perché molte aziende non avranno un solo scenario AI.

Avranno assistenti interni, copiloti per operatori, motori di ricerca documentale, classificatori di ticket, agenti che interagiscono con sistemi aziendali, generatori di report, strumenti di knowledge management.

Ogni caso d’uso potrà avere policy diverse.

Se ogni applicazione gestisce da sola queste decisioni, l’architettura diventa incoerente.

Se invece esiste un livello comune di policy, routing, metriche e controllo, l’azienda può governare l’AI come capacità di prodotto.

Non come una collezione di esperimenti separati.

Anche agenti, RAG e vector database possono diventare lock-in

Lo stesso ragionamento vale per agenti, RAG e vector database.

Il problema non è scegliere un framework agentico. Il problema è costruire il prodotto come se quel framework fosse il prodotto.

Un agente può essere centrale nel comportamento di una soluzione AI, ma dovrebbe restare un componente governabile. Deve avere una versione, configurazioni per ambiente, policy per cliente, limiti, metriche, log, test, rollout controllati e modalità di fallback.

Se l’agente è una magia nascosta dentro un framework, il prodotto diventa fragile.

Se invece l’agente è modellato come un componente applicativo, allora può essere sostituito, scalato, osservato, isolato e aggiornato senza bloccare tutto il sistema.

La domanda non è:

Quale framework agentico uso?

La domanda più importante è:

Se domani cambio framework, cosa resta del mio prodotto?

Se la risposta è “quasi niente”, il framework è diventato il prodotto.

E questo è un problema.

Lo stesso vale per il vector database.

All’inizio sembra solo un componente tecnico. Serve per memorizzare embedding, fare similarity search, costruire un sistema RAG e recuperare contesto.

Ma nel tempo può influenzare molto di più: il modo in cui indicizzi i documenti, gestisci i metadati, applichi permessi, separi clienti diversi, aggiorni gli embedding, fai filtering, misuri qualità del retrieval, gestisci retention e cancellazione dei dati.

Anche qui, il punto non è evitare un prodotto managed.

Il punto è evitare che la logica del prodotto venga modellata interamente intorno alle primitive specifiche di un singolo database.

Il prodotto dovrebbe avere una propria idea di documento, permesso, contesto, fonte, versione, policy e cliente.

Il vector database dovrebbe implementare una parte di questa strategia.

Non definirla completamente.

Misurare non basta: bisogna attribuire

Un altro punto critico è il costo.

Nel software tradizionale misurare CPU, memoria, storage e traffico è importante. Nel mondo AI, però, il costo può dipendere da molte altre dimensioni: token, chiamate al modello, iterazioni di un agente, embedding generati, documenti indicizzati, retrieval, reranking, fallback, provider diversi, prompt troppo lunghi, tool invocati troppe volte.

Un prodotto AI può funzionare bene dal punto di vista tecnico e fallire dal punto di vista economico.

Può rispondere correttamente, ma costare troppo. Può sembrare intelligente, ma fare troppe iterazioni. Può migliorare la qualità, ma ridurre il margine. Può essere adottato da molti clienti, ma senza un modello chiaro di attribuzione dei costi.

Per questo non basta osservare.

Bisogna attribuire.

Attribuire costi per cliente, workflow, modello, versione dell’agente, ambiente, funzionalità, classe di richiesta e provider.

Questo punto è decisivo anche per evitare lock-in.

Perché se non sai quale modello costa di più, quale workflow genera più chiamate, quale cliente consuma più token o quale agente produce troppe iterazioni, non puoi decidere davvero.

Non puoi confrontare provider. Non puoi cambiare modello con consapevolezza. Non puoi capire se conviene un runtime interno. Non puoi sapere se una feature è sostenibile. Non puoi attribuire margine a un cliente. Non puoi distinguere un problema tecnico da un problema economico.

Il punto non è solo sapere quanto costa l’AI.

Il punto è sapere perché costa così, per chi costa così e quale parte del prodotto genera quel costo.

Senza questa capacità, non hai davvero un prodotto AI sostenibile.

Hai una funzionalità AI con un costo difficile da spiegare.

Il multi-cliente mostra se hai un prodotto o progetti custom

Il multi-cliente è uno dei punti in cui la differenza diventa evidente.

Immaginiamo un assistente AI venduto a più aziende.

La base applicativa è la stessa, ma ogni cliente può avere documenti diversi, permessi diversi, provider diversi, modelli diversi, policy diverse, retention diversa, limiti di costo diversi, prompt diversi, dashboard diverse, secret dedicati, integrazioni diverse e vincoli di data residency diversi.

Se ogni cliente diventa un progetto separato, il prodotto non scala.

All’inizio sembra gestibile. Copi una configurazione. Modifichi due valori. Aggiungi un prompt. Cambi un endpoint. Crei un indice dedicato.

Poi arriva il secondo cliente. Poi il terzo. Poi il primo chiede una modifica. Poi il secondo vuole un provider diverso. Poi il terzo richiede isolamento. Poi devi aggiornare tutti. Poi devi capire quanto costa ciascuno. Poi devi dimostrare quali dati sono stati inviati a quale modello.

A quel punto il problema non è più AI.

È architettura di prodotto.

Un prodotto AI multi-cliente deve poter dire:

• stesso prodotto;
• istanze controllate;
• configurazioni diverse;
• policy diverse;
• metriche separate;
• costi attribuibili;
• secrets isolati;
• dati separati;
• evoluzione comune.

Se non puoi farlo, non stai vendendo un prodotto.

Stai vendendo progetti custom con una base comune.

Che è un’altra cosa.

Dove entra Kubernetes

Kubernetes entra qui.

Non come moda. Non come religione. Non come risposta automatica a qualsiasi problema AI.

Kubernetes entra quando hai bisogno di un piano operativo comune per eseguire e governare componenti diversi: frontend, backend API, agent runtime, model gateway, ingestion worker, embedding worker, retrieval service, vector store, database applicativo, queue, job batch, secret, policy, metriche, logging e tracing.

Questi componenti devono essere eseguiti, configurati, aggiornati, scalati, osservati e isolati.

Kubernetes può offrire una base comune per farlo.

Una API può essere un Deployment. Un worker può essere un Deployment. Un processo di ingestion può essere un Job. Un aggiornamento periodico può essere un CronJob. Un servizio interno può essere esposto con un Service. Un cliente può avere namespace, valori, secret e policy dedicati. Una configurazione può essere gestita in modo dichiarativo. Un rollout può essere controllato. Una metrica può essere raccolta in modo standard. Un agente può essere trattato come workload applicativo. Un model gateway può diventare un componente centrale della piattaforma.

Questo non significa che Kubernetes renda tutto portabile.

Non significa che elimini ogni lock-in.

Non significa che ogni soluzione AI debba girare su Kubernetes.

Significa una cosa più precisa:

Kubernetes può aiutare a non far coincidere il modello operativo del prodotto con il runtime di un singolo vendor.

Il punto non è “mettere l’AI su Kubernetes”.

Il punto è costruire prodotti AI in cui modelli, provider, framework e runtime siano componenti governati, non fondazioni rigide.

Kubernetes non è la tesi.

La tesi è il controllo architetturale.

Kubernetes può essere uno dei modi concreti per renderlo operativo.

La piattaforma deve assorbire complessità, non distribuirla

Naturalmente Kubernetes è complesso.

Ma un prodotto AI multi-cliente, governabile, osservabile, misurabile, sicuro e capace di usare modelli diversi è complesso comunque.

La domanda non è se la complessità esiste.

La domanda è dove la metti.

Puoi lasciarla sparsa dentro applicazioni, script, configurazioni manuali, portali SaaS e integrazioni specifiche.

Oppure puoi incapsularla dentro una piattaforma.

Ma attenzione: una piattaforma non deve scaricare Kubernetes sui team.

Se ogni team applicativo deve conoscere nel dettaglio Deployment, Service, Ingress, RBAC, NetworkPolicy, ServiceMonitor, HPA, Helm, Kustomize, Argo CD e Prometheus, allora la piattaforma non sta facendo il suo lavoro.

La piattaforma dovrebbe offrire pattern consumabili: AI API service, agent runtime, model gateway, embedding worker, ingestion pipeline, RAG backend, customer instance, policy profile, cost attribution, observability standard.

Il team applicativo dovrebbe ragionare in termini di prodotto.

La piattaforma dovrebbe trasformare quelle intenzioni in risorse operative governate.

Questa è la differenza tra adottare Kubernetes e scaricare Kubernetes.

Nel primo caso costruisci una base operativa.

Nel secondo crei solo un altro livello di fatica.

La vera domanda architetturale

A questo punto la domanda da fare non è:

Quale modello scegliamo?

Questa domanda resta importante, ma non basta.

La domanda più importante è:

Cosa succede al nostro prodotto se domani cambiamo modello, provider, framework, vector database o strategia di retrieval?

Se la risposta è “dobbiamo riscrivere tutto”, allora il prodotto è troppo accoppiato.

Se la risposta è “dobbiamo cambiare una configurazione, una policy, un adapter o una strategia di routing”, allora l’architettura è più sana.

Non perfetta.

Ma più sana.

Perché un prodotto AI maturo non è quello che usa il modello migliore oggi.

È quello che può integrare il modello migliore di domani senza perdere identità.

Conclusione

Il rischio più grande nei prodotti AI non è usare servizi esterni.

Non è usare LLM SaaS. Non è usare framework agentici. Non è usare vector database managed. Non è usare provider cloud. Non è partire velocemente con componenti già pronti.

Il rischio è costruire il prodotto come se quelle scelte fossero il prodotto.

Un prodotto AI deve avere un proprio centro.

Deve sapere quali sono le sue regole, i suoi dati, i suoi workflow, le sue policy, le sue metriche, i suoi clienti, i suoi costi, i suoi confini, le sue integrazioni e la sua architettura.

Modelli, provider, framework, vector store e runtime devono essere componenti importanti, ma sostituibili.

Non perché sia facile sostituirli.

Ma perché il prodotto non deve perdere sé stesso quando il mercato cambia.

Il vero lock-in dell’AI non è scegliere un modello.

È costruire un prodotto che non esiste più senza quel modello.

Non è usare un provider.

È far coincidere il prodotto con quel provider.

Non è adottare un framework.

È lasciare che il framework definisca l’architettura.

Non è usare un vector database.

È lasciare che il vector database decida come il prodotto interpreta documenti, permessi, contesto e clienti.

La differenza tra una demo AI e un prodotto AI sostenibile sta qui.

Una demo dimostra che qualcosa può funzionare.

Un prodotto dimostra che quella cosa può evolvere.

E nel mondo AI, dove modelli, provider, costi, policy e framework cambieranno continuamente, questa capacità di evolvere non è un dettaglio tecnico.

È il vero vantaggio architetturale.