Dokumentacja publiczna
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 wg RFC 6962 · weryfikacja offline · AGPL-3.0
Dotyczy PATRONa 1.3.0. Strona opublikowana 23 sierpnia 2026, ostatnia aktualizacja 24 sierpnia 2026.
Ś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.
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.
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.
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.
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.
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.
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.
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.
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, zgodnie z konwencją RFC 6962 stosowaną w Certificate Transparency.
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), sam algorytm z RFC 6962.
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.
Artykuł 12 rozporządzenia (UE) 2024/1689 wymaga od systemów wysokiego ryzyka automatycznego rejestrowania zdarzeń przez cały cykl życia systemu. Poniżej zestawienie wymogu z tym, co dziennik faktycznie zapisuje.
| Wymóg z art. 12 | 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.
Ł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.
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.
Dlaczego akurat RFC 6962?
To sprawdzona w praktyce specyfikacja Certificate Transparency, używana do publicznego audytu certyfikatów w internecie. Ma jawnie opisaną regułę budowy drzewa i formatu dowodu, więc audytor może napisać własny weryfikator zamiast ufać naszemu. Sięgnięcie po istniejący standard było tańsze i bezpieczniejsze niż wymyślanie swojego.
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.
PATRON działa na sprzęcie kancelarii. Dziennik, weryfikator i kod są dostępne od pierwszego uruchomienia.