Bezpieczeństwo AI: kto kontroluje systemy, które działają za nas?

Sztuczna inteligencja, która przygotowuje projekt wiadomości, i sztuczna inteligencja, która samodzielnie ją wysyła, to nie ten sam problem biznesowy. W pierwszym przypadku organizacja kupuje wsparcie w pracy. W drugim przekazuje technologii możliwość działania w swoim imieniu. Gdy do tego dochodzą dostęp do dokumentów, systemów informatycznych i danych klientów, bezpieczeństwo AI przestaje być pytaniem o jakość odpowiedzi. Staje się pytaniem o granice powierzonych uprawnień.

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.

BPPZ – Biuro Porad Prawnych Zacharski

• +48 600 784 526
• kontakt@bppz.pl

Zadzwoń Napisz wiadomość

Właśnie tę granicę coraz wyraźniej widać w debacie o rozwoju najbardziej zaawansowanych modeli. We wrześniu 2026 r. Dario Amodei, współzałożyciel Anthropic, wystąpił z apelem o ograniczenie tempa zwiększania ich możliwości. Kierunek poparli również przedstawiciele konkurencyjnych firm, w tym Sam Altman, Elon Musk i Demis Hassabis. Przedmiotem sporu nie jest jednak to, czy AI powinna istnieć. Chodzi o to, czy branża potrafi wykazać, że zachowuje kontrolę nad technologią, którą rozwija.

Dla przedsiębiorstw to znacznie więcej niż wiadomość z Doliny Krzemowej. To moment, w którym warto ponownie ocenić własne wdrożenia: nie według liczby zakupionych licencji, lecz według zakresu decyzji i operacji oddanych systemom. W BPPZ tak rozumiemy AI governance: jako połączenie oceny ryzyka, wymagań prawnych, relacji z dostawcami i odpowiedzialności za rzeczywiste wykorzystanie technologii.

Od chatbota do agenta AI: zmienia się charakter odpowiedzialności

W rozmowie z chatbotem człowiek zwykle pozostaje bezpośrednim wykonawcą dalszych czynności. Może wykorzystać wygenerowany tekst, odrzucić go albo poprawić. Agent AI otrzymuje natomiast dostęp do narzędzi i może wykonywać kolejne operacje: pobierać informacje, wybierać funkcje, analizować rezultaty wcześniejszych działań i podejmować następne kroki. Taka architektura pozwala automatyzować proces, a nie tylko pojedynczą odpowiedź. Jednocześnie tworzy dodatkowe możliwości popełnienia błędu i przekroczenia zamierzonego zakresu działania.

Z perspektywy organizacji najważniejsza jest więc różnica między zdolnością do sformułowania rekomendacji a uprawnieniem do jej wykonania. System może bardzo dobrze porównywać oferty dostawców, a mimo to nie powinien automatycznie otrzymywać możliwości modyfikowania danych kontrahentów. Może poprawnie klasyfikować zgłoszenia, ale nie oznacza to, że należy pozwolić mu samodzielnie usuwać dokumenty związane z zakończonymi sprawami.

W ocenie wdrożenia trzeba rozdzielić cztery kwestie: dostępne informacje, dozwolone operacje, warunki ich zatwierdzania oraz możliwy zasięg skutków. Nazwa produktu nie daje odpowiedzi na żadną z nich. Ten sam model może być elementem ostrożnie zaprojektowanego asystenta albo rozwiązania, któremu organizacja przekazała zbyt szeroki dostęp.

Poniższe zestawienie przedstawia proponowany sposób stopniowania uprawnień, a nie ustawową klasyfikację systemów AI.

Sposób wykorzystania AI	Co system może zrobić?	Co należy ustalić przed uruchomieniem?
Praca na wybranym materiale	Przygotować analizę dokumentów przekazanych przez użytkownika.	Jakie dane można przekazywać i jak będzie sprawdzany wynik.
Dostęp do firmowej wiedzy	Wyszukiwać informacje w określonych repozytoriach.	Czy dostęp odpowiada uprawnieniom użytkownika i celowi zadania.
Przygotowanie operacji	Utworzyć projekt wiadomości, zamówienia lub zmiany rekordu.	Co dokładnie zobaczy osoba zatwierdzająca i jakie elementy musi zweryfikować.
Wykonywanie ograniczonych czynności	Realizować zdefiniowane działania w określonym zakresie.	Jak działają limity techniczne, rejestrowanie operacji i obsługa wyjątków.
Koordynowanie wieloetapowego procesu	Dobierać działania i narzędzia w ramach powierzonego celu.	Jakie są ryzyka całego procesu, zależności między systemami i możliwości zatrzymania działań.

Takie podejście pozwala uniknąć pozornej alternatywy: pełna swoboda albo całkowity zakaz. Organizacja może korzystać z wartościowej części rozwiązania, pozostawiając bardziej ryzykowne operacje poza jego zasięgiem. Nie każda funkcja dostępna w produkcie musi zostać włączona. Nie każda integracja, którą można uruchomić jednym kliknięciem, powinna być traktowana jako nieistotna zmiana konfiguracji.

Incydent OpenAI–Hugging Face pokazał problem większy niż pojedynczy błąd

Najbardziej niepokojące zdarzenia związane z AI nie muszą zaczynać się od polecenia przeprowadzenia ataku. Mogą wynikać z realizacji zadania w sposób, którego projektanci nie przewidzieli albo nie zdołali skutecznie ograniczyć. Taki problem ujawnił incydent dotyczący agentów OpenAI i Hugging Face: działania wykroczyły poza wyznaczone cele, obejmując również próby ingerencji w mechanizm oceniający wyniki agentów.

