Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d

Notatka techniczna o jednym artykule i jednym scenariuszu. Średnia firma produkcyjna, podmiot kluczowy w rozumieniu NIS2, chce użyć ChatGPT Enterprise albo Claude do generowania instrukcji pracy. Pytanie compliance, które trafia na biurko CISO: czy umowa z publicznym dostawcą LLM spełnia wymagania Art. 21 ust. 1 lit. d dyrektywy NIS2 w zakresie bezpieczeństwa łańcucha dostaw?

Krótka odpowiedź: nie zawsze "nie", ale częściej "trzeba udokumentować, dlaczego tak" niż "jest oczywiście OK".

Co dokładnie mówi Art. 21 ust. 1 lit. d

Dyrektywa 2022/2555 (NIS2) wymaga w Art. 21 ust. 1, żeby podmioty kluczowe i ważne wdrożyły odpowiednie i proporcjonalne środki zarządzania ryzykiem w cyberbezpieczeństwie. Litera d brzmi (w skrócie): bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa dotyczące relacji między podmiotem a jego bezpośrednimi dostawcami lub usługodawcami.

Co istotne, ust. 3 doprecyzowuje, że ocena tych relacji ma uwzględniać:

• specyficzne podatności każdego bezpośredniego dostawcy,
• ogólną jakość produktów i praktyk cyber dostawcy,
• praktyki bezpiecznego rozwoju produktów u dostawcy.

ENISA w wytycznych z 2024 i 2025 r. mówi to wprost: to nie jest tylko o klasycznym IT vendor management. Dotyczy każdego dostawcy, który dotyka systemów lub danych objętych zakresem NIS2. Dostawca generatywnej AI, do którego trafia treść techniczna podmiotu kluczowego, mieści się w tym zakresie bez dyskusji.

Anatomia relacji z dostawcą public cloud LLM

Kiedy podmiot kluczowy używa ChatGPT Enterprise, Claude for Work albo Gemini Enterprise, łańcuch dostaw nie kończy się na vendorze. Każdy z głównych dostawców LLM stoi na infrastrukturze hyperscalera:

• OpenAI: znaczna część infrastruktury produkcyjnej na Microsoft Azure.
• Anthropic: AWS i GCP jako platformy obliczeniowe.
• Google: własna infrastruktura, ale z licznymi sub-processorami.

Z perspektywy Art. 21 ust. 1 lit. d to oznacza, że ocena ryzyka łańcucha dostaw obejmuje nie jednego, lecz minimum dwóch dostawców (vendor LLM plus jego hyperscaler), a często więcej (CDN, observability, billing, support).

Trzy obszary, w których standardowa relacja ma trudność

Z analizy publicznie dostępnych umów (DPA, master service agreements, sub-processor lists) wyłaniają się trzy obszary, w których standardowa relacja z public cloud LLM rzadko spełnia wymagania Art. 21 ust. 1 lit. d bez dodatkowych negocjacji.

1. Sub-processors i transparencja łańcucha

Standardowy DPA pozwala vendorowi LLM dodawać i zmieniać sub-processorów z ograniczonym uprzedzeniem (typowo 30 dni). Dla podmiotu kluczowego, który musi udokumentować pełną listę dostawców w mapowaniu Art. 21, oznacza to ciągły obowiązek monitorowania zmian po stronie vendora. W praktyce: ktoś w organizacji co miesiąc weryfikuje sub-processor list i aktualizuje rejestr ryzyk.

2. Audit rights i prawo do weryfikacji

Klasyczna enterprise SaaS pozwala na audyt, ale w wąskich ramach: roczna częstotliwość, wynajęty audytor, scope ograniczony do certyfikatów (SOC 2, ISO 27001). Art. 21 ust. 3 wymaga oceny "praktyk bezpiecznego rozwoju produktów" dostawcy. Ile vendorów LLM zgodzi się na audyt MLOps pipeline, training data governance, model lifecycle management? W praktyce: bardzo niewielu, a jeśli się zgodzą, sam audyt kosztuje 50 do 150 tysięcy euro w godzinach pracy audytora i prawnika.

3. Incident notification i czas reakcji

