NIS-2 + AI Act — wspólny stack compliance. Risk register, DPIA, FRIA

Dwa frameworki, jeden stack — bo fundamenty się pokrywają

NIS-2 i AI Act trafiły do polskiego MŚP w odstępie dwóch lat — pierwsza z terminem transpozycji 17 października 2024, druga z głównym terminem sierpień 2026. Naturalna pokusa — traktować je jako dwa oddzielne projekty, dwa zespoły, dwa zestawy dokumentacji. Naturalny błąd.

Oba rozporządzenia opierają się na tych samych fundamentach — zarządzaniu ryzykiem, monitoringu, dokumentacji, incident response, governance. Te fundamenty są wymagane też przez RODO (art. 35 DPIA), przez DORA dla sektora finansowego, przez ISO 27001 jako standard branżowy. Budowanie pięciu osobnych stacków zamiast jednego z wieloma widokami to mnożenie kosztów bez wartości compliance.

W tym artykule pokazujemy, gdzie NIS-2 i AI Act faktycznie się pokrywają, gdzie wymagają osobnych artefaktów (DPIA, FRIA), i jak zbudować shared compliance stack, który obsługuje oba frameworki naraz. Cel — jeden risk register, jeden process monitoringu, jeden cykl audytu.

Cztery punkty wspólne

Zarządzanie ryzykiem — NIS-2 art. 21 vs AI Act art. 9

Art. 21 NIS-2 wymaga od podmiotów kluczowych i ważnych wdrożenia „odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych do zarządzania ryzykiem dla bezpieczeństwa sieci i systemów informatycznych”. Lista minimum w ust. 2 obejmuje politykę analizy ryzyka, obsługę incydentów, business continuity, security supply chain, security w pozyskiwaniu i utrzymywaniu systemów, ocenę skuteczności środków, podstawowe praktyki cyber-hygieny i szkolenia, kryptografię, kontrolę dostępu i zarządzanie aktywami.

Art. 9 AI Act dla systemów high-risk wymaga „systemu zarządzania ryzykiem” — udokumentowanego, ciągłego, iteracyjnego procesu obejmującego identyfikację, estymację, ewaluację i ograniczanie ryzyk znanych i przewidywalnych przez cały cykl życia systemu.

Punkty wspólne: ciągły charakter procesu (nie jednorazowy dokument), iteracyjność, wymóg dokumentacji, połączenie z monitoringiem operacyjnym, integracja z dostawcami (supply chain w NIS-2, dane treningowe i komponenty third-party w AI Act).

Różnice: NIS-2 koncentruje się na ryzyku dla sieci i systemów; AI Act — na ryzyku dla praw podstawowych, zdrowia, bezpieczeństwa wynikającym z konkretnego systemu AI. W praktyce risk register potrzebuje dwóch widoków na te same zasoby — z perspektywy cyber i z perspektywy AI impact.

Monitoring — NIS-2 art. 21 ust. 2 vs AI Act art. 72

NIS-2 wymaga monitoringu skuteczności środków zarządzania ryzykiem (art. 21 ust. 2 lit. f). AI Act art. 72 nakłada na providera high-risk obowiązek post-market monitoringu — udokumentowanego systemu, który aktywnie zbiera, dokumentuje i analizuje dane o wydajności systemu AI przez cały okres jego życia.

Wspólne: aktywny, ciągły monitoring; obowiązek dokumentacji wyników; obowiązek aktualizacji środków na podstawie obserwacji.

Praktyka stacka: jeden zestaw narzędzi observability (logi, metryki, traces, alerty) z dwoma osobnymi dashboardami — security operations dla NIS-2 i AI performance/drift dla AI Act. Ten sam SIEM, ten sam datalake, dwa widoki.

Dokumentacja — NIS-2 vs AI Act art. 11 + Aneks IV

NIS-2 wymaga dokumentacji środków zarządzania ryzykiem (pośrednio z art. 21 w połączeniu z art. 32 egzekucji). AI Act art. 11 wymaga sporządzenia szczegółowej dokumentacji technicznej systemu high-risk przed wprowadzeniem na rynek, z minimalnym zakresem zdefiniowanym w Aneksie IV.

Aneks IV obejmuje opis ogólny systemu, szczegółowy opis komponentów, opis monitoringu, opis zarządzania ryzykiem, kopię deklaracji zgodności UE — w sumie ponad pięćdziesiąt pól informacyjnych.

W praktyce dokumentacja AI Act jest znacznie głębsza technicznie. Ale wspólny shell — system zarządzania dokumentacją z wersjonowaniem, kontrolą dostępu, audit trailem, retencją — jest jeden.

