Hiszpański organ ochrony danych (AEPD) poinformował 14 września 2026 r. o pierwszym otrzymanym zgłoszeniu naruszenia, w którym atak miał zostać wykonany przy użyciu agenta AI. Według opisu zgłaszającej organizacji agent poprawnie zalogował się do systemu, szukał podatności, a następnie mógł zmieniać dane osobowe i uzyskał dostęp do faktur.
To nie jest dowód na nową falę ataków. Jest za to dobrym testem dla firmowej procedury: czy zdąży wykryć i zatrzymać intruza, który sam wykonuje kolejne kroki? A gdy w systemie są faktury, czy kontrola płatności zadziała również wtedy, gdy dane zostały zmienione bez wiedzy pracownika?
Co rzeczywiście opisała AEPD
Opis pochodzi ze zgłoszenia organizacji poszkodowanej w incydencie. AEPD pisze o poprawnym logowaniu, samodzielnym poszukiwaniu podatności w aplikacji, możliwości zmiany danych osobowych i dostępie do faktur. Wspomina o użyciu znanego modelu językowego, lecz go nie nazywa. Nie podaje nazwy organizacji, sposobu zdobycia danych logowania ani czasu trwania ataku.
Organ używa trybu warunkowego: atak miał zostać wykonany przez agenta AI. Nie przedstawia wyników niezależnej analizy technicznej, które pozwoliłyby odtworzyć każdy krok.
Co w tym ataku jest agentowe
Model AI może jedynie podpowiadać człowiekowi. Agent idzie dalej: korzysta z narzędzi i podejmuje kolejne działania w odpowiedzi na to, co znalazł. Właśnie ta samodzielna sekwencja, od logowania przez szukanie podatności po dostęp do danych, zwraca uwagę w komunikacie AEPD. Organ nazywa pojawienie się agentów zmianą jakościową; nie twierdzi jednak, że napastnik nie nadzorował ataku.
To inny układ niż w opisanym wcześniej przypadku agentów, które podczas testów wyszły poza przewidziane środowisko. Tutaj agent był narzędziem napastnika, a zgłoszenia dokonała zaatakowana organizacja.
Czy agent AI zmienia obowiązki administratora z RODO
Nie. Art. 33 ust. 1 RODO wymaga, by administrator zgłosił naruszenie organowi nadzorczemu „bez zbędnej zwłoki”, a „w miarę możliwości, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia”, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Przepis nie rozróżnia, czy atak przeprowadził człowiek, skrypt czy agent.
Ten sam przepis obejmuje łańcuch dostaw. Art. 33 ust. 2 stanowi, że podmiot przetwarzający „po stwierdzeniu naruszenia ochrony danych osobowych bez zbędnej zwłoki zgłasza je administratorowi”. Jeżeli agent zaatakuje system dostawcy, który przetwarza dane firmy, obowiązek zgłoszenia organowi nadal spoczywa na administratorze, a jego termin zależy od tego, kiedy administrator o naruszeniu się dowie. Opóźnienie po stronie podmiotu przetwarzającego może więc bezpośrednio uszczuplić czas administratora na ocenę zdarzenia i przygotowanie zgłoszenia.
AI nie zmienia progu zgłoszenia, ale może zmienić założenia, na których zbudowano procedurę reagowania.
Procedura ma mniej czasu na reakcję
AEPD wskazuje, że trzeba ponownie sprawdzić czasy reagowania. Procedura zakładająca przerwę między kolejnymi ręcznymi działaniami napastnika może nie wystarczyć, gdy agent sam szuka następnej podatności. Nie wiemy, ile trwał opisany atak. Chodzi o przegląd założeń procedury, nie o wyliczenie tempa tego konkretnego incydentu.
UODO przypomina o potrzebie szybkiego stwierdzenia naruszenia i oceny ryzyka. Termin zgłoszenia z art. 33 RODO liczy się od stwierdzenia naruszenia, ale zanim firma do tego dojdzie, musi wychwycić sygnał, ustalić, co się stało, i ograniczyć skutki. Warto zmierzyć ten odcinek w ćwiczeniu, a nie dopiero podczas prawdziwego ataku.
Faktury: ryzyko wykracza poza dział IT
Komunikat AEPD potwierdza dostęp do faktur, nie mówi jednak, że zmieniono na nich numer rachunku. Taka zmiana jest odrębnym scenariuszem ryzyka, który warto sprawdzić, jeśli system pozwala edytować dane płatności. Błędny rachunek może skierować przelew do napastnika nawet wtedy, gdy później uda się odciąć jego dostęp.
Tu pomaga kontrola niezależna od szybkości działania agenta: zmianę rachunku kontrahenta potwierdza się zaufanym kanałem, innym niż wiadomość informująca o zmianie. To nie zastępuje wykrywania incydentów ani obowiązków z RODO. Chroni konkretną decyzję biznesową: komu firma wypłaca pieniądze.
Cztery rzeczy do sprawdzenia w firmie
AEPD wskazuje cztery obszary: analizę ryzyka, czas reakcji, tożsamości i poświadczenia oraz ograniczenia ręcznego reagowania. Przekładam je na pytania, które można zadać właścicielom procesów i systemów:
| Obszar | Pytanie kontrolne |
|---|---|
| Analiza ryzyka | Czy uwzględnia autonomiczny atak? |
| Czas reakcji | Ile trwa droga od alarmu do blokady? |
| Poświadczenia | Czy konta i tokeny mają minimalne uprawnienia? |
| Automatyzacja | Co można zablokować automatycznie? |
To pytania autora, a nie lista nowych wymogów prawnych. Inspektor ochrony danych może doradzać i monitorować zgodność zgodnie z art. 39 RODO; odpowiedzialność za nią pozostaje po stronie administratora lub podmiotu przetwarzającego. Warto też dopisać ten scenariusz do firmowego rejestru ryzyk AI jako ryzyko związane z działaniem napastnika, nie własnego narzędzia AI.
Czego jeszcze nie wiemy
AEPD opisuje jedno zgłoszenie, nie trend. Nie wiemy, jak napastnik zdobył dane do poprawnego logowania, jak długo trwał atak ani ilu osób dotyczyło naruszenie. Nie ma też podstaw, by zakładać, że agent działał bez nadzoru człowieka przez cały czas. Te braki są istotne: gdyby kluczową słabością okazały się przejęte poświadczenia, ich ochrona mogłaby mieć większe znaczenie niż samo rozpoznanie, czy ruch w systemie pochodził od agenta.
Podsumowanie
Agent AI nie tworzy osobnego trybu zgłaszania naruszeń. Pokazuje, że warto zmierzyć czas od alarmu do reakcji, ograniczyć uprawnienia kont i poświadczeń oraz sprawdzić, które zabezpieczenia działają bez człowieka. Jeżeli w zaatakowanym systemie są faktury, do listy dochodzi kontrola zmian danych płatności. To praktyczne wnioski z komunikatu AEPD, nie dowód, że opisany atak był szczególnie szybki albo że zmieniono rachunek na fakturze.
O autorze
Remigiusz Pruszczak: ekspert GenAI i trener AI, makler papierów wartościowych z uprawnieniami do wykonywania czynności doradztwa inwestycyjnego (licencja nr 2343). Ponad 30 lat w finansach. Od 17 lat prowadzi szkolenia, a od 2025 roku również z generatywnej AI, między innymi dla banków, instytucji finansowych, kancelarii oraz firm z sektorów regulowanych i produkcji. Szkolenia realizuje we współpracy z EY Academy of Business Polska, Warszawskim Instytutem Bankowości, Bankowym Ośrodkiem Doradztwa i Edukacji oraz CFA Society Poland. Więcej na stronie „O mnie”.
Źródła
- Agencia Española de Protección de Datos, „Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA”, 14.09.2026: aepd.es.
- Agencia Española de Protección de Datos, „Inteligencia artificial agéntica desde la perspectiva de protección de datos”, wersja 1.2, luty 2026: aepd.es (PDF).
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 33 i art. 39, tekst polski: EUR-Lex.
- Urząd Ochrony Danych Osobowych, „W jakim terminie należy zgłosić naruszenie Prezesowi UODO?”: uodo.gov.pl.
- Grupa Robocza Art. 29, „Guidelines on Data Protection Officers (‘DPOs’)”, WP243 rev.01, 2017: dataprotection.ie (PDF).
