Mettere l’AI in casa non basta: il controllo si misura quando dovete cambiarla

L’AI locale viene presentata spesso come la risposta definitiva a riservatezza, costi e dipendenza dai grandi vendor. Si scarica un modello open-weight, lo si esegue su una GPU in azienda, e il problema sembra chiuso. In realtà il problema si è solo spostato un metro più in là.

Chi aggiorna il modello quando esce la versione nuova? Dove finiscono embeddings, log e backup? Quale pezzo dell’applicazione conosce le API di quel runtime e non di un altro? Quanto costa tenere una GPU accesa se le richieste arrivano solo tra le nove e le sei? E soprattutto: quanto lavoro serve per sostituire quel modello, quella scheda o il fornitore che gestisce la macchina?

Per una PMI il controllo sull’AI non coincide con il possesso del server. Coincide con la capacità di governare dati, identità, costi e sostituzione dei pezzi senza fermare il lavoro. Nella pratica, la soluzione migliore quasi mai è “tutto on-premises” o “tutto su una API globale”: è un’architettura ibrida, seguita da un interlocutore raggiungibile, in cui ogni carico sta dove ha senso che stia.

1. “Locale” è un indirizzo, non una garanzia

Un assistente AI può girare sul server aziendale e continuare a dipendere da mezzo mondo. La generazione del testo è locale, ma l’autenticazione, il database vettoriale, l’OCR dei documenti, il monitoraggio o la telemetria stanno nel cloud. Anche un’interfaccia apparentemente autonoma può scaricare aggiornamenti, spedire metriche o validare una licenza online.

La prima verifica non riguarda quindi il modello della GPU o il nome del modello linguistico, ma il flusso intero: documento in ingresso, preparazione del contenuto, creazione degli embeddings, generazione della risposta, conservazione delle conversazioni, log amministrativi, backup. Basta che un passaggio esca dal perimetro che avevate in mente perché l’etichetta “AI locale” diventi poco informativa.

C’è poi un equivoco frequente tra open-weight e open source. La disponibilità dei pesi permette di eseguire un modello sulla propria infrastruttura, ma non garantisce automaticamente libertà d’uso, accesso ai dati di addestramento o possibilità di modificare ogni componente. Alcune licenze pongono condizioni sulla dimensione dell’organizzazione, sugli usi ammessi o sulla redistribuzione. E il formato dei pesi, insieme agli strumenti necessari per l’inferenza, può creare una dipendenza tecnica molto concreta.

Non è un motivo per rinunciare ai modelli open-weight: è un motivo per trattarli come qualsiasi altra dipendenza software. Licenza archiviata, versione identificata, requisiti hardware noti, procedura di sostituzione provata almeno una volta. Il controllo comincia da questa disciplina, non dal led che lampeggia in sala server.

2. API, servizio gestito o self-hosting: decide il carico, non il principio

Per una PMI le strade praticabili sono tre, e nessuna vince sempre.

API pubblica a consumo. Si parte in giornata, si accede ai modelli più capaci, non si gestiscono GPU. In cambio prezzi, limiti, versioni disponibili e condizioni restano in mano al provider: possono cambiare mentre la vostra applicazione resta dov’è.

Servizio gestito, possibilmente su infrastruttura italiana o europea, con istanza condivisa o dedicata. Non amministrate l’intero stack, ma potete ottenere risposte chiare su dove stanno i dati, chi fa supporto, che log esistono e cosa succede se il servizio si ferma. È spesso il compromesso giusto quando l’AI entra in un processo vero ma i volumi non giustificano ancora competenze interne dedicate.

Self-hosting, nel vostro data center, in colocation o su un cloud che scegliete voi. Dà controllo sull’esecuzione e tiene prompt e documenti dentro un perimetro definito. Richiede però hardware, patching, monitoraggio, gestione delle vulnerabilità, un minimo di ridondanza e qualcuno capace di aggiornare i modelli senza interrompere il servizio.

La scelta ragionevole dipende dal carico, non dalla filosofia. Un sistema che classifica migliaia di documenti ripetitivi funziona bene con un modello locale anche piccolo. Un assistente usato poche volte al giorno per analisi complesse conviene quasi sempre via API. Un’applicazione che tratta documentazione sensibile con richieste concentrate in orario di ufficio è un buon candidato per un’istanza dedicata presso un provider italiano.

