7 błędów w prywatności danych agentów AI, które po cichu wyciekają dane Twojej firmy (i jak ich uniknąć)

Większość wycieków danych przez agentów AI nie wynika z tego, że model po cichu zapamiętuje Twoją firmę. Wynikają z błędów w konfiguracji i architekturze, które można nazwać i naprawić. Te najważniejsze to: działanie na koncie w wersji konsumenckiej, którego ustawienia domyślne trenują na Twoich danych wejściowych, pozwolenie agentowi na dziedziczenie szerokich uprawnień jednej osoby, podłączenie agenta dostępnego publicznie do systemów wewnętrznych oraz pozostawienie nietkniętej "śmiertelnej triady" (dane prywatne, niezaufana treść i zewnętrzna ścieżka wysyłki), tak że pojedyncze wstrzyknięcie promptu może odczytać Twoje dane i wysłać je pocztą. Dokładnie tak wzorzec ten zadziałał, gdy EchoLeak (CVE-2025-32711) ujawnił wrażliwe dane przez Microsoft 365 Copilot z poziomu spreparowanego e-maila, bez żadnego kliknięcia ze strony użytkownika. Rozwiązania nie są egzotyczne, a niemal wszystkie z nich to decyzje podejmowane przed startem agenta, a nie lista kontrolna wręczona Ci po tym, jak coś wycieknie.

To lista, którą przepracowujemy, zanim wstawimy zbudowanego przez nas agenta do stosu technologicznego innej firmy, napisana tak, aby nietechniczny właściciel mógł wypatrzeć te same błędy we własnym wdrożeniu lub u dostawcy. Jeśli wolisz, żebyśmy utrzymali tę linię tam, gdzie powinna być w Twoim przypadku, zobacz, jak prowadzimy odpowiedzialne zarządzanie AI i ryzykiem. Wszystko poniżej jest Twoje do wykorzystania, niezależnie od wyboru.

Najpierw rozróżnienie, które zaciera niemal każdy artykuł na ten temat, bo pomyłka w tym miejscu to błąd zerowy. Istnieją dwa zupełnie różne sposoby, w jakie dane wyciekają przez agenta, i mają one zupełnie różne rozwiązania:

• Obsługa danych przez dostawcę. Czy dostawca modelu przechowuje lub trenuje na Twoich danych wejściowych? To kontrakt, który podpisujesz, oraz poziom konta, który wybierasz. Rozwiązuje się to warunkami umowy i konfiguracją.
• Eksfiltracja w czasie działania. Czy agenta można w momencie działania nakłonić do wysłania Twoich danych tam, gdzie nie powinny trafić? To rozwiązuje się architekturą, a nie kontraktem.

Liczby z badań pokazują, że nabywcy odczuwają to, nawet gdy nie potrafią tego nazwać. W badaniu Cloudera obejmującym blisko 1500 wyższych liderów IT z 14 krajów 96% planuje rozszerzyć użycie agentów AI w nadchodzącym roku, a mimo to 53% (ponad połowa) wskazuje prywatność danych jako główną przeszkodę w adopcji. Siedem błędów poniżej to miejsca, w których ten lęk staje się prawdziwym wyciekiem i w których mieszka rozwiązanie.

Błąd 1: uruchamianie produkcyjnych agentów na kontach w wersji konsumenckiej

To najtańszy do popełnienia i najłatwiejszy do naprawienia błąd. Ktoś podłącza przepływ pracy do osobistego konta ChatGPT lub konsumenckiego Gemini, bo jest już dostępne, i teraz dane Twojej firmy są regulowane warunkami konsumenckimi, które nigdy nie były dla nich przeznaczone.

Różnica między wersją konsumencką a korporacyjną jest wyraźna. Po stronie korporacyjnej wzorzec jest spójny u wszystkich dostawców: domyślny brak trenowania na Twoich danych, krótkie okno przechowywania na potrzeby monitorowania nadużyć i mocniejsze opcje na żądanie. API OpenAI przechowuje dane przez 30 dni na potrzeby monitorowania nadużyć, a następnie je usuwa, i domyślnie na nich nie trenuje. Od 14 września 2025 Anthropic skrócił okres przechowywania logów API z 30 dni do 7 dni, a dane wejściowe i wyjściowe API nigdy nie są używane do trenowania. Google Vertex AI (poziom korporacyjny) jest konfigurowalny bez wykorzystywania danych do trenowania. Po stronie konsumenckiej ustawienia domyślne są odwrotne: konsumencki ChatGPT przechowuje rozmowy bezterminowo, dopóki ich nie usuniesz, a konsumencki Gemini przechowuje dane nawet do 36 miesięcy i może je wykorzystywać do ulepszania produktów.

