Eseguire l'AI on-premise evita l'EU AI Act?

No. La normativa si applica in base al caso d'uso e al livello di rischio, non a dove gira il modello. L'on-premise può rendere più facili alcuni obblighi (governance dei dati, logging, supervisione, residenza), ma non ti esenta.

Quali sono i livelli di rischio dell'AI Act?

Inaccettabile (vietato), alto rischio (obblighi stringenti), rischio limitato (obblighi di trasparenza) e rischio minimo (in gran parte non regolato). La maggior parte degli usi LLM aziendali ricade in rischio limitato o alto a seconda del dominio.

I modelli di AI generica hanno regole proprie?

Sì. I modelli di AI generica (GPAI) hanno obblighi di trasparenza, documentazione e policy sul copyright, con requisiti extra per i modelli più capaci ritenuti a rischio sistemico. Anche chi usa modelli aperti eredita alcune responsabilità.

Come aiuta l'on-premise nella compliance?

Dati, log e modello restano sotto la tua governance, rendendo facili da dimostrare residenza dei dati, audit logging, controllo accessi e versioning del modello — e il modello non può essere cambiato da un vendor a tua insaputa, il che protegge la tua validazione.

Un'azienda che usa un modello aperto può diventare provider secondo la normativa?

Sì — se modifichi sostanzialmente un sistema, ci metti il tuo nome o ne cambi la finalità verso un uso ad alto rischio, gli obblighi da provider possono passare a te. Il semplice deployment interno di norma ti lascia deployer; farne un prodotto no.

Quali sono le sanzioni dell'EU AI Act?

Fino a 35M€ o il 7% del fatturato globale per le pratiche vietate; fino a 15M€ o il 3% per la maggior parte delle altre violazioni; fino a 7,5M€ o l'1% per informazioni fuorvianti. Per le PMI vale l'importo più basso.

EU AI Act e AI on-premise (2026): checklist di compliance

Un equivoco comune è che tenere l'AI in casa eviti l'EU AI Act. Non è così — la normativa riguarda come l'AI viene usata e il rischio che pone, indipendentemente dall'infrastruttura. Ciò che l'on-premise ti dà è controllo, e il controllo è la materia di cui sono fatte le prove di compliance. Questa guida mappa livelli, ruoli, obblighi, sanzioni, dove l'on-prem aiuta davvero, e una checklist operativa.

Livelli di rischio e obblighi

Livello	Esempi	Obblighi
Inaccettabile	Social scoring, tecniche manipolative, riconoscimento emozioni a lavoro/scuola	Vietato
Alto rischio	Assunzioni, credito, dispositivi medici, infrastrutture critiche, valutazione scolastica	Regime di compliance completo (vedi sotto)
Rischio limitato	Chatbot, generazione contenuti, deepfake	Trasparenza: dichiarare uso AI / contenuti generati
Rischio minimo	Filtri spam, gran parte dei tool interni	In gran parte non regolato (codici volontari)

Il calendario: entra in vigore per fasi

La normativa è entrata in vigore ad agosto 2024 e si applica a tappe: divieti e obblighi di alfabetizzazione AI da inizio 2025; obblighi GPAI (modelli generici) da metà 2025; il regime principale per l'alto rischio da metà 2026; le regole alto-rischio per l'AI incorporata in prodotti regolamentati si estendono al 2027. Conseguenza pratica: se stai leggendo, divieti e obblighi di trasparenza già ti riguardano, e la macchina dell'alto rischio è operativa o imminente per i tuoi casi d'uso — "ci penseremo poi" ha smesso di essere una strategia nel 2025. Date esatte e normativa secondaria evolvono; verifica lo stato attuale con un legale.

Provider vs deployer — e la trappola in mezzo

