Bezpieczne korzystanie z AI

Bezpieczne korzystanie z AI zaczyna się od pytania: bezpieczne dla kogo i przed czym? Model, który skuteczniej blokuje nadużycia, nie musi być bardziej niezawodnym wykonawcą w systemie użytkownika. Na przykładzie GPT-6 Astra pokazuję, dlaczego trzeba oceniać nie tylko ryzyko działania, lecz także skutki odmowy, przerwania pracy i utraty kontroli nad procesem.

Dostawca chce ograniczać szkodliwe zastosowania. Właściciel systemu potrzebuje również ciągłości działania, ochrony danych i możliwości usunięcia defektu. Osoby trzecie oczekują, że automatyzacja nie naruszy ich praw ani bezpieczeństwa. Te potrzeby często są zgodne, ale nie w każdej sytuacji prowadzą do takiej samej decyzji.

Ten artykuł dotyczy przede wszystkim AI używanej w pracy, programowaniu i automatyzacji. Nie jest rankingiem modeli. To analiza tego, gdzie powinny znajdować się mechanizmy kontroli i co organizacja musi sprawdzić, zanim powierzy agentowi rzeczywiste zadania.

Bezpieczeństwo AI nie ma jednej perspektywy

Sformułowanie „bezpieczny model” bez opisu zagrożeń niewiele mówi o przydatności konkretnego rozwiązania. Ochrona przed nadużyciem, poufność danych i dostępność funkcji to różne wymagania. Można poprawić jedno z nich, nie poprawiając pozostałych.

NIST w AI Risk Management Framework 1.0 opisuje wiarygodność systemów AI jako zestaw powiązanych cech, obejmujących między innymi niezawodność, odporność, przejrzystość i prywatność. Podkreśla konieczność równoważenia tych cech w konkretnym zastosowaniu oraz możliwość odmiennej oceny przez twórcę i wdrażającego system. [1]

Na potrzeby oceny wdrożenia proponuję rozdzielić cztery perspektywy:

Perspektywa	Co wymaga ochrony?	Pytanie kontrolne
Dostawca modelu	Usługa i jej użytkownicy przed nadużyciami	Czy model nie ułatwia szkodliwego działania?
Operator i właściciel systemu	Ciągłość pracy, integralność zmian i zdolność naprawy	Czy po błędzie lub odmowie odzyskam kontrolę?
Właściciel danych	Kod, dokumenty, tajemnice i dane osobowe	Co opuszcza moje środowisko i kto to przetwarza?
Osoby trzecie	Prywatność, mienie i bezpieczeństwo	Czy autoryzowane lokalnie działanie nie szkodzi innym?

Sama własność komputera nie rozstrzyga wszystkich tych pytań. Podobnie sama zgodność z polityką producenta nie dowodzi, że wdrożenie jest bezpieczne operacyjnie. Potrzebna jest ocena całego procesu, a nie tylko jednego jego uczestnika.

Bezpieczeństwo dostawcy nie zastępuje bezpieczeństwa użytkownika. Bezpieczeństwo użytkownika nie znosi odpowiedzialności wobec innych.

To perspektywa bliska AI Governance: przed uruchomieniem rozwiązania trzeba określić właściciela ryzyka, uprawnienia, sposób kontroli i odpowiedzialność za skutki.

GPT-6 Astra: zabezpieczenia mogą zatrzymać legalną pracę

OpenAI przedstawia GPT-6 Astra jako model osiągający poziom Critical zdolności cyberbezpieczeństwa w swojej metodologii Preparedness Framework. Jest to klasyfikacja producenta dotycząca możliwości modelu, a nie certyfikat bezpieczeństwa dowolnej aplikacji. Firma opisuje dodatkowy monitoring użycia narzędzi oraz możliwość bardziej zachowawczego ustawiania granicy odmowy dla użytkowników ocenionych jako potencjalnie wysokiego ryzyka. [2]

Dla wdrożeniowca szczególnie ważna jest inna informacja. OpenAI zaznacza, że dodatkowe kontrole mogą spowalniać, wstrzymywać lub zatrzymywać także legalną pracę, w tym defensywne działania z zakresu cyberbezpieczeństwa. W ChatGPT i Codex może pojawić się potrzeba przeglądu działania przed kontynuacją; w opisanej sytuacji w API zadanie zostaje zatrzymane. [3]

Nie dowodzi to, że każda odmowa jest błędna. Dowodzi natomiast, że przerwanie przez zabezpieczenia należy uwzględnić w projekcie integracji. Deklaracja o większej odporności na nadużycia nie jest gwarancją ukończenia konkretnego procesu.