Rozwiązanie: umieść każdego produkcyjnego agenta na korporacyjnym API lub koncie biznesowym, nigdy na osobistym logowaniu. Technologia jest identyczna. Warunki nie są, a to właśnie warunki stanowią całą różnicę między danymi, które pozostają pod kontrolą, a danymi, które po cichu stają się materiałem treningowym.

Błąd 2: zbyt szerokie uprawnienia dziedziczone przez agenta

Najczęstszy wyciek w czasie działania nie jest wyrafinowany. Agent dostaje dostęp jednego pracownika lub, co gorsza, klucz administratora, więc technicznie może zobaczyć wszystko to, co widzi ta osoba. Następnie zadaje mu się pytanie lub nakłania go do takiego, które sięga daleko poza jego zadanie.

Microsoft Cloud Adoption Framework formułuje tę zasadę wprost: "Przyznawaj agentom dostęp tylko do konkretnych źródeł danych wymaganych przez ich funkcję. Nie udostępniaj szerokiego dostępu do wszystkich danych organizacji". Agent wsparcia nie potrzebuje Twojego systemu płac. Agent planujący spotkania nie potrzebuje bazy klientów. Gdy agent działa w imieniu danej osoby, powinien dziedziczyć jej uprawnienia, bezpiecznie przekazując jej tożsamość, tak aby agent helpdesku pokazywał pracownikowi tylko jego własną kartotekę HR, a nie wszystkich.

Rozwiązanie: nadaj każdemu agentowi własną tożsamość o zakresie najmniejszych uprawnień i spraw, by dziedziczył uprawnienia działającego użytkownika, zamiast nosić stały, nadmiarowy zestaw. Test jest prosty. Jeśli jutro agent zostanie oszukany, szkoda jest ograniczona przez wąski zakres, który mu przyznano, a nie przez wszystko, co mogłoby osiągnąć jedno nadmiernie uprawnione konto.

Błąd 3: agenci dostępni publicznie podłączeni do danych wewnętrznych

Chatbot na Twojej stronie i agent piszący wewnętrzne raporty to dwa różne światy bezpieczeństwa, a wyciek następuje w chwili, gdy ktoś pozwala im współdzielić backend. Agent publiczny przyjmuje dane wejściowe od każdego w internecie. Jeśli ten sam agent może też odpytywać wewnętrzne dane biznesowe, zbudowałeś drzwi z publicznej sieci prosto do swoich prywatnych systemów.

Framework Microsoftu wyznacza tu najtwardszą granicę: "Agenci dostępni publicznie nie mogą mieć dostępu do wewnętrznych danych biznesowych". Trzymaj dane poufne i publiczne oddzielone fizyczną lub logiczną granicą (ich przykład używa osobnych grup zarządzania "corp" i "online"). Chodzi o to, że granica jest strukturalna, a nie nadzieją, że prompt się utrzyma.

Rozwiązanie: postaw prawdziwą granicę między agentami przyjmującymi niezaufane dane publiczne a agentami dotykającymi danych poufnych. Jeśli pojedynczy agent naprawdę musi robić jedno i drugie, jest to najwyższego ryzyka projekt, jaki możesz wybrać, i wymaga on kontroli przerywających triadę z kolejnych błędów, a nie tylko starannego promptu systemowego.

Błąd 4: ignorowanie śmiertelnej triady

To błąd, który zamienia pierwsze trzy w rzeczywistą eksfiltrację. Simon Willison, niezależny ekspert, który ukuł termin "wstrzyknięcie promptu", nazwał "śmiertelną triadą" dla agentów AI: trzy warunki, które połączone razem pozwalają pojedynczej wstrzykniętej instrukcji ukraść Twoje dane.

Gdy wszystkie trzy są obecne, atakujący ukrywa instrukcję wewnątrz niezaufanej treści. Model, słowami Willisona, "z radością wykona każdą instrukcję, która do niego dotrze, niezależnie od tego, czy pochodzi od jego operatora, czy z jakiegoś innego źródła". Odczytuje Twoje dane prywatne i wysyła je na zewnątrz, a nic w prompcie nie kazało mu nie ufać temu e-mailowi.

