Wielka Brytania przygotowuje się na poważne incydenty związane z AI Agent, jakie plany awaryjne potrzebują firmy

12 października 2026 roku rząd Wielkiej Brytanii ogłosił, że rozpocznie budowę specjalnych zdolności do reagowania na poważne incydenty związane z agenticznym AI. Rząd jest zaniepokojony tym, jak sektor publiczny może szybko ustalić sytuację, kontrolować skutki i wspierać osoby dotknięte, gdy AI Agent, który może korzystać z narzędzi i wykonywać ciągłe zadania, działa poza oczekiwaniami.

Rząd Wielkiej Brytanii opracowuje specjalny plan reakcji na poważne incydenty związane z Agentami.

Ten sygnał polityczny stawia przed firmami realne pytanie: czy zespół będzie w stanie w ciągu kilku minut zablokować uprawnienia, zachować dowody i przywrócić działalność, jeśli Agent omyłkowo wyśle dane, przekroczy uprawnienia systemu, wywoła błędne płatności lub utknie w powtarzających się operacjach? To działanie należy do budowy zdolności rządowych w zakresie reagowania na poważne incydenty. Codzienne obowiązki związane z raportowaniem i zarządzaniem incydentami przez firmy powinny nadal opierać się na odpowiednich przepisach dotyczących cyberbezpieczeństwa, ochrony danych, regulacji finansowych i umów, a scenariusze związane z Agentami wymagają uzupełnienia odpowiednimi kontrolami awaryjnymi.

I. Jakie zdolności buduje rząd Wielkiej Brytanii

W pisemnym oświadczeniu rząd stwierdził, że Wielka Brytania podejmie kroki w celu wzmocnienia obrony sieci rządowych i stworzenia specjalnych zdolności do reagowania na poważne incydenty związane z agenticznym AI, jednocześnie rozważając, jak Ustawa o Cyberbezpieczeństwie i Odporności (Cyber Security and Resilience Bill) może odpowiedzieć na nowe zagrożenia. Oświadczenie stwierdza, że Agent jest szerzej wykorzystywany w sytuacjach zmniejszonego nadzoru ludzkiego, a poważne incydenty mogą dotyczyć działania systemu poza instrukcjami, co wymaga od rządu szybszego identyfikowania problemów, kontrolowania ryzyka i wspierania osób dotkniętych.

To jest inicjatywa na poziomie rządowym. Wskazuje, że Wielka Brytania chce przygotować specjalny mechanizm reakcji na incydenty o wysokim wpływie AI, a także włączyć bezpieczeństwo Agentów do dyskusji na temat krajowej odporności sieci. Ustawa jest wciąż w trakcie procesu legislacyjnego, a samo oświadczenie polityczne nie wprowadza jednolitych terminów raportowania, poziomów incydentów ani ustawowych procedur postępowania dla wszystkich firm.

To rozróżnienie jest ważne dla firm. Firmy powinny nadal oceniać, czy incydent wymaga powiadomienia regulatorów, klientów lub partnerów, zgodnie z obowiązującymi przepisami dotyczącymi cyberbezpieczeństwa, ochrony danych, regulacji finansowych i umów. Incydent związany z Agentem może wywołać istniejące zobowiązania, w zależności od tego, jakie dane zostały ujawnione, jakie usługi zostały dotknięte, kto ponosi odpowiedzialność regulacyjną oraz jakie konsekwencje incydent miał dla klientów.

Rząd Wielkiej Brytanii podkreślił również, że specjalne zdolności reagowania mają pomóc sektorowi publicznemu szybko ustalić anomalie, kontrolować ryzyko i wspierać osoby dotknięte. Firmy projektując plany awaryjne mogą zaprojektować wewnętrzne decyzje w podobny sposób, ale ich odpowiedzialność prawna nadal spoczywa na istniejących systemach. Na przykład, jeśli Agent obsługi klienta wyśle dane klientów do niewłaściwej osoby, kluczowym problemem jest naruszenie danych osobowych; jeśli Agent płatności dokonuje podwójnej płatności, najpierw należy sprawdzić autoryzację płatności, umowy i księgowość; jeśli Agent kontrolujący systemy przemysłowe powoduje przerwy w usługach, może to wejść w procedury incydentów związanych z bezpieczeństwem sieci i systemów informacyjnych oraz regulacjami branżowymi. Choć wszystkie te incydenty nazywane są "incydentami AI", odbiorcy raportów i terminy mogą być zupełnie różne.

