Compliance

Stary system to dług prawny i ryzyko zarządu, nie tylko dług techniczny

W wielu szpitalach i przychodniach działa taki system. Program w pracowni, stary moduł apteczny albo rozliczeniowy, stacja przy aparacie diagnostycznym z systemem operacyjnym, którego producent dawno nie łata. Działa od lat, nikt nie ma do niego aktualnej dokumentacji i nikt do końca nie wie, jak funkcjonuje pod spodem. Dopóki działa, problem wydaje się czysto techniczny: kiedyś trzeba będzie go wymienić. Dziś to za mało.

W świetle RODO, znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa, która wdraża dyrektywę NIS 2, W świetle RODO i znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa, która wdraża dyrektywę NIS 2, stary system bez dokumentacji, bez wsparcia producenta i bez dostępu do danych przestaje być wyłącznie długiem technicznym. Staje się długiem prawnym, a ustawa o KSC przypisuje odpowiedzialność za cyberbezpieczeństwo wprost kierownikowi podmiotu. Skala ma tu znaczenie: przychodnia z jednym systemem ma jeden taki problem do opisania, szpital z systemem szpitalnym, laboratorium, pracownią obrazową i rozliczeniami ma ich wiele, powiązanych ze sobą. Więcej o doborze rozwiązań do wielkości placówki: kwestia skali w IT.

Zgodność z przepisami przesuwa się od papieru ku technice

Przez lata zgodność z przepisami sprowadzała się do dokumentów: polityk, procedur, list kontrolnych. Kierunek się zmienia. Przepisy i organy nadzoru nadal pytają o dokumenty, a do tego o to, czy placówka realnie panuje nad swoją infrastrukturą techniczną.

Samo odhaczenie wymogów przestaje wystarczać. RODO wymaga, by administrator potrafił wykazać przestrzeganie zasad przetwarzania (art. 5 ust. 2 i art. 24 ust. 1 RODO) i stosował środki bezpieczeństwa odpowiednie do ryzyka (art. 32 ust. 1 RODO). Znowelizowana ustawa o KSC wymaga od podmiotu kluczowego lub ważnego między innymi regularnych aktualizacji oprogramowania stosownie do zaleceń producenta i monitorowania systemu informacyjnego w trybie ciągłym (art. 8 ust. 1 pkt 5 lit. b i pkt 2 lit. g ustawy o KSC). Rośnie też liczba organów, które mogą kontrolować. Poza Prezesem UODO i organami właściwymi do spraw cyberbezpieczeństwa dochodzi nadzór rynku systemów sztucznej inteligencji: w Polsce pełni go Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (art. 5 ust. 1 ustawy z 3 lipca 2026 r. o systemach sztucznej inteligencji, Dz.U. 2026 poz. 1003). W sektorze finansowym działa dodatkowo rozporządzenie DORA, stosowane od 17 stycznia 2025 r. (art. 2 ust. 1 i art. 64 rozporządzenia (UE) 2022/2554), które szpitali ani przychodni nie obejmuje.

Gdzie dokładnie powstaje dług prawny

Stary system rzadko ma jeden problem. Zwykle ma ich kilka naraz, a każdy z osobna potrafi zaświecić się na czerwono w analizie ryzyka.

Dokumentacja widmo. Bez rzetelnej dokumentacji nie da się przeprowadzić analizy ryzyka, której wymagają art. 32 ust. 2 RODO i art. 8 ust. 1 pkt 1 ustawy o KSC. Nie wiadomo, jak dane płyną wewnątrz systemu, więc nie sposób ocenić ryzyk cybernetycznych ani tych związanych z ochroną danych. W razie kontroli nieumiejętność wyjaśnienia, jak system działa i jak przetwarza dane, oznacza, że administrator nie wykaże zgodności, a ten obowiązek spoczywa na nim (art. 5 ust. 2 RODO). Do tego stare systemy często nie zapisują, kto i kiedy miał dostęp do danych, a bez takiego zapisu trudno obsłużyć incydent i ustalić jego zakres.

Wiedza tylko w głowach ludzi. Część procesów istnieje wyłącznie w głowach pracowników, często już byłych: informatyk, który jako jedyny wiedział, jak wyeksportować dane do rozliczeń, statystyk, który znał obejście błędu w raporcie. Gdy taka osoba odchodzi, placówka zostaje z procesem, którego nikt nie potrafi opisać. Stąd częsta obserwacja: dopiero przy analizie przedwdrożeniowej dyrekcja dowiaduje się, jak naprawdę działa jej szpital.

