Microsoft 365 Copilot czytał poufne e-maile: bug CW1226324, DLP i mit suwerennej chmury

Microsoft 365 Copilot czytał poufne e-maile przez około trzydzieści dni, wbrew politykom DLP skonfigurowanym specjalnie po to, by temu zapobiec. Sprawa, zarejestrowana wewnętrznie przez Microsoft jako bug CW1226324, była aktywna od 21 stycznia do około 20 lutego 2026 roku. Łatka wdrażana była stopniowo od 3 lutego 2026. Wśród dotkniętych organizacji potwierdzono NHS w Anglii oraz Parlament Europejski, który zablokował narzędzia AI; rzeczywista skala pozostaje nieznana, ponieważ Microsoft nie ujawnił liczby poszkodowanych. Warto pamiętać o kontekście: NHS korzysta z ponad 50 000 licencji Copilot na mocy umowy oferowanej „bez dodatkowych kosztów".

Co się właściwie wydarzyło

21 stycznia 2026 roku pierwsi użytkownicy enterprise zaczęli zgłaszać anomalne zachowanie Copilota. Microsoft zarejestrował problem wewnętrznie jako CW1226324, jednak opis był celowo mało alarmujący: „issue with the Microsoft 365 Copilot chat improperly summarizing email messages" — a nie „AI czyta wasze poufne dane". Reakcja Microsoftu sprowadziła się do oświadczenia PR: „This did not provide anyone access to information they weren't already authorized to see". Zdanie to jest technicznie prawdziwe w wąskim sensie, ale ignoruje fakt, że polityki DLP zostały skonfigurowane właśnie po to, by ograniczyć dostęp Copilota do danych, do których użytkownicy formalnie mają uprawnienia. Celem DLP jest bowiem nie tylko kontrola dostępu, lecz także kontrola kontekstu przetwarzania.

Trzydzieści dni milczenia układa się w wymowną oś czasu. 21 stycznia 2026 pojawiły się pierwsze raporty użytkowników enterprise. Przez kolejne dziesięć dni, do 31 stycznia, nie było żadnej publicznej komunikacji ze strony Microsoftu. 3 lutego 2026 Microsoft utworzył wewnętrzny alert CW1226324. Dopiero 17 lutego BleepingComputer opublikował artykuł — pierwszą publiczną informację o sprawie. 19 lutego nastąpiła lawinowa reakcja mediów: BBC News, PC Mag, The Stack i CXToday. Tego samego dnia Microsoft wydał oświadczenie PR minimalizujące incydent, a 20 lutego rozpoczął finalizację wdrożenia łatki.

Dlaczego incydent w ogóle się wydarzył

U podstaw sprawy leży struktura biznesowa, w której NHS otrzymał Copilota bez gotowości pełnych zabezpieczeń DLP. Microsoft oferował NHS Copilota „bez dodatkowych kosztów", co jest klasycznym mechanizmem vendor lock-in: darmowe wdrożenie generuje zależność operacyjną, po której komercyjne przejście na pełne funkcjonalności staje się znacznie łatwiejsze. Im szybciej NHS uzależni się od Copilota, tym silniejsza pozycja Microsoftu w przetargach NHS Digital na lata 2026–2030.

Dlaczego NHS akceptuje narzędzia bez dojrzałych zabezpieczeń? Ponieważ działa pod ogromną presją finansową — Wielka Brytania szuka oszczędności w systemie opieki zdrowotnej, a 400 000 godzin oszczędności miesięcznie to wartość ekonomiczna trudna do zignorowania. Presja budżetowa przeważa nad cyberhigieną — to znany wzorzec w instytucjach publicznych. Rząd UK (Department of Health and Social Care) aktywnie promował Microsoft Copilot jako narzędzie transformacji NHS, opierając się na raporcie pilotażowym finansowanym przez… Microsoft. Recenzja narzędzia przez podmiot finansujący badanie nie jest niezależną oceną bezpieczeństwa. Rząd UK jest jednocześnie regulatorem danych zdrowotnych (poprzez ICO) i promotorem adopcji narzędzia, które naruszyło ochronę tych danych — to klasyczny konflikt interesów w zarządzaniu danymi sektora publicznego.

