Skip to main content

Wymagania rozporządzenia AI dotyczące śladu audytu

Czego art. 12, 19 i 26 ust. 6 wymagają w zakresie rejestrowania, co rozporządzenie pozostawia otwarte i jakie praktyki inżynierskie chronią rejestry jako dowód.

Dostawcy systemów AI wysokiego ryzyka muszą projektować je tak, aby automatycznie rejestrowały zdarzenia (rejestry zdarzeń) przez cały cykl życia (art. 12). Dostawcy i podmioty wdrażające (używający systemu) przechowują rejestry pod swoją kontrolą co najmniej sześć miesięcy. Inne przepisy mogą stanowić inaczej (art. 19 i 26 ust. 6).

Obowiązuje od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I). Art. 2 wymienia wyłączenia. Starsze systemy podlegają rozporządzeniu dopiero po istotnych zmianach projektu (art. 111 ust. 2). 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: wypisz zdarzenia do rejestrowania.

Rozporządzenie wymaga możliwości rejestrowania, przechowywania i dostępu, a nie formatu rejestru

  • Art. 12 ust. 1: system musi umożliwiać automatyczne rejestrowanie zdarzeń

    System AI wysokiego ryzyka musi technicznie umożliwiać automatyczne rejestrowanie zdarzeń (rejestry zdarzeń) przez cały cykl życia.

  • Art. 12 ust. 2: rejestry służą trzem celom

    Rejestrowanie musi umożliwiać zapis zdarzeń istotnych dla identyfikacji sytuacji ryzyka (art. 79 ust. 1) lub istotnych zmian, dla monitorowania po wprowadzeniu do obrotu (art. 72) oraz dla monitorowania działania przez podmioty wdrażające (art. 26 ust. 5). Rozporządzenie nie wymienia rodzajów zdarzeń.

  • Art. 12 ust. 3: dla zdalnej identyfikacji biometrycznej obowiązuje minimum

    Systemy zdalnej identyfikacji biometrycznej (załącznik III pkt 1 lit. a) muszą rejestrować co najmniej okres każdego wykorzystania, sprawdzoną referencyjną bazę danych, dane wejściowe, które doprowadziły do trafienia, oraz osoby, które zweryfikowały wynik.

  • Art. 19 ust. 1: dostawcy przechowują rejestry co najmniej sześć miesięcy

    Dostawcy przechowują automatycznie generowane rejestry zdarzeń w zakresie, w jakim znajdują się pod ich kontrolą. Okres jest odpowiedni do przewidzianego zastosowania i wynosi co najmniej sześć miesięcy, chyba że prawo Unii, w szczególności o ochronie danych osobowych, lub prawo krajowe stanowi inaczej. Dostawcy będący instytucjami finansowymi przechowują rejestry jako część dokumentacji prowadzonej na podstawie prawa o usługach finansowych (art. 19 ust. 2).

  • Art. 26 ust. 6: podmioty wdrażające przechowują rejestry co najmniej sześć miesięcy

    Podmiot wdrażający to osoba fizyczna lub prawna, organ publiczny, agencja lub inny podmiot, który używa systemu pod własnym nadzorem (art. 3 pkt 4). Podmioty wdrażające przechowują rejestry generowane przez system w zakresie, w jakim znajdują się pod ich kontrolą, przez okres odpowiedni do przewidzianego zastosowania i wynoszący co najmniej sześć miesięcy, chyba że prawo Unii lub prawo krajowe stanowi inaczej. Podmioty wdrażające będące instytucjami finansowymi przechowują rejestry jako część dokumentacji prowadzonej na podstawie prawa Unii o usługach finansowych i wewnętrznym zarządzaniu.

  • Art. 21 ust. 2: organy mogą żądać dostępu do rejestrów

    Na uzasadniony wniosek właściwego organu dostawcy udostępniają automatycznie generowane rejestry zdarzeń w zakresie, w jakim znajdują się pod ich kontrolą.

  • Nie ma w rozporządzeniu: formatu rejestru, niezmienności, łańcuchów skrótów, regionu przechowywania

    Art. 12, 19 i 26 ust. 6 nie wskazują formatu rejestru, pamięci jednokrotnego zapisu, łańcucha skrótów ani regionu przechowywania. Słowa „niezmienny”, „manipulacja” i „hash” nie występują w ujednoliconym rozporządzeniu z 27 lipca 2026 r. Takie środki chronią rejestry jako dowód; to twoja własna decyzja projektowa.

Praktyki inżynierskie chroniące rejestry jako dowód (nasze zalecenia)

