Cross-mapping NIS2, AI Act, RODO, ISO 27001 bez dublowania

Czas czytania: ok. 10 minut. Klaster: compliance. Autor: Fryderyk.

Odpowiedź najpierw

Cztery reżimy, jeden zestaw dowodów. NIS2 (w Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązująca od 3 kwietnia 2026), AI Act, RODO i ISO 27001 nakładają na producenta wdrażającego AI wymagania, które w dużej mierze się pokrywają. Jedna porządna analiza ryzyka odpowiada jednocześnie na NIS2 Art. 21, AI Act art. 9, RODO art. 35 i klauzulę 6.1 ISO. Jedna umowa z dostawcą z właściwymi klauzulami domyka łańcuch dostaw NIS2, obowiązki z AI Act i powierzenie z RODO. Praktyczny wniosek: nie prowadź czterech osobnych projektów compliance. Zbuduj jeden zestaw kontroli i dowodów, a potem zmapuj każdy z nich na cztery reżimy. Pracujesz kontrolami, nie ustawami. Poniżej tabela cross-mappingu i miejsca, w których reżimy naprawdę się rozjeżdżają, bo tych nie wolno przeoczyć.

Spis treści

1. Dlaczego cztery reżimy pytają o to samo
2. Tabela cross-mappingu: dziewięć obszarów
3. Trzy nakładki, które robią największą różnicę
4. Gdzie reżimy się rozjeżdżają
5. Jak to poukładać w praktyce
6. Terminy: co obowiązuje w 2026
7. FAQ
8. Disclosure i biases
9. Czego tu nie pokrywam
10. Powiązane notatki

Dlaczego cztery reżimy pytają o to samo

Producent wdrażający AI w Polsce trafia w co najmniej cztery reżimy naraz. NIS2, transponowana nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa, obejmuje go jako podmiot kluczowy lub ważny. AI Act klasyfikuje część zastosowań AI jako wysokiego ryzyka. RODO obowiązuje wszędzie, gdzie w grę wchodzą dane osobowe. ISO 27001 zwykle nie jest wymagana ustawowo, ale bywa oczekiwana kontraktowo i jest najwygodniejszym szkieletem, na którym da się poukładać resztę.

Naturalna reakcja to potraktowanie każdego reżimu jako osobnego projektu z własnym zespołem, własnym harmonogramem i własnym kompletem dokumentów. To najdroższy możliwy wariant, bo cztery reżimy w warstwie technicznej pytają w większości o to samo: czy przeprowadziłeś analizę ryzyka, czy panujesz nad dostawcami, czy wykrywasz i zgłaszasz incydenty, czy kontrolujesz dostęp, czy logujesz, czy szyfrujesz, czy masz ciągłość działania i czy ktoś na właściwym poziomie za to odpowiada.

Różnią się słownikiem, numeracją artykułów i akcentem, ale nie fundamentem. Analiza ryzyka zrobiona raz, porządnie i udokumentowana, jest tym samym dowodem dla audytora NIS2, dla oceny zgodności AI Act i dla ISO. Dlatego opłaca się myśleć kontrolami, a nie ustawami: zdefiniować zestaw kontroli, wdrożyć je raz i zmapować na cztery reżimy.

Tabela cross-mappingu: dziewięć obszarów

Poniżej dziewięć obszarów kontrolnych, które powtarzają się we wszystkich czterech reżimach, z odniesieniami do konkretnych artykułów i kontroli. Numeracja AI Act odnosi się do obowiązków systemów wysokiego ryzyka.

