NIS2 a vendor AI w łańcuchu dostaw: mapowanie Art. 21 dla podmiotów kluczowych

Większość mapowań NIS2, które trafiają na biurko CISO, traktuje AI jako jeszcze jedną pozycję w rejestrze systemów IT. To błąd kategorii. Dostawca generatywnej AI nie jest aplikacją, którą się hostuje — jest dostawcą usługi, który przetwarza treść operacyjną organizacji, stoi na cudzej infrastrukturze i ma własny, nieprzejrzysty łańcuch poddostawców. Z perspektywy Art. 21 dyrektywy NIS2 (i polskiej ustawy o KSC, która ją transponuje) ten dostawca jest elementem łańcucha dostaw, który trzeba ocenić, udokumentować i monitorować — tak samo jak dostawcę systemu SCADA czy MES.

Ten przewodnik jest pillarem klastra NIS2 na aionprem.pl. Pokazuje, jak konkretnie zmapować dostawcę AI na wymagania Art. 21, gdzie standardowe vendor management się rozjeżdża z regulacją, i jaki minimalny zestaw dokumentów trzeba wytworzyć, żeby przejść audyt. Nie jest poradą prawną — jest mapą roboczą dla architekta bezpieczeństwa i compliance leada, który musi tę pracę faktycznie wykonać.

Spis treści

• Stan prawny: co dokładnie obowiązuje w Polsce
• Dlaczego AI vendor jest problemem łańcucha dostaw, a nie problemem IT
• Anatomia łańcucha: ilu dostawców naprawdę masz
• Mapowanie Art. 21 ust. 1 lit. d na konkretne pytania
• Cztery obszary, w których standardowa relacja zawodzi
• Personal liability zarządu: dlaczego to zmienia kalkulację
• Szkielet rejestru ryzyk dla dostawcy AI
• Checklista audit readiness
• Decyzja: cztery drogi i kiedy która ma sens
• Disclosure i biases
• Co tu nie pokrywam
• Powiązane

Stan prawny: co dokładnie obowiązuje w Polsce

Zanim wejdziemy w mapowanie, ustalmy grunt — bo wiele analiz w sieci wciąż operuje na stanie sprzed transpozycji.

Dyrektywa NIS2 (2022/2555) sama w sobie nie obowiązuje przedsiębiorcy bezpośrednio. Obowiązuje krajowa ustawa, która ją wdraża. W Polsce jest to znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (UKSC): nowelizacja z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026 r., modyfikując ustawę z 5 lipca 2018 r. (tekst jednolity Dz.U. 2026 poz. 20).

Z punktu widzenia decyzji o dostawcy AI istotne są cztery elementy nowego stanu prawnego:

• Samoidentyfikacja zamiast decyzji administracyjnej. O objęciu organizacji przepisami coraz częściej przesądza nie decyzja organu, lecz obowiązek samodzielnej weryfikacji statusu. Jeśli spełniasz kryteria, jesteś podmiotem kluczowym lub ważnym — niezależnie od tego, czy ktoś ci to formalnie zakomunikował.
• Terminy. Rejestracja w Wykazie podmiotów kluczowych i ważnych — do 3 października 2026 r. (dla podmiotów spełniających kryteria w dniu wejścia w życie). Wdrożenie systemu zarządzania bezpieczeństwem informacji i obowiązków rozdziału 3 — do 3 kwietnia 2027 r. Pierwszy audyt podmiotu kluczowego — do 3 kwietnia 2028 r.
• Kary. Do 10 000 000 EUR lub 2 procent rocznego obrotu globalnego dla podmiotu kluczowego. Dodatkowo do 300 procent wynagrodzenia osoby pełniącej funkcję kierowniczą.
• Łańcuch dostaw jako osobny obszar ryzyka. Wymóg oceny bezpieczeństwa relacji z bezpośrednimi dostawcami jest wprost w materialnym zakresie ustawy, identycznym co Art. 21 dyrektywy.

