Come vengono costruite e verificate le regole di Scanara
Ogni regola è ancorata all'articolo, al paragrafo e al punto esatti del regolamento — e passa attraverso sei livelli di verifica prima del rilascio.
Misurato il 4 agosto 2026 — riverificato a ogni release.
Come vengono costruite le regole
La pipeline delle regole di Scanara analizza il testo completo del Regolamento (UE) 2024/1689 e ancora ogni regola al suo articolo, paragrafo e punto esatti. Un unico file di mappatura classifica ogni obbligo del regolamento in una di tre categorie: rilevabile nel codice, rilevabile in un documento di policy, oppure non rilevabile automaticamente e affidato a una valutazione guidata.
La scala dei cancelli di rilascio
Ogni rilascio del ruleset attraversa sei cancelli in serie, da controlli strutturali generali fino a un confronto esatto con un risultato noto come corretto. Un rilascio non avviene finché tutti i cancelli non vengono superati.
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
Nove controlli strutturali sul corpus delle regole: copertura degli articoli, assenza di pattern duplicati, metadati completi, valori enum validi, ID regola univoci e limiti sulle 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, su 25 applicazioni di benchmark, fissato a una versione specifica del ruleset.
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 di conformità a livello documentale di Scanara vengono eseguiti su Open Policy Agent (OPA). OPA valuta la documentazione tecnica rispetto agli obblighi del Regolamento (UE) 2024/1689. Questo segue lo stesso approccio policy-as-code usato in tutto l'ecosistema OPA: regole dichiarative, valutazione deterministica, un risultato verificabile ogni volta. Questo 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 seguente mostra il pattern. È semplificato a scopo di documentazione pubblica. Il ruleset in produzione copre decine di categorie di obblighi, oltre a rilevamento multilingue, ponderazione della gravità e controlli di coerenza tra documenti non mostrati qui.
package eu_ai_act.example.article_11
# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset covers dozens of obligation categories with
# multi-language detection, severity weighting, and cross-document
# consistency checks not shown here.
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 satisfiedInsieme, i due motori rilevano automaticamente 66 articoli del Regolamento (UE) 2024/1689: 44 rilevabili nel codice e 22 a livello documentale tramite OPA. La copertura si estende a tutte le 8 lingue UE. I riscontri di entrambi i motori confluiscono direttamente nel dossier di conformità generato. La tracciabilità delle prove risale a un risultato di scansione reale, non a un'autodichiarazione.
Valori attualmente misurati
| Metrica | Soglia | Attuale |
|---|---|---|
| Copertura degli articoli (113 articoli del regolamento) | 100% | 100% |
| Copertura con pattern reali degli articoli idonei al codice | 100% | 100% (44/44) |
| Articoli documentali/di policy con copertura OPA | 100% | 100% (22/22) |
| Obblighi rilevabili nel codice con almeno una regola | 100% | 100% (77/77) |
| Regole con metadati sul livello di rischio | 100% | 100% (522/522) |
| Regole con metadati sull'attore | 100% | 100% (522/522) |
| Regole con indicazioni di remediation strutturate | 100% | 100% (522/522) |
| 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
Queste sono metriche di copertura, completezza e determinismo — mostrano quanta parte del regolamento è mappata e quanto è coerente il comportamento della pipeline tra linguaggi e release. Non esiste un KPI di precisione, richiamo o tasso di falsi positivi, perché richiederebbe un corpus di riferimento etichettato da persone che non abbiamo. La prova strutturale contro i falsi positivi è questa: ogni fixture negativa per obbligo deve produrre zero rilievi, e un'applicazione di benchmark a rischio minimo dedicata — con ogni regola ad alto rischio, GPAI e a rischio limitato soppressa — deve anch'essa produrre zero rilievi.
Scanara rileva le lacune di conformità a livello di codice e documenti. Per interpretazioni legali complesse, consigliamo di affidarsi a consulenza legale specializzata.