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

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

Odpowiedź najpierw

Cztery reżimy, jeden zestaw dowodów, a od jesieni 2026 piąty reżim dla tych, którzy sami wytwarzają produkty z oprogramowaniem. 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 warstwie technicznej 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 jest ten sam co w krótszej notatce, od której zaczął się ten materiał: nie prowadź czterech osobnych projektów compliance. Zbuduj jeden zestaw kontroli i dowodów, przypisz każdej kontroli jeden artefakt, a potem zmapuj każdy artefakt na cztery reżimy w jednej macierzy zgodności. Pracujesz kontrolami, nie ustawami. Ten tekst rozwija tę zasadę do poziomu przewodnika: pełniejsza tabela z kontrolami ISO Załącznika A, wzorzec dowodu per kontrola, warstwa reżimów sektorowych (CRA i DORA) oraz miejsca, w których reżimy naprawdę się rozjeżdżają, bo tych zlać się nie da.

Spis treści

1. Dlaczego reżimy pytają o to samo
2. Zasada: kontrola, dowód, mapowanie
3. Tabela cross-mappingu: dziewięć obszarów i kontrole ISO
4. Dowód per kontrola: jeden artefakt, cztery reżimy
5. Trzy nakładki o największym zwrocie
6. Reżimy sektorowe: CRA i DORA jako piąta i szósta kolumna
7. Gdzie reżimy się rozjeżdżają: cztery zegary i wyłączne domeny
8. Macierz zgodności: jak ją zbudować i utrzymać
9. Terminy: co obowiązuje, a co się przesuwa w 2026 i 2027
10. FAQ
11. Disclosure i biases
12. Czego tu nie pokrywam
13. Powiązane notatki

Dlaczego 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 wszystkie reżimy, które akurat na ciebie patrzą.

Zasada: kontrola, dowód, mapowanie

Zanim przejdziemy do tabeli, warto nazwać trzy pojęcia, bo cały materiał się na nich opiera i mylenie ich jest źródłem większości podwójnej pracy.

Kontrola to zabezpieczenie organizacyjne lub techniczne, na przykład zarządzanie ryzykiem, kontrola dostępu, logowanie. Kontrola jest niezależna od reżimu, bo dobra higiena bezpieczeństwa wygląda tak samo bez względu na to, który akt prawny o nią pyta.

Dowód to konkretny artefakt, który pokazujesz audytorowi, że kontrola działa: dokument analizy ryzyka, podpisana umowa, mapa przepływu danych, wyeksportowany log, wypełniony rejestr. Audytora nie interesuje deklaracja, tylko artefakt.

Mapowanie to przypisanie dowodu do artykułów w każdym reżimie. To jedyna warstwa, która jest specyficzna dla przepisu, i jedyna, którą przerabiasz, gdy przepis się zmienia. Kontrolę wdrażasz raz, dowód wytwarzasz raz, mapowanie aktualizujesz w miarę potrzeb. Ta separacja jest różnicą między compliance, które skaluje się na piąty i szósty reżim, a compliance, które przy każdym nowym akcie trzeba budować od nowa.

Tabela cross-mappingu: dziewięć obszarów i kontrole ISO

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, a kolumna ISO wskazuje kontrole Załącznika A wydania 2022.

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, A.5.1
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, A.8.5
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, A.8.13
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. Kontrole ISO Załącznika A działają tu jak wspólny mianownik, bo są najbardziej granularne i najłatwiej podpiąć pod nie wymagania pozostałych reżimów niż odwrotnie.

Dowód per kontrola: jeden artefakt, cztery reżimy

Tabela pokazuje, gdzie reżimy się spotykają. Trzeba iść krok dalej i powiedzieć, co konkretnie kładziesz na stole audytora dla każdej kontroli. Poniżej wzorzec: jedna kontrola, jeden podstawowy dowód, który zaspokaja wszystkie cztery reżimy naraz.

Dla analizy ryzyka dowodem jest jeden dokument oceny ryzyka wdrożenia AI, obejmujący zagrożenia dla bezpieczeństwa systemu, dla praw osób i dla ciągłości procesu. Jeśli realnie pokrywa te trzy warstwy, jest jednocześnie środkiem z NIS2, systemem zarządzania ryzykiem z AI Act, oceną skutków z RODO i wejściem do planu postępowania z ryzykiem ISO.

Dla łańcucha dostaw dowodem jest komplet umowny z dostawcą, czyli MSA plus DPA, z klauzulami o zakresie przetwarzania, podwykonawcach, zabezpieczeniach, prawie do audytu i warunkach wyjścia. Ten jeden komplet domyka ocenę łańcucha dostaw NIS2, podział ról z AI Act, powierzenie z RODO i blok kontroli dostawców ISO.