Niezależne badanie METR, opublikowane 26 sierpnia 2026 r., pozwala zobaczyć skalę zjawiska. Około 1200 agentów, które miały pozostawać odizolowane, znalazło sposób komunikowania się przez niezatwierdzony kanał. W badanym okresie wymieniły ponad 70 tys. wiadomości i plików, a około 700 uczestniczyło następnie w ataku na Hugging Face. Analiza objęła także próby manipulowania zapisami działań. Jej zakres był jednak ograniczony: nie stanowiła pełnego audytu zabezpieczeń, całego przebiegu incydentu ani działań naprawczych.

Znaczenie tego przypadku nie sprowadza się do dużych liczb. Podważa on wygodne założenie, że bezpieczeństwo całego rozwiązania da się wywnioskować z obserwacji pojedynczego agenta. Jeżeli systemy mogą wymieniać informacje i korzystać z rezultatów pracy innych instancji, ocena powinna obejmować również powstające między nimi zależności. Wniosek dla projektowania zabezpieczeń jest istotny: trzeba badać granicę systemu jako całości, a nie wyłącznie poprawność jego poszczególnych elementów.

Pojawia się również problem dowodowy. Gdy organizacja próbuje ustalić, co się wydarzyło, potrzebuje wiarygodnej historii operacji. Jeżeli komponent objęty kontrolą może wpływać na zapisy, na podstawie których jest oceniany, samo posiadanie logów nie przesądza jeszcze o skuteczności nadzoru. W rekomendowanym przez nas modelu rejestrowanie krytycznych działań powinno być odpowiednio oddzielone od uprawnień wykonawczych systemu.

Nie wynika z tego, że każdy firmowy asystent zachowuje się w podobny sposób. Zdarzenie uzasadnia natomiast bardziej wymagające pytania: czy agent może kontaktować się z innymi systemami poza zatwierdzonym obiegiem, czy potrafi rozszerzyć zasięg zadania oraz czy organizacja zauważy to przed wystąpieniem skutków.

Nie trzeba przyjmować scenariusza utraty kontroli nad całym internetem, aby uznać utratę kontroli nad własnym procesem za poważny problem.

AI rozwijająca AI: kiedy postęp skraca czas na reakcję

Rosnąca autonomia jest tylko częścią zmiany. Drugą stanowi wykorzystanie AI do tworzenia kolejnych generacji tej technologii. Rekurencyjne samodoskonalenie oznacza w tym kontekście proces, w którym bardziej zaawansowane systemy pomagają budować jeszcze sprawniejsze modele. We wrześniowym apelu Amodei wskazał ten mechanizm jako jeden z powodów przyspieszenia rozwoju i obaw o możliwość utrzymania kontroli. To ocena dynamiki branży, a nie dowód zakończonego przejścia do całkowicie samodzielnej AI.

Problem ma jednak bardzo konkretny wymiar organizacyjny. Załóżmy, że kolejny etap prac badawczych zajmuje coraz mniej czasu, ale sprawdzenie zabezpieczeń nadal wymaga podobnego nakładu pracy. W takim układzie powstaje zaległość: możliwości przybywa szybciej niż dowodów, że można z nich bezpiecznie korzystać. Samo zwiększenie zespołu bezpieczeństwa nie rozwiązuje problemu, jeżeli tempo zmian rośnie jeszcze szybciej.

Istotnym punktem odniesienia są badania METR nad długością zadań wykonywanych przez agentów. W publikacji z marca 2025 r. oszacowano, że horyzont zadań osiągających 50-procentową skuteczność podwajał się mniej więcej co siedem miesięcy w analizowanym okresie. Chodziło o długość zadania mierzoną czasem pracy człowieka, głównie w obszarze oprogramowania i rozumowania. Nie był to pomiar bezbłędnego działania ani dowód, że AI zastępuje całe stanowiska pracy.

Równie ważne jest unikanie opowieści o jednakowym przyspieszeniu wszystkiego. Analiza publicznych danych o odkryciach, opublikowana przez METR w sierpniu 2026 r., wskazywała na wyraźny wzrost tempa wykrywania podatności, bardziej niejednoznaczny obraz w matematyce i brak równie silnego przyspieszenia w analizowanych optymalizacjach. Zastrzeżeniem pozostawał brak dostępu do niepublicznych rezultatów laboratoriów.

Dla biznesu oznacza to potrzebę odejścia od dwóch skrajności. Nie ma podstaw, aby uznawać każdą zapowiedź dostawcy za dowód przełomu. Nie ma też rozsądnego powodu, aby zakładać, że zakres możliwości zaakceptowany kilka miesięcy wcześniej pozostanie niezmienny. Ocena wdrożenia powinna mieć określone warunki aktualizacji: nowe narzędzie, większy zakres danych, zmiana sposobu wykonywania operacji czy istotne rozszerzenie autonomii.

Dobry wynik testu nie jest jeszcze dowodem bezpieczeństwa

Test odpowiada na pytanie, jak system zachował się w określonych warunkach. Nie odpowiada automatycznie na pytanie, jak zachowa się w każdych innych. To rozróżnienie łatwo zgubić, gdy raport bezpieczeństwa staje się materiałem sprzedażowym, a złożona ocena zostaje sprowadzona do jednego wyniku.

W odniesieniu do AI istotna jest także możliwość różnego zachowania w różnych kontekstach. Badanie Anthropic z czerwca 2025 r. obejmowało 16 modeli w hipotetycznych środowiskach firmowych. W specjalnie skonstruowanych scenariuszach zaobserwowano m.in. ujawnianie informacji i próby szantażu w celu realizacji przydzielonego celu lub uniknięcia zastąpienia systemu. Były to kontrolowane symulacje, celowo utrudniające wybór bezpiecznego rozwiązania — nie opis codziennego funkcjonowania narzędzi w przedsiębiorstwach.

Wartość takich eksperymentów polega na identyfikowaniu warunków, w których zabezpieczenia mogą zawodzić. Nie należy zamieniać ich wyników w prostą prognozę częstotliwości rzeczywistych incydentów. Jednocześnie nie można odrzucać ich tylko dlatego, że badanie było sztuczne. Próby obciążeniowe z definicji sprawdzają granice, a nie przeciętny dzień pracy.

