NIS2 i transformacja AI w sektorze produkcyjnym: jak OpenKBS zapewnia zgodność z ustawą o krajowym systemie cyberbezpieczeństwa

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (UKSC) weszła w życie 3 kwietnia 2026 r., transponując Dyrektywę (UE) 2022/2555 (NIS2) do polskiego porządku prawnego. Prezydent podpisał ustawę 19 lutego 2026 r., a jej tekst został opublikowany w Dz.U. z 2 marca 2026 r. Organem właściwym w zakresie reagowania na incydenty jest NASK (CSIRT).

Średnie i duże przedsiębiorstwa produkcyjne objęte są zakresem ustawy jako „podmioty ważne" (przedsiębiorstwa zatrudniające co najmniej 50 pracowników i osiągające roczny obrót w wysokości 10 mln EUR, w sektorach wymienionych w Załączniku II Dyrektywy). Dla tych organizacji NIS2 stawia konkretne wyzwanie: jak wdrożyć rozwiązania AI w procesach produkcyjnych, nie zwiększając ryzyka regulacyjnego i cyberbezpieczeństwa. Niniejsza publikacja opisuje, w jaki sposób platforma OpenKBS adresuje wymagania znowelizowanej ustawy UKSC dla swoich klientów enterprise.

Bezpieczeństwo infrastruktury dzięki AWS

OpenKBS buduje infrastrukturę swoich klientów w całości na Amazon Web Services (AWS). Nie jest to wyłącznie wybór dostawcy hostingu — wiąże się z przejęciem obszernego katalogu niezależnie audytowanych certyfikacji i atestacji, w tym:

ISO/IEC 27001 — system zarządzania bezpieczeństwem informacji;
ISO/IEC 22301 — zarządzanie ciągłością działania;
ISO/IEC 27017 — kontrole bezpieczeństwa usług chmurowych;
SOC 2 Type II — kontrole bezpieczeństwa, dostępności, integralności przetwarzania, poufności i ochrony danych osobowych;
C5 — katalog zgodności dla chmury obliczeniowej, opracowany przez niemieckie BSI.

AWS dysponuje ponad 150 niezależnie audytowanymi certyfikacjami bezpieczeństwa na całym świecie. W kontekście UKSC jest to istotne, ponieważ art. 21 ust. 1 Dyrektywy (UE) 2022/2555 wymaga, aby środki zarządzania ryzykiem odzwierciedlały „aktualny stan wiedzy" (state of the art). Korzystanie z certyfikowanej infrastruktury wykazuje spełnienie tej zasady.

Model współdzielonej odpowiedzialności

AWS stosuje model współdzielonej odpowiedzialności (Shared Responsibility Model):

AWS odpowiada za bezpieczeństwo infrastruktury chmurowej — fizyczne centra danych, sieć, hypervisor, usługi zarządzane;
Klient odpowiada za bezpieczeństwo tego, co buduje w chmurze — kod aplikacji, konfiguracje, kontrola dostępu.

Dla klientów enterprise każde rozwiązanie przechodzi ustrukturyzowany proces audytu i przeglądu bezpieczeństwa przed wdrożeniem do produkcji.

Wydzielone konto AWS dla każdego klienta enterprise

Jednym z kluczowych wymagań NIS2 jest zapewnienie ciągłości działania i zarządzania kryzysowego (art. 21 ust. 2 lit. c) Dyrektywy (UE) 2022/2555). Dyrektywa kładzie również nacisk na bezpieczeństwo łańcucha dostaw (art. 21 ust. 2 lit. d)), w tym zarządzanie ryzykami wynikającymi z zależności od dostawców technologicznych.

OpenKBS adresuje te wymagania poprzez model wydzielonych kont AWS.

Jak to działa

Każdy klient enterprise otrzymuje własne konto AWS, w którym są wdrażane wszystkie jego zasoby:

Zasób	Opis
Funkcje Lambda	Obliczenia serverless dla logiki biznesowej (do 20 na projekt)
Magazyn S3	Magazyn obiektowy na pliki i dane
Aurora PostgreSQL	Zarządzana relacyjna baza danych z automatycznymi kopiami zapasowymi i przywracaniem point-in-time
CloudFront CDN	Dystrybucja treści z szyfrowaniem TLS
EventBridge	Zaplanowane zadania i automatyzacje

Zasoby jednego klienta są fizycznie izolowane od zasobów każdego innego klienta na poziomie konta AWS. Nie jest to separacja logiczna (namespace, tag czy sieć wirtualna), lecz twarda granica na poziomie konta, egzekwowana przez AWS Identity and Access Management (IAM).

