Il Regolamento UE sull'IA è entrato in vigore nell'agosto 2024, con disposizioni introdotte gradualmente in un arco di due-tre anni [1][2]. Finora, la maggior parte delle conversazioni aziendali sulla conformità si è concentrata sul fatto che un flusso di lavoro rientri o meno nella categoria "ad alto rischio". A metà 2026, la discussione si sta spostando verso una domanda più pratica: dato che il flusso di lavoro è in ambito di applicazione, quali architetture di deployment consentono effettivamente di soddisfare le obbligazioni del deployer, e quali invece no?

Questa seconda domanda è il punto in cui il deployment on-prem smette di essere una preferenza stilistica e diventa una scelta strutturale.

Cosa richiede il Regolamento ai deployer di IA ad alto rischio

Il Regolamento distingue tra il fornitore di un sistema di IA e il deployer di esso [1]. Una banca che utilizza un'API LLM di terze parti per valutare le domande di prestito è il deployer, non il fornitore. I deployer di sistemi ad alto rischio hanno obblighi che includono: garantire la supervisione umana, monitorare il funzionamento del sistema, conservare i log per un periodo appropriato, sospendere l'uso se il sistema rappresenta un rischio per i diritti fondamentali e dimostrare queste capacità su richiesta.

Diverse di queste obbligazioni sono semplici da rispettare quando il deployer controlla l'ambiente di esecuzione. L'obbligo di "conservare i log per un periodo appropriato" è meccanicamente semplice se l'inferenza avviene su un server di proprietà del deployer e i log vengono archiviati nel SIEM del deployer. L'obbligo di "sospendere l'uso" è altrettanto banale se il deployer può spegnere il modello sulla propria infrastruttura.

Le stesse obbligazioni diventano più difficili quando l'inferenza avviene su un'API LLM cloud che il deployer non gestisce. I log che il deployer può produrre sono limitati a ciò che il fornitore espone. Sospendere l'uso richiede la cooperazione del fornitore. Dimostrare, in tempo reale, quali dati sono transitati nel sistema richiede di fidarsi della pipeline del fornitore.

Dove si collocano le API LLM cloud nella normativa

Niente di tutto ciò rende non conformi le API LLM cloud. Articolo per articolo, fornitori e implementatori di AI ospitata su cloud possono soddisfare gli obblighi del Regolamento. L’attrito è operativo, non legale: l’implementatore deve assemblare, verificare e dimostrare la conformità attraverso un confine di fornitore, spesso per flussi di lavoro che eseguono migliaia di inferenze al giorno.

L’indice longitudinale AI di Stanford HAI ha monitorato il corrispondente cambiamento nella spesa aziendale [3]: la crescita più marcata tra il 2023 e il 2025 non è stata nell’AI generativa a scopo generale, ma negli strumenti di supporto — osservabilità, governance, registrazione dei prompt, classificazione dei contenuti, rilevamento di jailbreak. La maggior parte di questa spesa serve a colmare il divario tra ciò che le API LLM cloud espongono nativamente e ciò che un implementatore deve dimostrare in un contesto regolatorio.

Questo divario è il vantaggio strutturale di eseguire l’inferenza su hardware di proprietà dell’implementatore. Ogni domanda “è successo questo?” si riduce a una domanda a cui l’implementatore può rispondere dai propri log.

Cosa l’on-prem non ti regala gratuitamente