La posizione più robusta è una sola: evitare che l’applicazione conosca direttamente le particolarità di uno di questi ambienti. Un gateway interno — anche semplice — che gestisca autenticazione, tetti di spesa, rimozione dei dati non necessari, instradamento e registrazione degli eventi vi permette di tenere dietro lo stesso punto di controllo un modello locale per il lavoro ordinario e un servizio esterno per le richieste più pesanti. Non elimina il lock-in, ma lo rende visibile e circoscritto: cambiare un pezzo non significa riscrivere il gestionale, il portale clienti o il workflow documentale.

3. Il conto della GPU si fa sulle ore vuote

Il confronto economico tra API e AI locale è quasi sempre truccato, spesso in buona fede. Si moltiplica il prezzo dei token per un volume teorico generoso e lo si mette accanto al prezzo di acquisto di una scheda. Dal lato locale, però, spariscono energia, spazio, ridondanza, assistenza, monitoraggio, aggiornamenti e tempo delle persone. Spariscono soprattutto le ore in cui la macchina è accesa e non produce nulla.

Il self-hosting conviene quando il carico è stabile, ripetitivo e abbastanza alto da saturare la risorsa. Se l’uso è intermittente, l’hardware acquistato resta immobilizzato; se è noleggiato, per avere tempi di risposta prevedibili spesso si paga capacità riservata. E nei picchi una macchina sola può non bastare: a quel punto si sceglie se accettare la coda, aggiungere ferro o deviare temporaneamente le richieste verso un servizio esterno.

Messo in fila, il conto annuale dell’API comprende token, eventuale conservazione, strumenti accessori e supporto. Quello del self-hosting comprende ammortamento o canone dell’hardware, energia, esercizio, aggiornamenti, backup delle configurazioni, capacità inutilizzata e continuità operativa. Il servizio gestito sta nel mezzo: costa più della sola infrastruttura, ma si porta via attività che altrimenti dovreste organizzare in casa.

C’è poi una voce che non compare in nessun preventivo: la qualità insufficiente. Un modello piccolo può essere economico e riservato, ma se ogni output richiede correzione umana il risparmio infrastrutturale se lo mangia il processo. All’opposto, usare il modello più grande sul mercato per estrarre cinque campi da una fattura è spreco puro. Il modello giusto non è il più potente: è il più piccolo che tiene in modo stabile la qualità richiesta per quel compito.

Per questo la valutazione dovrebbe partire da numeri raccolti in un pilot vero: richieste al giorno, lunghezza media di input e output, latenza accettabile, tasso di errore, minuti di revisione umana, distribuzione dei picchi. Senza quei dati, il business case dell’AI locale è una previsione costruita per confermare una decisione già presa.

4. Il GDPR segue i dati, non il rack

Eseguire il modello a Bergamo non rende conforme il servizio. Se prompt, documenti o risposte contengono dati personali valgono comunque i principi dell’articolo 5 del GDPR — a partire da limitazione della finalità e minimizzazione —, i rapporti con i responsabili del trattamento previsti dall’articolo 28 e le misure di sicurezza adeguate al rischio dell’articolo 32.

La posizione del server è solo uno degli elementi. Contano gli accessi amministrativi, i subfornitori, il supporto remoto, i backup, la telemetria e gli eventuali trasferimenti verso Paesi terzi, disciplinati dal capo V. Un fornitore che dichiara data center europeo ma usa servizi esterni per logging o assistenza ha un flusso dei dati più articolato di quanto racconti la brochure: va chiesto, e va messo per iscritto.

Anche il Regolamento (UE) 2024/1689, AI Act, porta obblighi che non dipendono da dove gira il modello. L’articolo 4 chiede a fornitori e deployer di garantire un livello sufficiente di alfabetizzazione in materia di AI al personale coinvolto, tenendo conto di competenze, contesto d’uso e persone interessate. Installare un modello in casa non sostituisce quindi la necessità di spiegare a chi lo usa quali risultati vanno verificati e quali dati non devono entrare nel sistema.

Per la maggior parte delle applicazioni interne di una PMI il punto non è una classificazione sofisticata del sistema, ma sapere cosa sta facendo. Un assistente che riassume procedure ha un impatto diverso da uno strumento che filtra candidature o condiziona decisioni sulle persone. L’architettura locale riduce alcuni rischi di esposizione, ma non cambia la finalità del trattamento e non rende innocua una decisione automatizzata progettata male.

La documentazione utile non è un faldone. È una descrizione del flusso reale: dati ammessi, dati esclusi, modello utilizzato, fornitore che lo opera, tempi di conservazione, chi ha accesso, cosa si fa quando il servizio non risponde. Se quel documento non coincide con l’architettura vera, il problema non è formale: è che non sapete più dove passa il vostro patrimonio informativo.

