Skip to main content

Zgodność z rozporządzeniem AI w pipeline CI/CD

Czego wymaga rozporządzenie i co może udokumentować potok CI/CD, trzy etapy potoku, jak działa merge gate Scanara w GitHub i gdzie kończą się skany oparte na regułach.

Rozporządzenie nie wymaga CI/CD. Dostawcy systemów AI wysokiego ryzyka muszą aktualizować dokumentację techniczną (art. 11) i testować przed wprowadzeniem do obrotu lub oddaniem do użytku (art. 9 ust. 8). Muszą też prowadzić system zarządzania jakością (art. 17). Potok (pipeline) może dostarczyć dowody tych obowiązków.

Te 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: przypisz każdy etap potoku do artykułu, który dokumentuje.

Potok może dostarczyć dowodów tych obowiązków; nie rozstrzyga o zgodności

  • Dokumentacja techniczna jest aktualna (art. 11)

    Dokumentację techniczną sporządza się przed wprowadzeniem do obrotu lub oddaniem do użytku i aktualizuje. Zawiera co najmniej elementy z załącznika IV. Krok potoku może sprawdzić, czy wymagane dokumenty istnieją i zmieniają się razem z kodem.

  • Testy odbywają się przed wprowadzeniem do obrotu lub oddaniem do użytku (art. 9 ust. 6–8)

    Testy przeprowadza się w dowolnym momencie rozwoju i w każdym razie przed wprowadzeniem do obrotu lub oddaniem do użytku, według z góry określonych metryk i progów probabilistycznych odpowiednich do przewidzianego zastosowania. Etapy testowe potoku ze stałymi progami dają wyniki opatrzone datą.

  • Zarządzanie jakością obejmuje kontrolę zmian (art. 17 ust. 1)

    System zarządzania jakością dokumentuje kontrolę projektu, kontrolę jakości rozwoju, procedury badania, testowania i walidacji oraz zarządzanie zmianami. Logi potoku i reguły przeglądu mogą zapisywać te kroki.

  • Istotne zmiany wymagają nowej oceny zgodności (art. 43 ust. 4)

    Zmiana w systemie po wprowadzeniu do obrotu, której nie przewidziano w pierwotnej ocenie zgodności i która wpływa na zgodność z wymogami sekcji 2 lub zmienia przewidziane zastosowanie, jest istotną zmianą (art. 3 pkt 23). Potok może oznaczać zmiany modelu lub przewidzianego zastosowania do przeglądu przez człowieka. Nie rozstrzyga, czy zmiana jest istotna. W systemach, które po wprowadzeniu do obrotu nadal się uczą, zmiany z góry określone przy pierwotnej ocenie i udokumentowane zgodnie z załącznikiem IV pkt 2 lit. f nie są istotnymi zmianami (art. 43 ust. 4).

Trzy etapy potoku odpowiadające tym obowiązkom (nasza propozycja)

Rozporządzenie nie wskazuje etapów potoku. Ten podział umieszcza szybkie kontrole przy każdym pull requeście, a pełny skan przed wydaniem.

Etap 1: kontrole przy pull requeście

Uruchamiają się przy każdym pull requeście i dają programistom szybką informację zwrotną.

  • Skan kodu: Oparta na regułach analiza statyczna oznacza komponenty AI i brakujące wzorce, na przykład operacje AI bez rejestrowania. Wykrywa tylko standardowe wzorce frameworków ML.
  • Kontrola dokumentów: Reguły polityk sprawdzają, czy wymagane dokumenty istnieją i zawierają wymagane sekcje. Sprawdzają obecność treści, a nie jej prawdziwość czy jakość.
  • Zapis klasy ryzyka: Sprawdź, czy klasyfikacja ryzyka systemu jest zapisana i weryfikowana przy zmianie kodu lub przewidzianego zastosowania. Sama klasyfikacja jest decyzją człowieka (art. 6).

Etap 2: merge gate

Kontrola przed scaleniem, która może zatrzymać zmiany niezgodne z wymogami.

  • Progi dla ustaleń: Ustaw progi dla ustaleń krytycznych i wysokich. W trybie blokującym skan powyżej progów powoduje niepowodzenie kontroli.
  • Ustalenia dotyczące art. 5 i art. 14: Skan kodu nie pokazuje zamiaru ani kontekstu. Człowiek ocenia każde ustalenie wskazujące na zakazaną praktykę (art. 5) lub brak nadzoru ze strony człowieka (art. 14).
  • Zmiany w dokumentacji: Sprawdź, czy dokumentacja z załącznika IV zmienia się w tym samym pull requeście co opisywany przez nią kod.