La normativa assegna gli obblighi per ruolo. Il provider (chi sviluppa un sistema o modello e lo immette sul mercato) porta i doveri pesanti: valutazione di conformità, documentazione tecnica, marcatura CE per i sistemi ad alto rischio. Il deployer (chi usa l'AI sotto la propria autorità) ha doveri più leggeri ma reali: usare il sistema secondo le istruzioni, garantire supervisione umana e alfabetizzazione AI del personale, conservare i log, svolgere le valutazioni d'impatto privacy dove richieste — e per alcuni usi ad alto rischio, una valutazione d'impatto sui diritti fondamentali (FRIA).

La trappola: i deployer possono diventare provider. Metti il tuo nome/marchio su un sistema AI, modificane uno sostanzialmente, o riconverti un sistema a un uso ad alto rischio, e gli obblighi da provider possono passare a te. Per chi fa self-hosting la domanda viva è il fine-tuning: il semplice deployment interno di un modello open-weight in genere ti lascia deployer, ma più le tue modifiche e la produttizzazione si avvicinano a "immettere un nuovo sistema sul mercato", più i tuoi doveri diventano da provider. Se fai fine-tuning e vendi funzioni AI ai clienti, fatti dare una lettura legale del tuo ruolo — prima, non dopo.

Gli obblighi ad alto rischio, concretamente

Se un caso d'uso ricade nell'alto rischio, il regime richiede (in sostanza): un sistema di gestione del rischio lungo il ciclo di vita; governance dei dati (dati di training/validazione pertinenti e rappresentativi, provenienza documentata ed esame dei bias); documentazione tecnica e logging automatico degli eventi; trasparenza verso deployer/utenti; supervisione umana effettiva; e adeguate accuratezza, robustezza e cybersecurity. Nota di cosa è fatta questa lista: di prove. È un regime di documentazione-e-logging più che di tecnologia — ed è esattamente per questo che il controllo dell'infrastruttura conta.

Modelli GPAI: il livello sotto il tuo caso d'uso

I modelli generici hanno obblighi propri, per lo più sul provider del modello: documentazione tecnica, informazioni agli utilizzatori a valle, una policy di conformità al copyright e una sintesi dei contenuti di training. I modelli sopra una soglia di compute ritenuti a rischio sistemico affrontano doveri extra (valutazioni, segnalazione incidenti, cybersecurity). I modelli open-source godono di esenzioni parziali da alcuni obblighi di trasparenza — una ragione per cui gli open-weight sono attraenti in UE — ma le esenzioni cadono per i modelli a rischio sistemico e non toccano gli obblighi del tuo caso d'uso. Come self-hoster per lo più consumi questo livello: archivia documentazione e provenienza del modello; fa parte della tua catena di prove.

Dove l'on-premise aiuta davvero

Logging senza negoziazione. I sistemi ad alto rischio devono loggare; sulla tua infrastruttura logghi tutto, nel tuo formato, con la tua retention — nessun limite di API del vendor.
Residenza per costruzione. Dati ed elaborazione ancorati alla tua sede UE — una risposta da una riga in audit invece di un'indagine sulla catena di fornitura.
Versioning e congelamento del modello. Le tue prove di conformità descrivono un sistema specifico. Un provider cloud può aggiornare o ritirare un modello sotto i tuoi piedi, invalidando silenziosamente la tua validazione; un modello self-hosted cambia solo quando lo cambi tu — con un changelog.
Auditabilità dell'intera pipeline. Gli auditor possono ispezionare il sistema reale — pesi, prompt, retrieval, log — non una black box dietro una API.
Sinergia GDPR. L'AI Act non sostituisce il GDPR; si applicano entrambi. Le stesse proprietà on-prem (residenza, minimizzazione, controllo accessi) servono entrambi i regimi, e DPIA e FRIA possono condividere la base di prove.

Sanzioni (perché è un tema da consiglio d'amministrazione)

Pratiche vietate: fino a 35M€ o il 7% del fatturato globale. La maggior parte delle altre violazioni, inclusa la non-conformità alto-rischio: fino a 15M€ o il 3%. Informazioni fuorvianti alle autorità: fino a 7,5M€ o l'1%. Le PMI pagano il più basso dei due importi. La cultura sanzionatoria in stile GDPR applicata all'AI: assumi che gli audit arriveranno prima nei settori regolati.

Tre scenari, passo passo

Assistente RAG interno sui documenti aziendali — tipicamente rischio limitato/minimo: trasparenza (gli utenti sanno che è AI), alfabetizzazione AI del personale, igiene GDPR sui log. L'on-prem rende banale la storia privacy. Occhio allo scope creep: il giorno in cui inizia a filtrare CV, ha cambiato livello.
Screening CV / scoring HR — alto rischio per definizione (occupazione). Regime completo: gestione del rischio, governance dei dati (bias!), logging, supervisione umana reale (un umano che può correggere e lo fa), FRIA dove applicabile.
QC visivo su linea di produzione — dipende: lo smistamento qualità è di norma rischio minimo; nel momento in cui agisce da componente di sicurezza di macchinari regolamentati eredita doveri da alto rischio via normativa di prodotto. La classificazione è per funzione, non per progetto.

Checklist di compliance on-premise

✓ Censisci ogni caso d'uso AI e classificalo in un livello di rischio (per funzione, non per progetto)
✓ Determina il tuo ruolo — provider o deployer — per sistema, e monitora i trigger del "diventare provider"
✓ Mantieni log automatici di input/output del modello per i sistemi ad alto rischio (retention definita)
✓ Documenta governance dei dati, provenienza dei dati di training e la documentazione del modello stesso
✓ Versiona e congela i modelli sotto sistemi validati; cambia solo con changelog
✓ Garantisci supervisione umana reale sulle decisioni ad alto rischio (potere di override, e usato)
✓ Dichiara agli utenti l'interazione con AI e i contenuti generati (trasparenza rischio limitato)
✓ Forma il personale: gli obblighi di alfabetizzazione AI valgono per i deployer
✓ Ancora dati ed elaborazione alla giurisdizione richiesta; allinea le prove DPIA (GDPR) e FRIA
✓ Metti a calendario le date di applicazione rilevanti e rivedi le classificazioni ogni anno

Queste sono informazioni generali, non consulenza legale. L'AI Act entra in vigore per fasi, la normativa secondaria e le linee guida evolvono — consulta un legale qualificato per i tuoi obblighi e le scadenze specifiche.