5. Il pilot deve provare anche l’uscita

Un pilot normale dimostra che il sistema produce una risposta convincente. Un pilot utile dimostra anche che l’azienda sa misurarlo, governarlo e sostituirlo. La differenza salta fuori quando il prototipo è ormai dentro un processo quotidiano e il fornitore cambia prezzi, versione o condizioni.

Prima di scegliere l’infrastruttura conviene preparare una scheda di una pagina per ogni singolo workload. Non un censimento astratto dell’AI aziendale: un foglio operativo con pochi elementi verificabili.

• processo supportato, utenti autorizzati, decisione che resta in capo alle persone;
• categorie di dati ammesse, dati da rimuovere, durata dei log;
• volume medio, picco previsto, latenza massima, disponibilità necessaria;
• soglia di qualità, campione di test, costo della revisione umana;
• componenti sostituibili, formati di esportazione, configurazioni da conservare;
• cosa si fa se modello o infrastruttura non sono disponibili.

Il test di uscita va fatto prima della produzione, non dopo il primo incidente. Si prende un campione rappresentativo, si sostituisce il modello con un’alternativa e si guarda cosa si rompe. Se bisogna riscrivere prompt, connettori e logica applicativa, la dipendenza esiste già. Se la qualità cala, il calo va misurato: può essere accettabile per la classificazione documentale e inaccettabile per la risposta ai clienti.

Vanno poi esportati e conservati sotto il vostro controllo i prompt di sistema, le configurazioni, i test di valutazione, gli schemi dei metadati e la documentazione delle integrazioni. I pesi di un modello non bastano a ricostruire un servizio: senza contesto applicativo, regole di accesso e processo di indicizzazione restano un file molto grande che non garantisce nessuna continuità.

Anche il piano B va dimensionato con buon senso. Non serve duplicare tutto. Per un assistente interno può bastare sospendere la generazione e lasciare attiva la ricerca documentale. Per una classificazione che alimenta ordini o assistenza clienti serve invece un secondo modello pronto a ricevere le richieste, oppure il ritorno controllato a una coda manuale.

6. A volte la scelta più sovrana è un fornitore che vi risponde al telefono

Per molte PMI italiane gestire in proprio driver, runtime, orchestrazione e aggiornamenti dei modelli non è un uso intelligente delle poche ore disponibili. Questo non significa consegnare il progetto intero a una piattaforma globale. Esiste uno spazio reale, e popolato, di provider e system integrator italiani a misura d’azienda, capaci di gestire infrastruttura, osservabilità e supporto lasciando dati, configurazioni e diritto di uscita in mano al cliente.

La vicinanza, però, non è l’indirizzo della sede legale. Un fornitore è vicino quando discute il processo reale e non la demo, quando dichiara i subfornitori, quando documenta il ripristino e lo prova, quando esporta configurazioni e dati in formati che potete riutilizzare altrove. È vicino quando vi propone una GPU più piccola invece di venderne una sovradimensionata, o quando ammette che per quel workload specifico conviene una API esterna.

Nel contratto tenete separate almeno tre cose: infrastruttura, gestione operativa e sviluppo applicativo. Se finiscono in un unico servizio indistinto, cambiare provider vorrà dire rifare anche l’applicazione. Se restano distinte, potete tenere il software, spostare il runtime o affidare l’esercizio a un altro partner senza ricominciare da zero.

L’architettura ibrida è, nella maggior parte dei casi, la scelta più pragmatica: documenti sensibili e compiti ripetitivi su un modello controllato o su un’istanza dedicata, richieste sporadiche e pesanti verso un servizio esterno dopo la minimizzazione dei dati, un livello aziendale di autenticazione, policy e log a tenere insieme il tutto.

Non promette indipendenza assoluta, che nell’IT non esiste per nessuno. Riduce le dipendenze non dichiarate e rende negoziabili quelle che restano. Una PMI non deve possedere ogni componente per essere padrona del proprio sistema: deve sapere quali componenti controlla, quali ha affidato a terzi e quanto tempo serve per sostituirli.

L’AI locale, insomma, è uno strumento e non una strategia. Può migliorare riservatezza, prevedibilità dei costi e continuità, ma solo quando il carico la giustifica e il flusso è progettato di conseguenza. Il vero test non è riuscire ad accendere il modello: è riuscire a spegnerlo, cambiarlo e continuare a lavorare lo stesso.