21 stycznia 2026 roku w Microsoft 365 coś po cichu poszło nie tak.
Copilot Chat — asystent AI Microsoftu wbudowany w Word, Excel, Outlook, PowerPoint i Teams — zaczął podsumowywać e-maile, do których dostęp był mu wyraźnie zakazany. E-maile przechowywane w folderach Elementy wysłane i Wersje robocze, oznaczone etykietami poufności, chronione przez polityki zapobiegania utracie danych (DLP) skonfigurowane przez Microsoft Purview.
Wszystkie zabezpieczenia były na miejscu. Copilot ominął je wszystkie.
Przez tygodnie asystent AI czytał i podsumowywał poufną korespondencję — tego rodzaju e-maile, które organizacje szczególnie chronią: dyskusje o fuzjach i przejęciach, komunikację prawną, sprawy HR, dane wrażliwe klientów. Problem, śledzony wewnętrznie jako CW1226324, nie został wykryty przez żaden automatyczny system monitoringu ani alertów. Został zauważony, ponieważ ktoś ręcznie zauważył, że Copilot wyświetla treści, których nie powinien.
Microsoft potwierdził przyczynę źródłową w doradztwie serwisowym: defekt na poziomie kodu pozwolił Copilotowi przetwarzać elementy w folderach Elementy wysłane i Wersje robocze pomimo ustawionych etykiet poufności. Poprawka zaczęła być wdrażana na początku lutego, ale Microsoft nie ujawnił, ile organizacji lub użytkowników zostało dotkniętych. Incydent pozostaje oznaczony jako „doradztwo".
Ta historia ma znaczenie daleko wykraczające poza cykl łatek Microsoftu. Ujawnia strukturalną wadę w sposobie, w jaki organizacje podchodzą dziś do zarządzania AI — a ta wada stanie się znacznie niebezpieczniejsza, gdy firmy przejdą od asystentów AI do autonomicznych agentów AI.
Co tak naprawdę się wydarzyło
Aby zrozumieć, dlaczego ten incydent jest znaczący, musisz zrozumieć, co powinno było mu zapobiec.
Microsoft 365 oferuje warstwowy system kontroli ochrony danych. Etykiety poufności pozwalają organizacjom klasyfikować dokumenty i e-maile według poziomu poufności — Publiczny, Wewnętrzny, Poufny, Ściśle poufny. Polityki zapobiegania utracie danych (DLP), zarządzane przez Microsoft Purview, egzekwują zasady dotyczące sposobu dostępu, udostępniania i przetwarzania oznaczonych treści. Prawidłowo skonfigurowana polityka DLP powinna uniemożliwić Copilotowi czytanie lub podsumowywanie jakichkolwiek treści z ograniczoną etykietą poufności.
Organizacje, które wdrożyły Microsoft 365 Copilot, zrobiły dokładnie to, co zalecają najlepsze praktyki. Sklasyfikowały swoją wrażliwą komunikację. Skonfigurowały reguły DLP. Ustanowiły ramy zarządzania, które sam Microsoft zaleca.
A potem błąd w kodzie Copilota po cichu to wszystko obejścił.
Asystent AI zindeksował e-maile w folderach Elementy wysłane i Wersje robocze — folderach, które rutynowo zawierają korespondencję firmową wysyłaną do stron zewnętrznych, komunikację prawną i wrażliwe negocjacje — i udostępnił ich zawartość przez zapytania Copilot Chat. Każdy w organizacji korzystający z funkcji czatu w „zakładce pracy" mógł nieumyślnie otrzymać podsumowania poufnych treści, które polityki miały konkretnie chronić przed przetwarzaniem przez AI.
Co czyni to szczególnie niepokojącym, to co dokumentacja Microsoftu ujawnia o szerszym ograniczeniu. Nawet gdy etykiety poufności działają poprawnie w aplikacjach Office, Microsoft przyznaje, że chronione treści mogą nadal być dostępne dla Copilota w innych kontekstach, w tym w Teams i Copilot Chat. Granica zarządzania nie jest tak szczelna, jak zakłada większość administratorów.
Większy problem: kontrole po stronie dostawcy to nie zarządzanie
Obejście DLP przez Copilota to nie izolowany błąd. To symptom fundamentalnego problemu architektonicznego, który dotyka każdą organizację korzystającą dziś z narzędzi AI.
Oto schemat:
- Firma wdraża narzędzie AI (Copilot, ChatGPT Enterprise, niestandardowego agenta zbudowanego na GPT-4, Claude lub Gemini).
- Dostawca AI zapewnia wbudowane kontrole — etykiety poufności, polityki DLP, zakres dostępu, filtrowanie treści.
- Firma konfiguruje te kontrole i zakłada, że ma zarządzanie AI na miejscu.
- AI po cichu narusza kontrole. Nikt nie wie, aż szkoda jest zrobiona.
Kluczowy problem polega na tym, że kontrole zarządzania i system AI żyją w tym samym ekosystemie dostawcy. Podmiot zarządzany i podmiot zarządzający to ten sam byt. Nie ma niezależnej weryfikacji. Nie ma zewnętrznej ścieżki audytu. Nie ma systemu znajdującego się poza stosem dostawcy AI, który potwierdza, czy AI faktycznie przestrzegała skonfigurowanych polityk.
To odpowiednik proszenia kogoś o ocenianie własnego egzaminu. Działa, dopóki nie przestanie — a gdy zawodzi, nie masz sposobu, żeby się dowiedzieć.
Obejście DLP Copilota Microsoftu trwało tygodniami niewykryte. Nie dlatego, że organizacja nie skonfigurowała zabezpieczeń, ale dlatego, że żaden niezależny system nie obserwował, czy te zabezpieczenia są faktycznie egzekwowane.
A teraz pomnóż to przez każdego agenta AI w Twojej organizacji
Incydent z Copilotem dotyczył asystenta AI pierwszej strony od najbardziej dojrzałego dostawcy oprogramowania korporacyjnego na świecie. Ale krajobraz AI wewnątrz firm jest znacznie bardziej złożony — i znacznie mniej kontrolowany — niż pojedynczy produkt Microsoftu.
Zastanów się, co dzieje się teraz w organizacjach:
Pracownicy używają dziesiątek narzędzi AI bez nadzoru. Badania pokazują, że 76% zespołów bezpieczeństwa szacuje, że pracownicy używają narzędzi AI takich jak ChatGPT i GitHub Copilot bez formalnego zatwierdzenia. Pracownicy w ponad 90% firm zgłaszają używanie osobistych narzędzi AI do zadań służbowych. Każda z tych interakcji to niekontrolowany przepływ danych — dane osobowe, kod źródłowy, strategia biznesowa, informacje o klientach wklejane do systemów, nad którymi organizacja nie ma widoczności ani zarządzania.
Zespoły budują agentów AI z bezpośrednim dostępem do wrażliwych systemów. Firmy wdrażają autonomicznych agentów zbudowanych na GPT, Claude, Gemini i modelach open-source. Ci agenci są podłączeni do CRM-ów, dokumentacji wewnętrznej, systemów e-mail, baz danych i danych klientów. Wysyłają wiadomości, wykonują wywołania API, realizują przepływy pracy i przetwarzają wrażliwe dane — często konfigurowane przez pracowników nietechnicznych, często bez wiedzy zespołów IT czy bezpieczeństwa.
Incydenty już się zdarzają. To nie jest ryzyko teoretyczne:
-
Zoho (listopad 2025): Agent AI przypadkowo ujawnił szczegóły przejęcia zewnętrznemu założycielowi startupu. Agent wysłał następnie automatyczny e-mail z przeprosinami do CEO Zoho, Sridhara Vembu, który publicznie udostępnił incydent. Nikt nie włamywał się. Agent po prostu przetworzył dane i podjął działanie bez zdefiniowania, czym mógł, a czym nie mógł się dzielić.
-
Salesforce Agentforce (wrzesień 2025): Badacze bezpieczeństwa zademonstrowali podatność CVSS 9.4, która pozwalała atakującemu wyeksfiltrować całe rekordy CRM — imiona klientów, e-maile, numery telefonów, informacje o transakcjach — rejestrując domenę za 5 dolarów i wykonując atak prompt injection na wdrożeniu Agentforce.
-
Microsoft Copilot — atak Reprompt (styczeń 2026): Badacze Varonis odkryli atak jednym kliknięciem, który mógł po cichu wyeksfiltrować dane osobowe z Copilota. Atak działał, ponieważ zabezpieczenia przed wyciekiem danych Copilota dotyczyły tylko początkowego żądania — samo poinstruowanie Copilota, aby wykonał każdą akcję dwukrotnie, powodowało, że druga próba omijała zabezpieczenia.
-
Microsoft Copilot — EchoLeak (czerwiec 2025): Aim Security ujawniło podatność zero-click (CVE-2025-32711, CVSS 9.3), która pozwalała atakującym na wyeksfiltrowanie wrażliwych danych z kontekstu Microsoft 365 Copilot bez jakiejkolwiek interakcji użytkownika. LLM został skutecznie obrócony przeciwko sobie, aby zidentyfikować i wyciekać najbardziej wrażliwe informacje w jego zasięgu.
Każdy z tych incydentów ma tę samą przyczynę źródłową: systemy AI działające z szerokim dostępem do danych i nieadekwatnym niezależnym zarządzaniem.
Dlaczego to problem zarządzania, a nie problem bezpieczeństwa
Instynkt w większości organizacji to traktowanie incydentów z danymi AI jako problemów cyberbezpieczeństwa. Załataj podatność. Zaktualizuj politykę. Idź dalej.
Ale obejście DLP Copilota — i szerszy wzorzec niepowodzeń w zarządzaniu AI — nie da się rozwiązać łataniem. Są strukturalne.
Tradycyjne narzędzia bezpieczeństwa nie zostały zaprojektowane dla AI. DLP, SIEM i ochrona punktów końcowych zostały zbudowane do monitorowania sposobu, w jaki ludzie uzyskują dostęp do danych i je przenoszą. Rozumieją transfery plików, załączniki e-mail i ruch sieciowy. Nie rozumieją interakcji prompt-odpowiedź, zawartości okna kontekstowego, łańcuchów użycia narzędzi w agencie ani różnicy między asystentem AI podsumowującym poufny e-mail na prośbę użytkownika a asystentem AI podsumowującym go z powodu błędu w kodzie.
Kontrole po stronie dostawcy tworzą fałszywe poczucie bezpieczeństwa. Gdy Microsoft zapewnia etykiety poufności i polityki DLP dla Copilota, organizacje rozsądnie zakładają, że te kontrole działają. Gdy nie działają — jak w incydencie CW1226324 — nie ma planu awaryjnego. Żaden niezależny system nie sygnalizuje naruszenia. Luka między „polityką skonfigurowaną" a „polityką egzekwowaną" jest niewidoczna.
Agenci AI wprowadzają fundamentalnie nową powierzchnię zarządzania. Pracownik używający ChatGPT do redagowania e-maila to jeden przepływ danych do monitorowania. Autonomiczny agent podłączony do Twojego CRM, wykonujący wywołania API, realizujący wieloetapowe przepływy pracy i wysyłający komunikację w imieniu Twojej organizacji to zupełnie inne wyzwanie zarządzania. Agenci działają bez nadzoru człowieka w pętli. Łączą akcje ze sobą. Uzyskują dostęp do danych w różnych systemach. I robią to wszystko z prędkością i skalą, które uniemożliwiają ręczny nadzór.
Organizacja wdrażająca ponosi odpowiedzialność. To punkt, który ma największe znaczenie dla europejskich firm. Zgodnie z EU AI Act odpowiedzialność spoczywa na wdrażającym — organizacji, która wprowadza system AI do użytku — a nie na dostawcy, który go zbudował. Jeśli Microsoft Copilot podsumowuje poufne e-maile zawierające dane osobowe szczególnej kategorii (informacje zdrowotne, sprawy prawne, dane HR), organizacja wdrażająca Copilota jest odpowiedzialna za naruszenie RODO. Nie możesz powiedzieć organowi ochrony danych, że Twoje etykiety poufności były poprawnie skonfigurowane, gdy AI, którą wybrałeś do wdrożenia, je zignorowała.
Kary EU AI Act są znaczne: do 35 milionów euro lub 7% globalnego rocznego obrotu. A regulacja wymaga od organizacji prowadzenia inwentarzy systemów AI, przeprowadzania ocen ryzyka, zapewnienia nadzoru ludzkiego i wykazywania zgodności przez dokumentację i ścieżki audytu.
Nic z tego nie jest osiągalne, jeśli Twoje kontrole zarządzania żyją w ekosystemie dostawcy AI.
Jak naprawdę wygląda niezależne zarządzanie AI
Lekcja z incydentu Copilota jest jasna: zarządzanie AI musi być niezależną warstwą, która znajduje się poza stosem dostawcy AI.
To oznacza:
Scentralizowany rejestr systemów AI. Każde narzędzie AI i autonomiczny agent działający w organizacji — czy to Microsoft Copilot, subskrypcja ChatGPT, niestandardowy agent zbudowany na Claude, czy wewnętrzne wdrożenie modelu — musi być zinwentaryzowany w jednym systemie ewidencji. Każdy system powinien mieć wyznaczonego właściciela biznesowego, zdefiniowany cel, klasyfikację ryzyka i udokumentowane uprawnienia dostępu do danych. Jeśli nie wiesz, jakie systemy AI działają w Twojej organizacji, nie możesz nimi zarządzać.
Niezależne egzekwowanie polityk. Polityki regulujące, do jakich danych systemy AI mogą mieć dostęp, jakie działania mogą podejmować agenci i jakie zatwierdzenia są wymagane, powinny być oceniane przez system odrębny od zarządzanych narzędzi AI. Gdy etykieta DLP zawodzi w Copilocie, niezależny silnik polityk powinien wykryć naruszenie — a nie polegać na tym, że Copilot sam się pilnuje.
Ciągłe monitorowanie z zewnętrzną ścieżką audytu. Każda interakcja z AI — czy to pracownik wklejający treść do narzędzia AI, czy autonomiczny agent wykonujący wywołanie API — powinna być rejestrowana w niezmiennej, niezależnej od dostawcy ścieżce audytu. Gdy regulator lub audytor zapyta „do jakich danych miały dostęp Wasze systemy AI w styczniu?", powinieneś móc odpowiedzieć dowodami, które nie pochodzą z własnych logów dostawcy AI.
Zarządzanie obejmujące zarówno ludzi, jak i agentów. Różnica między pracownikiem używającym ChatGPT a autonomicznym agentem wywołującym API GPT-4 jest operacyjnie różna, ale równoważna pod względem zarządzania. Obie to interakcje AI, które obejmują przepływy danych, wymagania zgodności z politykami i odpowiedzialność. Platforma zarządzania musi traktować obie jako pełnoprawnych uczestników w tym samym ramach polityk.
Gotowe szablony zgodności. Dla europejskich firm działających w ramach EU AI Act, RODO i NIS2, narzędzia zarządzania powinny zapewniać gotowe szablony polityk, które mapują się bezpośrednio na wymagania regulacyjne — a nie zmuszać organizacje do budowania ram zgodności od zera.
Trzy pytania, na które każda organizacja powinna odpowiedzieć dziś
Przed następnym incydentem w stylu Copilota każda organizacja — niezależnie od wielkości — powinna umieć odpowiedzieć na trzy pytania:
1. Jakie systemy AI i agenci działają w Twojej organizacji?
Nie tylko te, które IT zatwierdziło. Te, na które pracownicy zarejestrowali się prywatnymi e-mailami. Agenci, których ktoś z marketingu zbudował w weekend. Rozmowy z ChatGPT odbywające się na urządzeniach osobistych. Narzędzia MCP, z którymi eksperymentują Twoi deweloperzy. Wszystkie.
2. Jakie dane przepływają do każdego systemu AI i czy to jest zgodne z polityką?
Dla każdego narzędzia AI i agenta, czy potrafisz zidentyfikować, do jakich kategorii danych ma dostęp? Czy przetwarza dane osobowe? Dane klientów? Informacje finansowe? Kod źródłowy? Czy te dane przepływają do systemu, który spełnia Twoje wymagania regulacyjne dotyczące rezydencji danych, umów o przetwarzanie i standardów bezpieczeństwa?
3. Kto jest odpowiedzialny za każdy system AI?
Zgodnie z EU AI Act każdy system AI w zakresie potrzebuje wyznaczonej odpowiedzialnej osoby w organizacji. Nie dostawca. Nie „IT" jako dział. Konkretna osoba, która jest właścicielem klasyfikacji ryzyka, konfiguracji polityk i obowiązków zgodności dla tego systemu.
Jeśli nie potrafisz odpowiedzieć na wszystkie trzy pytania z pewnością, nie masz luki w zarządzaniu AI. Masz martwy punkt. I jak pokazał incydent z Copilotem, martwe punkty nie ogłaszają się same — ujawniają się jako incydenty, ustalenia regulacyjne i utrata zaufania.
Okno jest teraz
Obejście DLP Copilota nie jest ostatnim incydentem tego rodzaju. Dr Ilia Kolochenko, CEO ImmuniWeb i członek Europolu, ostrzegł, że podobne incydenty prawdopodobnie gwałtownie wzrosną w 2026 roku, potencjalnie stając się najczęstszym rodzajem incydentu bezpieczeństwa w organizacjach wszystkich rozmiarów. Powód jest prosty: organizacje adoptują AI szybciej, niż budują infrastrukturę zarządzania do jej obsługi, a tradycyjne zabezpieczenia jak DLP nigdy nie zostały zaprojektowane do monitorowania sposobu, w jaki systemy AI uzyskują dostęp, interpretują i przepakowują wrażliwe dane.
Firmy, które zbudują niezależne zarządzanie AI teraz — przed incydentem, przed audytem, przed zapytaniem regulacyjnym — będą tymi, które utrzymają zaufanie klientów, wykażą zgodność regulatorom i wdrożą AI z pewnością.
Te, które będą czekać, nauczą się tej samej lekcji, co klienci Microsoftu w styczniu: skonfigurowane kontrole to nie egzekwowane kontrole i żaden dostawca nie będzie zarządzał swoją własną AI w Twoim imieniu.
PanelSec buduje niezależną platformę zarządzania AI dla europejskich firm średniej wielkości. Pomagamy organizacjom inwentaryzować, kontrolować i audytować całe użycie AI — zarówno przez pracowników, jak i autonomicznych agentów — zaprojektowaną specjalnie dla zgodności z EU AI Act, RODO i NIS2.
Zespół PanelSec
Built in Europe · Hosted in Germany · 2026-02-22