Dowód pod liczbą z raportu znika po siedmiu dniach. Sprawozdanie, do którego weszła, trzyma się pięć lat

Raport zarządczy za październik poszedł na posiedzenie 12 listopada. W marcu ktoś prosi o odtworzenie jednej liczby z tego raportu: audytor, nowy członek rady albo dostawca w sporze o fakturę. W rejestrze tożsamości, z którego policzono, kto i kiedy uruchamiał agenta, nie ma już ani jednego zdarzenia z października, bo w Microsoft Entra ID Free dzienniki inspekcji i logowań są przechowywane siedem dni, a w planach P1 i P2 trzydzieści. Liczby nie da się przeliczyć. Zostaje w raporcie jako twierdzenie bez dowodu.

To nie jest problem archiwizacji ani porządku w dokumentach. To problem kolejności: wskaźnik wchodzi do raportu, zanim ktokolwiek sprawdził, jak długo żyje materiał, z którego go policzono. Rejestry wskaźników mają zwykle definicję i właściciela. Nie mają rubryki z retencją źródła, więc nikt nie zauważa, że decyzja oparta na liczbie przeżyje tę liczbę o kilka lat.

Kto potrafi odtworzyć liczbę z października w marcu?

Odtworzenie wskaźnika wymaga czterech rzeczy naraz, a brak którejkolwiek z nich zamyka sprawę. Pierwsza to definicja w tej wersji, w której liczono – nie bieżąca, tylko ta z października; sam fakt, że ten sam miesiąc potrafi dać dwa różne odczyty w zależności od przyjętego licznika, wystarcza, żeby wersja definicji była osobnym polem. Druga to źródło zapisu, czyli konkretny dziennik, tabela albo eksport, a nie nazwa narzędzia. Trzecia to materiał, który w tym źródle nadal jest. Czwarta to osoba lub rola, która potrafi powtórzyć rachunek bez autora pierwotnego wyliczenia.

Warunek czwarty jest tym, który najczęściej pęka w sposób niewidoczny. Dopóki autor wyliczenia pracuje w firmie, każde pytanie o liczbę wraca do niego i rachunek odtwarza się w godzinę. Po jego odejściu zostaje arkusz z wynikiem i formułą, ale bez wiedzy, które zdarzenia wchodziły do licznika, a które zostały odfiltrowane jako testowe. Sprawdzenie tego jest tanie i robi się je raz: wybrać dowolny wskaźnik z poprzedniego kwartału i poprosić kogoś innego o powtórzenie rachunku z samego rejestru.

W praktyce pierwsze dwie bywają zapisane, czwarta jest domyślnie przypisana do jednej osoby, a trzeciej nikt nie weryfikuje przed posiedzeniem. Pytanie dla rady nie brzmi więc „czy liczba jest poprawna”, bo na to odpowiedź zawsze jest twierdząca w miesiącu publikacji. Brzmi: ile dni ta odpowiedź pozostanie sprawdzalna.

Ile dni żyje dowód pod każdym wskaźnikiem w raporcie?

Domyślne okna retencji są krótsze, niż sugeruje intuicja, i różnią się między dostawcami oraz między planami u tego samego dostawcy. Poniższe wartości to ustawienia domyślne z dokumentacji producentów, sprawdzone 6 listopada 2026 r. Każdą z nich trzeba potwierdzić na własnej dzierżawie, bo plan licencyjny i polityki lokalne je zmieniają.

Rozstrzał w tej tabeli to od siedmiu dni do pięciu lat na tej samej liczbie. Jeden wiersz raportu może stać na źródle siedmiodniowym, drugi na sześciomiesięcznym, a oba trafiają do tego samego dokumentu z tą samą rangą.

Czego dostawca nie zapisuje w ogóle?

