CRA i akt w sprawie AI: nakładanie cyberbezpieczeństwa dla AI wysokiego ryzyka

Produkt to sterownik bezpieczeństwa AI dla sieci elektroenergetycznej. Jest produktem z elementami cyfrowymi, więc ma zastosowanie akt o cyberodporności (CRA). Jest też systemem AI wysokiego ryzyka, więc stosuje się akt w sprawie sztucznej inteligencji (akt w sprawie AI). Dwie regulacje, dwie oceny zgodności, dwie deklaracje? Nie w części dotyczącej cyberbezpieczeństwa.

Po przeczytaniu tego przewodnika producent będzie znał odpowiedź na trzy pytania: czy nakładanie w ogóle dotyczy danego produktu, jakie dowody cyberbezpieczeństwa można ponownie wykorzystać w obu regulacjach i co nadal wymaga odrębnej pracy po stronie aktu w sprawie AI. Skrót: artykuł 12 aktu o cyberodporności pozwala ponownie wykorzystać dowody cyberbezpieczeństwa w obu regulacjach, pod pewnymi warunkami. Nie scala jednak zgodności z CRA i aktem w sprawie AI w jeden reżim.

Podsumowanie

• Nakładanie jest wąskie. Dotyczy wyłącznie produktu, który jest jednocześnie w zakresie CRA i systemem AI wysokiego ryzyka w rozumieniu aktu w sprawie AI.
• CRA tworzy jednostronny pomost, pod warunkami. Spełnienie wymogów cyberbezpieczeństwa CRA i wykazanie tego poziomu ochrony w deklaracji zgodności UE sprawia, że produkt jest traktowany jako spełniający wymóg cyberbezpieczeństwa aktu w sprawie AI.
• Pomost obejmuje wyłącznie cyberbezpieczeństwo. Wymagania dotyczące dokładności i niezawodności pozostają przy akcie w sprawie AI.
• Dla większości produktów prowadzi się jedną ocenę zgodności, utrzymuje jeden zestaw dokumentacji technicznej i stosuje jedno oznakowanie CE. Produkty ważne i krytyczne CRA są wyjątkiem.
• Wszystko inne pozostaje rozdzielone. Zarządzanie danymi, rejestrowanie i nadzór ludzki pozostają po stronie aktu w sprawie AI. SBOM, obsługa podatności, okres wsparcia i zgłaszanie w ciągu 24 godzin pozostają po stronie CRA.

Czy produkt jest w strefie nakładania?

Większość systemów AI nie jest w zakresie CRA, a większość produktów CRA nie jest AI. O wszystkim rozstrzygają trzy pytania.

• Czy to produkt z elementami cyfrowymi? CRA obejmuje sprzęt i oprogramowanie łączące się z urządzeniem lub siecią. Proces wyłącznie papierowy lub narzędzie całkowicie offline pozostaje poza zakresem.
• Czy jest to jednocześnie system AI wysokiego ryzyka? Akt w sprawie AI kwalifikuje system jako wysokiego ryzyka, gdy jest składnikiem bezpieczeństwa produktu wymagającego niezależnego testowania lub gdy wykonuje jedno z zastosowań wysokiego ryzyka wymienionych w akcie, takich jak zdalna identyfikacja biometryczna. Lista jest konkretna, a część zastosowań jest ponownie filtrowana jako niższego ryzyka. Chatbot ogólnego przeznaczenia zwykle nie jest systemem wysokiego ryzyka.
• Czy produkt jest wyłączony przez prawo sektorowe? CRA ustępuje miejsca produktom objętym własnymi przepisami: wyrobom medycznym, diagnostyce in vitro, pojazdom z homologacją typu, certyfikowanym statkom powietrznym i wyposażeniu morskiemu. System AI będący wyrobem medycznym obsługuje swoje bezpieczeństwo na podstawie przepisów o wyrobach medycznych, nie CRA.

Jeżeli któraś bramka nie jest spełniona, pomost nie ma zastosowania. To też jest użyteczne: można przestać próbować wykorzystywać dowody cyberbezpieczeństwa CRA na potrzeby aktu w sprawie AI i zaplanować oba strumienie pracy oddzielnie.

Krótka odpowiedź: cyberbezpieczeństwo wykazuje się raz

