Cyberbezpieczeństwo: agent AI nie może dostać kluczy do całej organizacji

Generatywna AI i autonomiczni agenci zmieniają skalę ryzyka związanego z danymi. Nie chodzi już wyłącznie o sytuację, w której pracownik przypadkowo wkleja poufny dokument do chatbota. Agent może w krótkim czasie przeszukać wiele systemów, połączyć rozproszone informacje i wykonać działania przekraczające intencję użytkownika. Dlatego firmy powinny traktować AI nie jak zwykłe narzędzie, lecz jak nowego uczestnika procesu biznesowego – z precyzyjnie określonym zakresem dostępu, kontrolą działań i odpowiedzialnością.

Rozwój generatywnej AI oraz agentów autonomicznych sprawia, że inaczej musimy myśleć o ochronie danych i informacjach poufnych. Dotychczasowy, wciąż aktualny scenariusz ryzyka był stosunkowo prosty: pracownik przez nieuwagę przekazywał dokument, dane klienta lub fragment wewnętrznej analizy do zewnętrznego chatbota. Dziś coraz częściej mamy do czynienia z systemami, które potrafią samodzielnie korzystać z wielu źródeł danych, przeszukiwać repozytoria, analizować korespondencję, łączyć informacje i podejmować kolejne działania za pomocą udostępnionych im narzędzi.

To nie oznacza, że dawne ryzyka znikają. Zmieniają się jednak ich skala, tempo i charakter. Człowiek może przypadkowo przekazać pojedynczy dokument. Agent, realizując pozornie prawidłowe polecenie, może w krótkim czasie sięgnąć po dane z wielu systemów, skorelować je i ujawnić wniosek, którego żadna pojedyncza informacja nie zdradzała. Co więcej, ryzyko nie musi pochodzić od atakującego z zewnątrz. Problemem może być również własny agent organizacji, który dostał zbyt szerokie uprawnienia albo został nakłoniony do działania poza zakresem pierwotnego zadania.

W praktyce bezpieczeństwo AI należy więc projektować podobnie jak bezpieczeństwo pracy człowieka w organizacji. Nowemu pracownikowi nie powierzamy automatycznie dostępu do wszystkich dokumentów, skrzynek pocztowych, baz klientów i systemów finansowych tylko dlatego, że zatrudniliśmy go w firmie. Określamy, do jakich informacji ma dostęp, co może z nimi zrobić, komu może je przekazać oraz jak monitorujemy jego aktywność. Tak samo trzeba myśleć o agencie AI.

Agent AI jako użytkownik z ograniczonym zaufaniem

Wiele dyskusji o bezpieczeństwie modeli językowych koncentruje się na tym, co system może napisać w odpowiedzi na prompt. To istotne, ale niewystarczające. Agent może nie tylko generować tekst. Może wyszukiwać dokumenty, odczytywać wpisy w CRM, pobierać dane z baz wiedzy, analizować e-maile, tworzyć pliki, wykonywać zapytania do usług zewnętrznych lub inicjować komunikację.

Dlatego kontrola powinna obejmować cały cykl działania systemu:

• klasyfikację dokumentów i danych jeszcze przed ich udostępnieniem modelowi;
• analizę promptów, kontekstu i źródeł, z których agent pobiera informacje;
• kontrolę odpowiedzi generowanych użytkownikowi;
• kontrolę operacji wykonywanych przez agenta za pomocą narzędzi;
• rejestrowanie zdarzeń, analizę incydentów i ulepszanie zasad po fakcie.

Przykładowo agent może otrzymać dostęp do dokumentu, aby przygotować analizę dla uprawnionego pracownika. Nie powinno to jednak automatycznie oznaczać, że wolno mu przesłać pełną treść dokumentu na zewnętrzny adres, umieścić ją w publicznej usłudze albo wykorzystać w odpowiedzi dla innej osoby. Równie ważne jak kontrola treści jest zatem egzekwowanie granic działań.

