Hoe Scanara's regels worden gebouwd en geverifieerd
Deze pagina is voor engineers en compliance-verantwoordelijken die willen beoordelen hoe betrouwbaar de regels van Scanara zijn. Elke regel verwijst naar één artikel, lid en punt van de AI-verordening, en een release van de regelset moet zes controles doorstaan. De laatste sectie noemt wat de cijfers niet meten.
Gemeten op 9 september 2026.
Hoe regels worden gebouwd
Scanara's regelpipeline verwerkt de tekst van Verordening (EU) 2024/1689 zoals gewijzigd en verankert elke regel in het exacte artikel, lid en punt. Eén mappingbestand wijst elke verplichting een van drie uitkomsten toe: detecteerbaar in code, controleerbaar in een beleidsdocument, of niet machinaal detecteerbaar en overgelaten aan een begeleide assessment.
De release-poortenladder
De regelset doorloopt zes controles in serie, van brede structurele controles tot een exacte vergelijking met bekende juiste uitvoer. Alle zes draaien in de CI-pipeline van Scanara.
L2.5
Catalogusconsistentie
Controleert of de artikelcatalogus, de verplichtingenmapping en eventuele overlap-onderdrukkingsregels onderling gesynchroniseerd blijven.
L1/L2
Corpusstructuur
Structurele controles op het regelcorpus: artikeldekking, geen dubbele patronen, volledige metadata, geldige enumwaarden, unieke regel-ID's en limieten voor stubregels.
L3
Fixtures per verplichting
Voor elke in code detecteerbare verplichting moet een positieve fixture minstens één bevinding opleveren en een negatieve fixture nul — in elke ondersteunde taal.
L4
KPI-drempels
17 drempels voor dekking, volledigheid en determinisme — zie de tabel hieronder.
L5
Golden snapshots
Een exacte vergelijking van elke bevinding met een vastgelegd verwacht resultaat, voor de 27 testapplicaties met een golden snapshot, vastgezet op een specifieke versie van de regelset.
R1
Remediation-poort
Bevestigt dat een onbewerkte fixture een niet-voldane bevinding oplevert, en dat dezelfde fixture met de aanbevolen remediation toegepast als voldaan wordt herkend.
Hoe Scanara documentatie beoordeelt met OPA en Rego
Scanara's controles op documenten draaien op Open Policy Agent (OPA). OPA toetst technische documentatie aan verplichtingen uit de Verordening (EU) 2024/1689. Dit is een policy-as-code-aanpak: declaratieve regels en deterministische evaluatie, zodat hetzelfde document elke keer hetzelfde resultaat geeft. Dit loopt parallel aan Scanara's broncodescan. Codescanning controleert wat de code doet. OPA controleert wat de documentatie zegt.
Elk documentatiebestand doorloopt dezelfde stappen. Eerst parst Scanara het bestand en detecteert de taal (8 EU-talen worden ondersteund). Daarna normaliseert Scanara het bestand tot een gestructureerd invoerdocument: secties, koppen, geëxtraheerde tekst. OPA toetst dit gestructureerde document aan een gecompileerde Rego-policybundel.
Scanara genereert deze regels vanuit een canonieke koppeling tussen de artikeltekst van de Verordening (EU) 2024/1689 en machinaal controleerbare vereisten. Geen enkele regel wordt per repository met de hand geschreven. Elke regel is herleidbaar tot een specifiek artikel, lid en punt. De evaluatie levert één bevinding per verplichting op: voldaan, ontbrekend of gedeeltelijk. Deze bevindingen komen samen met de broncodebevindingen in het compliance-rapport terecht.
Het voorbeeld hieronder toont het patroon, vereenvoudigd voor openbare documentatie. De productieregelset is groter en verwerkt ook meerdere documenttalen en weging naar ernst.
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 satisfiedIn de momentopname van 24 augustus 2026 dekken automatische regels 66 van de 113 artikelen (ongeveer 58%). Coderegels dekken 43 artikelen en documentregels 23, in 8 EU-documenttalen. De overige artikelen worden behandeld via begeleide assessments en gegenereerde documentatie, of richten zich op autoriteiten in plaats van op operators. Deze aantallen zijn een gedateerde momentopname en veranderen bij elke generatie van de regels. Bevindingen van beide engines gaan naar het compliancerapport, en elke bevinding is herleidbaar tot een daadwerkelijk scanresultaat, niet tot een zelf ingevulde checklist.
Huidige gemeten waarden
| Metriek | Drempel | Huidig |
|---|---|---|
| Artikelen die de regelpipeline meeneemt (119 in de verordening) | 100% | 100% |
| Echte-patroondekking van code-geschikte artikelen | 100% | 100% |
| Document-/beleidsartikelen met OPA-dekking | 100% | 100% |
| In code detecteerbare verplichtingen met minstens één regel | 100% | 100% |
| Regels met risiconiveau-metadata | 100% | 100% |
| Regels met actor-metadata | 100% | 100% |
| Regels met gestructureerde remediation-richtlijnen | 100% | 100% |
| Spreiding in regelaantal over de 12 ondersteunde talen | ≤ 1 | 0 |
| Dubbele regel-ID's | 0 | 0 |
| Stub-regels (zonder codepatroon) per artikel | ≤ 1 | 0 |
| Geslaagde L4 KPI-drempels | 17/17 | 17/17 |
Wat deze cijfers niet meten
De waarden van 100% bij artikeldekking betekenen dat de regelpipeline elk artikel meeneemt; ze betekenen niet dat elk artikel automatisch wordt gecontroleerd. Deze statistieken meten dekking, volledigheid en determinisme: hoeveel van de verordening is gemapt en hoe consistent de pipeline zich gedraagt over talen en releases heen. Er is geen KPI voor precisie, recall of percentage valse positieven, omdat daarvoor een door mensen gelabeld referentiecorpus nodig is dat Scanara niet heeft. Het structurele bewijs tegen valse positieven is dit: elke negatieve fixture per verplichting moet nul bevindingen opleveren, en een aparte testapplicatie met minimaal risico, waarbij alle regels voor hoog risico, AI-modellen voor algemene doeleinden en beperkt risico zijn onderdrukt, moet ook nul bevindingen opleveren.
Scanara detecteert de hiaten in code en documenten die zijn regels dekken. Het kan aangepaste, niet-standaard of versluierde code missen, en een geslaagde scan betekent niet dat een organisatie voldoet aan de regels. Indeling en juridische uitleg blijven bij jou en je juridisch adviseur.