Brak dostępu do danych i dokumentacji, zależność od dostawcy. Wiele systemów legacy opiera się na umowach sprzed dekady, w których nie ma klauzul o dokumentacji, eksporcie danych, zasadach modyfikacji ani wyjściu z umowy. Placówka staje się zakładnikiem dostawcy, który jako jedyny dysponuje wiedzą techniczną. Nawet kod złożony kiedyś w escrow bywa wart niewiele, jeśli nikt nie wie, co tam realnie jest i czy był aktualizowany. Realne scenariusze: dostawca znika z rynku, zmienia model biznesowy albo ogłasza migrację wszystkiego do chmury, i zaczynają się schody. Podmiot kluczowy lub ważny musi przy tym zadbać o bezpieczeństwo i ciągłość łańcucha dostaw, uwzględniając podatności związane z dostawcą i ogólną jakość jego produktów (art. 8 ust. 1 pkt 2 lit. e i art. 8 ust. 2 pkt 1 i 2 ustawy o KSC).

Koniec wsparcia producenta (end-of-life). Utrzymywanie systemu, dla którego producent nie wydaje już poprawek bezpieczeństwa, jest akceptacją wysokiego ryzyka. Ustawa o KSC wymaga regularnych aktualizacji oprogramowania i niezwłocznego działania po dostrzeżeniu podatności (art. 8 ust. 1 pkt 5 lit. b i d ustawy o KSC). System, którego nie da się zaktualizować, utrudnia wykonanie tego obowiązku, a ignorowanie raportów o krytycznych lukach trudno obronić jako należytą staranność.

Brak izolacji. Systemy legacy są zwykle powiązane z innymi: wymieniają pliki, mają wspólne konta, stoją w tej samej sieci co stanowiska lekarzy. Bez podziału sieci infekcja jednego potrafi rozlać się na pozostałe. Nieaudytowany, niezabezpieczony system to najsłabsze ogniwo, a często przechowuje najwięcej danych pacjentów z wielu lat.

Paradoks modernizacji: AI dokłada podatności

Modernizacja przez sztuczną inteligencję bywa przedstawiana jako rozwiązanie problemu legacy. Ma też drugą stronę. Systemy oparte o AI wnoszą nowe rodzaje podatności, na przykład podatność na ukryte polecenia w danych wejściowych, a budując rozwiązania agentowe na starym fundamencie, dokładamy kolejne warstwy ryzyka.

Dochodzi do tego natura agentów. Agent z założenia ma wykonać zlecone zadanie i sięgnąć po dane, których potrzebuje. Jeśli dostaje je ze starego systemu, który nie zna ról i nie zapisuje odczytów, dostaje wszystko, a po fakcie nikt nie ustali, czyje dane przeczytał. Zanim agent dostanie dostęp do danych pacjentów, dostęp musi przejść przez warstwę z kontrolą uprawnień i dziennikiem zdarzeń. Masowa dostępność AI obniża też barierę wejścia dla atakujących: przestarzałe mechanizmy stają się łatwym celem dla zautomatyzowanych skanerów. Rozporządzenie (UE) 2024/1689 o sztucznej inteligencji obowiązuje od 1 sierpnia 2024 r. i jest stosowane etapami (art. 113 AI Act); od 2 lutego 2025 r. stosuje się art. 4 AI Act, według którego podmiot stosujący system AI podejmuje środki wspierające rozwój kompetencji personelu w zakresie AI (w brzmieniu nadanym rozporządzeniem (UE) 2026/1744).

Dlaczego to ryzyko osobiste zarządu

W Polsce dyrektywę NIS 2 wdraża ustawa o krajowym systemie cyberbezpieczeństwa znowelizowana ustawą z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), w życiu od 3 kwietnia 2026 r. Kierownik podmiotu kluczowego lub ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa, w tym za system zarządzania bezpieczeństwem informacji (art. 8c ust. 1 ustawy o KSC). Odpowiada także wtedy, gdy powierzył obowiązki innej osobie (art. 8c ust. 3), a gdy kierownikiem jest wieloosobowy zarząd i nie wskazano osoby odpowiedzialnej, odpowiadają wszyscy jego członkowie (art. 8c ust. 2). Kierownik raz w roku kalendarzowym przechodzi udokumentowane szkolenie (art. 8e ust. 1 i 3). W SPZOZ, który jest jednostką sektora finansów publicznych, kierownikiem w rozumieniu ustawy jest kierownik tej jednostki, a w spółce kierownik jednostki w rozumieniu ustawy o rachunkowości, czyli zwykle zarząd (art. 2 pkt 8a ustawy o KSC). Szczegóły obowiązków i terminów: NIS2 w szpitalu krok po kroku.