Przeniesienie infrastruktury po zakończeniu umowy

Po zakończeniu umowy lub w razie potrzeby wydzielone konto AWS może zostać w całości przeniesione na klienta. Proces obejmuje:

Zmianę użytkownika root konta na adres e-mail klienta;
Potwierdzenie przez klienta i ustawienie nowego hasła;
Usunięcie konta z AWS Organization OpenKBS;
Klient dodaje metodę płatności i przejmuje pełną kontrolę;
Klient usuwa dostęp OpenKBS poprzez usunięcie roli IAM cross-account.

Nic nie jest migrowane. Funkcje Lambda nadal działają, dane w S3 i Aurora pozostają na miejscu, dystrybucje CloudFront obsługują ruch bez przerw. Klient uzyskuje pełną kontrolę nad swoją infrastrukturą bez utraty danych i bez przestojów.

Wszystkie zasoby to standardowe prymitywy AWS — bez formatów własnościowych, bez vendor lock-in. Klient może kontynuować zarządzanie infrastrukturą samodzielnie lub z innym dostawcą.

AWS Organizations umożliwia utworzenie do 50 000 kont w ramach jednej organizacji, bez dodatkowych opłat za samo konto. Opłaty naliczane są wyłącznie za zużycie zasobów wewnątrz konta.

Znaczenie dla zgodności z NIS2

Art. 21 ust. 2 lit. c) (ciągłość działania): Infrastruktura nie zależy od statusu operacyjnego OpenKBS. W przypadku zaprzestania działalności dostawcy klient może kontynuować operacje.
Art. 21 ust. 2 lit. d) (bezpieczeństwo łańcucha dostaw): Ryzyko zależności od jednego dostawcy jest zminimalizowane dzięki gwarantowanej możliwości pełnego przeniesienia.
Klauzula 5 wymagań kontraktowych NIS2 (wsparcie przy zakończeniu i bezpieczeństwo danych): Pokryta z założenia — dane znajdują się już na koncie, które klient może w pełni przejąć.

Lokalizacja danych i architektura serverless

Hosting w Unii Europejskiej

Wszystkie zasoby klientów enterprise są wdrażane w regionie AWS eu-central-1 (Frankfurt, Niemcy) domyślnie. Centralna baza danych platformy (AWS Aurora DSQL) działa wyłącznie w eu-central-1.

Dane nie opuszczają terytorium UE. Każdy projekt klienta otrzymuje:

Magazyn S3 w eu-central-1;
Instancję Aurora PostgreSQL w eu-central-1;
Funkcje Lambda wykonywane w eu-central-1;
Dystrybucję CloudFront z lokalizacjami edge w UE.

Lokalizacja danych jest kluczowym czynnikiem w ocenie ryzyka zgodnie z NIS2. Wdrożenie infrastruktury w UE upraszcza spełnienie wymagań dotyczących ochrony danych i ułatwia interakcję z krajowymi organami regulacyjnymi.

Architektura serverless i zmniejszona powierzchnia ataku

OpenKBS wykorzystuje w pełni architekturę serverless dla zasobów klientów. Oznacza to:

Brak serwerów do utrzymania — brak systemu operacyjnego do aktualizacji, brak dostępu SSH, brak otwartych portów;
AWS zarządza środowiskiem uruchomieniowym — Node.js 24.x na Lambda, z automatycznymi aktualizacjami bezpieczeństwa;
Izolacja na poziomie wykonania — każda funkcja Lambda jest wykonywana w oddzielnym środowisku microVM;
TLS 1.2+ dla wszystkich komunikacji — przez CloudFront, bez wyjątków.

Z perspektywy art. 21 ust. 2 lit. e) Dyrektywy (UE) 2022/2555 (bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu sieci i systemów informatycznych), architektura serverless eliminuje całą klasę podatności — niezałatane systemy operacyjne, nieprawidłowo skonfigurowane serwery, nieautoryzowany dostęp sieciowy.

Bezpieczeństwo kodu generowanego przez AI

Rzeczywistość współczesnego rozwoju oprogramowania

Znaczna i rosnąca część kodu programistycznego w przemyśle jest generowana z pomocą modeli AI. Ten trend jest nieodwracalny. Pytanie nie brzmi, czy AI będzie generować kod, lecz jakie procesy zapewniają jakość i bezpieczeństwo tego kodu.

