W Hiszpanii po raz pierwszy zgłoszono naruszenie ochrony danych, w którym atak miał zostać przeprowadzony przy użyciu agenta AI. Artykuł wyjaśnia, jak ocenić obowiązek zgłoszenia, gdy dochodzi do naruszenia danych z udziałem agenta AI, kiedy zaczyna biec 72 godziny i jakie przygotowania warto mieć już za sobą, by nie działać pod presją.
14 września 2026 r. w Hiszpanii stało się publiczne, że po raz pierwszy zgłoszono organowi ochrony danych atak przeprowadzony przy użyciu agenta AI. Rodzi to praktyczne pytanie: kto musi co zrobić, gdy w grę wchodzi agent AI, czy to jako narzędzie ataku zewnętrznych sprawców, czy jako własne narzędzie firmy? Chodzi o obowiązek zgłoszenia, terminy, logi i procedury na wypadek incydentu.
Sprawa AEPD w skrócie
W Hiszpanii po raz pierwszy zgłoszono naruszenie ochrony danych osobowych, w którym atak miał zostać przeprowadzony przy użyciu agenta AI opartego na znanym modelu językowym. Według opisu atakujący najpierw przeszukał publicznie dostępne pliki w poszukiwaniu luk, a następnie zalogował się do systemu docelowego. Agent znalazł w aplikacji kolejne luki, zmienił dane osobowe i uzyskał dostęp do faktur.
Ważny jest podział ról. Zgłaszająca firma była ofiarą, a agent narzędziem atakujących. Nie był to więc błąd agenta, którego używałaby sama organizacja. Nie podano ani nazwy organizacji, ani modelu. Z użycia znanego modelu nie wynika, że jego dostawca lub infrastruktura zostały skompromitowane, i nie powiedziano, że narzędzie stworzono do szkodliwych celów. Pojedynczy przypadek nie pozwala też wnioskować o trendzie.
AI nie tworzy zasadniczo nowych zagrożeń, ale może zwiększyć tempo, skalę i zdolność dostosowania ataków. Wynikają z tego praktyczne wnioski: ataki z użyciem AI należą do analizy ryzyka, czasy reakcji zaprojektowane na ataki ręczne trzeba zweryfikować, dane dostępowe o zbyt szerokich uprawnieniach lepiej chronić, a nadzór człowieka potrzebuje wsparcia w postaci szybkiego wykrywania i powstrzymywania.
Kiedy agent AI powoduje naruszenie danych podlegające zgłoszeniu
Obowiązek zgłoszenia naruszeń danych spowodowanych przez agentów AI nie zależy od technologii, lecz od skutku. Zgodnie z art. 4 pkt 12 RODO naruszenie ochrony danych osobowych występuje, gdy naruszenie bezpieczeństwa prowadzi do zniszczenia, utraty, zmiany, nieuprawnionego ujawnienia lub nieuprawnionego dostępu do danych osobowych, przypadkowo lub w sposób niezgodny z prawem. To, czy za incydentem stoi człowiek, skrypt czy agent, nie ma dla tej definicji znaczenia. Mimo to można wyraźnie odróżnić dwa scenariusze.
W scenariuszu A atakuje obcy agent, tak jak w sprawie hiszpańskiej. Nieuprawniony dostęp i zmiana danych stanowią naruszenie, a obowiązek zgłoszenia powstaje wraz z nim. Nowością jest tu przede wszystkim tempo, a nie ocena prawna. W scenariuszu B naruszenie powoduje własny agent. Może to być agent obsługi klienta, który wysyła dane niewłaściwej osobie, agent programistyczny ze zbyt szerokimi uprawnieniami albo agent pocztowy, który po podrzuconym poleceniu przekazuje treści dalej.
W scenariuszu B ocena nie zawsze jest oczywista. Jeśli agent zrobił dokładnie to, do czego został skonfigurowany, i nikt nieuprawniony nie uzyskał dostępu, często brakuje naruszenia bezpieczeństwa. Jeśli natomiast dane trafiają do odbiorców, którzy nie powinni ich otrzymać, albo agent sięga do zasobów, które miały być dla niego zamknięte, wiele przemawia za naruszeniem. Własnych wytycznych dla agentów jest jak dotąd niewiele. Ocena pozostaje zatem kwestią indywidualnego przypadku i opiera się na ogólnych standardach organów nadzorczych.
| Scenariusz | Naruszenie? | Dotknięty cel ochrony |
|---|---|---|
| Obcy agent loguje się bez uprawnień | Tak | Poufność |
| Obcy agent zmienia rekordy w aplikacji | Tak | Integralność |
| Własny agent wysyła faktury do niewłaściwych odbiorców | Tak | Poufność |
| Własny agent po prompt injection przekazuje zawartość skrzynki na zewnątrz | Tak | Poufność |
| Własny agent usuwa rekordy bez kopii zapasowej | Tak | Dostępność |
| Własny agent odpowiada błędnie, bez wycieku danych | Zwykle nie | Żaden, raczej problem jakościowy |
Kluczowe pytanie można zatem rozstrzygnąć krótko.
Czy naruszenie danych z udziałem agenta AI trzeba zgłosić na podstawie art. 33 RODO?
Próg ryzyka i wyłączenie z obowiązku zgłoszenia
Nie każde naruszenie trzeba zgłaszać. Art. 33 RODO przewiduje wyjątek, gdy naruszenie prawdopodobnie nie skutkuje ryzykiem naruszenia praw lub wolności osób fizycznych. Poprzeczka jest więc ustawiona nisko. Z reguły zgłasza się już wtedy, gdy nie można wykluczyć ryzyka. Kto rezygnuje ze zgłoszenia, musi umieć dobrze uzasadnić, dlaczego ryzyka nie było.
W atakach i awariach z udziałem agentów wiele przemawia przeciwko temu wyjątkowi. Agenci często sięgają jednocześnie po wiele rekordów, działają szybko i mają dostęp do takich obszarów jak faktury, konta klientów czy skrzynki pocztowe. Jeśli atakujący zmienia dane, obok utraty poufności pojawia się problem wtórny: początkowo nikt nie wie, które rekordy są jeszcze prawidłowe. Zwiększa to ryzyko dla osób, których dane dotyczą.
Do oceny europejskie organy ochrony danych opublikowały wytyczne. Wytyczne EROD dotyczące zgłaszania naruszeń ochrony danych wymieniają jako kryteria m.in. rodzaj naruszenia, wrażliwość i ilość danych, możliwość identyfikacji osób, wagę możliwych skutków oraz liczbę osób poszkodowanych. Przy wysokim ryzyku dochodzi dodatkowo zawiadomienie osób, których dane dotyczą, na podstawie art. 34 RODO. Ten krok jest odrębny od zgłoszenia do organu i ma własne wymogi.
Odpowiedzialność leży po stronie operatora
Agent jest narzędziem, a nie podmiotem prawa. Odpowiedzialny pozostaje ten, kto decyduje o celach i sposobach przetwarzania, czyli firma, która agenta wdraża. Nie wystarczy wskazać model, platformę ani dział merytoryczny. Nawet jeśli agent działa samodzielnie, przetwarzanie pozostaje przypisane operatorowi.
Agent jest narzędziem, odpowiedzialność pozostaje przy operatorze.
Jeśli platforma lub dostawca modelu uruchamia agenta na zlecenie, zwykle działa jako podmiot przetwarzający. Wtedy obowiązuje art. 33 ust. 2 RODO: podmiot przetwarzający musi zgłosić administratorowi naruszenie bez zbędnej zwłoki po jego stwierdzeniu. Termin administratora zaczyna jednak biec dopiero od jego własnego stwierdzenia. Umowy powinny więc określać, w jakim czasie i jakim kanałem zgłasza się incydenty. Informacja, która po kilku dniach trafia do ogólnej skrzynki, nikomu nie pomaga.
| Uczestnik | Rola przy awarii agenta |
|---|---|
| Operator agenta | Administrator, zgłasza do organu nadzorczego i dokumentuje |
| Platforma agentów | Często podmiot przetwarzający, niezwłocznie informuje operatora |
| Dostawca modelu | W zależności od układu podmiot przetwarzający lub podwykonawca, przy własnej kompromitacji również zobowiązany do informowania |
| Dział merytoryczny | Rozpoznaje i zgłasza wewnętrznie, sam nie decyduje |
| Inni usługodawcy | Dostarczają logi i wskazówki do oceny |
Jeśli atakujący wchodzi przez usługodawcę, obowiązują te same zasady co przy każdej awarii w łańcuchu dostaw.
Prawidłowe liczenie 72 godzin
Zgodnie z art. 33 ust. 1 RODO termin biegnie od chwili, gdy administrator stwierdzi naruszenie. Zgłasza się bez zbędnej zwłoki i w miarę możliwości w ciągu 72 godzin. Według wytycznych EROD stwierdzenie następuje wtedy, gdy administrator ma wystarczającą pewność, że incydent bezpieczeństwa doprowadził do naruszenia ochrony danych osobowych. Krótki czas na zbadanie podejrzenia jest dopuszczalny. Bezczynność nie jest.
W przypadku agentów wąskie gardło się przesuwa. Agent może w kilka minut pobrać lub zmienić tysiące rekordów. To, czy incydent zostanie wykryty tego samego dnia, czy dopiero po tygodniu, zależy wtedy od monitoringu i alarmowania. Agenci działający w nocy lub w weekendy pogłębiają problem. Kto zauważa anomalie dopiero przy następnym spojrzeniu na dashboard, traci czas, którego termin nie przewiduje. Szczególnie liczy się tu czas wykrycia oraz pytanie, kto może reagować poza godzinami pracy.
W przypadku agentów 72 godziny to przede wszystkim kwestia czasu wykrycia.
Prawo pozwala zgłaszać etapami. Jeśli nie wszystkie informacje są jeszcze dostępne, uzupełnia się je na podstawie art. 33 ust. 4 RODO bez dalszej zbędnej zwłoki. Jeśli termin zostanie przekroczony, trzeba uzasadnić opóźnienie. Jako orientację może posłużyć poniższy przebieg.
Podane czasy są wartościami orientacyjnymi. Decydujące jest to, by każdy etap miał osobę, która go uruchamia, oraz by decyzja o zgłoszeniu nie zależała od dostępności jednej osoby.
Protokołowanie działań agentów
Bez logów trudno określić skalę naruszenia. U agentów jest to szczególnie kłopotliwe, bo wykonują wiele pojedynczych działań, które każde z osobna wyglądają niewinnie. Użyteczny log odpowiada na cztery pytania: kto działał, co zrobiono, do jakich danych sięgnięto i dokąd one trafiły? Dochodzi obowiązek dokumentacji z art. 33 ust. 5 RODO, który dotyczy każdego naruszenia, także niezgłoszonego.
| Pole logu | Korzyść dla zgłoszenia | Uwaga o minimalizacji danych |
|---|---|---|
| Tożsamość i wersja agenta | Przypisanie incydentu do systemu i konfiguracji | Wystarczy identyfikator techniczny |
| Zlecenie i wyzwalacz | Wyjaśnia, czy działanie zainicjował człowiek, harmonogram czy obce dane wejściowe | Krótki opis zamiast pełnej treści |
| Dostęp do narzędzi i danych | Pokazuje rodzaj i zakres dotkniętych danych | Kategorie i ilości zamiast treści |
| Znaczniki czasu | Podstawa stwierdzenia naruszenia i liczenia terminu | Bez zastrzeżeń |
| Systemy docelowe i odbiorcy | Pokazuje, dokąd trafiły dane | Adresy tylko w razie potrzeby |
| Błędy i przerwania | Wskazówki o próbach ataku i usterkach | Bez zastrzeżeń |
| Zatwierdzenia przez ludzi | Dowodzi nadzoru i ścieżek decyzyjnych | Tylko identyfikator zatwierdzającej jednostki |
Dla protokołowania agentów obowiązuje zasada: same logi zawierają dane osobowe i muszą być chronione. Dostęp należy ograniczyć do niewielu osób, a wpisy przechowywać w sposób odporny na manipulację, na przykład w osobnym systemie. Okres przechowywania wymaga wyważenia: wystarczająco długi, by odtworzyć incydent, wystarczająco krótki, by nie powstał zbiór danych na zapas. Środki te należą do bezpieczeństwa przetwarzania z art. 32 RODO. Te same logi pomagają też przy wnioskach o dostęp do danych. Jak sensownie zorganizować nadzór nad agentami AI, aby agenci nie podważali własnej kontroli, to osobny temat.
Ograniczanie uprawnień i danych dostępowych
Sprawa hiszpańska pokazuje, jak działa atakujący z agentem: szuka znanych plików, domyślnych dostępów i codziennych luk. Dokładnie to agent potrafi robić z prędkością maszyny i bez zmęczenia. Kto zamyka takie luki, odbiera atakowi sporo tempa. Organ wprost wskazuje jako słaby punkt konta, klucze API i tokeny o zbyt szerokich uprawnieniach.
W praktyce sprawdza się garść zasad:
- Każdy agent dostaje własne konto z najmniejszymi niezbędnymi uprawnieniami.
- Klucze i tokeny są krótkotrwałe i można je odwoływać pojedynczo.
- Dostęp do wielu rekordów w krótkim czasie jest ograniczany i zgłaszany.
- Wyłącznik awaryjny zatrzymuje agentów i blokuje ich dostępy, bez konieczności wcześniejszych konsultacji.
- Opublikowane pliki, konta testowe i hasła domyślne są regularnie wyszukiwane i usuwane.
Te środki chronią zarówno przed obcymi agentami, jak i przed błędami własnych. Wielkość szkody zależy w dużym stopniu od uprawnień, które agent otrzymał. W przypadku powierzchni ataku aplikacji internetowej pomagają zautomatyzowane kontrole, które wykrywają widoczne luki, zanim zrobią to inni.
Sprawdź powierzchnię ataku
Otwarte pliki, brakujące zabezpieczenia i wycieki danych na własnej stronie można wykrywać automatycznie.
Plan reakcji na zautomatyzowane ataki
Wiele planów awaryjnych zakłada atakującego, który potrzebuje godzin lub dni. Organ zaleca przegląd czasów reakcji zaprojektowanych na ataki ręczne. Nadzór człowieka pozostaje ważny, ale potrzebuje wsparcia mechanizmów, które wykrywają, powstrzymują i reagują dostatecznie szybko. Zautomatyzowany atak nie zważa na koniec dnia pracy.
Solidny plan ustala kilka rzeczy. Są alarmy dla nietypowych wzorców dostępu, na przykład wielu pobrań z tego samego konta albo logowań o nietypowych porach. Konta można blokować automatycznie po przekroczeniu progów. Poza godzinami pracy ktoś jest osiągalny. Jasne jest, kto decyduje o zgłoszeniu i kto je wysyła. Formularz zgłoszeniowy organu nadzorczego jest przygotowany, a dane kontaktowe inspektora ochrony danych są pod ręką. Na pierwsze godziny incydentu warto zajrzeć do planu działania na pierwsze 60 minut, który powstał przy ransomware, ale da się go przenieść na inne ataki.
Dobrze, jeśli plan został przećwiczony. Ćwiczenie z wymyślonym incydentem agenta, w którym konto pobiera dane na dużą skalę, szybko pokazuje, gdzie zgrzyta: brak dyżurów, niejasne kompetencje, logi, których nie da się analizować. Takie luki można zamknąć w spokoju, a nie w trakcie incydentu.
Przygotowanie zgłoszenia do organu nadzorczego
Art. 33 ust. 3 RODO określa minimalną treść. Opisuje się charakter naruszenia wraz z przybliżoną liczbą osób i rekordów, imię i nazwisko oraz dane kontaktowe inspektora ochrony danych lub innego punktu kontaktowego, prawdopodobne skutki oraz zastosowane lub proponowane środki. Właściwy jest z reguły organ nadzorczy państwa, w którym firma ma siedzibę. Większość organów udostępnia formularz online, a przegląd zapewnia Konferencja Ochrony Danych.
U agentów występują typowe luki. Zakresu dostępu nie da się określić bez logów, a przy zmianie danych nie wiadomo, które rekordy rzeczywiście dotknięto. Pomaga ustalenie z wyprzedzeniem, jak z logów, kopii zapasowych bazy i wersji danych wyprowadzić wiarygodną liczbę. Kto może tylko szacować, podaje przedział i oznacza go jako wstępny. Późniejsze uzupełnienie zgłoszenia wypełnia luki.
Krótka lista kontrolna zgłoszenia:
- Moment stwierdzenia naruszenia i okres incydentu
- Rodzaj naruszenia: nieuprawniony dostęp, zmiana, ujawnienie, utrata
- Dotknięte kategorie danych i przybliżona liczba osób i rekordów
- Rola agenta: obce narzędzie ataku czy własny agent
- Powstrzymane konta, klucze i systemy
- Prawdopodobne skutki dla osób, których dane dotyczą
- Decyzja o zawiadomieniu osób, których dane dotyczą
- Kontakt do inspektora ochrony danych
To, czy dodatkowo obowiązują obowiązki zgłoszeniowe z innych regulacji, na przykład dla operatorów infrastruktury krytycznej lub z rozporządzenia o AI, zależy od przypadku i powinno być wskazane w planie awaryjnym, aby kompetencji nie trzeba było ustalać dopiero w trakcie incydentu.
Podsumowanie
Pierwszy zgłoszony w Hiszpanii przypadek nie pokazuje nowego pojęcia prawnego, lecz nowe tempo. Niezależnie od tego, czy atakuje obcy agent, czy własny popełnia błąd, decydujące jest, czy doszło do naruszenia ochrony danych osobowych i czy istnieje ryzyko dla osób, których dane dotyczą. Wtedy trzeba działać bez zbędnej zwłoki i w miarę możliwości zgłosić w ciągu 72 godzin.
Krótka lista kontrolna:
- Obcy agenci jako napastnicy i własni agenci jako przyczyna to różne scenariusze z tą samą oceną.
- Odpowiedzialność pozostaje przy operatorze, także gdy uczestniczą platformy i dostawcy modeli.
- Czas wykrycia decyduje, czy termin da się dotrzymać.
- Dobre logi zamieniają podejrzenie w wiarygodne zgłoszenie.
- Minimalne uprawnienia, krótkotrwałe klucze i wyłącznik awaryjny odbierają atakowi tempo i szkodę.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