Kary pieniężne mogą być nakładane na podmiot i bezpośrednio na kierownika podmiotu (art. 73 i art. 73a ustawy o KSC). Podmioty objęte ustawą w dniu wejścia nowelizacji w życie mają 12 miesięcy, czyli do 3 kwietnia 2027 r., na wdrożenie obowiązków (art. 33 ust. 1 nowelizacji), a kary z art. 73 ust. 1 do 4 i art. 73a mogą być po raz pierwszy nałożone po upływie dwóch lat od wejścia nowelizacji w życie, czyli po 3 kwietnia 2028 r. (art. 35 nowelizacji).

Niezależnie od KSC, gdy szpital albo przychodnia działa jako spółka, członek zarządu ma obowiązek dołożyć staranności wynikającej z zawodowego charakteru swojej działalności (art. 209¹ § 1 i art. 377¹ § 1 Kodeksu spółek handlowych) i odpowiada wobec spółki za szkodę wyrządzoną działaniem lub zaniechaniem sprzecznym z prawem, chyba że nie ponosi winy (art. 293 § 1 i art. 483 § 1 KSH). Sama akceptacja ryzyka, bez realnych działań naprawczych, nie zamyka więc tematu. Działa też efekt łańcucha dostaw: podmiot nieobjęty bezpośrednio ustawą bywa weryfikowany, jeśli jest dostawcą dla podmiotu kluczowego lub ważnego, bo ten musi ocenić bezpieczeństwo swoich dostawców (art. 8 ust. 2 ustawy o KSC).

Osobny obowiązek to ciągłość działania: podmiot kluczowy lub ważny wdraża, dokumentuje, testuje i utrzymuje plany ciągłości działania, plany awaryjne i plany odtworzenia działalności (art. 8 ust. 1 pkt 2 lit. f ustawy o KSC). Przy nieudokumentowanym systemie legacy bywa to niemożliwe do wykazania. Dokumentacja ma wartość dowodową wtedy, gdy powstała wcześniej. Dokumentacją pisaną na gorąco, już po incydencie, trudno wykazać staranność. Praktyczny sprawdzian: czy ktoś w placówce odtworzył ten system z kopii i zapisał, ile to trwało.

Co z tym zrobić

Starego systemu nie trzeba wymieniać z dnia na dzień. Trzeba świadomie panować nad jego ryzykiem i umieć to udokumentować.

Audyt systemów krytycznych. Sprawdź, które systemy nie mają dokumentacji, wsparcia ani zapisu zdarzeń. Przejrzyj stare kontrakty: jakie prawa do korzystania z systemu i do jego modyfikacji daje licencja, jakie są zasady serwisu, eksportu danych i wyjścia z umowy. Pomaga w tym lista kontrolna umowy z dostawcą.
Plan utrzymania i ciągłości działania. Dla każdego systemu krytycznego określ plan aktualizacji, plan przywracania pracy po incydencie i scenariusz na wypadek zniknięcia dostawcy. Sprawdź odtworzenie z kopii w praktyce (protokół testu odtworzenia kopii) i ustal, jak oddziały pracują, gdy systemu nie ma (praca bez systemu przez 72 godziny).
Izolacja. Oddziel systemy legacy, zwłaszcza stacje bez wsparcia producenta, w osobnych segmentach sieci z ruchem ograniczonym do tego, co niezbędne, tak by ewentualna infekcja nie rozlała się na resztę infrastruktury.
Dostęp do danych i dokumentacji. Eksport danych w udokumentowanym formacie, dostęp do nich przez interfejs z kontrolą uprawnień i dziennikiem zdarzeń oraz pełna dokumentacja zmniejszają zależność od jednego dostawcy i ułatwiają wykazanie kontroli nad systemem. Dane należą do placówki. Kto ma prawa do oprogramowania oraz do modeli i ustawień wytworzonych na danych placówki, określa umowa, dlatego warto to w niej zapisać wprost.
Spisanie wiedzy z głów ludzi. Opisanie nieudokumentowanych procesów, dziś coraz częściej z pomocą narzędzi AI, porządkuje pracę i jest jednocześnie dowodem staranności.

Od czego zacząć

Pierwszy krok to lista systemów, dla których nikt w placówce nie odpowie dziś na trzy pytania: jak działa, kto go wspiera i jak długo potrwa odtworzenie po awarii. Obok każdego warto wpisać roczny koszt utrzymania, bo stary system, który po prostu działa, rzadko jest tani, gdy doliczyć ludzi, obejścia i ryzyko. Do uporządkowania obowiązków z ustawy przydaje się lista kontrolna KSC 2027, a do porównania kosztu pozostania przy starym systemie z kosztem zmiany kalkulator kosztu systemu na 5 lat.

Co chcecie osiągnąć i ile kosztuje was dziś utrzymanie tego, czego nikt nie potrafi opisać?

Stan prawny na 7 października 2026 r. Zobacz, jak prowadzimy zmianę systemów w placówkach, albo przejrzyj pozostałe materiały w sekcji wiedzy.

Wróć do sekcji Wiedza