Kod generowany przez AI nie jest z definicji niebezpieczny. Współczesne modele językowe (jak Claude firmy Anthropic) wykrywają podatności w kodzie skuteczniej niż większość ręcznych przeglądów — w tym iniekcje SQL, ataki XSS, nieautoryzowany dostęp, nieprawidłowe zarządzanie sesjami i dziesiątki innych kategorii z OWASP Top 10 i klasyfikacji CWE.

Ryzyko związane z kodem generowanym przez AI nie wynika z samego modelu, lecz z braku procesów audytu i walidacji. System, w którym wygenerowany kod jest wdrażany bezpośrednio bez przeglądu, jest ryzykowny — niezależnie od tego, czy kod został napisany przez człowieka, czy przez AI.

Proces OpenKBS dla klientów enterprise

OpenKBS stosuje ustrukturyzowany proces przeglądu bezpieczeństwa przy każdej nowej wersji rozwiązania klienta:

Automatyczny audyt bezpieczeństwa przy każdej wersji:

Statyczna analiza kodu pod kątem podatności z OWASP Top 10;
Weryfikacja iniekcji SQL, XSS, CSRF, SSRF, command injection;
Analiza zależności (dependency audit) pod kątem znanych podatności (CVE);
Weryfikacja wycieku danych wrażliwych (zakodowane poświadczenia, klucze API, ciągi połączeń);
Walidacja danych wejściowych i kontrola dostępu;
Weryfikacja nieautoryzowanego ujawnienia informacji w odpowiedziach HTTP i obsłudze błędów.

Przegląd infrastruktury:

Przegląd polityk IAM i zasady najmniejszych uprawnień (least privilege);
Walidacja szyfrowania w tranzycie (TLS) i w spoczynku (AES-256);
Weryfikacja publicznie dostępnych zasobów (buckety S3, endpointy Lambda);
Audyt konfiguracji sieciowej i reguł firewalla.

Udokumentowany raport:

Każdy audyt generuje udokumentowany raport z ustaleniami i rekomendacjami;
Krytyczne podatności są usuwane przed wdrożeniem do środowiska produkcyjnego;
Raporty są dostępne dla klienta i mogą być przedstawione organom regulacyjnym podczas audytu.

Ten proces adresuje wymagania art. 21 ust. 2 lit. e) (bezpieczeństwo przy rozwoju i utrzymaniu) oraz art. 21 ust. 2 lit. f) (polityki i procedury oceny skuteczności środków zarządzania ryzykiem).

Konsolidacja łańcucha dostaw AI

Organizacja, która chce korzystać z modeli AI od kilku dostawców (OpenAI, Anthropic, Google), musi zawrzeć odrębne umowy, przeprowadzić odrębne oceny ryzyka i zapewnić zgodność z NIS2 dla każdego z nich.

OpenKBS konsoliduje dostęp do wielu modeli AI za pośrednictwem jednego proxy, działającego w infrastrukturze UE platformy. Klient komunikuje się z jednym dostawcą (OpenKBS), który zarządza integracją z dostawcami AI.

To ogranicza:

liczbę dostawców podlegających ocenie zgodnie z art. 21 ust. 2 lit. d) UKSC;
liczbę umów, które muszą zawierać pięć obowiązkowych klauzul dotyczących bezpieczeństwa łańcucha dostaw;
obciążenie administracyjne przy okresowym przeglądzie dostawców.

Dodatkowe środki zgodności

Szyfrowanie

Zgodnie z art. 21 ust. 2 lit. h) Dyrektywy (UE) 2022/2555 (polityki stosowania kryptografii):

W tranzycie: TLS 1.2+ dla wszystkich komunikacji, bez wyjątków;
W spoczynku: AES-256 dla danych wrażliwych (ciągi połączeń, klucze API), szyfrowanie zarządzane przez AWS dla S3 i Aurora;
Tokeny dostępu: Przechowywane jako hash SHA-256, oryginalny tekst nie jest zapisywany;
Komunikacja MQTT: Połączenia WebSocket podpisane SigV4 z tymczasowymi tokenami sesji STS (ważność 15 minut).

Kontrola dostępu

Zgodnie z art. 21 ust. 2 lit. i) (bezpieczeństwo zasobów ludzkich, kontrola dostępu):

Uwierzytelnianie JWT (RS256) z ograniczonym okresem ważności;
Klucze API per projekt z jawnie zdefiniowanymi uprawnieniami;
Automatyczna rotacja kluczy przy każdym wdrożeniu;
STS session credentials z 15-minutową ważnością dla dostępu cross-account.

