Europejski Inspektor Ochrony Danych żąda granic danych Europolu » Prezes UODO skontroluje spółkę MyDr » Grecja: 30 tys. euro kary za naruszenie praw osób, których dane dotyczą » Duży wyciek danych obywateli Łotwy » Cyberbezpieczeństwo AI w planie Komisji. AI Act trzeba łączyć z NIS2, u.k.s.c. i DORA
⬇️ Pobierz W PDF
Praktyczny poradnik o wdrażaniu RODO
Książka RODOLOGIA to kompleksowy przewodnik po RODO, który pomaga wdrożyć ochronę danych osobowych w sposób prosty, szybki i skuteczny. Ponad 500 stron praktycznej wiedzy podanej w przystępnej formie i zrozumiałym języku. A wszystko to podane w pięknej, premium formie. Dowiedz się więcej o RODOLOGII: SprawdźEuropejski Inspektor Ochrony Danych żąda granic danych Europolu
- Kontekst: Opinia Europejskiego Inspektora Ochrony Danych (EIOD) z 11 sierpnia 2026 r. dotyczy projektu nowego rozporządzenia o Europolu.
- Ogólna ocena: EIOD popiera wzmocnienie roli Europolu, ale podkreśla, że projekt wymaga znacznie precyzyjniejszych gwarancji ochrony danych, szczególnie wobec osób niepowiązanych z ustaloną działalnością przestępczą.
- Teza 1 – dane nieskategoryzowane (najważniejszy punkt opinii):
- Przetwarzanie przez Europol danych osób, których związek z dochodzeniem lub przestępczością nie został ustalony, to bardzo poważna ingerencja w prawo do ochrony danych osobowych.
- Projekt może umożliwiać przetwarzanie dużych, nieustrukturyzowanych zbiorów danych (także z internetu i od podmiotów prywatnych) przez długi i nieokreślony czas.
- Zdaniem EIOD obecnie takie przetwarzanie ma charakter wyjątku, a projekt mógłby uczynić je elementem zwykłej działalności Europolu.
- Problemem jest brak jasnych ograniczeń: celu, zakresu danych i maksymalnych okresów przechowywania, co rodzi wątpliwości co do konieczności i proporcjonalności.
- Rekomendacje EIOD: ściśle ograniczyć cele (co do zasady do konkretnego, trwającego postępowania przygotowawczego), zdefiniować kryteria istotności i konieczności oraz wprowadzić jasne maksymalne terminy przetwarzania.
- Teza 2 – biometria: brak automatyzmu:
- EIOD sprzeciwia się podejściu, które pozwalałoby na systematyczne przeszukiwanie zasobów Europolu przy użyciu danych biometrycznych służących jednoznacznej identyfikacji osoby.
- W każdym przypadku powinna być wymagana indywidualna ocena:
- ścisłej niezbędności użycia biometrii,
- proporcjonalności takiego przeszukania.
- Nie wystarczy, że działanie „mieści się w zadaniach Europolu” — potrzebna jest ocena dla konkretnej operacji (EIOD odwołuje się do orzecznictwa TSUE wskazanego w opinii).
- Teza 3 – jasny podział odpowiedzialności w operacjach wspólnych:
- Projekt przewiduje nowe formy współpracy (np. wspólne sprawy analityczno-operacyjne, narzędzia udostępniane organom krajowym), ale nie rozdziela wystarczająco jasno ról w ochronie danych.
- To ma bezpośredni wpływ na:
- możliwość wykonywania praw przez osoby, których dane dotyczą,
- skuteczność nadzoru.
- Rekomendacje: jednoznacznie określić role (administrator / współadministrator / podmiot przetwarzający) tak, aby odzwierciedlały rzeczywistość operacyjną; jeśli nie w samym rozporządzeniu, to zapewnić podstawę do doprecyzowania w aktach wykonawczych.
- Teza 4 – skuteczny nadzór wymaga pełnych uprawnień i zasobów:
- EIOD powinien mieć wyraźne uprawnienie do nadzorowania czynności przetwarzania prowadzonych przez personel Europolu w krajowych środowiskach dochodzeniowych.
- Rozszerzony mandat Europolu wymaga też, aby EIOD miał odpowiednie zasoby kadrowe i finansowe.
- Dodatkowe obszary poruszane w opinii (wybrane):
- dostęp innych organów do systemów Europolu,
- przetwarzanie danych otrzymanych bezpośrednio od podmiotów prywatnych,
- zawiadamianie o naruszeniach ochrony danych,
- usługi chmurowe oraz kanały komunikacji z systemem ETIAS,
- postulat publicznie dostępnego wykazu organów mających dostęp do systemów Europolu,
- potrzeba szczegółowych zasad działania mechanizmu „trafienie/brak trafienia”,
- w odniesieniu do ETIAS: wymóg pełnej rozliczalności (możliwości prześledzenia każdej operacji i decyzji) poprzez odpowiednią „ścieżkę audytu”.
- Charakter opinii: ma wymiar legislacyjny (dotyczy kształtu przepisów), a nie rozstrzyga indywidualnej sprawy — EIOD nie stwierdza naruszenia przez Europol, lecz wskazuje warunki, które prawodawca powinien spełnić, aby rozszerzenie mandatu nie prowadziło do nieograniczonego przetwarzania danych osób bez ustalonego związku z przestępczością.
Prezes UODO skontroluje spółkę MyDr
- Kontekst: Prezes UODO zapowiedział kontrolę w spółce MyDr po zgłoszeniach naruszeń ochrony danych osobowych, związanych z wyciekiem danych o stanie zdrowia pacjentów. MyDr przetwarza dane w imieniu placówek ochrony zdrowia korzystających z jej aplikacji.
- Co się stało: Placówki medyczne, które powierzyły MyDr dane swoich pacjentów w ramach korzystania z aplikacji, zgłaszają naruszenia ochrony danych.
- Skala problemu: Pełny zakres naruszenia nie jest jeszcze znany, ale według doniesień medialnych może dotyczyć ok. 12 tys. podmiotów leczniczych.
- Dlaczego kontrola: UODO uznał, że ze względu na charakter danych (informacje o zdrowiu) i możliwą dużą skalę, konieczne jest sprawdzenie działań MyDr jako podmiotu przetwarzającego.
- Co sprawdzą kontrolerzy UODO:
- jakie środki techniczne i organizacyjne zastosowała spółka do ochrony danych,
- czy zabezpieczenia były regularnie testowane i dostosowywane do zmieniających się zagrożeń,
- czy przeprowadzona analiza ryzyka uwzględniała realne zagrożenia dla danych oraz czy jej wyniki zostały wdrożone w praktyce.
- Najważniejszy wniosek: Kluczowym elementem oceny UODO będzie to, czy MyDr nie tylko posiadała formalne procedury bezpieczeństwa, ale faktycznie wdrażała adekwatne zabezpieczenia oraz aktualizowała je na podstawie analizy ryzyka.
Grecja: 30 tys. euro kary za naruszenie praw osób, których dane dotyczą
- Kontekst: Grecki organ ochrony danych nałożył na operatora telekomunikacyjnego karę 30 tys. euro po skardze klienta dotyczącej realizacji praw wynikających z RODO. Sprawa dotyczyła obsługi wniosku o udostępnienie nagrań rozmów telefonicznych oraz żądania ograniczenia przetwarzania danych.
- Organ ocenił nie tylko to, co operator odpowiedział, ale także jak przebiegał cały proces obsługi klienta (czy był przejrzysty i nieutrudniający korzystania z praw).
- Kluczowy przepis: art. 12 RODO – administrator ma obowiązek ułatwiać osobom wykonywanie ich praw. To nie jest tylko kwestia przyjęcia wniosku i odpowiedzi w terminie.
- Administrator powinien tak zorganizować proces, aby osoba:
- otrzymywała jasne i spójne informacje,
- wiedziała, jakie działania są podejmowane i na jakim etapie jest sprawa,
- nie była zmuszana do pokonywania dodatkowych barier organizacyjnych ani zbędnych formalności.
- Sprzeczne informacje przekazywane klientowi lub tworzenie niepotrzebnych wymogów formalnych zostało wskazane jako sprzeczne z celem RODO.
- Prawo dostępu: w tym przypadku dotyczyło dostępu do nagrań rozmów. Organ podkreślił, że realizacja tego prawa wymaga konkretnych działań organizacyjnych, a nie tylko ogólnej instrukcji „jak złożyć wniosek”.
- Prawo do ograniczenia przetwarzania: klient żądał ograniczenia przetwarzania danych do czasu wyjaśnienia sprawy. Również tutaj liczy się realna możliwość skorzystania z prawa, a nie wyłącznie formalna odpowiedź.
- Znaczenie procedur wewnętrznych: zgodność z RODO zależy nie tylko od posiadania procedur „na papierze”, ale od tego, czy są stosowane w praktyce i czy działają spójnie w całej organizacji.
- Administrator powinien zapewnić pracownikom jasne instrukcje i narzędzia, aby wnioski były obsługiwane sprawnie i jednolicie, bez „odbijania” klienta między kanałami lub działami.
- Wniosek ogólny: organ wyraźnie wskazał, że RODO wymaga budowania procesów, które wspierają osoby korzystające z praw, a nie ograniczają się do rutynowych odpowiedzi na wnioski.
- Znaczenie dla innych firm: stanowisko ma zastosowanie dla wszystkich administratorów danych. Im bardziej złożona obsługa klienta, tym ważniejsze jest dobre zaprojektowanie procedur i przygotowanie osób, które mają kontakt z klientami.
Duży wyciek danych obywateli Łotwy
- Kontekst: Po niedawnym ujawnieniu danych medycznych ok. 19 mln Polaków z bazy firmy MyDr. pojawiła się informacja o kolejnym dużym incydencie – tym razem na Łotwie, w systemie CSDD (Łotewska Dyrekcja Bezpieczeństwa Ruchu Drogowego).
- Skala wycieku: wykradziono dane 1,2 mln osób (ok. 65% populacji Łotwy) oraz 200 tys. firm.
- Kiedy doszło do ataku: według Cert.lv incydent miał miejsce w dniach 8–10 sierpnia 2026 r.
- Jak doszło do wycieku: atakujący uzyskali dostęp do wystawionej do internetu części systemu CSDD i nieuprawnienie pobrali historyczne dane dotyczące potwierdzeń płatności za usługi CSDD.
- Jakie dane mogły wyciec:
- numer identyfikacyjny osoby (odpowiednik polskiego PESEL) lub numer rejestracyjny firmy,
- imię i nazwisko / nazwa firmy,
- informacje o płatności i data zapłaty,
- numer rejestracyjny pojazdu,
- adres.
- Co nie wyciekło (ważne dla odbiorców): CSDD i Cert.lv podkreślają, że loginy i hasła klientów nie zostały objęte incydentem, więc nie ma potrzeby podejmowania dodatkowych działań związanych z hasłami.
- Sprawca: na tym etapie nie jest znana atrybucja ataku (nie wiadomo, kto za nim stoi).
- Reakcja władz: prezydent Edgars Rinkēvičs uznał zdarzenie za zagrożenie dla bezpieczeństwa narodowego i wskazał na utratę zaufania do CSDD. Premier Andris Kulbergs wezwał kierownictwo CSDD do rezygnacji.
- Konsekwencje organizacyjne: po sprzecznych deklaracjach do dymisji podała się cała rada CSDD (odpowiednik rady nadzorczej).
- Rola dostawców zewnętrznych: kontrowersje wzbudził fakt, że dostawcy zewnętrzni odpowiedzialni za działanie systemu nie poinformowali CSDD o ataku w trakcie jego trwania.
- Kto odpowiadał za utrzymanie/bezpieczeństwo: wątek dotyczy firmy Tet (usługi cyberbezpieczeństwa) oraz jej podwykonawcy Kyndryl (utrzymanie systemu). Nadal nie jest jasne, jak dokładnie rozkładały się odpowiedzialności między CSDD, Tet i Kyndryl.
- Problemy z komunikacją:
- między CSDD a Tet – CSDD twierdzi, że zabrakło informacji o ataku w czasie jego trwania,
- między CSDD a Cert.lv – również pojawiły się trudności w komunikacji.
- Co zrobiło CSDD w trakcie incydentu: specjaliści CSDD wykryli podejrzane działania, po kilku godzinach zablokowali podejrzane adresy i ataki ustały, ale nie zidentyfikowali od razu wycieku danych.
- Ryzyka dla obywateli i firm: Cert.lv ostrzega przed phishingiem i oszustwami – zestaw danych (np. imię i nazwisko, numer identyfikacyjny, adres, numer rejestracyjny pojazdu, data płatności) pozwala tworzyć bardzo wiarygodne scenariusze wyłudzeń.
- Szerszy wniosek: rosnąca cyfryzacja oznacza większą koncentrację danych w systemach IT, co zwiększa atrakcyjność takich baz dla cyberprzestępców i potencjalnie obcych służb. Kluczowe stają się procedury, monitoring, nadzór oraz sprawna komunikacja między instytucją i dostawcami – a w tym przypadku wygląda na to, że były niewystarczające.
Cyberbezpieczeństwo AI w planie Komisji. AI Act trzeba łączyć z NIS2, u.k.s.c. i DORA
- Kontekst: organizacja nie powinna ograniczać się do sprawdzenia, jakie obowiązki nakłada na nią AI Act. Systemy AI mogą równolegle podlegać wymaganiom z obszaru cyberbezpieczeństwa, odporności operacyjnej i bezpieczeństwa produktów, więc te tematy trzeba uwzględniać łącznie już na etapie wdrażania AI.
- Co ogłosiła Komisja Europejska: 7 lipca 2026 r. Komisja przedstawiła komunikat „Action Plan on Cybersecurity and Artificial Intelligence”. Dokument nie tworzy nowych obowiązków dla firm, ale pokazuje kierunek rozwoju unijnej praktyki regulacyjnej i nadzorczej dot. bezpieczeństwa AI.
- Główna teza planu: bezpieczeństwa AI nie należy oceniać wyłącznie przez pryzmat wymagań AI Act dla określonych systemów i modeli. Rośnie znaczenie równoległego stosowania przepisów o cyberbezpieczeństwie, odporności produktów i ciągłości działania.
- Jakie regulacje trzeba brać pod uwagę obok AI Act:
- NIS2 oraz polskie przepisy o cyberbezpieczeństwie (ustawa o krajowym systemie cyberbezpieczeństwa – u.k.s.c.),
- Akt o cyberodporności (CRA) – dot. produktów z elementami cyfrowymi,
- w sektorze finansowym także DORA – szczegółowe wymogi dot. cyfrowej odporności operacyjnej, zarządzania ryzykiem ICT i raportowania incydentów.
- Wniosek dla organizacji: konieczna jest integracja AI governance i cyberbezpieczeństwa. Podejście, w którym te obszary działają niezależnie, przestaje odpowiadać realnym ryzykom i kierunkowi zmian regulacyjnych.
- Dlaczego sama klasyfikacja z AI Act nie wystarcza: nawet jeśli system nie jest „wysokiego ryzyka” w AI Act, może zwiększać ryzyko dla:
- ciągłości działania,
- poufności danych,
- integralności procesów,
- bezpieczeństwa łańcucha dostaw,
- odporności usług organizacji.
- AI jednocześnie zwiększa zagrożenia i pomaga się bronić:
- Modele AI mogą ułatwiać ataki (automatyzacja, wyszukiwanie podatności, skuteczniejszy phishing, skalowanie działań ofensywnych).
- Te same technologie mogą wzmacniać obronę (analiza podatności, wykrywanie anomalii, identyfikacja zagrożeń).
- W praktyce oba aspekty powinny być analizowane w jednym procesie zarządzania ryzykiem.
- Zapowiedzi z planu Komisji (kierunek działań):
- utworzenie unijnej zdolności do oceny zaawansowanych modeli AI,
- opracowanie z ENISA zasad dostępu do modeli AI na potrzeby cyberbezpieczeństwa,
- uruchomienie bezpiecznej platformy testowej, także dla sektorów krytycznych,
- rozwój wytycznych ENISA oraz dostosowanie zarządzania podatnościami do realiów, w których wykrywanie podatności będzie coraz częściej wspierane przez AI.
- NIS2/u.k.s.c. mają inny cel niż AI Act: AI Act koncentruje się na wymaganiach wobec systemów i modeli AI, a NIS2/u.k.s.c. – na odporności organizacji i ciągłości usług (ryzyko, incydenty, ciągłość działania, łańcuch dostaw).
- Istotny praktyczny wniosek: narzędzie AI używane w organizacji objętej u.k.s.c. powinno być uwzględnione w ocenie ryzyka, jeśli może wpływać na bezpieczeństwo systemów informacyjnych lub ciągłość usług – niezależnie od tego, czy jest „wysokiego ryzyka” w AI Act.
- Akt o cyberodporności (CRA): jeżeli rozwiązanie z AI jest produktem z elementami cyfrowymi, producent odpowiada za wymagania cyberbezpieczeństwa w całym cyklu życia produktu. Pełne stosowanie CRA zacznie się 11 grudnia 2027 r., a część obowiązków notyfikacyjnych (dot. aktywnie wykorzystywanych podatności i poważnych incydentów) zacznie obowiązywać wcześniej.
- AI Act nie zastępuje u.k.s.c. ani DORA: zgodność z AI Act nie oznacza automatycznie, że organizacja spełnia obowiązki z cyberbezpieczeństwa i odporności operacyjnej. System może być zgodny z AI Act, a mimo to tworzyć ryzyko dla działania całej organizacji.
- Harmonogramy i wdrożenia: przesunięcia terminów dla części obowiązków AI Act nie uzasadniają wstrzymania prac, bo nie zawieszają obowiązków w cyberbezpieczeństwie, ochronie danych, odporności operacyjnej ani regulacjach sektorowych.
- Kluczowe daty dla nowelizacji u.k.s.c. (wg treści artykułu):
- wpis do właściwego wykazu do 3 października 2026 r.,
- wdrożenie zasadniczych obowiązków do 3 kwietnia 2027 r.
- Ryzyko biznesowe: jeśli ryzyk AI nie uwzględni się przy projektowaniu inwentaryzacji aktywów, metodyki analizy ryzyka, reakcji na incydenty i zasad łańcucha dostaw, system zarządzania ryzykiem będzie niepełny i szybko może wymagać kosztownej przebudowy.
- Inwentaryzacja AI jako fundament: organizacja powinna prowadzić spójny rejestr systemów AI, obejmujący m.in. model i wersję, sposób hostowania, cel użycia, kategorie danych, integracje, zakres uprawnień, zależności od dostawców oraz procesy/usługi, na które AI wpływa. Dane te powinny zasilać rejestr aktywów i ocenę ryzyka cyberbezpieczeństwa.
- Jakie zagrożenia AI trzeba uwzględnić w analizie ryzyka: m.in. zatruwanie danych/modelu, ataki adwersaryjne, prompt injection, obchodzenie zabezpieczeń, niekontrolowane działanie agentów AI, a także wpływ na poufność, integralność i dostępność informacji oraz ciągłość działania.
- Nie pomijać ryzyk „operacyjnych” wokół AI: aktualizacje modeli, zmiany warunków usługi, utrata dostępu do rozwiązania, silna zależność od dostawcy.
- Przykładowe środki zabezpieczające (weryfikowalne): ograniczanie uprawnień, separacja środowisk, ochrona danych uwierzytelniających, filtrowanie danych, logowanie operacji, kontrola zmian, ograniczanie autonomii agentów AI.
- Łańcuch dostaw i umowy z dostawcami AI: umowy powinny regulować m.in. zasady użycia danych, informowanie o zmianach modelu, dostęp do logów i informacji o bezpieczeństwie, zgłaszanie incydentów i podatności, podwykonawców, współpracę przy notyfikacjach oraz zakończenie usługi i migrację danych.
- Jeden incydent może uruchamiać kilka reżimów prawnych: to samo zdarzenie może być jednocześnie incydentem wg u.k.s.c., poważnym incydentem związanym z systemem/modelem AI, naruszeniem ochrony danych osobowych, a w finansach także incydentem ICT wg DORA. Potrzebny jest jeden spójny proces wykrywania, eskalacji i kwalifikacji zdarzeń.
- Nadzór kierownictwa: decyzja o wdrożeniu AI powinna opierać się na udokumentowanej ocenie wpływu na bezpieczeństwo, zgodność regulacyjną i ciągłość działania; funkcja cyberbezpieczeństwa powinna uczestniczyć w strukturach nadzorujących AI.
- Podstawa prawna przywołana w artykule: rozporządzenie (UE) 2024/1689 (AI Act) oraz ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (u.k.s.c.).
Administratorem danych osobowych jest Lex Artist sp. z o.o., ul. Szańcowa 74/1, 01-458 Warszawa. Dane osobowe będą przetwarzane w celu umieszczenia i obsługi komentarza na blogu. Przysługują Panu/Pani następujące prawa: prawo dostępu do treści danych, prawo do sprostowania danych, prawo do usunięcia danych, prawo do ograniczenia przetwarzania danych, prawo do wniesienia sprzeciwu, prawo do wniesienia skargi do organu nadzorczego. Pełna treść klauzuli informacyjnej znajduje się tutaj.
Zanonimizowany ciąg znaków stworzony na podstawie Pani/Pana adresu email (tak zwany hash) może zostać przesłany do usługi Gravatar w celu sprawdzenia czy jej Pan/Pani używa. Polityka prywatności usługi Gravatar jest dostępna tutaj. Po zatwierdzeniu komentarza obrazek profilowy jest widoczny publicznie w kontekście twojego komentarza.