Compliance as Code dla systemów AI

Jak compliance as code dotyczy art. 9–15: co może sprawdzić reguła, co zostaje po stronie człowieka oraz co obejmują, a czego nie obejmują skany Scanara oparte na regułach.

Zaktualizowano 22 października 2026

Compliance as code oznacza zapisanie części wymogów prawnych jako reguł uruchamianych razem z kodem. Dla dostawców systemów AI wysokiego ryzyka niektóre wymogi art. 9–15 można tak sprawdzić, ale większość wymaga oceny człowieka.

Obowiązki obowiązują od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I). art. 2 wymienia wyłączenia. Kary sięgają 15 mln EUR lub 3 % całkowitego światowego obrotu rocznego, zależnie od tego, która kwota jest wyższa (art. 99 ust. 4). Następny krok: wybierz jeden artykuł i wypisz, które jego wymogi może sprawdzić reguła.

Reguła może sprawdzić, czy coś istnieje; czy jest wystarczające, ocenia człowiek

Wymogi rozporządzenia mówią o tym, co jest odpowiednie do przewidzianego zastosowania. Reguły zamieniają sprawdzalną część w testy, a resztę zostawiają ludziom.

Co może sprawdzić reguła

Czy wokół wywołań modelu istnieje kod rejestrowania (art. 12).
Czy wymagane dokumenty istnieją i zawierają oczekiwane sekcje (art. 11, 13, 17 i 47).
Czy dla każdego systemu zapisano klasę ryzyka.
Kto zmienił regułę lub dokument i kiedy (historia gita).

Co wymaga człowieka

Czy analiza ryzyka jest wystarczająca, a ryzyko szczątkowe dopuszczalne (art. 9 ust. 5).
Czy system jest wysokiego ryzyka, co zależy od jego przewidzianego zastosowania (art. 6).
Czy nadzór ze strony człowieka działa w praktyce i ma obsadę (art. 14 i 26 ust. 2).
Czy dokumenty są prawdziwe i kompletne. Skan sprawdza, czy treść jest obecna.

Trzy elementy: reguły dla kodu, polityki dla dokumentów, wersjonowana dokumentacja

Reguły dla kodu

Reguły analizy statycznej (Semgrep) wykrywają w twoim kodzie źródłowym standardowe wzorce frameworków ML.

Wykrywanie wzorców: Reguły oznaczają operacje AI bez rozpoznawalnego rejestrowania, walidacji lub punktów interwencji człowieka.
Przypisanie do artykułów: Każda reguła odpowiada artykułowi rozporządzenia.
Ograniczenia: Pewność wykrywania zależy od poziomu języka programowania, a poziomy eksperymentalne mają więcej wyników fałszywie pozytywnych i fałszywie negatywnych. Własne nakładki i zaciemniony kod mogą zostać pominięte.

Polityki dla dokumentów

Polityki Open Policy Agent (OPA) sprawdzają wymaganą treść dokumentów zgodności w ośmiu językach: EN, DE, FR, IT, ES, NL, PL i PT.

Sekcje dokumentacji technicznej: Polityki sprawdzają, czy dokumentacja techniczna zawiera osiem sekcji wymaganych przez reguły Scanara, oparte na załączniku IV. Sprawdzają obecność treści, a nie jej jakość.
Dokumenty GPAI: Skan dokumentów obejmuje dokumentację dostawców modeli AI ogólnego przeznaczenia (art. 53). Generowanie dossier przygotowuje projekty dokumentów z załączników XI i XII.

Wersjonowana dokumentacja

Dokumentacja w repozytorium jest wersjonowana razem z kodem.

Dokumentacja jako kod: Oceny ryzyka i opisy systemu mają postać ustrukturyzowanych plików. Historia gita pokazuje, kto co i kiedy zmienił. Art. 11 wymaga aktualizowania dokumentacji technicznej.
Wygenerowane projekty: Scanara przygotowuje dokumenty zgodne z załącznikiem IV na podstawie twoich danych i odpowiedzi z oceny. Autouzupełnianie jest częściowe, a błędne dane dają dobrze sformatowane, ale błędne dokumenty.