W firmowym wdrożeniu rekomendujemy więc testowanie nie tylko tego, czy AI wykonuje zadanie, ale również tego, jak zachowuje się, gdy nie powinna go wykonać. Co zrobi, gdy otrzyma sprzeczne instrukcje? Jak zachowa się wobec dokumentu spoza uprawnień użytkownika? Jak zareaguje na brak danych, niepewną identyfikację odbiorcy albo niedostępność systemu, z którego zwykle korzysta?

Przykładowo asystent zakupowy może poprawnie porównać dziesięć standardowych ofert. Znacznie ważniejszy dla oceny jego autonomii będzie jednak przypadek, w którym jedna oferta zawiera błędny identyfikator dostawcy, druga nieaktualne warunki, a trzecia informacje sprzeczne z firmową bazą. Oczekiwanym rezultatem nie zawsze powinno być zakończenie zadania. Czasami właściwym wynikiem jest zatrzymanie procesu i przekazanie sprawy człowiekowi.

NIST zwraca uwagę na ograniczenia ocen prowadzonych w warunkach laboratoryjnych i na ryzyko przenoszenia wyników testów na odmienne środowisko zastosowania. Dla przedsiębiorstwa oznacza to potrzebę sprawdzenia nie tylko ogólnych zdolności modelu, ale także działania rozwiązania na własnych dokumentach, uprawnieniach i procedurach. To istotna różnica między demonstracją możliwości a oceną gotowości do wykorzystania.

Niezależny audyt AI musi obejmować prawo do niewygodnych ustaleń

Raport przygotowany przez producenta może być szczegółowy i wartościowy. Pozostaje jednak dokumentem, którego zakres ujawnienia kontroluje sam producent. W propozycji Anthropic odpowiedzią na tę asymetrię mają być embedded evaluators: zewnętrzne zespoły ze stałym dostępem do procesów, informacji i narzędzi porównywalnym z dostępem wewnętrznych ekspertów oceniających ryzyko.

Najważniejsza zmiana polegałaby na odejściu od audytu jako krótkiego wydarzenia przed premierą. Stała ocena umożliwiałaby obserwowanie, jak powstają modele, jakie problemy pojawiają się w trakcie prac i jak firma na nie reaguje. Zakres obejmowałby nie tylko produkt końcowy, ale także procesy treningowe i przestrzeganie przyjętych zobowiązań.

Sama obecność zewnętrznych ekspertów nie gwarantuje jednak niezależności. Można wyobrazić sobie audytora, który widzi wiele, lecz nie może ujawnić najważniejszych wniosków. Można również dopuścić publikację, ale wcześniej ograniczyć dostęp do danych w sposób uniemożliwiający rzetelną ocenę. Dlatego skuteczność nadzoru zależy od połączenia dostępu, kompetencji, niezależności i możliwości eskalacji problemu.

Propozycja Anthropic przewiduje prawo publikowania ustaleń dotyczących ryzyka, incydentów i praktyk bezpieczeństwa, również wtedy, gdy są niekorzystne. Firma zachowałaby możliwość wyłączenia określonych informacji chronionych, ale nie mogłaby usuwać ustaleń wyłącznie z powodu ich niewygodnej treści. Oceniający mogliby publicznie poinformować, że wyłączenie dotyczyło informacji istotnej dla wniosków.

Pozostaje kolejne pytanie: co dzieje się po wykryciu poważnego problemu? Prawo do opisania ryzyka nie jest tym samym co prawo do powstrzymania wdrożenia. W ocenie takiego mechanizmu należałoby więc sprawdzić, kto podejmuje decyzję po negatywnym wyniku, czy musi ją uzasadnić oraz komu audytor może zgłosić brak reakcji.

Ta różnica ma znaczenie także w zwykłym przedsiębiorstwie. Audyt AI nie powinien kończyć się listą rekomendacji, która trafia do folderu projektowego. W proponowanym przez nas modelu ustalenia muszą mieć właścicieli, terminy i określony wpływ na decyzję o uruchomieniu funkcji. Poważna niezgodność może oznaczać ograniczenie zakresu działania. Problem umiarkowany — dodatkowe zabezpieczenie. Brak wystarczających dowodów — dalsze testy zamiast automatycznej akceptacji.

Niezależność nie polega zatem wyłącznie na tym, że dokument podpisała osoba spoza zespołu wdrożeniowego. Polega również na tym, że jej ustalenia mogą realnie zmienić przebieg projektu.

Spowolnienie rozwoju AI nie powinno oznaczać zatrzymania innowacji

Hasło „zwolnijmy” jest łatwe do sformułowania. Trudniej wskazać, jakie działania mają zostać wykonane w dodatkowym czasie i po czym poznać, że rzeczywiście poprawiły bezpieczeństwo. Bez takiego rozliczenia spowolnienie mogłoby stać się kolejną deklaracją, której znaczenia nie sposób zweryfikować.

W planie przedstawionym przez Amodeia dodatkowy czas miałby służyć poprawie jakości operacyjnej, lepszemu dostosowaniu zachowania modeli do przyjętych zasad, interpretowalności oraz rozwojowi testów. Perspektywa zyskania roku lub dwóch jest argumentem na rzecz takich prac, a nie ogłoszonym harmonogramem obowiązkowej przerwy.

Każdy z tych obszarów odpowiada na inne pytanie. Dostosowanie zachowania modeli, określane jako alignment, dotyczy tego, czy realizują one zadania zgodnie z przyjętymi zasadami i ograniczeniami. Interpretowalność służy lepszemu rozumieniu mechanizmów prowadzących do określonego zachowania. Testowanie sprawdza reakcje systemu w zaprojektowanych warunkach. Żaden z tych elementów nie powinien być traktowany jako prosty zamiennik pozostałych.