Część bez ogródek i powód, dla którego jest to architektura, a nie problem inżynierii promptów: "wciąż nie wiemy, jak w 100% niezawodnie temu zapobiec". Udokumentowane exploity dotknęły Microsoft 365 Copilot, serwer MCP GitHuba i GitLab Duo. W ciągu jednego tygodnia w styczniu 2026 ujawniono podatności na pośrednie wstrzyknięcie promptu w czterech narzędziach produktywności AI, wszystkie według tego samego wzorca triady.

Rozwiązanie: odetnij jedną nogę. Zablokuj zewnętrzną ścieżkę wysyłki, aby skradzione dane nie miały gdzie pójść, albo nigdy nie pozwól, by agent odczytujący niezaufaną treść miał w tym samym kontekście również dostęp do danych prywatnych. Nie musisz wygrywać niemożliwej do wygrania walki z wyłapywaniem każdego wstrzyknięcia. Musisz upewnić się, że nawet udane wstrzyknięcie nie ma drogi na zewnątrz.

Błąd 5: traktowanie EchoLeak jako cudzego problemu

Warto nazwać jeden rzeczywisty incydent, bo "śmiertelna triada" brzmi abstrakcyjnie, dopóki nie zobaczysz jej w działaniu. EchoLeak (CVE-2025-32711) był atakiem typu zero-click na Microsoft 365 Copilot. Atakujący wysłał spreparowany e-mail. Copilot, wykonując swoją normalną pracę, przetworzył ten e-mail (niezaufana treść), miał dostęp do wewnętrznych danych użytkownika (dane prywatne) i miał sposób na wysłanie informacji na zewnątrz (komunikacja zewnętrzna). Ukryta instrukcja dokończyła ujawnienie wrażliwych danych całkowicie bez interakcji użytkownika. Nikt w nic nie kliknął.

Błędem tutaj jest założenie, że wyciek wymaga nieostrożnego pracownika. EchoLeak nie wymagał żadnego. Obroną, która miała znaczenie, nie było "szkolenie personelu w wykrywaniu phishingu", bo nie było niczego, co człowiek mógłby wypatrzeć. Obroną była architektura: agent, który nie może jednocześnie odczytywać treści kontrolowanej przez atakującego i dokonywać eksfiltracji, nie może zostać w ten sposób obrócony przeciwko Tobie.

Rozwiązanie: załóż, że zero-click to model zagrożenia, a nie wyjątek. Jeśli Twój agent odczytuje cokolwiek, na co osoba z zewnątrz może wpłynąć (e-mail, treść internetową, przesłane pliki, zgłoszenia), i może też wysyłać dane na zewnątrz, masz dziurę w kształcie EchoLeak, dopóki nie zamkniesz jednej z tych dwóch możliwości lub nie ogrodzisz na twardo ścieżki wysyłki.

Błąd 6: brak granicy rezydencji lub przechowywania danych

Niektóre wycieki nie są dramatycznymi eksfiltracjami, lecz powolnym dryfem. Dane lądują przechowywane w regionie, na który nigdy się nie zgodziłeś, albo zalegają w logach dłużej, niż pozwala Twoja polityka, po prostu dlatego, że nikt nie ustawił granicy. Framework Microsoftu wymienia to jako podstawowy element zarządzania: zidentyfikuj lokalizację każdego źródła danych, środowiska uruchomieniowego agenta i miejsca przechowywania wyników, trzymaj dane w regionach lub lokalnie zgodnie z polityką rezydencji i utrzymuj je zaszyfrowane w spoczynku.

Pocieszająca wiadomość, której niemal żaden artykuł nie podaje wprost, to jak wiele można ustalić na sztywno. Korporacyjny wzorzec u wszystkich dostawców to domyślny brak trenowania plus krótkie okno przechowywania plus mocniejsze gwarancje na żądanie. Anthropic oferuje kwalifikującym się przedsiębiorstwom umowę o zerowym przechowywaniu danych (Zero Data Retention, ZDR), w ramach której dane wejściowe i wyjściowe nie są przechowywane dłużej, niż jest to potrzebne do kontroli pod kątem nadużyć. OpenAI oferuje ZDR poprzez wynegocjowaną umowę oraz rezydencję danych. Oba pozwalają wybrać, gdzie znajdują się dane. Samodzielne hostowanie otwartego modelu (na przykład z Ollama) utrzymuje dane w pełni lokalnie, z zerowym przechowywaniem przez podmioty trzecie.

Rozwiązanie: zdecyduj i udokumentuj granicę przed startem. Który region trzyma dane, jak długo żyją logi, czy potrzebujesz ZDR i czy wrażliwe pobieranie danych powinno działać we własnym VPC lub lokalnie. ZDR jest zwykle dostępne tylko dla API i negocjowane, i nie obejmuje automatycznie każdego produktu, jeśli go nie dodasz, więc szczegół ma znaczenie.

