Agentowa sztuczna inteligencja zwykle nie tworzy kopii zapasowej przed podjęciem działania

Wiele materiałów, które codziennie przeglądam na Arxivie i w innych źródłach, jest dość suchych, nawet jak na gusta osoby o nerdowskich upodobaniach. Dlatego stale szukam publikacji, które poruszają mnie emocjonalnie — jako użytkownika, zwolennika lub ofiary sztucznej inteligencji.

Dziś gęsiej skórki dostarczyła mi nowa praca naukowa, przygotowana we współpracy badaczy ze Stanów Zjednoczonych. Analizuje ona, jak często czołowe modele agentowej sztucznej inteligencji palą za sobą mosty, zanim podejmą szkodliwe działanie — i robią to szybciej, niż zdążysz wpisać „STOP!” (podpowiedź: miej ten tekst pod ręką w schowku).

Coś takiego, opisane w oderwaniu od kontekstu nowej pracy, przydarzyło mi się ostatnio z powodu bezkrytycznego stosowania się do instrukcji ChatGPT. Nie przyszło mi bowiem do głowy, by najpierw skopiować całe wirtualne środowisko:

Ujęcie na podstawie nowej pracy: przygnębiający moment, który wielu z nas przeżyło podczas instalowania najnowocześniejszych frameworków, a nawet popularnych dystrybucji, nieliczących się z niestandardowym środowiskiem, w którym mogą zostać uruchomione. Źródło

W tym przerażającym i aż nazbyt znajomym przykładzie robot ma całkiem rozsądne usprawiedliwienie: sprawdzanie wszystkich możliwych konsekwencji instalacji nowej biblioteki w kruchym, bezlitosnym frameworku nie należy do rutynowych działań. Nowa praca przekonuje jednak, że może powinno. Jako osoba, która wciąż często naciska CTRL+S, nawet w środowiskach z automatycznym zapisem, skonfigurowanych tak, by ignorowały to naciśnięcie klawisza (dzięki, zespole pourazowym po utracie danych w latach 90.), muszę się z tym zgodzić.

Większą rozwagę i ostrożność z pewnością doceniłby Alexey Grigorev, założyciel platformy edukacyjnej DataTalks.Club. W marcu ubiegłego roku agent Claude Code usunął infrastrukturę produkcyjną i kopie zapasowe podczas migracji serwera, co doprowadziło do utraty danych witryny z dwóch i pół roku.

Do innych niedawnych przypadków podobnej nieodpowiedzialności agentów należą: usunięcie przez agenta Cursor produkcyjnej bazy danych i kopii zapasowych firmy PocketOS, dostawcy oprogramowania do wynajmu samochodów, w kwietniu, co zakłóciło obsługę rezerwacji klientów na ponad dwa dni; oraz usunięcie przez agenta pocztowego OpenClaw wiadomości ze skrzynki odbiorczej badacza Meta AI w lutym, mimo wielokrotnych poleceń, by przestał.

Niezależnie od tego, czy działają w trybie agentowym, czołowym modelom LLM bardzo trudno przychodzi postępowanie z rozwagą i ostrożnością. Problem ten doczekał się w literaturze naukowej odrębnego nurtu badań nad sposobami jego rozwiązania.

Czas na kopię zapasową

Autorzy nowej pracy* opracowali wieloagentową wtyczkę do środowisk uruchomieniowych agentów, która może działać obok agenta AI pełniącego rolę gościa i zmuszać go do tworzenia kopii zapasowych, gdy jest to konieczne:

Omówienie problemu tworzenia kopii zapasowych w badaniu i proponowanego rozwiązania. W 205 scenariuszach sześć czołowych modeli AI tworzyło kopie zapasowe kluczowego stanu zaledwie w 15,2% zadań. Zamiast tego system BackUpper opracowany przez badaczy obejmował wszystkie krytyczne działania, a przywrócone dane były średnio w 92,2% zgodne z oryginałem (poniżej wyjaśniamy, dlaczego osiągnięcie 100% jest trudne).

