AI i NIS2 w administracji – jak dwa rozporządzenia działają razem?

AI Act i NIS2 to dwa filary nowego europejskiego ładu regulacyjnego: pierwszy standaryzuje bezpieczne stosowanie systemów sztucznej inteligencji, drugi wzmacnia cyberbezpieczeństwo sieci i systemów informatycznych. Dla administracji publicznej oba akty nakładają się na siebie – szczególnie tam, gdzie urząd świadczy usługi z użyciem systemów AI o wysokim ryzyku, a jednocześnie podlega NIS2 jako „podmiot publiczny” w sektorze administracji.

Dlaczego AI Act i NIS2 są kluczowe dla administracji publicznej

NIS2 (dyrektywa 2022/2555) rozszerza katalog sektorów objętych obowiązkową regulacją cyberbezpieczeństwa do 18, w tym o sektor administracji publicznej, obejmując centralne i wybrane regionalne organy administracji jako „essential” lub „important entities”. Państwa członkowskie muszą stosować przepisy NIS2 od 18 października 2024 r., po transpozycji do prawa krajowego, choć wiele krajów – w tym Polska – przyjęło ustawy wdrażające z opóźnieniem.

AI Act (rozporządzenie 2024/1689) wszedł w życie 1 sierpnia 2024 r., ale jego obowiązki są rozłożone w czasie – zakazane praktyki i wymogi w zakresie „AI literacy” stosuje się od 2 lutego 2025 r., obowiązki dla modeli ogólnego przeznaczenia od 2 sierpnia 2025 r., a pełny reżim dla systemów wysokiego ryzyka (wraz z sankcjami) od 2 sierpnia 2026 r. Administracja publiczna jest szczególnie istotna, bo wiele zastosowań wymienionych w załączniku III – np. systemy oceniające uprawnienie do świadczeń publicznych – jest definiowanych jako wysokiego ryzyka.

Zakres podmiotowy: kiedy urząd podlega NIS2, a kiedy AI Act

NIS2 obejmuje „public administration entities”, czyli m.in. centralne organy administracji (z wyłączeniem parlamentów, sądów, banków centralnych oraz służb bezpieczeństwa), a także – według decyzji państw członkowskich – wybrane administracje regionalne i w niektórych przypadkach lokalne. Jeżeli urząd spełnia kryteria wielkości lub znaczenia usług, trafia do rejestru podmiotów kluczowych lub ważnych i musi wdrożyć ścisłe środki zarządzania ryzykiem cyberbezpieczeństwa oraz raportowania incydentów.

AI Act działa inaczej – nie patrzy na sektor, lecz na rolę w cyklu życia systemu AI (dostawca, wdrażający/deployer, importer itd.) oraz na poziom ryzyka konkretnego systemu. W administracji publicznej najczęściej urząd będzie „deployerem” systemu wysokiego ryzyka, np. przy podejmowaniu decyzji o przyznaniu świadczenia, ocenie wiarygodności beneficjenta czy dostępie do usług publicznych, co wprost wskazuje załącznik III.

Mapa nakładania się AI Act i NIS2

Na poziomie technicznym oba akty dotykają podobnych obszarów – zarządzania ryzykiem, monitorowania systemów, raportowania incydentów, zarządzania łańcuchem dostaw oraz odpowiedzialności kierownictwa – ale robią to z różnych perspektyw.

• NIS2 patrzy na cały krajobraz sieci i systemów IT/OT urzędu, niezależnie od tego, czy wykorzystują AI, i wymaga wdrożenia środków bezpieczeństwa dla infrastruktury krytycznej usług publicznych.
• AI Act patrzy na konkretne systemy AI, szczególnie wysokiego ryzyka, i wymaga ich projektowania, wdrażania oraz nadzoru w sposób kontrolujący ryzyka dla zdrowia, bezpieczeństwa i praw podstawowych.
• Obszar wspólny to m.in. procesy zarządzania ryzykiem, ciągłe monitorowanie, prowadzenie logów, szkolenia, procedury reagowania na incydenty oraz zarządzanie dostawcami, które można w praktyce zaprojektować jako jeden spójny system kontroli.

Co jest wymagane tylko przez NIS2

Niektóre obowiązki wynikają wyłącznie z NIS2 i nie mają bezpośredniego odpowiednika w AI Act, choć można je wspierać narzędziami AI.

