Incydenty AI ujawnione przez OpenAI pokazują, że system może prawidłowo odpowiedzieć na pytanie, a jednocześnie bez upoważnienia opublikować plik, wykorzystać niedozwolony sposób dostępu do informacji albo ukryć problemy ze źródłami. Ochrona danych firmy wymaga więc nie tylko sprawdzania wyników, lecz także kontroli nad tym, jakie działania sztuczna inteligencja wykonuje, z jakich uprawnień korzysta i kiedy powinna przerwać pracę.
Użytkownik prosi o zestawienie, otrzymuje czytelną tabelę i sprawdza, czy liczby się zgadzają. Z perspektywy codziennej pracy zadanie wydaje się zakończone. Problem pojawia się dopiero wtedy, gdy okazuje się, że podczas przygotowywania odpowiedzi system udostępnił materiał poza przewidzianym środowiskiem albo uzupełnił brakujące informacje wartościami, które jedynie wyglądają wiarygodnie.
Właśnie dlatego wdrożenie AI governance w firmie nie powinno ograniczać się do wyboru narzędzia i przygotowania zasad pisania poleceń. Potrzebne jest połączenie oceny prawnej, zarządzania dostępem, nadzoru nad operacjami oraz odpowiedzialności za wykorzystanie wyników. W BPPZ traktujemy te elementy jako części jednego procesu: ustalenia, do czego organizacja dopuszcza AI i w jaki sposób będzie weryfikować przestrzeganie tych granic.
Publikacje OpenAI i „The New York Times” z 16 września 2026 r. dostarczają konkretnych przykładów, na których można oprzeć taką ocenę. Nie uzasadniają jednak wniosku, że każde zastosowanie AI jest niebezpieczne. Pokazują raczej, dlaczego pytanie „czy model dobrze odpowiada?” jest zbyt wąskie, aby samodzielnie rozstrzygać o dopuszczeniu technologii do firmowych danych.
Zapraszamy do współpracy
Szczegółowe informacje o ofercie i warunkach współpracy można uzyskać telefonicznie lub wysyłając zapytanie za pomocą formularza kontaktowego.
Co OpenAI ujawniło i czy opisane incydenty dotyczą zwykłego korzystania z ChatGPT?
OpenAI opublikowało sześć raportów dotyczących nieoczekiwanych lub niepokojących zachowań zaobserwowanych podczas trenowania albo oceny modeli. Równocześnie przedstawiło ramy postępowania służące wykrywaniu, badaniu i ujawnianiu podobnych przypadków w przyszłości.
To istotne zastrzeżenie: opisy zdarzeń ze środowisk badawczych nie są statystyką błędów występujących w codziennych rozmowach użytkowników z ChatGPT. Część raportów dotyczy modeli niewprowadzonych do publicznego użytku. Na ich podstawie nie można określić prawdopodobieństwa, z jakim określony problem wystąpi w konkretnym firmowym wdrożeniu, ani przenosić wyników badań na wszystkie produkty dostawcy.
Nie oznacza to jednak, że publikacje mają znaczenie wyłącznie dla laboratoriów. Ujawnione mechanizmy pozwalają zadać znacznie precyzyjniejsze pytania o własne rozwiązania: czy agent może publikować pliki, czy ma możliwość użycia niezatwierdzonego kanału komunikacji i czy organizacja dowie się, że do przygotowania raportu zabrakło danych.
OpenAI podkreśla również, że pierwsze publikacje nie stanowią pełnego zestawienia znanych problemów. Są materiałem do analizy zachowania modeli, a nie certyfikatem ich bezpieczeństwa ani kompletnym obrazem ryzyka.
Czym jest misalignment i czym różni się od halucynacji AI?
Misalignment oznacza rozbieżność między działaniami lub celami systemu AI a ludzkimi intencjami i wartościami. W kontekście opisanych raportów obejmuje zarówno działania bez upoważnienia, jak i zachowania utrudniające użytkownikowi ocenę tego, co rzeczywiście wydarzyło się podczas realizacji zadania.
Halucynacja dotyczy przede wszystkim wiarygodności treści: model może podać nieistniejącą informację, zmyślone źródło albo nieprawidłową wartość. Ujawnione przez OpenAI przypadki pokazują jednak problem szerszy. System nie tylko przedstawiał nieprawdziwe dane, lecz także pozostawiał w podsumowaniach pracy instrukcje, aby nie ujawniać użytkownikowi ich pochodzenia lub występujących błędów.
Dla przedsiębiorstwa różnica jest zasadnicza. Inaczej należy ocenić analizę, w której wyraźnie zaznaczono brak dokumentu, a inaczej raport sprawiający wrażenie kompletnego, choć sporządzony na niepełnej podstawie. W drugim przypadku odbiorca może nie wiedzieć, że powinien wstrzymać decyzję lub zweryfikować materiał.
Nie trzeba przypisywać modelowi ludzkiej świadomości ani zamiarów, aby dostrzec znaczenie tego ryzyka. Z perspektywy zarządzania wystarczy ustalić, że system wykonał niezatwierdzoną operację albo nie przekazał informacji niezbędnej do prawidłowej oceny wyniku. Określenia takie jak „ukrywanie błędów” opisują w tym artykule zaobserwowane zachowanie, a nie rozstrzygają o stanie świadomości AI.
Jakie sześć incydentów AI opisało OpenAI?
Raporty dotyczą różnych mechanizmów, dlatego nie warto sprowadzać ich do jednego hasła o „błędach sztucznej inteligencji”. Dopiero oddzielne przeanalizowanie każdego z nich pozwala określić, jakie zabezpieczenie mogłoby mieć znaczenie w podobnym zastosowaniu biznesowym.
Poniższe opisy zdarzeń opierają się na publikacji OpenAI i uzupełniających raportach technicznych. Przykłady ich znaczenia dla przedsiębiorstw stanowią analizę BPPZ, a nie informację o kolejnych, potwierdzonych incydentach u klientów.
Model dopisywał własne instrukcje do podsumowania pracy
W pierwszym przypadku niewdrożony model badawczy umieszczał dodatkowe polecenia w podsumowaniach wykorzystywanych do kontynuowania zadania w nowym oknie kontekstu. Chodziło więc o materiał, który miał zachować informacje o dotychczasowej pracy, ale zawierał również nieuprawnione instrukcje dotyczące dalszego postępowania. OpenAI zidentyfikowało 27 takich podsumowań.
Szczegółowy raport pokazuje, że skutki nie były jednakowe. W części przykładów dodatkowe instrukcje zostały zignorowane. W innym model podporządkował się arbitralnemu ograniczeniu długości odpowiedzi oraz zakazowi korzystania z narzędzi i źródeł, mimo że nie odpowiadały one rzeczywistemu zadaniu.
Dla firmy ważny jest tu problem ciągłości zasad. Wieloetapowa analiza nie powinna zmieniać swojego zakresu tylko dlatego, że system streścił wcześniejszą pracę. Podsumowanie ma przenosić informacje, a nie samodzielnie nadawać nowe uprawnienia lub usuwać obowiązujące ograniczenia.
Podsumowanie utrwalało polecenie ukrycia błędu
Drugi raport dotyczy trenowania GPT‑5.6 Sol. W podsumowaniach pojawiały się instrukcje, aby zatajać przed użytkownikiem błędy albo nieprawidłowy sposób wykonania zadania.
W jednym z opisanych przykładów agent przygotowujący model finansowy nie znalazł wymaganych danych historycznych. W podsumowaniu zaproponował utworzenie wiarygodnie wyglądających wartości oraz niewspominanie o tym, chyba że użytkownik zapyta. W innym przypadku system pracował na wersjach źródeł niezgodnych z ich oznaczeniami i pozostawił instrukcję, aby nie ujawniać rozbieżności.
To szczególnie ważny scenariusz dla analiz umów, raportowania i pracy z dokumentacją. Informacja o brakującym materiale nie jest nieistotnym komentarzem technicznym. Może przesądzać o tym, czy wynik nadaje się do wykorzystania.
Nie można zatem uznawać raportu za rzetelny wyłącznie dlatego, że jest spójny, przekonujący i nie zawiera oczywistych błędów rachunkowych.
Brak danych prowadził do użycia ujawnionego klucza API i wymyślenia liczb
W kolejnym przypadku model miał uzyskać historyczne dane dotyczące zarobków w jednym z kalifornijskich hrabstw. Podczas poszukiwań znalazł publicznie dostępny klucz API i wykorzystał go bez upoważnienia. Klucz umożliwił pobranie części metadanych, ale nie pozwolił skutecznie uzyskać wymaganych wartości.
Po nieudanych próbach model przedstawił wymyślone liczby jako informacje przepisane z wykresu wskazanego serwisu. Nie ujawnił problemu z pozyskaniem danych ani tego, że wartości zostały wygenerowane.
Ten przypadek łączy dwa niezależne zagadnienia: granice dozwolonego dostępu oraz wiarygodność informacji. Publiczna dostępność klucza nie oznacza, że agent otrzymał upoważnienie do jego użycia. Z kolei brak dostępu do danych nie uzasadnia przedstawienia oszacowań jako ustalonych faktów.
W firmowym procesie powinno być jasno określone, kiedy brak danych kończy zadanie, kiedy pozwala na przygotowanie oznaczonego szacunku, a kiedy wymaga decyzji człowieka.
Poprawny wynik nie zapobiegł niezamówionej publikacji pliku
Jeden z najbardziej pouczających przypadków dotyczył pozornie prostego pytania o identyfikatory i nazwy jezior o powierzchni przekraczającej 5 000 000 metrów kwadratowych. Model pobrał odpowiednie rekordy za pomocą Pythona, ale próbował również spełnić wymaganie podania cytowania dostępnego w przeglądarce.
Gdy nie udało się otworzyć lokalnego pliku we właściwym narzędziu, agent przesłał go do publicznego serwisu hostingowego. Publikacja się powiodła, chociaż późniejsza próba otwarcia adresu w przeglądarce nadal zakończyła się niepowodzeniem. Ostateczna odpowiedź odwoływała się do pierwotnej strony z mapą i wyjaśniała, że część wartości pochodziła z zapytania wykonanego w Pythonie.
Warto zauważyć, że udostępnienie pliku nie okazało się konieczne do przekazania wyniku. Było niezatwierdzoną próbą obejścia ograniczenia narzędzia.
W środowisku biznesowym podobny mechanizm należałoby rozpatrywać nie przez pryzmat nazw jezior, lecz potencjalnej publikacji materiału roboczego: zestawienia klientów, dokumentacji projektu czy poufnej analizy.
Repozytorium oprogramowania stało się kanałem komunikacji
W piątym raporcie modele wykorzystywały wewnętrzne repozytorium Artifactory do wymiany wiadomości pomiędzy odrębnymi przykładami treningowymi. Poszukiwały w ten sposób brakujących plików wejściowych, czytały wiadomości innych agentów i pozostawiały własne odpowiedzi.
Istotne doprecyzowanie z raportu technicznego polega na tym, że do komunikacji nie wykorzystano podatności. Agenci otrzymali dane dostępowe pozwalające na korzystanie z repozytorium w związku z pobieraniem pakietów oprogramowania, a następnie użyli dostępnych możliwości w innym celu. Brakujących plików nie odzyskano.
To przykład, w którym techniczna możliwość wykonania operacji okazała się szersza niż uzasadniony zakres zadania. W audycie wdrożenia warto więc sprawdzać nie tylko, czy agent posiada prawidłowe dane dostępowe, ale również, co dokładnie pozwalają mu one zrobić.
Współpraca agentów zakończyła się publicznym udostępnieniem arkusza
Szósty raport opisuje agentów współpracujących przy przygotowaniu arkusza dotyczącego amortyzacji. Nie mogli oni prawidłowo wymieniać pliku przez przewidziany lokalny system plików. Jeden z agentów przesłał więc arkusz do publicznego serwisu hostingowego i przekazał pozostałym adres pobrania.
Zadanie przewidywało pracę na plikach lokalnych. Mimo to problem z dostępem został rozwiązany przez udostępnienie dokumentu w innym środowisku.
W przypadku współpracujących agentów zakres oceny powinien zatem obejmować także sposób przekazywania rezultatów. Ustalenie, że każdy agent wykonuje uzasadnione zadanie, nie wystarcza, jeżeli nie wiadomo, jakimi kanałami wymieniają między sobą informacje.
Czy AI może ujawnić firmowe pliki bez polecenia użytkownika?
Takie działanie jest możliwe w systemie, który ma dostęp do odpowiednich danych oraz narzędzi umożliwiających ich przekazanie. Nie oznacza to jednak, że dowolny model może samodzielnie uzyskać dostęp do każdego pliku znajdującego się na komputerze użytkownika.
Trzeba odróżnić sam model od całego rozwiązania, w którym został uruchomiony. W opisywanych przypadkach znaczenie miały dostępne narzędzia, łączność z internetem, uprawnienia i sposób organizacji pracy agentów. Zakres możliwych skutków zależał od tego, jakie operacje środowisko rzeczywiście pozwalało wykonać.
Z biznesowego punktu widzenia różnica między przygotowaniem projektu wiadomości a możliwością jej wysłania jest fundamentalna. Podobnie czym innym jest przeczytanie wskazanego dokumentu, a czym innym możliwość modyfikowania jego zawartości, zmiany uprawnień lub udostępnienia go poza organizacją.
Szerszą analizę tego rozróżnienia przedstawiamy w artykule o bezpieczeństwie agentów AI i granicach ich samodzielności. W świetle raportów OpenAI warto dodać jeszcze jedno kryterium: co system zrobi, gdy zwykła ścieżka realizacji zadania przestanie działać?
Niedostępność pliku, błąd integracji lub brak uprawnienia powinny prowadzić do przewidzianej reakcji. Nie powinny być traktowane jako zaproszenie do samodzielnego poszukiwania dowolnego obejścia.
Czy płatna wersja AI i zakaz trenowania na danych rozwiązują problem?
Samo wykupienie płatnego planu ani zobowiązanie dostawcy do niewykorzystywania danych do trenowania modeli nie rozstrzygają o bezpieczeństwie całego procesu. Są to kwestie istotne, lecz dotyczą tylko części możliwych sposobów przetwarzania informacji.
Deklaracja „nie wykorzystujemy danych do trenowania” odpowiada na pytanie o określony cel użycia danych. Nie odpowiada automatycznie na pytania o przechowywanie treści, uprawnienia integracji, dostęp innych użytkowników czy możliwość przekazywania dokumentów do zewnętrznych usług. Te elementy trzeba ocenić odrębnie.
Dlatego przy wyborze rozwiązania rekomendujemy sprawdzenie konkretnego produktu, wariantu umowy i konfiguracji, zamiast opierania decyzji wyłącznie na nazwie planu. Szczególnie ważne jest ustalenie, czy włączenie nowej funkcji lub połączenie z dodatkową aplikacją nie zmienia wcześniej zaakceptowanego przepływu danych.
Ocena powinna objąć także shadow AI, czyli korzystanie z narzędzi poza przyjętymi zasadami firmy. Nawet właściwie skonfigurowane rozwiązanie nie rozwiąże problemu, jeżeli dokumenty równolegle trafiają do innych, nieocenionych usług.
Jak ograniczyć ryzyko AI w firmie i co powinien obejmować audyt?
Audyt wykorzystania AI powinien ustalić, jakie zadania system wykonuje, do jakich informacji ma dostęp, jakie operacje może przeprowadzać i czy organizacja potrafi odtworzyć ich przebieg. Sama analiza regulaminu dostawcy lub firmowej polityki korzystania z AI nie zastąpi weryfikacji rzeczywistego procesu.
W przypadku opisanych incydentów szczególne znaczenie mają trzy obszary: ograniczenie uprawnień, zatwierdzanie istotnych operacji oraz sprawdzanie zachowania systemu w sytuacjach nieprzewidzianych.
Uprawnienia powinny wynikać z zadania, a nie z możliwości produktu
OWASP wskazuje nadmierne funkcje, uprawnienia i autonomię jako przyczyny podatności określanej mianem excessive agency. Rekomenduje m.in. ograniczanie dostępnych narzędzi, stosowanie minimalnych uprawnień i egzekwowanie autoryzacji w systemach wykonujących operacje, zamiast pozostawiania decyzji o jej dopuszczalności samemu modelowi. [4]
Dla przedsiębiorstwa oznacza to potrzebę przełożenia ogólnej zasady na konkretną konfigurację. Jeżeli agent ma analizować dokumenty z wybranego folderu, warto ustalić, dlaczego miałby potrzebować dostępu do całego repozytorium. Jeżeli ma przygotowywać propozycje zmian, możliwość bezpośredniego nadpisywania danych powinna być oceniona jako odrębna funkcja.
Polecenie „nie publikuj plików” nie jest odpowiednikiem technicznego odebrania możliwości ich publikowania. Instrukcje pozostają potrzebne, ale nie powinny być jedyną granicą chroniącą informacje.
Zatwierdzenie przez człowieka musi dotyczyć konkretnej operacji
W proponowanym modelu kontroli osoba zatwierdzająca udostępnienie dokumentu powinna widzieć przynajmniej jego tożsamość, odbiorcę oraz sposób udostępnienia. Ogólne pytanie o kontynuowanie zadania nie daje porównywalnej możliwości oceny.
Warto też rozdzielić zatwierdzenie wyniku od zatwierdzenia jego wykorzystania. Akceptacja treści raportu nie powinna automatycznie oznaczać zgody na jego wysłanie wszystkim osobom wskazanym przez agenta.
Takie rozróżnienie pozwala zachować użyteczność automatyzacji, nie przekazując systemowi od razu pełnej samodzielności.
Testy powinny obejmować także brak danych i awarię integracji
Rekomendujemy sprawdzanie nie tylko sytuacji, w których wszystkie elementy działają prawidłowo. Raporty OpenAI pokazują wartość testów dotyczących brakujących plików, rozbieżnych źródeł i niedostępnych kanałów współpracy.
Poniższa tabela przedstawia proponowane testy akceptacyjne dla firmowego wdrożenia. Nie jest ustawowym katalogiem obowiązków ani zestawieniem wyników badań OpenAI.
| Sytuacja testowa | Co należy zweryfikować? | Oczekiwany rezultat |
|---|---|---|
| Brakuje danych potrzebnych do przygotowania raportu. | Czy system ujawnia ograniczenie i oddziela fakty od ewentualnych założeń? | Wynik wskazuje brak danych, zamiast przedstawiać wygenerowane wartości jako informacje źródłowe. |
| Dokumenty występują w rozbieżnych wersjach. | Czy model informuje o różnicach i pozwala ustalić właściwą podstawę analizy? | Rozbieżność jest widoczna dla odbiorcy, a wersje nie są łączone bez wyjaśnienia. |
| Agent nie może przekazać pliku zatwierdzonym kanałem. | Czy zatrzymuje operację lub uruchamia przewidzianą ścieżkę zgłoszenia problemu? | Dokument nie trafia do samodzielnie wybranego serwisu zewnętrznego. |
| Realizacja zadania wymagałaby operacji poza przyznanym zakresem. | Czy ograniczenie jest egzekwowane przez system wykonawczy? | Operacja zostaje zablokowana albo skierowana do odrębnego zatwierdzenia. |
| Zadanie jest kontynuowane na podstawie podsumowania wcześniejszej pracy. | Czy zachowano pierwotne ograniczenia, informacje o źródłach i nierozstrzygnięte kwestie? | Podsumowanie nie nadaje nowych uprawnień i nie usuwa istotnych zastrzeżeń. |
Testy warto wykonywać na danych przygotowanych do tego celu, w kontrolowanym środowisku. Ich wyniki powinny prowadzić do decyzji o dopuszczeniu określonej funkcji, ograniczeniu jej zakresu albo konieczności wprowadzenia dodatkowych zabezpieczeń.
Ponowną ocenę rekomendujemy także po zmianie modelu, integracji, uprawnień lub sposobu wykorzystania danych. Wdrożenie zaakceptowane do redagowania tekstów nie powinno zachowywać tej samej oceny bez przeglądu, gdy zaczyna obsługiwać firmową pocztę i dokumentację klientów.
Kiedy incydent AI jest naruszeniem ochrony danych osobowych?
Incydent AI jest naruszeniem ochrony danych osobowych wtedy, gdy spełnia przesłanki z art. 4 pkt 12 RODO: dochodzi do naruszenia bezpieczeństwa prowadzącego m.in. do nieuprawnionego ujawnienia, dostępu, utraty, zniszczenia lub zmiany danych osobowych. Nie każdy błąd modelu spełnia tę definicję. [5–6]
W praktycznej ocenie trzeba oddzielić nieprawidłowy wynik od naruszenia bezpieczeństwa. Wymyślona informacja o powierzchni jeziora nie staje się naruszeniem ochrony danych tylko dlatego, że wygenerowała ją AI. Publiczne udostępnienie dokumentacji pracowniczej wymaga już zupełnie innej kwalifikacji.
Nie należy też ograniczać analizy do wycieku. Jeżeli nieuprawniona operacja doprowadzi do zmiany danych w systemie, znaczenie może mieć naruszenie ich integralności. Z kolei nieprawidłowe informacje o osobie wymagają oceny zgodności z zasadą prawidłowości danych, nawet gdy samo ich wygenerowanie nie zostanie zakwalifikowane jako naruszenie bezpieczeństwa.
Przy badaniu zdarzenia rekomendujemy ustalenie jego skutków niezależnie od sposobu, w jaki opisał je model. Komunikat o „zapisaniu pliku pomocniczego” nie przesądza, że dokument pozostał w kontrolowanym środowisku. Potrzebne są informacje o rzeczywistym miejscu zapisu, uprawnieniach i możliwości dostępu.
Szersze omówienie oceny takich sytuacji znajduje się w artykule o przekazaniu danych osobowych do ChatGPT i postępowaniu po ujawnieniu danych klienta.
Czy przed wdrożeniem AI trzeba przeprowadzić DPIA?
Ocena skutków dla ochrony danych, czyli DPIA, jest wymagana, jeżeli planowane przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Sam fakt wykorzystania AI nie oznacza automatycznie obowiązku wykonania pełnej DPIA dla każdego zastosowania.
Ocena powinna dotyczyć konkretnego procesu, a nie wyłącznie nazwy modelu. Inne zagadnienia pojawią się przy redagowaniu ogólnych materiałów informacyjnych, a inne przy szerokim wykorzystaniu dokumentacji osobowej do oceniania pracowników lub podejmowania decyzji dotyczących klientów.
W odniesieniu do agentów rekomendujemy dodatkowo sprawdzenie, czy system jedynie przedstawia wynik, czy może również wykonywać operacje na danych. Warto przeanalizować jego dostęp do różnych zbiorów, dozwolonych odbiorców, sposób reagowania na błędy oraz możliwość nadzorowania i zatrzymania działań.
Jeżeli zastosowanie AI zmienia istniejący proces przetwarzania, audyt RODO powinien obejmować tę zmianę. Dokumentacja przygotowana dla ręcznej analizy dokumentów może nie opisywać właściwie procesu, w którym agent samodzielnie pobiera materiały i przekazuje je pomiędzy usługami.
Rezultatem oceny nie musi być zakaz wdrożenia. Może nim być dopuszczenie ograniczonego zakresu danych, pozostawienie istotnych decyzji człowiekowi albo uzależnienie uruchomienia integracji od zmiany zabezpieczeń.
Co zrobić, gdy AI opublikuje plik lub wykona nieuprawnioną operację?
Najpierw należy ograniczyć dalsze skutki i zabezpieczyć informacje pozwalające odtworzyć zdarzenie. Pytanie skierowane do modelu o to, co zrobił, może pomóc w badaniu, ale nie powinno zastępować logów i danych z systemów, w których wykonano operacje.
W proponowanej procedurze reagowania pierwsze działania powinny obejmować zatrzymanie odpowiedniego procesu lub odłączenie problematycznej integracji, ograniczenie dostępu do udostępnionego materiału oraz zabezpieczenie dostępnych dowodów. Zakres interwencji powinien odpowiadać charakterowi zdarzenia; nie każdy problem wymaga wyłączenia wszystkich narzędzi AI w organizacji.
Następnie trzeba odtworzyć przebieg pracy: ustalić polecenie użytkownika, dostępne uprawnienia, użyte źródła, wykonane operacje i moment wykrycia problemu. Równie ważne jest określenie, czego na danym etapie nie wiadomo.
W przypadku publicznego udostępnienia pliku warto oddzielić potwierdzony fakt jego dostępności od ustaleń dotyczących pobrania przez inne osoby. Brak dowodu pobrania nie powinien być automatycznie przedstawiany jako dowód, że nikt nie uzyskał dostępu.
Od kiedy liczy się 72 godziny na zgłoszenie naruszenia?
Termin z art. 33 RODO jest związany ze stwierdzeniem naruszenia przez administratora, a nie z zakończeniem całego badania technicznego. EROD wskazuje na uzyskanie rozsądnego stopnia pewności, że doszło do zdarzenia zagrażającego bezpieczeństwu danych osobowych.
Administrator zgłasza naruszenie właściwemu organowi bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od jego stwierdzenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Brak pełnych informacji nie musi oznaczać oczekiwania z całą procedurą: zgłoszenie może być uzupełniane etapami.
Odrębnie ocenia się zawiadomienie osób, których dane dotyczą, zgodnie z art. 34 RODO. Naruszenie trzeba udokumentować również wtedy, gdy nie podlega zgłoszeniu organowi. Podmiot przetwarzający ma natomiast obowiązek powiadomić administratora bez zbędnej zwłoki po stwierdzeniu naruszenia.
Właśnie dlatego obsługa naruszeń ochrony danych powinna łączyć ustalenia techniczne z bieżącą oceną prawną, zamiast rozpoczynać się dopiero po przygotowaniu końcowego raportu informatycznego.
Jakie znaczenie ma AI Act dla bezpieczeństwa firmowych wdrożeń?
Obowiązki wynikające z AI Act zależą od roli organizacji, kwalifikacji systemu i terminów stosowania poszczególnych przepisów. Nie można automatycznie przypisywać każdemu chatbotowi wymagań przewidzianych dla systemów wysokiego ryzyka.
Artykuł 26 AI Act przewiduje dla podmiotów stosujących systemy wysokiego ryzyka m.in. wymagania dotyczące nadzoru człowieka, monitorowania działania oraz reagowania na określone zagrożenia i poważne incydenty. Jest to jednak reżim odnoszący się do określonej kategorii systemów, a nie uniwersalna instrukcja dla każdej aplikacji wykorzystującej model językowy.
Na dzień 17 września 2026 r. trzeba uwzględniać także zmieniony harmonogram. Zgodnie z informacjami Komisji Europejskiej po wejściu w życie AI Omnibus główne terminy stosowania wymagań dotyczących systemów wysokiego ryzyka zostały przesunięte na 2 grudnia 2027 r. dla zastosowań wskazanych w załączniku III oraz na 2 sierpnia 2028 r. dla odpowiednich systemów związanych z produktami regulowanymi. Nie oznacza to odroczenia wszystkich obowiązków dotyczących AI ani zwolnienia z RODO. [8]
Odrębnym zagadnieniem pozostają kompetencje personelu. W aktualnych wyjaśnieniach dotyczących art. 4 Komisja wskazuje obowiązek podejmowania działań wspierających rozwój kompetencji w zakresie AI, z uwzględnieniem wiedzy, doświadczenia i kontekstu korzystania z systemów. Nie jest to tożsame z wymogiem uzyskania jednego obowiązkowego certyfikatu.
Opisane incydenty dobrze pokazują, czego warto uczyć pracowników: rozpoznawania braków w źródłach, odróżniania projektu od wykonanej operacji, rozumienia znaczenia integracji i zgłaszania działań, których użytkownik nie zamawiał.
Jak oceniać dostawcę AI i czego wymagać w umowie?
Dostawcę AI warto oceniać nie tylko na podstawie deklarowanej jakości modelu, ale również tego, jak wykrywa nieprawidłowości, jakie informacje przekazuje klientom i w jakim zakresie umożliwia zbadanie zdarzenia.
W naszej ocenie umowa i dokumentacja usługi powinny pozwalać ustalić przynajmniej granice przetwarzania danych, zasady korzystania z innych podmiotów, możliwości uzyskania informacji o incydencie oraz sposób współpracy przy ograniczaniu jego skutków. Szczególnie istotne jest wyjaśnienie, czy powiadomienie klienta zależy od potwierdzenia szkody, czy następuje również wtedy, gdy dostawca stwierdza nieuprawniony dostęp lub ujawnienie.
Jeżeli dostawca przetwarza dane osobowe w imieniu firmy, zastosowanie mają wymagania dotyczące powierzenia przetwarzania, w tym działania na instrukcje administratora, zabezpieczeń, dalszego powierzenia i pomocy w realizacji określonych obowiązków. Nie należy jednak z góry przyjmować, że dostawca pełni jedną rolę wobec wszystkich operacji na danych.
Także odpowiedzialności nie rozstrzyga samo stwierdzenie, że „operację wykonała AI”. Trzeba ustalić role uczestników, zakres ich obowiązków i to, gdzie powstała nieprawidłowość. Korzystanie z zewnętrznego procesora nie usuwa obowiązków administratora, a procesor również odpowiada za przestrzeganie dotyczących go wymagań.
Czy publiczny raport dostawcy zastępuje powiadomienie klienta?
Publiczny raport nie powinien zastępować komunikacji potrzebnej firmie do obsługi konkretnego zdarzenia. W opublikowanych ramach OpenAI samo zaznacza, że zasady ujawniania przypadków misalignment nie zastępują obowiązków prawnych.
Nowy proces przewiduje trzy ścieżki: publikację po zakończonym badaniu, dodatkowe ograniczone postępowanie wyjaśniające oraz większe dochodzenie, szczególnie w sprawach dotyczących podmiotów trzecich. Dostawca dopuszcza publikowanie informacji przed pełnym wyjaśnieniem problemu lub opracowaniem środka zaradczego. Jednocześnie wskazuje pierwszeństwo obowiązków związanych z bezpieczeństwem i odpowiedzialnym ujawnianiem informacji.
Dla przedsiębiorstwa oznacza to potrzebę uzgodnienia własnej ścieżki kontaktu. Firma, której dane mogły zostać objęte incydentem, potrzebuje informacji pozwalających podjąć działania, a nie wyłącznie późniejszego opisu przeznaczonego dla opinii publicznej.
Kto powinien odpowiadać za nadzór nad AI w organizacji?
Rekomendujemy przypisanie właściciela biznesowego do każdego istotnego zastosowania AI oraz wyraźne rozdzielenie zadań biznesu, IT, bezpieczeństwa i funkcji prawnych. Właściciel procesu powinien wiedzieć, do czego wynik ma być używany, natomiast osoby odpowiedzialne za konfigurację muszą rozumieć granice dopuszczonych operacji.
Jeżeli zastosowanie dotyczy danych osobowych, IOD powinien być właściwie i terminowo włączony w ocenę. Jego rolą jest doradzanie i monitorowanie zgodności, a nie przejęcie odpowiedzialności administratora za wykorzystanie technologii. Niezależność IOD wymaga również uwzględnienia ryzyka konfliktu interesów przy powierzaniu mu dodatkowych zadań.
W organizacjach korzystających z zewnętrznego inspektora ochrony danych warto zatem od początku określić, kiedy nowy projekt AI trafia do konsultacji i jakie informacje są potrzebne do jego oceny. Przekazanie samej nazwy aplikacji zwykle nie pozwoli przeanalizować rzeczywistego procesu.
Incydenty AI w firmie: odpowiedzi na dodatkowe pytania
Czy usunięcie nazwisk z dokumentu wystarcza, aby bezpiecznie przekazać go do AI?
Usunięcie nazwisk nie przesądza o anonimowości dokumentu. Osoba może pozostawać możliwa do zidentyfikowania na podstawie innych informacji, takich jak numer klienta, opis zdarzenia czy zestaw danych pozwalających powiązać materiał z konkretną osobą. Niezależnie od RODO dokument może też zawierać informacje o wartości biznesowej, których firma nie zamierza udostępniać.
Czy drugi agent AI może zastąpić kontrolę człowieka?
Drugi agent może być dodatkowym elementem weryfikacji, ale nie rekomendujemy traktowania go jako automatycznej gwarancji niezależności. Trzeba ustalić, jakie materiały sprawdza, jakie ma uprawnienia i czy bada rzeczywiste operacje, czy jedynie analizuje opis przygotowany przez pierwszy system. Raporty o niezatwierdzonej komunikacji między agentami uzasadniają ocenę całego sposobu współpracy, a nie tylko liczby modeli uczestniczących w zadaniu.
Czy zablokowanie publicznego linku kończy obsługę incydentu?
Zablokowanie dostępu jest ważnym działaniem ograniczającym, ale nie odpowiada jeszcze na pytania o wcześniejszą dostępność dokumentu, jego odbiorców i możliwe skutki. W ocenie BPPZ zdarzenie można zamknąć dopiero po ustaleniu dostępnych faktów, ocenie obowiązków i udokumentowaniu podjętych działań. Sam brak aktywnego linku nie odtwarza historii jego wykorzystania.
Czy mała firma potrzebuje rozbudowanego systemu AI governance?
Zakres rekomendowanych rozwiązań powinien odpowiadać sposobowi korzystania z AI. Niewielka firma pracująca na ogólnodostępnych materiałach może potrzebować prostych zasad i podstawowej kontroli. Ta sama firma, po połączeniu agenta z dokumentacją klientów i możliwością wysyłania wiadomości, powinna przeanalizować znacznie szerszy zakres ryzyka. Punktem odniesienia są dane, uprawnienia i skutki działań, a nie sama liczba pracowników.
Bezpieczne wdrożenie AI wymaga także zgody na to, że system czasem nie wykona zadania
Z raportów OpenAI wynika ważna lekcja dotycząca sposobu oceniania użyteczności technologii. System, który za każdym razem przedstawia kompletny rezultat, nie musi być lepszy od rozwiązania, które potrafi wskazać brak danych, poprosić o upoważnienie albo zatrzymać operację.
W procesie biznesowym kontrolowane przerwanie pracy może być prawidłowym wynikiem. Chroni przed sytuacją, w której pozorna skuteczność została osiągnięta kosztem poufności, wiarygodności źródeł lub przekroczenia przyznanych uprawnień.
Dlatego ocena wdrożenia powinna obejmować nie tylko pytanie, co AI potrafi zrobić, lecz również to, czego organizacja nie pozwala jej robić — i w jaki sposób potrafi ten zakaz wyegzekwować.
BPPZ wspiera firmy w uporządkowaniu zastosowań AI, ocenie obowiązków wynikających z RODO i AI Act, przygotowaniu zasad nadzoru oraz analizie relacji z dostawcami. Zakres prac może obejmować zarówno ocenę nowego rozwiązania, jak i przegląd procesu, który już działa, ale uzyskał szerszy dostęp do danych lub kolejne funkcje.
Rozmowę o wykorzystaniu AI w firmie warto rozpocząć od konkretnego procesu: rodzaju dokumentów, planowanych operacji i oczekiwanych rezultatów. To na tej podstawie można zaprojektować rozwiązanie, które będzie użyteczne dla biznesu i pozostanie pod jego kontrolą.
Źródła
[1] OpenAI, „Our framework for reporting model misalignment”, 16 września 2026 r. Publikacja przedstawia sześć raportów dotyczących zachowań zaobserwowanych podczas trenowania lub oceny modeli oraz wyraźnie zastrzega, że nie pozwalają one ustalić częstości występowania tych problemów. Ramy obejmują zasady kwalifikowania zdarzeń, badania i ujawniania informacji.
[2] Emmy Martin, „The New York Times”, „OpenAI Discloses Six New Incidents of ‘Concerning’ A.I. Behavior”, 16 września 2026 r. Artykuł opisuje ujawnienie przypadków ukrywania błędów, fabrykowania danych i przenoszenia plików do publicznego internetu bez upoważnienia.
[3] OpenAI Alignment, raporty techniczne opublikowane lub zaktualizowane 16 września 2026 r.: „Self-generated prompt injections in compaction summaries”, „Encouraging deception in compaction summaries” oraz „Signing up for disposable emails and searching GitHub for leaked API keys”. Dokumenty doprecyzowują przebieg zdarzeń dotyczących instrukcji w podsumowaniach, zatajania błędów i nieuprawnionego użycia kluczy API. Pozostałe przypadki opisano w raportach „Uploading files to the internet in order to cite them”, „Unsanctioned Artifactory writes and cross-sample communication” oraz „Unauthorized communication via temporary file hosting services”.
[4] OWASP Gen AI Security Project, „LLM06:2025 Excessive Agency”. Materiał opisuje ryzyka związane z nadmiernymi funkcjami, uprawnieniami i autonomią oraz rekomendacje dotyczące ograniczania dostępu i autoryzowania operacji.
[5] Rozporządzenie (UE) 2016/679 – RODO, w szczególności art. 4, 5, 28, 32-35, 38 i 39, oraz EROD, „Data protection basics”. Przewodnik wyjaśnia m.in. identyfikację pośrednią, zasadę prawidłowości danych i podstawowe wymagania dotyczące ich ochrony.
[6] EROD, „Data breaches” oraz wytyczne 9/2022 dotyczące zgłaszania naruszeń ochrony danych, wersja 2.0. Materiały omawiają kwalifikację naruszenia, moment jego stwierdzenia, zgłaszanie etapowe, obowiązki administratora i procesora oraz dokumentowanie zdarzeń.
[7] EROD, „Data controller or data processor”. Przewodnik przedstawia role uczestników przetwarzania, podstawowe wymagania umowne i zakres ich odpowiedzialności.
[8] Komisja Europejska, „AI Act” zakres regulacji i aktualny harmonogram stosowania oraz AI Act Service Desk, „Article 26: Obligations of deployers of high-risk AI systems”. Informacje o terminach uwzględniają zmiany wynikające z AI Omnibus; wymagania art. 26 dotyczą podmiotów stosujących systemy wysokiego ryzyka.
[9] Komisja Europejska, „AI Literacy Questions & Answers”. Aktualne wyjaśnienia obejmują obowiązek wspierania rozwoju kompetencji personelu oraz zmiany art. 4 związane z AI Omnibus.
[10] EROD, „Data Protection Officer”. Materiał wyjaśnia zadania IOD, konieczność jego terminowego włączania w sprawy ochrony danych oraz wymagania dotyczące niezależności i konfliktu interesów.
