Dokumentacja publiczna
Dziennik, który audytor sprawdzi bez zaufania do nas
PATRON zapisuje każdą interakcję z modelem w łańcuchu skrótów SHA-256, a nad łańcuchem buduje drzewo Merkle. Kancelaria może udowodnić, że historia pracy z AI nie została zmieniona po fakcie, i zrobić to bez dostępu do naszych serwerów oraz bez ujawniania treści akt.
SHA-256 · drzewo Merkle · weryfikacja offline · AGPL-3.0
Dotyczy PATRONa 1.3.0. Strona opublikowana 23 sierpnia 2026, ostatnia aktualizacja 24 sierpnia 2026.
Czym jest ślad audytowy w systemie AI
Ślad audytowy w systemie AI to rejestr zdarzeń, który pozwala odtworzyć, kto zadał pytanie, kiedy, jakim modelem zostało obsłużone, na jakich źródłach oparła się odpowiedź i kto ją zatwierdził. Sama historia czatu tym nie jest. Historię czatu da się edytować i usunąć bez śladu, a ślad audytowy ma wykrywać właśnie taką zmianę.
Różnica jest praktyczna. Gdy dział compliance albo sąd pyta „jak powstała ta odpowiedź", kancelaria z historią czatu ma zrzut ekranu, a kancelaria ze śladem audytowym ma dowód, który weryfikuje się mechanicznie i którego poprawność nie zależy od dobrej woli dostawcy oprogramowania.
Co PATRON zapisuje w dzienniku
Dziennik obejmuje pracę z modelem, dostęp administracyjny do samego dziennika i operacje na danych osobowych. Lista typów zdarzeń jest zamknięta i pilnowana ograniczeniem CHECK w bazie, więc nowy typ nie pojawi się w logu bez migracji, którą widać w historii kodu.
Praca z modelem
RejestrowanePytanie użytkownika i odpowiedź asystenta, wybór trasy modelu, uruchomienie potoku obronnego przed wstrzyknięciem promptu, zatwierdzenie zmiany przez człowieka, kontrola źródeł w przeglądzie tabelarycznym, limit kosztu.
Dostęp do dziennika
Meta-audytOtwarcie podglądu audytu, eksport paczki dowodowej, wymuszenie przeliczenia korzenia Merkle, wgląd w metryki. Zamiar wyniesienia dowodu na zewnątrz zostaje zapisany, zanim dowód opuści system.
Dane osobowe i konfiguracja
RejestrowaneRealizacja żądania usunięcia i eksportu danych z RODO, zgoda na przetwarzanie w chmurze dla konkretnego projektu, włączenie i wyłączenie konektora źródła prawa, edycja dokumentu.
Ograniczenie projektowe: pole payload zdarzenia trzyma liczby, identyfikatory i wartości słownikowe. Treści dokumentów ani danych osobowych tam nie ma. To warunek tego, żeby paczkę dowodową dało się wynieść do audytora bez wynoszenia akt klienta.
Jak zbudowany jest łańcuch
Dziennik jest rejestrem tylko do dopisywania. Każdy rekord przechowuje skrót rekordu poprzedniego w polu prev_hash oraz własny skrót hash, policzony z połączenia prev_hash i kanonicznej postaci JSON pozostałych pól zdarzenia: znacznika czasu, typu zdarzenia, identyfikatora osoby, sprawy, dokumentu i ładunku.
Pierwszy rekord w systemie ma prev_hash złożony z sześćdziesięciu czterech zer. Serializacja jest deterministyczna i niezależna od kolejności kluczy w JSON, więc ten sam zestaw danych zawsze daje ten sam skrót, także po przeniesieniu bazy na inną maszynę.
Usunięcie albo zmiana wpisu w środku dziennika rozrywa ciągłość ogniw. Nie da się podmienić jednego zdarzenia bez przeliczenia wszystkich następnych, a to zostawia ślad w korzeniach Merkle policzonych wcześniej.
Wybraliśmy łańcuch skrótów zamiast dziennika podpisywanego kluczem prywatnym, bo podpis wymaga zarządzania kluczem i jego rotacji po stronie kancelarii. Cena tej decyzji jest opisana niżej, w sekcji o granicach.
- hash = SHA-256( prev_hash + canonical_json(zdarzenie) )
- prev_hash rekordu genesis = 64 zera
- kanoniczny JSON: kolejność kluczy bez znaczenia
- zapis wyłącznie przez dopisanie, bez UPDATE
- typ zdarzenia z zamkniętej listy (CHECK)
Drzewo Merkle nad łańcuchem
Sam łańcuch wykrywa zmianę. Żeby go sprawdzić, trzeba jednak przejść cały dziennik od początku. Drzewo Merkle rozwiązuje ten problem: pozwala udowodnić przynależność jednego zdarzenia do zapieczętowanego bloku, bez ujawniania pozostałych zdarzeń z tego bloku.
Liście
WejścieLiśćmi drzewa są gotowe skróty zdarzeń z łańcucha. Nie liczymy ich drugi raz, więc warstwa Merkle nie modyfikuje dziennika i jest wobec niego operacją tylko do odczytu.
Węzły
RegułaWęzeł wewnętrzny to SHA-256 z połączenia skrótu lewego i prawego dziecka. Przy nieparzystej liczbie węzłów na poziomie ostatni jest powielany. To nasza obecna reguła, nie reguła RFC 6962: standard dodaje prefiksy 0x00 i 0x01 i nie powiela węzłów.
Korzeń
WynikKorzeń zapisujemy razem z zakresem bloku, liczbą zdarzeń, czasem i informacją, kto go policzył. Przeliczenie uruchamia administrator albo wyzwalacz automatyczny po przekroczeniu liczby zdarzeń lub odstępu czasu.
Algorytm jest deterministyczny: ten sam blok zdarzeń zawsze daje ten sam korzeń. Wzorzec warstwy pochodzi z microsoft/agent-governance-toolkit (licencja MIT), a konstrukcja drzewa jest wzorowana na Certificate Transparency (RFC 6962), jeszcze bez pełnej zgodności ze standardem.
Trzy ścieżki weryfikacji
Każda z trzech ścieżek daje inny zasięg dowodu i inny koszt sprawdzenia. Wybór zależy od tego, czy audytor bada pojedyncze zdarzenie, całą historię, czy dowód wyniesiony poza kancelarię.
Polecenie npm run audit:verify przechodzi dziennik liniowo i przelicza każde ogniwo. Wykrywa wpis usunięty ze środka, przestawiony albo zmieniony po fakcie. Koszt rośnie liniowo z liczbą zdarzeń. Nie publikujemy czasu dla miliona wpisów, bo go nie zmierzyliśmy na produkcyjnym zbiorze; liniowość wynika z samego algorytmu i tyle można stwierdzić bez pomiaru.
Dowód Merkle zwraca ścieżkę siostrzanych skrótów od zdarzenia do korzenia bloku. Audytor przelicza ją sam i porównuje z zapisanym korzeniem. Pozostałe zdarzenia z bloku zostają zakryte. Przy tajemnicy zawodowej to bywa warunkiem, na którym audyt w ogóle się odbędzie.
Paczka dowodowa jest samodzielnym plikiem. Weryfikator uruchamiasz poleceniem python verify.py. Korzysta wyłącznie z biblioteki standardowej Pythona 3.8 lub nowszej. Nie łączy się z siecią i nie potrzebuje dostępu do bazy kancelarii.
Weryfikator paczki działa trzystopniowo: sprawdza sumy kontrolne każdej części względem manifestu, potem ciągłość ogniw w wyciągu z dziennika, na końcu skrót całości. Zwraca kod wyjścia 0 dla paczki nienaruszonej, 1 dla naruszonej i 2 przy błędzie odczytu, więc wepniesz go w skrypt, nie tylko odpalisz ręcznie.
Co z tego wynika dla art. 12 EU AI Act
Artykuł 12 rozporządzenia (UE) 2024/1689 wymaga, żeby systemy wysokiego ryzyka technicznie umożliwiały automatyczne rejestrowanie zdarzeń przez cały cykl życia systemu. Poniżej praktyczne rozwinięcie tego wymogu, zestawione z tym, co dziennik faktycznie zapisuje.
| Cel rejestru w naszej lekturze, nie cytat z artykułu | Co zapisuje PATRON |
|---|---|
| Rejestrowanie zdarzeń w trakcie działania | Każde pytanie i odpowiedź jako osobne zdarzenie ze znacznikiem czasu, dopisywane bez możliwości edycji |
| Identyfikacja osób sprawujących nadzór | Identyfikator osoby przy każdym zdarzeniu oraz osobny typ zdarzenia dla zatwierdzenia zmiany przez człowieka |
| Dane wejściowe prowadzące do wyniku | Wybór trasy modelu, źródła powołane w odpowiedzi i wynik kontroli źródeł w trzech klasach |
| Wersja systemu i konfiguracja | Wersje aplikacji i konektorów w paczce dowodowej, wraz z odciskiem użytych promptów |
| Możliwość wykazania zgodności organowi | Eksport paczki weryfikowalnej poza systemem; sam eksport też trafia do dziennika |
Interpretacja MateMatic dotycząca AI Act i RODO, nie stanowisko NRA ani KRRP. Przy formalnej ocenie zgodności należy sięgnąć do tekstu skonsolidowanego w EUR-Lex, CELEX 32024R1689. Kwalifikacja konkretnego wdrożenia jako systemu wysokiego ryzyka zależy od zastosowania po stronie kancelarii, nie od samego narzędzia.
Czego ten ślad nie dowodzi
Łańcuch skrótów wykrywa zmianę zapisu. To nie to samo co dowód, kto zapis wytworzył. Bez podpisu kryptograficznego kancelaria może zaprzeczyć, że dana paczka pochodzi od niej, i sam skrót tego nie rozstrzygnie.
Podpis Ed25519 wraz ze znacznikiem czasu wg RFC 3161 jest u nas zarezerwowany jako osobna decyzja architektoniczna i nie jest zaimplementowany. Piszemy to wprost, bo różnica między wykryciem zmiany a niezaprzeczalnością bywa w sporze rozstrzygająca.
Nie prowadzimy też narzuconej polityki retencji. Dziennik rośnie, dopóki kancelaria go trzyma, a okres przechowywania pozostaje jej decyzją i musi być pogodzony z RODO oraz z zasadami tajemnicy zawodowej.
Każde z tych ograniczeń da się sprawdzić w kodzie: brak podpisu w module budującym paczkę, brak reguły czyszczenia w schemacie bazy.
- wykrywa zmianę zapisu, nie autorstwo
- brak podpisu i znacznika czasu zaufanej strony
- retencja pozostaje decyzją kancelarii
- paczka dowodzi spójności, nie trafności odpowiedzi
- weryfikacja całego łańcucha rośnie liniowo
Częste pytania o ślad audytowy
Czym ślad audytowy różni się od historii czatu?
Historię czatu da się zmienić i nikt tego nie zauważy. Ślad audytowy wiąże zapisy skrótami, więc usunięcie albo podmiana wpisu rozrywa ciągłość i wychodzi na jaw. Czat odpowiada na pytanie „co". Ślad audytowy na pytanie „czy na pewno tak było".
Jak sprawdzić ślad audytowy w systemie AI kancelarii?
Poproś dostawcę o opis algorytmu, weryfikator działający bez połączenia z jego serwerem i przykładową paczkę dowodową. Jeśli weryfikacja wymaga zalogowania się u dostawcy, to nie jest audyt, tylko zwiedzanie: sprawdzasz cudze twierdzenie cudzym narzędziem. Odpowiedź „mamy pełny audit log" nie znaczy nic, dopóki nie zobaczysz, czym go sprawdzić.
Czy audytor musi mieć dostęp do akt klienta?
Nie. Nic z tego, co dostaje audytor, nie zawiera treści dokumentu, a dane osobowe serwer maskuje, zanim paczka opuści system. Dowodem Merkle potwierdzisz pojedyncze zdarzenie, nie odsłaniając reszty bloku.
Czy to jest RFC 6962?
Jeszcze nie w pełni. Drzewo jest wzorowane na Certificate Transparency, ale dziś różni się od RFC 6962 w dwóch miejscach: nie dodaje prefiksów 0x00 i 0x01 przed haszowaniem i powiela ostatni węzeł przy nieparzystej liczbie. Reguła jest jawnie opisana na tej stronie, więc audytor i tak może napisać własny weryfikator. Pełną zgodność z RFC 6962 planujemy w PATRON 2.0, z nową wersją formatu eksportu, żeby starsze paczki dalej dało się zweryfikować.
Kto może wyeksportować paczkę dowodową?
Zależy, o którą paczkę chodzi. Archiwum pojedynczego zdarzenia z dziennika eksportuje administrator z listy adresów prowadzonej przez kancelarię. Pakiet dowodowy całego pisma pobiera jego autor, bo granicą jest sprawa, nie rola. Dziennik zapisuje zamiar wyniesienia dowodu w obu przypadkach, zanim dowód powstanie.
Czy otwarty kod nie ułatwia obejścia zabezpieczeń dziennika?
Bezpieczeństwo tego rozwiązania nie opiera się na tajemnicy algorytmu, tylko na własnościach funkcji skrótu. Jawność kodu pozwala kancelarii i jej audytorowi sprawdzić, że zapisujemy to, co deklarujemy. Rozwiązanie zamknięte wymagałoby przyjęcia takiej deklaracji na słowo.
Sprawdź to na własnych danych
PATRON działa na sprzęcie kancelarii. Dziennik, weryfikator i kod są dostępne od pierwszego uruchomienia.