Tendenze AI Pubblicato il 2026-06-15 · 7 min di lettura

EU AI Act nel 2026: cosa cambia il deployment on-prem in termini di conformità

Gli obblighi del deployer per i sistemi ad alto rischio previsti dall'Act entrano in vigore progressivamente nel corso del 2026. Il deployment on-prem non aggira la regolamentazione, ma cambia quali obblighi sono praticabili e quali non possono affatto essere soddisfatti dal SaaS cloud.

L'EU AI Act è entrato in vigore in agosto 2024, con disposizioni applicate gradualmente nell'arco di due o tre anni ^[1]^[2]. La maggior parte delle conversazioni di compliance aziendali si è finora concentrata sul se un workflow rientri o meno nella categoria "ad alto rischio". Verso metà 2026, la conversazione si sta spostando su una domanda più pratica: dato che il workflow rientra nell'ambito, quali architetture di deployment consentono effettivamente di soddisfare gli obblighi del deployer, e quali invece, in silenzio, non lo consentono?

Quella seconda domanda è il punto in cui il deployment on-premises smette di essere una preferenza stilistica e inizia a essere una scelta strutturale.

Cosa chiede l'Act ai deployer di AI ad alto rischio

L'Act distingue tra il provider di un sistema di AI e il suo deployer ^[1]. Una banca che utilizza un'API LLM di terzi per valutare richieste di prestito è il deployer, non il provider. I deployer di sistemi ad alto rischio sostengono obblighi che includono: assicurare la supervisione umana, monitorare il funzionamento del sistema, conservare i log per un periodo adeguato, sospenderne l'uso se il sistema pone un rischio per i diritti fondamentali e dimostrare tali capacità su richiesta.

Diversi di questi obblighi sono semplici quando il deployer controlla il runtime. L'obbligo di "conservare i log per un periodo adeguato" è meccanicamente semplice se l'inferenza avviene su un server di proprietà del deployer e i log atterrano nel SIEM del deployer. L'obbligo di "sospendere l'uso" è altrettanto banale se il deployer può spegnere il modello sulla propria infrastruttura.

Gli stessi obblighi diventano più complicati quando l'inferenza gira su un'API LLM cloud che il deployer non gestisce. I log che il deployer può produrre sono limitati a ciò che il provider espone. Sospenderne l'uso richiede la cooperazione del provider. Dimostrare, in modo contestuale, quali dati siano transitati attraverso il sistema richiede di fidarsi della pipeline del provider.

Come si collocano le API LLM cloud nella regolamentazione

Nulla di tutto questo rende le API LLM cloud non conformi. Articolo per articolo, provider e deployer di AI ospitata in cloud possono soddisfare gli obblighi dell'Act. L'attrito è operativo, non legale: il deployer deve assemblare, auditare e dimostrare la conformità attraverso un confine con il fornitore, spesso per workflow che eseguono migliaia di inferenze al giorno.

L'AI Index longitudinale di Stanford HAI ha tracciato il corrispondente spostamento della spesa aziendale ^[3]: la crescita più ripida nel periodo 2023–2025 non è stata nell'AI generativa generalista, ma nel tooling di supporto — observability, governance, prompt-logging, classificazione dei contenuti, rilevamento del jailbreak. La maggior parte di quella spesa esiste per colmare il divario tra ciò che le API LLM cloud espongono nativamente e ciò che un deployer deve dimostrare in un contesto regolamentare.

Quel divario è il vantaggio strutturale dell'eseguire l'inferenza su hardware di proprietà del deployer. Ogni domanda del tipo "è successo questo?" si riduce a una domanda a cui il deployer può rispondere dai propri log.

Cosa l'on-prem non ti dà gratis

Tre obblighi del deployer previsti dall'AI Act non sono automaticamente soddisfatti da un deployment on-prem, e vale la pena nominarli esplicitamente:

Supervisione umana. L'Act richiede una supervisione significativa dell'AI ad alto rischio, con persone in grado di interpretare gli output e di intervenire. Eseguire il modello localmente non mette una persona nel loop; lo fa il design del workflow.
Monitoraggio per il drift e i comportamenti non sicuri. Il deployer deve monitorare continuamente il sistema. Il deployment on-prem rende banale l'idraulica (i dati sono locali), ma la policy ("come si manifesta il drift per questo workflow?") deve comunque essere definita.
Obblighi del provider trasferiti. Quando il deployment on-prem è costruito su un modello di terzi (per esempio un modello a pesi aperti con licenza non commerciale, o un modello del fornitore distribuito come binario), il deployer deve comunque rendere visibili le disclosure obbligatorie del provider.

Il vantaggio strutturale dell'on-prem riguarda gli assi della gestione dei dati e della dimostrabilità, non quello della policy. La policy deve essere scritta e applicata indipendentemente da dove si trovi la GPU.

Come si combina con USA, Regno Unito e altre giurisdizioni

L'EU AI Act è il più prescrittivo dei principali quadri normativi. Il NIST AI RMF statunitense ^[4] adotta un approccio volontario, basato su framework, e l'OECD AI Policy Observatory ^[5] traccia come i governi nazionali al di fuori dell'UE stiano convergendo su principi sostanzialmente simili (supervisione basata sul rischio, obblighi di trasparenza, regole sulla gestione dei dati).

Per un deployer multinazionale, l'effetto pratico è che la giurisdizione più rigorosa fissa l'architettura. Se un workflow deve soddisfare l'EU AI Act per gli utenti europei, lo stesso workflow non mancherà gli obblighi statunitensi, britannici, giapponesi o singaporiani se è progettato secondo il livello UE. Progettare il deployment secondo il livello più rigoroso — inclusa la capacità del deployer di dimostrare la gestione dei dati per ogni richiesta — è ciò che rende l'on-prem il default strutturalmente più semplice nell'AI aziendale del 2026.

Come appare un deployment AI on-prem pronto per la conformità 2026

La forma che distribuiamo — e la forma che i revisori di compliance con cui collaboriamo richiedono — è:

Inferenza locale al cliente. Sul dispositivo dell'utente o su un server gestito dal cliente. Nessun prompt lascia il perimetro.
Log di audit privi di contenuto. Ogni azione amministrativa è registrata con timestamp + autore; nessun prompt e nessuna risposta compaiono nella riga di audit. La riga di audit è l'evidenza; il contenuto è del deployer, conservato secondo la propria policy di retention.
Identità tramite l'IdP del cliente. OIDC verso Microsoft Entra ID o Google Workspace, con i controlli di accesso esistenti del deployer che si applicano invariati.
Nessun tenant lato fornitore. Il fornitore (noi) non gestisce il runtime, non vede i dati e non è un point of failure per la postura di compliance del deployer.

Quest'ultima proprietà è quella che le API LLM cloud strutturalmente non possono replicare, ed è il motivo per cui il deployment on-prem è il modello dominante nell'angolo enterprise regolamentato del mercato nel 2026.

Il contesto su come abbiamo costruito attorno a questo fin dall'inizio è in Perché distribuiamo l'AI come binari installabili, non come SaaS cloud. Le capacità che implementano la superficie di audit, identità e policy vivono in AI Admin Console.

Riferimenti

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Consultato il 2026-06-15.
European Commission. "AI Act enters into force." digital-strategy.ec.europa.eu. Consultato il 2026-06-15.
Stanford HAI. "AI Index Report." aiindex.stanford.edu. Consultato il 2026-06-15.
NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-06-15.
OECD AI Policy Observatory. "National AI policies." oecd.ai. Consultato il 2026-06-15.

Percorri gli obblighi del deployer attraverso un carico di lavoro reale.

Un pilot gratuito di 1 settimana percorre con il team di compliance del cliente gli obblighi del deployer su un autentico pezzo di lavoro, su inferenza locale, con l'IdP del cliente e l'audit trail del cliente.

Avvia un pilot gratuito di 1 settimana