Co zapisywać w dzienniku systemu AI i agenta: rejestr zdarzeń, który pomaga cofnąć błąd i wykazać, co się stało

Na stronie o technicznym sprincie zgodności z AI Act piszemy, że projektujemy „uzgodniony, ograniczony do minimum zapis działań systemu” — bez domyślnego archiwum pełnych treści rozmów. AI Act to unijne rozporządzenie o sztucznej inteligencji. Przy agentach AI — programach, które korzystają z modelu AI i wykonują czynności w innych systemach — piszemy o rejestrze działań, czyli zapisie tego, co agent zrobił i na jakiej podstawie. Oba zdania są prawdziwe i oba zostawiają pytanie, które pada na pierwszym spotkaniu technicznym: co konkretnie ma się znaleźć w jednym wpisie? Sama reguła sześciu miesięcy z AI Act na to nie odpowiada. Zaczynamy o krok dalej: od pól, które trzeba zapisać, żeby za trzy miesiące dało się odpowiedzieć, co system zrobił, dlaczego, kto to zatwierdził i co da się z tym jeszcze zrobić.

Opisujemy tu, co zbudować i co zapisywać. Nie rozstrzygamy, czy Twój system jest systemem wysokiego ryzyka w rozumieniu AI Act ani jaka jest podstawa prawna przetwarzania danych — to ocenia prawnik. Od oceny prawnika, czy system wysokiego ryzyka jest już objęty obowiązkiem przechowywania rejestrów zdarzeń, zależy, czy dotyczy Cię poziom 3 opisany niżej; poziomy 1 i 2 wynikają z tego, czy system przetwarza dane osobowe lub ma kontakt z klientami.

Co mówią art. 12, 19 i 26 ust. 6 AI Act — i kogo to w ogóle dotyczy

Rozporządzenie używa nazwy rejestry zdarzeń; w języku technicznym to logi, czyli automatyczne zapisy tego, co system zrobił. My nazywamy je po prostu dziennikiem. Trzy przepisy, wszystkie w rozdziale III, czyli wyłącznie dla systemów wysokiego ryzyka:

• Art. 12 — projekt systemu. System wysokiego ryzyka musi mieć techniczną możliwość automatycznego rejestrowania zdarzeń przez cały cykl życia. Rejestrowane mają być zdarzenia istotne dla trzech celów: wykrywania sytuacji, w których system może stwarzać ryzyko (w rozumieniu art. 79 ust. 1) albo które mogą prowadzić do istotnej zmiany systemu; monitorowania systemu po wprowadzeniu do obrotu; oraz monitorowania jego działania przez podmiot stosujący. To obowiązek dostawcy, czyli podmiotu, który rozwija system albo zleca jego rozwój i wprowadza go do obrotu lub oddaje do użytku pod własną nazwą lub znakiem towarowym (art. 3 pkt 3) — to nie zawsze ten, kto go technicznie wykonuje. Minimalną listę pól rozporządzenie podaje tylko dla systemów z załącznika III pkt 1 lit. a (zdalna identyfikacja biometryczna, art. 12 ust. 3). Dla wszystkich innych zestaw pól jest decyzją projektową, o ile dziennik nadal służy tym trzem celom.
• Art. 19 — dostawca przechowuje. Dostawca przechowuje rejestry zdarzeń z art. 12 ust. 1 „w zakresie, w jakim tego rodzaju rejestry zdarzeń znajdują się pod ich kontrolą”, przez okres stosowny do przeznaczenia systemu, nie krótszy niż sześć miesięcy — z takim samym zastrzeżeniem jak w art. 26 ust. 6: o ile inne przepisy, zwłaszcza o ochronie danych osobowych, nie stanowią inaczej.
• Art. 26 ust. 6 — podmiot stosujący przechowuje. Podmiot, który system wysokiego ryzyka stosuje pod swoją kontrolą i poza osobistą działalnością pozazawodową (firma, instytucja publiczna lub inna osoba), przechowuje automatycznie generowane rejestry zdarzeń, które są pod jego kontrolą, „przez stosowny ze względu na przeznaczenie danego systemu AI wysokiego ryzyka okres, wynoszący co najmniej sześć miesięcy, o ile mające zastosowanie prawo Unii lub prawo krajowe, w szczególności prawo Unii dotyczące ochrony danych osobowych, nie stanowi inaczej”.

