Pracownik zgłasza, że nie może zalogować się do systemu. Informatyk podejrzewa awarię, ale w logach widzi też nietypowe próby dostępu. Po godzinie usługa znów działa. Czy sprawę można zamknąć jako krótką przerwę techniczną? A może był to incydent, który trzeba zgłosić?

Takiej decyzji nie warto podejmować wyłącznie na podstawie tego, jak szybko udało się przywrócić system. Zgodnie z ustawą o krajowym systemie cyberbezpieczeństwa incydentem jest zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych. Liczy się więc również możliwy skutek, nawet jeśli na początku nie znamy jeszcze pełnego zakresu zdarzenia.

Najpierw ustalmy, co się wydarzyło

Przy pierwszej ocenie sprawdziłabym, czy zdarzenie wpłynęło na dostępność usługi lub danych, ich integralność, autentyczność albo poufność. Niedostępność systemu jest zwykle widoczna od razu. Nieuprawniona zmiana danych lub skopiowanie ich przez osobę trzecią może wyjść na jaw znacznie później.

Warto odnotować godzinę wykrycia, system i usługę, których dotyczy zdarzenie, oraz to, co już wiemy i czego jeszcze nie udało się potwierdzić. Odpowiedź „nie ustalono” jest uczciwsza niż „nie”, wpisane tylko dlatego, że brakuje dowodów. Do oceny trzeba wrócić, gdy pojawią się nowe informacje.

Kiedy incydent jest poważny?

Ustawa wiąże tę kwalifikację między innymi z poważnym obniżeniem jakości lub przerwaniem ciągłości świadczenia usługi przez podmiot kluczowy albo ważny, stratami finansowymi tego podmiotu oraz poważną szkodą materialną lub niematerialną dla innych osób i podmiotów. Także tutaj należy brać pod uwagę skutki, które incydent może spowodować.

Od początku sierpnia pojawił się nowe obowiązki dotyczące przejrzystości korzystania ze sztucznej inteligencji, wynikające z AI Act. Najważniejsze jest to, aby podkreślić, że nie każde użycie AI trzeba oznaczać.

Kluczowe zmiany dotyczą konieczności m.in. przepisy dotyczące informowania o interakcji z AI, oznaczania określonych treści generowanych lub zmienianych przez AI, deepfake’ów oraz niektórych tekstów dotyczących spraw leżących w interesie publicznym. Trzeba przy tym rozróżnić obowiązki dostawcy systemu AI od obowiązków podmiotu stosującego AI.

Dostawca systemu AI ma m.in. zapewnić możliwość wykrycia, że określone treści zostały wygenerowane lub zmodyfikowane przez AI. Chodzi m.in. o oznaczenia w formacie nadającym się do odczytu maszynowego. Nas – jako użytkowników takich narzędzi – zdecydowanie częściej będzie interesował drugi przypadek.

Co muszę zrobić z materiałem, który powstał przy wykorzystaniu AI, zanim go opublikuję, aby nie naruszyć nowych przepisów?

Jeżeli tworzymy realistyczne zdjęcie ludzi uczestniczących w koncercie, który nigdy się nie odbył, albo wykorzystujemy prawdziwe zdjęcie sali, ale AI dodaje do niego publiczność, dekoracje czy występujących artystów – powinna zapalić się nam czerwona lampka. Odbiorca może przecież pomyśleć: „Tak wyglądało to wydarzenie”, chociaż w rzeczywistości nigdy tak nie wyglądało. Obowiązek oznaczenia treści powstaje zawsze wtedy, gdy takie narzędzie generuje nową rzeczywistość, tzn. wygeneruje osobę, zmieni istotnie jej wygląd, stworzy nowe tło, doda elementy, których na zdjęciu wcześniej nie było, wygeneruje głos albo całe nagranie. Może np. na bazie prawdziwego zdjęcia wygenerować nowe, wskazujące osoby znajdujące się na tym zdjęciu w nowych okolicznościach. Nie ma znaczenia, czy na zdjęciu jesteśmy my sami, czy ktoś inny. Nie ma znaczenia, czy okoliczności są negatywne (kompromitująca sytuacja), czy pozytywne (zdjęcie z wakacji, na których nigdy nie byliśmy).

