La risposta breve: metti l'AI in produzione senza vendor lock-in usando modelli open-weight eseguiti on-premise o in cloud sovrano UE, separando l'orchestrazione dal modello e tenendo dati e log dentro il tuo perimetro. Così controlli dati e modelli e cambi fornitore senza riscrivere tutto. Il resto sono dettagli, ma contano.
01Cosa significa davvero vendor lock-in nell'AI?
Il lock-in non è il prezzo a token. È l'impossibilità di andartene. Quando i tuoi prompt, le integrazioni, i dati di addestramento e la pipeline vivono solo dentro la piattaforma di un fornitore, migrare diventa un progetto da mesi. E finché migrare costa più che restare, non sei un cliente: sei un ostaggio educato.
L'agenzia europea per la cybersicurezza ha classificato il lock-in come rischio elevato fin dalla sua prima valutazione del cloud, indicando come causa la mancanza di standard e di strumenti per spostare dati e sistemi tra fornitori (ENISA, Cloud Computing Risk Assessment). Nell'AI il problema è più acuto: il modello è opaco, l'API è proprietaria, e i dati che gli dai oggi addestrano il fornitore di domani.
02Perché "datacenter in Europa" non basta?
È la trappola più diffusa. Un fornitore americano apre una region a Francoforte e vende "dati in UE". Ma il CLOUD Act statunitense segue il controllo del fornitore, non la posizione dei server: un'azienda soggetta al diritto USA può essere obbligata a consegnare i dati ovunque siano fisicamente, e la FISA 702 amplia ulteriormente la portata.
Il GDPR regola i trasferimenti, ma non annulla questa esposizione. Le autorità europee per la protezione dei dati, nelle raccomandazioni post Schrems II, indicano come misura tecnica davvero efficace la cifratura con chiavi gestite dal cliente e trattenute nell'area europea. In altre parole: la residenza del dato non è la sovranità del dato. Lo approfondiamo nella pagina sovranità digitale europea.
03Quanto siamo dipendenti, in numeri
Non è una paranoia di nicchia: è la struttura del mercato. Tre dati citabili, da fonti istituzionali, fotografano la dipendenza europea.
Fonte: iniziativa EuroStack, Bertelsmann Stiftung, febbraio 2025, in linea con lo studio del Parlamento europeo sulle dipendenze software e cyber (STUD 2025/778576). Costruire AI in produzione su questa base, senza una via d'uscita, significa ereditare la dipendenza a livello applicativo.
04Come si costruisce un'AI portabile, in pratica?
La regola P3 è una sola: l'orchestrazione conta più del modello. Il modello è un componente sostituibile, l'architettura intorno è ciò che ti tiene libero. Ecco i quattro pilastri che usiamo.
Modelli open-weight, non scatole chiuse
Parti da modelli con pesi aperti, eseguibili sulla tua infrastruttura. Non devi addestrarne uno da zero: per quasi tutte le PMI è uno spreco. Prendi un modello già pronto, lo esegui dove vuoi, lo adatti con i tuoi dati. Se domani esce qualcosa di migliore, lo sostituisci senza toccare il resto.
Uno strato di astrazione tra te e il modello
Non chiamare mai un fornitore direttamente dal codice di business. Metti in mezzo uno strato API standard: il tuo software parla a quello, e quello parla al modello. Cambiare modello diventa una riga di configurazione, non un refactoring.
Dati e log dentro il perimetro
Prompt, risposte, log e dati di adattamento restano nella tua infrastruttura. È la differenza tra usare l'AI e regalare il tuo know-how a chi un giorno potrebbe rivendertelo.
Portabilità scritta nel contratto
La portabilità si verifica prima della firma. Il Data Act europeo (Regolamento UE 2023/2854) dedica il Capo VI proprio al cambio di fornitore cloud, per prevenire il lock-in: si applica dal 12 settembre 2025 e impone la rimozione delle tariffe di switching, comprese quelle di uscita dei dati, entro il 12 gennaio 2027 (EUR-Lex, Data Act). Usalo come leva contrattuale: chiedi i tempi e i formati di esportazione nero su bianco.
05Dove conviene l'AI sovrana e dove no
Anti-hype, sempre. L'AI on-premise non è la risposta a tutto. Conviene quando i dati sono sensibili, regolati o strategici: cartelle cliniche, progetti industriali, comunicazioni interne, sicurezza. Lì il controllo vale più della comodità.
Per casi a basso rischio e bassa riservatezza, un servizio gestito può andare bene, a patto che la via d'uscita resti aperta. Il punto non è dire no al cloud per principio. È non costruire nulla di critico su una porta che non puoi riaprire. È lo stesso principio dietro Fenrir, il nostro SOC/MDR con AI sovrana: il rilevamento gira su infrastruttura controllata, i log non escono, il modello è sostituibile.
06Da dove iniziare, concretamente
L'errore tipico è partire dal modello. Si parte invece dalla mappa: quali dati toccherebbe l'AI, quanto sono sensibili, dove andrebbero a finire. Per questo il primo passo che proponiamo è quasi sempre un audit dell'esposizione: una fotografia di dati, flussi e dipendenze, prima di scegliere qualunque tecnologia.
Da lì l'adozione diventa una sequenza di decisioni informate, non un salto nel buio. Scegli i casi d'uso, scegli i modelli, definisci la via d'uscita. La parte difficile non è far funzionare l'AI. È farla funzionare senza consegnare le chiavi di casa. Se vuoi un confronto sul tuo caso, scrivici o guarda i nostri prodotti AI e cyber sovrani.