Con AI Compliance si intende la capacità di un’azienda di dimostrare che i sistemi di Intelligenza Artificiale in uso rispettano i requisiti normativi applicabili, a partire dall’EU AI Act e dal GDPR. In questo articolo, vedremo come, più che dal modello scelto, la conformità dipende da come viene progettato, controllato e documentato il sistema che lo integra nei processi aziendali.
L’Architettura Applicativa per l’AI Compliance
Quando un’azienda porta l’AI Generativa in produzione, la prima domanda sulla compliance riguarda quasi sempre il modello: quale sia il più affidabile, quanto spesso rifiuti un’istruzione illecita. È una domanda comprensibile, ma sposta l’attenzione nel punto sbagliato. Ciò che determina la conformità, infatti, è il sistema costruito attorno al modello.
La normativa europea attribuisce la responsabilità legale al deployer, cioè a chi integra il modello in un sistema specifico, e non a chi lo addestra e lo distribuisce. Ne deriva un modo diverso di impostare governance e compliance, che riguarda meno il procurement e molto di più le scelte di architettura.
Provider e deployer: come l’AI Act distribuisce gli obblighi
L’EU AI Act è il primo quadro normativo europeo che regola lo sviluppo e l’utilizzo dei sistemi di intelligenza artificiale secondo un approccio basato sul rischio. Adottato nel 2024 e applicato per fasi successive, la normativa classifica i sistemi AI in quattro categorie di rischio e assegna a ciascuna obblighi proporzionati: da un lato i divieti per gli usi considerati incompatibili con i diritti fondamentali, dall’altro i semplici obblighi informativi per i sistemi a rischio limitato.
Del suo impatto strategico sulle aziende abbiamo parlato in modo approfondito nell’articolo AI Act e controllo operativo: la regolazione europea come leva strategica. Qui ci concentriamo su un aspetto specifico: come il regolamento ripartisce le responsabilità tra chi sviluppa i modelli e chi li utilizza.
I provider di modelli GPAI
I provider GPAI (General Purpose AI) sono le aziende che addestrano e distribuiscono i foundation model: OpenAI, Anthropic, Google, Meta, Mistral. Parliamo di sistemi generalisti, addestrati su enormi quantità di dati e in grado di svolgere compiti molto diversi. Proprio perché generalisti, nessuno può governarli a priori per ogni contesto in cui verranno impiegati.
Gli obblighi che la normativa assegna a questi soggetti ruotano attorno a trasparenza e documentazione. Il provider, infatti, è obbligato a:
- produrre e tenere aggiornata la documentazione tecnica del modello;
- fornire ai deployer le informazioni utili a capirne capacità e limiti;
- adottare una policy conforme al diritto d’autore europeo;
- pubblicare una sintesi dei contenuti usati per l’addestramento.
Per i modelli a rischio sistemico si aggiungono obblighi di valutazione e gestione del rischio.
Tra questi obblighi non c’è quello di rifiutare i task illeciti, e la scelta ha una sua logica. Un modello generalista non ha gli elementi per capire se un’attività è lecita nel caso d’uso specifico in cui verrà inserito. Quella valutazione può farla solo chi conosce il contesto applicativo.
Il deployer e la responsabilità sul sistema
Il deployer è l’azienda che prende un modello e lo inserisce in un sistema con uno scopo preciso, per esempio un agente di customer service o uno strumento di analisi documentale in ambito finanziario o legale. Con questa scelta si assume la responsabilità legale di come il sistema si comporta nel proprio contesto operativo.
Per i sistemi ad alto rischio gli obblighi sono espliciti; nello specifico, il deployer deve:
- affidare la supervisione umana a persone con competenze e autorità adeguate;
- monitorare il funzionamento del sistema e sospenderlo se emergono rischi;
- conservare i log generati per almeno sei mesi;
- informare i lavoratori quando il sistema interviene nelle loro attività.
La ripartizione segue una logica semplice: il provider conosce il modello, il deployer conosce il caso d’uso. Se in uno scenario simulato un modello esegue un’istruzione potenzialmente illecita, questo non lo rende automaticamente non conforme: gli manca il contesto per valutarla. Costruire quel contesto, insieme ai meccanismi di controllo, spetta al deployer. Se un agente di customer service produce output problematici, ne risponde l’azienda che lo ha configurato e messo in produzione, qualunque sia il modello sottostante.
Le scadenze dell’AI Act
L’AI Act si applica per fasi: alcuni obblighi sono già operativi, altri sono stati rinviati.
Per i provider GPAI gli obblighi valgono da agosto 2025; da agosto 2026 la Commissione europea può esercitare i propri poteri di enforcement. La documentazione tecnica deve quindi essere pronta da esibire alle autorità. In caso di violazione, le sanzioni arrivano fino al 3% del fatturato annuo globale o a 15 milioni di euro.
Dal 2 agosto 2026 si applicano anche gli obblighi di trasparenza dell’Articolo 50, indipendentemente dalla classe di rischio. Chi interagisce con un sistema AI deve saperlo, quando non è evidente, e i contenuti generati devono essere riconoscibili.
Per i sistemi ad alto rischio, invece, il Digital Omnibus on AI ha spostato la scadenza. Gli obblighi per i sistemi dell’Allegato III si applicheranno dal 2 dicembre 2027. L’Allegato III comprende, tra gli altri, HR e recruiting, credit scoring, infrastrutture critiche e amministrazione della giustizia. Per l’AI integrata in prodotti regolamentati la data è il 2 agosto 2028.
Sarebbe un errore leggere il rinvio come un invito ad aspettare. Supervisione umana documentabile, logging auditabile e valutazione di conformità prima del deployment richiedono interventi sull’architettura, e sono lavori che difficilmente si chiudono in poche settimane a ridosso della scadenza.
Il punto di partenza resta la mappatura dei sistemi AI in uso: quali sono, in che contesto operano, con quanta autonomia e chi li supervisiona nei fatti. Senza questo quadro, qualsiasi valutazione del rischio regolatorio poggia su informazioni parziali.
Guardrail, logging e controllo degli accessi
Per costruire una compliance solida occorre quindi intervenire prima di tutto sull’ingegneria dello stack. Usare il comportamento del modello come prima linea di difesa espone l’azienda a un rischio legale sistemico. I modelli cambiano a ogni aggiornamento e reagiscono in modo diverso a seconda del contesto e dei prompt, mentre la responsabilità dell’azienda resta la stessa.
I presidi che contano ai fini della conformità risiedono a livello applicativo e infrastrutturale:
- filtri inbound che analizzano le richieste prima che arrivino al modello;
- filtri outbound sulle risposte generate;
- log strutturati e auditabili di ogni interazione;
- controlli di accesso che stabiliscono chi può usare il sistema e con quale autonomia;
- meccanismi di escalation verso una persona quando il sistema si trova in scenari ad alta incertezza.
Il caso delle architetture agentiche
Con i sistemi agentici la questione si fa ancor più delicata. Si tratta di sistemi che lavorano in autonomia su workflow complessi, chiamano strumenti esterni e correggono da soli il proprio percorso. Quando un agente agisce su un CRM, un ERP o un database, il system prompt da solo non basta a governarlo. Serve un layer infrastrutturale in grado di intercettare, registrare e bloccare i comportamenti anomali prima che abbiano effetti irreversibili.
Supervisione umana: una capacità da dimostrare
La supervisione umana prevista dalla normativa non consiste nel far leggere ogni output a una persona. Per i sistemi che lavorano in autonomia, e gli agenti ne sono l’esempio più evidente, il riferimento più efficace è l’approccio human-on-the-Loop (HOTL).
In questo modello, l’Intelligenza Artificiale esegue l’intero processo in autonomia, mentre la persona agisce come supervisore esterno: monitora l’azione del sistema e si riserva il potere di intervenire o di bloccarlo in caso di anomalie. L’approccio human-in-the-loop richiede un’approvazione umana a ogni passaggio. L’HOTL, invece, conserva l’efficienza dell’automazione senza rinunciare al controllo.
Perché questo modello regga, il potere di intervento deve essere concreto e dimostrabile: chi supervisiona deve poter vedere cosa sta accadendo, fermare il processo e ricostruirne le decisioni a posteriori. Servono quindi log, alert e meccanismi di override funzionanti. Una dichiarazione di principio in una policy interna, da sola, non regge a un’ispezione.
Tre approcci alla compliance a confronto
Nei contesti enterprise si incontrano soprattutto tre modi di affrontare la conformità: affidarsi al comportamento del modello, distribuire i controlli nelle singole applicazioni oppure centralizzare la governance a livello di stack. Nella tabella seguente li mettiamo a confronto:
| Approccio | Dove risiede il controllo | Stabilità nel tempo | Tracciabilità e audit | Esposizione legale del deployer |
| 1. Affidamento al modello | Nel comportamento del modello e nei suoi meccanismi di rifiuto. | Bassa; cambia a ogni aggiornamento del provider. | Assente o delegata al provider. | Elevata; la responsabilità resta, i presidi mancano. |
| 2. Controlli applicativi frammentati | Nel codice dei singoli progetti, con logiche diverse per ogni team. | Media; dipende dalla manutenzione di ciascuna applicazione. | Log disomogenei, difficili da ricostruire durante un’ispezione. | Significativa; è difficile dimostrare la conformità in modo uniforme. |
| 3. Governance centralizzata a livello di stack | In un layer infrastrutturale unico, applicato a tutti i flussi. | Alta; le policy restano valide anche cambiando modello. | Log strutturati e centralizzati, pronti per un audit. | Contenuta; la conformità è progettata, misurabile e documentata. |
L’approccio di Bitrock
In Bitrock consideriamo l’AI Compliance una proprietà dell’architettura, da progettare fin dall’inizio anziché ricostruire a posteriori con la documentazione. Un approccio simile a quello adottato relativamente all’AI Governance, di cui abbiamo parlato nei nostri articoli precedenti, e lo applichiamo con un percorso incrementale che non ferma il lavoro dei team.
Si parte dalla mappatura dei sistemi AI in uso. Per ciascuno ricostruiamo il contesto operativo e il grado di autonomia e attribuiamo la classe di rischio prevista dall’EU AI Act. Su questa base progettiamo i guardrail: filtri inbound e outbound, regole di mascheramento dei dati sensibili e policy di accesso calibrate sul singolo caso d’uso. Il passo successivo riguarda la tracciabilità, con un logging auditabile di ogni interazione e tempi di conservazione allineati ai requisiti normativi. Infine rendiamo la supervisione umana verificabile, introducendo alert, escalation e meccanismi di override coerenti con un modello human-on-the-loop.
Sul piano tecnologico, proponiamo di introdurre l’AI Gateway di Radicalbit, parte del product portfolio del Gruppo Fortitude: un layer centralizzato che si colloca tra le applicazioni aziendali e i provider di LLM.
Nel concreto, il Gateway:
- Applica guardrail trasversali: i controlli inbound e outbound valgono per tutti i progetti, senza modificare il codice delle singole applicazioni.
- Produce un audit trail strutturato: ogni chiamata viene registrata con metadati su modello, latenza, utente e costo, così da poter rispondere a un’ispezione o ricostruire il comportamento del sistema in qualsiasi momento.
- Instrada le richieste secondo criteri di compliance: i casi d’uso più sensibili possono essere isolati su modelli on-premise o su deployment geograficamente appropriati, senza toccare il codice applicativo.
- Disaccoppia l’azienda dai provider: se un vendor cambia policy, pricing o disponibilità, il passaggio a un’alternativa non richiede riscritture architetturali.
Conclusione
Scegliere il modello più sicuro o fidarsi dei tassi di rifiuto misurati nei benchmark non basta a rispettare la normativa europea sull’AI. Quei dati aiutano a capire come si comporta un modello, ma la conformità si valuta su un altro piano: quello del sistema che il deployer costruisce attorno al modello.
Questo cambio di prospettiva ha anche un vantaggio pratico. Finché la compliance dipende dal modello, ogni aggiornamento del provider rimette tutto in discussione. Quando invece è una proprietà del proprio sistema, l’azienda può progettarla, misurarla e dimostrarla con i propri strumenti e alle proprie condizioni.
Contatta il team di Bitrock per un assessment dedicato. Partiamo dalla mappatura dei tuoi sistemi AI per capire cosa serve a renderli conformi, tracciabili e pronti per le prossime scadenze dell’AI Act.
FAQ
No. L’AI Act assegna ai provider GPAI obblighi di trasparenza e documentazione sul modello. La responsabilità per il comportamento del sistema nel suo contesto operativo resta però al deployer, cioè all’azienda che integra il modello e lo mette in produzione. Un buon risultato nei benchmark non esonera dal costruire guardrail, logging e supervisione umana adeguati.
Il Digital Omnibus ha spostato al 2 dicembre 2027 la scadenza per i sistemi dell’Allegato III, ma gli obblighi di trasparenza sono già in vigore. Il lavoro necessario richiede comunque tempo: mappatura dei sistemi, classificazione del rischio, logging e supervisione sono interventi architetturali. Chi inizia ora arriva alla scadenza con presidi già consolidati, invece di doversi adeguare in emergenza.
Un AI Gateway come quello di Radicalbit fa passare tutto il traffico verso gli LLM da un unico punto di controllo. Lì si possono applicare guardrail uniformi, registrare ogni interazione in modo auditabile e instradare le richieste secondo criteri di compliance, per esempio verso modelli on-premise per i casi d’uso più sensibili. Bitrock ne cura la progettazione e l’integrazione nello stack esistente, all’interno di un percorso di governance più ampio.