Gdy produkt przejdzie przez wszystkie trzy bramki, pomost spełnia swoją rolę, pod trzema warunkami. Produkt spełnia wymogi cyberbezpieczeństwa CRA, procesy producenta spełniają obowiązki CRA w zakresie obsługi podatności, a deklaracja zgodności UE CRA wykazuje poziom ochrony cyberbezpieczeństwa wymagany przez akt w sprawie AI. Spełnienie tych warunków sprawia, że produkt jest traktowany jako spełniający wymóg cyberbezpieczeństwa aktu w sprawie AI. Dowody bezpieczeństwa buduje się raz dla CRA i liczy się to też dla aktu w sprawie AI.

Ten ostatni warunek ma znaczenie. Domniemanie nie jest automatyczne. Zależy od deklaracji, która faktycznie stwierdza poziom ochrony, a nie tylko odhacza pole.

Czego pomost nie obejmuje

Pomost przenosi cyberbezpieczeństwo i nic więcej. Akt w sprawie AI wymaga też dokładności i niezawodności, a strona CRA nic w tym zakresie nie robi. Pomost nie dotyczy też szerszych obowiązków AI wysokiego ryzyka: danych i zarządzania danymi, prowadzenia rejestrów i rejestrowania, nadzoru ludzkiego oraz jasnych informacji dla osób korzystających z systemu. Jeżeli producent ukończył już pracę CRA, ta lista to to, co pozostaje do zrobienia dla aktu w sprawie AI. Pracę nad aktem w sprawie AI planuje się wokół niej, nie wokół powtarzania wykonanej pracy w zakresie bezpieczeństwa.

Warto utrwalić trzy granice. Europejski certyfikat cyberbezpieczeństwa może też spełniać wymóg cyberbezpieczeństwa aktu w sprawie AI w zakresie, w jakim go obejmuje, więc certyfikacja to druga ścieżka do tego samego celu. Samodzielny model AI ogólnego przeznaczenia nie jest strefą nakładania, ale produkt, aplikacja lub urządzenie zbudowane na tym modelu nadal może być produktem CRA, jeżeli spełnia test zakresu. Jeżeli system AI jest wbudowany w maszynę, konieczne jest obserwowanie tego interfejsu: Digital Omnibus skieruje przepisy AI dotyczące zdrowia i bezpieczeństwa maszyn przez Rozporządzenie w sprawie maszyn, z aktami delegowanymi oczekiwanymi do 2 sierpnia 2028 r.

Jakie dowody można przenieść

Pomost polega na ponownym wykorzystaniu. Poniżej zestawienie tego, co producent buduje dla CRA i co to odpowiada po stronie aktu w sprawie AI.

Trzeci wiersz to ten, który zespoły pomijają. Ocena ryzyka CRA musi uwzględniać ataki na sam model, a nie tylko na otaczające go oprogramowanie. Zatruwanie danych atakuje dane treningowe, a dane wejściowe przeciwnika atakują to, co model widzi w czasie wykonywania, więc oba należą do tej samej oceny. Ta sama praca jest tym, czego oczekuje wymóg cyberbezpieczeństwa aktu w sprawie AI, więc wykonanie jej raz obejmuje oba reżimy.

Jedna ocena, jedna dokumentacja techniczna, jedno oznakowanie CE

Dla większości produktów w strefie nakładania przeprowadza się jedną ocenę zgodności w ramach ścieżki aktu w sprawie AI, a jednostka notyfikowana oceniająca system AI może jednocześnie pokryć kontrolę cyberbezpieczeństwa CRA, o ile jest kompetentna po stronie CRA. Producent utrzymuje jeden zestaw dokumentacji technicznej służącej obu regulacjom, a gotowy produkt nosi jedno oznakowanie CE, nie dwa. Akt w sprawie AI jest do tego zbudowany: producent sporządza jedną deklarację zgodności UE obejmującą każdą mającą zastosowanie regulację, a jedno oznakowanie CE sygnalizuje spełnienie też tej drugiej regulacji.