Najbardziej podstawowe ograniczenia nie powinny zależeć wyłącznie od tego, czy model „zrozumie” sytuację. Uprawnienia, dozwolone kanały komunikacji, limity pobierania danych i wymóg zatwierdzania krytycznych operacji powinny być narzucone przez systemy otaczające model. Model może wspierać ocenę ryzyka, ale nie powinien być jedynym mechanizmem egzekwującym reguły bezpieczeństwa.

Dane wrażliwe nie zawsze są widoczne

Wykrywanie danych wrażliwych często kojarzy się z identyfikowaniem numerów PESEL, adresów e-mail, numerów rachunków czy dokumentów tożsamości. W takich przypadkach nadal bardzo skuteczne bywają relatywnie proste mechanizmy oparte na wzorcach, słownikach i regułach.

Problem zaczyna się wtedy, gdy poufna informacja wynika z kontekstu. W dokumencie może nie paść nazwisko pracownika, ale może znaleźć się opis jedynej osoby pełniącej konkretne stanowisko w niewielkiej firmie. Kilka na pozór niewinnych danych może łącznie wskazywać na planowaną transakcję, reorganizację, sytuację zdrowotną konkretnej osoby albo poziom wynagrodzenia w określonym zespole.

Współczesne modele językowe znacznie lepiej niż tradycyjne mechanizmy radzą sobie z analizą znaczenia, relacji i kontekstu. Nie oznacza to jednak, że automatycznie rozpoznają każde ryzyko. Czasami do właściwej oceny potrzebna jest wiedza o strukturze organizacji, relacjach między dokumentami lub aktualnej sytuacji biznesowej. Model analizujący jeden plik może po prostu nie dysponować informacjami koniecznymi do zauważenia problemu.

Nie ma więc uniwersalnej odpowiedzi na pytanie o skuteczność takich narzędzi. Należy testować je na materiałach reprezentatywnych dla danej organizacji i mierzyć zarówno przeoczenia, jak i fałszywe alarmy. System blokujący wszystko może ograniczyć część ryzyka, ale jednocześnie sparaliżować normalną pracę. Celem jest rozsądna równowaga między ochroną informacji a użytecznością narzędzia.

Maskowanie nie zawsze wystarcza by zachować anonimowość

W praktyce często mieszają się trzy pojęcia: maskowanie, pseudonimizacja i anonimizacja. Tymczasem opisują one różne rzeczy i wiążą się z innym poziomem ryzyka.

Maskowanie polega na ukryciu albo zastąpieniu określonych wartości. Można zamaskować numer telefonu, pozostawiając jedynie kilka ostatnich cyfr, lub zastąpić numer karty znakami „** ** **** 2856”. Samo maskowanie nie przesądza jednak, że informacja przestała identyfikować osobę. Możemy usunąć nazwisko, ale zostawić tak szczegółowy opis stanowiska, lokalizacji, projektu i wydarzeń, że ustalenie tożsamości nadal będzie łatwe.

Pseudonimizacja pozwala zachować możliwość powiązania danych z konkretną osobą, ale wymaga użycia dodatkowych informacji przechowywanych oddzielnie i odpowiednio zabezpieczonych. Typowym przykładem jest zastąpienie nazwiska identyfikatorem, przy jednoczesnym przechowywaniu tabeli mapującej identyfikator na konkretną osobę w odrębnym systemie. Takie dane nadal są danymi osobowymi i nadal wymagają ochrony.

Anonimizacja zakłada z kolei, że identyfikacja osoby nie jest możliwa przy użyciu środków, których wykorzystania można racjonalnie oczekiwać – również poprzez połączenie zbioru z innymi informacjami. To znacznie wyższy próg niż proste usunięcie nazwiska czy zamiana kilku wartości na fikcyjne dane.