Od artykułu do kontroli: co obejmuje reguła, a co zostaje po twojej stronie

Pięć artykułów pokazuje, jak wymóg dzieli się na kontrolę opartą na regułach i zadanie człowieka. Pokrycie różni się zależnie od artykułu: niektóre mają reguły dla kodu, inne skany dokumentów, inne ocenę z przewodnikiem.

Art. 9: zarządzanie ryzykiem

Wymóg: Ustanowić, wdrożyć, udokumentować i utrzymywać system zarządzania ryzykiem przez cały cykl życia (art. 9 ust. 1 i 2).
Kontrola w Scanara: Reguła dla kodu: oznacza punkty decyzyjne AI bez rozpoznawalnego kodu oceny ryzyka lub walidacji. Ocena z przewodnikiem zapisuje twoją analizę ryzyka jako dowód.
Zostaje po twojej stronie: Zidentyfikować i ocenić ryzyka oraz zdecydować, że ryzyko szczątkowe jest dopuszczalne (art. 9 ust. 5).

Art. 11: dokumentacja techniczna

Wymóg: Sporządzić dokumentację techniczną przed wprowadzeniem do obrotu lub oddaniem do użytku i aktualizować ją, z co najmniej elementami z załącznika IV.
Kontrola w Scanara: Skan dokumentów: sprawdza, czy są obecne osiem wymaganych sekcji, które reguły Scanara określają dla dokumentacji technicznej, na podstawie załącznika IV. Generowanie dossier przygotowuje dokumentację z załącznika IV z twoich danych.
Zostaje po twojej stronie: Napisać rzetelną treść i utrzymywać ją w aktualności. Skan sprawdza obecność, a nie prawdziwość.

Art. 12: rejestrowanie zdarzeń

Wymóg: Umożliwić automatyczne rejestrowanie zdarzeń przez cały cykl życia systemu.
Kontrola w Scanara: Reguła dla kodu: oznacza operacje AI bez rozpoznawalnego rejestrowania.
Zostaje po twojej stronie: Wybrać zdarzenia do rejestrowania dla trzech celów z art. 12 ust. 2 i przechowywać rejestry.

Art. 13: przejrzystość

Wymóg: Zaprojektować system tak, aby podmioty wdrażające mogły interpretować jego wyniki i właściwie je wykorzystywać, oraz dostarczyć instrukcję obsługi.
Kontrola w Scanara: Skan dokumentów: sprawdza, czy instrukcje obsługi istnieją i zawierają wymagane sekcje.
Zostaje po twojej stronie: Uczynić instrukcje rzetelnymi i zrozumiałymi dla podmiotów wdrażających.

Art. 14: nadzór ze strony człowieka

Wymóg: Zaprojektować system tak, aby osoby fizyczne mogły skutecznie go nadzorować. W stosownym i proporcjonalnym zakresie muszą móc interweniować w jego działanie lub je przerwać, na przykład za pomocą przycisku „stop” lub podobnej procedury (art. 14 ust. 1 i 4 lit. e).
Kontrola w Scanara: Reguła dla kodu: oznacza ścieżki decyzyjne bez rozpoznawalnego punktu interwencji człowieka.
Zostaje po twojej stronie: Zaprojektować nadzór, który działa w praktyce, i wyznaczyć przeszkolone osoby (art. 26 ust. 2).

Czego Scanara nie robi

Scanara nie obserwuje działających systemów, nie ocenia przewidzianego zastosowania ani kontekstu biznesowego, nie udziela porad prawnych i nie zastępuje oceny zgodności przez jednostkę notyfikowaną tam, gdzie jest wymagana. Ten sam kod może mieć minimalne albo wysokie ryzyko, zależnie od przewidzianego zastosowania. Pomyślny skan nie dowodzi zgodności.