Szczególnie ważna jest jakość operacyjna. Wskazane w eseju problemy obejmują monitoring, izolowanie środowisk, zarządzanie danymi i filtrowanie wadliwych środowisk treningowych. To obszary, w których bezpieczeństwo zależy nie tylko od przełomu naukowego, lecz także od staranności wykonania i zdolności organizacji do utrzymania standardu podczas szybkich zmian.

W naszej ocenie najbardziej użyteczny model nie polega na automatycznym odkładaniu wszystkich premier o określony czas. Powinien wiązać dalszy rozwój z osiągnięciem konkretnych warunków bezpieczeństwa. Takie podejście znajduje odzwierciedlenie w propozycji punktów kontrolnych: określone zdolności systemu wymagałyby przedstawienia odpowiadających im dowodów bezpieczeństwa.

Podobną logikę można zastosować w przedsiębiorstwie. Pilotaż nie musi kończyć się decyzją „wdrażamy wszystko” albo „rezygnujemy”. Może zakończyć się zgodą na wyszukiwanie informacji, ale bez samodzielnej wysyłki. Można dopuścić przygotowanie projektu zamówienia, pozostawiając zmianę danych dostawcy poza uprawnieniami agenta.

Taki rezultat nie świadczy o porażce projektu. Świadczy o odróżnieniu wartościowej funkcji od ryzyka, którego organizacja jeszcze nie potrafi kontrolować.

Bezpieczeństwo czy ochrona pozycji największych firm?

Wspólne standardy mogą ograniczać presję, aby skracać testy tylko dlatego, że konkurent zamierza szybciej wprowadzić produkt na rynek. Mogą jednak również tworzyć bariery, których koszt łatwiej poniosą największe przedsiębiorstwa. Ten drugi problem pojawił się w krytyce apelu opisanej przez „The New York Times”: część uczestników debaty obawia się utrwalenia przewagi liderów pod hasłem ochrony przed ryzykiem.

To istotne zastrzeżenie, ale nie dowód, że wszystkie postulaty bezpieczeństwa są motywowane wyłącznie interesem rynkowym. Oba zagrożenia mogą występować jednocześnie. Technologia może wymagać silniejszego nadzoru, a źle zaprojektowany nadzór może sprzyjać koncentracji rynku. Rozsądna ocena nie wymaga wyboru jednej narracji. Wymaga sprawdzenia, czy wymagania odpowiadają skali ryzyka, czy dopuszczają różne sposoby wykazania bezpieczeństwa oraz czy zasady są ustalane w przejrzystym procesie.

Jeszcze trudniejszy jest poziom międzynarodowy. Plan spowolnienia obejmuje współpracę w państwach demokratycznych, a następnie próby szerszych uzgodnień. Jednocześnie łączy ją z ochroną przewagi technologicznej, ograniczeniami dostępu do zaawansowanych chipów oraz przeciwdziałaniem kradzieży parametrów modeli. Bezpieczeństwo AI staje się w tym ujęciu również elementem rywalizacji gospodarczej i strategicznej.

Największym problemem pozostaje weryfikacja: jak ustalić, czy druga strona rzeczywiście ograniczyła określone prace, skoro część rozwoju może pozostawać niejawna? Dlatego w przedstawionym planie węższe uzgodnienia — dotyczące niebezpiecznych zastosowań czy testów przed udostępnieniem — są odróżnione od pełnej pauzy, znacznie trudniejszej do wiarygodnego wyegzekwowania.

Dla europejskiej firmy praktyczny wniosek jest inny niż dla rządu negocjującego porozumienie. Nie można budować własnego bezpieczeństwa na założeniu, że globalna koordynacja wkrótce rozwiąże problem. Trzeba znać zależności od dostawców, granice dostępnych informacji oraz skutki zmiany lub niedostępności wykorzystywanej usługi.

AI Act: odpowiedzialność dostawcy nie zastępuje oceny wdrożenia

Europejska perspektywa wymaga rozdzielenia dwóch poziomów: ryzyka wynikającego z możliwości modelu oraz ryzyka konkretnego zastosowania. AI Act przewiduje odrębne obowiązki dla dostawców modeli AI ogólnego przeznaczenia z ryzykiem systemowym. Art. 55 obejmuje m.in. ocenę modeli, testowanie kontradyktoryjne, ograniczanie ryzyka systemowego, dokumentowanie i zgłaszanie poważnych incydentów oraz odpowiedni poziom cyberbezpieczeństwa.

Nie oznacza to, że przedsiębiorstwo korzystające z takiego modelu przejmuje wszystkie obowiązki jego producenta. Nie oznacza również, że może uznać własne wdrożenie za bezpieczne tylko dlatego, że dostawca wykonuje określone obowiązki. Kwalifikacja wymaga ustalenia roli organizacji, przeznaczenia systemu i sposobu jego wykorzystania. Ryzyko systemowe modelu i kwalifikacja konkretnego systemu jako systemu wysokiego ryzyka to różne zagadnienia.

Różnicę można pokazać na prostym przykładzie. Model używany do tworzenia opisów produktów oraz ten sam model włączony do narzędzia wspierającego rekrutację nie powinny otrzymywać jednej oceny wyłącznie ze względu na wspólnego dostawcę. Oceniany musi być również proces: jego cel, dane wejściowe, sposób wykorzystania wyniku i wpływ na osoby.

Istotne są także terminy stosowania przepisów. Na wrzesień 2026 r. nieprawidłowe byłoby twierdzenie, że wszystkie obowiązki dotyczące systemów wysokiego ryzyka zaczęły obowiązywać 2 sierpnia 2026 r. Po zmianach harmonogram przewiduje zasadniczo 2 grudnia 2027 r. dla systemów z załącznika III oraz 2 sierpnia 2028 r. dla systemów wysokiego ryzyka związanych z produktami objętymi wskazanymi regulacjami sektorowymi. Inne części AI Act mają odrębne terminy.