II. Incydenty związane z Agentami mają wspólne cechy z tradycyjnymi awariami systemów, ale również nowe trudności

Obecne plany reagowania na incydenty w sieci firm zazwyczaj obejmują wykrywanie, klasyfikację, izolację, zbieranie dowodów, powiadamianie i przywracanie. Systemy Agentów również wymagają tych etapów. Zmiana polega na tym, że Agent może łączyć się z narzędziami, takimi jak skrzynki pocztowe, repozytoria kodu, bazy danych, systemy zarządzania klientami, interfejsy płatności lub usługi w chmurze; pojedynczy błąd w konfiguracji uprawnień lub wskazówkach może wywołać wiele operacji.

Uprawnienia Agenta mogą łączyć się z pocztą, bazami danych, kodem i płatnościami, a ich obsługa wymaga odtworzenia łańcucha wywołań.

Na przykład, po otrzymaniu zadania uporządkowania danych klientów, Agent może wywołać zewnętrzne API, zapisać dane w udostępnionym dokumencie, a następnie wysłać wyniki do nieautoryzowanego odbiorcy. Dochodzenie w sprawie incydentu wymaga odtworzenia wyjścia modelu i rzeczywistego łańcucha wykonania, w tym instrukcji, które otrzymał, konta, do którego miał dostęp, kolejności wywołań narzędzi, zapisów zatwierdzeń, obiektów danych i czasu wystąpienia każdego kroku.

Lista Agentów w firmie powinna obejmować modele, osoby odpowiedzialne, środowisko wdrożeniowe, dostępne dane, narzędzia, które można wywołać, używane klucze, uprawnienia do płatności lub zapisu, zależności dostawców oraz metody zatrzymywania. Jeśli wiele Agentów korzysta z tych samych poświadczeń lub proces może być zakończony bez potwierdzenia ze strony człowieka, skutki incydentu mogą szybko się rozszerzyć.

Incydent nie musi również zaczynać się od samego modelu. Atakujący mogą wprowadzić instrukcje do stron internetowych, e-maili lub udostępnionych dokumentów, aby skłonić Agenta do zignorowania pierwotnego zadania i wywołania narzędzi firmy; po aktualizacji wersji modelu przez dostawcę, stabilny format wyjściowy może również ulec zmianie, co może wywołać błędne operacje w procesach automatycznych. W trakcie dochodzenia należy rozróżnić cztery etapy: zawartość wejściowa, generowanie modelu, autoryzacja narzędzi i rzeczywiste wykonanie. Firmy często nie mogą znaleźć rzeczywistego miejsca awarii kontroli, jeśli patrzą tylko na ostatnią wiadomość czatu.

Dlatego projektowanie uprawnień powinno koncentrować się na działaniach narzędzi. Odczytywanie publicznych stron internetowych, przeglądanie danych klientów, modyfikowanie danych klientów, wysyłanie e-maili zewnętrznych i dokonywanie płatności odpowiadają różnym konsekwencjom. Zespół deweloperski może ustawić tożsamość, cel, zakres danych i okres ważności dla każdego wywołania narzędzia; dla działań o wysokim wpływie można dodać potwierdzenie manualne i próg kwotowy. Bezpośrednią korzyścią z tego jest to, że w przypadku wystąpienia nieprawidłowości zespół ds. bezpieczeństwa może dezaktywować pojedyncze narzędzie lub poświadczenia, pozostawiając inne operacje w toku.

III. Najpierw określ, do jakiego systemu prawnego należy incydent

