Nella prima ondata di sperimentazione, molte aziende hanno affrontato l’AI come una questione quasi esclusivamente applicativa: quale tool usare, quale vendor scegliere, quali persone coinvolgere per partire in fretta. Era una fase necessaria. Ma quando l’uso si avvicina ai processi reali, la domanda cambia natura. Non basta più chiedersi se l’AI possa essere utile. Bisogna capire dove debba girare, con quali dati, con quali confini, sotto quali controlli e con quale tracciabilità.
È in questo passaggio che la governance dei dati smette di essere un capitolo legale o IT a valle del progetto e diventa una scelta di design.
In Europa il tema è ormai esplicito: l’AI Act è entrato in vigore nell’agosto 2024; da febbraio 2025 si applicano divieti, definizioni e obblighi di AI literacy, mentre le regole di governance e gli obblighi per i modelli general purpose sono entrati in applicazione dall’agosto 2025.
NIST, con il profilo dedicato alla generative AI, insiste sul fatto che il rischio vada gestito lungo tutto il ciclo di vita, dalla progettazione al monitoraggio. Tradotto in termini aziendali: architettura e governance non possono più essere separate.
Indice degli argomenti:
L’AI locale non è ideologia: è un’opzione architetturale
Nel dibattito pubblico l’idea di AI locale viene spesso letta come una reazione difensiva: paura della cloud, sfiducia verso i grandi provider, desiderio di controllo totale. In realtà è, più semplicemente, una delle opzioni progettuali disponibili. Far girare un modello in locale, su device o in ambienti privati, può avere molto senso quando entrano in gioco dati sensibili, esigenze di latenza, continuità operativa in contesti offline, vincoli regolatori o necessità di ridurre l’esposizione dei flussi informativi.
Microsoft ha evidenziato scenari in cui l’elaborazione locale consente di trattare dati sensibili senza upload verso il cloud, mentre Deloitte ha previsto una crescita importante dei dispositivi dotati di capacità di generative AI locale. Questo significa che l’AI locale non è più un tema di laboratorio. Sta diventando parte della strategia enterprise su device, sicurezza e produttività.
Tre architetture, tre logiche di valore
Per semplificare, oggi le aziende possono ragionare su tre modelli.
Il primo è l’on-device o local-first, utile per task personali o di team che richiedono prossimità ai dati, velocità di risposta, funzionamento anche senza connessione o riduzione del rischio di esposizione.
Il secondo è l’ambiente privato o on-premise, più adatto quando servono controllo stretto, integrazione profonda con sistemi interni, auditabilità e politiche severe di accesso ai dati.
Il terzo è il modello ibrido, che per molte imprese è il più realistico: una parte del lavoro resta vicino ai dati, un’altra sfrutta scalabilità, aggiornamento e potenza del cloud.
Il punto non è decidere in astratto se sia meglio il locale o il cloud. Il punto è capire quale segmento del workflow debba restare vicino al dato e quale, invece, possa beneficiare di una capacità esterna più ampia. Pensare in termini binari porta quasi sempre a due errori opposti: sistemi iperprotetti ma inutilizzabili, oppure sistemi molto accessibili ma troppo esposti e poco governabili.
Le cinque scelte progettuali che contano davvero
Le decisioni architetturali realmente importanti sono almeno cinque.
La prima riguarda la classificazione dei dati: quali dati sono ammessi, sensibili, riservati, vietati o soggetti a condizioni particolari.
La seconda riguarda il movimento del dato: dove entra, dove viene trattato, se viene memorizzato, per quanto tempo e con quali logiche di retention.
La terza riguarda il modello: dimensione, costo, latenza, capacità di personalizzazione, explainability e vincoli di deployment.
La quarta riguarda controlli e responsabilità: identità, logging, approvazioni umane, tracciabilità degli accessi, gestione delle eccezioni.
La quinta riguarda l’integrazione con le basi di conoscenza e con i sistemi di record aziendali.
Senza queste scelte, la governance resta un documento e non un sistema operativo. E quando la governance non si traduce in decisioni progettuali, viene aggirata dal business quasi inevitabilmente.
Perché i modelli più grandi non sono sempre la scelta migliore
Nel discorso pubblico esiste ancora una fascinazione quasi automatica per i modelli più grandi. Ma nei contesti enterprise la dimensione non coincide sempre con il valore. IBM osserva che i CEO possono ottenere un vantaggio più concreto adottando modelli più piccoli, alimentati con dati d’impresa pertinenti, perché in molti casi producono output più adatti al contesto, con minore costo computazionale e maggiore controllabilità. Questo è un punto chiave: la qualità percepita nel business dipende spesso più dall’allineamento al dominio che dalla sola potenza generica del modello.
Inoltre i modelli locali o più compatti costringono spesso l’organizzazione a essere più disciplinata. Aiutano a circoscrivere use case, a selezionare meglio i dati, a definire output più misurabili, a distinguere ciò che deve restare interno da ciò che può essere delegato all’esterno. In molti casi questa disciplina migliora non solo la sicurezza, ma anche l’adozione.
Governare i dati significa governare i comportamenti
La governance dei dati nell’AI non si esaurisce in una policy. Tocca comportamenti quotidiani: che cosa si può copiare e incollare in un sistema, quali connettori sono consentiti, come si costruisce una base RAG, quali output devono essere verificati, che cosa va loggato, che cosa può essere riusato per il fine-tuning, quali diritti ha il vendor su input e output, come si gestiscono anonimizzazione e retention.
L’EDPB ha richiamato l’attenzione sui rischi di privacy e leakage legati ai large language model, segnalando che l’uso di questi sistemi richiede misure tecniche e organizzative coerenti.
Questo significa che la governance efficace non è quella che vive solo nel dipartimento legale. È quella che arriva fino al comportamento del singolo utente e del singolo manager. Se le persone non sanno quali dati possano usare, dove finiscano i log, quando serva una revisione umana o quali fonti siano approvate, l’architettura verrà rapidamente bypassata.
La scelta migliore è quella che l’azienda riesce ad adottare
In molte organizzazioni il problema non è scegliere l’architettura più sofisticata, ma quella più adottabile. Una piattaforma perfettamente sicura ma troppo lenta, troppo complessa o troppo distante dal lavoro reale verrà evitata. Una soluzione semplicissima ma senza controllo sui dati o senza tracciabilità genererà invece timore, resistenze e, prima o poi, incidenti. L’adozione reale sta nel mezzo: fiducia sufficiente, frizione accettabile, chiarezza su ruoli e responsabilità.
Per questo l’AI locale, le architetture ibride e la data governance non sono temi tecnici da lasciare agli specialisti. Sono scelte di management e di modello operativo. Determinano quali use case possano scalare, quanto il business si fidi, quanta libertà possa avere il team e quanto l’organizzazione sia in grado di trasformare la sperimentazione in un sistema stabile.
La vera domanda non è solo dove gira il modello. È se quella scelta rende l’AI finalmente utilizzabile, controllabile e sostenibile per l’azienda.
Takeaway
- Con l’AI che entra nei processi, architettura e governance dei dati diventano parte della strategia di adozione.
- AI locale, ambienti privati e modelli ibridi rispondono a esigenze diverse di rischio, latenza, sovranità e usabilità.
- Le decisioni chiave riguardano classificazione dei dati, movimento del dato, scelta del modello, controlli e integrazione.
- La governance efficace non resta nelle policy: arriva fino ai comportamenti quotidiani di utenti, manager e sistemi.
