Il modello AI che usate oggi cambierà: progettate la sostituzione adesso

Il prototipo AI che funziona meglio è quasi sempre anche il più veloce da mettere in produzione. Un’API, due o tre prompt scritti bene, una settimana di integrazione e il risultato sembra pronto. I problemi arrivano dopo: il modello viene aggiornato, una versione va in pensione, cambiano i limiti di utilizzo, la fattura cresce insieme ai volumi.

A quel punto scoprite due cose insieme. La prima è di dipendere da un fornitore. La seconda, meno ovvia, è che il comportamento di quel modello specifico è entrato dentro i vostri processi: nelle risposte ai clienti, nella classificazione dei documenti, nella preparazione delle offerte, nel supporto agli operatori. Sostituirlo non significa cambiare un endpoint, significa rimettere mano a un pezzo di processo.

Per una PMI la risposta non è costruire una piattaforma multi-cloud monumentale. È progettare una via d’uscita proporzionata, verificabile e fatta di componenti che restano in azienda. Indipendenza non vuol dire usare per forza un modello europeo, open-weight o installato in casa: vuol dire poter cambiare idea senza ricominciare da zero.

1. Il lock-in arriva dopo il prototipo

In fase di sperimentazione è giusto privilegiare velocità e qualità del risultato. Costruire un’architettura complessa prima di aver dimostrato che il caso d’uso produce valore è uno spreco. L’errore è lasciare quella soluzione così com’è il giorno in cui il prototipo diventa un servizio che qualcuno usa tutte le mattine.

La dipendenza si forma su quattro piani. C’è il livello tecnico delle API, perché ogni fornitore ha parametri, formati e funzioni diverse. C’è il livello comportamentale: lo stesso prompt non dà risultati equivalenti su modelli diversi. C’è quello operativo, fatto di quote, filtri sui contenuti, regioni cloud e tempi di risposta. E c’è quello economico, che diventa visibile quando crescono documenti, utenti, lunghezza del contesto e numero di richieste.

I grandi fornitori pubblicano calendari di ciclo di vita e di ritiro delle versioni: vale per i modelli offerti su Azure, per quelli su Vertex AI di Google e per quelli disponibili tramite Amazon Bedrock. Non è una scorrettezza, nessun servizio tecnologico può mantenere ogni versione per sempre. È però una condizione da mettere nel progetto fin dall’inizio, invece di scoprirla con una mail di deprecazione a metà agosto.

Il punto non è indovinare quale modello durerà di più. È evitare che un suo cambiamento vi costringa a riscrivere l’applicazione, a reindicizzare tutto l’archivio documentale o ad accettare risultati peggiori perché non avete un metro di paragone con il “prima”.

2. Separare dati, prompt e modello

Una soluzione sostituibile ha un confine netto fra applicazione, dati e servizio di inferenza. Il gestionale, il portale clienti o il sistema documentale non dovrebbero chiamare direttamente cinque API diverse, ognuna con le sue credenziali e il suo formato. Meglio farli passare da un livello intermedio — quello che si chiama di solito AI gateway — che normalizza richieste, autenticazione, log, tetti di spesa e scelta del modello.

Non serve comprare una piattaforma dedicata. Per una PMI il gateway può essere un servizio leggero, costruito con componenti standard e gestito dal proprio system integrator. Deve però essere documentato, esportabile e installabile anche altrove: se diventa a sua volta un prodotto proprietario che non potete spostare, avete solo traslato il lock-in di un piano.

La separazione riguarda anche i prompt. Istruzioni di sistema, esempi, regole di output e relative versioni non possono stare sepolti nel codice o configurati solo nella console del fornitore. Vanno in un repository vostro, con uno storico che permetta di dire quale configurazione ha prodotto un certo risultato il mese scorso.

Lo stesso vale per la conoscenza aziendale. Documenti originali, metadati, permessi e regole di indicizzazione devono restare distinti dal modello. In un sistema RAG gli indici vettoriali sono ricostruibili solo se conservate le fonti, le trasformazioni applicate e il legame con i diritti di accesso: esportare milioni di vettori senza sapere da quali documenti arrivano non è possedere i propri dati.