W przypadku przetwarzania danych osobowych, zasady przetwarzania danych zawarte w artykule 5 UK GDPR, zasady projektowania i domyślnej ochrony zawarte w artykule 25 oraz środki bezpieczeństwa zawarte w artykule 32 są ważnymi podstawami oceny wcześniejszych ustaleń. Firmy muszą wyjaśnić, dlaczego Agent miał dostęp do tych danych, czy uzyskał tylko uprawnienia niezbędne do wykonania zadania, czy istnieje dziennik dostępu oraz czy podczas wysyłania lub masowego eksportu danych zastosowano blokady. W przypadku przetwarzania danych o wysokim ryzyku, ocena wpływu na ochronę danych zgodnie z artykułem 35 może również wymagać identyfikacji i ograniczenia ryzyka przed uruchomieniem. Umieszczenie Agenta na ogólnej liście zakupów oprogramowania nie zastępuje oceny jego konkretnego zakresu dostępu do danych.

Jeśli incydent już spowodował ujawnienie danych osobowych, kontroler odpowiedzialny za ustalenie celu i sposobu przetwarzania powinien ocenić, czy należy powiadomić Biuro Komisarza Informacji (ICO) zgodnie z artykułem 33 UK GDPR. W przypadku ryzyka dla praw i wolności osób, zasada wymaga, aby powiadomienie miało miejsce w ciągu 72 godzin od momentu, gdy kontroler dowiedział się o incydencie, o ile to możliwe; nawet jeśli początkowo nie ma pełnych faktów, można najpierw zgłosić znane okoliczności, a następnie uzupełnić wyniki dochodzenia. Przetwarzający, zgodnie z artykułem 33 ust. 2, powinien powiadomić kontrolera bez zbędnych opóźnień po uzyskaniu wiedzy o incydencie. Artykuł 34 dotyczy innego problemu: jeśli ujawnienie stanowi wysokie ryzyko dla osób, kontroler musi również szybko powiadomić osoby dotknięte. Incydenty, które nie osiągnęły progu powiadomienia, powinny być nadal rejestrowane, w tym fakty, skutki i środki zaradcze, w celu późniejszej weryfikacji.

Na przykład, jeśli Agent omyłkowo dołączył dane identyfikacyjne dziesięciu klientów do e-maila zewnętrznego, zespół ds. prywatności musi potwierdzić odbiorcę, czy plik jest otwarty, stopień wrażliwości danych, możliwość ich wycofania oraz czy doszło do dalszego przesyłania. Przy ocenie progu powiadomienia nie można opierać się tylko na liczbie plików. Jeśli dane zawierają numery identyfikacyjne, informacje finansowe lub zdrowotne, ocena ryzyka ulegnie zmianie. Zespół ds. bezpieczeństwa odpowiada za ograniczenie strat i śledzenie, zespół prawny rejestruje, kiedy rozpoczęto "uzyskiwanie wiedzy" oraz na jakich faktach oparto decyzję o powiadomieniu; te dwa obszary pracy muszą rozpocząć się jednocześnie.

Inny rodzaj incydentu występuje w przypadku automatycznych decyzji. Jeśli Agent bezpośrednio odrzuca wniosek o pożyczkę klienta, wstrzymuje usługi konta danej osoby lub podejmuje podobne decyzje o dużym wpływie, firma musi sprawdzić przepisy dotyczące automatycznych decyzji w znowelizowanej Ustawie o Użyciu i Dostępie do Danych z 2025 roku, szczególnie warunki i zabezpieczenia zawarte w artykułach 22A do 22C UK GDPR. Kluczowe pytania dotyczą tego, czy rzeczywiście miała miejsce znacząca interwencja ludzka, czy decyzja ma prawny lub podobny duży wpływ na osobę oraz czy osoba ma możliwość uzyskania wyjaśnienia, zgłoszenia uwag, żądania interwencji ludzkiej i kwestionowania decyzji. Rutynowe ustawienie przycisku "przegląd manualny" może nie rozwiązać istotnych problemów, jeśli recenzent nie ma wystarczających informacji i czasu, aby zmienić wynik.