Praktyczny wniosek: harmonogram do kwietnia 2027 i 2028 wygląda na odległy, ale decyzja o dostawcy AI podjęta dziś będzie oceniana w pierwszym audycie. Dług dokumentacyjny zaciągnięty teraz spłaca się pod presją czasu w 2027 roku.

Dlaczego AI vendor jest problemem łańcucha dostaw, a nie problemem IT

Klasyczne IT vendor management pyta: czy dostawca ma SOC 2? Czy szyfruje dane w spoczynku? Czy ma plan ciągłości działania? To dobre pytania, ale dla dostawcy AI niewystarczające z trzech powodów.

Po pierwsze, dostawca AI przetwarza treść, nie tylko ją przechowuje. Kiedy zespół utrzymania ruchu wkleja opis usterki do modelu, żeby wygenerować instrukcję serwisową, do dostawcy trafia wiedza operacyjna organizacji — czasem dane objęte tajemnicą przedsiębiorstwa, czasem dane osobowe, czasem informacje, które w rękach konkurenta lub atakującego mają realną wartość. To nie jest backup plików. To ciągły strumień treści wrażliwej.

Po drugie, dostawca AI rzadko stoi na własnej infrastrukturze. Główni dostawcy generatywnej AI działają na hyperscalerach. To znaczy, że ocena ryzyka łańcucha dostaw nie kończy się na vendorze — sięga jego poddostawcy obliczeniowego i dalej. Rozwijam ten konkretny scenariusz w węższej notatce: Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d.

Po trzecie, praktyki rozwoju produktu u dostawcy AI są nieprzejrzyste. Art. 21 wymaga uwzględnienia jakości praktyk bezpiecznego rozwoju produktów dostawcy. Dla dostawcy AI oznacza to pytania o governance danych treningowych, o cykl życia modelu, o to, czy treść klienta jest używana do dalszego trenowania. To pytania, na które klasyczny security questionnaire nie ma rubryki.

Dlatego dostawca AI nie wpada do tej samej szuflady co system ERP. Wymaga osobnego mapowania.

Anatomia łańcucha: ilu dostawców naprawdę masz

Pierwszy krok mapowania to narysowanie realnego łańcucha. Typowa organizacja, która "po prostu kupiła licencję na asystenta AI", zwykle nie ma świadomości, ilu dostawców faktycznie weszło do jej łańcucha dostaw.

Minimalny łańcuch dla publicznego dostawcy LLM wygląda tak:

• Dostawca warstwy aplikacyjnej (interfejs, asystent, integracja) — z którym podpisałeś umowę.
• Dostawca modelu — czasem ten sam podmiot, czasem inny (gdy aplikacja jest zbudowana na cudzym API).
• Hyperscaler — infrastruktura obliczeniowa, na której model działa.
• Poddostawcy operacyjni — CDN, observability, billing, wsparcie, czasem moderacja treści.

Z perspektywy Art. 21 każde z tych ogniw jest częścią Twojej oceny ryzyka łańcucha dostaw. Nie dlatego, że masz z nimi umowę (zwykle nie masz), ale dlatego, że Twoja treść przez nie przepływa. Standardowy DPA dostawcy zwykle wymienia poddostawców w osobnym dokumencie, który może się zmieniać z 30-dniowym uprzedzeniem. To znaczy, że Twój rejestr ryzyk łańcucha dostaw jest dokumentem żywym, nie jednorazowym.

Dla on-prem deploymentu ten sam diagram wygląda radykalnie krócej: dostawca oprogramowania lub modelu, Twoja infrastruktura, koniec. Liczba ogniw, które trzeba ocenić i monitorować, jest jedną z najbardziej niedocenianych zmiennych w kalkulacji build vs buy — wrócę do tego w sekcji o decyzji.

Mapowanie Art. 21 ust. 1 lit. d na konkretne pytania

Art. 21 ust. 1 lit. d mówi o bezpieczeństwie łańcucha dostaw, w tym o aspektach bezpieczeństwa w relacji między podmiotem a jego bezpośrednimi dostawcami. Ustęp doprecyzowujący każe uwzględnić specyficzne podatności dostawcy, ogólną jakość jego produktów i praktyk cyber oraz praktyki bezpiecznego rozwoju produktów.