Obszar kontrolny	NIS2 / UKSC (Art. 21)	AI Act (system wysokiego ryzyka)	RODO	ISO 27001:2022
Analiza i zarządzanie ryzykiem	Art. 21 ust. 2 lit. a	Art. 9 (system zarządzania ryzykiem)	Art. 35 (DPIA)	Klauzula 6.1, obszar A.5
Bezpieczeństwo łańcucha dostaw i dostawcy	Art. 21 ust. 2 lit. d	Art. 25, 26 (dostawca i podmiot stosujący)	Art. 28 (umowa powierzenia)	A.5.19 do A.5.23
Obsługa i zgłaszanie incydentów	Art. 21 ust. 2 lit. b, Art. 23	Art. 73 (poważne incydenty)	Art. 33, 34 (naruszenia)	A.5.24 do A.5.28
Kontrola dostępu i uwierzytelnianie	Art. 21 ust. 2 lit. i, j (MFA)	Art. 15 (cyberbezpieczeństwo)	Art. 32	A.5.15 do A.5.18
Logowanie i monitorowanie	Art. 21 (wykrywanie zdarzeń)	Art. 12 (rejestrowanie zdarzeń)	Art. 32	A.8.15, A.8.16
Kryptografia i ochrona danych	Art. 21 ust. 2 lit. h	Art. 15	Art. 32 ust. 1 lit. a	A.8.24
Ciągłość działania i kopie zapasowe	Art. 21 ust. 2 lit. c	Art. 15 (odporność)	Art. 32 ust. 1 lit. b, c	A.5.29, A.5.30
Dokumentacja i rejestry	Dokumentacja SZBI	Art. 11, Załącznik IV	Art. 30 (rejestr czynności)	Klauzula 7.5
Nadzór człowieka i odpowiedzialność	Art. 20 (odpowiedzialność kierownictwa)	Art. 14 (nadzór człowieka)	Art. 22 (decyzje zautomatyzowane)	A.5.2 do A.5.4

Kolumna po kolumnie widać ten sam wzorzec: różne przepisy, jedno pytanie kontrolne. To jest cała idea cross-mappingu. Zamiast dziewięciu razy cztery, czyli trzydziestu sześciu zadań, masz dziewięć kontroli, każda udokumentowana raz i pokazana z czterech stron.

Trzy nakładki, które robią największą różnicę

Nie wszystkie wiersze tabeli ważą tyle samo. Trzy obszary dają największy zwrot z jednej pracy, bo są jednocześnie najczęściej audytowane i najbardziej pracochłonne, jeśli robić je osobno.

Analiza ryzyka. To najczystszy przykład jednej pracy na cztery reżimy. NIS2 wymaga środków zarządzania ryzykiem, AI Act każe prowadzić system zarządzania ryzykiem przez cały cykl życia systemu wysokiego ryzyka, RODO dla operacji o wysokim ryzyku dla osób wymaga oceny skutków, a ISO stawia ocenę ryzyka w centrum systemu zarządzania bezpieczeństwem informacji. Jeśli zbudujesz jedną analizę ryzyka dla wdrożenia AI, która pokrywa zagrożenia dla bezpieczeństwa systemu, dla praw osób i dla ciągłości procesu, jednym dokumentem odpowiadasz na cztery wymagania. Warunek: analiza musi realnie obejmować te trzy warstwy, a nie być kopią szablonu z jednego reżimu.

Łańcuch dostaw i umowa z dostawcą. Drugi obszar wysokiego zwrotu. NIS2 wprost obejmuje bezpieczeństwo łańcucha dostaw, AI Act rozkłada obowiązki między dostawcę systemu i podmiot go stosujący, RODO wymaga umowy powierzenia z każdym podmiotem przetwarzającym, a ISO ma osobny blok kontroli dostawców. Jedna dobrze skonstruowana umowa, MSA plus DPA, z klauzulami o zakresie przetwarzania, podwykonawcach, zabezpieczeniach, prawie do audytu i warunkach wyjścia, domyka wszystkie cztery. Pisałem o samych klauzulach w notatce o DPA dla AI vendora.

Logowanie i incydenty. Trzeci obszar. Zdolność do wykrycia, opisania i zgłoszenia incydentu wynika z logów. Ten sam mechanizm logowania i ta sama procedura reagowania obsługują obowiązek zgłoszeniowy NIS2 wobec CSIRT, zgłoszenie poważnego incydentu z AI Act, notyfikację naruszenia z RODO i kontrole incydentowe ISO. Różnią się progi i terminy, ale infrastruktura jest jedna. Więcej o tym, co konkretnie logować w systemie AI uruchomionym lokalnie, jest w notatce o observability dla on-prem LLM.

Gdzie reżimy się rozjeżdżają

Cross-mapping jest potężny, ale ma granicę. Kilka wymagań nie mapuje się na nic w pozostałych reżimach i próba ich zlania tylko generuje ryzyko. Te trzeba obsłużyć osobno.