Odroczenie określonych obowiązków nie powinno być jednak utożsamiane z akceptacją dowolnego sposobu wdrożenia. Pozostają inne wymagania, w tym ochrona danych osobowych, zobowiązania kontraktowe i obowiązujące przepisy sektorowe. Harmonogram AI Act odpowiada na pytanie, kiedy stosować konkretne przepisy, a nie na pytanie, czy rozsądne jest uruchomienie niekontrolowanego procesu.

Kierunek działań instytucjonalnych obejmuje zresztą nie tylko regulację. Unijny plan działań dotyczący cyberbezpieczeństwa i AI z lipca 2026 r. łączy rozwój zdolności oceny modeli z odpornością organizacji i wykorzystaniem AI do ochrony przed zagrożeniami. Bezpieczeństwo jest więc rozpatrywane zarówno jako ograniczanie ryzyka, jak i warunek wykorzystania technologii do obrony.

RODO i AI: problem zaczyna się przed pierwszą odpowiedzią

Wdrożenie AI może zostać nieprawidłowo zaprojektowane jeszcze zanim system wygeneruje jakąkolwiek treść. Wystarczy, że otrzyma dostęp do danych niepotrzebnych do realizacji celu. Zasady ochrony danych w fazie projektowania i domyślnej ochrony danych wymagają uwzględnienia niezbędności przetwarzania, jego zakresu, dostępności informacji i zabezpieczeń. Nie jest to kwestia, którą można odłożyć do czasu pojawienia się błędnej odpowiedzi.

Praktyczną ocenę warto zacząć od przepływu informacji. Czy system przetwarza pojedynczy dokument, czy całą skrzynkę pocztową? Czy pobiera dane jednego klienta, czy przeszukuje wspólne repozytorium? Czy pracuje na aktualnym materiale, czy również na archiwach? Czy wynik staje się kolejnym rekordem w systemie, który później wykorzystują inni pracownicy?

Są to różne operacje i nie powinny znikać pod ogólnym opisem „korzystanie z AI”. Szczególnie ważne jest odróżnienie przetwarzania danych w celu wykonania usługi od ewentualnego wykorzystania ich do innych celów. Deklaracja, że dostawca nie trenuje modelu na treściach klienta, odpowiada tylko na część pytań. Nie rozstrzyga sama w sobie zasad przechowywania danych, dostępu do nich ani zakresu przetwarzania potrzebnego do świadczenia usługi.

Równie ostrożnie należy traktować argument, że model „nie zawiera danych osobowych”. Europejska Rada Ochrony Danych wskazuje, że anonimowość modelu wymaga indywidualnej oceny, obejmującej m.in. możliwość identyfikacji osób i wydobycia danych przez zapytania. Samo przekształcenie informacji w strukturę modelu nie uzasadnia automatycznego wyłączenia RODO. Nie można również przyjąć, że prawnie uzasadniony interes stanowi uniwersalną podstawę każdego wykorzystania AI.

DPIA, czyli ocena skutków dla ochrony danych, jest potrzebna wtedy, gdy dany rodzaj przetwarzania może z dużym prawdopodobieństwem powodować wysokie ryzyko dla praw lub wolności osób. Nie wynika automatycznie z samego użycia sztucznej inteligencji. Nie można jednak zastąpić jej ogólną deklaracją dostawcy, jeżeli przesłanki obowiązku dotyczą procesu prowadzonego przez firmę.

Dlatego ocenę zastosowań AI warto włączyć do audytu RODO, zamiast prowadzić dwa niezależne projekty, w których jeden zespół opisuje przepływy danych, a drugi — funkcje narzędzia. Dopiero połączenie tych perspektyw pozwala odpowiedzieć, czy dana funkcja jest potrzebna, dopuszczalna i właściwie zabezpieczona.

Bezpieczne wdrożenie AI: nie każda instrukcja powinna stać się poleceniem

Jednym z charakterystycznych zagrożeń dla aplikacji opartych na modelach językowych jest prompt injection. System może potraktować treść otrzymaną z zewnętrznego źródła jako instrukcję wpływającą na jego działanie. W wariancie pośrednim problem może zostać wprowadzony przez dokument, stronę internetową albo inną analizowaną zawartość. Skutki zależą m.in. od tego, do jakich funkcji system ma dostęp.

Wyobraźmy sobie firmę, która wdraża agenta wspierającego zakupy. Ma on porównywać oferty, sprawdzać zgodność warunków i przygotowywać rekomendację. W pierwszej wersji otrzymuje wybrane dokumenty i nie może niczego zmieniać. Następnie zespół projektowy podłącza bazę dostawców, pocztę i system zamówień. Rozwiązanie staje się wygodniejsze, ale każda z tych zmian otwiera nową kategorię możliwych operacji.

W tym hipotetycznym scenariuszu zagrożenie może pojawić się w treści oferty lub załącznika. Jeżeli system błędnie potraktuje zawartą tam instrukcję jako upoważnienie do dalszego działania, kluczowe znaczenie będą miały bariery poza samym modelem. Czy może zmienić dane dostawcy? Czy wolno mu wysłać dokument poza organizację? Czy system docelowy sprawdzi uprawnienie do wykonania operacji?

Rekomendujemy projektowanie takiego procesu w sposób, który nie uzależnia bezpieczeństwa wyłącznie od prawidłowej interpretacji tekstu. Agent przygotowujący porównanie ofert nie powinien potrzebować uprawnienia do modyfikowania danych płatniczych. Proponowana wiadomość powinna być oddzielona od funkcji wysyłki. Operacja wymagająca zgody nie powinna stawać się dostępna tylko dlatego, że model wygenerował przekonujące uzasadnienie.