Warto pamiętać, że ochrona danych zawsze wiąże się z kompromisem. Im więcej szczegółów usuwamy lub uogólniamy, tym trudniej uzyskać precyzyjne analizy. Organizacja powinna więc nie tylko pytać, czy dane zostały technicznie ukryte, lecz przede wszystkim: czy po ich zestawieniu z dostępnym kontekstem można jeszcze rozpoznać osobę albo ujawnić wrażliwy fakt.

RODO i AI Act: dwie perspektywy

RODO i AI Act nie są konkurencyjnymi porządkami. Uzupełniają się, choć zadają różne pytania. RODO koncentruje się na danych osobowych: czy istnieje podstawa do ich przetwarzania, w jakim celu są wykorzystywane, czy zakres jest niezbędny oraz czy prawa osób, których dane dotyczą, są właściwie chronione. AI Act dodaje perspektywę ryzyka związanego z konkretnym zastosowaniem systemu AI i obowiązków dostawcy oraz podmiotu wykorzystującego taki system.

Dobrym przykładem jest rekrutacja. Jeżeli system AI analizuje CV kandydatów, organizacja musi przetwarzać dane zgodnie z RODO. Jeżeli jednak system wpływa na ocenę lub wybór kandydatów, może także podlegać wymaganiom przewidzianym dla systemów wysokiego ryzyka w AI Act. Dotyczą one m.in. zarządzania ryzykiem, jakości danych, dokumentacji oraz nadzoru człowieka. Bardzo dobrze zabezpieczony system może nadal prowadzić do niesprawiedliwych decyzji.

W praktyce należy zatem oceniać cały proces: skąd pochodzą dane, kto ma do nich dostęp, jak AI je wykorzystuje, na jakie decyzje wpływa system i kto odpowiada za jego działanie. Zgodność z jednym rozporządzeniem nie oznacza automatycznie zgodności z drugim. Warto prowadzić te analizy wspólnie, angażując osoby odpowiedzialne za technologię, cyberbezpieczeństwo, ochronę danych i dany proces biznesowy.

Zagrożenie może być wewnętrzne

Wyciekiem nie jest wyłącznie przesłanie danych na zewnątrz organizacji. Równie poważny problem powstaje wtedy, gdy asystent AI ujawnia informację niewłaściwemu użytkownikowi wewnątrz firmy.

Wyobraźmy sobie wspólnego asystenta połączonego z dokumentacją projektową, CRM, skrzynkami zarządu oraz systemami kadrowymi. Jeżeli nie przeniesiemy do niego zasad dostępu obowiązujących w systemach źródłowych, może on stać się pośrednikiem umożliwiającym pracownikowi uzyskanie informacji, których sam nie byłby uprawniony odczytać.

Pytanie użytkownika nie musi przy tym brzmieć: „Jakie wynagrodzenie otrzymuje konkretny pracownik?”. Może dotyczyć przyczyn wzrostu kosztów działu, harmonogramu pracy zespołu albo ryzyk w realizacji projektu. Jeżeli model wykorzysta do odpowiedzi dane płacowe, informacje o planowanej reorganizacji czy poufną korespondencję, naruszy granice dostępu nawet wtedy, gdy dane technicznie nie opuściły organizacji.

Dlatego kontrola uprawnień powinna działać w kontekście konkretnego użytkownika, zadania i źródła danych. Nie wystarczy dać modelowi AI dostęp do wszystkiego i oczekiwać, że będzie pamiętał, komu wolno przekazać daną informację. Te same zasady muszą obejmować pamięć rozmów, zapisane podsumowania oraz wyniki wcześniejszych analiz.

Prompt injection: zakładajmy nieufność

Szczególnym problemem dla agentów AI jest prompt injection, czyli próba wpłynięcia na ich zachowanie przez treść, którą same odczytują. Taka instrukcja może znajdować się w wiadomości e-mail, dokumencie klienta, pliku PDF, stronie internetowej lub rekordzie CRM. Nie musi wyglądać jak oczywisty atak. Może przypominać fragment instrukcji technicznej albo dodatkowe polecenie pozornie potrzebne do wykonania zadania.

