Jak powstają i są weryfikowane reguły Scanary
Ta strona jest dla inżynierów i osób odpowiedzialnych za zgodność, którzy chcą ocenić wiarygodność reguł Scanary. Każda reguła odsyła do jednego artykułu, ustępu i punktu rozporządzenia o AI, a wydanie zestawu reguł musi przejść sześć kontroli. Ostatnia sekcja podaje, czego liczby nie mierzą.
Zmierzono 9 września 2026.
Jak powstają reguły
Potok reguł Scanary analizuje tekst rozporządzenia (UE) 2024/1689 w wersji zmienionej i zakotwicza każdą regułę w jej dokładnym artykule, ustępie i punkcie. Jeden plik mapowania przypisuje każdemu obowiązkowi jeden z trzech wyników: wykrywalny w kodzie, sprawdzalny w dokumencie polityki, lub niewykrywalny automatycznie i pozostawiony do prowadzonej oceny.
Drabina bramek wydania
Zestaw reguł przechodzi sześć kontroli po kolei, od szerokich kontroli strukturalnych po dokładne porównanie ze znanym poprawnym wynikiem. Wszystkie sześć działa w potoku CI Scanary.
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
Kontrole strukturalne korpusu reguł: pokrycie artykułów, brak zduplikowanych wzorców, kompletne metadane, poprawne wartości enum, unikalne identyfikatory reguł i limity reguł 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 zapisanym oczekiwanym wynikiem, dla 27 aplikacji testowych z migawką wzorcową, 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 dokumentów w Scanara 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 policy-as-code: reguły deklaratywne i ocena deterministyczna, dzięki czemu ten sam dokument za każdym razem daje ten sam wynik. 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 wzorzec, uproszczony na potrzeby publicznej dokumentacji. Produkcyjny zestaw reguł jest większy i obsługuje też kilka języków dokumentów oraz ważenie według wagi.
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 satisfiedW migawce z 24 sierpnia 2026 r. reguły automatyczne obejmują 66 z 113 artykułów (około 58%). Reguły kodu obejmują 43 artykuły, a reguły dokumentów 23, w 8 językach dokumentów UE. Pozostałe artykuły są obsługiwane przez prowadzone oceny i wygenerowaną dokumentację albo dotyczą organów, a nie operatorów. Te liczby to migawka z określonej daty i zmieniają się przy każdym generowaniu reguł. Wyniki obu silników trafiają do raportu zgodności, a każdy wynik prowadzi do rzeczywistego wyniku skanowania, a nie do samodzielnie wypełnionej listy kontrolnej.
Aktualnie zmierzone wartości
| Metryka | Próg | Aktualnie |
|---|---|---|
| Artykuły ujęte w potoku reguł (119 w rozporządzeniu) | 100% | 100% |
| Pokrycie rzeczywistymi wzorcami artykułów kwalifikujących się do kodu | 100% | 100% |
| Artykuły dokumentowe/polityczne z pokryciem OPA | 100% | 100% |
| Obowiązki wykrywalne w kodzie z co najmniej jedną regułą | 100% | 100% |
| Reguły z metadanymi poziomu ryzyka | 100% | 100% |
| Reguły z metadanymi aktora | 100% | 100% |
| Reguły ze strukturalnymi wskazówkami remediacji | 100% | 100% |
| 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ą
Wartości 100% przy pokryciu artykułów oznaczają, że potok reguł uwzględnia każdy artykuł; nie oznaczają, że każdy artykuł jest sprawdzany automatycznie. Te wskaźniki mierzą pokrycie, kompletność i determinizm: jaka część rozporządzenia jest zmapowana i jak spójnie potok działa między językami i wydaniami. Nie ma wskaźnika precyzji, czułości ani odsetka fałszywych alarmów, bo wymagałby on korpusu referencyjnego opisanego przez ludzi, którego Scanara nie ma. Strukturalny dowód przeciw fałszywym alarmom jest taki: każdy negatywny fixture dla obowiązku musi dać zero ustaleń, a osobna aplikacja testowa o minimalnym ryzyku, z wyłączonymi regułami dla wysokiego ryzyka, modeli AI ogólnego przeznaczenia i ograniczonego ryzyka, też musi dać zero ustaleń.
Scanara wykrywa luki w kodzie i dokumentach, które obejmują jego reguły. Może pominąć kod niestandardowy, nietypowy lub zaciemniony, a pozytywny wynik skanu nie oznacza, że organizacja spełnia wymogi. Klasyfikacja i interpretacja prawna pozostają po Twojej stronie i po stronie Twojego doradcy prawnego.