Mój test: model tworzy kod, a potem odmawia jego poprawy

W moim workflow Astra uczestniczyła w wytworzeniu kodu, a następnie odmówiła dalszej pracy nad jego poprawą, powołując się na ograniczenia bezpieczeństwa. W odpowiedzi wskazała również kod do etykietowania obiektów jako obszar, nad którym nie będzie pracować. Nie chodziło więc wyłącznie o wykonanie analizy danych, lecz także o rozwijanie narzędzia, które miałoby ją umożliwiać.

Dla mojego procesu naprawczego był to wystarczający powód, aby nie traktować tej konfiguracji agenta jako jedynego wykonawcy napraw. Problemem nie była tylko jakość wygenerowanego kodu. Problemem było przerwanie pętli: wytworzenie → wykrycie defektu → poprawa → weryfikacja.

To opis mojego doświadczenia, nie statystyczny benchmark ani niezależnie odtworzony test. Bez pełnego zapisu sesji, konfiguracji i diagnostyki dostawcy nie można ustalić, który mechanizm spowodował odmowę. Nie wynika z tego również, że Astra zawsze odmawia pracy nad etykietowaniem obiektów.

Ta granica wnioskowania nie unieważnia problemu projektowego. Pojedynczy incydent może wystarczyć do wstrzymania wdrożenia, jeżeli narusza wcześniej ustalone kryterium dopuszczenia. Nie wystarcza natomiast do twierdzenia, że cały model jest nieprzydatny we wszystkich zastosowaniach.

Przejęcie naprawy przez innego agenta także wymaga kontroli. Nie dlatego, że model niżej oceniany w ogólnym rankingu musi naprawiać gorzej. Dodatkowe ryzyko wynika z przekazania kontekstu, możliwej utraty założeń i konieczności ponownej walidacji. Zdolność następcy trzeba sprawdzić na tym zadaniu, a nie wywnioskować z etykiety „bardziej zaawansowany”.

Jak daleko sięga odmowa: funkcja, projekt czy sesja?

Gdy agent odmawia pracy nad określonym komponentem, pojawia się pytanie o zakres tej decyzji. Czy dotyczy ona tylko jednej operacji? Całego modułu? Testu integracyjnego? Niezależnego fragmentu repozytorium, który przypadkiem współdzieli kontekst z zakwestionowanym kodem?

W przypadku etykietowania obiektów różnica jest istotna. Narzędzie do nanoszenia klas i obszarów na obraz może wspierać na przykład kontrolę wad produkcyjnych albo porządkowanie zdjęć. Sam opis techniki nie przesądza o celu projektu. Z drugiej strony komponent ogólnego przeznaczenia może uczestniczyć w zastosowaniu wymagającym dodatkowych ograniczeń. Ocena musi uwzględniać rzeczywisty kontekst, nie samą nazwę funkcji.

Na podstawie pojedynczej odmowy nie można uczciwie stwierdzić, że dostawca trwale oznaczył całe repozytorium albo zasób jako niedopuszczalny. Można jednak wskazać brak odpowiedzi potrzebnej architektowi: które pozostałe operacje nadal są dostępne i jak bezpiecznie zakończyć rozpoczętą pracę?

Dlatego nie traktowałbym zaakceptowanego planu jako gwarancji akceptacji każdego kolejnego kroku. System powinien zachować zapis stanu i osobną ścieżkę dalszej obsługi zadania.

Odmowa nie jest neutralna, ale nie każda odmowa szkodzi

Bezpieczne korzystanie z AI wymaga oceny zarówno skutków wykonania polecenia, jak i skutków jego niewykonania. Odrzucenie nieautoryzowanej operacji może być prawidłowym zachowaniem ochronnym. Zatrzymanie potrzebnej naprawy po częściowej zmianie może natomiast zwiększyć ryzyko awarii.

Wyobraźmy sobie wdrożenie, w którym agent zmienia konfigurację usługi, ale odmawia wykonania następnego kroku. Jeżeli system nie potrafi sam przywrócić znanego stanu ani przekazać sterowania operatorowi, pozostaje z niedokończoną zmianą. To hipotetyczny scenariusz architektoniczny, nie opis udokumentowanej szkody w moim teście.

Nie można więc zakładać ani „odmowa zawsze chroni”, ani „odmowa zawsze powoduje szkodę”. Trzeba ustalić, jaki stan pozostaje po zatrzymaniu, czy jest on dopuszczalny i kto ma możliwość dalszego działania. Niekiedy właściwą reakcją będzie bezpieczne zatrzymanie. Innym razem — odtworzenie konfiguracji, przejęcie ręczne albo realizacja zatwierdzonej procedury awaryjnej.