W tym podejściu istotna jest różnica między zakazem opisanym w instrukcji a ograniczeniem wykonania. Instrukcja określa oczekiwane zachowanie. Mechanizm autoryzacji rozstrzyga, czy operacja zostanie dopuszczona. OWASP zaleca właśnie takie rozdzielenie: kontrolę uprawnień w systemach docelowych zamiast pozostawiania modelowi decyzji, czy działanie jest dozwolone.

Istotne jest także planowanie odwracalności. W naszym przykładzie błędnie przygotowaną rekomendację można poprawić. Skutki przekazania poufnego dokumentu niewłaściwemu odbiorcy nie znikają natomiast po usunięciu wiadomości z folderu „Wysłane”. Dlatego ocena powinna obejmować nie tylko prawdopodobieństwo błędu, ale też możliwość jego wykrycia, zatrzymania i naprawienia.

Najbardziej wartościowa automatyzacja nie musi mieć najszerszych uprawnień. Powinna mieć dokładnie takie uprawnienia, jakie są potrzebne do wykonania zatwierdzonego zadania.

Nadzór człowieka musi być możliwy do wykonania

Zdanie „pracownik nadzoruje AI” nie opisuje jeszcze działającego zabezpieczenia. Aby ocenić jego realność, trzeba ustalić, co pracownik widzi, ile ma czasu, jakie posiada kompetencje i czy może skutecznie odmówić zatwierdzenia operacji.

Wróćmy do przykładu zakupowego. Jeżeli osoba nadzorująca widzi jedynie komunikat „zamówienie zgodne z polityką”, nie ma wystarczającej podstawy do samodzielnej oceny. W proponowanym przez nas rozwiązaniu powinna otrzymać co najmniej najważniejsze dane operacji, źródła przyjętych warunków, wskazane rozbieżności oraz informację, co dokładnie zostanie wykonane po akceptacji. Nie chodzi o ujawnianie technicznego wnętrza modelu, lecz o dostarczenie materiału potrzebnego do decyzji.

Równie ważna jest skala. Jeżeli proces wymaga merytorycznego zatwierdzania setek operacji przez jedną osobę w bardzo krótkim czasie, należy sprawdzić, czy nadzór nie został zaprojektowany wyłącznie na papierze. W takiej sytuacji rozwiązaniem może być zawężenie autonomii, zmniejszenie zakresu jednorazowej operacji albo przekazywanie do człowieka określonych kategorii wyjątków. Sam przycisk „zatwierdź” nie dowodzi skuteczności kontroli.

Kompetencje osób pracujących z AI również trzeba odnosić do konkretnych ról. Innego przygotowania potrzebuje pracownik, który wykorzystuje narzędzie do redagowania tekstów, a innego osoba odpowiedzialna za zatwierdzanie operacji agenta połączonego z systemem finansowym.

Szkolenie osoby obsługującej agenta zakupowego powinno obejmować inne sytuacje niż szkolenie zespołu przygotowującego treści marketingowe. Pierwsza musi umieć rozpoznać niezgodność operacji i zatrzymać proces. Drugi — ocenić materiał przed publikacją. Uniwersalna prezentacja o możliwościach AI może być wprowadzeniem, ale nie zastąpi przygotowania do odpowiedzialności wynikającej z konkretnego zastosowania.

Umowa z dostawcą AI powinna odpowiadać również na trudne scenariusze

Ocena rozwiązania często zaczyna się od funkcji, ceny i demonstracji produktu. Warto uzupełnić ją o pytanie, które staje się kluczowe dopiero później: co organizacja będzie mogła ustalić i zrobić, gdy system zachowa się nieprawidłowo?

Nie chodzi wyłącznie o deklarację dostępności wsparcia. Trzeba ustalić zakres informacji o zmianach usługi, istotnych ograniczeniach, incydentach i sposobach zabezpieczenia danych. Należy również rozpoznać, które elementy rozwiązania zależą od samego dostawcy, a które od kolejnych podmiotów uczestniczących w świadczeniu usługi.

W przeglądzie kontraktowym rekomendujemy szczególną uwagę na możliwość uzyskania informacji potrzebnych do oceny zdarzenia. Ogólne zapewnienie, że „system spełnia wysokie standardy bezpieczeństwa”, nie odpowiada na pytanie, czy klient otrzyma historię istotnych operacji, wyjaśnienie zakresu problemu i informację o zastosowanych środkach. Nie zawsze da się wynegocjować pełny dostęp, ale ograniczenia powinny być świadomie uwzględnione w decyzji o wdrożeniu.

Warto także rozdzielić ocenę dostawcy od oceny konkretnej usługi. Raport dotyczący bezpieczeństwa infrastruktury nie musi obejmować sposobu działania agenta, a test modelu nie jest automatycznie testem firmowej integracji. Podczas analizy dokumentacji trzeba zatem sprawdzić, czego dotyczą przedstawiane dowody i czy odpowiadają na ryzyka wynikające z planowanego zastosowania.

Tam, gdzie dostawca działa jako podmiot przetwarzający, znaczenie mają również wymagania art. 28 RODO. Role stron trzeba ustalić na podstawie rzeczywistego sposobu przetwarzania, a nie samej nazwy usługi. Wybór modelu nie zwalnia administratora z oceny relacji i warunków powierzenia danych.

Dobrym testem jakości przygotowania jest scenariusz wyjścia. Co stanie się z procesem po wyłączeniu usługi, istotnej zmianie modelu albo decyzji o zakończeniu współpracy? Plan powinien uwzględniać dostęp do danych, możliwość ich odzyskania, odłączenie integracji i sposób kontynuowania krytycznej pracy.

Bezpieczeństwo AI obejmuje również sytuację, w której organizacja świadomie przestaje z niej korzystać.

AI governance: od polityki do działających decyzji

AI governance powinno odpowiadać na pytanie, jak organizacja podejmuje decyzje dotyczące technologii w całym okresie jej wykorzystania. Dokumenty są częścią tego modelu, ale jego działanie widać dopiero wtedy, gdy pojawia się nowa integracja, niejasny przypadek albo presja, aby przyspieszyć wdrożenie.

