Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem

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

Odpowiedź najpierw

Przed audytem NIS2 nie musisz mieć osobnej „polityki AI". Musisz umieć pokazać, że narzędzie AI jest objęte tymi samymi mechanizmami zarządzania ryzykiem, łańcuchem dostaw i incydentami, co reszta systemów. W praktyce sprowadza się to do siedmiu dokumentów, które i tak wytwarzasz, gdy robisz wdrożenie porządnie: rejestr systemu AI w inwentaryzacji aktywów, analiza ryzyka dla tego systemu, umowa z dostawcą z klauzulami bezpieczeństwa, mapa przepływu danych, polityka logowania i retencji, procedura zgłaszania incydentów obejmująca AI oraz dowód nadzoru kierownictwa. Żaden z nich nie jest „dokumentem o AI". Każdy to istniejący artefakt compliance, w którym system AI jest po prostu jedną z pozycji. Jeśli zaczynasz od pisania osobnego regulaminu sztucznej inteligencji, prawdopodobnie idziesz w złą stronę.

Spis treści

1. Dlaczego „polityka AI" to zły punkt wyjścia
2. Siedem dokumentów po kolei
3. Tabela: dokument, podstawa, kto wytwarza
4. Najczęstszy błąd: traktowanie AI jako osobnej kategorii
5. FAQ
6. Disclosure i biases
7. Czego tu nie pokrywam
8. Powiązane notatki

Dlaczego „polityka AI" to zły punkt wyjścia

Pierwsza reakcja wielu zespołów na pytanie „a co z AI w kontekście NIS2" to napisanie nowego, osobnego dokumentu zatytułowanego „Polityka korzystania ze sztucznej inteligencji". To zrozumiałe, ale zwykle nietrafione.

NIS2 nie zna kategorii „system AI" jako odrębnej klasy wymagającej własnego reżimu. Dyrektywa, a w Polsce ustawa o krajowym systemie cyberbezpieczeństwa po nowelizacji, mówi o środkach zarządzania ryzykiem (Art. 21), o bezpieczeństwie łańcucha dostaw i o obowiązkach zgłaszania incydentów. System AI, w tym wewnętrzny asystent oparty na modelu językowym czy pipeline przetwarzający dokumentację techniczną, jest po prostu kolejnym systemem informatycznym, który podlega tym samym wymaganiom.

Audytor nie zapyta „pokażcie politykę AI". Zapyta „pokażcie, że ten system jest w waszej inwentaryzacji, że zrobiliście dla niego analizę ryzyka, że umowa z dostawcą domyka łańcuch dostaw i że wiecie, co się dzieje, gdy coś pójdzie nie tak". Osobny regulamin AI, który nie jest wpięty w te mechanizmy, to dokument na półkę, nie dowód zgodności.

Praktyczny wniosek: zamiast tworzyć nowy reżim, rozszerz istniejące artefakty o pozycję „system AI". Poniżej siedem dokumentów, w których to się dzieje.

Siedem dokumentów po kolei

1. Rejestr systemu AI w inwentaryzacji aktywów

Punkt wyjścia. Jeśli system AI nie figuruje w inwentaryzacji aktywów informatycznych, formalnie dla audytu nie istnieje, a to gorsze niż istnienie z lukami. Wpis powinien obejmować: nazwę i przeznaczenie systemu, właściciela biznesowego i technicznego, klasyfikację przetwarzanych danych, lokalizację przetwarzania (on-prem, chmura, model hybrydowy) oraz powiązane systemy, z którymi się integruje.

Lokalizacja przetwarzania to pozycja, na której audytor zatrzyma się najdłużej, bo od niej zależy ocena łańcucha dostaw i ekspozycji danych. Jeśli zapytania trafiają do publicznego API modelu poza organizacją, jest to sub-processor i musi być udokumentowane jako element łańcucha dostaw.

2. Analiza ryzyka dla systemu AI

To nie nowy gatunek analizy, to twoja istniejąca metodyka oceny ryzyka zastosowana do konkretnego systemu. Powinna pokrywać co najmniej: ryzyko wycieku danych wprowadzanych do modelu, ryzyko niedostępności (co się dzieje, gdy system padnie), ryzyko jakości odpowiedzi w procesach, gdzie błąd ma konsekwencje, oraz ryzyko łańcucha dostaw związane z dostawcą modelu lub platformy.

Wartość tej analizy nie leży w długości, lecz w tym, że pokazuje świadomy proces decyzyjny. Audytor szuka dowodu, że organizacja rozważyła zagrożenia i podjęła decyzje, a nie że wdrożyła narzędzie, bo było modne.