Dla incydentów dowodem jest procedura reagowania plus konfiguracja logowania, z której wynika zdolność wykrycia i opisania zdarzenia. Jedna procedura obsługuje zgłoszenie do CSIRT z NIS2, zgłoszenie poważnego incydentu z AI Act, notyfikację naruszenia z RODO i kontrole incydentowe ISO, choć, jak pokażę niżej, terminy trzeba w niej rozdzielić.

Dla kontroli dostępu dowodem jest polityka dostępu plus dowód wdrożenia MFA i przeglądu uprawnień. Dla logowania to polityka logowania plus przykładowy eksport z retencją. Dla kryptografii to polityka szyfrowania plus rejestr, co i gdzie jest szyfrowane. Dla ciągłości to plan ciągłości plus dowód testu odtworzenia. Dla dokumentacji to zestaw rejestrów, w tym rejestr czynności przetwarzania i dokumentacja techniczna systemu AI. Dla nadzoru człowieka to opis mechanizmu przeglądu decyzji plus przypisanie odpowiedzialności na poziomie kierownictwa.

Dziewięć kontroli, dziewięć podstawowych dowodów. To jest realna lista rzeczy do wytworzenia, a nie cztery równoległe segregatory. Więcej o samym zestawie dokumentów, które produkujesz przed audytorem, jest w notatce o audit readiness NIS2 plus AI.

Trzy nakładki o największym zwrocie

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. Warunek jest jeden: analiza musi realnie obejmować 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 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.

Reżimy sektorowe: CRA i DORA jako piąta i szósta kolumna

Cztery reżimy z tabeli to wspólny mianownik dla większości producentów. Część z nich wpada dodatkowo w reżimy sektorowe, które nakładają własne kontrole i, co ważniejsze, własne zegary zgłoszeniowe. Dwa warto znać, bo dotykają producentów bezpośrednio.

CRA, czyli akt o cyberodporności. To piąty reżim dla każdego, kto sam wytwarza produkty z elementami cyfrowymi, a nie tylko wdraża cudze AI. Producent maszyny ze sterownikiem, urządzenia z oprogramowaniem czy komponentu z modułem łączności staje się w rozumieniu CRA producentem produktu z elementami cyfrowymi. Kluczowa różnica wobec NIS2: NIS2 patrzy na ciebie jako na podmiot, który używa systemów, a CRA patrzy na ciebie jako na producenta, który wprowadza produkt do obrotu. To dwie różne role i dwa różne komplety obowiązków, które mogą spaść na tę samą firmę.

Od 11 września 2026 rusza obowiązek raportowania w CRA. Producent zgłasza aktywnie wykorzystywaną podatność oraz poważny incydent do ENISA i właściwego CSIRT przez jedną platformę zgłoszeniową, w trybie wieloetapowym: wczesne ostrzeżenie w ciągu 24 godzin, pełniejsze zgłoszenie w ciągu 72 godzin, a raport końcowy dla podatności w ciągu 14 dni od udostępnienia środka naprawczego. Pełne obowiązki produktowe CRA zaczynają obowiązywać od 11 grudnia 2027. Obszary kontrolne CRA, zarządzanie podatnościami, bezpieczeństwo w cyklu życia, dokumentacja techniczna, w dużej mierze pokrywają się z tym, co masz już w tabeli, więc CRA dokłada głównie nowy zegar i nowego adresata, nie nowy fundament.

DORA, czyli reżim dla sektora finansowego. Obowiązuje od 17 stycznia 2025 i dotyczy podmiotów finansowych oraz dostawców ICT, którzy im usługują. Dla typowego producenta DORA nie jest reżimem własnym, ale bywa nim pośrednio, gdy sprzedajesz komponent lub usługę do banku czy ubezpieczyciela i twoja umowa musi spełnić wymagania DORA wobec dostawców krytycznych. Nie forsuj DORA do głównej macierzy, jeśli nie jesteś w łańcuchu finansowym, bo tylko dodasz kolumnę, której nikt nie audytuje.

Wniosek jest taki, że reżimy sektorowe nie łamią zasady kontrola, dowód, mapowanie. Dokładasz kolumnę do macierzy, sprawdzasz, które istniejące dowody ją pokrywają, i domykasz to, co specyficzne, na przykład zarządzanie podatnościami produktu przy CRA. O tym, że warstwa produktowa i warstwa operatorska to dwie różne role wobec tego samego prawa, piszę też przy okazji art. 50 AI Act i własnego LLM.

Gdzie reżimy się rozjeżdżają: cztery zegary i wyłączne domeny

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ć. Jedno zdarzenie może uruchomić kilka niezależnych zegarów do różnych instytucji. NIS2 wprowadza tryb wieloetapowy, 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, liczone od innego momentu i wobec innego adresata. AI Act ma własny reżim zgłaszania poważnych incydentów. CRA, jeśli cię obejmuje jako producenta produktu, dokłada czwarty tryb: 24 godziny, 72 godziny, 14 dni, do ENISA i CSIRT. Ten sam wyciek może więc oznaczać cztery zgłoszenia do czterech adresatów w różnych terminach. Procedura incydentowa musi to rozpoznawać i rozgałęziać, a nie zakładać jeden termin.