Art. 19 i art. 26 ust. 6 to dwa odrębne obowiązki przypisane różnym rolom: dostawcy systemu i podmiotowi stosującemu. Każdy dotyczy rejestrów pod kontrolą danego podmiotu — mogą to być nawet te same rejestry. Samo to, gdzie leżą dane, nie przesądza ani o roli, ani o kontroli. W praktyce, jeżeli system kupujesz jako usługę w chmurze sprzedawcy, część zapisów kontroluje on, a część — na przykład to, co Twoja integracja (program łączący Twoje systemy z modelem) zapisuje po swojej stronie — Ty. Dlatego przy zakupie pytaj, które rejestry da się z panelu sprzedawcy wyeksportować i na jak długo.

Od kiedy. Według tekstu skonsolidowanego na 27 lipca 2026 r. (po zmianach z rozporządzenia 2026/1744, tzw. Digital Omnibus) sekcje 1–3 rozdziału III, a więc art. 12, 19 i 26, stosuje się w odniesieniu do systemów wysokiego ryzyka z załącznika III (listy zastosowań uznanych za wysokie ryzyko, np. w zatrudnieniu czy ocenie zdolności kredytowej) od 2 grudnia 2027 r., a w odniesieniu do systemów wysokiego ryzyka z załącznika I (związanych z unijnymi przepisami o bezpieczeństwie produktów, np. zabawek czy wyrobów medycznych) od 2 sierpnia 2028 r. (art. 113 lit. c). Wyjątek: dla systemów zaklasyfikowanych jako wysokiego ryzyka na podstawie art. 6 ust. 1 i związanych z produktami objętymi przepisami z sekcji B załącznika I, np. maszynami, pojazdami czy wybranymi produktami lotniczymi, art. 12, 19 i 26 nie mają zastosowania (art. 2 ust. 2). Do tego dochodzi przepis przejściowy (art. 111 ust. 2): do operatorów (dostawców, podmiotów stosujących i innych ról z art. 3) systemu wysokiego ryzyka wprowadzonego do obrotu lub oddanego do użytku przed właściwą dla niego datą rozporządzenie stosuje się dopiero wtedy, gdy po tej dacie projekt systemu zostanie istotnie zmieniony. W każdym razie dostawcy i podmioty stosujące systemy wysokiego ryzyka przeznaczone do wykorzystywania przez organy publiczne muszą spełnić wymogi najpóźniej do 2 sierpnia 2030 r. Przepis nie obejmuje elementów wielkoskalowych systemów informatycznych UE, dla których art. 111 ust. 1 ma własny termin, i nie odsuwa zakazów z art. 5. To, czy ten przepis przejściowy obejmuje Twój system, ocenia prawnik. Szerszy kalendarz zebraliśmy w tekście o AI Act w Polsce.

Kiedy to Cię nie dotyczy. Zwykła automatyzacja obiegu faktur, chatbot odpowiadający na pytania o zamówienia czy asystent piszący szkice maili zwykle nie są systemami wysokiego ryzyka i AI Act nie każe im prowadzić rejestrów zdarzeń. Dziennik nadal się opłaca — po to, żeby znaleźć i cofnąć błąd i wyjaśnić decyzję — ale nie potrzebuje sześciomiesięcznego poziomu, o którym niżej. Jeżeli przetwarza dane osobowe, obowiązuje RODO, czyli ogólne rozporządzenie o ochronie danych — niezależnie od AI Act.

