Jak powstają i są weryfikowane reguły Scanary
Każda reguła jest zakotwiczona w dokładnym artykule, ustępie i punkcie rozporządzenia — i przechodzi przez sześć warstw weryfikacji, zanim trafi do produkcji.
Zmierzono 4 sierpnia 2026 — ponownie weryfikowane przed każdym wydaniem.
Jak powstają reguły
Potok reguł Scanary analizuje pełny tekst rozporządzenia (UE) 2024/1689 i zakotwicza każdą regułę w jej dokładnym artykule, ustępie i punkcie. Jeden plik mapowania klasyfikuje każdy obowiązek z rozporządzenia jako jedną z trzech rzeczy: wykrywalny w kodzie, wykrywalny w dokumencie polityki, lub niewykrywalny automatycznie i pozostawiony do prowadzonej oceny.
Drabina bramek wydania
Każde wydanie zestawu reguł przechodzi przez sześć bramek po kolei — od szerokich kontroli strukturalnych po dokładne porównanie ze znanym poprawnym wynikiem. Wydanie nie trafia do produkcji, dopóki nie przejdzie każdej bramki.
L2.5
Spójność katalogu
Sprawdza, czy katalog artykułów, mapowanie obowiązków i wszelkie reguły tłumienia nakładania się pozostają ze sobą zsynchronizowane.
L1/L2
Struktura korpusu
Dziewięć kontroli strukturalnych korpusu reguł: pokrycie artykułów, brak zduplikowanych wzorców, kompletne metadane, prawidłowe wartości enum, unikalne identyfikatory reguł oraz limity reguł typu stub.
L3
Fixtures dla poszczególnych obowiązków
Dla każdego wykrywalnego w kodzie obowiązku fixture pozytywny musi wywołać co najmniej jedno ustalenie, a fixture negatywny — zero, w każdym wspieranym języku.
L4
Progi KPI
17 progów pokrycia, kompletności i determinizmu — patrz tabela poniżej.
L5
Migawki wzorcowe
Dokładne porównanie każdego ustalenia z zatwierdzonym oczekiwanym wynikiem, na 25 aplikacjach benchmarkowych, przypięte do konkretnej wersji zestawu reguł.
R1
Bramka remediacji
Potwierdza, że nieobrobiony fixture wywołuje niespełnione ustalenie, a ten sam fixture z zastosowaną zalecaną remediacją jest rozpoznawany jako spełniony.
Jak Scanara ocenia dokumentację za pomocą OPA i Rego
Kontrole zgodności Scanary na poziomie dokumentów działają na Open Policy Agent (OPA). OPA ocenia dokumentację techniczną pod kątem obowiązków wynikających z rozporządzenia (UE) 2024/1689. To podejście jest zgodne z policy-as-code stosowanym w całym ekosystemie OPA: reguły deklaratywne, ocena deterministyczna, wynik możliwy do zweryfikowania za każdym razem. Odbywa się to równolegle ze skanowaniem kodu źródłowego Scanary. Skanowanie kodu sprawdza, co robi kod. OPA sprawdza, co mówi dokumentacja.
Każdy plik dokumentacji przechodzi te same etapy. Najpierw Scanara go parsuje i wykrywa jego język (obsługiwanych jest 8 języków UE). Następnie normalizuje plik do ustrukturyzowanego dokumentu wejściowego: sekcje, nagłówki, wyodrębniony tekst. OPA ocenia ten ustrukturyzowany dokument względem skompilowanego pakietu polityk Rego.
Scanara generuje te reguły na podstawie kanonicznego mapowania między tekstem artykułów rozporządzenia (UE) 2024/1689 a wymaganiami możliwymi do zweryfikowania maszynowo. Żadna reguła nie jest pisana ręcznie dla pojedynczego repozytorium. Każda reguła daje się prześledzić do konkretnego artykułu, ustępu i punktu. Ocena generuje jeden wynik dla każdego obowiązku: spełniony, brakujący lub częściowy. Te wyniki trafiają do raportu zgodności razem z wynikami dotyczącymi kodu źródłowego.
Poniższy przykład pokazuje ten wzorzec. Jest uproszczony na potrzeby publicznej dokumentacji. Produkcyjny zestaw reguł obejmuje dziesiątki kategorii obowiązków, a także wykrywanie wielojęzyczne, ważenie istotności i kontrole spójności między dokumentami, których tu nie pokazano.
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 satisfiedRazem oba silniki automatycznie wykrywają 66 artykułów rozporządzenia (UE) 2024/1689: 44 wykrywalne w kodzie i 22 na poziomie dokumentów za pomocą OPA. Pokrycie obejmuje wszystkie 8 języków UE. Wyniki z obu silników trafiają bezpośrednio do wygenerowanego dossier zgodności. Ścieżka dowodowa prowadzi do rzeczywistego wyniku skanowania, a nie do samodzielnie zadeklarowanej listy kontrolnej.
Aktualnie zmierzone wartości
| Metryka | Próg | Aktualnie |
|---|---|---|
| Pokrycie artykułów (113 artykułów rozporządzenia) | 100% | 100% |
| Pokrycie rzeczywistymi wzorcami artykułów kwalifikujących się do kodu | 100% | 100% (44/44) |
| Artykuły dokumentowe/polityczne z pokryciem OPA | 100% | 100% (22/22) |
| Obowiązki wykrywalne w kodzie z co najmniej jedną regułą | 100% | 100% (77/77) |
| Reguły z metadanymi poziomu ryzyka | 100% | 100% (522/522) |
| Reguły z metadanymi aktora | 100% | 100% (522/522) |
| Reguły ze strukturalnymi wskazówkami remediacji | 100% | 100% (522/522) |
| Rozrzut liczby reguł między 12 wspieranymi językami | ≤ 1 | 0 |
| Zduplikowane identyfikatory reguł | 0 | 0 |
| Reguły typu stub (bez wzorca kodu) na artykuł | ≤ 1 | 0 |
| Zaliczone progi KPI L4 | 17/17 | 17/17 |
Czego te liczby nie mierzą
Są to metryki pokrycia, kompletności i determinizmu — pokazują, jaka część rozporządzenia jest odwzorowana i jak spójnie zachowuje się potok między językami i wydaniami. Nie istnieje KPI precyzji, czułości ani odsetka fałszywych trafień, ponieważ wymagałoby to oznaczonego przez ludzi korpusu odniesienia, którego nie posiadamy. Strukturalny dowód przeciwko fałszywym trafieniom jest następujący: każdy negatywny fixture dla danego obowiązku musi dawać zero ustaleń, a dedykowana aplikacja o minimalnym ryzyku — w której każda reguła wysokiego ryzyka, GPAI i ograniczonego ryzyka jest wyciszona — również musi dawać zero ustaleń.
Scanara wykrywa luki w zgodności na poziomie kodu i dokumentów. W przypadku złożonych interpretacji prawnych zalecamy współpracę z wyspecjalizowanym doradcą prawnym.