I właśnie przed takim wprowadzaniem odbiorcy w błąd mają chronić przepisy AI Act.

3 kwietnia 2026 r. weszła w życie duża nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC), wdrażająca w Polsce dyrektywę NIS2. I choć wiele organizacji kojarzy nowe przepisy głównie z „dużymi operatorami infrastruktury krytycznej”, w praktyce ustawa obejmuje dziś znacznie szerszą grupę podmiotów – również samorządy, spółki komunalne, instytucje kultury, dostawców IT czy średnie firmy świadczące usługi cyfrowe.

W ostatnich tygodniach bardzo często słyszę pytania:

• „Czy nas to już dotyczy?”,
• „Czy musimy się rejestrować?”,
• „Skąd mamy wiedzieć, czy jesteśmy podmiotem ważnym albo kluczowym?”,
• „Czy trzeba czekać na decyzję ministra?”,
• „Czy infrastruktura krytyczna to to samo co podmiot kluczowy?”.

Postaram się udzielić prostych odpowiedzi na te pytania. Najważniejsze brzmi:

Kiedy podmiot zostaje uznany za podmiot kluczowy lub podmiot ważny w rozumieniu ustawy KSC?

Nowelizacja odeszła od wcześniejszego modelu „operatorów usług kluczowych” i wprowadziła dwa nowe poziomy podmiotów, tzn. kluczowe i ważne. Obie grupy są częścią krajowego systemu cyberbezpieczeństwa (zgodnie z art. 4 ustawy KSC) i najprościej mówiąc:

• podmiot kluczowy to organizacja o największym znaczeniu dla państwa, gospodarki lub społeczeństwa,
• podmiot ważny to organizacja istotna, ale o nieco mniejszym znaczeniu systemowym.

W praktyce obie grupy mają bardzo podobne obowiązki dotyczące cyberbezpieczeństwa, zarządzania ryzykiem, zgłaszania incydentów, audytów bezpieczeństwa. Różnice dotyczą głównie poziomu nadzoru i potencjalnych konsekwencji.

Do ustalenia statusu organizacji kluczowe jest sprawdzenie warunków wskazanych w art. 5 ustawy, które określają warunki kwalifikacji.

Jest 16:43. Kończę dzień, lista rzeczy „na jutro” już gotowa, jeszcze tylko szybkie spojrzenie na skrzynkę. I wtedy telefon: „Dzień dobry, chyba doszło do incydentu – wysłałem e-mail do kilku osób, ale jedna z nich nie była właściwym odbiorcą. Program podpowiedział…”. W tym momencie już wiem, że to nie będzie spokojne zamknięcie dnia. W głowie od razu pojawia się lista pytań: jakie dane zostały ujawnione, do ilu osób, czy odbiorcy się znają, czy ktoś już zdążył kliknąć „odpowiedz wszystkim”? Bo doświadczenie podpowiada jedno — problem bardzo rzadko kończy się na jednym błędzie.

Scenariusz jest zazwyczaj podobny. Ktoś wpisuje odbiorcę, system podpowiada adres, klik — pierwszy z listy. Albo wiadomość trafia do szerszej grupy w polu DW, bo „tak było szybciej”. Na tym etapie wydaje się, że to tylko drobna pomyłka.

Ale to dopiero początek.

Po chwili zaczynają pojawiać się odpowiedzi. Najpierw ktoś uprzejmie pisze, że to chyba nie do niego. Potem ktoś prosi o usunięcie z listy. A potem pojawia się klasyczne „odpowiedz wszystkim”. I w tym momencie sytuacja wymyka się spod kontroli — ujawnia się pełna lista adresów, w stopkach pojawiają się imiona, nazwiska, stanowiska, numery telefonów. Ktoś dorzuca dodatkowe informacje „przy okazji”, ktoś zadaje pytanie do całej grupy. Z jednego maila robi się chaotyczna, publiczna wymiana informacji.

Z perspektywy IOD to już nie jest pomyłka. To jest rozwijające się naruszenie.

