Come vengono costruite e verificate le regole di Scanara
Questa pagina è per ingegneri e responsabili della conformità che vogliono valutare l'affidabilità delle regole di Scanara. Ogni regola rimanda a un articolo, paragrafo e punto del Regolamento sull'IA, e un rilascio del set di regole deve superare sei controlli. L'ultima sezione indica ciò che i numeri non misurano.
Misurato il 9 settembre 2026.
Come vengono costruite le regole
La pipeline delle regole di Scanara analizza il testo del Regolamento (UE) 2024/1689 come modificato e ancora ogni regola al suo articolo, paragrafo e punto esatti. Un unico file di mappatura assegna a ogni obbligo uno di tre esiti: rilevabile nel codice, verificabile in un documento di policy, oppure non rilevabile automaticamente e affidato a una valutazione guidata.
La scala dei cancelli di rilascio
Il set di regole attraversa sei controlli in serie, dai controlli strutturali generali fino a un confronto esatto con un output di riferimento. Tutti e sei vengono eseguiti nella pipeline CI di Scanara.
L2.5
Coerenza del catalogo
Verifica che il catalogo degli articoli, la mappatura degli obblighi ed eventuali regole di soppressione delle sovrapposizioni rimangano sincronizzati tra loro.
L1/L2
Struttura del corpus
Controlli strutturali sul corpus di regole: copertura degli articoli, nessun pattern duplicato, metadati completi, valori enum validi, ID di regola univoci e limiti per le regole stub.
L3
Fixture per obbligo
Per ogni obbligo rilevabile nel codice, una fixture positiva deve generare almeno un rilievo e una fixture negativa deve generarne zero — in ogni linguaggio supportato.
L4
Soglie KPI
17 soglie di copertura, completezza e determinismo — vedi la tabella sottostante.
L5
Snapshot di riferimento
Un confronto esatto di ogni rilievo con un risultato atteso registrato, per le 27 applicazioni di test che hanno uno snapshot di riferimento, vincolato a una versione precisa del set di regole.
R1
Cancello di remediation
Conferma che una fixture non corretta generi un rilievo non soddisfatto, e che la stessa fixture con la remediation consigliata applicata venga riconosciuta come soddisfatta.
Come Scanara valuta la documentazione con OPA e Rego
I controlli documentali di Scanara vengono eseguiti su Open Policy Agent (OPA). OPA valuta la documentazione tecnica rispetto agli obblighi del Regolamento (UE) 2024/1689. È un approccio policy-as-code: regole dichiarative e valutazione deterministica, così lo stesso documento dà sempre lo stesso risultato. Avviene in parallelo alla scansione del codice sorgente di Scanara. La scansione del codice controlla cosa fa il codice. OPA controlla cosa dice la documentazione.
Ogni file di documentazione segue gli stessi passaggi. Prima, Scanara lo analizza e rileva la lingua (sono supportate 8 lingue UE). Poi lo normalizza in un documento di input strutturato: sezioni, intestazioni, testo estratto. OPA valuta questo documento strutturato rispetto a un bundle di policy Rego compilato.
Scanara genera queste regole a partire da una mappatura canonica tra il testo degli articoli del Regolamento (UE) 2024/1689 e requisiti verificabili automaticamente. Nessuna regola è scritta a mano per un singolo repository. Ogni regola è riconducibile a un articolo, paragrafo e punto specifici. La valutazione produce un riscontro per ogni obbligo: soddisfatto, mancante o parziale. Questi riscontri confluiscono nel report di conformità insieme ai riscontri sul codice sorgente.
L'esempio qui sotto mostra il pattern, semplificato per la documentazione pubblica. Il set di regole di produzione è più ampio e gestisce anche più lingue dei documenti e la ponderazione per gravità.
package eu_ai_act.example.article_11
# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset is larger and also handles several document
# languages and severity weighting.
default satisfied := false
# A document satisfies this (illustrative) Article 11 check when its parsed
# sections include the required topic, with non-empty content.
satisfied if {
some section in input.document.sections
section.topic == "risk_management_process"
count(trim_space(section.content)) > 0
}
finding := {
"article": "11",
"obligation": "technical_documentation.risk_management_process",
"status": "satisfied",
} if satisfied
finding := {
"article": "11",
"obligation": "technical_documentation.risk_management_process",
"status": "missing",
"severity": "high",
} if not satisfiedNello snapshot del 24 agosto 2026, le regole automatiche coprono 66 articoli su 113 (circa il 58%). Le regole sul codice coprono 43 articoli e le regole sui documenti 23, in 8 lingue dei documenti dell'UE. Gli altri articoli sono trattati con valutazioni guidate e documentazione generata, oppure riguardano le autorità e non gli operatori. Questi numeri sono uno snapshot datato e cambiano a ogni generazione delle regole. I rilievi di entrambi i motori confluiscono nel rapporto di conformità, e ogni rilievo risale a un risultato di scansione reale, non a una checklist autodichiarata.
Valori attualmente misurati
| Metrica | Soglia | Attuale |
|---|---|---|
| Articoli considerati dalla pipeline di regole (119 nel regolamento) | 100% | 100% |
| Copertura con pattern reali degli articoli idonei al codice | 100% | 100% |
| Articoli documentali/di policy con copertura OPA | 100% | 100% |
| Obblighi rilevabili nel codice con almeno una regola | 100% | 100% |
| Regole con metadati sul livello di rischio | 100% | 100% |
| Regole con metadati sull'attore | 100% | 100% |
| Regole con indicazioni di remediation strutturate | 100% | 100% |
| Variazione del numero di regole tra i 12 linguaggi supportati | ≤ 1 | 0 |
| ID regola duplicati | 0 | 0 |
| Regole stub (senza pattern di codice) per articolo | ≤ 1 | 0 |
| Soglie KPI L4 superate | 17/17 | 17/17 |
Cosa questi numeri non misurano
I valori del 100% sulla copertura degli articoli significano che la pipeline di regole considera ogni articolo; non significano che ogni articolo sia controllato automaticamente. Queste metriche misurano copertura, completezza e determinismo: quanta parte del regolamento è mappata e con quanta coerenza la pipeline si comporta tra linguaggi e rilasci. Non esiste un indicatore di precisione, richiamo o tasso di falsi positivi, perché richiederebbe un corpus di riferimento etichettato da persone che Scanara non ha. La prova strutturale contro i falsi positivi è questa: ogni fixture negativa per obbligo deve produrre zero rilievi, e un'applicazione di test a rischio minimo, con tutte le regole per alto rischio, modelli di IA per finalità generali e rischio limitato soppresse, deve produrre anch'essa zero rilievi.
Scanara rileva le lacune nel codice e nei documenti che le sue regole coprono. Può non rilevare codice personalizzato, non standard od offuscato, e superare una scansione non significa che un'organizzazione sia conforme. La classificazione e l'interpretazione giuridica restano a te e al tuo consulente legale.