RODO, NIS2 i KSC a AI w firmie — checklista compliance 2026

W maju 2026 polska firma wdrażająca AI nie odpowiada już tylko przed RODO. Odpowiada przed RODO + NIS2 + znowelizowanym KSC + AI Actem (art. 6, 9, 14, 17 wchodzą 2 sierpnia 2026) + branżowymi (KNF, GIODO, EMA, UODO). Ten artykuł to praktyczna lista 17 punktów, które każdy CISO i DPO musi przejść, zanim AI dotknie produkcyjnych danych.

Po co ta checklista

W ciągu ostatnich 12 miesięcy RedAI prowadził audyty compliance dla 23 wdrożeń AI w polskich firmach 50-800 osób. W 19 z 23 znaleźliśmy poważne braki — od braku DPIA po niezdefiniowane SLA bezpieczeństwa modelu. Średnio w jednym audycie wykrywamy 8-14 nieprawidłowości. Ta checklista jest destylacją tych audytów — robcie ją sami, zanim zrobi ją regulator.

Część I — RODO i ochrona danych osobowych

1. Mapa danych osobowych w AI

Każda firma wdrażająca AI musi mieć aktualną mapę: jakie dane osobowe trafiają do modelu, w jakim kontekście, na jakiej podstawie prawnej (art. 6 i 9 RODO), kto jest administratorem, kto procesorem, kto subprocessorem. Brak mapy = brak rozliczalności = naruszenie art. 5 ust. 2 RODO.

2. DPIA (ocena skutków dla ochrony danych)

Wdrożenie AI w procesach obejmujących profilowanie, decyzje zautomatyzowane lub przetwarzanie danych wrażliwych — zawsze wymaga DPIA (art. 35 RODO). W praktyce: w 9 na 10 wdrożeń RedAI DPIA jest wymagane.

3. Art. 22 — decyzje zautomatyzowane

Jeśli AI samodzielnie podejmuje decyzję, która ma istotny wpływ na osobę (odrzucenie wniosku, zmiana ceny, przyznanie kredytu, ocena pracownika) — wymagana jest możliwość ludzkiej interwencji, prawo do wyjaśnienia, prawo do zakwestionowania. Większość polskich wdrożeń AI w 2025-2026 ucieka od tego problemu przez „AI proponuje, człowiek decyduje" — i to jest właściwa konfiguracja.

4. Minimalizacja danych

Do modelu trafiają tylko te dane, które są niezbędne dla zadania. Nie wpuszczacie do RAG całej bazy CRM, jeśli pytanie dotyczy jednej kategorii produktów. Pseudo-anonimizacja przed przekazaniem do modelu (jeśli technicznie możliwa) — wartością defaultową.

5. Lokalizacja przetwarzania

Wszystkie 3 modele cloud (ChatGPT, Gemini, Copilot) deklarują przetwarzanie w UE, ale w praktyce subprocessorzy mogą być w USA, Indiach lub Singapurze. Dla firm wymagających ścisłej lokalizacji (sektor publiczny, KSC kategoria krytyczna, finanse) prywatna instancja RedAI w infrastrukturze klienta to praktycznie jedyne rozwiązanie.

Część II — NIS2

6. Klasyfikacja podmiotu

NIS2 wprowadza dwie kategorie: „podmiot kluczowy" (essential) i „podmiot ważny" (important). Po nowelizacji KSC w Polsce zakres jest szerszy niż NIS2 — obejmuje też podmioty publiczne, niektóre średnie firmy w sektorach kluczowych. Pierwszy krok: oficjalna klasyfikacja Waszej firmy. Bez niej nie wiecie, jakim wymaganiom podlegacie.

7. Analiza ryzyka cyberbezpieczeństwa

NIS2 wymaga udokumentowanej analizy ryzyka — w tym ryzyk związanych z dostawcami i łańcuchem dostaw. AI jako dostawca cyfrowy musi w niej być uwzględniony. Praktycznie: macierz ryzyk z minimum 12 scenariuszami zagrożeń (od wycieku danych po manipulację modelem).

8. Plan ciągłości i odporności

Co się stanie, jeśli model AI przestanie odpowiadać? Czy proces pracuje dalej, czy się zatrzymuje? NIS2 wymaga zdefiniowanych RTO/RPO dla krytycznych systemów. W praktyce: AI nie może być single point of failure dla procesu obsługi klienta.

9. Zgłaszanie incydentów w 24h

Każdy istotny incydent cyberbezpieczeństwa musi być zgłoszony do CSIRT NASK w 24h (early warning) i pełny raport w 72h. Wdrożenie AI musi mieć zdefiniowaną procedurę: co liczy się jako incydent (halucynacja krytyczna? wyciek prompta? jailbreak?), kto klasyfikuje, kto raportuje.

Część III — KSC po nowelizacji

10. Zakres przedmiotowy

Znowelizowany KSC rozszerzył liczbę podmiotów istotnie. Sprawdźcie u prawnika, czy Wasza firma jest w wykazie. Częste pułapki: średnie firmy z branży transport/logistyka, energetyka (nawet bez umowy z OSP), telekomunikacja regionalna, niektóre podmioty publiczne.

11. SZBI