Jeden wpis w dzienniku: przykład

Zanim tabela pól, jeden wpis w całości. To przykład ilustracyjny, nie zapis z projektu klienta: agent, który na podstawie maila od klienta proponuje termin spotkania i wpisuje go do kalendarza i do CRM (systemu do obsługi klientów). Kolejność wierszy odpowiada numerom pól z tabeli niżej.

Jedenaście wierszy, które przeczyta osoba bez wykształcenia technicznego. Wrócimy do tego wpisu przy rekonstrukcji błędu, bo ma w sobie dwie wady: jedną w danych, drugą w konfiguracji. W pierwszej wersji takiego agenta umawianie przechodziłoby przez zatwierdzenie przez człowieka; tu zakładamy, że kategorię zwolniono z niego później — i właśnie dlatego dziennik musi pozwolić sprawdzić, czy to była dobra decyzja.

Schemat: jedenaście pól i do czego służy każde z nich

Każde pole ma uzasadnienie w jednej z czterech rzeczy, które dziennik ma umożliwić: cofnąć skutek, wyjaśnić decyzję, poprawić system albo wykazać, co się stało, komuś z zewnątrz. Pole, które nie służy żadnej z nich, jest kosztem przechowywania, a często i ryzykiem.

Cztery uwagi do tabeli.

Zapis przy każdej operacji, a nie tylko na końcu. Jeżeli dziennik powstaje dopiero w ostatnim kroku automatyzacji, a po drodze wpis do kalendarza się uda, a zapis w CRM nie, zostaje skutek bez śladu. Dlatego pole 7 zapisuje się przy każdej operacji: najpierw co agent zamierza zrobić, potem co się faktycznie stało. Oba zapisy łączy ten sam identyfikator operacji, a każda próba ma swój numer. Brak zapisanego wyniku nie oznacza, że operacja się nie wykonała — przed ponowieniem trzeba sprawdzić jej skutek w systemie docelowym albo zastosować zabezpieczenie przed podwójnym wykonaniem. Parametry zapisuje się w zakresie potrzebnym do cofnięcia i wyjaśnienia: treść wiadomości raczej jako odnośnik, a hasła, klucze dostępu i inne dane do logowania nigdy. Podsumowanie na końcu może to uzupełniać, ale nie zastępuje.

Odnośnik, kopia czy skrót — decyzja dla każdego pola osobno. Skrót (hash) to krótki „odcisk” tekstu: porównanie z wcześniej zapisanym i chronionym skrótem pozwala wykryć, że treść się zmieniła, ale skrót nie pozwala tej treści odczytać. Służy więc kontroli integralności, a nie umożliwia odtworzenia decyzji. Żeby zobaczyć, co system dostał, potrzebujesz albo zminimalizowanej kopii w dzienniku, albo odnośnika do rekordu źródłowego, który żyje co najmniej tak długo, jak ustalono, że treść ma być dostępna. Odnośnik do maila, który skrzynka usuwa po miesiącu wbrew ustalonemu okresowi, w trzecim miesiącu jest martwy — i to jest błąd projektu. Planowe usunięcie treści po uzgodnionym terminie błędem nie jest.

Dane osobowe są nie tylko w treści. Identyfikator klienta w polu 5, parametry w polu 7, odpowiedź w polu 8 i osoba zatwierdzająca w polu 10 też mogą być danymi osobowymi. Skrót niczego tu nie załatwia: motyw 26 RODO mówi, że dane spseudonimizowane, które przy użyciu dodatkowych informacji można przypisać osobie, są informacjami o osobie możliwej do zidentyfikowania, a zwykły skrót numeru telefonu może zresztą pozwolić odgadnąć numer przez sprawdzanie kolejnych kandydatów. Każde pole ocenia się więc pod tym kątem osobno.