Etap 3: skan przed wydaniem

Pełny skan kandydata do wydania.

  • Pełny skan: Kompletny skan kodu i dokumentów. Skan dokumentów obsługuje osiem języków: EN, DE, FR, IT, ES, NL, PL i PT.
  • Projekt dossier: Scanara przygotowuje projekty dokumentów zgodne z załącznikami IV i V na podstawie twoich danych i odpowiedzi z oceny. Autouzupełnianie jest częściowe; resztę piszesz i weryfikujesz sam.
  • Migawka dowodowa: Przechowuj raport ze skanu razem z wpisem wydania, aby móc wykazać, co i kiedy sprawdzono.

Jak działa merge gate Scanara w GitHub

Scanara odbiera zdarzenia pull request z GitHub, skanuje zmianę i zgłasza wynik jako check run w GitHub. W trybie tylko raportowania nieudana kontrola jest zgłaszana jako neutralna. W trybie blokującym kontrola kończy się niepowodzeniem.

Merge gate działa tylko z GitHub. Skany harmonogramowe nie są jeszcze dostępne; skany uruchamia się na żądanie i przy pull requestach.

Co sprawdzają skany i gdzie się kończą

Pokrycie jest częściowe. W stanie z 24 sierpnia 2026 r. 77 ze 174 zmapowanych obowiązków ma reguły dla kodu, w 43 artykułach, a 23 ma reguły dla dokumentów, w 23 artykułach. Mapowanie powstało przed zmianami wprowadzonymi rozporządzeniem (UE) 2026/1744, na przykład art. 4a, 60a i 75a–75d. Pozostałe obowiązki wymagają ocen i pracy człowieka.

Reguły dla kodu

  • Art. 5: zakazane praktyki

    Reguły oznaczają wzorce kodu, które mogą wskazywać na zakazaną praktykę. To, czy praktyka jest zakazana, zależy od celu i kontekstu, których kod nie pokazuje.

  • Art. 9: zarządzanie ryzykiem

    Reguły oznaczają punkty decyzyjne AI bez rozpoznawalnego kodu oceny ryzyka lub walidacji.

  • Art. 10: dane i zarządzanie danymi

    Reguły oznaczają potoki treningowe bez rozpoznawalnych kontroli jakości danych.

  • Art. 12: rejestrowanie zdarzeń

    Reguły oznaczają operacje AI bez rozpoznawalnego rejestrowania.

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

    Reguły oznaczają ścieżki decyzyjne bez rozpoznawalnego punktu interwencji człowieka, takiego jak nadpisanie lub procedura zatrzymania.

  • Art. 15: dokładność i odporność

    Reguły oznaczają brak walidacji modelu i brak metryk dokładności.

Reguły dla dokumentów

  • Sekcje dokumentacji technicznej (art. 11)

    Reguły Scanara określają osiem wymaganych sekcji dokumentacji technicznej, opartych na załączniku IV, i sprawdzają, czy są obecne. Sprawdzają obecność treści, a nie jej jakość.

  • Instrukcja obsługi (art. 13)

    Sprawdza, czy instrukcja obsługi istnieje i zawiera wymagane sekcje.

  • Unijna deklaracja zgodności

    Sprawdza, czy deklaracja zawiera elementy wymienione w załączniku V.

  • Osiem języków

    Skan dokumentów obsługuje EN, DE, FR, IT, ES, NL, PL i PT.

Lista kontrolna wdrożenia

  • Dodaj skan kodu i dokumentów do przepływu pracy pull requestów.
  • Zacznij w trybie tylko raportowania i przejrzyj ustalenia.
  • Ustaw progi dla ustaleń krytycznych i wysokich, potem przełącz na tryb blokujący.
  • Wymagaj przeglądu przez człowieka każdego ustalenia dotyczącego art. 5 lub art. 14.
  • Przechowuj raport ze skanu przy każdym wpisie wydania.
  • Oznaczaj zmiany modelu, danych treningowych lub przewidzianego zastosowania do przeglądu jako możliwe istotne zmiany (art. 43 ust. 4).
  • Powtarzaj pełny skan przed każdym wydaniem i aktualizuj dokumentację z załącznika IV.
  • Trzymaj dokumentację techniczną w repozytorium obok kodu i aktualizuj ją w tym samym pull requeście.

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: ścieżki audytu, skanowanie oparte na regułach 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.