3. Umowa z dostawcą z klauzulami bezpieczeństwa

Art. 21 wprost obejmuje bezpieczeństwo łańcucha dostaw, a dostawca rozwiązania AI jest częścią tego łańcucha. Umowa, czy to MSA, czy DPA, powinna domykać: zakres przetwarzania danych, podwykonawców (sub-processorów), zobowiązania dotyczące bezpieczeństwa, prawo do audytu lub odpowiednik w postaci certyfikatów, oraz zasady zakończenia współpracy i przenoszalności danych.

Tu wraca temat, który omawiałem w notatce o vendor lock-in w AI: brak klauzul przenoszalności danych jest jednocześnie ryzykiem operacyjnym i luką compliance. Dla wdrożenia on-prem część tych klauzul wygląda inaczej niż dla SaaS, bo dane nie opuszczają organizacji, ale umowa wciąż musi opisywać aktualizacje modelu, wsparcie i warunki wyjścia.

4. Mapa przepływu danych

Jeden diagram albo jedna tabela, która odpowiada na pytanie: jakie dane, skąd, dokąd i z jaką klasyfikacją trafiają do i z systemu AI. To dokument, który najszybciej ujawnia problem, bo zmusza do nazwania, czy dokumentacja techniczna, dane osobowe lub informacje objęte tajemnicą przedsiębiorstwa wychodzą poza kontrolowane środowisko.

Dla audytora mapa przepływu danych to skrót myślowy do oceny ekspozycji. Jeśli wszystkie strzałki zostają wewnątrz organizacji, rozmowa jest krótka. Jeśli któraś prowadzi na zewnątrz, zaczyna się pytanie o podstawę, zabezpieczenia i zgodność z punktem 3.

5. Polityka logowania i retencji

NIS2 oczekuje zdolności do wykrywania i analizy incydentów, a to wymaga logów. Dla systemu AI istotne jest udokumentowanie: co jest logowane (dostępy, zapytania, działania administracyjne), gdzie logi są przechowywane, jak długo i kto ma do nich dostęp.

Logowanie zapytań do systemu AI bywa drażliwe, bo same zapytania mogą zawierać dane wrażliwe. To nie powód, by nie logować, lecz powód, by świadomie zaprojektować zakres i retencję. Brak logów oznacza, że w razie incydentu nie odtworzysz przebiegu zdarzeń, a to jest dokładnie ta zdolność, której wymaga dyrektywa.

6. Procedura zgłaszania incydentów obejmująca AI

Masz już procedurę reagowania na incydenty. Pytanie audytora brzmi: czy obejmuje ona scenariusze związane z systemem AI. Co liczy się jako incydent w kontekście AI, kto go klasyfikuje, jak przebiega eskalacja i jak wpina się w obowiązki zgłoszeniowe wobec CSIRT.

Nie potrzebujesz osobnej procedury. Potrzebujesz dowodu, że istniejąca procedura rozpoznaje takie zdarzenia jak wyciek danych przez system AI, kompromitacja konta z dostępem do narzędzia czy istotna awaria wpływająca na proces biznesowy.

7. Dowód nadzoru kierownictwa

Po nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa odpowiedzialność za zarządzanie ryzykiem spoczywa wprost na kierownictwie, z osobistą odpowiedzialnością włącznie. Dlatego ostatni dokument to dowód, że decyzje dotyczące systemu AI były świadome i zatwierdzone na właściwym poziomie: protokół, w którym zarząd lub osoba odpowiedzialna akceptuje analizę ryzyka i decyzję o wdrożeniu, albo wpis w istniejącym rejestrze decyzji.

Ten artefakt jest często pomijany, a w nowym reżimie jest jednym z najważniejszych, bo przenosi temat z poziomu zespołu IT na poziom, na którym ustawa lokuje odpowiedzialność. Pisałem o tym szerzej w notatce o odpowiedzialności zarządu po nowelizacji UKSC.

Tabela: dokument, podstawa, kto wytwarza

Dokument	Obszar NIS2 / Art. 21	Kto wytwarza
Rejestr systemu AI w inwentaryzacji	Zarządzanie aktywami i ryzykiem	IT / właściciel systemu
Analiza ryzyka systemu AI	Środki zarządzania ryzykiem	Zespół ryzyka / bezpieczeństwo
Umowa z dostawcą z klauzulami	Bezpieczeństwo łańcucha dostaw	Dział prawny plus bezpieczeństwo
Mapa przepływu danych	Bezpieczeństwo danych i ekspozycja	Architekt / bezpieczeństwo
Polityka logowania i retencji	Wykrywanie i analiza incydentów	Bezpieczeństwo / IT
Procedura incydentów obejmująca AI	Obsługa i zgłaszanie incydentów	Bezpieczeństwo / SOC
Dowód nadzoru kierownictwa	Odpowiedzialność kierownictwa	Zarząd / osoba odpowiedzialna