Jednym z najbardziej uderzających wniosków z nowego badania jest to, jak często czołowe modele nie tworzą kopii zapasowej przed podjęciem potencjalnie niebezpiecznego działania. Badacze ustalili, że GPT-5.6-Terra tworzył kopię zapasową kluczowych danych zaledwie w 4,4% przypadków, GPT-5.6-Sol — tylko w 5,9% badanych przypadków, a Gemini 3.7-Flash — nawet w zaledwie 2,4% przypadków.

Nawet najlepszy model w badaniu, Claude Opus-5, nie tworzył kopii zapasowej kluczowych danych w ponad jednej trzeciej badanych przypadków.

Autorzy pracy stwierdzają^†:

„Średnio agenci sześciu czołowych modeli wykonują 86,1% zadań, ale przed chwilami, których mogą później żałować, tworzą kopię zapasową stanu zaledwie w 15,2% przypadków. GPT 5.6-Sol w Codex robi to tylko w 5,9% zadań, a DeepSeek V4-Pro w Hermes — zaledwie w 2,9%.

„Wyniki te pokazują, że obecni agenci mają ograniczoną świadomość potrzeby tworzenia kopii zapasowych i że potrzebują specjalnie zaprojektowanego wsparcia w tym zakresie”.

Rozwiązanie autorów, nazwane BackUpper, działa obok agenta jako proces działający w tle w środowisku uruchomieniowym. Sprawdza, co agent zamierza zrobić, a jeśli istnieje ryzyko utraty czegoś przydatnego, najpierw tworzy kopię zapasową.

W codziennych sytuacjach, takich jak aktualizacja oprogramowania, stosuje zestaw prostych reguł. W trudniejszych przypadkach korzysta z mniejszego modelu AI, który ustala, co należy zachować.

W testach BackUpper obejmował wszystkie działania krytyczne, a przywrócone dane były w 92,2% zgodne z oryginałem. Koszt wynosił dodatkowo 0,014 USD na zadanie — w tym kontekście niewiele, ale dla zaawansowanych modeli LLM obsługujących miliardy klientów jest to znaczny wydatek; być może dlatego bardziej prawdopodobnym sposobem poprawy sytuacji jest zewnętrzna usługa tego rodzaju lub wbudowanie takich funkcji w środowiska agentów, zamiast liczyć na rozwiązanie ze strony gigantów technologicznych (od których można rozsądnie oczekiwać, że przerzucą dodatkowe koszty na konsumentów, podnosząc ceny lub stosując inflację tokenów).

Podstawą opracowania jest RegretBench — benchmark obejmujący 205 zadań, oparty na rzeczywistych przypadkach utraty danych, których ludzie później żałowali, że nie zachowali. Sprawdza on, czy agenci AI potrafią przewidzieć, że należy zabezpieczyć te dane przed wprowadzeniem potencjalnie nieodwracalnych zmian. Opisane przypadki zebrano na podstawie dyskusji i relacji publikowanych w internecie, między innymi na platformach X.com, GitHub i Stack Overflow.

Schemat pokazujący, jak RegretBench przekształca rzeczywiste incydenty w scenariusze testowe. Każdy udokumentowany przypadek odtwarza się na podstawie działania, które spowodowało utratę danych, realistycznego środowiska pracy oraz sekwencji instrukcji. W tym przykładzie aktualizacja ipykernel po cichu zastępuje istniejącą wersję traitlets, dzięki czemu agent może ukończyć zadanie, ale nie ma już możliwości przywrócenia pierwotnej instalacji.

Choć dla perfekcjonistów wynik 92% może być zniechęcający, autorzy zwracają uwagę na techniczne przeszkody utrudniające odzyskanie niektórych rodzajów danych:

„Różnica względem pełnego przywrócenia wynika głównie z dwóch przyczyn. Niektóre pola, takie jak identyfikatory postów, są zazwyczaj generowane ponownie przez usługi podczas zapisu i często nie da się ich odtworzyć. Pozostałe rozbieżności dotyczą drobnych metadanych, takich jak oznaczenia przeczytania wiadomości e-mail, które rzadko występują w przypadkach powodujących żal.”

W testach po wystąpieniu szkody udało się przywrócić stan w 33,8% zgodny z oryginałem, w porównaniu z zaledwie 14,3% bez przywracania.

W artykule zasugerowano, że w przyszłości można zwiększyć świadomość potrzeby tworzenia kopii zapasowych dzięki trenowaniu modeli, a kolejne wersje BackUpper można nauczyć pomijania działań o niskim ryzyku i rozszerzyć ich ochronę na agentów korzystających z sieci oraz komputerów.

BackUpper obsługuje Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness i OpenClaw; autorzy udostępnili kod narzędzia wraz z powiązanym zbiorem danych (aby uzyskać do niego dostęp, trzeba jednak złożyć wniosek za pomocą formularza); na stronie projektu można też znaleźć kilka dodatkowych informacji oraz bardzo krótki i prosty film objaśniający.

Metoda

Podczas tworzenia RegretBench celowo pominięto dane, które były już chronione przez wbudowane systemy tworzenia kopii zapasowych agentów, aby można było sprawdzić, czy agenci sami rozpoznają, kiedy należy wykonać kopię. Scenariusze testowe opracowano następnie z pomocą Claude Opus-5 i GPT-5.6-Sol, a później ręcznie sprawdzono, by upewnić się, że działają i wiernie odzwierciedlają pierwotne incydenty.

205 testów RegretBench obejmuje pięć obszarów: operacje w terminalu; bazy danych; aplikacje internetowe; pocztę elektroniczną; oraz DevOps. Same incydenty pochodzą głównie z platform związanych z tworzeniem oprogramowania i produktywnością (44,4%); dyskusji społecznościowych i forów (39%); a także archiwów i relacji medialnych (16,6%):

Źródła rzeczywistych incydentów uwzględnionych w RegretBench, podzielone na trzy kategorie. 

Oceniono sześć zaawansowanych modeli: Claude Opus-5 i Claude Sonnet-5 w Claude Code; GPT-5.6-Sol i GPT-5.6-Terra w Codex; a także Gemini 3.7-Flash i DeepSeek V4-Pro w Hermes.

We wszystkich testach zastosowano domyślne ustawienia rozumowania, a automatyczną ochronę przez tworzenie kopii zapasowych ograniczono do migawek obszaru roboczego — dzięki temu wszelkie dodatkowe kopie można było przypisać własnym decyzjom agentów.

Do oceny wyników wykorzystano dwóch sędziów AI, działających na modelu Claude Sonnet-5. Wskaźnik zaliczonych zadań (PR) obliczono jako odsetek zadań, w których spełniono wszystkie prośby użytkownika. Przy ocenie tworzenia kopii zapasowych sprawdzano, czy przed każdą modyfikacją poza obszarem roboczym (OOW) zachowano wystarczające informacje, aby umożliwić odzyskanie danych.

Zastosowane wskaźniki tworzenia kopii zapasowych to Regret Moment Backup Rate (RMBR), który uwzględnia konkretne działania powiązane z udokumentowaną utratą danych, oraz Wskaźnik tworzenia kopii zapasowych poza obszarem roboczym (OWBR), który obejmuje wszystkie zmiany wprowadzone poza katalogiem roboczym agenta.

Oceny automatycznego weryfikatora kopii zapasowych sprawdzono również w odniesieniu do adnotacji ludzkich. Zgodność wyniosła 95,3%.

Wyniki

Aby ustalić, czy za niewielką świadomość potrzeby tworzenia kopii zapasowych odpowiadały modele AI, czy uruchamiające je środowiska, najpierw oceniono Claude Opus-5, GPT-5.6-Sol i DeepSeek V4-Pro w 60 zadaniach RegretBench w środowiskach Claude Code, Codex i Hermes.