Gorszy przypadek od krótkiej retencji to retencja zerowa. W dokumentacji OpenAI dla większości punktów końcowych stan aplikacji jest opisany jako brak, a osobny termin 30 dni dotyczy Responses API oraz sytuacji, w której parametr store ma wartość true. Logi nadzoru nad nadużyciami, przechowywane do 30 dni, są narzędziem dostawcy, a nie waszym rejestrem zdarzeń. Jeśli wskaźnik liczy się z treści zapytań i odpowiedzi, a wasza strona nie zapisuje nic, to po stronie dostawcy nie ma czego odpytać.

Ta sama mechanika dotyczy dzienników aktywności Microsoft Graph, których po prostu nie ma, dopóki ktoś nie skonfiguruje eksportu. Konsola dostawcy pokazuje w takiej sytuacji agregaty policzone na danych, których już nie ma – i to jest różnica, której rada zwykle nie widzi. Wykres w panelu nie jest dowodem, bo nie da się z niego wrócić do pojedynczych zdarzeń.

Rozdzielenie tych dwóch przypadków ma wartość operacyjną, bo wymagają różnych działań. Krótka retencja to problem terminu: materiał istnieje i wystarczy wyprowadzić go na czas do magazynu o dłuższym oknie. Zerowa retencja to problem projektu: zapisu trzeba dopisać po swojej stronie, zanim pierwsze zdarzenie przejdzie przez system, bo wstecz nie da się go odzyskać. Pierwsze jest zadaniem administracyjnym na kilka dni, drugie wchodzi w zakres prac wdrożeniowych i ma koszt.

Czego w tym miejscu nie da się ustalić z dokumentacji publicznej: co zostaje u waszego dostawcy na waszych warunkach. Tryb retencji, zakres umowy powierzenia i ewentualne wyłączenia są w kontrakcie i aneksie, nie w poradniku producenta. To jest pytanie do działu zakupów z konkretną datą odpowiedzi, nie założenie do przyjęcia.

Dlaczego akcje agenta mają inny zegar niż akcje ludzi?

Agent działający pod własną tożsamością techniczną nie jest użytkownikiem i nie podlega tym samym regułom. W dokumentacji Purview zapisano, że rekordy inspekcji generowane przez podmioty inne niż użytkownicy – działania jednostek usługi, zdarzenia systemowe i aktywność aplikacji – są przechowywane przez ustalony okres jednego roku, którego nie można konfigurować, a własne polityki retencji ich nie obejmują.

Konsekwencja jest policzalna. Dodatkowa licencja na dziesięcioletnią retencję jest przypisywana na użytkownika, więc nie da się nią objąć działań agenta. Organizacja, która kupiła długi termin dla ludzi, ma dla agenta sztywny rok – i to niezależnie od tego, jak długo odpowiada za skutki jego decyzji. Zapis o nadzorze nad agentem, który żyje w rejestrze krócej niż umowa z klientem obsłużonym przez tego agenta, nie jest zapisem nadzoru.

Praktyczny skutek dla raportowania jest taki, że dwa wiersze opisujące ten sam proces mają różną trwałość: część obsłużona przez pracownika zostaje w rejestrze na warunkach polityki, którą rada zatwierdziła, a część obsłużona przez agenta na warunkach, których rada nie ustalała i nie może zmienić. Przy procesie przejętym w połowie oznacza to, że po roku porównanie obu ścieżek przestaje być możliwe – zostaje tylko ta ludzka.

Który termin jest wiążący dla waszego raportu?

Dolne progi ustawowe są wyższe niż domyślne ustawienia narzędzi i to jest cały problem. Rozporządzenie o sztucznej inteligencji nakłada obowiązek przechowywania dzienników generowanych automatycznie zarówno na dostawców systemów wysokiego ryzyka w art. 19, gdzie termin wynosi co najmniej sześć miesięcy, jak i na podmioty stosujące te systemy w art. 26 ust. 6, z tym samym progiem sześciu miesięcy, w obu przypadkach w zakresie dzienników pozostających pod ich kontrolą. Po stronie rachunkowej art. 74 ustawy o rachunkowości daje księgom i zatwierdzonemu sprawozdaniu finansowemu co najmniej pięć lat, licząc od początku roku następującego po roku obrotowym.