Uzasadnienie i decyzja człowieka to deklaracje, nie dowód. Pole 8 zapisuje powód, który podał model, a nie wgląd w to, jak faktycznie „myślał”; mocniejsze są reguły i dokumenty, na które da się wskazać. Pola 9 i 10 pokazują, że zatwierdzenie zapisano, a nie to, że było przemyślane. Jak na ich podstawie sprawdzić, czy zatwierdzanie nie stało się klikaniem (mediana czasu decyzji, odsetek korekt, audyt próbki), rozpisaliśmy w tekście o zatwierdzaniu przez człowieka (human in the loop).

Rekonstrukcja: agent umówił spotkanie z niewłaściwym klientem

Wracamy do wpisu z przykładu. Scenariusz jest ilustracyjny, ale każdy krok opiera się wyłącznie na polach z tabeli.

Dzień później dzwoni pan Nowak z pytaniem, dlaczego dostał zaproszenie na spotkanie, o które nie prosił. Prosił inny klient o tym samym nazwisku.

1. Znaleźć krok. Szukamy w polu 7 identyfikatora jego kontaktu (kontakt:5531). Jest jeden wpis z czynnością dotyczącą tego kontaktu, z numerem sprawy spr-2026-10-07-0412.
2. Zrozumieć, co się stało. Pole 5 pokazuje, że wyszukanie w CRM zwróciło dwa kontakty, a pole 8 — że agent wybrał pierwszy. Pole 9 jest puste: pewność modelu była wysoka, bo z jego perspektywy wszystko się zgadzało. To pierwsza wada — dwa trafienia powinny same w sobie być flagą. Druga to konfiguracja z pola 10: kategoria działała bez zatwierdzania.
3. Cofnąć to, co da się cofnąć. Pole 7 zawiera identyfikatory wydarzenie:9930 i notatka:44120 oraz informację, że obie operacje się udały, a zaproszenie wyszło. Usuwamy wydarzenie i wycofujemy notatkę tylko wtedy, gdy system docelowy potwierdzi przy tej czynności, że rekord nadal ma wersję po zapisie z pola 7 — czyli nikt go po agencie nie zmienił. Jeśli wersja się różni albo nie da się tego sprawdzić, decyzję podejmuje człowiek. Wysłanego zaproszenia nie da się cofnąć — panu Nowakowi zostają przeprosiny i sprostowanie. Właściwego klienta ustalamy z maila, do którego prowadzi odnośnik w polu 6.
4. Usunąć przyczynę. Pole 4 mówi, że działała instrukcja umawianie-spotkan v7, w której nie ma reguły „przy więcej niż jednym trafieniu zapytaj albo przekaż sprawę człowiekowi”. Dopisujemy ją jako regułę w automatyzacji, a nie tylko w poleceniu dla modelu — polecenie jest instrukcją, a nie kontrolą. W tej kategorii przywracamy zatwierdzanie, dopóki reguła się nie sprawdzi.
5. Znaleźć podobne sprawy. Ponieważ pole 5 zapisuje liczbę trafień, jedno zapytanie zwraca wszystkie sprawy z ostatnich miesięcy, w których wyszukanie dało więcej niż jeden kontakt, a agent mimo to działał sam. Te sprawdzamy ręcznie.

Bez pól 5 i 7 kroki 1, 3 i 5 zamieniają się w przeszukiwanie kalendarzy i skrzynek, a odpowiedź na pytanie „ile było takich przypadków” brzmi „nie wiemy”. Ile może zrobić agent bez zatwierdzania, zależy od jego uprawnień — to osobna decyzja projektowa, którą opisujemy przy wdrożeniach agentów AI.

Dziennik decyzji a logi aplikacji, historia wykonań n8n i logi u dostawcy modelu

W typowym wdrożeniu zapisy powstają w kilku miejscach i żadne z nich samo w sobie nie daje kompletnego dziennika decyzji:

• Logi aplikacji to zwykle zapisy techniczne dla zespołu deweloperskiego: błędy, czasy odpowiedzi, restarty. Mogą zawierać identyfikatory spraw, ale rzadko mają komplet pól z tabeli.
• Historia wykonań w n8n (narzędziu do budowania automatyzacji) zapisuje dane, które przepłynęły przez automatyzację. Na własnym serwerze n8n domyślnie usuwa zakończone wykonania po 14 dniach albo po przekroczeniu 10 000 wykonań; wykonania w toku, oczekujące i oznaczone adnotacją zostają (stan na 12 października 2026 r.) — szczegóły w przewodniku po n8n. To krótkotrwała kopia danych, a nie dziennik decyzji. Dziennik to osobny krok przy każdej istotnej operacji, który zapisuje wiersz z polami z tabeli do Twojej bazy danych.
• Logi u dostawcy modelu. Stan na 12 października 2026 r. według dokumentacji producentów: w Amazon Bedrock zapis wywołań modelu jest domyślnie wyłączony; po włączeniu trafia do Twoich zasobów w chmurze AWS (CloudWatch Logs albo S3) i zapis trwa, dopóki nie usuniesz jego konfiguracji; jak długo pliki leżą w CloudWatch czy S3, ustawiasz osobno w tych usługach. W interfejsie programistycznym OpenAI (API, czyli sposobie, w jaki program korzysta z usługi) dostawca domyślnie przechowuje logi do monitorowania nadużyć, które mogą zawierać zapytania i odpowiedzi, przez okres do 30 dni. Dłużej — jeżeli wymaga tego prawo lub jest to racjonalnie niezbędne do ochrony usług OpenAI albo osób trzecich przed szkodą. Uprawnieni klienci mogą uzyskać wyłączenie swojej treści (zapytań i odpowiedzi) z tych logów. Osobną sprawą są dane, które przechowują niektóre funkcje API do wykonania zadania (tzw. stan aplikacji): na przykład Responses API domyślnie przechowuje dane odpowiedzi co najmniej 30 dni, a rozmowy zapisane przez Conversations API — dopóki ich nie usuniesz; przy tym usunięcie samej rozmowy nie usuwa jej elementów, które trzeba usunąć osobno. Przy modelach OpenAI w Microsoft Foundry (dawniej Azure OpenAI) w samym modelu nie są przechowywane ani zapytania, ani odpowiedzi. W ramach monitorowania nadużyć wybrane zapytania i odpowiedzi mogą jednak zostać przejrzane automatycznie, a w razie potrzeby także przez człowieka. U klienta zatwierdzonego do zmodyfikowanego monitorowania przechowywanie danych i przegląd przez człowieka nie są prowadzone, a przegląd automatyczny może nadal działać. Niezależnie od tego niektóre opcjonalne funkcje z zapamiętywaniem stanu, takie jak Responses API, przechowują w usłudze historię wiadomości i inne treści, zgodnie z tym, jak je skonfigurujesz.

Logi monitorowania nadużyć służą dostawcy. Zapis wywołań w Bedrock jest Twój i może zawierać przekazany modelowi kontekst sprawy, ale sam nie potwierdza, kto zatwierdził propozycję ani co faktycznie zmieniło się w kalendarzu i w CRM. To wie Twoja integracja, czyli program pośredniczący między Twoimi systemami a modelem. Tam powstaje dziennik. Którędy płyną dane w takim układzie, opisaliśmy na stronie o bezpieczeństwie danych i RODO.

Okres przechowywania: trzy poziomy zamiast jednej liczby

AI Act w art. 26 ust. 6 sam odsyła do prawa ochrony danych („o ile … prawo Unii dotyczące ochrony danych osobowych nie stanowi inaczej”). Napięcie między sześcioma miesiącami a RODO nie rozwiązuje się więc jednym zdaniem, tylko projektem, który się dokumentuje. RODO wymaga, żeby dane były „ograniczone do tego, co niezbędne” (art. 5 ust. 1 lit. c, minimalizacja) i przechowywane w formie umożliwiającej identyfikację osoby „przez okres nie dłuższy, niż jest to niezbędne” (art. 5 ust. 1 lit. e, ograniczenie przechowywania).