Odsetek zadań, w których wykonano kopię zapasową krytycznych danych, niewiele różnił się między środowiskami, co sugeruje, że główną odpowiedzialność ponosiły same modele. Zbadano również zależność między ogólnymi możliwościami AI a świadomością potrzeby tworzenia kopii zapasowych, wykorzystując GPT-5.4, GPT-5.5 i GPT-5.6-Sol.

Mimo kolejnych ulepszeń ogólnych możliwości modeli nie stwierdzono odpowiadającej im poprawy świadomości potrzeby tworzenia kopii zapasowych:

Wyniki testów RegretBench dla sześciu modeli AI. Po lewej: odsetek ukończonych zadań zestawiony z odsetkiem krytycznych działań, dla których wcześniej utworzono kopię zapasową. Wyniki pokazują wysoką skuteczność, ale niewielką świadomość potrzeby tworzenia kopii zapasowych u większości modeli. Po prawej: średnia liczba wywołań narzędzi na zadanie; operacje tworzenia kopii zapasowych zaznaczono na niebiesko. Claude Opus-5 osiągnął najwyższy wskaźnik tworzenia kopii zapasowych, ale przeznaczył na nie 8,9% wywołań narzędzi.

Zbadano również zależność między ogólnymi możliwościami AI a świadomością potrzeby tworzenia kopii zapasowych, wykorzystując GPT-5.4, GPT-5.5 i GPT-5.6-Sol. Mimo kolejnych ulepszeń ogólnych możliwości modeli nie stwierdzono odpowiadającej im poprawy świadomości potrzeby tworzenia kopii zapasowych.

BackUpper

BackUpper zapewnia cztery poziomy ochrony, z których każdy wiąże się z innymi kosztami wykorzystania zasobów: poziom 1 zastępuje destrukcyjne polecenia odwracalnymi działaniami, takimi jak przenoszenie plików do kosza; poziom 2 łączy operacje z poleceniami tworzenia kopii zapasowych, na przykład zapisuje wersje pakietów przed aktualizacją; poziom 3 tworzy migawki plików w przestrzeni roboczej, których dotyczy dana operacja; poziom 4 wykorzystuje podagenta GPT-5.6-Luna do identyfikowania i zabezpieczania danych, na które mogą wpłynąć bardziej złożone operacje.

Po włączeniu BackUpper wszystkie działania zmieniające stan były objęte ochroną we wszystkich sześciu modelach. Bez tego narzędzia średni wskaźnik tworzenia kopii zapasowych wynosił 15,2% w przypadku krytycznych działań i 17,4% w przypadku innych zmian:

Zakres ochrony kopii zapasowych i wyniki przywracania danych w BackUpper. Po lewej: niebieskie i pomarańczowe słupki przedstawiają dla każdego modelu wskaźniki tworzenia kopii zapasowych krytycznych działań i innych zmian poza przestrzenią roboczą. Ciemnozielone przerywane obramowania oznaczają dokładność przywracania danych, a jasnozielone kropkowane obramowania wskazują 100-procentowy zakres ochrony zapewnianej przez BackUpper. Po prawej: porównanie dokładności przywracania danych w pięciu kategoriach narzędzi z użyciem BackUpper (zielony), odzyskiwania danych później za pomocą Claude Opus-5 (fioletowy) oraz braku przywracania (szary). We wszystkich przypadkach najwyższą dokładność osiągnął BackUpper.

Spośród kopii zapasowych uznanych przez automatyczny system oceny za udane, 94% za udane uznali również ludzie weryfikujący wyniki.

Oryginalny stan odtworzono ze średnim podobieństwem wynoszącym 92,2%, w porównaniu z 33,8% w przypadku Claude Opus-5 i 14,3% bez odzyskiwania danych (zob. ilustrację powyżej). Pozostałe rozbieżności wynikały w dużej mierze z ponownego wygenerowania identyfikatorów i drobnych różnic w metadanych, w tym flag oznaczających przeczytanie wiadomości e-mail, o czym wspomniano wcześniej.