Tre obblighi dell’implementatore previsti dal Regolamento AI non sono automaticamente soddisfatti da un’implementazione on-prem, ed è utile nominarli esplicitamente:

  • Supervisione umana. Il Regolamento richiede una supervisione significativa dell’AI ad alto rischio, con umani in grado di interpretare i risultati e intervenire. Eseguire il modello localmente non mette un umano nel ciclo; lo fa il design del flusso di lavoro.
  • Monitoraggio di deriva e comportamenti non sicuri. L’implementatore deve monitorare continuamente il sistema. L’implementazione on-prem rende l’infrastruttura banale (i dati sono locali), ma la policy (“come si manifesta la deriva in questo flusso di lavoro?”) deve comunque essere definita.
  • Obblighi del fornitore trasmessi. Quando l’implementazione on-prem si basa su un modello di terzi (ad esempio, un modello open-weight sotto licenza non commerciale, o un modello vendor fornito come binario), l’implementatore deve comunque rendere evidenti le dichiarazioni richieste dal fornitore.

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

Come si integra con USA, Regno Unito e altre giurisdizioni

Il Regolamento AI UE è il più prescrittivo tra i principali quadri normativi. Il NIST AI RMF USA [4] adotta un approccio volontario basato su framework, e l’Osservatorio Politiche AI OCSE [5] monitora come i governi nazionali fuori dall’UE convergano su principi sostanzialmente simili (supervisione basata sul rischio, obblighi di trasparenza, regole di gestione dei dati).

Per un implementatore multinazionale, l’effetto pratico è che la giurisdizione più severa determina l’architettura. Se un flusso di lavoro deve soddisfare il Regolamento AI UE per utenti europei, lo stesso flusso non fallirà gli obblighi USA, UK, giapponesi o di Singapore se progettato secondo lo standard UE. Progettare l’implementazione secondo lo standard più severo — inclusa la capacità dell’implementatore di dimostrare la gestione dei dati per ogni richiesta — è ciò che rende l’on-prem la scelta strutturalmente più semplice per l’AI aziendale nel 2026.

Come appare un’implementazione AI on-prem pronta per la conformità 2026

La configurazione che distribuiamo — e quella richiesta dai revisori della conformità con cui collaboriamo — è:

  • Inferenza locale presso il cliente. Sia sul dispositivo dell'utente sia su un server gestito dal cliente. Nessun prompt esce dal perimetro.
  • Log di audit privi di contenuto. Ogni azione amministrativa è registrata con data e ora + attore; nessun prompt né risposta appare nella riga di audit. La riga di audit è la prova; il contenuto è di proprietà del deployer da conservare secondo la propria politica di retention.
  • Identità tramite l'IdP del cliente. OIDC contro Microsoft Entra ID o Google Workspace, con i controlli di accesso esistenti del deployer che rimangono invariati.
  • Nessun tenant di inferenza gestito dal fornitore. Software Tailor non gestisce il runtime del modello né riceve prompt, risposte o documenti del cliente su questo percorso. Identità dell'organizzazione, licenze, policy, stato del server, utilizzo aggregato, audit e registri di supporto possono comunque utilizzare un control plane del fornitore e devono essere valutati come dipendenza separata.

Questa ultima caratteristica dell'inferenza è quella che le API cloud LLM non possono replicare strutturalmente. Non rende automaticamente conforme un prodotto on-premises né elimina la necessità di valutare il suo control plane, le vie di supporto, la catena di fornitura del modello e le responsabilità operative del cliente.

Le basi di come abbiamo costruito tutto questo fin dall'inizio sono in Perché distribuiamo AI come binari installabili, non come SaaS cloud. Le funzionalità che implementano audit, identità e policy risiedono in AI Admin Console.

Riferimenti

  1. Commissione Europea. "AI Act — Quadro normativo sull'IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Accesso 15-06-2026.
  2. Commissione Europea. "Entrata in vigore dell'AI Act." https://digital-strategy.ec.europa.eu/Accesso il 15-06-2026.
  3. Stanford HAI. "Rapporto sull'Indice AI." https://aiindex.stanford.edu/Accesso il 15-06-2026.
  4. NIST. "Quadro di Gestione del Rischio AI (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-frameworkAccesso il 15-06-2026.
  5. Osservatorio Politiche AI OCSE. "Politiche nazionali sull'AI." https://oecd.ai/Accesso il 15-06-2026.