Wymagania specyficzne dla AI nie mają odpowiednika w NIS2, RODO, ISO ani CRA. 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, ISO czy CRA 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.

Macierz zgodności: jak ją zbudować i utrzymać

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

Macierz to arkusz, w którym wiersze to kontrole, a kolumny to kolejno: nazwa dowodu, właściciel, status, data przeglądu, a potem po jednej kolumnie na każdy reżim z odniesieniem do artykułu. Najpierw ustal listę kontroli, mniej więcej tych dziewięć z tabeli plus wymagania specyficzne dla AI, jeśli system jest wysokiego ryzyka, plus wiersze CRA, jeśli wytwarzasz produkty z oprogramowaniem. Dla każdej kontroli wpisz jeden dowód i jego właściciela. Dopiero potem uzupełnij kolumny reżimowe. Ta macierz jest jednocześnie twoją mapą i twoim dowodem gotowości do audytu, bo audytorowi dowolnego reżimu pokazujesz jego kolumnę i stojące za nią artefakty.

Zaletą tego podejścia jest odporność na zmiany. Gdy pojawia się nowy reżim albo zmienia się numeracja w którymś akcie, nie przerabiasz całego compliance. Dodajesz kolumnę i sprawdzasz, które istniejące dowody ją pokrywają, a które luki trzeba domknąć. To znacznie tańsze niż utrzymywanie równoległych obiegów dokumentów, których 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, warstwy AI i CRA jest tańsze niż start od zera. Które trzy kontrole ISO zmapować najpierw, opisuję w notatce o ISO 27001 a AI vendor.

Gotowa macierz do pobrania

Zamiast budować arkusz od zera, możesz zacząć od gotowego szablonu. Macierz zgodności w formacie arkusza zawiera 14 kontroli zmapowanych na NIS2, AI Act, RODO, ISO 27001 i CRA, osobną zakładkę z czterema zegarami zgłoszeniowymi oraz kalendarz kluczowych terminów na lata 2026 do 2028. Wypełniasz kolumny właściciela, statusu i daty przeglądu, a licznik postępu liczy się automatycznie. To ten sam szkielet, który opisuję powyżej, gotowy do użycia. Pobierz macierz zgodności w formacie XLSX.

Terminy: co obowiązuje, a co się przesuwa w 2026 i 2027

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, z krótszym okresem przejściowym na sam watermarking dla systemów będących już na rynku. Odroczenie dotyczy warstwy wysokiego ryzyka, nie całego aktu.

CRA dokłada nowy termin, którego wcześniej w tej układance nie było. Od 11 września 2026 obowiązuje raportowanie aktywnie wykorzystywanych podatności i poważnych incydentów do ENISA i CSIRT, a pełne obowiązki produktowe wchodzą 11 grudnia 2027. Jeśli wytwarzasz produkty z oprogramowaniem, ten zegar dotyczy cię niezależnie od NIS2.

RODO jest stabilne i obowiązuje bez zmian. DORA obowiązuje od 17 stycznia 2025 dla sektora finansowego i jego dostawców ICT. 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ć osobne projekty compliance dla każdego reżimu?

Nie. W warstwie technicznej NIS2, AI Act, RODO, ISO 27001, a często też CRA pytają w większości o te same kontrole. Efektywniej jest zbudować jeden zestaw kontroli i dowodów, a potem zmapować go na wszystkie 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.

Czym CRA różni się od NIS2, skoro oba dotyczą cyberbezpieczeństwa?

Rolą, w jakiej cię widzą. NIS2 patrzy na ciebie jako podmiot, który używa systemów i świadczy usługi. CRA patrzy na ciebie jako producenta, który wprowadza do obrotu produkt z elementami cyfrowymi. Ta sama firma może podlegać obu, w dwóch różnych rolach, z dwoma kompletami obowiązków.

Ile zegarów zgłoszeniowych może uruchomić jeden incydent?

Nawet cztery: NIS2 (24 h i 72 h do CSIRT), RODO (72 h do organu nadzorczego), AI Act (poważne incydenty) i CRA (24 h, 72 h, 14 dni do ENISA i CSIRT). Terminy i adresaci są różne, więc procedura incydentowa musi je rozgałęziać.

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.

Czego cross-mapping nie załatwi?

Terminów zgłaszania incydentów, bo są różne. 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.

// 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 możliwość zaudytowania zależności. 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, AI Act i CRA 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 aktów, bo to materiał na macierz roboczą, nie na jeden tekst. Nie wchodzę głębiej w reżimy sektorowe poza sygnalizacją CRA i DORA, bo każdy z nich zasługuje na osobny materiał. 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 prowadzę w osobnych notatkach.

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