Compliance as Code per i sistemi IA

Come si applica la compliance as code agli articoli da 9 a 15: che cosa può verificare una regola, che cosa resta a una persona e che cosa coprono e non coprono le scansioni basate su regole di Scanara.

Aggiornato 22 ottobre 2026

Compliance as code significa scrivere parti dei requisiti legali come regole che girano insieme al codice. Per i fornitori di sistemi di IA ad alto rischio, alcuni requisiti degli articoli 9-15 si possono verificare così. La maggior parte richiede un giudizio umano.

Gli obblighi si applicano dal 2 dicembre 2027 (allegato III) e dal 2 agosto 2028 (allegato I). L’articolo 2 elenca esclusioni. Le sanzioni arrivano a 15 milioni di EUR o al 3 % del fatturato mondiale annuo, se superiore (articolo 99(4)). Prossimo passo: scegliere un articolo ed elencare quali suoi requisiti una regola può verificare.

Una regola può verificare se qualcosa esiste; una persona deve giudicare se è adeguato

I requisiti del regolamento parlano di ciò che è adeguato alla finalità prevista. Le regole trasformano la parte verificabile in test e lasciano il resto alle persone.

Che cosa può verificare una regola

Se esiste codice di registrazione attorno alle chiamate al modello (articolo 12).
Se i documenti richiesti esistono e contengono le sezioni attese (articoli 11, 13, 17 e 47).
Se per ogni sistema è registrata una classe di rischio.
Chi ha modificato una regola o un documento, e quando (cronologia git).

Che cosa richiede una persona

Se l’analisi dei rischi è adeguata e il rischio residuo accettabile (articolo 9(5)).
Se il sistema è ad alto rischio, il che dipende dalla finalità prevista (articolo 6).
Se la sorveglianza umana funziona nella pratica ed è dotata di personale (articoli 14 e 26(2)).
Se i documenti sono veri e completi. Una scansione verifica che il contenuto sia presente.

Tre componenti: regole sul codice, policy sui documenti, documentazione versionata

Regole sul codice

Regole di analisi statica (Semgrep) rilevano schemi standard dei framework di ML nel suo codice sorgente.

Rilevamento di schemi: Le regole segnalano operazioni di IA senza registrazione, convalida o punti di intervento umano riconoscibili.
Collegamento agli articoli: Ogni regola corrisponde a un articolo del regolamento.
Limiti: L’affidabilità del rilevamento varia con il livello del linguaggio di programmazione, e i livelli sperimentali hanno più falsi positivi e falsi negativi. Wrapper personalizzati e codice offuscato possono sfuggire.

Policy sui documenti

Le policy di Open Policy Agent (OPA) verificano il contenuto richiesto nei documenti di conformità in otto lingue: EN, DE, FR, IT, ES, NL, PL e PT.

Sezioni della documentazione tecnica: Le policy verificano che la documentazione tecnica contenga le otto sezioni richieste dalle regole di Scanara, basate sull’allegato IV. Verificano che il contenuto sia presente, non che sia buono.
Documenti GPAI: Una scansione dei documenti copre la documentazione dei fornitori di modelli di IA per finalità generali (articolo 53). La generazione dei dossier redige bozze dei documenti degli allegati XI e XII.

Documentazione versionata

La documentazione nel suo repository è versionata insieme al codice.

Documentazione come codice: Valutazioni dei rischi e descrizioni del sistema sono file strutturati. La cronologia git mostra chi ha cambiato che cosa e quando. L’articolo 11 richiede di tenere aggiornata la documentazione tecnica.
Bozze generate: Scanara redige documenti allineati all’allegato IV a partire dai suoi dati e dalle risposte di valutazione. Il precompilato è parziale, e dati errati producono documenti ben formattati ma sbagliati.

Dall’articolo al controllo: che cosa copre una regola e che cosa resta a lei

Cinque articoli mostrano come un requisito si divide in un controllo basato su regole e un compito umano. La copertura varia per articolo: alcuni hanno regole sul codice, altri scansioni dei documenti, altri una valutazione guidata.

Articolo 9: gestione del rischio

Requisito: Stabilire, attuare, documentare e mantenere un sistema di gestione del rischio durante il ciclo di vita (articolo 9(1) e (2)).
Controllo in Scanara: Regola sul codice: segnala punti decisionali di IA senza codice riconoscibile di valutazione del rischio o di convalida. Una valutazione guidata registra la sua analisi dei rischi come prova.
Resta a lei: Individuare e valutare i rischi e decidere che il rischio residuo è accettabile (articolo 9(5)).

Articolo 11: documentazione tecnica

Requisito: Redigere la documentazione tecnica prima dell’immissione sul mercato o della messa in servizio e tenerla aggiornata, con almeno gli elementi dell’allegato IV.
Controllo in Scanara: Scansione dei documenti: verifica che siano presenti le otto sezioni obbligatorie che le regole di Scanara definiscono per la documentazione tecnica, basate sull’allegato IV. La generazione dei dossier redige la documentazione dell’allegato IV dai suoi dati.
Resta a lei: Scrivere contenuti accurati e tenerli aggiornati. Una scansione verifica la presenza, non la veridicità.

Articolo 12: registrazione

