NIS2 i DORA: jakie wymogi stawia regulacja na AI w Twojej firmie i kiedy własny serwer to jedyne wyjście?

Jeśli Twoja firma podlega pod NIS2 lub DORA, korzystanie z publicznego SaaS AI, jak ChatGPT Enterprise, Azure OpenAI Service czy Google Vertex AI, nie spełnia kilku konkretnych wymogów tych regulacji. Chodzi przede wszystkim o lokalizację danych z art. 30 DORA, prawo do audytu dostawcy ICT i kontrolę nad łańcuchem dostaw wynikającą z art. 21 NIS2. Własna instancja AI działająca na serwerze w Polsce te punkty wypełnia, bo dane nie opuszczają Twojej infrastruktury, a dostęp do logów i konfiguracji masz w każdej chwili.

Kogo dotyczy NIS2, a kogo DORA: dwie regulacje, jeden wspólny problem z AI

NIS2 (dyrektywa UE 2022/2555, wdrożona w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa) obejmuje firmy z kilkunastu sektorów: energetyki, transportu, bankowości, infrastruktury rynków finansowych, ochrony zdrowia, wodociągów, infrastruktury cyfrowej i innych. Podział na podmioty kluczowe i podmioty ważne zależy od wielkości firmy i jej roli w danym sektorze.

DORA (rozporządzenie UE 2022/2554) dotyczy wyłącznie sektora finansowego: banków, zakładów ubezpieczeń, towarzystw funduszy inwestycyjnych, domów maklerskich, instytucji płatniczych, SKOK-ów. Jako rozporządzenie stosuje się bezpośrednio, bez krajowej transpozycji, od 17 stycznia 2025 roku.

Obie regulacje stoją na tym samym założeniu: firma nie może zarządzać ryzykiem ICT, jeśli nie wie, gdzie leżą jej dane i kto nimi dysponuje. AI przetwarza dane operacyjne. Każdy zewnętrzny system AI to nowy dostawca, który wymaga formalnej oceny i dokumentacji. I właśnie tu zaczyna się problem z publicznym SaaS.

Co art. 21 NIS2 mówi o dostawcach AI i łańcuchu dostaw

Artykuł 21 ust. 2 NIS2 wymienia środki zarządzania ryzykiem, które każdy objęty podmiot musi wdrożyć. Dwa z nich bezpośrednio dotyczą każdego wdrożenia AI:

• Lit. d: "bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa dotyczące stosunków między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami". Każdy zewnętrzny system AI, który przetwarza dane firmowe, staje się ogniwem łańcucha dostaw. Musisz ocenić jego ryzyko, udokumentować tę ocenę i być gotowy pokazać ją podczas kontroli.
• Lit. e: bezpieczeństwo w procesie nabywania i utrzymania sieci i systemów informatycznych, w tym postępowanie z podatnościami. Wdrożenie narzędzia AI bez formalnej oceny bezpieczeństwa tego procesu narusza ten punkt.

Artykuł 23 dodaje obowiązek zgłaszania poważnych incydentów: wstępne powiadomienie w ciągu 24 godzin od wykrycia, pełny raport w ciągu 72 godzin. Jeśli incydent dotknął systemu AI działającego po stronie zewnętrznego SaaS, a dostawca nie udostępnił Ci logów zdarzenia, nie jesteś w stanie sporządzić rzetelnego raportu dla CSIRT. Proste jak budowa cepa, a w praktyce blokuje compliance.

DORA idzie dalej: lokalizacja danych i prawo do audytu to obowiązkowe zapisy w każdej umowie ICT

DORA jest precyzyjniejsza niż NIS2, bo to rozporządzenie, a nie dyrektywa. Stosuje się wprost, bez żadnych krajowych furtek.

Artykuł 30 ust. 2 określa, co musi zawierać każda umowa z zewnętrznym dostawcą ICT. Dwa punkty są tu nie do pominięcia:

• Lit. g: "miejsce, w którym dane są przechowywane i przetwarzane, w tym Unia Europejska, oraz wymogi dotyczące przechowywania danych przez dostawcę zewnętrznego w przypadku przetwarzania danych poza Unią Europejską". To nie sugestia negocjacyjna. To obowiązkowy zapis w kontrakcie z każdym dostawcą ICT, w tym z dostawcą systemu AI.
• Lit. d: pełna współpraca podczas inspekcji i audytów przeprowadzanych przez podmiot finansowy, właściwy organ lub wyznaczonego przez nich audytora zewnętrznego.

Pytanie praktyczne, które słyszę od compliance officerów: czy OpenAI, Microsoft ani Google podpiszą umowę, w której zgadzają się na audyt swojej infrastruktury przez Twoją firmę lub przez KNF? Standardowe warunki ich usług API tego prawa nie dają. Raporty SOC 2 i certyfikat ISO 27001 dostawcy to nie audit clause z art. 30 DORA. To dwie różne rzeczy.

Artykuł 28 ust. 4 DORA wymaga ponadto, żeby podmiot finansowy ocenił ryzyko koncentracji ICT wynikające z uzależnienia od jednego zewnętrznego dostawcy. Duże modele językowe dostępne przez publiczne API to dziś infrastruktura dla setek tysięcy podmiotów finansowych jednocześnie. Awaria po stronie dostawcy to awaria po Twojej stronie, a ESMA i EBA w wytycznych do DORA wskazują taką koncentrację jako ryzyko wymagające udokumentowania i ograniczenia.