NIS2 wymaga, żeby podmiot kluczowy zgłosił poważny incydent do CSIRT w ciągu 24 godzin od wykrycia. Jeśli incydent dzieje się po stronie dostawcy LLM (np. wyciek danych w hyperscalerze), podmiot kluczowy musi się o tym dowiedzieć szybciej niż przewiduje standardowe SLA na poziomie "uptime 99,9 procent". Typowa umowa z public cloud LLM nie gwarantuje notyfikacji w godzinach (zazwyczaj formuła "bez zbędnej zwłoki"). To znaczy: trzeba aktywnie monitorować, nie polegać na vendor notification.

Co to znaczy w praktyce

Nie znaczy "nie wolno używać public cloud LLM". Znaczy: jeśli używasz, w mapowaniu Art. 21 powinieneś mieć udokumentowane:

• listę sub-processorów aktualizowaną co miesiąc,
• analizę ryzyka dla każdego sub-processora,
• mechanizm monitorowania zmian w sub-processor list,
• alternatywne mechanizmy audytu (np. SOC 2 Type II report, security questionnaire, third-party attestation),
• runbook na incident response w przypadku wycieku po stronie vendora,
• mapowanie data residency dla każdego rodzaju przetwarzanej treści,
• decyzję compliance: które kategorie dokumentów wolno wysłać do vendora, a które nie.

To realna praca. Dla średniej firmy 200 do 500 FTE z jednym compliance lead i pół etatem CISO to często 4 do 6 tygodni roboty na samo udokumentowanie, plus ongoing maintenance. Dla porównania, ten sam zespół w tym samym oknie może zaplanować pilot on-prem deployment, w którym data residency rozwiązuje się z definicji.

Czerwone flagi w umowie z dostawcą

Krótka lista do weryfikacji przed podpisaniem MSA z public cloud LLM. Jeśli któryś punkt nie da się rozwiązać kontraktowo, warto się zatrzymać i policzyć alternatywę.

• Brak konkretnej listy sub-processorów (tylko "lista jest dostępna online") plus brak SLA na powiadomienie o zmianie.
• Audit rights ograniczone do certyfikatów, bez prawa do operational audit.
• Incident notification ograniczone do incydentów "wpływających na klienta" (kto definiuje wpływ?).
• Data residency określona tylko na poziomie regionu (np. EU), bez gwarancji konkretnego DC.
• Brak mechanizmu data deletion po zakończeniu umowy z SLA potwierdzającym.
• Limitacja odpowiedzialności vendora na poziomie 12-miesięcznych opłat. Przy potencjalnej karze 10 mln euro lub 2 procent obrotu globalnego po stronie podmiotu kluczowego to asymetria, której zarząd powinien się przyjrzeć osobno.

// disclosure i biasesDisclosure i biases

Autor (Fryderyk Pryjma) pracuje nad on-prem AI platform dla europejskich producentów. Analiza tu może być stronnicza w kierunku rozwiązań alternatywnych wobec public cloud LLM. Tam, gdzie ta stronniczość mogłaby zaważyć na wnioskach, starałem się zaznaczać inline. Szacunki czasu pracy compliance team przy public cloud są moją oceną na podstawie kilku rozmów z compliance leadami, nie publicznymi danymi.

// co tu nie pokrywamCo tu nie pokrywam

Tej notatki nie należy czytać jako wyczerpującej analizy Art. 21. Pominąłem:

• pozostałe litery Art. 21 ust. 1 (a do j); niektóre, np. lit. f (polityki oceny skuteczności środków), też mają konkretne implikacje dla AI vendor selection,
• relację Art. 21 z Art. 23 (obowiązki notyfikacyjne) w scenariuszu wycieku przez vendora LLM,
• specyficzne wymagania państw członkowskich w transpozycji NIS2 (polska UKSC po nowelizacji z 3 kwietnia 2026, niemiecki NIS2UmsG, francuski LPM),
• AI Act i jego klasyfikację high-risk AI, która może dodatkowo wpływać na decyzję vendor,
• ekonomię build vs buy z konkretnymi liczbami dla średniej firmy 500 FTE,
• techniczne możliwości private deployment hyperscaler offerings (Azure OpenAI Dedicated, Google Distributed Cloud), które zasługują na osobną analizę kalibracyjną.

Te tematy znajdą się w kolejnych notatkach.