Start w pięciu krokach

1
Sklasyfikuj swój system AI
Zdecyduj, czy system jest wysokiego ryzyka (art. 6, załącznik III). Wynik zależy od przewidzianego zastosowania i jest twoją decyzją.
2
Uruchom pierwszy skan
Przeskanuj kod i dokumenty, aby uzyskać punkt wyjścia ustaleń. Czytaj je jako wskazówki, nie jako wyrok.
3
Dodaj skan do potoku
Zacznij w trybie tylko raportowania, potem rozważ tryb blokujący. Przewodnik o CI/CD opisuje etapy.
4
Opracuj ustalenia według priorytetu
Najpierw niech człowiek oceni ustalenia wskazujące na art. 5 lub art. 14.
5
Przygotuj dokumentację
Wygeneruj projekty dokumentów z załączników IV i V na podstawie swoich danych, a potem uzupełnij je i zweryfikuj.

Wyłączenia, starsze systemy i górne granice kar

Rozporządzenia nie stosuje się do systemów AI wykorzystywanych wyłącznie do celów wojskowych, obronnych lub bezpieczeństwa narodowego (art. 2 ust. 3). Nie stosuje się go do systemów AI opracowanych i oddanych do użytku specjalnie i wyłącznie do celów badań naukowych i prac rozwojowych (art. 2 ust. 6) ani do badań, testów i prac rozwojowych przed wprowadzeniem do obrotu lub oddaniem do użytku, z wyjątkiem testów w warunkach rzeczywistych (art. 2 ust. 8). Systemy na wolnych licencjach open source są wyłączone, chyba że wprowadza się je do obrotu lub oddaje do użytku jako systemy wysokiego ryzyka albo podlegają art. 5 lub 50 (art. 2 ust. 12). Osoby fizyczne używające systemu w ramach czysto osobistej działalności pozazawodowej nie są związane obowiązkami podmiotu wdrażającego (art. 2 ust. 10). Do systemów wysokiego ryzyka związanych z produktami objętymi przepisami z załącznika I sekcja B, takimi jak pojazdy silnikowe, lotnictwo, kolej, wyposażenie morskie, pojazdy rolnicze i maszyny, stosuje się tylko art. 6 ust. 1, art. 60a i art. 102–112. Art. 57–59 stosuje się tylko w takim zakresie, w jakim te przepisy włączają wymogi (art. 2 ust. 2).

Systemy wysokiego ryzyka wprowadzone do obrotu lub oddane do użytku przed datą stosowania podlegają rozporządzeniu dopiero po istotnych zmianach projektu. W każdym razie dostawcy i podmioty wdrażające systemy AI wysokiego ryzyka przeznaczone do wykorzystywania przez organy publiczne muszą podjąć niezbędne kroki, aby spełnić wymogi do 2 sierpnia 2030 (art. 111 ust. 2).

W przypadku MŚP każda kara sięga co najwyżej niższego procentu lub niższej kwoty (art. 99 ust. 6). Dla małych przedsiębiorstw o średniej kapitalizacji (art. 3 pkt 14b) ta sama granica dotyczy kar z art. 99 ust. 4 i 5 (art. 99 ust. 6a). Poziom 15 mln EUR obejmuje też obowiązki dostawców i operatorów z art. 25 ust. 2 i 4 (art. 99 ust. 4 lit. da).

Czytaj dalej: etapy potoku, ścieżki audytu i dokumentacja techniczna

Scanara przygotowuje dowody na podstawie Państwa repozytoriów

Scanara odczytuje połączone repozytoria GitHub i uruchamia skany oparte na regułach pod kątem typowych wzorców AI i uczenia maszynowego. Może pominąć kod niestandardowy. Osobno generuje projekty dokumentacji na podstawie szablonów i Państwa odpowiedzi w ocenach, jako dowody dla Państwa pracy nad zgodnością. Klasyfikację ustalają Państwo.

Jak Scanara skanuje Państwa repozytoria