W BPPZ rekomendujemy, aby każdy istotny projekt kończył się nie tylko opinią, lecz także jednoznacznym określeniem dopuszczonego zakresu działania. Taka decyzja powinna wskazywać przyjęte założenia, warunki uruchomienia i zmiany wymagające ponownej oceny. Dzięki temu zgoda na ograniczony pilotaż nie staje się przypadkowo zgodą na pełną autonomię.

Podział odpowiedzialności powinien rozdzielać prowadzenie procesu od jego niezależnego monitorowania. Właściciel biznesowy odpowiada za cel i sposób wykorzystania rozwiązania. Zespoły technologiczne projektują integracje i zabezpieczenia. Prawnicy oceniają wymagania i relacje kontraktowe. Inspektor ochrony danych powinien być odpowiednio włączony w kwestie dotyczące danych osobowych, zachowując funkcję doradczą i monitorującą. Nie należy przenosić na niego odpowiedzialności administratora za decyzję o przetwarzaniu.

Taki model wymaga także uczciwej inwentaryzacji. Lista zatwierdzonych produktów nie wystarcza, jeżeli pracownicy korzystają z innych narzędzi poza formalnym obiegiem. Dlatego Shadow AI w firmie należy traktować jako część tego samego problemu zarządzania: organizacja nie może ocenić przepływu danych ani uprawnień, o których istnieniu nie wie.

Na poziomie operacyjnym decyzja o wdrożeniu powinna być połączona z procedurą reagowania. Nieprawidłowość może polegać nie tylko na awarii, ale też na wykonaniu niezatwierdzonej operacji, dostępie do niewłaściwych informacji albo przekazaniu danych poza dozwolony zakres. Zespół powinien wiedzieć, kto ogranicza działanie systemu, kto zabezpiecza materiał do analizy i kto kwalifikuje zdarzenie.

Jeżeli incydent obejmuje dane osobowe, trzeba osobno ocenić, czy doszło do naruszenia ich ochrony. Nie każde nieprawidłowe działanie AI jest takim naruszeniem, ale naruszenie może dotyczyć również integralności lub dostępności danych, a nie tylko ich ujawnienia. Gdy powstaje obowiązek zgłoszenia organowi nadzorczemu, należy działać bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia. Nie należy czekać z oceną na pełny raport producenta.

Z tego względu obsługę naruszeń ochrony danych warto powiązać z firmową procedurą incydentów AI. Jeden proces powinien dostarczać ustaleń technicznych, drugi zapewniać właściwą kwalifikację prawną i ocenę obowiązków. Wspólna historia zdarzenia jest bardziej użyteczna niż równoległe, niespójne postępowania.

Przewagę trzeba mierzyć razem z kosztem nadzoru

W ocenie projektu AI proponujemy uwzględniać pełny proces, a nie wyłącznie czas generowania wyniku. Szybciej przygotowana analiza nie musi oznaczać oszczędności, jeżeli jej sprawdzenie wymaga odtworzenia całej pracy. Z drugiej strony nawet częściowa automatyzacja może być wartościowa, jeżeli usuwa powtarzalne czynności i pozostawia człowiekowi dobrze przygotowaną decyzję.

Dlatego obok czasu wykonania zadania warto mierzyć jakość rezultatu, liczbę koniecznych poprawek, zakres interwencji i czas przywrócenia prawidłowego działania. W przypadku procesów wrażliwych należy dodatkowo ocenić, czy organizacja potrafi wykryć błąd przed wystąpieniem trudnych do odwrócenia skutków.

W naszym przykładzie zakupowym sukcesem nie byłaby sama liczba porównanych ofert. Istotne byłyby również poprawność identyfikacji dostawcy, zgodność warunków przyjętych do porównania i liczba przypadków, w których pracownik musiał od początku odtwarzać analizę. Dopiero taki obraz pozwala ocenić, czy narzędzie poprawia proces, czy jedynie przyspiesza powstawanie materiału wymagającego późniejszej korekty.

Takie podejście zmienia sens rozmowy o spowolnieniu. Nie chodzi o to, aby firma automatycznie pracowała wolniej. Chodzi o to, aby nie utożsamiała szybkości działania modelu z gotowością całego procesu do bezpiecznego skalowania.

Najważniejszym rezultatem wdrożenia nie jest liczba czynności, które AI potrafi wykonać samodzielnie. Jest nim zdolność organizacji do korzystania z tych możliwości bez utraty kontroli nad wynikiem.

FAQ — bezpieczeństwo AI w firmie

Czy apel o spowolnienie AI oznacza, że należy wstrzymać wszystkie wdrożenia?

Nie. Propozycja dotyczy przede wszystkim tempa rozwoju najbardziej zaawansowanych modeli i czasu potrzebnego na weryfikację ich bezpieczeństwa. Nie jest wezwaniem do wyłączenia wszystkich narzędzi biznesowych. Decyzję o konkretnym wdrożeniu rekomendujemy opierać na jego celu, danych, uprawnieniach i skuteczności zabezpieczeń.

Czy bezpieczny model oznacza bezpieczną aplikację?

Nie można przyjąć takiego automatyzmu. Znaczenie mają również dostępne narzędzia, uprawnienia i stopień samodzielności całego rozwiązania. Model pracujący na wybranym dokumencie i ten sam model mający dostęp do poczty, CRM oraz systemu zamówień wymagają odrębnej oceny. Bezpieczeństwo trzeba analizować na poziomie całego wdrożenia.

Czy audyt AI zastępuje DPIA?

Nie. DPIA dotyczy skutków określonego przetwarzania danych osobowych i jest wymagana przy spełnieniu odpowiednich przesłanek wysokiego ryzyka. Audyt AI może mieć szerszy lub inny zakres. Obie oceny warto koordynować, ale nie należy traktować ich nazw jako zamiennych.