Stąd zasada, którą stosujemy: zapis zdarzenia i treść mają osobne, uzasadnione celem okresy przechowywania — okres przechowywania treści jest zwykle krótszy. Pola 1–4, 9 i 11 to w większości identyfikatory, wersje, flagi i liczby, ale jeżeli pozwalają zidentyfikować osobę — samodzielnie lub w połączeniu z innymi informacjami — też są danymi osobowymi. Pole 6 — treść, która przyszła — najczęściej zawiera dane osobowe, dlatego jej okres przechowywania ustalamy według udokumentowanego celu, często krótszy niż dla zapisu zdarzenia. Jeżeli pole 6 jest odnośnikiem, ten okres trzeba zapewnić w systemie źródłowym. Pola 5, 7, 8 i 10 częściej zawierają dane osób wprost. Dlatego ocenia się każde pole i jego możliwe powiązania.

Nasz domyślny podział na trzy poziomy — to projekt, a nie lista z rozporządzenia:

Poziomy mogą się nakładać: jeżeli system spełnia warunki poziomu 3, ten poziom ma pierwszeństwo przed poziomami 1 i 2. Na każdym poziomie inne przepisy, np. rachunkowe, pracownicze czy branżowe, mogą wymagać własnych okresów przechowywania. Sześć miesięcy na poziomie 3 to dolna granica dla rejestrów zdarzeń, a nie zgoda na trzymanie pełnych treści zapytań przez pół roku. O tym, jak długo przechowywać dane osobowe w dzienniku, decyduje administrator danych — czyli firma, która ustala cele i sposoby ich przetwarzania, zwykle Twoja — korzystając z porad prawnika i inspektora ochrony danych, jeżeli go masz. To, jaki okres jest „stosowny” w rozumieniu AI Act i które rejestry są „pod kontrolą” firmy, ocenia prawnik na podstawie faktycznej sytuacji.

Kto może czytać dziennik

Dziennik systemu, który obsługuje klientów, jest jednym z najbardziej wrażliwych zbiorów w firmie, bo zbiera w jednym miejscu to, co w systemach źródłowych leży rozproszone. Art. 32 RODO wymaga środków bezpieczeństwa odpowiednich do ryzyka i wymienia wśród nich pseudonimizację, poufność i integralność systemów oraz regularne testowanie zabezpieczeń. Jak to przełożyć na dziennik, jest wyborem projektowym; nasz domyślny zestaw to trzy zasady. Po pierwsze, ustalasz, kto ma dostęp do zapisu zdarzeń. Po drugie, osobno ograniczasz dostęp do treści: danych wejściowych (pole 6), odpowiedzi (pole 8) i innych pól z danymi wymagającymi dodatkowej ochrony, a każdy odczyt treści sam zostawia ślad. Po trzecie, wpisów nie poprawia się po fakcie: korekta to nowy wpis, a usuwanie danych po upływie terminu albo na żądanie osoby odbywa się ustaloną procedurą, która zapisuje sam fakt usunięcia, bez usuniętej treści.

Przegląd dziennika robi się regularnie, z częstotliwością zależną od ryzyka — na start proponujemy raz w tygodniu. Trzy pytania: czy pojawiły się sprawy z flagami, których nikt nie obejrzał, czy w którejś kategorii nagle skoczył odsetek korekt i czy koszt albo czas odpowiedzi skoczyły po zmianie wersji modelu lub instrukcji.

Żądanie usunięcia danych: co skasować z dziennika