Które z tych reżimów obejmują konkretny wskaźnik w waszym raporcie, rozstrzyga prawnik, nie zarząd i nie dział IT – to pytanie o kwalifikację systemu i o charakter dokumentu, w którym liczba wylądowała. Zadaniem rady jest zauważyć samą rozbieżność: okno dowodowe liczone w dniach wobec okna odpowiedzialności liczonego w latach. Ta rozbieżność nie wymaga opinii prawnej, żeby ją zobaczyć w tabeli powyżej.

Co wpisać do rejestru wskaźników przed następnym raportem?

Rejestr wskaźników, w którym stoi tylko definicja i właściciel, nie wyłapie tego problemu. Potrzebuje dwóch dodatkowych rubryk i jednej decyzji wymuszanej ich porównaniem.

Rubryka pierwsza bywa traktowana jako formalność, a jest odwrotnie: jeden wskaźnik potrafi mieć kilka poprawnych odczytów naraz, co widać najlepiej na wskaźnikach liczonych na portfelu klientów. Bez numeru wersji przy definicji porównanie dwóch kolejnych raportów nie ma podstawy, nawet gdy oba źródła jeszcze istnieją.

Kolejność pracy przed najbliższym raportem:

• Wypisać wskaźniki o AI, które weszły do raportu w ostatnich trzech miesiącach, z nazwą źródła przy każdym.
• Dla każdego źródła odczytać retencję z dokumentacji dostawcy i potwierdzić ją na własnej dzierżawie, bo plan licencyjny ją zmienia.
• Policzyć datę utraty odtwarzalności i zestawić ją z horyzontem potrzeby.
• Dla wskaźników, w których retencja jest krótsza niż horyzont, wybrać jedno z trzech: eksport do magazynu o dłuższym terminie, cykliczny zrzut wyliczenia wraz z danymi wejściowymi, albo wykreślenie wskaźnika z raportu.
• Oddzielnie sprawdzić zdarzenia generowane przez tożsamości techniczne agentów, bo mają własny, nieregulowany waszymi politykami zegar.
• Przypisać rolę, która przeliczy każdy wskaźnik bez autora pierwotnego wyliczenia, i sprawdzić to raz na wybranej liczbie z poprzedniego kwartału.

Trzecia opcja przy luce – wykreślenie wskaźnika – jest realnym wyborem, nie figurą retoryczną. Liczba, której nikt nie odtworzy po trzech miesiącach, nie jest tańsza od jej braku; jest droższa, bo buduje przekonanie o kontroli i wraca w uzasadnieniu decyzji inwestycyjnej. Jeśli w organizacji nie ma nikogo z mandatem do wykreślania wskaźników z raportu, to jest to brak w podziale odpowiedzialności, a nie w narzędziach – i jedno z zadań, które bierze na siebie właściciel programu agentowego zatrudniony na części etatu w firmach, które nie obsadzają tej roli na pełny wymiar.

Pytania na najbliższe posiedzenie

• Który wskaźnik o AI w ostatnim raporcie stoi na źródle o retencji krótszej niż sześć miesięcy i kto to sprawdził?
• Jaka jest data, po której nie odtworzymy liczby uzasadniającej ostatnią decyzję o skalowaniu?
• Czy zdarzenia tożsamości technicznych naszych agentów trafiają do magazynu o terminie dłuższym niż rok, a jeśli nie, to kto i kiedy to zmieni?
• Który zapis umowy z dostawcą daje nam dostęp do materiału źródłowego, a nie tylko do agregatów w jego konsoli?
• Kto poza autorem wyliczenia przeliczy dowolny wskaźnik z poprzedniego kwartału i w jakim czasie?
• Kto ma mandat do wykreślenia z raportu wskaźnika, którego nie da się odtworzyć?