• Pełne zarządzanie ryzykiem cyberbezpieczeństwa sieci i systemów – artykuł 21 NIS2 wymaga wdrożenia co najmniej 10 kategorii środków, w tym polityk analizy ryzyka, planów ciągłości działania i odtwarzania, bezpieczeństwa łańcucha dostaw, procedur weryfikacji skuteczności środków, polityk kryptograficznych i wieloskładnikowego uwierzytelniania.
• 24–72–30 dla incydentów cybernetycznych – NIS2 wymaga zgłoszenia „znaczącego incydentu” do krajowego CSIRT lub właściwego organu w trzech krokach: wstępne ostrzeżenie w ciągu 24 godzin, zgłoszenie uzupełniające w ciągu 72 godzin oraz raport końcowy w ciągu 1 miesiąca.
• Klasyfikacja na „essential” i „important entities” oraz reżim nadzoru – NIS2 buduje dwupoziomowy model nadzoru (proaktywny dla podmiotów kluczowych, reaktywny dla ważnych) i powiązane z tym sankcje oraz uprawnienia organów, np. możliwość czasowego zakazu pełnienia funkcji przez osoby z kierownictwa.
• Specyficzna architektura krajowego systemu cyberbezpieczeństwa – dyrektywa wymaga wyznaczenia krajowych CSIRT, organów właściwych i punktu kontaktowego oraz zasilania ENISA zagregowanymi informacjami o incydentach, co jest poza zakresem AI Act.

Co jest wymagane tylko przez AI Act

Druga grupa to obowiązki występujące wyłącznie w AI Act, kluczowe szczególnie dla urzędów korzystających z systemów wysokiego ryzyka.

• Klasyfikacja systemów AI i zakazane praktyki – urząd musi zidentyfikować, które używane systemy są zakazane (np. niektóre formy oceny społecznej) lub wysokiego ryzyka w rozumieniu artykułu 6 i załącznika III, a od 2 lutego 2025 r. nie może stosować praktyk zakazanych.
• System zarządzania ryzykiem dla wysokiego ryzyka – artykuł 9 wymaga, aby dostawcy systemów wysokiego ryzyka ustanowili ciągły, iteracyjny system zarządzania ryzykiem obejmujący identyfikację, analizę, ocenę i redukcję ryzyk dla zdrowia, bezpieczeństwa i praw podstawowych. Urząd jako deployer musi korzystać z systemu zgodnie z tymi zasadami i monitorować jego działanie.
• Ocena skutków dla praw podstawowych (FRIA) – artykuł 27 wymaga, aby organy publiczne wdrażające systemy wysokiego ryzyka (z wyjątkiem systemów dla infrastruktury krytycznej) przeprowadziły ocenę skutków dla praw podstawowych przed pierwszym użyciem systemu. Ocena obejmuje m.in. opis procesu, grup dotkniętych, scenariuszy ryzyka, środków nadzoru ludzkiego i mechanizmów skargowych.
• Rejestracja systemów wysokiego ryzyka w unijnej bazie – artykuł 71 przewiduje utworzenie centralnej bazy, w której dostawcy, a w przypadku organów publicznych także deployerzy, muszą rejestrować systemy wysokiego ryzyka z załącznika III. Dane o systemie (m.in. przeznaczenie, dostawca, ID) będą publicznie dostępne w ograniczonym zakresie.
• Specyficzne obowiązki dla modeli ogólnego przeznaczenia (GPAI) – od 2 sierpnia 2025 r. dostawcy modeli ogólnego przeznaczenia muszą spełniać wymogi dokumentacyjne, dotyczące praw autorskich i – dla modeli o systemowym ryzyku – testów odporności, co może dotknąć administrację jako nabywcę takich rozwiązań, ale nie jest regulowane przez NIS2.

Wymagania wspólne: co nakazują oba akty

Istnieje grupa obowiązków, które – choć ujęte różnym językiem – pojawiają się w obu aktach i mogą być realizowane jednym zintegrowanym systemem zgodności.

• Zarządzanie ryzykiem i kontrola wewnętrzna – NIS2 wymaga wdrożenia środków zarządzania ryzykiem dla sieci i systemów (art. 21), a AI Act wymaga systemu zarządzania ryzykiem dla systemów wysokiego ryzyka (art. 9) oraz monitorowania i ograniczania ryzyk przez deployerów (art. 26).
• Szkolenia i kompetencje – NIS2 nakłada na kierownictwo obowiązek zatwierdzania środków bezpieczeństwa oraz odbywania szkoleń z cyberbezpieczeństwa, a wprost wymaga podstawowej higieny cybernetycznej i szkoleń personelu. AI Act wprowadza wymogi „AI literacy” oraz żąda, aby osoby sprawujące nadzór nad systemami wysokiego ryzyka miały odpowiednie kompetencje i przeszkolenie.
• Raportowanie incydentów – NIS2 wprowadza obowiązek raportowania istotnych incydentów cybernetycznych w trybie 24–72–30 do krajowego CSIRT, natomiast AI Act wymaga zgłaszania „poważnych incydentów” związanych z systemami wysokiego ryzyka do organu nadzoru rynku niezwłocznie, najpóźniej w 15 dni, z krótszymi terminami w przypadku poważniejszej szkody. W praktyce jeden incydent (np. atak na usługę opartą na AI) może uruchomić oba łańcuchy raportowania.
• Łańcuch dostaw – NIS2 explicite wymaga uwzględniania bezpieczeństwa w relacjach z dostawcami i usługodawcami IT w ramach środków zarządzania ryzykiem. AI Act wymaga, aby dostawcy systemów wysokiego ryzyka zapewnili komplet dokumentacji i wsparcie dla deployerów, a deployerzy kontrolowali wejściowe dane, nadzór ludzki i logowanie, co również wymusza zarządzanie ryzykiem łańcucha dostaw.
• Dokumentacja i logowanie – oba akty stawiają na ścisłą dokumentację i prowadzenie logów: NIS2 oczekuje dowodów skuteczności środków bezpieczeństwa, zaś AI Act wymaga utrzymywania logów działania systemów wysokiego ryzyka przez co najmniej 6 miesięcy i gotowości udostępnienia dokumentacji organom nadzoru.

