Monitorowanie agentów w Copilot Studio

Jak wygląda monitorowanie agentów w Copilot Studio?

Praktyczny przegląd sześciu warstw telemetrii, pułapek transkryptów w Dataverse oraz braków, które ujawniają się dopiero podczas wyjaśniania incydentu.

Handlowiec pyta bota w Teams o przysługujący rabat, kopiuje odpowiedź do maila i wysyła ofertę. Po dwóch tygodniach wychodzi na jaw, że bot pomylił progi rabatowe, a klient domaga się ceny, którą dostał na piśmie. Handlowiec twierdzi: „przecież bot mi tak napisał”. Żeby to rozstrzygnąć, trzeba sięgnąć do zapisanej historii tej rozmowy. I tu zaczynają się schody. W Copilot Studio nie ma jednego, centralnego widoku z logami. Telemetria rozproszyła się po sześciu osobnych systemach, a każdy z nich to osobny świat: ma własnego właściciela, odmienne czasy przechowywania danych i wymaga innych licencji (do części potrzebujesz Microsoft 365 E5). Co więcej, części z nich nie dostajesz domyślnie, trzeba je skonfigurować ręcznie. W tym artykule pokażę, jak to wygląda w praktyce. (Uwaga: powyższy scenariusz to przykład poglądowy, a nie opis konkretnego wdrożenia.) ## Telemetria w sześciu miejscach Najpierw mapa. Administrator mówi „mamy audyt”, mając na myśli Purview, twórca agenta mówi „mam transkrypty”, mając na myśli Dataverse, a osoba od compliance zakłada, że jedno wynika z drugiego. Nie wynika. To odrębne miejsca logowania i te dane nie łączą się automatycznie. | Warstwa | Co zapisuje | Retencja domyślna | Kto ma dostęp | Czego wymaga | |---|---|---|---|---| | Monitor (analityka) w Copilot Studio | zagregowane metryki: sesje, wyniki, CSAT, aktywni użytkownicy | 360 dni dla metryk, 28 dni dla szczegółów sesji i transkryptów | właściciel agenta oraz osoby z rolą `Analytics Viewer` | Copilot Studio | | Transkrypty w Dataverse | pełny zapis aktywności rozmowy w formacie JSON | 30 dni, kasowane cyklicznym zadaniem, które da się zmienić | wyłącznie rola `Bot Transcript Viewer`, nadawana przez administratora | Dataverse w środowisku; nie działa w środowiskach deweloperskich | | Purview Audit | zdarzenia twórcze na agencie i zdarzenie `CopilotInteraction`: metadane, użyte zasoby, identyfikator wątku transkryptu | 180 dni w Audit (Standard) | role `Audit Reader` / `Audit Manager` w Purview | włączony audyt w tenancie; w planach Microsoft 365 Business trzeba go włączyć ręcznie | | DSPM for AI (Data Security Posture Management for AI) | treść promptu i odpowiedzi powiązana ze zdarzeniem audytu | zgodnie z politykami retencji w Purview | zespół compliance w portalu Purview | E5 albo odpowiedni dodatek compliance | | Application Insights | telemetria aktywności agenta, opcjonalnie treść wiadomości i identyfikator użytkownika | ustalasz sam w zasobie Azure | każdy z dostępem do zasobu Application Insights | subskrypcja Azure | | Entra Agent ID | tożsamość agenta i jego aktywność uwierzytelniania | zgodnie z retencją logów Microsoft Entra ID | administrator Entra | tożsamość tworzona automatycznie dla nowych agentów | Każdy z tych systemów widzi tylko część interakcji. Microsoft Purview wie, że rozmowa się odbyła, i zna identyfikator wątku, ale treść jest dla niego niewidoczna. Dataverse przechowuje treść konwersacji, za to nie powie Ci, czy odpowiedź nie została ucięta przez filtry moderacji. Application Insights wyłapie i działanie filtrów, i treść wiadomości, tylko że wymaga konfiguracji oraz włączenia logowania danych wrażliwych. Nawet wtedy nie zobaczysz tam, jakie źródła wiedzy agent przeszukiwał, dopóki ręcznie nie dopiszesz niestandardowej telemetrii w każdym temacie. Próba ustalenia, co naprawdę zaszło w trakcie jednej rozmowy, wymaga więc składania danych z kilku różnych platform. ## Transkrypty w Dataverse: sześć pułapek To warstwa, na której realnie stoi zapis polityki o odtwarzalności rozmów, więc opiszę ją najdokładniej. Pierwsza pułapka jest w miejscu, w którym mało kto szuka. Zaczynasz od dwóch osobnych przełączników: PPAC (Power Platform Admin Center) → Manage → Environments → wybrane środowisko → Settings → Product → **Features** → sekcja Copilot Studio agents. Pierwszy decyduje, czy transkrypty w ogóle zapisują się do Dataverse, a drugi, czy właściciele i edytorzy agenta mogą je oglądać i pobierać. W nowych środowiskach oba są domyślnie włączone. Na poziomie grupy środowisk odpowiada im reguła `Accessing transcripts from conversations in Copilot Studio agents`, która nadpisuje ustawienia poszczególnych środowisk.  *Rysunek: Zapis do Dataverse i dostęp twórców to dwie niezależne decyzje.* Druga pułapka to uprawnienia. Wgląd w transkrypty w Power Apps daje rola `Bot Transcript Viewer`, której rola `Environment Maker` nie zawiera i którą nadaje wyłącznie administrator. Platforma wyraźnie rozdziela uprawnienia do tworzenia agenta od dostępu do historii prowadzonych rozmów. Przy analityce jest tak samo: rola `Analytics Viewer` nie wystarcza, do treści rozmowy i tak potrzeba `Bot Transcript Viewer`. Trzecia pułapka dotyczy samego momentu zapisu. Rozmowa trafia do bazy dopiero po 30 minutach bezczynności. Jeśli po tym czasie użytkownik wznowi czat, system utworzy zupełnie nowy rekord o identycznej nazwie, ale z nowym znacznikiem czasu rozpoczęcia. Czwarta pułapka to scalanie. Każdy rekord ma limit 1 MB na kolumnę z treścią. Dłuższy transkrypt system dzieli na kilka rekordów o tej samej nazwie i tym samym czasie rozpoczęcia, różniących się wartością `BatchId`. Żeby odtworzyć całość, trzeba wziąć wszystkie rekordy o zgodnej parze `Name` i `ConversationStartTime`, a potem posortować je po `BatchId`. Jeśli tego nie zrobisz, dostaniesz urwaną w połowie rozmowę i nawet nie zauważysz, że czegoś brakuje. Piąta pułapka to polityka retencji. Domyślnie w Power Apps działa cykliczne zadanie masowego usuwania, które po 30 dniach kasuje wszystkie transkrypty. Nie zmienisz tego jednym suwakiem w panelu: trzeba ręcznie anulować domyślne zadanie systemowe i utworzyć własne z nowym progiem czasowym. Niezależnie od tego Copilot Studio i tak trzyma dane sesyjne we własnym magazynie jeszcze przez maksymalnie 28 dni. Miesiąc to może być za mało, by obsłużyć proces reklamacyjny, o wymogach audytowych czy compliance nie wspominając. Właśnie dlatego dłuższe przechowywanie historii rozmów wymaga manualnej konfiguracji środowiska już na starcie. I wreszcie ostatnia pułapka: pobieranie historii sesji bezpośrednio z panelu Copilot Studio. Taki eksport ma spore ograniczenie, bo system obcina każdą pojedynczą wypowiedź agenta do pierwszych 512 znaków. Jeśli potrzebujesz pełnej, nieobciętej treści konwersacji, jedynym wyjściem jest wyeksportowanie tabeli `ConversationTranscript` z poziomu Power Apps. W polu `content` jest znacznie więcej. To surowy zrzut wszystkich aktywności, gdzie każde zdarzenie ma znacznik czasu, identyfikator kanału `channelId` oraz sekcję `from`, w której parametr `role` przyjmuje wartość 0 dla agenta i 1 dla użytkownika. Poszczególne typy aktywności dokumentują kolejne kroki w logice agenta: `IntentRecognition` oznacza wywołanie tematu, `VariableAssignment` przypisanie wartości do zmiennej, a `SessionInfo` podsumowuje wynik sesji i liczbę tur konwersacji. Przydatna, a często pomijana jest opcja Settings → Advanced → **Enhance Transcripts**. Po jej włączeniu w logach pojawia się obiekt `nodeTraceData` ze szczegółami na poziomie pojedynczych węzłów: znajdziesz tam identyfikator i typ węzła, dokładny czas startu i zakończenia oraz nazwę tematu. To jedyny wbudowany mechanizm pozwalający prześledzić dokładną ścieżkę logiczną agenta, a nie jedynie samą treść wygenerowanej odpowiedzi.  *Rysunek: Szczegóły na poziomie węzłów są wyłączone domyślnie, a to one pokazują przebieg rozmowy.* Jeśli nie chcesz parsować JSON-ów na własną rękę, możesz skorzystać z gotowego narzędzia. Microsoft udostępnia w repozytorium na GitHubie projekt Copilot Agent Kit (z modułem Conversation KPIs), który automatycznie rozbija transkrypty na dedykowane tabele w Dataverse. Warto jednak pamiętać, że to projekt open-source, a nie oficjalnie wspierany produkt komercyjny. Sam, na własne potrzeby, napisałem prostą przeglądarkę logów. Przy wdrażaniu takich rozwiązań trzeba jednak pamiętać o ważnej kwestii bezpieczeństwa: każde narzędzie, które pobiera i analizuje transkrypty, samo staje się kolejnym systemem przetwarzającym dane osobowe. ## Test: czego w transkrypcie nie ma Do tej pory opisywałem mechanikę. Teraz rzecz najważniejsza: nie to, jak transkrypt działa, tylko czego w nim nie ma. Zbudowałem w tenancie demo dokładnie takiego agenta jak w scenie otwierającej: asystent ofertowy dla handlowca, z dokumentami w SharePoincie jako jedynym źródłem wiedzy, opublikowany do Teams. W rozmowie padły i pytania obsłużone przez zaprojektowane przeze mnie węzły Message, i pytanie o warunki rabatowe, na które agent odpowiedział generatywnie. Potem pobrałem transkrypt z tabeli `ConversationTranscript` w Power Apps.  *Rysunek: Rozmowa z agentem po stronie handlowca.* W transkrypcie wygląda to już zupełnie inaczej. Wypowiedzi agenta pochodzące z węzłów, które sam zaprojektowałem, zapisały się normalnie, z pełną treścią. Odpowiedź generatywna oparta na SharePoincie zapisała się jako `REDACTED`.  *Rysunek: Surowy zapis rekordu. W miejscu zdania, które handlowiec przeczytał w Teams, stoi `REDACTED`.* Ten sam rekord otwarty w przeglądarce transkryptów, którą sobie napisałem, układa się w czytelną rozmowę i pokazuje dokładnie to samo.  *Rysunek: Wygodniejszy odczyt. Każde narzędzie czytające transkrypty pokaże w tym miejscu to samo, bo w rekordzie nie ma nic więcej.* Warunki tego testu: tenant demo TrustInAI, licencja Microsoft 365 Business Basic, Copilot Studio rozliczany w modelu pay-as-you-go, brak etykiet wrażliwości w tenancie, agent w środowisku typu sandbox, test z sierpnia 2026 roku. Warto zwrócić uwagę na sprzeczność w samej dokumentacji Microsoftu. Materiały o pobieraniu transkryptów (aktualizowane pod koniec sierpnia 2026 r.) podają, że dla SharePointa transkrypt rejestruje pytanie oraz treść dokumentów źródłowych w `search_results`, ale ukrywa odpowiedź pod flagą `REDACTED`. Z kolei artykuł o konfiguracji bazy wiedzy na SharePoincie (z początku sierpnia 2026 r.) opisuje to odwrotnie: wycinana jest treść plików, a odpowiedź pozostaje nietknięta. Mój test rozstrzygnął to na korzyść pierwszej wersji. W logach znalazłem tablicę `searchResults` (w dokumentacji: `search_results`), zawierającą bezpośredni link do pliku w SharePoincie, numer strony i dokładny zrzut treści. Całość pojawiła się powtórzona również w `verifiedSearchResults`. Transkrypt zapisuje zatem kompletny zrzut danych przekazanych do modelu (źródła i użyte fragmenty informacji), pomijając przy tym samą treść wygenerowanej odpowiedzi. Pozostaje tu jednak jedna niewiadoma: według części ekspertów wykluczenie to obejmuje wyłącznie pliki z etykietami wrażliwości. Moje środowisko nie korzysta z etykietowania, więc w tenantach z licencją E5 i wdrożonymi politykami ochrony danych sytuacja może wyglądać inaczej. Z tego wynikają dwie rzeczy. Pierwsza to paradoks. W transkrypcie zostają elementy statyczne (czyli ścieżka i reguły, które i tak znasz z konfiguracji agenta), natomiast bezpowrotnie znika treść wygenerowana przez model językowy. Znika dokładnie ten fragment rozmowy, którego zazwyczaj szukasz przy wyjaśnianiu incydentów.  *Rysunek: Nawet gdy treść odpowiedzi znika, ślad po wywołaniu węzła generatywnego zostaje. To wystarczy, żeby udowodnić, że odpowiedź powstała, ale nie żeby pokazać, jaka.* Druga to zachwiany profil ryzyka. System utrwala w bazie surową treść przeszukiwanych plików, pomijając to, co agent rzeczywiście napisał użytkownikowi. Mój test to pokazał: transkrypt zrzucił kompletne informacje o regułach rabatowych, wraz z dokładnymi ścieżkami URL, a samą odpowiedź zamaskował jako `REDACTED`. Taki mechanizm tworzy w Dataverse niezarządzany zrzut danych z SharePointa, który traci pierwotne restrykcje dostępowe i klasyfikację bezpieczeństwa. Dostęp do samego transkryptu reguluje osobna rola w Dataverse, `Bot Transcript Viewer`, nadawana przez administratora na poziomie środowiska lub udostępnienia agenta. Przycinanie uprawnień do treści z SharePointa działa tylko raz, w momencie generowania odpowiedzi, względem osoby faktycznie rozmawiającej z agentem. Nikt nie sprawdza tego ponownie, gdy później ktoś inny, wyposażony w rolę `Bot Transcript Viewer`, otwiera zapisany rekord: może swobodnie przeczytać w `searchResults` treść dokumentu, do którego sam nigdy nie miałby dostępu, gdyby spróbował otworzyć go bezpośrednio w SharePoincie. To pułapka wdrożeniowa: formalne procedury audytowe wyglądają na wdrożone, a w krytycznym momencie logi nie pozwalają odpowiedzieć na podstawowe pytanie o to, co użytkownik przeczytał na ekranie.  *Rysunek: W tym samym rekordzie, w którym odpowiedź agenta jest wycięta, leży treść dokumentów, z których powstała.* Najważniejsza lekcja wykracza daleko poza sam mechanizm SharePointa: architektura bazy wiedzy wprost przesądza o tym, jak wygląda ślad audytowy. Dopóki na etapie testów nie zrobisz zrzutu transkryptu dla wybranego konektora, nie wiesz, czy system w ogóle zachowa kluczowe dane z interakcji. ## Kto tak naprawdę rozmawiał z agentem? Drugie pytanie, które pojawia się przy każdej reklamacji, dotyczy tożsamości rozmówcy: z kim właściwie rozmawiał agent? I tutaj platforma jest zaskakująco restrykcyjna. Identyfikator nadawcy w polu `from.id` zostaje zahaszowany, zanim w ogóle trafi do transkryptu. Dokumentacja tłumaczy to względami bezpieczeństwa i prywatności. Ponieważ w Teams identyfikator użytkownika jest stały, wygenerowany hash nie zmienia się w kolejnych rozmowach tej samej osoby. Pozwala to łatwo zliczyć unikatowych użytkowników i połączyć ich sesje w jeden wątek, ale bez wglądu w to, kim ten człowiek faktycznie jest. W praktyce mówimy więc o pseudonimizacji. Wniosek? W świetle prawa to wciąż dane osobowe, nawet jeśli bezpośrednio nie da się z nich wyczytać nazwiska. Da się to obejść na dwa sposoby. Pierwszy opiera się wyłącznie na edytorze agenta: jeśli masz włączone uwierzytelnianie (domyślne w Copilot Studio i Teams), system udostępnia zmienne `User.Id`, `User.PrincipalName`, `User.DisplayName` oraz `User.Email`. Zapisanie którejś z nich do zmiennej globalnej sprawi, że pojawi się ona w transkrypcie pod postacią rekordu `VariableAssignment`. Zdecydowanie polecam `User.Id` zamiast `User.PrincipalName` czy `User.Email`. W zupełności wystarczy do identyfikacji rozmówcy i nie powiela adresów e-mail w tabelach, które łatwo potem nieopatrznie wyeksportować do CSV. Druga opcja to Application Insights, o którym za chwilę. Obie mają wspólną cechę: platforma domyślnie tego nie robi i jest to decyzja projektowa. Każde z tych obejść świadomie rozszerza zakres danych osobowych zapisywanych w rozmowie, więc powinno być udokumentowaną decyzją z celem i retencją. ### Obowiązek poinformowania użytkownika o rozmowie ze sztuczną inteligencją Zgodnie z art. 50 ust. 1 AI Act użytkownik musi zostać wyraźnie poinformowany o kontakcie ze sztuczną inteligencją, najpóźniej w chwili rozpoczęcia rozmowy. W systemie nie znajdziesz do tego dedykowanego przełącznika, ale załatwisz to w dwóch miejscach: w komunikacie powitalnym albo w opisie agenta w kanale publikacji. Pewniejszym wyborem jest opis, ponieważ odbiorca widzi go jeszcze przed wysłaniem pierwszej wiadomości, w momencie dodawania agenta. Z kolei zawarty w przepisach wyjątek dotyczący sytuacji „oczywistych” dobrze broni się w Teams czy Microsoft 365 Copilot Chat, gdzie sam interfejs jednoznacznie sugeruje chatbota. Jednak przy agencie osadzonym na stronie WWW czy agencie głosowym lepiej na nim nie polegać. ## Purview, czyli metadane bez treści Purview loguje dwie zupełnie różne kategorie zdarzeń. Pierwsza to działania twórcze na agencie, od `BotCreate` i `BotUpdateOperation-BotPublish` po `BotUpdateOperation-BotAuthUpdate`, `BotUpdateOperation-BotShare` i operacje na komponentach. Zbieranie tych zdarzeń jest włączone domyślnie we wszystkich tenantach i nie da się go wyłączyć: można wyłączyć audyt w Purview albo skrócić retencję polityką, ale nie samo zbieranie. To realny ślad odpowiadający na pytanie, kto i kiedy zmienił konfigurację agenta oraz kto go opublikował. Druga kategoria to zdarzenie `CopilotInteraction`, czyli interakcja użytkownika z agentem. I tu trzeba być precyzyjnym: rekord audytu zawiera metadane i identyfikator wątku transkryptu, a nie treść rozmowy. Dokumentacja mówi to wprost. Metadanych jest za to sporo: `AgentId` z prefiksem rozróżniającym typ agenta (`CopilotStudio.Declarative.*` albo `CopilotStudio.CustomEngine.*`), `AgentName`, `AgentVersion`, `AppHost` mówiący, czy rozmowa toczyła się w Teams czy w Microsoft 365 Copilot Chat, `ModelTransparencyDetails` z dostawcą i nazwą modelu, wreszcie `AccessedResources` z listą zasobów, po które agent sięgnął, wraz z identyfikatorami ich etykiet wrażliwości i flagą `XPIADetected`. `AccessedResources` odpowiada na pytanie, z czego konkretnie agent skorzystał. Treść promptu i odpowiedzi Purview trzyma osobno, w DSPM for AI, i to jest ten próg licencyjny. Zapis polityki typu „przechowujemy pełny zapis interakcji z systemem AI wraz z użytymi źródłami” zaczyna działać natywnie dopiero na tym poziomie. Dwie rzeczy na koniec. Po pierwsze, audyt nie jest domyślnie włączony dla licencji z rodziny Small and Medium Business, czyli Business Basic, Business Standard i Business Premium. Trzeba go włączyć ręcznie. Po drugie, dokumentacja Microsoftu sama sobie zaprzecza co do licencjonowania: strona o audycie Copilota i aplikacji AI stwierdza, że aplikacje zbudowane w Copilot Studio są objęte Audit (Standard), a strona wprowadzająca do audytu wymienia Copilot Studio wśród źródeł wymagających rozliczenia pay-as-you-go. Obie są aktualne i mówią co innego. Sprawdź to u siebie. ## Application Insights, czyli własny log Konfiguracja jest krótka: connection string zasobu Application Insights wklejasz w Settings → **Advanced** agenta. Dalej masz cztery ustawienia. `Enable logging` włącza logowanie przychodzących i wychodzących wiadomości oraz zdarzeń, `Log conversation details` dokłada identyfikator użytkownika, jego nazwę i treść wiadomości, `Log sensitive Activity properties` wartości właściwości uznanych za wrażliwe, a `Node execution events` zdarzenie przy każdym wykonaniu węzła w temacie. Dane lądują w tabeli `customEvents`, przeszukujesz je językiem KQL (Kusto Query Language), a szczegóły aktywności siedzą w `customDimensions`, w polach takich jak `fromId`, `fromName`, `text` i `designMode`. To ostatnie pozwala odfiltrować telemetrię z panelu testowego.  *Rysunek: Podłączenie Application Insights do agenta.*  *Rysunek: Ta sama rozmowa w Application Insights.* Zanim z tego skorzystasz, weź pod uwagę trzy rzeczy. Koszty obciążają Twoją subskrypcję w Azure i tam też ustawiasz retencję. Rejestrowanie treści rozmów i tożsamości rozmówców to realne rozszerzenie zakresu danych osobowych, a dokumentacja sama zaleca skonsultowanie tego kroku z zespołem compliance. Z kolei administratorzy mogą zablokować konektor `Application Insights in Copilot Studio` politykami danych w PPAC, co chroni firmę przed niekontrolowanym wypychaniem logów do prywatnych środowisk. Pamiętaj też o brakach: ta metoda nie zastąpi wpisów `AccessedResources` z logów audytowych (nie dowiesz się, po które pliki sięgnął agent) ani nie dostarczy gotowych podsumowań sesji znanych z Copilot Studio. To po prostu surowe zdarzenia, które trzeba samodzielnie obrobić i zwizualizować. ## Zanim uznasz, że masz transkrypcję rozmów z agentem Wszystkie te mechanizmy zdają egzamin tylko przy jednym założeniu: że transkrypty w ogóle się zapisują. W praktyce bywa z tym różnie, szczególnie w trzech konkretnych scenariuszach. **Środowiska deweloperskie.** Z definicji nie rejestrują transkryptów. W poprzednim tekście o wdrażaniu polityk AI wspominałem o funkcji Environment routing, która automatycznie kieruje twórców do ich własnych przestrzeni deweloperskich zamiast do środowiska domyślnego. To świetne zabezpieczenie, ale ma cenę: agent, który utknie na etapie deweloperskim, nie pozostawi żadnego śladu rozmów. Przeniesienie go na sandbox lub produkcję to nie tylko kwestia dobrych praktyk ALM, ale podstawowy warunek, by zapisy polityki dotyczące odtwarzalności miały jakiekolwiek pokrycie w rzeczywistości. **Agenci z Agent Buildera (Microsoft 365 Copilot) oraz Dataverse for Teams.** W obu tych przypadkach transkrypty w Dataverse po prostu nie powstają. W logach audytowych odkładają się jedynie metadane: nazwa, wersja agenta oraz lista odpytanych zasobów, bez treści samej konwersacji. Jeśli ktoś tworzy agenta bezpośrednio „w Copilocie” z przekonaniem, że pod spodem działa to identycznie jak w Copilot Studio, może się mocno zdziwić, gdy sięgnie po logi. **Rozliczalność wykonywanych akcji.** W tym przypadku problemem nie jest brak zapisu rozmowy, lecz to, do kogo zostaje przypisane działanie. Gdy agent korzysta z tożsamości użytkownika końcowego (tak jak przy odpowiedziach generatywnych bazujących na SharePoincie), wywołania idą w imieniu tego użytkownika. Jeśli jednak akcja wykorzystuje poświadczenia twórcy (maker connection), wszystkie operacje wykonywane przez użytkowników wpadają do systemów źródłowych na konto tej jednej osoby. Log w audycie niby jest, ale obciąża kogoś, kto fizycznie danej czynności nie zlecił. Przed tym scenariuszem da się zabezpieczyć administracyjnie: Copilot Studio pozwala zablokować w agencie możliwość używania poświadczeń twórcy, wymuszając uwierzytelnianie wyłącznie po stronie użytkownika końcowego. ## Pięć pytań przed uruchomieniem agenta Przykład rozmowy o rabacie z początku artykułu wygląda inaczej w każdym z tych wariantów. Gdyby ten agent działał w środowisku deweloperskim, w logach nie znalazłbyś absolutnie nic. Gdyby stał na właściwym środowisku, ale odpowiedź wygenerował z SharePointa, w transkrypcie zobaczyłbyś jedynie pytanie handlowca oraz znacznik `REDACTED` w miejscu przyznanej kwoty. Przy włączonych szczegółach na poziomie węzłów (node-level details) wiedziałbyś przynajmniej, że agent sięgnął do bazy wiedzy i o której godzinie to zrobił. Z kolei przy poprawnie podpiętym Application Insights i logowaniu treści cała odpowiedź znalazłaby się w tabeli `customEvents`, a wyjaśnienie sprawy zajęłoby pięć minut. O tym, w którym z tych wariantów wylądujesz w razie problemu, przesądza kilka ustawień zrobionych na starcie. Dlatego, zanim udostępnisz agenta użytkownikom, upewnij się, że znasz odpowiedzi na poniższe pytania: 1. **Czy transkrypty w ogóle są włączone?** Zweryfikuj typ środowiska (pamiętając o ograniczeniach dev) oraz stan obu przełączników odpowiadających za rejestrowanie rozmów. 2. **Kto ma wgląd do logów i jak długo są one przechowywane?** Standardowo dostęp mają wyłącznie osoby z przypisaną rolą `Bot Transcript Viewer`, a domyślny czas retencji to 30 dni. 3. **Czy potrafisz zidentyfikować rozmówcę?** To, czy w logu zobaczysz konkretnego użytkownika, zależy od Twojej konfiguracji uwierzytelniania. 4. **Co dokładnie trafia do logu przy Twoim typie źródła wiedzy?** Przetestuj to na własnym, wdrożonym agencie, zamiast polegać na ogólnej dokumentacji. Sprawdź, czy odpowiedzi generatywne nie są maskowane lub ucinane. 5. **Kto i jak często te dane analizuje?** Nawet najlepiej skonfigurowany audyt staje się tylko kosztem magazynowania danych, jeśli nikt regularnie do tych rejestrów nie zagląda. ## Pozostałe artykuły w serii - [Egzekwowanie polityki AI w praktyce. Wprowadzenie do serii i słownik pojęć](/egzekwowanie-polityki-ai-w-praktyce) - [Jakie polityki AI da się wyegzekwować w Power Platform?](/polityki-ai-power-platform)

Kacper Janowski

Tekst powstał przy współpracy człowieka i AI. Autor odpowiada za dobór przykładów, wnioski i ostateczną treść materiału.

Zauważyłeś błąd, nieścisłość lub zmianę w Copilot Studio? Napisz — zgłoszenie pomoże utrzymać artykuł aktualnym.

Monitorowanie agentów w Copilot Studio

Jak monitorować agentów w Copilot Studio: transkrypty Dataverse, Purview, DSPM for AI, Application Insights, retencja i luki audytowe.