Dwie rzeczy zmieniają ten obraz. Produkty ważne i krytyczne CRA zachowują własną ścieżkę oceny CRA dla części bezpieczeństwa, gdy akt w sprawie AI pozwoliłby na samoocenę systemu AI, więc jednostka notyfikowana kompetentna w zakresie CRA pozostaje zaangażowana. Jednorazowa ścieżka oceny obejmuje cyberbezpieczeństwo, a nie resztę aktu w sprawie AI. Ścieżki oceny zgodności CRA opisano na stronie oceny zgodności.

Co CRA nadal wymaga samodzielnie

Pomost działa w jednym kierunku i obejmuje wyłącznie bezpieczeństwo. Obowiązki CRA nie zmniejszają się dlatego, że produkt jest też AI. Producent nadal jest zobowiązany do:

• wykazu oprogramowania (SBOM) i rejestru zawartych w nim komponentów
• obsługi podatności i ich zgłaszania, w tym 24-godzinnego wczesnego ostrzeżenia o aktywnie wykorzystywanych podatnościach
• zdefiniowanego okresu wsparcia z aktualizacjami bezpieczeństwa
• konfiguracji domyślnie bezpiecznej i pozostałych właściwości produktu CRA

Akt w sprawie AI dodaje jedno polecenie, którego CRA nie formułuje samodzielnie. Ocena ryzyka bezpieczeństwa musi obejmować ataki specyficzne dla AI, takie jak zatruwanie danych i dane wejściowe przeciwnika. Ponowne wykorzystanie tej pracy nie zwalnia z obowiązku ich uwzględnienia. Oba reżimy oczekują zintegrowania ich w ramach tej samej pracy nad ryzykiem.

Dwa obowiązki zgłaszania, nie jeden

Pomost ponownie wykorzystuje dowody bezpieczeństwa. Nie łączy zgłaszania incydentów. Produkt w strefie nakładania może być obciążony dwoma odrębnymi obowiązkami zgłaszania, które nie sumują się w jeden. Uwaga terminologiczna: CRA nazywa producenta „producentem", a akt w sprawie AI „dostawcą". Dla produktu budowanego i sprzedawanego pod własną nazwą to ta sama firma, nie dwa podmioty.

• Obowiązek CRA. Producent zgłasza aktywnie wykorzystywaną podatność lub poważny incydent bezpieczeństwa do koordynującego CSIRT i ENISA, przez jednolitą platformę zgłaszania. Zegar jest krótki: 24-godzinne wczesne ostrzeżenie, aktualizacja w ciągu 72 godzin, potem raport końcowy.
• Obowiązek aktu w sprawie AI. Dostawca zgłasza poważny incydent, taki jak poważna szkoda dla zdrowia, naruszenie praw podstawowych lub poważne zakłócenie infrastruktury krytycznej, organowi nadzoru rynku w kraju, w którym do niego doszło. Termin wynosi do 15 dni, a dla najgorszych przypadków 2 dni.

Wyzwalacze ledwo się pokrywają. Zgłaszanie CRA dotyczy bezpieczeństwa produktu. Zgłaszanie aktu w sprawie AI dotyczy szkody dla bezpieczeństwa i praw. Jedno zdarzenie może uruchomić oba kanały, więc każdy typ incydentu należy kierować do właściwego kanału zanim coś się stanie. Akt w sprawie AI ogranicza zduplikowane zgłaszanie w jednym przypadku: dla samodzielnego systemu wysokiego ryzyka, którego dostawca podlega już równoważnym obowiązkom zgłaszania na podstawie innego prawa Unii, zgłoszenie aktu w sprawie AI zawęża się do incydentów dotyczących praw podstawowych.

Zespoły często budują 24-godzinne zgłaszanie CRA i traktują stronę aktu w sprawie AI jako pokrytą. Tak nie jest. Zgłoszenie poważnego incydentu do organu nadzoru rynku to odrębna praca, wymagająca własnego właściciela i własnego podręcznika.

Jeżeli organizacja jest też podmiotem kluczowym lub ważnym w rozumieniu NIS2, dodaje to trzeci kanał zgłaszania na poziomie firmy, a nie produktu. Zobacz przewodnik nakładania się CRA i NIS2.

Jak zestawiają się terminy

