W rekordzie audytu Copilota jest ID promptu, nie jego treść. Czym ustalić zakres incydentu
Log interakcji z Copilotem i Gemini mówi, kto i kiedy pytał, ale nie co wpisał. Gdzie leży treść, ile czasu zostaje i co ustalić w pierwszej godzinie.
Rekord audytu interakcji z Microsoft 365 Copilot ma pole Messages. W środku są dwie wartości na wiadomość: identyfikator i flaga isPrompt, która mówi tylko tyle, czy to było pytanie użytkownika, czy odpowiedź modelu. Treści promptu w tym rekordzie nie ma — dokumentacja Microsoft Purview opisuje to pole jako zestaw identyfikatorów wiadomości, a nie ich zawartość.
To jest różnica, która decyduje o tym, czy zgłoszenie „ktoś wprowadził dane klienta do asystenta” da się domknąć faktami, czy skończy się oświadczeniem osoby zainteresowanej. Dziennik zdarzeń odpowiada na pytanie kto, kiedy i w którym produkcie. Na pytanie co dokładnie odpowiada zupełnie inny zasób, z innym uprawnieniem, innym terminem ważności i — w części przypadków — z inną licencją. Poniżej stan dokumentacji na 25 października 2026 roku, z podziałem na to, co producent opisuje wprost, i to, czego nie opisuje.
Rekord audytu a treść rozmowy: dwa różne zasoby
Pojedynczy rekord CopilotInteraction jest bogatszy, niż się zwykle zakłada, tylko nie w tym wymiarze, który przy incydencie interesuje najbardziej. Według dokumentacji Microsoftu zawiera on między innymi AppHost (czy rozmowa toczyła się w Wordzie, Outlooku, Teams, czy w kliencie czatu), AppIdentity w formacie workloadName.appGroup.appName, oraz AccessedResources — listę zasobów, po które model sięgnął, budując odpowiedź.
Ta ostatnia tabela jest przy ustalaniu zakresu cenniejsza niż sam prompt. Dla każdego zasobu rekord podaje identyfikator, SiteUrl z pełną ścieżką pliku, typ, nazwę czytelną dla człowieka, rodzaj dostępu (read, create, modify) oraz SensitivityLabelId, czyli identyfikator etykiety poufności przypisanej do zasobu. Jeśli etykietowanie jest w organizacji wdrożone, to z samego dziennika — bez sięgania po treść — da się ustalić, czy asystent czytał dokument oznaczony jako poufny. Jest tam też pole XPIADetected, flaga wskazująca wykrycie próby wstrzyknięcia instrukcji z treści zasobu.
Czyli: jeśli incydent polega na tym, że asystent wyciągnął coś, czego nie powinien pokazać danej osobie, dziennik audytu wystarcza do ustalenia zakresu. Jeśli incydent polega na tym, że człowiek wprowadził do okna czatu dane, których nie wolno było tam umieścić, dziennik audytu potwierdzi jedynie, że interakcja miała miejsce. Te dwa scenariusze wymagają innych narzędzi i to rozróżnienie trzeba zrobić w pierwszych minutach, zanim ktoś zacznie przeszukiwać niewłaściwy zbiór.
| Pytanie przy incydencie | Zasób, który na nie odpowiada | Czy zawiera treść |
|---|---|---|
| Kto i kiedy korzystał z asystenta, w jakim produkcie | Dziennik audytu Purview, rekord CopilotInteraction | Nie — tylko identyfikatory wiadomości |
| Po jakie pliki sięgnął asystent i z jaką etykietą poufności | Pole AccessedResources w tym samym rekordzie | Nie, ale podaje ścieżki i etykiety |
| Co dokładnie zostało wpisane i co model odpowiedział | Eksport interakcji przez Microsoft Graph albo eDiscovery | Tak |
| Czy model korzystał z wyszukiwania w sieci | AISystemPlugin.Id o wartości BingWebSearch | Nie |
Trasa po treść w Microsoft 365: eksport interakcji, nie wyszukiwarka audytu
Treść jest dostępna, tylko inną drogą. Microsoft udostępnia zasób aiInteractionHistory w Microsoft Graph, a jego metoda Get all enterprise interactions jest w dokumentacji opisana jako zwracająca dane interakcji z Microsoft 365 Copilot, „w tym prompty użytkownika i odpowiedzi Copilota”. To jest właściwy punkt wejścia dla zespołu bezpieczeństwa, który musi odtworzyć przebieg rozmowy.
Dokumentacja wymienia przy tym trzy warunki i dwa twarde wyłączenia. Warunki: dostęp do danych eksportu może wymagać licencji dodatkowej Microsoft 365 Copilot zależnie od konfiguracji dzierżawy, użytkownicy, o których interakcje pytacie, muszą mieć przypisane licencje Copilota, a samo wywołanie wymaga uprawnień aplikacji i zgody administratora. Wyłączenia: interfejs nigdy nie zwróci interakcji z doświadczeń AI, które nie zapisują danych do usługi historii interakcji, ani interakcji z kont konsumenckich i osobistych kont Microsoft.
Drugie wyłączenie to w praktyce najczęstszy przypadek incydentu i wrócę do niego w przedostatniej sekcji. Pierwsze jest subtelniejsze: „Copilot” to nazwa parasolowa nad kilkunastoma produktami, a kryterium przynależności do eksportu nie brzmi „ma Copilota w nazwie”, tylko „zapisuje do usługi historii interakcji”. Zanim oprzecie procedurę reagowania na tym interfejsie, sprawdźcie na próbce, czy konkretne doświadczenie używane w waszej organizacji faktycznie się w nim pojawia. Test robi się raz, w spokojnym tygodniu, na koncie testowym — nie w trakcie incydentu. Powtórzcie go po każdej zmianie po stronie dostawcy, bo podmiana modelu albo zakresu usługi potrafi przejść bez ogłoszenia i zmienić to, co w ogóle trafia do dziennika.
Okno czasowe rekordu: 180 dni, rok i moment, w którym to się przesądza
Ustalanie zakresu ma termin ważności, bo rekordy nie leżą w systemie bez końca. Microsoft podaje, że domyślny okres przechowywania dla Audit (Standard) wynosi 180 dni, przy czym dzienniki wygenerowane przed 17 października 2023 roku zachowały poprzednie 90 dni. W Audit (Premium) domyślna, niemodyfikowalna reguła trzyma rekordy Exchange Online, SharePoint, OneDrive i Microsoft Entra przez rok, a wszystkie pozostałe aktywności nadal przez 180 dni.
Do tego dochodzi warunek licencyjny, który łatwo przeoczyć: ta sama dokumentacja zastrzega, że domyślna reguła roczna dotyczy aktywności użytkowników z licencją E5 albo z odpowiednim dodatkiem, a rekordy użytkowników bez E5 oraz gości są przechowywane przez 180 dni. Okres można wydłużyć regułą własną, aż do dziesięciu lat przy dodatkowej licencji, a organizacja może mieć maksymalnie 50 takich reguł.
Najważniejsze zdanie w całym tym dokumencie jest jednak zupełnie gdzie indziej. Microsoft pisze, że czas życia pozycji audytowej jest ustalany w momencie dodania jej do potoku audytowego, na podstawie licencji i obowiązujących wtedy reguł, a późniejsze zmiany licencji lub reguł nie aktualizują pozycji już zatwierdzonych. Innymi słowy: reguły przechowywania nie działają wstecz. Jeśli po incydencie zorientujecie się, że chcecie trzymać dzienniki dłużej, zmiana obejmie zdarzenia przyszłe, a nie to, którego właśnie szukacie. Decyzję o okresie przechowywania podejmuje się przed incydentem albo nie podejmuje się jej wcale.
Gemini: log zdarzeń w konsoli i Vault jako dwa niezależne zbiory
Po stronie Google rozdział między metadanymi a treścią jest jeszcze ostrzejszy, bo przebiega między dwoma osobnymi produktami.
Pierwszy to dziennik zdarzeń Gemini for Workspace w konsoli administracyjnej. Pomoc Google opisuje go jako rejestr interakcji użytkowników z Gemini — generowania i streszczania treści w Dokumentach, Arkuszach, Prezentacjach i innych usługach — z polami takimi jak wykonawca, akcja, typ zdarzenia, aplikacja i znacznik czasu. Na liście pól nie ma treści promptu. Dostęp wymaga uprawnienia administratora „Kontrola i dochodzenie”, a w narzędziu do analizy zagrożeń — uprawnienia administratora centrum bezpieczeństwa. Eksport wyników jest ograniczony do 100 000 wierszy, a w narzędziu do analizy zagrożeń do 30 milionów.
Te dzienniki mają własny zegar: Google podaje, że zdarzenia Gemini for Workspace są przechowywane przez 6 miesięcy, a opóźnienie pojawienia się zdarzenia wynosi „niemal czas rzeczywisty (kilka minut)”. Sześć miesięcy to krócej niż niejeden cykl audytu wewnętrznego i krócej niż typowy czas wyjścia na jaw incydentu zgłoszonego przez kogoś z zewnątrz.
Drugi zbiór to Vault i to tam leży treść. Zgodnie ze stroną obsługiwanych usług i typów danych Vault potrafi dla aplikacji Gemini przechowywać, blokować, przeszukiwać i eksportować prompty wprowadzone przez użytkowników oraz odpowiedzi wygenerowane przez aplikację. Reguły i blokady Vaulta mają przy tym pierwszeństwo: Google zaznacza, że blokady nadpisują reguły przechowywania oraz ustawienia z konsoli administracyjnej i ustawienia użytkownika, w tym ustawienie historii rozmów Gemini — te ostatnie wtedy jedynie ukrywają rozmowy przed użytkownikiem.
Na tej samej stronie jest jednak zastrzeżenie, które unieważnia część planów awaryjnych: jeśli administrator odbierze użytkownikowi licencję obsługującą Vault, blokada przestaje chronić wiadomości Gemini tego użytkownika przed usunięciem, a wiadomości oznaczone do usunięcia mogą zostać wyczyszczone natychmiast i bez możliwości odtworzenia. Odebranie licencji odchodzącemu pracownikowi w dniu rozwiązania umowy jest rutyną działu IT. W trakcie postępowania wyjaśniającego dotyczącego tej właśnie osoby ta rutyna kasuje materiał dowodowy.
Aplikacja Gemini a Gemini w aplikacjach Workspace: różnica w zakresie Vaulta
Google rozdziela dwie rzeczy, które użytkownik nazywa tak samo. „Aplikacja Gemini” to osobny produkt czatowy. „Gemini w Workspace” to asystent w panelu bocznym Dokumentów, Gmaila i reszty pakietu. W Vaulcie mają różny status i to jest najbardziej praktyczna informacja z całego tego materiału.
| Operacja w Vault | Aplikacja Gemini | Gemini w aplikacjach Workspace |
|---|---|---|
| Reguły przechowywania | Tak | Nie |
| Blokady na potrzeby postępowania | Tak | Nie |
| Wyszukiwanie i podgląd | Tak | Nie |
| Eksport promptów i odpowiedzi | Tak | Tak, i to jedyna dostępna operacja |
Konsekwencja jest konkretna: rozmowy z panelu bocznego da się wyeksportować, ale nie da się ich przeszukać w Vaulcie ani objąć blokadą. Jeżeli wasza procedura zakłada „założymy blokadę i poszukamy frazy”, dla panelu bocznego ona nie zadziała. Zadziała eksport, czyli operacja grubsza, wolniejsza i wymagająca przetworzenia wyniku poza Vaultem.
Druga luka dotyczy załączników. Dokumentacja wymienia jako nieobsługiwane pliki multimedialne i Gemy dołączane przez użytkowników do promptów oraz pliki multimedialne generowane w odpowiedzi. Jeśli incydentem jest zdjęcie dokumentu albo zrzut ekranu dołączony do zapytania, to akurat ten element w Vaulcie się nie znajdzie — a w realnych zgłoszeniach załącznik bywa dotkliwszy niż sam tekst.
Narzędzie spoza organizacji: rekord AIAppInteraction i przypadek bez żadnego logu
Dotąd było o narzędziach, które organizacja kupiła i wdrożyła. Większość zgłoszeń dotyczy czegoś innego: ktoś użył serwisu, którego nikt w firmie nie zamawiał, na prywatnym koncie, w przeglądarce na służbowym laptopie.
Microsoft przewiduje dla tego osobną kategorię rekordu. Dokumentacja Purview opisuje typ AIAppInteraction jako interakcje z aplikacjami AI innych producentów, które nie są wdrożone w waszej organizacji, i zaznacza, że są one rejestrowane dzięki mechanizmom DLP na poziomie sieci i przeglądarki. Rozliczane są w modelu pay-as-you-go, poza subskrypcją, a przechowywane przez 180 dni. Oddzielny typ ConnectedAIAppInteraction obejmuje aplikacje zarejestrowane i wdrożone wewnątrz organizacji.
Warunkiem istnienia tych rekordów jest więc działający kanał DLP w przeglądarce lub w sieci i włączone rozliczanie tej funkcji. Bez tego po waszej stronie nie powstaje żaden ślad interakcji — ani metadanych, ani treści — a po stronie dostawcy rozmowa należy do prywatnego konta, do którego nie macie tytułu administracyjnego. Dla tego wariantu nie istnieje żadna procedura odtworzenia zakresu z logów. Zostaje rozmowa z osobą, ewentualnie ślad sieciowy mówiący, że połączenie z tą domeną w ogóle nastąpiło. To jest też jeden z powodów, dla których przypisanie rejestru narzędzi AI i nadzoru nad nimi do konkretnej roli w organizacji wypada taniej niż dowolna analiza powypadkowa — jedyny moment, w którym da się zdecydować o istnieniu logów, jest przed incydentem.
Osobny przypadek to integracja przez API, a nie przez okno czatu. Tu logiem rozporządza dostawca, nie wy. Dokumentacja OpenAI dotycząca danych w API podaje na przykład, że dane na potrzeby monitorowania nadużyć są przechowywane do 30 dni, o ile dłuższy okres nie jest wymagany prawem lub potrzebny do ochrony usług. Trzydzieści dni to wyraźnie mniej niż 180 dni po stronie Microsoftu i mniej niż 6 miesięcy dzienników Google. Jeśli wasz potok danych przechodzi przez API, to najkrótszy zegar w całym zestawieniu należy właśnie do tego odcinka — i to on wyznacza realne okno na ustalenia.
Czego ten tekst nie rozstrzyga: zakresu dostępu administratora do rozmów w przestrzeniach roboczych poszczególnych dostawców czatów, bo ten różni się między planami i zmieniał się w ostatnich dwóch latach, a publicznie dostępna dokumentacja nie pozwalała na jednoznaczne odczytanie stanu w dniu weryfikacji. To jest pytanie do opiekuna konta, zadane na piśmie, z prośbą o wskazanie strony dokumentacji — nie do odtworzenia z artykułu ani z wpisu na blogu pośrednika.
Kolejność ustaleń w pierwszej godzinie
Zgłoszenie zwykle brzmi nieprecyzyjnie: „chyba wkleił coś z umowy”. Pierwsza godzina służy zawężeniu, a nie ocenie.
- Ustalcie produkt, nie markę. „Gemini” to co najmniej dwie różne ścieżki dowodowe, „Copilot” — kilkanaście. Zapytajcie o okno, w którym to się działo: panel boczny w dokumencie, osobna aplikacja, przeglądarka, telefon.
- Ustalcie konto. Służbowe w waszej dzierżawie czy prywatne. Od tej odpowiedzi zależy, czy w ogóle istnieje zbiór do przeszukania, i jest to jedyne pytanie, które może zakończyć analizę w dwie minuty.
- Zabezpieczcie zanim przeszukacie. W Vaulcie oznacza to blokadę przed upływem reguły przechowywania; w Microsoft 365 — eksport rekordów z interesującego okna, bo reguły nie działają wstecz. Kolejność odwrotna bywa nieodwracalna.
- Wstrzymajcie odbieranie licencji tej osobie, dopóki trwa postępowanie, i zapiszcie to jako wyjątek od procedury offboardingu w uzgodnieniu z działem IT.
- Rozdzielcie metadane od treści w notatce. Z dziennika zapiszcie czas, konto, produkt i listę zasobów z etykietami. Treść dopiszcie dopiero po eksporcie, oznaczając, z którego zasobu pochodzi.
- Zanotujcie, czego nie dało się ustalić. Brak logu jest ustaleniem, nie luką w pracy — pod warunkiem, że jest zapisany wprost.
Decyzja, która z tego wynika, nie dotyczy tego jednego zgłoszenia. Brzmi ona: przy których narzędziach AI używanych w waszej organizacji jesteście dziś w stanie odpowiedzieć na pytanie „co dokładnie wyszło”, i jakim kosztem. Odpowiedź sprawdza się w pół dnia, na koncie testowym: wpisujecie rozpoznawalny ciąg znaków do każdego z używanych asystentów, czekacie dobę, a potem próbujecie go odnaleźć każdą z dostępnych dróg. Narzędzia, przy których ciąg się nie znajdzie, dzielą się na dwie grupy — te, dla których trzeba włączyć odpowiedni kanał rejestrowania lub kupić licencję, i te, których nie wolno dopuszczać do danych objętych tajemnicą, dopóki pierwsza grupa się nie powiększy. Ten podział jest treścią polityki korzystania z AI, która realnie coś zmienia; reszta jest deklaracją.