Harmonogram: kluczowe daty i tabela obowiązków

W administracji publicznej największe „zagęszczenie” wymagań następuje w latach 2024–2026: od jesieni 2024 r. stosuje się NIS2 (w miarę wdrażania ustaw krajowych), a od 2025–2026 r. dochodzą kolejne fale obowiązków AI Act.

Poniższa tabela syntetyzuje wybrane obowiązki typowe dla urzędu, z podaniem podstawy prawnej i orientacyjnego terminu na poziomie UE (oraz wskazaniem specyfiki krajowej dla NIS2):

Jak praktycznie wykorzystać tę mapę w administracji

W praktyce najlepsze efekty daje podejście „map once, comply many” – czyli zbudowanie jednej matrycy kontroli, którą można zmapować równocześnie na wymagania NIS2 i AI Act, zamiast utrzymywać dwa oderwane od siebie programy zgodności. Z perspektywy urzędu można to zrealizować w kilku krokach:

• Inwentaryzacja usług i systemów – zidentyfikuj usługi publiczne, które lokują urząd w sektorze administracji NIS2, a następnie zmapuj systemy IT/OT oraz systemy AI wspierające te usługi, z wyróżnieniem potencjalnych systemów wysokiego ryzyka według załącznika III.
• Połączenie procesów zarządzania ryzykiem – rozwiń istniejące procesy zarządzania ryzykiem cyberbezpieczeństwa (NIS2) o specyficzne elementy wymagane przez AI Act, takie jak ocena ryzyk dla praw podstawowych, testowanie systemów wysokiego ryzyka i stałe monitorowanie jakości danych.
• Ujednolicenie procedur incydentowych – zaprojektuj jeden proces obsługi incydentów, który w pierwszej kolejności stosuje krótsze terminy NIS2 (24–72–30), a równolegle zapewnia wolniejsze, ale bardziej szczegółowe raportowanie poważnych incydentów AI w terminach z art. 73 AI Act.
• Zintegrowane zarządzanie dostawcami – włącz wymagania AI Act wobec dostawców systemów wysokiego ryzyka (dokumentacja, wsparcie, możliwość audytu) w ogólną politykę bezpieczeństwa łańcucha dostaw, której NIS2 wymaga wprost.
• Program szkoleniowy dla kierownictwa i kluczowych ról – połącz obowiązkowe szkolenia z cyberbezpieczeństwa (NIS2) z modułami o roli nadzoru ludzkiego, interpretacji wyników AI i ryzykach dla praw podstawowych, których wymagają przepisy AI Act.

Dzięki takiej integracji administracja może zmniejszyć „zmęczenie audytami”, uniknąć dublowania dokumentacji, a przede wszystkim – spójnie zarządzać ryzykiem technicznym i prawnym w środowisku, gdzie systemy AI stają się naturalną częścią infrastruktury usług publicznych.

Źródła

• EU Cybersecurity NIS2 Directive to be transposed National Law by October 2024 (trade.gov)
• NIS 2 Directive, Article 21: Cybersecurity risk-management measures
• NIS 2 Directive, Article 23: Reporting obligations
• NIS2 Article 21 Risk Management Measures Explained (Glocert)
• Article 9: Risk Management System – EU AI Act
• Art. 27 AI Act – Fundamental rights impact assessment for high-risk AI systems
• Article 26: Obligations of deployers of high-risk AI systems – AI Act Service Desk
• Annex III: High-Risk AI Systems Referred to in Article 6(2) – EU AI Act
• EU AI Act Timeline & When Obligations Kick In (Glocert)
• Public Administration Sector and NIS2 Directive
• Transposition of NIS2 in Poland
• Article 73: Reporting of Serious Incidents – EU AI Act
• Article 71: EU database for high-risk AI systems listed in Annex III – AI Act Service Desk
• NIS 2 and EU AI Act: How Overlapping Rules Redefine Cyber and AI Compliance
• Mastering the Overlap Between DORA, NIS2, and the EU AI Act (Enactia)