Questa architettura non promette che ogni modello sia intercambiabile con un clic — sarebbe poco credibile. Riduce però la quantità di lavoro da rifare: un connettore, qualche prompt e una campagna di verifica, invece dell’intera applicazione.

3. La portabilità si misura sulle risposte, non sulle API

Due modelli possono accettare lo stesso testo e restituire entrambi un JSON valido, e comportarsi in modo molto diverso. Uno è più preciso nel classificare le fatture, un altro più disciplinato nel seguire le istruzioni, un terzo è più veloce ma rende meno sui testi in italiano. La compatibilità tecnica è necessaria, non sufficiente.

Prima della produzione serve un insieme stabile di casi di prova, costruito con esempi reali adeguatamente anonimizzati. Non deve essere enorme: per un processo circoscritto, qualche decina di casi scelti bene vale più di migliaia di domande sintetiche. Devono esserci gli input ordinari, le eccezioni e soprattutto gli errori che l’azienda non può permettersi.

Per ogni caso vanno registrati risultato atteso, criteri di accettazione, tempo di risposta, consumo e necessità di revisione umana. I compiti creativi tollerano una valutazione qualitativa; l’estrazione di importi, codici o scadenze richiede confronti deterministici e soglie esplicite. Se l’output innesca un’azione automatica, misurate anche i falsi positivi e le condizioni che impongono il passaggio a un operatore.

Il NIST AI Risk Management Framework propone di governare, mappare, misurare e gestire i rischi dei sistemi AI. Non è una norma europea e nessuno obbliga una PMI italiana ad adottarne l’impianto formale, ma il principio è utile: il rischio non si governa con la reputazione del modello, si governa osservando come si comporta nel vostro contesto.

La prova del nove è far girare lo stesso insieme di casi su un secondo modello. Se servono tre mesi, l’architettura non è sostituibile. Se bastano un connettore nuovo, una revisione dei prompt e qualche giorno di verifiche, avete un’opzione concreta in mano — anche se non la userete subito.

4. Cinque cose che devono restare in azienda

Un pilot può chiudersi con una demo. Un servizio operativo deve lasciare materiale riutilizzabile anche se cambia il fornitore o il system integrator. Non servono cento pagine di documentazione: servono pochi oggetti tecnici, aggiornati e davvero usabili.

• Il repository di prompt, configurazioni e connettori, con versioni e istruzioni di installazione.
• Un test set aziendale con criteri di accettazione, risultati di riferimento e casi critici.
• La mappa dei dati inviati al modello, delle regioni in cui vengono trattati e degli eventuali sub-responsabili.
• I log che permettono di ricostruire errori, costi e versioni usate, senza raccogliere a strascico dati personali o informazioni riservate.
• Una procedura di fallback che dica quando passare a un secondo modello, quando degradare il servizio e quando tornare al processo manuale.

Questi cinque oggetti valgono più di qualsiasi dichiarazione generica di portabilità. Permettono a un altro tecnico di capire la soluzione, riprodurla e stimare quanto costa spostarla. E permettono a voi di discutere con il fornitore sui fatti: qualità misurata, latenza, costo per operazione, tempo di sostituzione.

Il system integrator ha un ruolo importante proprio qui. Una realtà italiana vicina alla PMI conosce i vostri processi, gli orari critici e i vincoli applicativi molto meglio di un grande vendor globale, e di solito risponde al telefono. Ma la vicinanza deve produrre autonomia: documentazione accessibile, credenziali e abbonamenti intestati all’azienda, componenti installabili su un’infrastruttura alternativa. Un buon rapporto di fiducia non rende superflua la via d’uscita, rende più facile costruirla insieme.

5. Continuità vuol dire anche saper lavorare senza AI