Terminy zgłaszania są różne i nie da się ich uśrednić. NIS2 wprowadza wieloetapowy tryb, z wczesnym ostrzeżeniem w ciągu 24 godzin i pełniejszym zgłoszeniem w ciągu 72 godzin do właściwego CSIRT. RODO ma swoje 72 godziny na zgłoszenie naruszenia do organu nadzorczego, ale liczone od innego momentu i wobec innego adresata. AI Act ma własny reżim zgłaszania poważnych incydentów. To jedno zdarzenie może uruchomić trzy różne zegary do trzech różnych instytucji. Procedura incydentowa musi to rozpoznawać, a nie zakładać jeden termin.

Wymagania specyficzne dla AI nie mają odpowiednika w NIS2, RODO ani ISO. Nadzór człowieka w rozumieniu AI Act, jakość i reprezentatywność danych treningowych, dokładność i odporność modelu oraz obowiązki informacyjne wobec użytkownika to wymagania, których nie zdejmiesz z półki cyberbezpieczeństwa. Cross-mapping tu nie pomoże, bo nie ma czego mapować. Te obszary wymagają odrębnej pracy przy systemach zakwalifikowanych jako wysokiego ryzyka. O samej klasyfikacji jest osobna notatka: AI Act w produkcji i klasyfikacja high-risk.

Podstawa prawna i prawa osób to wyłączna domena RODO. Zgodność z NIS2 czy ISO nie mówi nic o tym, czy masz podstawę do przetwarzania danych osobowych ani jak realizujesz prawa osób. To warstwa, która żyje własnym życiem i nie da się jej wyprowadzić z kontroli bezpieczeństwa.

Jak to poukładać w praktyce

Kolejność, która się sprawdza, jest odwrotna do intuicyjnej. Nie zaczynasz od czytania czterech aktów prawnych równolegle, tylko od zdefiniowania zestawu kontroli.

Najpierw ustal listę kontroli, mniej więcej tych dziewięć z tabeli plus wymagania specyficzne dla AI, jeśli system jest wysokiego ryzyka. Dla każdej kontroli zdefiniuj jeden dowód, czyli konkretny artefakt: analiza ryzyka, umowa, mapa przepływu danych, polityka logowania, procedura incydentowa. Dopiero potem zmapuj każdy dowód na odpowiednie artykuły czterech reżimów, budując prostą macierz zgodności. Ta macierz jest jednocześnie twoją mapą i twoim dowodem gotowości do audytu.

Zaletą tego podejścia jest odporność na zmiany. Gdy pojawia się piąty reżim albo zmienia się numeracja w którymś akcie, nie przerabiasz całego compliance. Dodajesz kolumnę do macierzy i sprawdzasz, które istniejące dowody ją pokrywają, a które luki trzeba domknąć. To znacznie tańsze niż utrzymywanie czterech równoległych obiegów dokumentów, które nikt nie synchronizuje. Ten sposób myślenia rozwijam w ściądze mapowania NIS2 plus AI na konkretne kontrole.

ISO 27001 warto tu potraktować jako szkielet organizujący. Jej system zarządzania bezpieczeństwem informacji jest na tyle ogólny, że pozostałe reżimy dają się na nim zawiesić jako wymagania szczegółowe. Jeśli już masz lub budujesz ISMS, dopięcie do niego NIS2 i warstwy AI jest tańsze niż start od zera.

Terminy: co obowiązuje w 2026

Cross-mapping działa tylko wtedy, gdy operujesz aktualnymi datami, a te w 2026 są ruchome.

NIS2 w Polsce weszła w życie przez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa, która zaczęła obowiązywać 3 kwietnia 2026. Podmioty spełniające kryteria mają czas na złożenie wniosku o wpis do właściwego wykazu do 3 października 2026, a na pełne wdrożenie obowiązków systemu zarządzania bezpieczeństwem informacji do 3 kwietnia 2027. Skala jest inna niż wcześniej: reżim obejmie rząd wielkości kilkudziesięciu tysięcy polskich firm, a nie kilkuset jak przed nowelizacją.