Przetłumaczmy to na pytania, które faktycznie zadajesz dostawcy AI i na które dokumentujesz odpowiedź:

Specyficzne podatności dostawcy:

• Gdzie fizycznie przetwarzana jest treść (region, konkretne centrum danych)?
• Jakie kategorie treści wolno przesłać, a jakich nie (klasyfikacja danych po stronie klienta)?
• Czy treść klienta jest izolowana od innych klientów na poziomie infrastruktury, czy logicznie?
• Czy treść klienta może trafić do zbioru treningowego — domyślnie, opcjonalnie, nigdy?

Jakość produktów i praktyk cyber:

• Jakie certyfikaty ma dostawca i jego hyperscaler (SOC 2 Type II, ISO 27001, ISO 42001)?
• Jak wygląda zarządzanie dostępem pracowników dostawcy do treści klienta?
• Jaki jest mechanizm i SLA usunięcia danych po zakończeniu umowy?

Praktyki bezpiecznego rozwoju produktu:

• Jak dostawca zarządza cyklem życia modelu i jego aktualizacjami?
• Jakie ma praktyki governance danych treningowych?
• Czy dostawca udostępnia attestation lub raport niezależnej strony trzeciej obejmujący te obszary?

Każde "nie wiem" w tej tabeli to luka w mapowaniu, którą audytor zobaczy. Każde "vendor odmawia odpowiedzi" to pozycja, którą trzeba albo zaakceptować świadomie (z uzasadnieniem zarządu), albo rozwiązać alternatywnie.

Cztery obszary, w których standardowa relacja zawodzi

Z analizy publicznie dostępnych umów (DPA, master service agreements, listy poddostawców) wyłaniają się cztery powtarzalne obszary tarcia między standardową ofertą publicznego dostawcy AI a wymaganiami Art. 21.

1. Transparencja poddostawców

Standardowy DPA pozwala dostawcy zmieniać poddostawców z ograniczonym uprzedzeniem. Dla podmiotu kluczowego, który musi utrzymać aktualną listę dostawców w mapowaniu, oznacza to ciągły obowiązek monitorowania. W praktyce: ktoś w organizacji co miesiąc weryfikuje listę poddostawców i aktualizuje rejestr ryzyk. Jeśli nikt tego nie robi, mapowanie jest nieaktualne w dniu pierwszej zmiany po stronie dostawcy.

2. Audit rights

Klasyczna enterprise SaaS daje prawo do audytu w wąskich ramach: roczna częstotliwość, scope ograniczony do certyfikatów. Art. 21 oczekuje oceny praktyk rozwoju produktu. Niewielu dostawców AI zgodzi się na audyt pipeline'u MLOps czy governance danych treningowych, a jeśli się zgodzą, sam audyt jest kosztowny. Najczęstsze realne rozwiązanie to akceptacja raportu niezależnej strony trzeciej zamiast audytu własnego — co trzeba świadomie udokumentować jako środek kompensacyjny, nie przemilczeć.

3. Incident notification

UKSC wymaga zgłoszenia poważnego incydentu w napiętych ramach czasowych (wczesne ostrzeżenie liczone w godzinach od wykrycia). Jeśli incydent dzieje się po stronie dostawcy lub jego hyperscalera, musisz się o nim dowiedzieć szybciej, niż przewiduje standardowa formuła "bez zbędnej zwłoki". Standardowa umowa rzadko gwarantuje notyfikację w godzinach. Wniosek: nie możesz polegać wyłącznie na powiadomieniu od dostawcy — potrzebujesz własnego monitoringu i runbooka na scenariusz "incydent u dostawcy".

4. Asymetria odpowiedzialności

Typowa umowa ogranicza odpowiedzialność dostawcy do wysokości 12-miesięcznych opłat. Po Twojej stronie ryzyko to kara do 10 mln EUR lub 2 procent obrotu plus osobista odpowiedzialność kierownictwa. Kontraktową stronę tego problemu — w tym pułapki przy wyjściu z umowy — rozkładam osobno w Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe. Ta asymetria nie jest argumentem "nie wolno" — jest pozycją, którą zarząd powinien zobaczyć i zaakceptować świadomie, na piśmie, bo to jego głowa jest na szali.