Incident response — NIS-2 art. 23 vs AI Act art. 73

NIS-2 art. 23 definiuje obowiązek raportowania znaczących incydentów cyberbezpieczeństwa — szczegółowo omówiony w artykule NIS-2 — reporting incydentów w praktyce.

AI Act art. 73 definiuje obowiązek raportowania poważnych incydentów (serious incidents) związanych z systemami high-risk — w tym śmierć lub poważne uszkodzenie zdrowia, poważne zakłócenia w zarządzaniu krytyczną infrastrukturą, naruszenie podstawowych praw, poważne szkody majątkowe lub środowiskowe.

Adresat różny — w NIS-2 CSIRT, w AI Act organ nadzorczy nad AI. Ale procedura wewnętrzna detekcji, eskalacji, dokumentacji, root cause analysis jest tym samym procesem. Różnica leży w klasyfikacji incydentu (czy to incydent cyber, czy AI safety incident, czy oba) i w adresacie raportu.

Jeden incident response team, jeden playbook z dwiema gałęziami klasyfikacji — to operacyjny minimum.

Risk register jako wspólny artefakt

Risk register to centralna baza danych ryzyk organizacji. Dla shared stacka NIS-2 + AI Act warto, by każdy wpis zawierał:

Pole	Opis	Mapowanie do regulacji
ID	Identyfikator wpisu	—
Asset	Czego dotyczy — system, dane, proces	NIS-2 art. 21 ust. 2 lit. i; AI Act art. 9
Threat	Zagrożenie	NIS-2 art. 21; AI Act art. 9
Likelihood	Prawdopodobieństwo	NIS-2; AI Act
Impact (cyber)	Wpływ na dostępność, integralność, poufność	NIS-2
Impact (AI/rights)	Wpływ na prawa podstawowe, zdrowie, bezpieczeństwo	AI Act art. 9, 27
Mitigation	Środki	NIS-2 art. 21 ust. 2; AI Act art. 9
Owner	Odpowiedzialny	NIS-2 art. 20 (zarząd); AI Act art. 14 (nadzór człowieka)
Review date	Data ostatniego przeglądu	Oba
Residual risk	Ryzyko po mitygacji	Oba
Status	Open / mitigated / accepted	Oba

Częstotliwość przeglądu — minimum kwartalnie dla aktywnych pozycji, miesięcznie dla pozycji o wysokim ryzyku rezydualnym. Pełny audit register — raz rocznie z udziałem zarządu (NIS-2 art. 20 wymaga zatwierdzenia środków przez organy zarządcze i pociąga je do odpowiedzialności).

DPIA — gdzie spotyka się z AI Act

Art. 35 RODO wymaga oceny skutków dla ochrony danych (DPIA) przed przetwarzaniem, które „prawdopodobnie spowoduje wysokie ryzyko dla praw i wolności osób fizycznych” — w szczególności przy systematycznym i kompleksowym profilowaniu, przetwarzaniu szczególnych kategorii danych na dużą skalę, monitoringu obszarów publicznie dostępnych.

Wiele systemów AI high-risk wymaga DPIA niezależnie od AI Act. Sensowne jest budowanie jednego procesu, który dostarcza:

DPIA jako artefakt zgodny z RODO;
wkład do FRIA dla wymaganych deployerów (art. 27 AI Act);
wkład do risk register (cyber i AI views).

Praktycznie — szablon DPIA poszerzony o sekcje wymagane przez art. 27 AI Act (kategorie osób narażonych, częstotliwość użycia, ryzyka specyficzne dla AI, środki nadzoru człowieka) staje się jednym dokumentem obsługującym oba reżimy. Tam, gdzie wymagana jest też analiza per FRIA — sekcje są wskazane jako część szerszego DPIA.

FRIA — kiedy wymagany i jak go zorganizować

Art. 27 AI Act nakłada obowiązek FRIA na:

deployerów będących organami publicznymi i podmiotami świadczącymi usługi publiczne;
deployerów systemów z Aneksu III pkt 5 lit. b (scoring kredytowy) i pkt 5 lit. c (pricing ubezpieczeń życiowych i zdrowotnych).

Zakres FRIA z art. 27 ust. 1:

opis procesów deployera, w których będzie używany system;
okres i częstotliwość wykorzystania;
kategorie osób fizycznych, na które wpłynie system;
konkretne ryzyka szkody dla tych kategorii;
opis środków nadzoru człowieka;
środki podejmowane w razie materializacji ryzyk, w tym wewnętrzny governance i mechanizmy skargowe.