Realizacja praw osób, których dane dotyczą (art. 15–22 RODO), w teorii wydaje się prosta. W praktyce już na wstępie pojawia się problem – skąd mamy wiedzieć, że osoba, która pisze do nas z wnioskiem, to faktycznie ta osoba, której dane dotyczą? Poza tym jak przeprowadzić właściwą weryfikację tożsamości, aby zachować równowagę między bezpieczeństwem a proporcjonalnością.
Zgodnie z art. 12 ust. 6 RODO „Jeżeli administrator ma uzasadnione wątpliwości co do tożsamości osoby fizycznej składającej wniosek, może zażądać dodatkowych informacji niezbędnych do potwierdzenia tożsamości.” Dwie rzeczy są tu kluczowe: „uzasadnione wątpliwości” – nie zawsze, nie automatycznie, a także to, że „niezbędnych” informacji – oznacza, że nie dowolnych, nie nadmiarowych.

Zatem weryfikacja tożsamości wnioskodawcy musi być:
• proporcjonalna,
• adekwatna do relacji z tą osobą,
• adekwatna do kategorii już przetwarzanych danych,
• adekwatna do ryzyka naruszenia praw i wolności.

Jak działa to w praktyce? Wyobraźmy sobie, że firma otrzymuje żądanie kopii danych od osoby, zapisanej do jej newslettera. W takiej sytuacji firma przetwarza jedynie adres e-mail i ewentualne informacje o sposobie i czasie wyrażenia zgody na otrzymywanie wiadomości.
Jeżeli wniosek przyszedł z adresu zapisanej skrzynki oraz brak znanych okoliczności wskazujących na przejęcie konta (np. publiczne informacje o takim zdarzeniu), można uznać to za wystarczającą weryfikację. Nie ma podstaw do żądania dodatkowych danych. Natomiast ważne jest, aby kopię danych wysłać na adres e-mail posiadany w bazie.
Natomiast jeżeli wniosek przyszedł z innego adresu, niezbędne jest zastosowanie dodatkowego mechanizmu weryfikacji, np. wysłanie linku weryfikacyjnego na zapisany adres.

W takim wypadku można poinformować wnioskodawcę o konieczności potwierdzenia tożsamości:
Otrzymaliśmy wniosek dotyczący realizacji prawa związanego z przetwarzaniem danych osobowych. W celu zapewnienia bezpieczeństwa danych oraz potwierdzenia tożsamości osoby składającej wniosek, wysłaliśmy wiadomość zawierającą link weryfikacyjny na adres e-mail znajdujący się w naszej bazie subskrybentów.

Od dawna nie było tu nowego wpisu. Nie dlatego, że zabrakło tematów – wręcz przeciwnie. W ciągu kilku ostatnich miesięcy zmarło kilka bardzo bliskich mi osób. To był czas, w którym musiałam na chwilę zwolnić, złapać oddech i poukładać swoje sprawy. Wracam jednak z tematem trudnym, ale niezwykle potrzebnym. Tematem, który pokazuje, że RODO nie jest przepisem „przeciwko ludziom”, lecz – w określonych sytuacjach – dla ochrony życia i zdrowia.

Historia, która nie powinna się wydarzyć

Ostatnio usłyszałam historię, która nie daje mi spokoju.

Dziewczyna nie przyszła do pracy. Pracowała tam od kilkunastu lat. Nigdy wcześniej nie zdarzyło się, by nie przyszła bez uprzedzenia. Nigdy nie było problemu z kontaktem. Tym razem – cisza. Telefon milczał.

Koledzy z pracy wiedzieli, że samotnie wychowuje dziecko z niepełnosprawnością. Zaczęli się obawiać, że mogło stać się coś poważnego – jej, dziecku albo im obojgu. Nie był to impuls ani plotka. Było to racjonalne zaniepokojenie oparte na wieloletniej znajomości i konkretnych okolicznościach.

Jedna z koleżanek przypomniała sobie, że wiele lat temu – „na wszelki wypadek” – dostała od niej klucz do mieszkania. Problem w tym, że nie pamiętała dokładnego adresu. Wiedziała tylko, w jakiej okolicy i w którym bloku może mieszkać.