Rozwijane są mechanizmy wykrywania podejrzanych treści, oznaczania danych pochodzących z niezaufanych źródeł czy uczenia modeli przestrzegania hierarchii instrukcji. Są one potrzebne, lecz nie zapewniają pełnej gwarancji bezpieczeństwa. W przeciwieństwie do parametryzowanych zapytań SQL, które są egzekwowane przez silnik bazy danych, samo oznaczenie fragmentu tekstu jako „danych” lub trening modelu nie tworzy nieprzekraczalnej bariery między poleceniem a treścią.

Najważniejsze jest zatem ograniczanie skutków ewentualnej manipulacji. Agent AI analizujący pocztę nie musi automatycznie mieć prawa do wysyłania wiadomości, zmiany uprawnień, publikowania plików czy pobierania całej bazy klientów. Jego dostęp powinien być możliwie wąski, a działania o istotnych skutkach powinny wymagać dodatkowej kontroli technicznej albo zatwierdzenia przez człowieka.

Trzeba też patrzeć szerzej niż na tekst odpowiedzi w oknie rozmowy. Dane można próbować wyprowadzić w parametrach zapytania do zewnętrznej usługi, w adresie URL, w metadanych pliku albo w automatycznie tworzonym dokumencie. Pojedyncze działanie może wyglądać niewinnie, ale cała sekwencja kroków może prowadzić do ujawnienia poufnych informacji.

3 priorytety w Gen AI na najbliższe miesiące

Organizacje, które chcą szerzej udostępniać pracownikom generatywną AI i agentów, powinny zacząć od trzech działań.

1. Uporządkować wiedzę o danych i uprawnieniach.

Firma powinna wiedzieć, jakie informacje są poufne, gdzie się znajdują, kto jest za nie odpowiedzialny i kto rzeczywiście potrzebuje do nich dostępu. Warto równolegle sprawdzić, z jakich narzędzi AI pracownicy już korzystają. Agent podłączony do firmowych zasobów może błyskawicznie ujawnić wieloletni bałagan w uprawnieniach.

2. Przygotować zatwierdzone, wygodne środowisko pracy z AI.

Sam zakaz korzystania z popularnych narzędzi zwykle nie usuwa potrzeby, która skłoniła pracownika do ich użycia. Jeżeli firmowe rozwiązanie będzie niedostępne, zbyt wolne albo niepraktyczne, pracownicy znajdą alternatywę. Potrzebne są zatem bezpieczne usługi, dostęp przez konta firmowe, jasne zasady dotyczące danych oraz ograniczone uprawnienia integracji. Rozsądnie jest zaczynać od niewielkiej liczby konkretnych zastosowań i stopniowo zwiększać autonomię agentów.

3. Szkolić ludzi i testować rzeczywiste scenariusze błędów oraz ataków.

Pracownicy powinni wiedzieć, jakie dane wolno przekazywać do danego narzędzia, kiedy konieczna jest weryfikacja wyniku i jak zgłaszać niepokojące zachowanie systemu. Organizacja powinna natomiast sprawdzać, czy agent oprze się próbie wydobycia cudzych danych, jak zareaguje na podejrzaną instrukcję ukrytą w dokumencie oraz czy można szybko odebrać mu dostęp. Znacznie więcej niż ogólna polityka bezpieczeństwa daje praktyczne przećwiczenie sytuacji, w której ochrona rzeczywiście ma zadziałać.

Agent AI nie powinien dostać kluczy do całej organizacji tylko dlatego, że potrafi efektywnie pomagać. Jego możliwości należy rozwijać stopniowo, proporcjonalnie do dojrzałości zabezpieczeń, jakości danych i zdolności firmy do kontroli skutków błędu. To właśnie połączenie użyteczności, ograniczonych uprawnień, monitoringu i odpowiedzialności pozwoli czerpać korzyści z AI bez niepotrzebnego zwiększania ryzyka.

Piotr Nyczyk, Zespół Analizy Prywatności i Zgodności Danych, Instytut Badawczy IDEAS