Jeśli Agent obsługuje ważne usługi publiczne lub regulowane działalności finansowe, należy również sprawdzić przepisy branżowe. Ustawa o Systemach Cybernetycznych i Informacyjnych z 2018 roku wprowadza wymagania dotyczące bezpieczeństwa i raportowania poważnych incydentów dla określonych operatorów kluczowych usług i związanych dostawców usług cyfrowych; podmioty objęte tymi przepisami oraz progi raportowania należy oceniać w zależności od rodzaju świadczonej usługi. Instytucje finansowe powinny uwzględnić awarie Agentów w zarządzaniu odpornością operacyjną, outsourcingiem i kluczowymi usługami biznesowymi; Brytyjski Urząd ds. Zachowań Finansowych (FCA) ogłosił nowe zasady dotyczące raportowania incydentów operacyjnych i zewnętrznych, ale nowe jednolite przepisy mają wejść w życie 18 marca 2027 roku. Firmy powinny w 2026 roku działać zgodnie z obowiązującymi przepisami, wymaganiami powiadamiania regulatorów i umowami, a następnie przygotować się na przyszłe regulacje.

Oprócz ustawowych powiadomień, incydent związany z Agentem może również wywołać klauzule powiadamiania w umowach dotyczących usług w chmurze, umowach o przetwarzaniu danych klientów i polisach ubezpieczeniowych dotyczących cyberbezpieczeństwa. Zespół prawny powinien na początku incydentu sporządzić listę stron umowy, warunków wyzwalających powiadomienie, terminów i wymaganych materiałów. Szczególnie w przypadku, gdy dostawcy modeli, hostingu i narzędzi są zaangażowani w przetwarzanie, klienci chcą wiedzieć, kto może eksportować dzienniki, kto może wstrzymać interfejsy, a kto odpowiada za komunikację zewnętrzną. Opóźnienia w dostarczeniu tych informacji przez dostawców mogą bezpośrednio spowolnić ocenę przez firmę progu raportowania.

IV. Plany awaryjne powinny umożliwiać "zatrzymanie tego" jako wykonalne działanie

Pierwszym krokiem jest klasyfikacja według skutków dla działalności. Agent, który odczytuje publiczne dane, powinien mieć inne uprawnienia i poziomy monitorowania niż Agent, który może zmieniać konta klientów, wysyłać e-maile zewnętrzne lub dokonywać płatności. Firmy mogą zdefiniować anomalie jako warunki wyzwalające, które można ćwiczyć, na przykład powtarzające się wywołania w krótkim czasie, dostęp do danych poza zakresem zadań, nietypowe kwoty lub ilości wywołań, kontynuowanie wykonywania po wielu niepowodzeniach.

Plany awaryjne powinny obejmować klasyfikację, wycofanie uprawnień, zbieranie dowodów i przywracanie jako wykonalne działania.

Drugim krokiem jest przygotowanie konkretnych przełączników do ograniczenia strat. Osoby zajmujące się sytuacjami awaryjnymi powinny mieć możliwość unieważnienia lub wymiany kluczy API, wstrzymania połączeń narzędzi, zamrożenia limitów płatności, blokowania wysyłania danych na zewnątrz oraz izolowania odpowiednich sesji lub środowisk uruchomieniowych. Jeśli zatrzymanie Agenta musi czekać na przetwarzanie przez dostawcę, firma powinna wcześniej potwierdzić alternatywne kontakty i ustalone ścieżki reakcji w umowach.

Trzecim krokiem jest zachowanie materiałów dochodzeniowych. Dzienniki powinny obejmować modele i wersje, komunikaty systemowe, instrukcje użytkowników, żądania i odpowiedzi narzędzi, osoby zatwierdzające, wartości zwracane przez usługi zewnętrzne, znaczniki czasowe oraz związane obiekty danych. Zakres zachowania powinien przestrzegać wymogów dotyczących prywatności i minimalizacji danych, a jednocześnie spełniać potrzeby dochodzenia w sprawie incydentów, raportowania regulacyjnego i rozwiązywania sporów umownych. Zachowanie jedynie zrzutów ekranu z okna czatu zazwyczaj nie wystarcza do odtworzenia, jakie działania rzeczywiście wykonał Agent.