Trzy konkretne miejsca, gdzie SaaS AI odpada przy kontroli regulatora

Typowy scenariusz: audyt wewnętrzny albo kontrola KNF pyta o rejestr dostawców ICT z wymaganymi zapisami umownymi z art. 28 DORA i o dowody oceny ryzyka łańcucha dostaw z art. 21 NIS2. Przy korzystaniu z publicznego SaaS AI trzy braki pojawiają się regularnie:

• Lokalizacja danych bez gwarancji. Publiczne API AI działają na serwerach w różnych regionach. Nawet jeśli wybrałeś centrum danych w UE, standardowa umowa nie gwarantuje, że każde zapytanie przetworzy się wyłącznie w Polsce ani że dane nie trafią do regionu poza UE przy wysokim obciążeniu sieci.
• Brak prawa do audytu w umowie. Standardowe warunki usług API dużych dostawców AI nie zawierają klauzuli audytowej zgodnej z art. 30 ust. 2 lit. d DORA. Umowy enterprise można negocjować, ale dostęp do fizycznej infrastruktury dostawcy i do logów zdarzeń na poziomie wymaganym przez regulatora to rzadko osiągalny zapis.
• Wielowarstwowy łańcuch sub-procesorów. OpenAI działa na Azure. Azure ma własnych podwykonawców centrów danych. Google Cloud obsługuje infrastrukturę globalnie. W raportowaniu DORA musisz umieć prześledzić łańcuch do końca. Przy publicznym SaaS jest to praktycznie niemożliwe na poziomie, który zadowoli audytora.

Co zmienia własna instancja AI na serwerze w Polsce

Własna instancja AI to model językowy uruchomiony na wydzielonym serwerze w Polsce. Dane firmowe nie opuszczają tej infrastruktury. Żadne zapytanie nie trafia do zewnętrznego API.

W kontekście NIS2 i DORA przekłada się to na kilka wymiernych zmian:

• Lokalizacja danych jest udokumentowana. Serwer ma adres, centrum danych ma certyfikat, umowa wskazuje konkretne miejsce przetwarzania. Spełniony jest wymóg z art. 30 ust. 2 lit. g DORA.
• Prawo do audytu jest realne. Logi konwersacji, konfiguracja modelu, historia zmian i zasoby obliczeniowe są dostępne dla administratora firmy i dla audytora. Przy wdrożeniu RedAI te elementy są częścią dokumentacji przekazywanej klientowi i podlegają klauzulom audytowym w umowie.
• Rejestr dostawców ICT jest przejrzysty. Jeden dostawca, jedna umowa, jeden wpis w rejestrze. Zamiast wielowarstwowego łańcucha: SaaS plus chmura plus sub-processorzy.
• Ciągłość działania pod Twoją kontrolą. Artykuł 12 DORA wymaga polityk tworzenia kopii zapasowych i procedur przywracania systemu. Własna instancja AI umożliwia lokalny backup, failover i testy odtwarzania na warunkach, które ustalasz sam, nie jakie daje Ci dostawca SaaS w regulaminie.

Jeden z naszych klientów z sektora finansowego wdrożył AI do wstępnej analizy wniosków kredytowych. Zanim trafił do nas, używał publicznego API. Przy pierwszym audycie wewnętrznym ICT nie potrafił wykazać lokalizacji danych ani prawa do audytu dostawcy. Przejście na własną instancję na serwerze w Polsce wypełniło obydwa braki i skróciło czas przygotowania dokumentacji audytowej z kilku tygodni do jednego dnia roboczego.

Od czego zacząć, gdy compliance AI trafia na agendę zarządu

Krok pierwszy: zrób inwentarz. Które procesy w firmie korzystają już z AI lub planują to robić? Shadow AI, czyli pracownicy korzystający z ChatGPT czy Copilota na własnych kontach, to ukryty wpis w łańcuchu dostaw, którego nie widać w rejestrach ICT. Warto sprawdzić, co działa poza formalnym nadzorem, zanim pojawi się kontrola.

Krok drugi: oceń obecne umowy. Czy Twoi dostawcy SaaS AI mają zapisy wymagane przez art. 30 DORA: lokalizacja danych, prawo audytu, uzgodnione poziomy usług? W większości standardowych umów tych zapisów po prostu nie ma.

Krok trzeci: porównaj modele wdrożenia. Własna instancja AI na serwerze w Polsce, chmura prywatna w krajowym centrum danych z gwarantowaną lokalizacją, publiczny SaaS z renegocjowaną umową enterprise. Każdy z nich inaczej wygląda w rejestrze ICT i inaczej radzi sobie z wymogami audytowymi.

Jeśli chcesz przejść przez ten proces z pomocą i zobaczyć, gdzie Twoja infrastruktura AI wymaga korekty pod kątem NIS2 lub DORA, umów się na bezpłatny audyt. Możesz też zajrzeć na stronę z realnymi wdrożeniami, gdzie opisujemy przypadki firm z sektorów objętych regulacją.