Microsoft wiedział o problemie wcześniej

Czy Microsoft wiedział o strukturalnym problemie niekonsekwentnych sensitivity labels przed incydentem? Tak. Własna dokumentacja Microsoft Support zawiera stronę „Known issues with sensitivity labels in Office" — regularnie aktualizowaną listę znanych problemów z tym systemem. Bug CW1226324 nie był pierwszą luką w tym obszarze.

Dlaczego problem pozostawał nierozwiązany? Architektura M365 jest fragmentaryczna — to efekt ponad dziesięciu akwizycji posklejanych w jeden ekosystem. DLP dla Copilota był w fazie Public Preview, a mimo to został wdrożony w produkcji bez pełnej certyfikacji. Pełne uspójnienie architektury sensitivity labels oznaczałoby opóźnienie o lata, więc Microsoft wybrał wdrożenie Copilota na architekturze „as-is", z udokumentowanymi lukami.

Co istotne, decyzja o tym wdrożeniu nie wymagała zgody klientów enterprise. Copilot jest „domyślnie włączony" dla użytkowników M365 E3/E5 posiadających odpowiednie licencje — bez procesu opt-in. Organizacje, które nie skonfigurowały aktywnie wyłączenia Copilota z dostępu do wrażliwych danych, były automatycznie narażone. Ciężar dowodu spoczywa po stronie klienta, nie Microsoftu. „Domyślnie włączony" jest modelem preferowanym przez Microsoft z konkretnego powodu: firma automatycznie instalowała Copilota dla użytkowników enterprise od października 2025 roku. Adoption rate Copilota wśród płatnych użytkowników M365 w USA spadł z 18,8% w lipcu 2025 do 11,5% w styczniu 2026 — to 39-procentowa kontrakcja. Microsoft aktywnie walczył z tym spadkiem poprzez przymusową instalację. Domyślne włączenie oznacza maksymalizację adopcji.

Klasyfikacja, która ukryła incydent

Microsoft sklasyfikował CW1226324 jako „advisory", a nie jako „incident" bezpieczeństwa. Ta klasyfikacja ma kluczowe konsekwencje prawne i komunikacyjne. W terminologii Microsoftu „incident" w Service Health Dashboard oznacza przerwę w działaniu usługi (service degradation), natomiast „advisory" oznacza zachowanie niezgodne z oczekiwaniami, ale bez przerwy w działaniu. Copilot działał — po prostu czytał dane, których nie powinien. Z perspektywy Microsoftu nie był to więc „incident": usługa działała. Z perspektywy RODO był to jednak potencjalny data breach, ponieważ dane poufne były przetwarzane bez podstawy prawnej.

Klasyfikacja „advisory" miała też wymiar notyfikacyjny. RODO Art. 33 wymaga zgłoszenia naruszenia danych do organu nadzorczego w ciągu 72 godzin, jeśli naruszenie jest prawdopodobne. Microsoft argumentował, że dane „nie opuściły granic M365" — bo Copilot przetwarzał je wewnętrznie, nie wysyłał na zewnątrz. To argument techniczny, który ignoruje fakt, że polityki DLP były skonfigurowane właśnie po to, by Copilot nie miał dostępu do tych danych w żadnym scenariuszu. Dlaczego taki argument bywa akceptowany przez regulatorów jako wyłączenie obowiązku notyfikacji? Europejski Inspektor Ochrony Danych (EDPS) zakończył trzyletnie dochodzenie w sprawie Microsoft 365 w lipcu 2025 roku — ale tylko dla Komisji Europejskiej i tylko w ramach Rozporządzenia 2018/1725 dotyczącego instytucji UE, nie RODO. Wyniki tego dochodzenia odnoszą się wyłącznie do specyficznego kontraktu Komisji i nie mają zastosowania do NHS, firm prywatnych ani innych podmiotów.

Sovereign Cloud kontra CLOUD Act

Najgłębsza warstwa sprawy dotyczy fundamentalnej sprzeczności między marketingiem „Sovereign Cloud" a amerykańskim prawem CLOUD Act. Anton Carniaux, Chief Legal Officer Microsoft France, zeznał przed Senatem Francji 10 lipca 2025 roku, pod przysięgą, że Microsoft nie może zagwarantować, iż dane europejskie nigdy nie trafią do amerykańskich władz — ponieważ CLOUD Act to prawo federalne USA, nadrzędne wobec kontraktów z klientami.