Jedna kwestia terminowa jest warta obserwowania. Pierwotna data aktu w sprawie AI dla systemów wysokiego ryzyka wbudowanych w produkty to 2 sierpnia 2027 r. Digital Omnibus dotyczący AI przesuwa samodzielne systemy wysokiego ryzyka na 2 grudnia 2027 r., a wbudowane w produkty na 2 sierpnia 2028 r. Współprawodawcy uzgodnili tę zmianę 7 maja 2026 r., a Parlament Europejski zatwierdził ją 16 czerwca 2026 r. Na dzień 24 czerwca 2026 r. nie jest jeszcze prawem wiążącym. Wymaga jeszcze przyjęcia przez Radę i publikacji w Dzienniku Urzędowym. Wytyczne Komisji dotyczące klasyfikacji wysokiego ryzyka są wciąż w fazie projektu, a ostateczne wytyczne oczekiwane są do końca 2026 r. Nowe daty należy traktować jako prawdopodobny wynik, nie jako ustalone prawo.

Dla produktu w strefie nakładania CRA działa jako pierwsza, ze zgłaszaniem od września 2026 r. i pełnym stosowaniem w grudniu 2027 r. Obowiązki aktu w sprawie AI dla systemów wysokiego ryzyka przypadają mniej więcej w grudniu 2027 r. dla systemów samodzielnych i w sierpniu 2028 r. dla wbudowanych w produkty, w ramach proponowanego harmonogramu.

Na co zwracać uwagę

Kilka kwestii zmienia prostą wersję tej historii.

• Domniemanie jest warunkowe. Obowiązuje tylko wtedy, gdy deklaracja zgodności UE CRA rzeczywiście wykazuje poziom ochrony cyberbezpieczeństwa wymagany przez akt w sprawie AI. Słaba deklaracja niszczy pomost.
• Produkty ważne i krytyczne są inne. Gdy akt w sprawie AI pozwoliłby na samoocenę, własna ścieżka oceny CRA rządzi częścią bezpieczeństwa, więc jednostka notyfikowana kompetentna w zakresie CRA pozostaje w grze.
• Jeden organ nadzoru rynku. Dla produktu w strefie nakładania organ nadzorujący system AI nadzoruje też stronę CRA i współpracuje z CSIRT i ENISA w zakresie zgłaszania CRA.
• Pomost to tylko bezpieczeństwo. Nic nie robi dla dokładności, niezawodności, zarządzania danymi, rejestrowania ani nadzoru ludzkiego. Na te elementy należy zaplanować budżet jako odrębną pracę na potrzeby aktu w sprawie AI.
• Daty nie są ustalone. Daty wysokiego ryzyka na lata 2027 i 2028 oczekują na przyjęcie przez Radę Digital Omnibus.
• Maszyny mają własną ścieżkę. Maszyny z funkcjami AI kierowane są ku Rozporządzeniu w sprawie maszyn w zakresie przepisów dotyczących zdrowia i bezpieczeństwa AI.

Nasza ocena

Pomost jest realny i użyteczny, ale „oceniane raz" należy traktować jako cel planistyczny, nie gwarancję. Zysk to ponowne wykorzystanie dowodów. Buduje się jeden solidny plik bezpieczeństwa CRA i jeden zestaw dokumentacji technicznej, a następnie wskazuje się na nie oba reżimy.

Pułapka, którą widzimy, to zespoły odczytujące pomost jako „obowiązek bezpieczeństwa aktu w sprawie AI jest odznaczony" i pomijające pracę dotyczącą zagrożeń specyficznych dla AI, którą ocena CRA wciąż musi obejmować. Zatruwanie danych i dane wejściowe przeciwnika to miejsca, w których produkt AI naprawdę odnosi szkody, i tego właśnie oba akty oczekują od producenta.

Nasza rekomendacja jest prosta. Produkt należy najpierw sklasyfikować, plik bezpieczeństwa CRA zbudować na wysokim poziomie, deklarację napisać tak, żeby stwierdzała poziom ochrony, i pracę nad dokładnością, niezawodnością oraz nadzorem aktu w sprawie AI prowadzić na odrębnym torze. Wtedy nakładanie oszczędza realnej duplikacji. Odczytywanie go jako skrótu zemści się przy ocenie.

Co robić dalej

Ten artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania szczegółowych wskazówek dotyczących zgodności należy skonsultować się z wykwalifikowanym doradcą prawnym.