Personal liability zarządu: dlaczego to zmienia kalkulację

Najważniejsza zmiana, którą wprowadza obecny stan prawny, nie dotyczy techniki. Dotyczy tego, kto odpowiada. UKSC przewiduje karę do 300 procent wynagrodzenia osoby pełniącej funkcję kierowniczą za niedopełnienie obowiązków.

To przenosi decyzję o dostawcy AI z poziomu "zespół IT wybrał narzędzie" na poziom "zarząd zaakceptował ryzyko". W praktyce oznacza to, że:

• decyzja o dopuszczeniu publicznego dostawcy AI do treści operacyjnej powinna być udokumentowana jako świadoma decyzja o akceptacji ryzyka, nie jako zakup operacyjny;
• analiza alternatyw (w tym opcji, w których treść nie opuszcza organizacji) powinna być częścią tej dokumentacji, bo audytor zapyta, czy rozważono opcje o niższym profilu ryzyka;
• compliance lead i CISO potrzebują formalnej ścieżki eskalacji decyzji do zarządu, a nie tylko podpisu pod zamówieniem.

Dla CISO to dobra i zła wiadomość naraz. Zła: presja rośnie. Dobra: argument za solidnym mapowaniem i za rozważeniem architektur o niższym profilu ryzyka przestaje być "paranoją działu bezpieczeństwa" i staje się ochroną zarządu.

Szkielet rejestru ryzyk dla dostawcy AI

Minimalny rejestr, który warto mieć dla każdego dostawcy AI w łańcuchu, zanim przyjdzie audytor. Każda pozycja to jedna kolumna lub jeden wpis:

• Dostawca i rola w łańcuchu (aplikacja / model / hyperscaler / poddostawca).
• Kategorie treści przesyłane do dostawcy (z odwołaniem do polityki klasyfikacji danych).
• Lokalizacja przetwarzania (region plus, jeśli dostępne, konkretne centrum danych).
• Lista poddostawców i data ostatniej weryfikacji.
• Mechanizm monitorowania zmian poddostawców (kto, jak często, gdzie zapisuje).
• Dostępne attestation lub certyfikaty (typ, data ważności).
• Mechanizm i SLA usunięcia danych po zakończeniu umowy.
• Runbook incident response dla scenariusza incydentu u dostawcy.
• Decyzja o akceptacji ryzyka (kto zaakceptował, data, uzasadnienie, środki kompensacyjne).
• Data następnego przeglądu (rekomendacja: kwartalnie).

Ten rejestr jest sercem mapowania Art. 21 dla AI. Jeśli istnieje i jest aktualny, audyt łańcucha dostaw w obszarze AI jest do obronienia. Jeśli go nie ma, żadna ilość certyfikatów dostawcy go nie zastąpi.

Checklista audit readiness

Krótka lista do samodzielnej weryfikacji przed pierwszym audytem (przypomnienie: dla podmiotu kluczowego termin to 3 kwietnia 2028 r., ale decyzje podejmowane dziś będą wtedy oceniane):

• Czy każdy dostawca AI ma wpis w rejestrze ryzyk łańcucha dostaw?
• Czy klasyfikacja danych określa, które kategorie treści wolno przesłać do dostawcy zewnętrznego?
• Czy istnieje udokumentowana, kwartalna procedura weryfikacji listy poddostawców?
• Czy decyzja o dopuszczeniu publicznego dostawcy AI jest udokumentowana jako akceptacja ryzyka na poziomie zarządu?
• Czy istnieje runbook na incydent po stronie dostawcy AI, spójny z terminami notyfikacji UKSC?
• Czy umowa ma mechanizm usunięcia danych z potwierdzającym SLA?
• Czy rozważono i udokumentowano alternatywy o niższym profilu ryzyka łańcucha dostaw?

Siedem pytań. Każde "nie" to pozycja w planie pracy do kwietnia 2027.

Decyzja: cztery drogi i kiedy która ma sens