AI Act został w tym roku istotnie przesunięty w czasie. Pakiet upraszczający, znany jako Digital Omnibus, przełożył start obowiązków dla systemów wysokiego ryzyka z Załącznika III z sierpnia 2026 na 2 grudnia 2027, a dla AI wbudowanej w produkty regulowane z Załącznika I na 2 sierpnia 2028. Uwaga na częsty błąd: to nie znaczy, że wszystko się odroczyło. Obowiązki przejrzystości z art. 50, na przykład oznaczanie treści generowanych przez AI, wchodzą zgodnie z pierwotnym kalendarzem od 2 sierpnia 2026. Odroczenie dotyczy warstwy wysokiego ryzyka, nie całego aktu.

RODO jest stabilne i obowiązuje bez zmian. ISO 27001 w aktualnym wydaniu z 2022 roku ma nową strukturę Załącznika A z czterema obszarami kontroli, a okres przejściowy z wersji z 2013 roku już się zakończył, więc certyfikaty i mapowania powinny odnosić się do wydania 2022.

Ponieważ daty AI Act zmieniały się w tym roku kilkukrotnie, przed decyzjami warto zweryfikować aktualny stan publikacji aktu zmieniającego w Dzienniku Urzędowym UE.

FAQ

Czy muszę prowadzić cztery osobne projekty compliance?

Nie. W warstwie technicznej NIS2, AI Act, RODO i ISO 27001 pytają w większości o te same kontrole. Efektywniej jest zbudować jeden zestaw kontroli i dowodów, a potem zmapować go na cztery reżimy w jednej macierzy zgodności.

Od czego zacząć, jeśli mam już ISO 27001?

Od potraktowania ISMS jako szkieletu. Pozostałe reżimy dopinasz jako wymagania szczegółowe do istniejących kontroli. To tańsze niż budowanie równoległych struktur.

Czego cross-mapping nie załatwi?

Terminów zgłaszania incydentów, bo są różne dla NIS2, RODO i AI Act. Wymagań specyficznych dla AI, takich jak nadzór człowieka, jakość danych czy dokładność modelu. Oraz podstawy prawnej i praw osób, które są wyłączną domeną RODO.

Czy odroczenie AI Act oznacza, że mam czas do 2027?

Tylko dla obowiązków systemów wysokiego ryzyka. Obowiązki przejrzystości z art. 50 obowiązują od 2 sierpnia 2026 niezależnie od odroczenia.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad wdrożeniami AI uruchamianymi poza chmurą publiczną, więc naturalnie akcentuję kontrolę nad przepływem danych i architekturę on-prem. Starałem się oddzielić treść przepisów od preferencji architektonicznej. Ten tekst nie jest opinią prawną. Mapowanie między reżimami jest uproszczeniem redakcyjnym: pojedynczy artykuł bywa realizowany przez wiele kontroli i odwrotnie, a interpretacja zależy od sektora i stanu faktycznego. Praktyka audytowa dla NIS2 i AI Act dopiero się kształtuje. Przed decyzjami compliance skonsultuj się z prawnikiem specjalizującym się w cyberbezpieczeństwie i ochronie danych.

// co tu nie pokrywamCzego tu nie pokrywam

Nie podaję pełnego mapowania wszystkich kontroli Załącznika A ISO ani wszystkich ustępów czterech aktów, bo to materiał na dokument roboczy, nie na notatkę. Nie wchodzę w reżimy sektorowe, na przykład DORA dla finansów czy wymagania dla wyrobów, które mogą nakładać dodatkowe obowiązki. Pomijam krajowe akty wykonawcze do ustawy o krajowym systemie cyberbezpieczeństwa, które będą doprecyzowywać szczegóły. Nie omawiam też operacyjnej strony samego zgłaszania incydentu do CSIRT ani technicznej warstwy zabezpieczeń modelu, które zasługują na osobne notatki.

Powiązane notatki

• AI Act w produkcji: klasyfikacja high-risk i co to znaczy dla wdrożenia
• ISO 27001 a AI vendor: trzy kontrole, które warto zmapować dziś
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem
• NIS2 plus AI: mapowanie Art. 21 na konkretne kontrole, jedna ściąga
• DPA dla AI vendora: 8 klauzul, których brak wywróci audyt