Co dokładnie gwarantuje, a czego nie gwarantuje Microsoft EU Data Boundary? Gwarantuje przechowywanie i przetwarzanie danych na serwerach w UE/EEA, ograniczenie dostępu do danych do europejskich pracowników Microsoftu oraz możliwość audytu przez klienta. Nie gwarantuje natomiast odmowy wykonania legalnych żądań amerykańskich władz na mocy CLOUD Act, NSL czy FISA — nawet jeśli dane fizycznie znajdują się w Europie. Carniaux wprost potwierdził, że jeśli rząd USA wyśle legalne żądanie, Microsoft musi je spełnić — i powiadamia klienta jedynie wtedy, „jeśli US authorities na to pozwolą". Jak często władze USA korzystają z CLOUD Act wobec danych europejskich? Tego nie wiemy precyzyjnie: Microsoft publikuje Transparency Reports, ale w kategorii National Security Requests (NSL, FISA 702) podaje wyłącznie zagregowane zakresy, a najbardziej wrażliwe żądania są prawnie objęte zakazem ujawniania.

Dlaczego UE toleruje taką sytuację? Dochodzenie EDPS w latach 2022–2025 zakończyło się dedykowanym porozumieniem (bespoke agreement) wyłącznie dla Komisji Europejskiej. Po zamknięciu dochodzenia EDPS dopisał zastrzeżenie, że jego zakończenie nie oznacza, iż EDPS ocenił czy potwierdził ogólną zgodność Komisji z innymi przepisami. Innymi słowy: nawet regulatorzy RODO nie rozwiązali fundamentalnego problemu CLOUD Act. Dlaczego UE nie wymagała od Microsoftu takiego porozumienia jako warunku działalności w UE, a jedynie jako rozwiązania ad hoc? Ponieważ Amazon AWS, Google Cloud, Microsoft Azure i Oracle razem kontrolują ponad 70% europejskiego rynku cloud. Niemcy płacą Microsoftowi prawie 500 mln EUR rocznie w opłatach licencyjnych, a duże francuskie korporacje wydają ponad 50 mld USD rocznie na amerykańskie cloud i oprogramowanie. Europejska gospodarka jest operacyjnie zależna od US Big Tech — co tworzy taki sam mechanizm regulatory capture jak w USA: regulatorzy nie mogą narzucić warunków, których spełnienie groziłoby paraliżem własnej gospodarki.

Regulator bez narzędzi

Dlaczego regulatorzy reagują dopiero wtedy, gdy AI jest już standardem enterprise? Copilot osiągnął 50 000 użytkowników w NHS, zanim ICO opublikowało jakiekolwiek wytyczne dla asystentów AI z dostępem do danych medycznych. NHS AI trial był reklamowany przez rząd UK 20 października 2025 roku — trzy miesiące przed incydentem DLP. Rząd UK występuje tu jednocześnie jako promotor adopcji, jako podmiot finansujący NHS (który musi oszczędzać) oraz jako nadzorca regulatora (ICO), co tworzy trójkąt konfliktu interesów analogiczny do tego opisywanego po stronie USA. Regulatorzy nie dysponują narzędziami do audytu AI — bo narzędzia te musiałby dostarczyć Microsoft, który nie ma w tym interesu, a regulatorzy nie mają technicznych możliwości samodzielnego ich zbudowania.

Mapa łańcucha przyczynowego

Objaw był prosty: Copilot czytał poufne e-maile przez około trzydzieści dni wbrew politykom DLP. Przyczyna bezpośrednia to niekonsekwentne działanie sensitivity labels w M365 — problem znany i dokumentowany przez Microsoft jeszcze przed wdrożeniem Copilota. Głębiej leży przyczyna systemowa: architektura M365 jest fragmentaryczna (efekt ponad dziesięciu akwizycji), a DLP dla Copilota był w Public Preview, lecz został wdrożony produkcyjnie bez pełnej certyfikacji. Na poziomie organizacyjnym Microsoft priorytetyzował adopcję (przymusowa instalacja od października 2025) ponad bezpieczeństwo, a klasyfikacja „advisory" ukrywała incydent przez blisko miesiąc. Najgłębsza, strukturalna przyczyna to fakt, że marketing „Sovereign Cloud" jest technicznie prawdziwy, ale prawnie fałszywy: CLOUD Act i FISA nadpisują każdą obietnicę suwerenności danych.

