Unia Europejska właśnie definiuje, co znaczy „cyberbezpieczny system AI”. Projekt normy prEN 18282 przekłada art. 15 AI Act na konkretne wymagania — i warto go poznać, zanim stanie się obowiązującym punktem odniesienia. Warto też śledzić go aż do finalnego wydania: po cytowaniu w Dzienniku Urzędowym UE zgodność z normą stanie się najprostszą przepustką do domniemania zgodności z AI Act.
Obowiązki AI Act dla systemów wysokiego ryzyka przesunięte na grudzień 2027. Dobra wiadomość? Tylko pozornie.
Wprowadzenie
Sztuczna inteligencja stworzyła nową powierzchnię ataku, której klasyczne cyberbezpieczeństwo nie obejmuje. Zatruty zbiór treningowy, podmienione wagi modelu, spreparowany prompt — żadne z tych zagrożeń nie wygląda jak tradycyjny incydent bezpieczeństwa, a każde może zmienić zachowanie systemu decydującego o kredycie, rekrutacji czy diagnozie.
AI Act odpowiada na to art. 15 ust. 5, wymagając od systemów AI wysokiego ryzyka odporności na próby manipulacji. Problem w tym, że rozporządzenie mówi „co”, a nie „jak”. Tę lukę wypełnia prEN 18282 — projekt Normy Europejskiej opracowany przez komitet CEN/CLC/JTC 21 na zlecenie standaryzacyjne Komisji Europejskiej, opublikowany do ankiety publicznej (CEN Enquiry) w maju 2026 r. Dokument ma jasno zadeklarowany cel: wsparcie wdrożenia wymagań cyberbezpieczeństwa z art. 15 ust. 5 AI Act. Po przyjęciu i cytowaniu w Dzienniku Urzędowym UE zgodność z nim da domniemanie zgodności z odpowiednimi wymaganiami rozporządzenia — a to zamienia dobrowolną normę w praktyczny standard rynkowy.
Dla organizacji rozwijających lub wdrażających systemy AI — zwłaszcza kandydujące do kategorii wysokiego ryzyka — to dokument, który warto czytać już dziś, w fazie projektu.
Rama cyberbezpieczeństwa AI: Od okoliczności do środków
Logika normy: pięć kroków, które znają audytorzy
Konstrukcja prEN 18282 będzie intuicyjna dla każdego, kto pracował z systemami zarządzania bezpieczeństwem informacji. Norma wymaga od dostawcy (providera) systemu AI przejścia przez uporządkowaną sekwencję: określenie istotnych okoliczności działania systemu (klauzula 6), identyfikację podatności specyficznych dla AI (klauzula 7) i zagrożeń, które mogą je wykorzystać (klauzula 8), wyznaczenie wynikających z nich ryzyk (klauzula 9), a na końcu dobór i wdrożenie środków (klauzula 10) — z weryfikacją przez testy (klauzula 11) i pełną dokumentacją (klauzula 12).
Istotne zastrzeżenie architektoniczne: norma nie tworzy odrębnego systemu zarządzania ryzykiem. Wyniki analizy cyberbezpieczeństwa mają zasilać ogólny proces zarządzania ryzykiem systemu AI — czyli w praktyce struktury znane z ISO/IEC 42001 czy ISO/IEC 23894. Co więcej, klauzula 5.1.3 stawia sprawę wprost: dostawca ma wdrożyć konwencjonalne środki cyberbezpieczeństwa jako warunek wstępny, odsyłając do serii ISO/IEC 27000 i pokrewnych standardów. prEN 18282 nie zastępuje więc systemu zarządzania bezpieczeństwem informacji — nadbudowuje nad nim warstwę specyficzną dla AI.
Aktywa, których nie ma w klasycznym rejestrze
Klauzula 6.3 i normatywny Załącznik D każą zidentyfikować aktywa, których próżno szukać w tradycyjnej inwentaryzacji: zbiory treningowe, walidacyjne i testowe wraz z prawami do ich użycia, wagi i parametry modelu, potoki przetwarzania danych, komponenty łańcucha dostaw — a także prompty systemowe i wbudowane instrukcje. To ostatnie pokazuje, jak świeżo norma traktuje rzeczywistość generatywnej AI: instrukcja systemowa chatbota jest aktywem podlegającym ochronie tak samo jak baza danych.
Pięć rodzin ataków i cykl pięciu wyników
Klauzula 10 — operacyjne serce dokumentu — porządkuje środki techniczne według pięciu rodzin ataków, wymienionych zresztą wprost w art. 15 ust. 5 AI Act:
Data poisoning — manipulacja danymi treningowymi, walidacyjnymi lub testowymi. Norma wymaga m.in. śledzenia pochodzenia danych (provenance), kontroli dostępu do potoków danych na zasadzie najmniejszych uprawnień, walidacji i sanityzacji zbiorów przed użyciem oraz monitorowania zachowania modelu po każdym treningu.
Model poisoning — manipulacja samym modelem lub komponentami wstępnie wytrenowanymi. Tu pojawiają się wymagania weryfikacji integralności modelu metodami kryptograficznymi przy każdym transferze, składowaniu i wdrożeniu, rejestrowania prób dostępu do wag i parametrów oraz oceny bezpieczeństwa modeli pozyskanych z zewnątrz — łącznie z ryzykami deserializacji.
Ataki adwersaryjne (model evasion) — dane wejściowe spreparowane tak, by wywołać błędną odpowiedź modelu. Ataki na poufność — ekstrakcja parametrów modelu, danych treningowych lub stanów wewnętrznych przez obserwację wyników (model theft, model inversion, membership inference). Wady modelu (model flaws) — błędy projektowe i implementacyjne możliwe do wykorzystania przez atakującego.
Dla każdej rodziny norma wymaga rozważenia środków w pięciostopniowym cyklu: zapobiegaj → wykrywaj → reaguj → usuwaj skutki → kontroluj (prevent, detect, respond, resolve, control). Ta pięciostopniowa struktura nie jest wynalazkiem komitetu — odzwierciedla dosłownie language art. 15 ust. 5, co widać czarno na białym w tabeli ZA.1, mapującej każdą kombinację „środek × atak” na konkretną podklauzulę normy.
Generatywna AI dostaje własną podklauzulę
Podklauzula 10.6 adresuje zagrożenia specyficzne dla modeli generatywnych, w tym dużych modeli językowych: prompt injection bezpośredni i pośredni, manipulację instrukcjami systemowymi, ekstrakcję modelu i wyciek informacji wrażliwych przez generowane odpowiedzi. Dostawcy mają obowiązek uwzględnić te zagrożenia w identyfikacji ryzyk i zastosować środki obejmujące m.in. zapobieganie nadpisywaniu instrukcji, wykrywanie anomalnych wzorców wejścia i reagowanie na szkodliwe outputy. To pierwsze tak wprost sformułowane wymagania normatywne dla bezpieczeństwa LLM w europejskiej standaryzacji.
Testowanie i dokumentacja: Dowody, nie deklaracje
Klauzula 11 przekłada środki na weryfikację: testy odporności na zatruwanie, testy adwersaryjne z jawnie zadeklarowanymi założeniami o wiedzy atakującego, testy poufności oraz — tam gdzie uzasadnia to ekspozycja lub złożoność systemu — testy złożone i red-teaming sprawdzające, czy mechanizmy obrony wielowarstwowej działają w realistycznych sekwencjach ataków. Kryteria akceptacji muszą być zdefiniowane przed wykonaniem testów oraz mierzalne i weryfikowalne.
Klauzula 12 domyka całość dokumentacją zdolną wesprzeć ocenę zgodności i działania po wprowadzeniu na rynek — od udokumentowanych okoliczności, przez rejestry podatności, zagrożeń i ryzyk, po opis każdego środka wraz ze sposobem jego testowania. Podklauzula 12.7 wymaga przekazania deployerowi instrukcji użytkowania opisujących poziom cyberbezpieczeństwa systemu — spinając normę z wymogami przejrzystości art. 13 AI Act.
Kontekst regulacyjny: Terminy po Digital Omnibus
Harmonogram AI Act zmienił się w ostatnich tygodniach. Digital Omnibus on AI — zatwierdzony ostatecznie przez Radę UE 29 czerwca 2026 r. — przesuwa stosowanie obowiązków dla samodzielnych systemów wysokiego ryzyka (Załącznik III) na 2 grudnia 2027 r., a dla AI wbudowanej w produkty regulowane (Załącznik I) na 2 sierpnia 2028 r. (stan na 26.07.2026; publikacja w Dz.U. UE oczekiwana przed 2 sierpnia 2026 r.). Powodem opóźnienia był m.in. brak gotowych norm zharmonizowanych — czyli dokładnie takich dokumentów jak prEN 18282. Odroczenie nie jest więc zawieszeniem prac, lecz czasem na ich rzetelne wykonanie: organizacje, które wykorzystają go na wdrożenie ramy cyberbezpieczeństwa AI, przystąpią do oceny zgodności z gotowym materiałem dowodowym.
Podsumowanie
prEN 18282 to najbardziej konkretna dziś odpowiedź na pytanie, czym jest cyberbezpieczeństwo systemu AI w rozumieniu prawa europejskiego: pięć rodzin ataków, pięć klas środków, mierzalne testy i dokumentacja gotowa pod ocenę zgodności. Dokument jest jeszcze projektem — ale kierunek jest przesądzony, a przewaga przypadnie tym, którzy zaczną wcześniej. Jeśli Twoja organizacja buduje system zarządzania AI lub przygotowuje się do wymagań AI Act — zapraszamy do kontaktu: pomagamy przejść od lektury normy do działającego systemu.
Bibliografia:
- prEN 18282:2026. Artificial intelligence — Cybersecurity specifications for AI systems. CEN/CENELEC, projekt w fazie Enquiry, maj 2026. [CEN-CENELEC]
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z dnia 13 czerwca 2024 r. (AI Act), art. 13 i art. 15 ust. 5. [EUR-Lex]
- Digital Omnibus on AI — pakiet uproszczeń cyfrowych, zgoda Rady UE z 29 czerwca 2026 r. [Rada UE]
- ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. [ISO.org]
- ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. [ISO.org]
FAQ - cyberbezpieczeństwo systemów AI
prEN 18282 to projekt Normy Europejskiej opracowany przez komitet CEN/CLC/JTC 21 na zlecenie Komisji Europejskiej. Określa specyfikacje cyberbezpieczeństwa dla systemów AI wysokiego ryzyka i ma wspierać wdrożenie art. 15 ust. 5 AI Act. Od maja 2026 r. znajduje się w fazie ankiety publicznej (CEN Enquiry) i może jeszcze ulec zmianom przed przyjęciem.
Nie — normy zharmonizowane są dobrowolne. Jednak po przyjęciu i cytowaniu w Dzienniku Urzędowym UE zgodność z nią da domniemanie zgodności z odpowiednimi wymaganiami AI Act. W praktyce oznacza to, że stosowanie normy stanie się najprostszą ścieżką wykazania zgodności dla dostawców systemów AI wysokiego ryzyka.
Norma porządkuje środki według pięciu rodzin ataków: zatruwanie danych (data poisoning), zatruwanie modelu (model poisoning), ataki adwersaryjne (model evasion), ataki na poufność (m.in. kradzież modelu i ekstrakcja danych treningowych) oraz wady modelu. Osobna podklauzula obejmuje zagrożenia generatywnej AI, w tym prompt injection bezpośredni i pośredni.
Nie — wręcz przeciwnie. Norma wymaga wdrożenia konwencjonalnych środków cyberbezpieczeństwa jako warunku wstępnego i odsyła w tym zakresie m.in. do serii ISO/IEC 27000. prEN 18282 nadbudowuje nad systemem zarządzania bezpieczeństwem informacji warstwę specyficzną dla AI: ochronę danych treningowych, integralności modelu i interfejsów systemu.
Po zatwierdzeniu Digital Omnibus przez Radę UE (29 czerwca 2026 r.) obowiązki dla samodzielnych systemów wysokiego ryzyka z Załącznika III zaczną być stosowane od 2 grudnia 2027 r., a dla AI wbudowanej w produkty regulowane z Załącznika I — od 2 sierpnia 2028 r. (stan na lipiec 2026). Odroczenie daje organizacjom czas na wdrożenie ramy cyberbezpieczeństwa opisanej w prEN 18282.
Opracowanie merytoryczne:
Ekspert w zakresie systemów zarządzania ISO, cyberbezpieczeństwa, compliance i AI governance. Audytor, konsultant, trener.