FRIA musi zostać zaktualizowana, jeśli któryś z elementów się zmienia. Wynik trafia do organu nadzorczego — w Polsce do organu wyznaczonego ustawą implementującą AI Act (proces legislacyjny w toku na moment publikacji).

Operacyjnie — FRIA bywa robione jako rozszerzony DPIA. Jeśli organizacja ma już proces DPIA pod RODO, dodanie sekcji FRIA per system high-risk jest tańsze niż budowa osobnego procesu od zera.

Kiedy DPIA + FRIA + risk register robi się jako jeden proces

Trzy artefakty mogą stać się jednym workflow, jeśli organizacja przyjmie podejście:

wspólny katalog assetów: systemy, dane, procesy raz wprowadzone, używane przez wszystkie trzy procesy;
wspólne taksonomie ryzyk: lista kategorii ryzyk (cyber, prawa podstawowe, prywatność, operacyjne, finansowe) używana wszędzie;
wspólny cykl review: kwartalnie dla risk register, rocznie dla DPIA/FRIA — w jednym kalendarzu compliance;
wspólny system dokumentacji: od jednej platformy GRC po dyscyplinowane użycie Confluence + Excel + Git dla artefaktów technicznych.

Granica, której nie warto zacierać — kompetencje. DPIA wymaga IOD lub osoby o równoważnych kompetencjach prawno-prywatnościowych. FRIA wymaga kompetencji w prawach podstawowych i przeznaczeniu konkretnego systemu AI. Risk register cyber wymaga security engineera. Te role mogą używać wspólnego stacka, ale nie powinny być łączone w jednej osobie poniżej pewnej skali organizacji.

Tooling — GRC vs Excel + Confluence

W 2026 dla polskiego MŚP poniżej 250 pracowników racjonalnym wyborem na pierwsze dwanaście-osiemnaście miesięcy jest stack:

risk register w Excelu lub w bazie z wersjonowaniem (np. Notion, Airtable);
dokumentacja w Confluence lub w repozytorium Git (Markdown + PR review);
incident tickets w Jira lub równoważnym narzędziu ticketowym;
audit log w write-once storage (S3 Object Lock lub równoważne).

Migracja do dedykowanej platformy GRC (np. OneTrust, Drata, Vanta, ServiceNow GRC) ma sens dopiero gdy: liczba systemów high-risk przekracza około piętnastu, liczba kontrolowanych wymogów (NIS-2 + AI Act + RODO + DORA + ISO) — ponad dwustu, lub gdy klient korporacyjny wymaga konkretnego raportu z konkretnego narzędzia.

Wcześniejsze wejście w platformę GRC kosztuje pieniądze, których MŚP nie ma — i tworzy wrażenie zgodności bez jej operacyjnej substancji. Lepiej zbudować dyscyplinę procesu na tańszym tooling i migrować z dyscypliną niż kupić platformę i traktować ją jako substytut procesu.

Plan 6-miesięczny dla MŚP w 2026

Miesiąc 1: audyt obecnego stanu. Co już istnieje? Lista wszystkich dokumentów, polityk, procesów, narzędzi związanych z bezpieczeństwem, compliance, AI. Stan AS-IS bez polerowania.

Miesiąc 2: gap analysis. Mapowanie istniejących artefaktów przeciwko wymogom NIS-2 (art. 20, 21, 23) i AI Act (art. 9-22, 26-27, 72-73). Każda luka skategoryzowana: blocking, major, minor.

Miesiąc 3: roadmap. Plan działań na kolejne dwanaście miesięcy z priorytetyzacją: najpierw blocking, potem major. Z odpowiedzialnościami, terminami, budżetem.

Miesiące 4-5: implementacja core stacka. Risk register operacyjny. DPIA-FRIA template. Incident playbooki. Lista kontaktów CSIRT. Polityki minimum: zarządzanie ryzykiem, incident response, supply chain security, użytkowanie AI.

Miesiąc 6: audyt zewnętrzny. Niezależna weryfikacja przez podmiot trzeci — nie po to, żeby otrzymać certyfikat, ale żeby dostać brutalną listę rzeczy, które wewnętrznie się przeoczyło. Wynik audytu staje się wkładem do drugiej iteracji roadmapy.

QA10 — gdzie to sprawdzamy

W ramach Audytu AiP przeprowadzamy gap analysis NIS-2 + AI Act + RODO w pojedynczym przebiegu i dostarczamy mapę luk wspólnych vs specyficznych dla każdego frameworka. Engineering Lab buduje shared risk register i pierwszą iterację DPIA-FRIA template z klientem.