Błąd 7: traktowanie prywatności jako listy kontrolnej, którą się przekazuje

Ostatni błąd jest strukturalny. Większość wskazówek, w tym znakomity framework Microsoftu, zakłada, że samodzielnie zbudujesz agenta i będziesz nim zarządzać, więc wręcza Ci liczący 3000 słów stos tożsamości Entra, etykiet Purview i grup zarządzania. To właściwa odpowiedź dla dużego zespołu IT. Dla większości firm jest to lista kontrolna, której nikt nie ma czasu ani specjalistycznych umiejętności w pełni wdrożyć, więc wdraża się ją połowicznie, a luki to dokładnie te miejsca, w których wyciekają dane.

Błędem jest traktowanie tych kontroli jako dokumentacji zamiast jako architektury, za którą ktoś odpowiada od początku do końca. Lista kontrolna wymieniająca "izoluj dane poufne" i "ogranicz integracje zewnętrzne do zaufanych serwerów MCP" jest tylko tak dobra, jak osoba, która to wszystko spina, weryfikuje każdą komunikację zewnętrzną i przygotowuje plan reagowania na incydenty, by szybko wyłączyć agenta, gdy coś pójdzie nie tak.

Rozwiązanie: upewnij się, że jedna strona faktycznie odpowiada za granicę, a nie tylko za dokument. Albo budujesz wewnętrzną zdolność do wdrożenia i utrzymania pełnego stosu, albo masz operatora, który architektonicznie eliminuje te tryby awarii i nimi zarządza, z opublikowaną granicą, na którą możesz wskazać. Złym środkiem jest lista kontroli i nikt, kto odpowiadałby za to, że się utrzymują.

Jak układa się siedem błędów i rozwiązań

Oto wszystkie siedem w jednym miejscu, posortowane według tego, czy rozwiązaniem jest kontrakt, który podpisujesz, czy architektura, którą budujesz. Ten podział to najszybszy sposób, by wiedzieć, który zespół odpowiada za każdy z nich.

Zwróć uwagę, że tylko dwa z siedmiu rozwiązuje się kontraktem. Pozostałe pięć to architektura i odpowiedzialność, czyli ta część, której PDF z najlepszymi praktykami nie zrobi za Ciebie. To także uczciwy powód, dla którego autorytatywne źródła zostawiają lukę: mówią Ci, co zbudować, a nie kto zbuduje to poprawnie wewnątrz Twoich konkretnych systemów.

Co naprawdę nigdy nie opuszcza firmy, gdy granica jest zbudowana właściwie

Łatwo przeczytać siedem błędów i wywnioskować, że agenci AI to pole minowe dla prywatności. Nie są, gdy linię wytyczono celowo. Na warunkach korporacyjnych Twoje dane wejściowe nie są danymi treningowymi, a przechowywanie to dni, a nie wieczność (7 dla API Anthropic, 30 dla OpenAI, potem usunięcie). Przy ZDR nie są przechowywane dłużej niż na potrzeby kontroli nadużyć. Przy ustalonej na sztywno rezydencji danych pozostają w Twoim regionie. Przy pobieraniu w VPC lub lokalnie wrażliwe dane w ogóle nie opuszczają Twojego obwodu. Przy maskowaniu na granicy pola, które nigdy nie powinny podróżować, są usuwane, zanim cokolwiek zostanie wysłane. Przy zakresie najmniejszych uprawnień dziedziczącym prawa użytkownika agent może sięgnąć tylko po to, do czego działająca osoba i tak miała już dostęp.

To konkretna, możliwa do obrony granica, a umiejętność jej jasnego sformułowania to cały sens. Niebezpieczeństwem nigdy nie był model po cichu wchłaniający Twoją firmę. To siedem powyższych błędów w konfiguracji i architekturze, z których każdemu można zapobiec, zanim pierwszy agent ruszy.

To praca, którą wykonujemy wewnątrz stosów technologicznych innych firm: wybór warunków, ustawianie zakresu tożsamości, izolowanie publicznego od poufnego, przerywanie triady i odpowiadanie za granicę, by się utrzymała. Jeśli chcesz, by te błędy zostały architektonicznie wyeliminowane z Twoich agentów, zanim dotkną czegokolwiek rzeczywistego, umów się na bezpłatną konsultację poniżej, a wspólnie nakreślimy Twoją granicę.