Koledzy zadzwonili do kadr. Opisali sytuację. Wskazali, że chodzi o realną obawę o życie i zdrowie pracownicy oraz jej dziecka. Poprosili o podanie adresu zamieszkania. Kadry odmówiły. Powołały się na ochronę prywatności pracownika.

Koledzy zdecydowali się działać sami. Ustalili blok, chodzili od drzwi do drzwi, pytali sąsiadów. W końcu ktoś wskazał właściwe mieszkanie. Gdy weszli do środka – było już za późno. Dziewczyna nie żyła.

Od kilku miesięcy dostaję od Was coraz więcej pytań o to, czy Inspektor Ochrony Danych może korzystać z narzędzi typu ChatGPT w codziennej pracy, np. generowanie klauzul informacyjnych, inni o wsparcie w analizie ryzyka, jeszcze inni o szybkie sprawdzenie przepisu czy wytycznych EROD. Rzeczywiście – ChatGPT potrafi być ogromnym ułatwieniem, ale tylko wtedy, gdy korzystamy z niego z głową.

ChatGPT a dane osobowe

Najważniejsza zasada: nie powinniśmy wprowadzać do ChatGPT danych osobowych – zwłaszcza tych, które powierzono nam jako IOD. Nawet jeśli narzędzie zapewnia pewne opcje prywatności, to wciąż mamy do czynienia z usługą chmurową i nie możemy w pełni kontrolować, co dzieje się z treściami wpisywanymi do modelu.

To oznacza, że nie podajemy nazwisk, adresów e-mail, PESEL-i czy danych pracowników/pacjentów/klientów. Na tej samej zasadzie trzeba uważać na kopiowanie raportów z audytów, podatności systemów, czy rejestru naruszeń – które mogą ujawnić potencjalnym oszustom, w jaki sposób włamać się do infrastruktury administratora. Możemy natomiast pracować na anonimizowanych przykładach – np. zamiast „Jan Kowalski, adres…” wpisujemy „Pracownik A, dane kontaktowe…”.

Wersja biznesowa a dane osobowe

Wersja ChatGPT Enterprise / Team różni się od darmowej tym, że dostawca deklaruje możliwość wyłączenia wykorzystywania danych do trenowania modelu (czyli nie powinny przypadkowo „wypłynąć” przy okazji innego zapytania). Pojawia się więc pytanie: czy można tam wprowadzać dane osobowe?

Teoretycznie tak, ale z pełną formalizacją i dużą ostrożnością.

Spoglądasz na telefon, a tam kilkanaście wiadomości z pytaniami „co z Tobą”? Do wiadomości jest dołączony link o filmu. Jesteś w tym filmie. Twój głos, twarz, gesty. Film przedstawia Cię, jak mówisz coś, czego nigdy nie powiedziałeś. Albo robisz coś, czego nigdy nie zrobiłeś. Ludzie to oglądają. Komentują. Osądzają. Rodzina i znajomi z pracy wymagają wyjaśnień. Ludzie zaczynają rozpoznawać Cię na ulicy, ale to nie jest miłe. Tak działa deepfake technologia potrafi ukraść Ci twarz, głos i reputację.

Dzięki rozwojowi generatywnej sztucznej inteligencji (GenAI), możliwe stało się tworzenie niewiarygodnie realistycznych materiałów multiedialnych. Te narzędzia potrafią odtworzyć człowieka w najmniejszym detalu, na podstawie niewielkich próbek (zdjęcia, krótkie nagrania). Z jednej strony to potężne narzędzie kreatywne. Z drugiej – broń dezinformacji, szantażu i manipulacji.

Polskie prawo cywilne oraz przepisy o ochronie danych osobowych, stanowią narzędzie do dochodzenia swoich praw, w przypadku naruszenia prywatności, czy dóbr osobistych, jak wizerunek. Jednak są to narzędzia działające bardzo powoli, często przenoszące ciężar udowodnienia faktycznej szkody na ofiarę. Gdy zapadnie wyrok, często nie ma to już większego znaczenia dla osoby poszkodowanej, która nieodwracanie utraciła reputację, zaufanie społeczne, anonimowość. Potrzebne są narzędzia, które działają szybciej i skuteczniej.