Trzy fikcje sprzedawane jako bezpieczeństwo

Pierwsza fikcja to DLP jako gwarancja ochrony. Polityki DLP i sensitivity labels były sprzedawane jako mechanizm ochrony przed Copilotem. Microsoft sam wiedział, że działają niekonsekwentnie. NHS inwestował w te kontrole, wierząc w ich skuteczność. Rzeczywistość jest taka, że lista „known issues" Microsoftu jest aktualizowana regularnie — użytkownicy enterprise kupują iluzję bezpieczeństwa, nie samo bezpieczeństwo.

Druga fikcja to Sovereign Cloud jako suwerenność. „EU Data Boundary" brzmi jak prawna gwarancja, ale jest nią wyłącznie w zakresie geograficznej lokalizacji danych. Prawna suwerenność — czyli prawo do odmowy dostępu amerykańskim władzom — jest niemożliwa dla firmy podlegającej jurysdykcji USA. Anton Carniaux powiedział to pod przysięgą. Żaden materiał marketingowy Microsoftu tej informacji nie zawiera.

Trzecia fikcja to incydent bez ofiar. „No patient information has been compromised" — to oświadczenie NHS oparte na zapewnieniach Microsoftu, a nie na niezależnym audycie. Microsoft nie ujawnił zakresu incydentu. Po prostu nie wiemy — i to dokładnie dlatego, że Microsoft nie udostępnia pełnych logów grounding, które pozwoliłyby na niezależną weryfikację tego, co Copilot zrobił z danymi.

Co z tego wynika

EU Cloud and AI Development Act (CADA), zaprezentowany 3 czerwca 2026 roku, definiuje cztery poziomy suwerenności, ale jego uchwalenie zajmie lata — a najwyższy poziom, oznaczający pełną niezależność od jurysdykcji USA, jest z definicji nieosiągalny dla firm takich jak Microsoft. Reuters ujawnił, że propozycja ograniczeń dla US Big Tech w zamówieniach publicznych „może spotkać się z reakcją Waszyngtonu"; USA już wyraziło sprzeciw. Europa reguluje, ale robi to za wolno wobec tempa wdrożeń, za miękko wobec presji Waszyngtonu i z lukami, które niezmiennie chronią firmy bardziej niż obywateli.

Wniosek jest trudny, ale jasny: jedynym sposobem na prawdziwą suwerenność danych jest infrastruktura podlegająca wyłącznie jurysdykcji UE. Potwierdza to stanowisko CTO Gaia-X: dla danych „krytycznych" nie należy używać amerykańskich firm cloud — nie dlatego, że są złe, lecz dlatego, że prawo USA jest nadrzędne wobec ich obietnic.

Źródła i ich wiarygodność

Materiał opiera się na hierarchii źródeł o różnym poziomie wiarygodności. Do najwyższego poziomu należą: pierwotne ujawnienie CW1226324 przez BleepingComputer, oficjalny service alert Microsoftu, zeznanie Antona Carniaux przed Senatem Francji z 10 lipca 2025 oraz komunikat prasowy EDPS z 27 lipca 2025. Kolejny poziom stanowi oficjalna dokumentacja techniczna Microsoftu dotycząca znanych problemów sensitivity labels oraz notatki Public Preview dla DLP w Copilocie. Dalej znajdują się niezależne analizy dziennikarskie (m.in. analiza osi czasu The Stack), dokumentacja legislacyjna EU Cloud and AI Development Act oraz doniesienie Reutersa z 1 czerwca 2026 o propozycji ograniczeń CLOUD Act. Najszerszy kontekst uzupełniają wypowiedzi CTO Gaia-X Christopha Strnadla, analiza KuppingerCole dotycząca suwerenności chmury Microsoftu oraz rządowy raport pilotażowy NHS z GOV.UK z października 2025.