Mapowanie Art. 21 nie kończy się stwierdzeniem "wolno" lub "nie wolno". Kończy się wyborem architektury o akceptowalnym profilu ryzyka. Cztery typowe drogi:

Droga 1: Publiczny dostawca AI z pełnym mapowaniem. Sensowna, gdy kategorie przetwarzanej treści są niskiego ryzyka, a organizacja ma capacity na ciągłe utrzymanie rejestru i monitoringu. Koszt ukryty: ongoing maintenance łańcucha dostaw.

Droga 2: Dedykowana / izolowana oferta hyperscalera (np. modele uruchamiane w wydzielonym tenancie). Skraca łańcuch i poprawia kontrolę nad lokalizacją, ale nie eliminuje hyperscalera z łańcucha dostaw. Wymaga osobnej analizy kalibracyjnej.

Droga 3: On-prem deployment open-source lub licencjonowanego modelu. Treść nie opuszcza organizacji; łańcuch dostaw kurczy się do dostawcy oprogramowania lub modelu i własnej infrastruktury. Mapowanie Art. 21 staje się krótsze, bo wiele pytań o lokalizację i poddostawców rozwiązuje się z definicji. Koszt przenosi się na infrastrukturę i kompetencje utrzymaniowe. Kto faktycznie utrzymuje taki deployment, rozkładam w DIY, productized czy managed: trzy modele on-prem AI, a architekturę całościowo w pillarze klastra on-prem.

Droga 4: Hybryda — treść niskiego ryzyka do publicznego dostawcy, treść wrażliwa do on-prem. Najbardziej elastyczna, ale wymaga twardej, egzekwowanej klasyfikacji danych, inaczej staje się fikcją.

Nie ma drogi uniwersalnie najlepszej. Jest droga, której profil ryzyka łańcucha dostaw zarząd jest gotów świadomie zaakceptować, znając asymetrię odpowiedzialności. Mapowanie Art. 21 jest narzędziem, które tę decyzję czyni świadomą zamiast domyślną.

// disclosure i biasesDisclosure i biases

Autor (Fryderyk Pryjma) pracuje nad on-prem AI platform dla europejskich producentów. Analiza w tym poście może być stronnicza w kierunku architektur, w których treść nie opuszcza organizacji (Droga 3 i częściowo 4). Tam, gdzie ta stronniczość mogłaby zaważyć na wnioskach, starałem się zaznaczać inline — w szczególności w sekcji o decyzji wymieniam publicznego dostawcę i ofertę hyperscalera jako pełnoprawne ścieżki, bo dla wielu organizacji są właściwym wyborem. Szacunki nakładu pracy compliance i interpretacje praktyk umownych są moją oceną na podstawie analizy publicznie dostępnych dokumentów i rozmów z compliance leadami, nie wiążącą wykładnią prawną.

// co tu nie pokrywamCo tu nie pokrywam

Ten pillar celowo nie jest kompletną analizą NIS2 ani UKSC. Pominąłem:

• pozostałe litery Art. 21 ust. 1 (np. lit. f — polityki oceny skuteczności środków — która też dotyka AI vendor selection);
• szczegółową relację obowiązków notyfikacyjnych z mechanizmem zgłaszania incydentów do CSIRT w scenariuszu wycieku przez dostawcę;
• AI Act i jego klasyfikację systemów wysokiego ryzyka, która może nakładać się na decyzję o dostawcy;
• cross-mapping z ISO 27001 i ISO 42001 (osobna notatka w klastrze compliance);
• konkretną ekonomię build vs buy z liczbami dla średniej firmy 500 FTE;
• techniczną architekturę on-prem deploymentu (GPU sizing, RAG, izolacja sieciowa — to klaster architektura).

Te wątki rozwijam w kolejnych postach klastra.

Powiązane

• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d — pojedynczy artykuł, jeden scenariusz, węższe ujęcie tej samej litery.
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe — kontraktowa strona oceny dostawcy.
• DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje — rozwinięcie Drogi 3 z sekcji o decyzji.
• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny — pillar klastra on-prem, jeśli decyzja idzie w stronę własnej infrastruktury.