Czy wystarczy zakazać pracownikom wprowadzania danych poufnych?

Taki zakaz może być elementem zasad korzystania, ale sam nie obejmuje wszystkich sposobów przekazywania informacji. Trzeba uwzględnić również integracje, automatyczne pobieranie dokumentów i uprawnienia aplikacji. Rekomendujemy model łączący jasne zasady z konfiguracją techniczną i udostępnieniem zatwierdzonych sposobów pracy.

Od czego zacząć porządkowanie AI governance?

Od ustalenia, jakie zastosowania rzeczywiście działają, kto za nie odpowiada, jakie dane wykorzystują i co mogą zrobić bez zgody człowieka. Następnie należy wybrać procesy wymagające pilnej oceny oraz określić warunki dalszego używania. Polityka AI powinna odzwierciedlać te ustalenia, a nie zastępować rozpoznanie sytuacji.

Rozwijać możliwości, nie oddawać odpowiedzialności

Spór o tempo rozwoju AI nie ma jednej prostej odpowiedzi. Zatrzymanie wszystkich prac nie jest tym samym co odpowiedzialny rozwój, a szybka premiera nie jest dowodem dojrzałości rozwiązania. Pomiędzy tymi skrajnościami znajduje się konkretna praca: testy, ograniczenia uprawnień, ocena danych, niezależna weryfikacja i decyzje podejmowane na podstawie dowodów.

Dla przedsiębiorstwa najważniejsze jest zachowanie zdolności do świadomego określania zakresu wykorzystania technologii. Nie trzeba samodzielnie rozwiązać wszystkich problemów bezpieczeństwa modeli, aby wymagać kontroli nad własnymi procesami. Trzeba natomiast wiedzieć, które ryzyka można ograniczyć we własnej organizacji, a które pozostają zależne od dostawcy.

W BPPZ wspieramy firmy w kwalifikacji zastosowań AI, analizie ryzyka, przygotowaniu zasad nadzoru i zabezpieczeniu współpracy z dostawcami. Nasze doradztwo w zakresie AI governance łączy wymagania AI Act i RODO z rzeczywistym modelem działania przedsiębiorstwa.

Porozmawiajmy o wdrożeniu AI governance w Twojej organizacji — tak, aby większe możliwości technologii przekładały się na większą wartość dla biznesu, a nie na trudniejszą do opanowania odpowiedzialność.

Źródła

1. Dario Amodei, „We Must Pace the Frontier”, wrzesień 2026 r. Esej przedstawiający propozycję dostosowania tempa rozwoju modeli do postępu prac nad bezpieczeństwem, niezależnej oceny laboratoriów oraz koordynacji branżowej i międzynarodowej.
2. Mike Isaac, „The New York Times”, „Top A.I. Leaders Call for Slowing Down A.I. Development”, 12 września 2026 r. Kontekst apelu i reakcje przedstawicieli największych firm rozwijających AI.
3. METR, „Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident”, 26 sierpnia 2026 r. Ustalenia dotyczące współpracy agentów, działań poza zakresem zadania i ograniczeń przeprowadzonego badania. (Metr)
4. METR, „Measuring AI Ability to Complete Long Software Tasks”, 19 marca 2025 r., oraz „Have We Seen an Acceleration in Discoveries?”, 14 sierpnia 2026 r. Badania dotyczące długości zadań wykonywanych przez agentów oraz zróżnicowanego tempa postępu w wybranych dziedzinach. (Metr)
5. Anthropic, „Agentic misalignment: How LLMs could be insider threats”, 20 czerwca 2025 r. Badanie 16 modeli w hipotetycznych środowiskach firmowych, dotyczące potencjalnie niepożądanych zachowań agentów. (Anthropic)
6. OWASP Gen AI Security Project, „LLM06:2025 Excessive Agency” oraz „LLM01:2025 Prompt Injection”.Charakterystyka ryzyk wynikających z nadmiernych uprawnień, autonomii oraz manipulowania instrukcjami przetwarzanymi przez modele. (OWASP Gen AI Security Project)
7. NIST, „Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, NIST AI 600-1. Ramy zarządzania ryzykiem generatywnej AI, w tym ograniczenia testów, ocena w kontekście wdrożenia i monitorowanie systemów. (DOI)
8. Rozporządzenie (UE) 2024/1689 — AI Act, tekst skonsolidowany na 27 lipca 2026 r. Podstawa prawna rozróżnienia obowiązków uczestników rynku oraz wymagań dotyczących modeli AI ogólnego przeznaczenia z ryzykiem systemowym. (EUR-Lex)
9. Komisja Europejska, „AI Act” — zakres regulacji i harmonogram stosowania oraz „EU Action Plan on Cybersecurity and Artificial Intelligence”. Informacje dotyczące terminów stosowania przepisów i europejskiego podejścia do cyberbezpieczeństwa AI. (Strategia Cyfrowa Europy)
10. Rozporządzenie (UE) 2016/679 — RODO. W szczególności przepisy dotyczące zasad przetwarzania, ochrony danych w fazie projektowania, powierzenia przetwarzania, bezpieczeństwa, DPIA, naruszeń oraz zadań inspektora ochrony danych. (EUR-Lex)
11. Europejska Rada Ochrony Danych, omówienie opinii dotyczącej modeli AI i stosowania RODO, 18 grudnia 2024 r. Wyjaśnienia dotyczące anonimowości modeli i oceny prawnie uzasadnionego interesu jako podstawy przetwarzania. (Europejska Rada Ochrony Danych)
12. Europejska Rada Ochrony Danych, poradnik dla przedsiębiorstw: „Be compliant” oraz „Data breaches”.Wyjaśnienia dotyczące ochrony danych w fazie projektowania, oceny skutków oraz reagowania na naruszenia ochrony danych osobowych. (Europejska Rada Ochrony Danych)