EU AI Act e modelli on-premise: cosa cambia per le aziende

Il Regolamento (UE) 2024/1689 è entrato in vigore il 1° agosto 2024 con applicazione graduale: i divieti sulle pratiche a rischio inaccettabile si applicano dal 2 febbraio 2025, gli obblighi per i modelli a uso generale (GPAI) dal 2 agosto 2025, mentre la parte più corposa — i requisiti per i sistemi ad alto rischio — diventa pienamente applicabile dal 2 agosto 2026. Le sanzioni possono arrivare a 35 milioni di euro o al 7% del fatturato mondiale per le pratiche vietate, e a 15 milioni o al 3% per la maggior parte delle altre violazioni. Le date esatte possono essere oggetto di revisioni normative: verificare sempre lo stato aggiornato prima di pianificare.

L'architettura del regolamento è basata sul rischio: pratiche vietate, sistemi ad alto rischio (con obblighi di gestione del rischio, qualità dei dati, documentazione tecnica, logging, trasparenza e supervisione umana), sistemi a rischio limitato (soprattutto obblighi di trasparenza) e rischio minimo. Un punto spesso sottovalutato: gli obblighi colpiscono sia chi fornisce il sistema sia chi lo utilizza in un contesto professionale, il cosiddetto deployer. Se la tua azienda usa l'AI su persone, documenti o processi rilevanti, ha responsabilità proprie anche se il modello arriva da un fornitore esterno.

Nella pratica, la parte dell'AI Act che interseca più direttamente il lavoro quotidiano di un DPO è la gestione dei dati: qualità, pertinenza, tracciabilità e minimizzazione. A questa si somma il GDPR, che resta pienamente applicabile. Inviare prompt e documenti a un'API esterna significa trasferire dati personali a un titolare o responsabile terzo: servono basi giuridiche, valutazioni sui trasferimenti extra-UE, accordi di trattamento e spesso una DPIA quando il trattamento è sistematico o sensibile.

Ogni passaggio a un fornitore esterno aggiunge lavoro di compliance ricorrente, non una tantum: il vendor cambia termini, regioni di trattamento, sottoresponsabili o policy di retention, e la valutazione va rifatta. Questo è il costo nascosto dell'inferenza in cloud per dati sensibili: non la fattura per token, ma il perimetro giuridico da presidiare in modo permanente.

Eseguire il modello nel proprio perimetro — un server aziendale, una workstation dedicata, infrastruttura privata — elimina alla radice la categoria più problematica di trasferimenti: i dati non lasciano l'ambiente che controlli, quindi non servono clausole per trasferimenti extra-UE, la minimizzazione è applicabile per progetto e la residenza del dato è un fatto tecnico, non una promessa contrattuale. Anche la fase di preparazione del modello può rispettare lo stesso principio: con un servizio a zero retention come Distiller Cloud, dataset e artefatti di addestramento vengono distrutti automaticamente entro 48 ore dalla consegna, senza copie residue presso terzi.

Il secondo vantaggio è l'auditabilità. Un modello scaricato come file — in formati standard come GGUF o safetensors — è un artefatto: ha una versione, può essere testato su un set di valutazione proprio, archiviato e riesaminato. Quando l'AI Act chiede documentazione tecnica, logging e capacità di supervisione umana, lavorare su un artefatto posseduto è più semplice che ricostruire il comportamento di un servizio esterno che può cambiare senza preavviso.

Vale la pena dirlo con chiarezza, perché è l'errore più comune: se il caso d'uso rientra fra quelli ad alto rischio — valutazione del personale, selezione, credito, servizi essenziali — gli obblighi dell'AI Act si applicano anche a un modello eseguito interamente in locale. Il deployment non cambia la classificazione di rischio, che dipende da cosa fa il sistema e su chi.

Ciò che cambia è il costo di dimostrare la conformità. Con il controllo pieno su dati, logging, ambiente di esecuzione e versioni del modello, gli adempimenti diventano processi interni invece che negoziazioni con un fornitore. Ed è più semplice anche la scelta inversa: se un caso d'uso è troppo rischioso o poco chiaro, lo si può tenere fermo senza dipendere dalle tempistiche di nessuno.

Primo: costruire l'inventario dei casi d'uso AI, esistenti e pianificati, indicando per ciascuno dati trattati, persone coinvolte e fornitori. Secondo: classificare ogni caso secondo le categorie di rischio del regolamento — per la maggior parte delle automazioni interne il livello sarà limitato o minimo, ma la classificazione va documentata. Terzo: per i dati sensibili, valutare quali flussi possono essere spostati su modelli locali o privati, partendo dai compiti ripetitivi e circoscritti dove un modello specializzato basta. Quarto: fissare le domande da porre a ogni fornitore — retention, uso dei dati per addestramento, sub-responsabili, regioni di trattamento — e applicare le stesse domande ai processi interni.

La direzione che emerge è una strategia a due velocità: API generaliste per sperimentazione e compiti su dati non sensibili, modelli specializzati nel proprio perimetro per i flussi stabili su dati che contano. È esattamente il secondo scenario quello per cui nasce Distiller Cloud: un modello piccolo, tagliato sul tuo compito, che scarichi ed esegui dove le tue policy lo consentono — con la certezza che nulla resta sui nostri server oltre le 48 ore dalla consegna.