Non tutti i casi d’uso richiedono un secondo modello acceso in tempo reale. Se l’AI prepara la bozza di una comunicazione interna, due ore di fermo sono tollerabili. Se classifica richieste commerciali, il lavoro si può accodare e recuperare. Se invece filtra operazioni urgenti o alimenta un processo produttivo, la continuità va progettata con un’altra attenzione.

La prima decisione quindi non riguarda il cloud, riguarda il processo. In caso di indisponibilità l’attività si ferma, rallenta o torna manuale? Per quanto tempo? Quali dati vanno conservati per riprendere senza duplicazioni? Solo dopo queste risposte ha senso scegliere fra modello alternativo, coda locale, una capacità minima self-hosted o una procedura cartacea per gli operatori.

L’articolo 32 del GDPR include fra le misure di sicurezza la capacità di assicurare disponibilità e resilienza dei sistemi e di ripristinare tempestivamente l’accesso ai dati personali dopo un incidente, oltre a una procedura per verificare periodicamente l’efficacia delle misure adottate. Non impone un’architettura AI particolare, ma rende difficile sostenere che la continuità sia un dettaglio quando il servizio tratta dati personali ed è dentro il processo. E un fallback mai provato resta un’ipotesi.

Per chi rientra nel perimetro NIS2, l’articolo 21, paragrafo 2, elenca fra le misure minime continuità operativa, gestione dei backup, disaster recovery e sicurezza della catena di fornitura. Anche se siete fuori perimetro, la logica regge: la dipendenza da un servizio AI è un rischio di fornitura come gli altri e va dimensionata sull’impatto, non sull’entusiasmo del momento.

Un modello open-weight eseguito su un cloud europeo o presso un provider italiano può essere un’ottima capacità di riserva. Non è però automaticamente una soluzione sovrana: servono competenze per gestirlo, capacità di calcolo disponibile, aggiornamenti, monitoraggio e una licenza compatibile con l’uso che ne fate. L’autonomia non è possedere un file di pesi, è riuscire a erogare il servizio.

6. Il contratto non vi garantisce l’eternità, vi garantisce l’uscita

Nessun contratto può obbligare un fornitore a mantenere un modello per sempre. Può però fissare preavvisi per le modifiche sostanziali, accesso ai log, restituzione dei dati, assistenza all’uscita e responsabilità sulle configurazioni. E può chiarire chi controlla gli account cloud, di chi è il codice dei connettori e in che formato vengono consegnati prompt, valutazioni e documentazione.

Quando il fornitore tratta dati personali per conto vostro, l’articolo 28, paragrafo 3, lettera g) del GDPR prevede che al termine del servizio i dati vengano restituiti o cancellati secondo la vostra scelta, salvo obblighi di conservazione previsti dalla legge. È una clausola necessaria ma non risolutiva: serve sapere quali dati sono realmente esportabili, in quanto tempo e se la cancellazione comprende log, cache e copie in mano ai sub-responsabili.

Poi ci sono gli aggiornamenti. Un modello nuovo non dovrebbe entrare da solo in un processo delicato solo perché il fornitore lo considera il successore del precedente. La configurazione deve permettere di fissare una versione, provare la successiva sul test set e promuoverla solo dopo l’accettazione. Dove bloccare la versione non è possibile, il rischio va messo per iscritto e il fallback deve essere più rapido.

Il contratto con il system integrator, infine, dovrebbe prevedere un’attività di uscita concreta: consegna dei repository, trasferimento delle credenziali, esportazione delle configurazioni, documentazione aggiornata e una prova di installazione in un ambiente alternativo. Non serve trasformare ogni progetto AI in una gara pubblica. Basta evitare che i pezzi indispensabili restino solo sul portatile o nel tenant del fornitore.

La scelta del modello continuerà a contare: qualità, costo, lingua, latenza e protezione dei dati restano criteri decisivi. Ma il modello migliore non è quello che promette di non cambiare mai. È quello che potete adottare senza consegnargli le chiavi del processo. Per una PMI è questa la forma più concreta di sovranità tecnologica: scegliere oggi senza rinunciare a scegliere di nuovo domani.