Streszczenie AI
AI Act i NIS‑2 to dwa kluczowe filary europejskiego ładu regulacyjnego, które w administracji publicznej się składają: NIS‑2 chroni całą infrastrukturę IT/OT, wymuszając ciągłą analizę ryzyka i dbałość o incydenty, podczas gdy AI Act nakłada obowiązki w zakresie bezpieczeństwa, przejrzystości i prawa podstawowego przy wdrażaniu wysokiego ryzyka AI. Wspólne zadania – zarządzanie ryzykiem, audyt łańcucha dostaw i reagowanie na incydenty – dają szansę na „map once, comply many”, łącząc dwa systemy zgodności w jedną, przejrzystą architekturę, przez co administracja zapobiega podwójnym obciążeniom i ryzykom.
Stan wpisów Ai Act.
Stan prawny aktualny na sierpień 2026 r. Ze względu na obszerność AI Act kolejna weryfikacja i aktualizacja treści odbędzie się w lutym 2027 r.
Spis treści:
- Dlaczego AI Act i NIS2 są kluczowe dla administracji publicznej
- Zakres podmiotowy: kiedy urząd podlega NIS2, a kiedy AI Act
- Mapa nakładania się AI Act i NIS2
- Co jest wymagane tylko przez NIS2
- Co jest wymagane tylko przez AI Act
- Wymagania wspólne: co nakazują oba akty
- Harmonogram: kluczowe daty i tabela obowiązków
- Jak praktycznie wykorzystać tę mapę w administracji
- Źródła
AI Act i NIS2 to dwa filary europejskiego ładu regulacyjnego w obszarze technologii cyfrowych: pierwszy standaryzuje bezpieczne projektowanie i stosowanie systemów sztucznej inteligencji, drugi wzmacnia cyberbezpieczeństwo sieci i systemów informatycznych. Dla sektora publicznego oba akty bezpośrednio nakładają się na siebie – w szczególności wtedy, gdy organ administracji świadczy usługi z wykorzystaniem systemów AI wysokiego ryzyka, a jednocześnie podlega reżimowi NIS2 jako podmiot publiczny.
Dlaczego AI Act i NIS2 są kluczowe dla administracji publicznej
Dyrektywa NIS2 (2022/2555) rozszerzyła katalog sektorów objętych obowiązkową regulacją cyberbezpieczeństwa do 18, klasyfikując centralne oraz wybrane regionalne i samorządowe organy administracji publicznej jako podmioty kluczowe (essential) lub ważne (important). W Polsce implementacja NIS2 weszła w życie 3 kwietnia 2026 r. poprzez nowelizację ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), nakładając na jednostki administracji konkretne terminy rejestracji i wdrożenia systemów zarządzania bezpieczeństwem informacji.
Z kolei AI Act (rozporządzenie 2024/1689) wszedł w życie 1 sierpnia 2024 r., a jego wymogi są wdrażane etapowo: zakazy niedozwolonych praktyk oraz kompetencje w zakresie AI (AI literacy) obowiązują od 2 lutego 2025 r., zasady dla modeli ogólnego przeznaczenia (GPAI) od 2 sierpnia 2025 r., a pełen reżim dla systemów wysokiego ryzyka (Załącznik III) oraz powiązane sankcje stosuje się od 2 sierpnia 2026 r. Administracja publiczna znajduje się w centrum tych przepisów, ponieważ systemy oceniające dostęp do świadczeń, usług socjalnych czy decyzji administracyjnych są wprost kwalifikowane jako rozwiązania wysokiego ryzyka.
Zakres podmiotowy: kiedy urząd podlega NIS2, a kiedy AI Act
NIS2 obejmuje sektor administracji publicznej podmiotowo: dotyczy m.in. organów administracji rządowej oraz wskazanych jednostek samorządu terytorialnego i ich jednostek organizacyjnych (z wyłączeniem sił zbrojnych, wymiaru sprawiedliwości i parlamentu). Po spełnieniu kryteriów ustawowych urząd podlega wpisowi do Wykazu podmiotów KSC i musi wdrożyć formalne środki techniczne i organizacyjne w zakresie zarządzania ryzykiem cybernetycznym.
AI Act opiera się na kryterium funkcjonalnym oraz analizie ryzyka konkretnego systemu AI. W urzędach administracji publicznej instytucja występuje najczęściej w roli podmiotu wdrażającego (deployera) systemu wysokiego ryzyka. Dotyczy to m.in. narzędzi automatyzujących rozpatrywanie wniosków obywateli, weryfikację uprawnień socjalnych, ocenę wiarygodności w systemach podatkowych czy biometryczną kontrolę dostępu.
Mapa nakładania się AI Act i NIS2
Na poziomie operacyjnym i technicznym oba akty prawne koncentrują się na analogicznych obszarach – analizie ryzyka, monitorowaniu środowisk produkcyjnych, obsłudze incydentów, kontroli łańcucha dostaw oraz odpowiedzialności kierownictwa – jednak podchodzą do nich pod innym kątem.
- NIS2 obejmuje całą infrastrukturę teleinformatyczną (sieci, serwery, aplikacje IT/OT) urzędu i wymaga zapewnienia odporności na cyberataki oraz ciągłości działania świadczonych usług publicznych.
- AI Act skupia się na warstwie algorytmicznej i danych konkretnego systemu AI, nakazując kontrolę nad ryzykami naruszenia praw podstawowych, stronniczością, brakiem nadzoru ludzkiego czy awariami modeli uczenia maszynowego.
- Obszar wspólny tworzą procedury reagowania na incydenty, mechanizmy audytu i logowania, zarządzanie dostawcami technologii (third-party risk) oraz programy podnoszenia kwalifikacji kadr.
Co jest wymagane tylko przez NIS2
Pewne obowiązki wynikają bezpośrednio z dyrektywy NIS2 i znowelizowanej ustawy o KSC, nie mając bezpośredniego odpowiednika w AI Act:
- Obligatoryjny katalog 10 środków techniczno-organizacyjnych (art. 21 NIS2) – wdrożenie m.in. polityk analizy ryzyka infrastruktury, planów ciągłości działania (BCP/DR), kontroli kryptografii, uwierzytelniania wieloskładnikowego (MFA) oraz procedur bezpieczeństwa zasobów ludzkich.
- Rygorystyczny schemat zgłaszania incydentów 24–72–30 – obowiązek przekazania wczesnego ostrzeżenia do właściwego zespołu CSIRT (w Polsce: CSIRT NASK, CSIRT GOV lub CSIRT MON) w ciągu 24 godzin od wykrycia znaczącego incydentu, pełnego zgłoszenia w 72 godziny oraz raportu końcowego w terminie 1 miesiąca.
- Rejestracja w krajowym rejestrze i systemie S46 – obowiązek wpisu do centralnego Wykazu podmiotów KSC oraz podłączenia do systemu teleinformatycznego S46 służącego do szybkiej wymiany informacji o zagrożeniach i incydentach.
- Nadzór i osobista odpowiedzialność kierowników jednostek – bezpośrednia odpowiedzialność członków kierownictwa urzędu za zatwierdzenie i nadzór nad wdrażaniem środków cyberbezpieczeństwa, włącznie z sankcjami finansowymi nakładanymi na osoby zarządzające.
Co jest wymagane tylko przez AI Act
Poniższe wymogi dotyczą specyfiki systemów algorytmicznych i obowiązują urzędy wykorzystujące systemy zaklasyfikowane do kategorii wysokiego ryzyka:
- Ocena skutków dla praw podstawowych (FRIA – art. 27) – podmioty publiczne wdrażające systemy wysokiego ryzyka muszą przed ich uruchomieniem przeprowadzić i udokumentować ocenę wpływu na prawa podstawowe obywateli (np. prawo do prywatności, niedyskryminacji czy sprawiedliwego procesu).
- Rejestracja we wspólnej bazie UE (art. 71) – deployerzy ze sfery publicznej są zobowiązani do zgłoszenia używanego systemu wysokiego ryzyka do publicznie dostępnej bazy danych prowadzonej przez Komisję Europejską przed wdrożeniem produkcyjnym.
- Zapewnienie skutecznego nadzoru ludzkiego (human-in-the-loop) – wyposażenie personelu urzędu w kompetencje i narzędzia umożliwiające weryfikację, zakwestionowanie lub manualne zatrzymanie działania algorytmu podejmującego decyzje.
- Nadzór nad jakością danych wejściowych i logowaniem – bieżąca kontrola reprezentatywności danych oraz obowiązek automatycznego rejestrowania zdarzeń (logów) i ich przechowywania przez minimum 6 miesięcy na potrzeby ewentualnego audytu organu nadzoru rynku.
Wymagania wspólne: co nakazują oba akty
Obszary wspólne pozwalają na stworzenie jednolitej architektury ładu technologicznego (governance) w instytucji:
- Ciągłe zarządzanie ryzykiem – NIS2 wymusza ciągłą analizę ryzyk w środowisku IT, podczas gdy AI Act (art. 9 i 26) nakazuje analizę specyficznych ryzyk modelu AI. Oba procesy można zintegrować w jeden system zarządzania ryzykiem operacyjnym.
- Podnoszenie kompetencji i szkolenia – NIS2 nakłada obowiązek cyklicznych szkoleń kierownictwa i pracowników z higieny cyfrowej, natomiast AI Act (art. 4) nakazuje zapewnienie odpowiedniego poziomu alfabetyzacji cyfrowej personelu nadzorującego modele AI (AI literacy).
- Weryfikacja łańcucha dostawców – w zamówieniach publicznych urząd musi weryfikować zarówno cyberbezpieczeństwo dostawcy oprogramowania (zgodnie z NIS2), jak i poprawność dokumentacji technicznej, certyfikacji CE i deklaracji zgodności modelu AI (zgodnie z AI Act).
- Reagowanie na incydenty – cyberatak na system AI (np. zatrucie danych treningowych lub przełamanie zabezpieczeń) wymaga równoległego uruchomienia ścieżki zgłoszenia do CSIRT w schemacie NIS2 oraz raportowania do organu nadzoru nad rynkiem AI w przypadku wystąpienia poważnego incydentu (art. 73 AI Act).
Harmonogram: kluczowe daty i tabela obowiązków
Wdrażanie obu regulacji w administracji publicznej wymaga koordynacji terminów unijnych z przepisami prawa krajowego. Poniższe zestawienie syntetyzuje kluczowe obowiązki jednostki administracji wraz z ich podstawami prawnymi i aktualnym stanem wdrożenia:
Obowiązek | Podstawa prawna | Termin i status (UE / PL) |
|---|---|---|
| Samorejestracja w krajowym Wykazie podmiotów KSC | Ustawa o KSC (nowelizacja 2026 r.) implementująca NIS2 | Do 3 października 2026 r. (dla podmiotów podlegających ustawie od momentu jej wejścia w życie 03.04.2026 r.) |
| Pełne wdrożenie środków zarządzania ryzykiem cyberbezpieczeństwa (SZBI, polityki, ciągłość działania) | NIS2 – art. 21; znowelizowana ustawa o KSC | Wymóg formalny od wejścia w życie ustawy (03.04.2026 r.); termin na pełne dostosowanie systemów upływa 3 kwietnia 2027 r. |
| Zgłaszanie incydentów cyberbezpieczeństwa do właściwego CSIRT w reżimie 24h / 72h / 1 mies. | NIS2 – art. 23; znowelizowana ustawa o KSC | Obowiązuje od wejścia w życie znowelizowanej ustawy o KSC (od 03.04.2026 r.). |
| Eliminacja systemów zakazanych oraz szkolenia personelu z wiedzy o AI (AI literacy) | AI Act – art. 4, art. 5 | Obowiązuje od 2 lutego 2025 r. (pełna egzekwowalność w całej UE). |
| Wdrożenie wymogów dla systemów wysokiego ryzyka (Załącznik III) – nadzór, logowanie, zarządzanie ryzykiem | AI Act – tytuł III (art. 9, art. 12–20, art. 26) | Obowiązuje od 2 sierpnia 2026 r. (dla systemów AI wbudowanych w produkty regulowane sektorowo: od 02.08.2027 r.). |
| Przeprowadzenie Oceny Skutków dla Praw Podstawowych (FRIA) przed wdrożeniem systemu AI wysokiego ryzyka | AI Act – art. 27 | Obowiązkowe dla organów publicznych przed uruchomieniem każdego systemu wysokiego ryzyka od 2 sierpnia 2026 r. |
| Rejestracja systemu wysokiego ryzyka w unijnej bazie danych (EU Database) | AI Act – art. 71 w zw. z art. 49 | Obowiązkowe dla deployerów publicznych od momentu produkcyjnego wdrożenia systemu po 2 sierpnia 2026 r. |
| Raportowanie poważnych incydentów AI do właściwego organu nadzoru rynku | AI Act – art. 26 ust. 5 i art. 73 | Obowiązuje od 2 sierpnia 2026 r. (zgłoszenie natychmiast, maksymalnie w ciągu 15 dni od powzięcia wiedzy, w sytuacjach krytycznych w 2–10 dni). |
Jak praktycznie wykorzystać tę mapę w administracji
Zamiast budować dwa odrębne silosy compliance, optymalnym podejściem w administracji jest wdrożenie zasady „zmapuj raz, spełnij wiele wymogów” (map once, comply many). W praktyce obejmuje to następujące kroki:
- Zintegrowana inwentaryzacja zasobów cyfrowych – połączenie rejestru aktywów IT/OT pod kątem KSC/NIS2 z wykazem algorytmów i systemów opartych na AI, ze szczególnym wskazaniem rozwiązań kwalifikujących się do Załącznika III AI Act.
- Wspólna metodyka analizy ryzyka – rozbudowanie wdrożonego Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) o moduł oceny ryzyka algorytmicznego oraz formularze Oceny Skutków dla Praw Podstawowych (FRIA).
- Zintegrowany proces obsługi incydentów (IRP) – stworzenie jednej procedury reagowania, w której incident response triage automatycznie kwalifikuje, czy dany incydent wymaga notyfikacji do CSIRT w oknie 24h (NIS2), czy powiadomienia organu nadzoru nad sztuczną inteligencją (AI Act).
- Klauzule umowne i audyt dostawców – ujednolicenie wymagań przetargowych i umów SLA z dostawcami oprogramowania, uwzględniających zarówno rygory bezpieczeństwa łańcucha dostaw (NIS2), jak i obowiązki w zakresie dostarczenia dokumentacji technicznej i logów (AI Act).
- Scentralizowane programy szkoleniowe – realizacja wspólnych modułów szkoleniowych z zakresu cyberbezpieczeństwa oraz bezpiecznego i etycznego wykorzystywania narzędzi AI dla urzędników i kadry kierowniczej.
Zintegrowane podejście minimalizuje obciążenie administracyjne, zapobiega powielaniu dokumentacji i pozwala zbudować stabilne środowisko bezpiecznych cyfrowych usług publicznych.