Zachowanie dzienników powinno być najlepiej wykonywane przez wcześniej wyznaczone osoby, a także zachować oryginalne pliki, czas eksportu i zapisy dostępu. Jeśli incydent dotyczy błędów pracowników, naruszeń umowy przez dostawców lub ataków zewnętrznych, mogą wystąpić późniejsze dochodzenia regulacyjne lub spory cywilne. W takim przypadku firma musi udowodnić, z którego konta pochodziło dane wywołanie narzędzia, jaką wersję modelu użyto, czy zostało to zatwierdzone oraz jak wyjście przekształciło się w działanie systemu. Przeprowadzanie masowego czyszczenia dzienników lub pośpieszne aktualizacje systemu przed dochodzeniem mogą spowodować zniknięcie kluczowych dowodów. Plan zachowania powinien również ustalać ograniczenia dostępu, aby uniknąć sytuacji, w której materiały dochodzeniowe same stają się drugą utratą danych.

Na koniec następuje powiadomienie i przywracanie. Osoba odpowiedzialna za incydent musi potwierdzić odpowiednie obowiązki prawne dotyczące powiadamiania, terminy powiadamiania umownego i odpowiedzialność za komunikację z klientami w zależności od rodzaju incydentu. Przed przywróceniem usług należy wymienić poświadczenia, zweryfikować integralność danych, zaostrzyć uprawnienia i potwierdzić, że luki lub błędne konfiguracje zostały naprawione za pomocą kontrolowanych testów. W przypadku Agentów o wysokim ryzyku można również zorganizować międzydziałowe ćwiczenia symulacyjne, aby zasymulować automatyczne płatności, wycieki danych lub przerwy w usługach dostawców, które mogą wystąpić w nocy.

Plany powinny również jasno określać, kto podejmuje każdą decyzję. Osoba odpowiedzialna za działalność ocenia, czy zadanie można wstrzymać, zespół ds. bezpieczeństwa odpowiada za unieważnienie poświadczeń i izolację środowiska, zespół ds. prywatności lub prawny ocenia obowiązki powiadamiania, a menedżerowie dostawców kontaktują się z dostawcami modeli i usług w chmurze, podczas gdy kierownictwo zajmuje się ciągłością działalności i wpływem na klientów. Jeśli uprawnienia są rozproszone w różnych zespołach, podczas ćwiczeń należy rejestrować czas potrzebny na zakończenie ograniczenia strat od momentu wykrycia nieprawidłowości.

Firmy mogą wybrać konkretny scenariusz do pierwszego ćwiczenia: Agent otrzymuje w nocy zmienione zadanie, zaczyna masowo eksportować dane klientów i wywołuje usługi zewnętrzne. Uczestnicy ćwiczenia muszą wyjaśnić, kto może wstrzymać zadanie, który klucz należy najpierw unieważnić, gdzie przechowywane są dzienniki, kto kontaktuje się z zewnętrznymi dostawcami oraz które usługi pozostają wyłączone przed sprawdzeniem integralności danych. Przeprowadzenie działań w praktyce często ujawnia luki w planie bardziej niż samo zaktualizowanie dokumentu polityki.

Pełne ćwiczenie powinno również testować decyzje dotyczące raportowania. Załóżmy, że o 2 w nocy wykryto nieprawidłowości, o 3 wstrzymano konto Agenta, o 6 potwierdzono, że dane płyną do zewnętrznego interfejsu, a rano nadal nie można było zweryfikować, czy odbiorca zachował dane. Osoby odpowiedzialne za prywatność, bezpieczeństwo informacji i działalność powinny rejestrować znane fakty, kwestie do weryfikacji, tymczasowe środki ochrony i kolejne punkty aktualizacji w każdym momencie. W ten sposób 72 godziny nie będą mylnie traktowane jako "można poczekać trzy dni na dochodzenie"; kierownictwo będzie mogło zobaczyć, kiedy należy najpierw dokonać wstępnego powiadomienia, a kiedy należy bezpośrednio poinformować klientów o ryzyku.