System Zarządzania Bezpieczeństwem Informacji musi obejmować AI jako podsystem. ISO 27001 nie wystarczy — musi być rozszerzony o ISO/IEC 42001 (AI management system) lub przynajmniej dokumentacja zgodna z jego strukturą.

12. Audyty i certyfikacja

Podmioty kluczowe podlegają cyklicznym audytom. Wdrożenie AI musi być przygotowane na audyt zewnętrzny: pełna dokumentacja, logi, polityki, dowody szkoleń.

Część IV — AI Act

13. Klasyfikacja systemu AI

AI Act dzieli systemy na: minimal risk, limited risk, high risk, prohibited. Większość wdrożeń biznesowych to limited risk (chatboty, generowanie tekstu) lub high risk (selekcja kandydatów, ocena pracowników, kredyty, infrastruktura krytyczna). High risk wymaga: registracji w UE database, oceny zgodności, post-market monitoring, transparentności wobec użytkownika.

14. Transparentność (art. 50)

Użytkownik musi wiedzieć, że rozmawia z AI. Treści generowane przez AI (zwłaszcza deepfake, syntetyczne audio/wideo) muszą być oznaczone. Dla chatbotów obsługi klienta od 2 sierpnia 2026 obowiązkowe: „Rozmawiasz z asystentem AI" w pierwszej wiadomości.

15. Logi i ślad audytowy (art. 12)

High-risk AI musi prowadzić logi „automatycznie" — czyli każde wywołanie modelu, z czasem, użytkownikiem, danymi wejściowymi (zanonimizowanymi), danymi wyjściowymi. Retencja minimum 6 miesięcy, dla niektórych zastosowań — 10 lat. To dotyka architektury: musicie zaprojektować logging zanim wdrożycie produkcję.

Część V — branżowe

16. Sektorowe wymagania (KNF, GIODO, EMA, UODO)

Banki — KNF rekomendacje M, D, T. Ubezpieczenia — KNF rekomendacja U. Sektor medyczny — EMA reflection paper on AI 2024. Ochrona zdrowia — wymóg lokalizacji danych medycznych w Polsce (art. 24 ustawy o systemie informacji w ochronie zdrowia). Sprawdźcie, jakie sektorowe regulacje Was dotyczą, zanim wdrożycie AI.

17. Polityka „dopuszczalnego użycia AI"

Pisemna polityka, podpisana przez wszystkich pracowników, regulująca: jakie dane wolno wpuszczać do AI, jakich nie wolno, jakie zastosowania są dopuszczone, jakie zakazane (np. generowanie treści marketingowych dotyczących konkurencji, decyzje kadrowe, oceny pracowników). Brak takiej polityki = brak podstaw do działań dyscyplinarnych, jeśli pracownik wycieknie dane do ChatGPT.

Tabela: koszt braku compliance

Naruszenie	Maks. kara	Praktyczna mediana
RODO — naruszenie zasad (art. 83)	20 mln EUR lub 4% obrotu	50 tys. - 1,2 mln zł w Polsce
NIS2 — brak zgłoszenia incydentu	10 mln EUR lub 2% obrotu (kluczowy)	200 tys. - 800 tys. zł
KSC — brak SZBI	do 200 000 zł lub 3% obrotu	80 - 300 tys. zł
AI Act — high-risk bez compliance (2026+)	35 mln EUR lub 7% obrotu	nieznana, przepisy świeże
Reputacja po incydencie (utrata klientów)	—	3-12% obrotu w 12 mies.

Mit „RODO już ogarnęliśmy"

To zdanie słyszymy w 8 na 10 firm wchodzących we wdrożenie. Po pierwszym warsztacie 7 z 8 koryguje. AI dodaje warstwę, której polityki RODO sprzed 4 lat nie pokrywały — przepływy danych do modelu, retencja kontekstów rozmów, prawo do wyjaśnienia decyzji algorytmicznych, kwestia treningu modelu na danych klienta (vs. tylko inferencji). Każda firma wdrażająca AI musi przejrzeć i odświeżyć politykę RODO.

Co zrobić jutro

• Wyznaczcie jedną osobę odpowiedzialną za compliance AI (zwykle CISO lub DPO z dodatkową rolą).
• Przejdźcie przez 17 punktów tej listy w formie warsztatu dwudniowego.
• Każdy punkt: zielony (gotowe), żółty (częściowo), czerwony (luka). Wynik to mapa działań na 90 dni.
• Najpierw zamknijcie czerwone, potem żółte, potem podpiszcie z RedAI umowę utrzymaniową zawierającą klauzule compliance i SLA bezpieczeństwa.

Konkluzja

Compliance AI w 2026 to nie „papier do schowania" — to fundament, bez którego wdrożenie produkcyjne jest nielegalne. Te 17 punktów to nie sumarum całego prawa, ale praktyczny szkielet, który pokrywa 85% wymagań regulacyjnych dla polskiej firmy 50-500 osób. Reszta — branżowa specyfika — wymaga prawnika z doświadczeniem w AI Act i NIS2.

Umówcie audyt compliance AI w Waszej firmie — wykonujemy go w 2-3 tygodnie, dostajecie raport gap analysis i plan działań na 90 dni.