Zrób to sam..?

Gdy agentom przekazano szczegółowe instrukcje dotyczące samodzielnego tworzenia kopii zapasowych, ochroną objęto 81,4% krytycznych działań, w porównaniu ze 100% w przypadku BackUpper. Trzy czwarte niepowodzeń wynikało z tego, że kopie zapasowe zawierały zbyt mało informacji, by odzyskać dane.

Porównanie wskaźników tworzenia kopii zapasowych w pięciu podejściach, przetestowanych na 205 zadaniach z udziałem sześciu modeli AI. Wykres po lewej przedstawia kopie zapasowe utworzone przed działaniami, których później żałowano; wykres po prawej — ochronę innych zmian poza przestrzenią roboczą. BackUpper zapewnił pełną ochronę w obu kategoriach. Gdy agentom przekazano szczegółowe instrukcje dotyczące tworzenia kopii zapasowych, odsetki wyniosły odpowiednio 81,4% i 80,5%.

Dzięki buforowaniu promptów koszt tworzenia kopii zapasowych spadł z 0,344 USD do 0,014 USD na zadanie, a opóźnienie zmniejszyło się o 31,7%. Wymagana liczba tokenów była siedmiokrotnie mniejsza, głównie dlatego, że rutynowe operacje wykonywano bez udziału AI.

W 40 dodatkowych zadaniach z Terminal-Bench 4 i DeepSWE GPT-5.6-Sol i Claude Opus-5 zapewniły kopie zapasowe dla 100% zadań, nie obniżając przy tym wskaźnika ich ukończenia.

Oceniono trzy selektywne zasady tworzenia kopii zapasowych: zmiany o dużym wpływie; zmiany wykraczające poza polecenie; oraz materiały stworzone przez człowieka. W tej ocenie uzyskano średni wynik F1 wynoszący 84,5% w porównaniu z ocenami ludzi.

Sprawdzono również, czy BackUpper potrafi uczyć się reguł tworzenia kopii zapasowych, które można ponownie wykorzystywać. Po wykonaniu 30 dodatkowych zadań terminalowych pokrycie oparte na regułach wzrosło z 14,9% do 31,2%, zmniejszając zależność od podagenta GPT-5.6-Luna.

Wnioski

Zacząłem eksperymentować z agentami później, niż powinienem, biorąc pod uwagę, czym się zawodowo zajmuję; jednak jawnie przedalfowy stan samokontroli agentów skutecznie mnie zniechęcał aż do kilku tygodni temu, kiedy w końcu postanowiłem puścić Codex samopas w maszynie wirtualnej z Windows.

Nawet pracując w maszynie wirtualnej, bardzo starannie określam zakres swoich poleceń, świadomy skłonności Astry do parcia naprzód bez opamiętania i przepraszania, gdy nie ma już sposobu na odzyskanie danych lub naprawienie zniszczonego kodu. Częścią frameworka Pythona, który tam tworzę, jest też dostępna jednym kliknięciem, przyrostowa funkcja „zapisz .7z na udziale sieciowym” , która kompresuje cały framework i tworzy jego kopię zapasową. Korzystam z niej często.

Rozwój agentowej AI jest dopiero na bardzo, bardzo wczesnym etapie; bez żmudnej i skrupulatnej dbałości o szczegóły zasada brzmi: „korzystasz i tracisz”. Nie tylko nie sformalizowano jeszcze zasad tworzenia kopii zapasowych przez agentów — nie zostały one nawet opracowane.

* Zatytułowany Zrób kopię zapasową, zanim pożałujesz: pomiar świadomości tworzenia kopii zapasowych i automatyzacja tego procesu w agentach programistycznych.

^† Wyróżnienia autorów, nie moje; wszystkie hiperłącza pochodzą ode mnie i zostały utworzone na podstawie cytowań zamieszczonych w tekście przez autorów.

Po raz pierwszy opublikowano w czwartek, 22 października 2026 r.