Klient składa żądanie usunięcia danych (art. 17 RODO). Najpierw administrator danych, z pomocą prawnika, ocenia, czy zachodzi któraś z przesłanek usunięcia z art. 17 ust. 1 i czy ma zastosowanie wyjątek z art. 17 ust. 3. Jeżeli dane trzeba usunąć, z dziennika usuwa się to, co pozwala tę osobę zidentyfikować: zapisaną treść zapytań i odpowiedzi, kopie dokumentów, a także identyfikatory, parametry, odnośniki i skróty prowadzące do jej danych. Osobna tabela na treść, powiązana numerem sprawy, ułatwia usunięcie samej treści, ale pozostałe pola trzeba ocenić i obsłużyć tak samo. To, co po tym zostaje, jest anonimowe tylko wtedy, gdy rzeczywiście nie da się go powiązać z osobą. Ten sam problem po stronie samego modelu i indeksów wyszukiwania opisaliśmy w tekście „RODO a wdrożenie LLM”.

Test odtworzenia: decyzja sprzed 90 dni

Na koniec praktyczny sprawdzian, czy dziennik działa. To jeden test na jednej sprawie, więc nie zastąpi sprawdzenia uprawnień ani procedury usuwania, ale szybko pokazuje luki. Wylosuj sprawę sprzed 90 dni — albo, jeśli zapis zdarzeń przechowujesz krócej, z najstarszego okresu objętego ustalonym okresem przechowywania; nie wybieraj, wylosuj — i odpowiedz na sześć pytań, korzystając wyłącznie z dziennika i systemów, do których prowadzą jego odnośniki:

1. Co przyszło do systemu — a jeżeli treść usunięto zgodnie z ustalonym okresem, czy dziennik pokazuje, skąd przyszła i kiedy ją usunięto?
2. Który model, w jakiej wersji i z jaką wersją instrukcji przygotował wynik?
3. Z jakich dokumentów lub rekordów korzystał?
4. Co zrobił w których systemach, czy operacje się udały i jakie rekordy po sobie zostawił?
5. Czy wynik zatwierdzono, odrzucono, czy zatwierdzenie było niewymagane — kto i kiedy zdecydował albo która reguła zwalniała z zatwierdzenia — i co zmieniono?
6. Co z tego da się dziś cofnąć albo poprawić — i co dokładnie trzeba by zrobić?

Każde „nie wiem”, którego nie tłumaczy planowe usunięcie, wskazuje brakujące pole albo odnośnik, który przestał działać wcześniej, niż zakładał projekt. Dlatego pierwszy taki test robimy już w pilotażu — na sprawach sprzed kilku tygodni — i wpisujemy go do kryteriów, które ustalamy przed jego startem, jak opisujemy w metodyce wdrożenia. Dobudowanie tych pól do działającego systemu jest droższe niż zaprojektowanie ich od razu, bo części historii po prostu już nie ma.

Jeżeli chcesz sprawdzić, czego brakuje w dzienniku Twojego systemu albo jak go zaprojektować przed startem, opisaliśmy ten zakres przy technicznym sprincie zgodności z AI Act — w zakresie, który ustali Twój prawnik.

Źródła i stan prawny na 12 października 2026 roku

• Rozporządzenie (UE) 2024/1689 (AI Act) — tekst skonsolidowany na 27 lipca 2026 r. na EUR-Lex (CELEX 02024R1689-20260727) — art. 2 ust. 2, 3 pkt 4, 12, 19, 26 ust. 6, 111 ust. 2, 113 lit. c i załącznik I. Brzmienie przepisów sprawdzone w kopii z Urzędu Publikacji UE 12 października 2026 r.
• Rozporządzenie (UE) 2016/679 (RODO) na EUR-Lex — art. 5 ust. 1 lit. c i e, art. 17, art. 32 i motyw 26.
• Amazon Bedrock — Monitor model invocation using CloudWatch Logs and Amazon S3, odczyt 12 października 2026 r.
• OpenAI — Data controls in the OpenAI platform, odczyt 12 października 2026 r.
• Microsoft Learn — Data, privacy, and security for Foundry Models sold by Azure, odczyt 12 października 2026 r.