L’AI Compliance per un’azienda che usa modelli generativi in produzione non è una questione di quanto spesso un LLM si rifiuta di eseguire istruzioni illecite. Dipende da molti altri fattori, in primis da come è costruito il sistema attorno al modello. L’attuale normativa europea sull’Intelligenza Artificiale assegna la responsabilità legale a chi integra un modello in un sistema specifico – il deployer – e non a chi il modello lo addestra e distribuisce. Una distinzione che cambia il modo in cui va progettata la governance e la compliance aziendale.
I benchmark di compliance sui modelli AI
Nei mesi scorsi ha avuto ampia circolazione uno studio condotto da Aithos, una fondazione di ricerca olandese no-profit, che ha testato 12 dei principali modelli AI su scenari simulati di ambienti lavorativi reali. Il framework si chiama LARA — Legal Assessment for Real-world Agents — e misura quante volte un modello esegue istruzioni che richiederebbero di violare le norme europee sull’AI o il GDPR. I risultati hanno mostrato tassi di compliance che variano sensibilmente tra i modelli testati, con il migliore che non oppone resistenza nel 46% degli scenari e il peggiore nel 93%.
Lo studio tocca un tema concreto: i sistemi AI in produzione possono produrre output o eseguire azioni problematiche dal punto di vista normativo. Un tema che ogni azienda che porta AI nei propri workflow operativi deve affrontare.
Va però chiarito cosa misura esattamente il framework: ciò che LARA valuta è la propensione del modello a rifiutare un task in scenari costruiti ad hoc. Il punteggio è calcolato dallo stesso sistema AI valutato, senza processo di peer review, e non corrisponde alla postura di compliance di un’azienda che usa quel modello in produzione. La ragione è strutturale e dipende da come la normativa europea distribuisce le responsabilità tra i diversi soggetti della filiera.
Provider e deployer: come la normativa AI distribuisce gli obblighi
Per capire dove ricade la responsabilità di compliance, occorre partire da una distinzione che la normativa europea introduce con precisione: quella tra provider di modelli GPAI e deployer.
I provider GPAI (General Purpose) sono le aziende che addestrano e distribuiscono i modelli linguistici di base: OpenAI, Anthropic, Google, Meta, Mistral, ecc. Sistemi generalisti, addestrati su enormi corpus di dati, capaci di svolgere una vasta gamma di task in domìni diversi. Ed è proprio questa generalità a renderli praticamente impossibili da governare a priori per ogni contesto applicativo in cui finiranno.
Per questi soggetti, la normativa fissa obblighi che ruotano attorno a trasparenza e documentazione: produrre e mantenere aggiornata la documentazione tecnica sul modello (architettura, dati di training, risorse computazionali); fornire ai deployer le informazioni necessarie per comprendere capacità e limitazioni; adottare una policy di rispetto del copyright europeo; pubblicare un sommario dei contenuti usati per il training. Per i modelli con rischio sistemico, ovvero quelli addestrati con soglie computazionali molto elevate, si aggiungono obblighi di valutazione e gestione del rischio.
Nessuno di questi obblighi impone che il modello rifiuti i task illegali, ed è una scelta coerente: un modello generalista non ha il contesto per distinguere un task illecito da uno legittimo nei possibili use-case in cui verrà impiegato. Questa valutazione appartiene a chi conosce il contesto applicativo specifico.
Responsabilità di compliance del deployer: obblighi sui sistemi ad alto rischio
Il deployer è l’azienda che prende un modello e lo integra in un sistema specifico per un uso determinato (per esempio, un agente per il customer service o un tool di analisi documentale in contesti finanziari o legali). Con questa scelta, il deployer assume la responsabilità legale del comportamento di quel sistema nel suo contesto operativo.
Gli obblighi che la normativa pone ai deployer di sistemi ad alto rischio sono espliciti: garantire supervisione umana affidata a personale con competenze e autorità adeguate; monitorare il funzionamento del sistema e sospenderlo in caso di rischi; conservare i log generati per un minimo di sei mesi; informare i lavoratori quando il sistema è utilizzato nell’ambito delle loro attività.
La differenza con il provider GPAI è strutturale: il provider conosce il modello, il deployer conosce il caso d’uso. L’AI Act ha distribuito le responsabilità di conseguenza. Un modello che in uno scenario simulato esegue un’istruzione potenzialmente illecita non è necessariamente un modello non-compliant: è un modello che non ha il contesto per valutare quella specifica istruzione nell’ambiente operativo in cui viene usato. Costruire quel contesto e i meccanismi di controllo appropriati ricade sul deployer.
Se un agente AI per il customer service produce output problematici, la responsabilità legale è dell’azienda che ha configurato e messo in produzione quel sistema, indipendentemente dal modello sottostante.
Trasparenza, supervisione e tracciabilità
Le disposizioni su trasparenza, supervisione umana e tracciabilità delle decisioni automatizzate sono ormai pienamente operative, così come i poteri di enforcement della Commissione europea.
Per i provider questo significa che la documentazione tecnica deve essere già pronta e disponibile su richiesta delle autorità. Le sanzioni arrivano fino al 3% del fatturato globale annuo o 15 milioni di euro in caso di inadempienza.
Per i deployer, gli obblighi dipendono dalla classificazione del sistema. I sistemi ad alto rischio, come quelli in contesti HR, accesso al credito,infrastrutture critiche e processi giudiziari, portano i requisiti più stringenti: supervisione umana documentabile, logging auditabile, valutazione di conformità prima del deployment. Ma anche fuori da questa categoria, le norme sulla trasparenza obbligano a dichiarare che si sta interagendo con un sistema AI quando non è ovvio per l’utente.
La mappatura dei propri sistemi AI rimane il prerequisito di qualunque strategia di compliance: sapere quali sistemi sono in uso, in quale contesto operativo, con quale grado di autonomia, e chi ne ha la supervisione effettiva. Senza questa visibilità, qualsiasi valutazione di rischio normativo resta incompleta.
AI Compliance a livello di stack: guardrail, logging e controlli di accesso
La conseguenza pratica di questa distinzione è che costruire una postura di compliance solida è un problema di ingegneria dello stack, e non solo di selezione del modello. Affidarsi al comportamento del modello come principale linea di difesa introduce un rischio legale sistemico: i modelli cambiano con gli aggiornamenti, il loro comportamento varia con il contesto e il prompt, e la responsabilità dell’azienda rimane invariata indipendentemente da cosa fa il modello.
I guardrail che contano ai fini della compliance si costruiscono al livello applicativo e infrastrutturale: filtri inbound che analizzano le richieste prima che raggiungano il modello, filtri outbound sulle risposte generate, log strutturati e auditabili di ogni interazione, controlli di accesso che definiscono chi può usare il sistema e con quale autonomia, meccanismi di escalation verso la supervisione umana quando il sistema incontra scenari ad alta incertezza.
Per le architetture agentiche, quei sistemi che operano in autonomia su workflow complessi, chiamano tool esterni e si auto-correggono, questo diventa ancora più critico. Un agente che esegue azioni su sistemi esterni come CRM, ERP o database non può essere governato solo attraverso il prompt di sistema: serve un layer infrastrutturale che possa intercettare, loggare e bloccare comportamenti anomali prima che producano effetti irreversibili.
La supervisione umana che la normativa richiede non è la presenza di un umano che legge ogni output: è la capacità dimostrabile di intervenire nel processo AI, di fermarlo, di auditarne le decisioni. Questa capacità deve essere dimostrabile tecnicamente, attraverso log, alert e meccanismi di override, non può essere un’affermazione di principio in una policy interna.
AI Gateway: un layer di governance centralizzato per la compliance
Le aziende enterprise che portano l’AI in più workflow contemporaneamente si trovano davanti a una frammentazione della governance che rende l’audit difficile e la risposta a un incidente lenta.
La risposta infrastrutturale a questo problema è un layer centralizzato tra le applicazioni aziendali e i provider LLM. Questo layer applica guardrail inbound e outbound in modo trasversale a tutti i progetti, senza richiedere modifiche al codice applicativo di ogni singolo sistema. Il logging strutturato per ogni chiamata, con metadati su modello, latenza, utente e costo, produce la traccia auditabile necessaria per rispondere a un’ispezione o ricostruire il comportamento del sistema in un dato momento.
Il routing intelligente multi-model consente di assegnare ogni richiesta al modello più adeguato anche in base a criteri di compliance: isolare certi use-case su modelli on-premise o in deployment geograficamente appropriato è una scelta che si gestisce a livello di gateway, senza toccare il codice delle applicazioni che lo utilizzano.
Il disaccoppiamento dal vendor lock-in significa che se le condizioni di un provider cambiano in termini di policy, pricing o disponibilità, la transizione non richiede riscritture architetturali.
L’AI Gateway di Radicalbit è progettato esattamente per questo scenario: centralizzare la governance delle chiamate LLM, rendere la spesa e il comportamento dei sistemi AI visibili e controllabili, e fornire il layer infrastrutturale su cui costruire una postura di compliance auditabile.
Conclusione
La compliance alla normativa europea sull’AI non si risolve scegliendo il modello più sicuro né affidandosi ai comportamenti di rifiuto testati in benchmark simulati. Questi benchmark sono utili per capire come si comporta un modello, ma misurano una dimensione diversa dalla conformità: la conformità non vive nel modello, vive nel sistema che il deployer costruisce attorno a esso.
Questo sposta il problema dall’acquisto all’ingegneria. Non esiste un modello che, una volta scelto, mette l’azienda al riparo: esiste uno stack progettato bene, con guardrail al livello giusto, log che reggono un audit e una supervisione umana che può davvero fermare il sistema quando serve. È un lavoro meno visibile della scelta del modello più performante, ma è quello che la normativa attribuisce alla responsabilità del deployer.
Una volta accettata questa cornice, l’AI Compliance smette di essere un bersaglio mobile legato agli aggiornamenti dei provider e diventa una proprietà del proprio sistema: qualcosa che si può progettare, misurare e dimostrare.
Per sapere come l’AI Gateway di Radicalbit può supportare la tua strategia di governance, visita la pagina dedicata o prenota una demo con il nostro team.