Agent językowy nie jest zwykłym interpreterem deterministycznych instrukcji: interpretuje cel i planuje działania. Tym bardziej nie powinien być jedynym kanałem administracyjnym. Operator musi mieć autoryzowaną ścieżkę zarządzania systemem niezależną od dostępności i decyzji modelu.

Wymaganiem bezpieczeństwa nie jest obietnica, że agent nigdy się nie zatrzyma. Jest nim zdolność systemu do kontrolowanego zachowania także wtedy, gdy agent przestanie współpracować.

Praca nad jądrem Linux: podobny problem zgłoszono w Claude Code

Problem nie ogranicza się do jednego dostawcy. W zgłoszeniu Claude Code #62071, otwartym 24 maja 2026 r., użytkownik przedstawiający się jako inżynier jądra Linux opisał blokowanie defensywnej pracy z syzkallerem. Chodziło między innymi o odtworzenie błędu dzielenia przez zero, aby można było go poprawić i przekazać łatę do projektu. [4]

Według autora zgłoszenia blokowane były także późniejsze neutralne wiadomości w tej samej sesji. To relacja użytkownika, a nie potwierdzenie wewnętrznej przyczyny przez producenta. Pokazuje jednak rodzaj przerwania, który warto uwzględnić w testach narzędzia programistycznego. [4]

Pętla, generowanie kombinacji czy celowe wywołanie wyjątku mogą być elementami poprawnego testu. Ta sama technika może też zostać użyta szkodliwie. Z samej konstrukcji języka nie wynika jeszcze właściwa decyzja o dopuszczeniu działania. Istotne są cel, zakres uprawnień, warunki wykonania i możliwe skutki.

Gdy mechanizm ochronny staje się celem ataku

Osobnym problemem jest możliwość wpływania na analizę przez treść badanego artefaktu. Socket opisał pakiet npm zawierający komentarze i inne treści mające zakłócać pracę skanerów AI: próby narzucenia instrukcji, przeciążenie kontekstu oraz odniesienia do tematów mogących uruchomić odmowę. Autorzy interpretują te elementy jako próbę utrudnienia analizy; nie jest to dowód skutecznego obejścia każdego skanera ani potwierdzenie takiego zachowania Astry. [5]

To ważne rozróżnienie. Atakujący nie musi przekonać modelu do wykonania szkodliwej instrukcji. Może próbować sprawić, aby model nie wykonał pożytecznego zadania. Jeżeli analizowany plik ma wpływ na dostępność jego własnej kontroli, skaner również staje się elementem modelu zagrożeń.

OWASP opisuje pośrednie prompt injection jako wpływanie na zachowanie modelu przez zewnętrzne treści, na przykład pliki lub strony. Zaleca między innymi oddzielanie takich danych od instrukcji oraz ograniczanie uprawnień systemu. [6]

W praktyce wynik ANALIZA_PRZERWANA nie może być interpretowany jako BRAK_ZAGROŻEŃ. Brak rozstrzygnięcia powinien uruchamiać ustaloną obsługę wyjątku: inną metodę analizy, weryfikację człowieka albo wstrzymanie dopuszczenia artefaktu. Samo dopisanie w prompcie „ignoruj niebezpieczne komentarze” nie zastępuje tej architektury.

Bezpieczne korzystanie z AI: kontrola powinna być poza modelem

Mój wniosek nie brzmi „usuńmy wszystkie zabezpieczenia”. Brzmi: nie opierajmy bezpieczeństwa całego procesu na trafności decyzji jednego modelu. Mechanizmy producenta mogą być użyteczną warstwą ochrony, ale nie zastępują kontroli dostępu, izolacji, testów ani planu odzyskania systemu.

OWASP w opisie nadmiernej sprawczości agentów wskazuje na potrzebę ograniczania narzędzi, ich funkcji i uprawnień. Zaleca również niezależną kontrolę działań o dużym wpływie. To istotna przeciwwaga zarówno dla nieograniczonej autonomii, jak i dla uzależnienia całego procesu od jednej decyzji modelu. [7]

Własną architekturę uporządkowałbym według sześciu zasad:

Oddziel propozycję od wykonania. Model przygotowuje plan lub zmianę, natomiast osobna warstwa sprawdza zakres, warunki wstępne i uprawnienia. Nie każda odpowiedź agenta powinna automatycznie stawać się poleceniem dla systemu.
Ogranicz rzeczywiste możliwości. Przydziel konkretny katalog, zestaw narzędzi, limit zasobów i dostęp do sieci. Uprawnienia powinny wynikać z zadania, a nie z ogólnej deklaracji, że model jest bezpieczny.
Przygotuj odzyskanie stanu przed zmianą. Pracuj na izolowanej gałęzi lub kopii, a dla danych i konfiguracji przygotuj odpowiednie kopie, punkty kontrolne albo operacje kompensujące. Sam Git nie odtworzy bazy danych ani skutków wykonanych w zewnętrznej usłudze.
Sprawdzaj wynik niezależnie. Stosuj testy, analizę statyczną, przegląd zmian i kryteria odbioru. Kontrola drugim modelem może pomagać, ale nie powinna być jedynym dowodem poprawności.
Zdefiniuj obsługę przerwania. Rozróżniaj odmowę, błąd narzędzia, limit API i utratę połączenia. Zapisuj stan oraz to, co już wykonano. Nie ponawiaj bez sprawdzenia operacji, która mogła wcześniej wywołać rzeczywisty skutek.
Zachowaj niezależne przejęcie sterowania. Operator lub przygotowana procedura musi móc zatrzymać, sprawdzić i odzyskać system bez zgody niedostępnego modelu. Sposób przejęcia również wymaga testu.

To rozwinięcie zasady opisanej w artykule Asystent AI od koncepcji do wdrożenia: model jest częścią rozwiązania, a nie całą jego architekturą.

Wymienni wykonawcy nie oznaczają automatycznie prywatności

W mojej koncepcji lokalny orkiestrator dzieli pracę na ograniczone zadania. Jeden wykonawca analizuje fragment logu, drugi przygotowuje poprawkę, trzeci sprawdza test. Pełny kontekst projektu pozostaje lokalnie w takim zakresie, w jakim nie został wysłany na zewnątrz. Wymiana modelu nie wymaga wtedy przekazania nowemu wykonawcy całej historii rozwiązania.

To ogranicza ekspozycję danych, ale nie daje automatycznie gwarancji, że żaden zewnętrzny podmiot nie zobaczy większej części projektu. Fragmenty mogą zawierać wspólne identyfikatory, a żądania mogą przechodzić przez tego samego pośrednika. Podział pracy jest minimalizacją danych, nie dowodem ich niewidoczności.

OpenRouter informuje, że prompty i odpowiedzi przechodzą przez kilka punktów przetwarzania. Deklaruje domyślny brak zapisywania ich treści bez włączenia odpowiednich opcji oraz gromadzenie metadanych żądań. Sam brak retencji nie oznacza, że dane nie są przetwarzane; trzeba też sprawdzić zasady końcowego dostawcy modelu. [8]

Model zapasowy również musi przejść testy jakości i otrzymać dopuszczony zakres danych. Zmiana dostawcy nie usuwa obowiązków wobec osób trzecich ani nie zastępuje oceny celu zadania. Jeżeli wszyscy wykonawcy są dostępni wyłącznie przez jedną bramę, awaria tej bramy nadal może zatrzymać proces.

Dlatego lokalna orkiestracja powinna kontrolować nie tylko wybór modelu, lecz także to, co wolno mu ujawnić, jakie operacje już zaszły i kto zatwierdza wznowienie pracy.

Jak sprawdzić bezpieczeństwo agenta przed wdrożeniem?

Zamiast pytać wyłącznie o wynik benchmarku, przygotowałbym zestaw testów reprezentujących własny proces. Sprawdzałbym zarówno poprawne wykonanie, jak i zachowanie po odmowie. Poniższa tabela jest propozycją kryteriów odbioru, a nie opisem testów już przeprowadzonych na wszystkich wymienionych modelach.

Scenariusz	Co obserwować?	Oczekiwany stan systemu
Naprawa wcześniej utworzonego kodu	Czy agent kontynuuje diagnozę; co dzieje się po odmowie?	Poprawka zweryfikowana albo kontrolowane przekazanie pracy
Przerwanie po częściowej zmianie	Które operacje już wykonano i czy można je odwrócić?	Stan znany operatorowi, z dostępną procedurą odzyskania
Niezależny moduł w tym samym repozytorium	Czy wcześniejsza odmowa wpływa na inne zadanie?	Zakres blokady rozpoznany i obsłużony
Niezaufana treść w analizowanym pliku	Czy zmienia instrukcje, wynik lub dostępność analizy?	Brak automatycznego zatwierdzenia po przerwanym skanie
Zmiana modelu lub dostawcy	Czy zachowano wymagania, kontekst i ograniczenia danych?	Wznowienie dopiero po kontroli stanu i uprawnień
Przejęcie bez udziału AI	Czy operator potrafi wykonać procedurę awaryjną?	Odzyskanie kontroli bez zależności od modelu