Żadna z pozycji w kolumnie „kto wytwarza" nie wprowadza nowej roli. To są zespoły, które już istnieją w organizacji objętej NIS2.

Najczęstszy błąd: traktowanie AI jako osobnej kategorii

Z perspektywy przygotowania do audytu najkosztowniejszy błąd jest pojęciowy, nie techniczny. Polega na wydzieleniu AI do osobnego silosu compliance, z własną polityką, własnym rejestrem i własnym procesem, oderwanymi od reszty systemu zarządzania bezpieczeństwem.

Skutki są dwa. Po pierwsze, powstaje równoległy obieg dokumentów, który nikt nie utrzymuje, więc szybko się dezaktualizuje. Po drugie, audytor i tak będzie oceniał system AI przez pryzmat tych samych mechanizmów co resztę infrastruktury, więc osobny silos nie odpowiada na jego pytania, tylko dokłada pracy.

Odwrotne podejście, czyli wpięcie systemu AI w istniejące artefakty, ma dodatkową zaletę: gdy pojawi się kolejny system AI, nie zaczynasz od zera. Rozszerzasz inwentaryzację, dopisujesz analizę ryzyka, aktualizujesz mapę przepływu danych. To skaluje się znacznie lepiej niż mnożenie osobnych polityk.

FAQ

Czy NIS2 wymaga osobnej polityki dotyczącej AI?

Nie wprost. Dyrektywa i ustawa mówią o środkach zarządzania ryzykiem, łańcuchu dostaw i incydentach. System AI podlega tym wymaganiom jako kolejny system informatyczny, więc kluczowe jest wpięcie go w istniejące dokumenty, a nie tworzenie odrębnego reżimu.

Czy wdrożenie on-prem zwalnia z części tych dokumentów?

Nie zwalnia, ale upraszcza. Przy przetwarzaniu wewnątrz organizacji mapa przepływu danych jest krótsza, a ocena łańcucha dostaw węższa, bo dane nie trafiają do zewnętrznego sub-processora. Wszystkie siedem artefaktów nadal jest potrzebnych, część po prostu zawiera mniej ryzyka do opisania.

Od którego dokumentu zacząć?

Od inwentaryzacji. Dopóki system nie jest formalnie zarejestrowany jako aktyw, pozostałe dokumenty nie mają do czego się odnosić.

Czy to wystarczy do pełnej zgodności z NIS2?

Nie. To jest warstwa dotycząca konkretnego systemu AI. Pełna zgodność obejmuje cały system zarządzania bezpieczeństwem organizacji. Te siedem dokumentów odpowiada na pytanie „jak pokazać audytorowi, że AI nie jest białą plamą", a nie na pytanie o całość obowiązków podmiotu kluczowego.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc naturalnie kładę nacisk na wątki on-prem i kontrolę nad przepływem danych. Starałem się oddzielić to, co wynika z treści przepisów, od tego, co jest preferencją architektoniczną. Ten tekst nie jest opinią prawną. Interpretacja NIS2 i ustawy o krajowym systemie cyberbezpieczeństwa zależy od konkretnego stanu faktycznego i sektora, a praktyka audytowa dopiero się kształtuje. Przed decyzjami compliance skonsultuj się z prawnikiem specjalizującym się w cyberbezpieczeństwie.

// co tu nie pokrywamCzego tu nie pokrywam

Nie omawiam tu klasyfikacji systemów AI pod kątem AI Act, bo to osobny reżim z własnymi kategoriami ryzyka. Nie wchodzę w szczegóły sektorowe (energetyka, ochrona zdrowia, podmioty infrastruktury cyfrowej), gdzie obowiązują dodatkowe wymagania. Pomijam też techniczny wymiar zabezpieczeń samego modelu oraz operacyjne progi i terminy zgłaszania incydentów do CSIRT, które zasługują na osobne notatki.

Powiązane notatki

• NIS2 a vendor AI w łańcuchu dostaw: mapowanie Art. 21 dla podmiotów kluczowych
• ISO 27001 a AI vendor: trzy kontrole, które warto zmapować dziś
• Personal liability zarządu po nowelizacji UKSC: co to znaczy dla decyzji AI