Requisito: Consentire la registrazione automatica degli eventi (log) per tutto il ciclo di vita del sistema.
Controllo in Scanara: Regola sul codice: segnala operazioni di IA senza registrazione riconoscibile.
Resta a lei: Scegliere gli eventi da registrare per i tre scopi dell’articolo 12(2) e conservare i log.

Articolo 13: trasparenza

Requisito: Progettare il sistema in modo che i deployer possano interpretarne l’output e usarlo in modo adeguato, e fornire istruzioni per l’uso.
Controllo in Scanara: Scansione dei documenti: verifica che le istruzioni per l’uso esistano e contengano le sezioni richieste.
Resta a lei: Rendere le istruzioni accurate e comprensibili per i deployer.

Articolo 14: sorveglianza umana

Requisito: Progettare il sistema in modo che persone fisiche possano sorvegliarlo efficacemente. In modo adeguato e proporzionato, devono poter intervenire sul sistema o interromperlo, per esempio con un pulsante di arresto o una procedura analoga (articolo 14(1) e (4), lettera e)).
Controllo in Scanara: Regola sul codice: segnala percorsi decisionali senza un punto di intervento umano riconoscibile.
Resta a lei: Progettare una sorveglianza che funzioni nella pratica e assegnare persone formate (articolo 26(2)).

Che cosa Scanara non fa

Scanara non osserva i sistemi in esercizio, non giudica la finalità prevista né il contesto aziendale, non dà consulenza legale e non sostituisce una valutazione della conformità da parte di un organismo notificato, dove è richiesta. Lo stesso codice può essere a rischio minimo o alto, secondo la finalità prevista. Una scansione superata non dimostra la conformità.

Per iniziare in cinque passi

1
Classifichi il suo sistema di IA
Decida se il sistema è ad alto rischio (articolo 6, allegato III). Il risultato dipende dalla finalità prevista ed è una sua decisione.
2
Esegua una prima scansione
Scansioni codice e documenti per ottenere una base di riscontri. Li legga come indicazioni, non come verdetto.
3
Inserisca la scansione nella pipeline
Inizi in modalità solo rapporto, poi valuti la modalità bloccante. La guida CI/CD descrive le fasi.
4
Affronti i riscontri per priorità
Faccia esaminare prima da una persona i riscontri che indicano l’articolo 5 o l’articolo 14.
5
Rediga la documentazione
Generi bozze dei documenti degli allegati IV e V a partire dai suoi dati, poi le completi e le verifichi.

Esclusioni, sistemi più vecchi e massimali delle sanzioni

Il regolamento non si applica ai sistemi di IA usati esclusivamente per scopi militari, di difesa o di sicurezza nazionale (articolo 2(3)). Non si applica ai sistemi di IA sviluppati e messi in servizio specificamente e al solo scopo di ricerca e sviluppo scientifici (articolo 2(6)), né alla ricerca, alle prove o allo sviluppo prima dell’immissione sul mercato o della messa in servizio, salvo le prove in condizioni reali (articolo 2(8)). I sistemi con licenze libere e open source sono esclusi, salvo che siano immessi sul mercato o messi in servizio come sistemi ad alto rischio o rientrino nell’articolo 5 o 50 (articolo 2(12)). Le persone fisiche che usano un sistema in un’attività puramente personale e non professionale non sono vincolate come deployer (articolo 2(10)). Per i sistemi ad alto rischio legati a prodotti disciplinati dalla normativa dell’allegato I, sezione B, come veicoli a motore, aviazione, ferrovie, attrezzature marittime, veicoli agricoli e macchinari, si applicano solo l’articolo 6(1), l’articolo 60a e gli articoli da 102 a 112. Gli articoli da 57 a 59 si applicano solo nella misura in cui tale normativa integra i requisiti (articolo 2(2)).

I sistemi ad alto rischio immessi sul mercato o messi in servizio prima della data di applicazione sono coperti solo dopo modifiche significative della progettazione. In ogni caso, i fornitori e i deployer di sistemi di IA ad alto rischio destinati a essere utilizzati da autorità pubbliche devono adottare le misure necessarie per conformarsi entro il 2 agosto 2030 (articolo 111(2)).

Per le PMI, ogni sanzione arriva al massimo alla percentuale o all’importo più bassi (articolo 99(6)). Per le piccole imprese a media capitalizzazione (articolo 3, punto 14b) lo stesso massimale vale per le sanzioni dell’articolo 99, paragrafi 4 e 5 (articolo 99(6a)). Il livello da 15 milioni di EUR copre anche gli obblighi di fornitori e operatori dell’articolo 25, paragrafi 2 e 4 (articolo 99(4), lettera da)).

Da leggere dopo: fasi della pipeline, audit trail e documentazione tecnica

Scanara prepara evidenze dai vostri repository

Scanara legge i vostri repository GitHub collegati ed esegue scansioni basate su regole per individuare pattern comuni di IA e machine learning. Può non rilevare il codice non standard. Separatamente genera bozze di documentazione a partire da modelli e dalle vostre risposte alle valutazioni, come evidenze per il vostro lavoro di conformità. La classificazione la decidete voi.

Scoprite come Scanara analizza i vostri repository