Dziennik audytu

Zgodnie z art. 21 ust. 2 lit. f) (ocena skuteczności środków):

Administracyjny dziennik audytu: typ akcji, zasób, którego dotyczy, szczegóły, adres IP;
Śledzenie zużycia zasobów według projektu i okresu;
Metryki CloudWatch dla każdej funkcji (wywołania, czas trwania, błędy).

Kopie zapasowe, przywracanie i plan awaryjny

Zgodnie z art. 21 ust. 2 lit. c) (ciągłość działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe):

Baza danych (Aurora PostgreSQL Serverless v2):

Automatyczne ciągłe kopie zapasowe, zarządzane przez AWS;
Przywracanie do konkretnego momentu w czasie (point-in-time restore) z dokładnością do sekundy, za konfigurowalny okres do 35 dni;
Dane przechowywane w sześciu kopiach rozproszonych w trzech strefach dostępności (Availability Zones) w regionie eu-central-1;
W przypadku awarii instancji głównej Aurora automatycznie przełącza się na replikę zapasową.

Magazyn obiektowy (S3):

Wersjonowanie obiektów — każda zmiana lub usunięcie zachowuje poprzednią wersję;
AWS S3 zapewnia 99,999999999% (11 dziewiątek) trwałości danych;
Dane przechowywane w wielu strefach dostępności w regionie.

Zasady ogólne:

Miękkie usuwanie (soft delete) wszystkich zasobów — bez nieodwracalnego kasowania;
Architektura serverless eliminuje potrzebę przywracania serwerów — w razie awarii instancji Lambda, AWS automatycznie uruchamia nową;
CloudFront CDN zapewnia obsługę ruchu nawet przy częściowej niedostępności serwera źródłowego.

Podsumowanie: pokrycie środków minimalnych z art. 21 NIS2

Środek z art. 21 ust. 2	Jak OpenKBS go adresuje
a) Analiza ryzyka i polityki bezpieczeństwa	Ustrukturyzowany proces audytu przy każdej wersji; udokumentowane raporty
b) Obsługa incydentów	Procedura reagowania na incydenty; 24-godzinne wczesne ostrzeżenie dla klienta
c) Ciągłość działania	Wydzielone konto AWS; Aurora PITR do 35 dni; wersjonowanie S3; 6 kopii w 3 AZ
d) Bezpieczeństwo łańcucha dostaw	Skonsolidowany proxy AI; jedna umowa; konto możliwe do przeniesienia
e) Bezpieczeństwo przy rozwoju i utrzymaniu	Audyt bezpieczeństwa przy każdej wersji; architektura serverless
f) Ocena skuteczności środków	Dziennik audytu; monitorowanie zasobów; metryki CloudWatch
g) Szkolenia z cyberbezpieczeństwa	Konsultacje i dokumentacja dla zespołów klienta
h) Kryptografia i szyfrowanie	TLS 1.2+; AES-256; SHA-256 dla tokenów; SigV4 dla MQTT
i) Kontrola dostępu	Uwierzytelnianie JWT; klucze per projekt; automatyczna rotacja
j) MFA i szyfrowana komunikacja	Szyfrowane połączenia WebSocket; STS session credentials

Następny krok

OpenKBS współpracuje z przedsiębiorstwami produkcyjnymi w Polsce i Europie, które wdrażają rozwiązania AI przy zachowaniu zgodności z wymaganiami UKSC.

Jeśli Twoja organizacja jest objęta zakresem ustawy o krajowym systemie cyberbezpieczeństwa i rozważa transformację AI, skontaktuj się z nami w sprawie konsultacji dotyczącej:

oceny obecnej infrastruktury pod kątem wymagań NIS2;
zaprojektowania rozwiązania AI w wydzielonym koncie AWS z EU Data Residency;
procesów audytu bezpieczeństwa kodu generowanego przez AI;
planu ciągłości działania i zarządzania kryzysowego.

Opisane usługi — audyt bezpieczeństwa, dedykowane konto AWS i przegląd kodu generowanego przez AI — stanowią część planu Enterprise OpenKBS.

Niniejsza publikacja ma charakter informacyjny i nie stanowi porady prawnej. W przypadku konkretnych pytań dotyczących stosowania ustawy o krajowym systemie cyberbezpieczeństwa należy skonsultować się z wykwalifikowanym doradcą prawnym.

Book a Strategy Call

NIS2UKSCcyberbezpieczeństwoprodukcjaprzemysłAWSAIłańcuch dostawenterprise