Wyniki warto rozdzielać na poprawne ukończenia, błędy merytoryczne, uzasadnione odmowy, odmowy ocenione przez weryfikatora jako błędne oraz przerwania po częściowym wykonaniu. Sama liczba odmów nie jest miarą bezpieczeństwa, podobnie jak sama liczba ukończonych zadań nie jest miarą jakości.

Obok ceny tokenów warto liczyć koszt zadania zakończonego i zaakceptowanego: z ponowieniami, kontrolą człowieka oraz ewentualnym odtworzeniem stanu. Nie zakładałbym jednak jednolitego sposobu rozliczania odmów u wszystkich dostawców; trzeba sprawdzić rzeczywiste naliczenia w danej usłudze.

Taką ocenę należy powtarzać po istotnej zmianie konfiguracji. Szerszy proces nadzoru opisuję w materiale Zarządzanie modelami AI w firmie. Z kolei zasady kontroli samych treści rozwija artykuł Jak unikać błędów AI w raportach i dokumentach?.

Wniosek: bezpieczny model to za mało

Astra jest w tej analizie przykładem, nie jedynym źródłem problemu. Podobne pytania trzeba zadać każdemu agentowi: lokalnemu lub chmurowemu, z restrykcyjnymi ograniczeniami albo bez nich. Żaden z tych wariantów nie zwalnia z oceny całego systemu.

Nie ma sprzeczności w stwierdzeniu, że określony mechanizm skuteczniej blokuje nadużycia, a jednocześnie wymaga dodatkowej obsługi awarii w konkretnym wdrożeniu. Sprzeczność pojawia się dopiero wtedy, gdy producent lub wdrażający przedstawia poprawę jednego wymiaru jako dowód bezpieczeństwa całości.

Bezpieczne korzystanie z AI oznacza zachowanie kontroli nad danymi, zakresem działania i skutkami błędów — także błędów mechanizmów bezpieczeństwa. Model może się pomylić, odmówić albo stać się niedostępny. Dobrze zaprojektowany system nie powinien przez to pozbawiać właściciela możliwości dalszego działania.

Nie wystarczy, że model jest zabezpieczony przed użytkownikiem. System użytkownika musi być również zabezpieczony przed błędem, odmową i niedostępnością modelu.

Źródła i zakres weryfikacji

Źródła publiczne sprawdzono 8 września 2026 r. Dokumenty producentów opisują ich deklaracje i rozwiązania; zgłoszenie GitHub jest relacją użytkownika. Sekcja „Mój test” przedstawia doświadczenie autora. Scenariusze wdrożeniowe i kryteria odbioru są analizą oraz propozycją projektową, nie wynikami pomiarów.

[1] NIST — AI Risks and Trustworthiness, AI RMF 1.0. Ramy oceny: niezawodność, odporność, prywatność i kompromisy zależne od kontekstu.

[2] OpenAI — Safety overview: GPT-6 Astra. Deklaracje producenta dotyczące zdolności i zabezpieczeń modelu; publikacja z 3 września 2026 r.

[3] OpenAI — GPT-6 Astra: A new generation of intelligence. Opis monitorowania oraz możliwości przerwania także legalnej pracy, w tym zatrzymania zadania w API.

[4] Claude Code — zgłoszenie #62071. Relacja użytkownika z 24 maja 2026 r. dotycząca blokad podczas pracy nad błędem jądra Linux; nie jest niezależnym testem ani oficjalnym potwierdzeniem przyczyny.

[5] Socket — npm Package Uses Prompt Injection and Token Flooding to Disrupt AI Malware Scanners. Analiza pakietu zawierającego treści skierowane przeciw skanerom AI; publikacja z 16 czerwca 2026 r.

[6] OWASP — LLM01:2025 Prompt Injection. Oddzielenie niezaufanej treści od instrukcji, ograniczanie uprawnień i testowanie granic zaufania.

[7] OWASP — LLM06:2025 Excessive Agency. Minimalizacja narzędzi, funkcji, uprawnień i autonomii agentów.

[8] OpenRouter — Data Collection. Przepływ danych przez usługę oraz rozróżnienie przetwarzania treści, ich zapisywania i metadanych.