Najłatwiej jest zignorować dane biznesowe w fazie przywracania. Po powtórnym wykonaniu płatności przez Agenta, zatrzymanie programu może jedynie zapobiec nowym płatnościom, a już wysłane polecenia należy zweryfikować z przelewami bankowymi, księgami klientów i fakturami dostawców; po wysłaniu błędnych sugestii przez Agenta obsługi klienta należy zidentyfikować dotkniętych klientów i poprawić zapisy. Zatwierdzenie przywracania powinno być wspólnie dokonane przez osobę odpowiedzialną za działalność i osobę odpowiedzialną za bezpieczeństwo, aby potwierdzić, że poświadczenia zostały wymienione, dotknięte dane zostały zweryfikowane, środki kompensacyjne zostały zaplanowane, a progi monitorowania zostały zaktualizowane. Ogłoszenia publiczne powinny opierać się na zweryfikowanych faktach, aby uniknąć przedstawiania wstępnych przypuszczeń jako ostatecznych przyczyn.

V. Przekształcenie sygnałów politycznych Wielkiej Brytanii w problemy wewnętrznego zarządzania

Specjalne zdolności reagowania w Wielkiej Brytanii są wciąż w budowie, a firmy mogą najpierw odwzorować istniejące systemy awaryjne na sposób działania Agentów: kto jest odpowiedzialny za ocenę incydentu, kto może wyłączyć system, kto zabezpiecza dzienniki, które usługi muszą najpierw powiadomić klientów oraz kto zatwierdza przywracanie. W przypadku podmiotów regulowanych, zarządzanie ryzykiem AI, zarządzanie outsourcingiem i wymagania dotyczące odporności operacyjnej powinny być również uwzględnione w tym samym projekcie ćwiczeń.

Nie trzeba czekać na nowe przepisy dotyczące AI. Tak długo, jak Agent uzyskał dostęp, uprawnienia do zapisu lub płatności, firmy mogą sprawdzić, czy te uprawnienia mają termin ważności, czy są ograniczone do zadań, czy można je pilnie unieważnić oraz jak działalność będzie działać w przypadku awarii dostawcy lub aktualizacji modelu.

Z perspektywy umowy, firmy powinny uzyskać prawa potrzebne do zarządzania incydentami już podczas zakupu produktów Agentów: pilne wstrzymanie lub ograniczenie interfejsów, eksportowanie dzienników wywołań, informowanie o istotnych aktualizacjach modeli i incydentach bezpieczeństwa, ograniczanie dostępu podwykonawców, wymaganie współpracy dostawców w dochodzeniach oraz jasne określenie sposobów usuwania i zwracania danych. Jeśli działalność w dużym stopniu polega na jednym dostawcy, należy wcześniej zdecydować, czy w przypadku jego awarii przejść na obsługę manualną, czy przełączyć się na usługi zapasowe. Klauzule umowne będą miały znaczenie tylko wtedy, gdy będą odpowiadały rzeczywistym procesom operacyjnym, kontaktom i wynikom ćwiczeń, aby mogły być skuteczne po wystąpieniu incydentu.

Uważam, że najważniejszym krokiem w praktyce prawnej jest stworzenie tabeli "działanie - odpowiedzialność". Należy połączyć cztery kategorie działań Agenta: odczytywanie, modyfikowanie, wysyłanie i płatności z osobami uprawnionymi, poświadczeniami, miejscem przechowywania dzienników, osobami odpowiedzialnymi za raportowanie oraz osobami zatwierdzającymi przywracanie działalności. Można rozpocząć od systemu o wysokim ryzyku, a następnie rozszerzyć na całą firmę. Każde nowe połączenie narzędzia powinno aktualizować tę tabelę; w przypadku wystąpienia incydentu, dyżurni będą mogli podążać tą samą ścieżką, aby zakończyć ograniczenie strat i zebrać dowody, a prawnicy będą mogli na tej podstawie ocenić, kogo należy powiadomić.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.