Rozporządzenie mówi o rejestrach zdarzeń, nie o ścieżkach audytu. Ścieżka audytu oznacza tu rejestry przechowywane jako dowód. Te praktyki służą celom art. 12 i 19; rozporządzenie ich nie wymaga.

  • Ustrukturyzowane zdarzenia

    Zapisuj każde zdarzenie jako JSON z zawsze tymi samymi polami, aby można je było odpytywać. Poniższy przykład to jeden możliwy schemat.

Przykładowe zdarzenie (schemat poglądowy, nienarzucony przez rozporządzenie)

{
  "event_type": "AI_DECISION",
  "timestamp": "2026-10-22T14:22:33.456Z",
  "trace_id": "abc-123-def-456",
  "system_id": "credit-scoring-v2",
  "actor_id": "user-789",
  "metadata": {
    "model_version": "v2.3.1",
    "input_hash": "sha256:a1b2c3...",
    "decision": "refer_to_human"
  }
}

  • Tylko dopisywanie, osobne przechowywanie

    Przechowuj rejestry tam, gdzie nikt nie może ich później zmienić, na przykład w pamięci obiektowej jednokrotnego zapisu poza bazą danych aplikacji. Rejestry w bazie danych aplikacji mogą zmienić lub usunąć jej administratorzy.

  • Kontrole integralności

    Łącz wpisy skrótami lub blokuj zapisane obiekty i sprawdzaj je regularnie. Wtedy możesz wykazać, że zapisane rejestry nie zostały zmienione.

  • Identyfikatory śladu

    Przekazuj jeden identyfikator śladu przez każdą usługę i umieszczaj go w każdym wpisie. Wtedy możesz śledzić pojedyncze żądanie w całym potoku AI.

  • Identyfikatory pseudonimizowane

    Rejestruj nieprzejrzyste identyfikatory i metadane zdarzeń, a nie imiona, nazwiska czy adresy e-mail, jeśli pozwala na to cel. Jakie dane osobowe może zawierać rejestr, to pytanie o RODO do twojego inspektora ochrony danych lub radcy prawnego.

  • Zapis bez blokowania

    Wysyłaj zdarzenia do kolejki i ponawiaj przy błędzie, aby nieudany zapis rejestru nie zatrzymał aplikacji.

  • Odpytywanie i eksport

    Umożliw filtrowanie rejestrów według czasu, rodzaju zdarzenia i systemu. Wtedy możesz odpowiedzieć na uzasadniony wniosek organu na podstawie art. 21 ust. 2 i prowadzić własny monitoring.

Co sprawdza Scanara, a czego nie

Reguły kodu Scanara wskazują operacje AI bez rozpoznawalnych wzorców rejestrowania. Kontrole to oparta na regułach analiza statyczna, która wykrywa standardowe wzorce frameworków ML; pewność zależy od poziomu języka programowania. Scanara prowadzi też dziennik działań na platformie z jednokrotnym zapisem, a skany można powtarzać na żądanie.

Scanara nie obserwuje działającego systemu, nie sprawdza treści ani kompletności jego rejestrów i nie dowodzi spełnienia art. 12. Pomyślny skan nie dowodzi zgodności, a decyzja należy do ciebie.

Lista kontrolna ścieżki audytu: najpierw wymagania rozporządzenia, potem dobre praktyki

  • Wymóg (art. 12 ust. 1): system technicznie umożliwia automatyczne rejestrowanie zdarzeń przez cały cykl życia.
  • Wymóg (art. 12 ust. 2): rejestrowanie obejmuje zdarzenia istotne dla sytuacji ryzyka i istotnych zmian, monitorowania po wprowadzeniu do obrotu oraz monitorowania przez podmiot wdrażający.
  • Wymóg (art. 12 ust. 3): systemy zdalnej identyfikacji biometrycznej rejestrują minimalny zakres danych.
  • Wymóg (art. 19 ust. 1 i art. 26 ust. 6): rejestry pod twoją kontrolą są przechowywane co najmniej sześć miesięcy, chyba że inne przepisy stanowią inaczej.
  • Wymóg (art. 21 ust. 2): możesz udostępnić organowi rejestry na uzasadniony wniosek.
  • Dobra praktyka: zdarzenia mają stały schemat JSON ze znacznikiem czasu, rodzajem zdarzenia, identyfikatorem systemu i identyfikatorem śladu.
  • Dobra praktyka: magazyn rejestrów jest tylko do dopisywania i oddzielony od bazy danych aplikacji.
  • Dobra praktyka: zapisy rejestrów nie blokują aplikacji.
  • Dobra praktyka: rejestry zawierają identyfikatory pseudonimizowane, a nie surowe dane osobowe, jeśli pozwala na to cel.
  • Dobra praktyka: integralność zapisanych rejestrów jest regularnie sprawdzana.

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: kontrole w potoku, skanowanie oparte na regułach i art. 12

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.