Pakuje output AI prawny w artefakt audytowy zgodny z AI Act art. 12 - łączy deliverable, ślad rozumowania (debata / grounding), log kosztu i metadane (model, data, źródła, kto zatwierdził) w jeden ustrukturyzowany folder z manifestem i hashami integralności SHA256. Generalizacja matematic-video-governance na dowolny output prawny. Dowód należytej staranności i record-keepingu. Używaj gdy: "spakuj audyt", "bundle zgodności", "artefakt AI Act", "ślad rozumowania do archiwum", "dokumentacja outputu AI", "record-keeping", "co archiwizować dla AI Act", "log kosztu i decyzji", "paczka audytowa deliverable", po zakończeniu opinii / adversarial-legal-review / grounding gdy trzeba zarchiwizować dowód.
Instrucciones de origen · Vista previa de solo lectura
name
legal-ai-audit-bundle
description
Pakuje output AI prawny w artefakt audytowy zgodny z AI Act art. 12 - łączy deliverable, ślad rozumowania (debata / grounding), log kosztu i metadane (model, data, źródła, kto zatwierdził) w jeden ustrukturyzowany folder z manifestem i hashami integralności SHA256. Generalizacja matematic-video-governance na dowolny output prawny. Dowód należytej staranności i record-keepingu. Używaj gdy: "spakuj audyt", "bundle zgodności", "artefakt AI Act", "ślad rozumowania do archiwum", "dokumentacja outputu AI", "record-keeping", "co archiwizować dla AI Act", "log kosztu i decyzji", "paczka audytowa deliverable", po zakończeniu opinii / adversarial-legal-review / grounding gdy trzeba zarchiwizować dowód.
license
Apache-2.0
allowed-tools
["Bash","Read","Write"]
data-residency
local
requires-human-approval
false
pii-egress
none
attribution
{"source":"AnttiHero/lavern","license":"Apache-2.0","relationship":"pattern-only","note":"Wzorzec paczki audytowej; wzór własny matematic-video-governance (AI Act art. 12).\n"}
Legal AI Audit Bundle - artefakt zgodności dla outputu AI prawnego
Filozofia
Jeśli nie potrafisz odtworzyć, jak AI doszło do wyniku, nie powinieneś wysyłać tego wyniku.
AI Act art. 12 wymaga rejestrowania zdarzeń (prowadzenia rejestrów) dla systemów wysokiego ryzyka,
art. 14 - nadzoru człowieka, art. 50 - poinformowania osoby, że treść została wygenerowana przez AI.
Dla kancelarii używającej AI w pracy
z klientem oznacza to: dla każdego istotnego deliverable musi istnieć ślad - jaki model, jakie
źródła, jaka weryfikacja, jaki koszt, kto zatwierdził. Ten skill składa ten ślad w jedną paczkę
z hashami integralności, tak by dało się ją odtworzyć i wykazać przy audycie.
To nie jest deliverable dla klienta. To deliverable dla audytora, regulatora i Twojej własnej
odpowiedzialności zawodowej.
Co wchodzi do paczki
Artefakt
Źródło
Wymagane
Deliverable finalny
praca prawna
TAK
Ślad rozumowania
transcript adversarial-legal-review-pl lub log analizy
mapa let-it-be (jeśli użyta) - TRZYMANA OSOBNO, nie w paczce
warunkowo
Workflow
Zbierz artefakty - upewnij się, że istnieją pliki: deliverable, transcript/ślad,
raport grounding, log kosztu. Brakujące oznacz w manifeście jako MISSING - paczka i tak
powstaje, ale z widoczną luką (audytor musi widzieć, czego nie ma).
Opisz manifest - przygotuj descriptor JSON (patrz FORMAT) z metadanymi i ścieżkami do
artefaktów.
Skrypt: kopiuje artefakty do ustrukturyzowanego folderu, liczy SHA256 każdego pliku
(integralność), generuje manifest.json + czytelny INDEX.md.
Zweryfikuj kompletność - skrypt zwraca listę i ostrzega, jeśli brak
record-keepingu wymaganego dla high-stakes. Uzupełnij albo świadomie odnotuj brak.
MISSING
Archiwizuj - paczka idzie do rejestru AI kancelarii. Mapa pseudonimizacji NIGDY nie ląduje
w paczce - trzymana osobno, dostęp ograniczony (to klucz do re-identyfikacji = dane osobowe).
Format descriptora (input skryptu)
{"deliverable_id":"OPINIA-2026-018","tytul":"Opinia w sprawie ważności klauzuli X","data":"2026-05-22","model":"claude-opus-4-7","autor":"Wiesław Mazur","zatwierdzajacy":"adw. ...","stawka":"WYSOKA","zrodla":["II CSK NN/RR","art. 385(1) KC","CELEX 32024R1689"],"pseudonimizacja_uzyta":true,"artefakty":{"deliverable":"sciezka/do/opinia-final.md","slad_rozumowania":"sciezka/do/adversarial-transcript.md","raport_grounding":"sciezka/do/grounding-report.json","log_kosztu":"sciezka/do/cost.json"}}
Pole zrodla to lista dowolnych identyfikatorów źródeł w formie tekstowej (sygnatura, oznaczenie
przepisu, numer CELEX, nazwa pliku) - skrypt zapisuje je bez parsowania, służą tylko do opisu paczki.
## Paczka audytowa: OPINIA-2026-018
Zlokalizowana: <katalog>/OPINIA-2026-018/
Artefakty: 4/4 obecne | 0 MISSING
Integralność: 4 pliki zahashowane (SHA256 w manifest.json)
High-stakes: TAK → wymóg śladu rozumowania SPEŁNIONY ✅
Pseudonimizacja: użyta → mapa NIE w paczce (trzymaj osobno) ⚠️
Gotowe do archiwizacji w rejestrze AI kancelarii.
Ochrona danych (RODO)
Skill działa lokalnie - kopiowanie plików i hashowanie w Node, bez sieci.
Mapa pseudonimizacji nigdy nie wchodzi do paczki - to klucz re-identyfikacji (dane osobowe
art. 4 pkt 5 RODO). Paczka audytowa ma być bezpieczna do pokazania audytorowi; mapa - nie.
Jeśli deliverable zawiera dane wrażliwe, rozważ przechowywanie w paczce hasha + lokalizacji
zamiast pełnej treści (decyzja kancelarii / inspektora ochrony danych).
art. 50 poinformowanie o AI: INDEX.md mówi jasno, że wynik powstał z udziałem AI i jakiego modelu.
art. 14 nadzór: pole zatwierdzajacy = człowiek wziął odpowiedzialność.
Wejścia produkują: adversarial-legal-review-pl (ślad), citation-grounding-pl (raport).
Pokrewny: matematic-video-governance robi to samo dla wideo; ten skill - dla pism prawnych.
Roadmap upgrade integralności: Merkle chain nad SHA256
Obecna wersja składa paczkę z SHA256 per artefakt w manifest.json. To wystarczy dla pojedynczego
deliverable, ale przy kancelarii produkującej setki opinii rocznie audytor chce zweryfikować
integralność dowolnej paczki bez czytania całego rejestru AI.
Cherry-pick wzorca z microsoft/agent-governance-toolkit
(MIT, "Merkle-chained audit log"): nad zbiorem hashes paczek buduje się Merkle tree, root chain'owany
z poprzednim rootem. Proof-of-inclusion dla pojedynczej paczki w O(log n) zamiast O(n).
Praktycznie dla kancelarii (planowane, nie zaimplementowane):
Każda paczka audytowa po złożeniu rejestruje swój manifest_hash w rejestrze AI kancelarii.
Co N paczek (np. N=64) liczy się Merkle root + zapisuje obok poprzedniego (chain).
Audytor pyta "czy paczka OPINIA-2026-018 jest integralna i istniała wtedy gdy twierdzicie" →
verifier zwraca proof O(log 64) zamiast hash całego rejestru.
Wartość dla AI Act art. 12: kancelaria po 5 latach działania ma dziesiątki tysięcy paczek;
weryfikacja "ten log nie był modyfikowany od 2027 r." musi być efektywna. SHA256-per-paczka
zostaje (wymagany dla detekcji modyfikacji w obrębie paczki), Merkle dodany dla efektywnej
weryfikacji rejestru.
Status: roadmap, do zaplanowania w osobnym sprintcie. Nie blokuje obecnego użycia skilla.
Komplementarne do Merkle, nie zamienne. Merkle daje integralność lańcucha audytu (audytor wie, że log nie był modyfikowany). Proof receipt daje dowód konkretnej pojedynczej decyzji (audytor wie, że "decyzja X z 2025-09-12 14:23 została zaakceptowana zgodnie z polityką wersji Y").
Cherry-pick wzorca z ICME Preflight (cloud-only, NIE wpinamy jako zależność z powodu Art. 1 lokalności danych - patrz ADR-0031 PATRON). Wzorzec lokalny:
Każda paczka audytowa (OPINIA-2026-018) opcjonalnie zawiera plik policy-verdict.json:
{"check_id":"0f25c151-e63e-4253-8eb2-1e6e894c7ce5","policy_hash":"60c79bbc4f8ac087de1110fa0e347292f35b6d2943a2a4ccd18ae991a5d64418","verdict":"ALLOWED","policy_version":"v1.4 z 2025-08-15","timestamp":"2025-09-12T14:23:00Z"}
policy_hash to SHA256 ze skompilowanej polityki (Konstytucja AI kancelarii w wersji obowiązującej w momencie decyzji).
Audytor (regulator UODO, KIRP, klient kancelarii) dostaje paczkę audytową + binarkę kancelaria-verify która offline weryfikuje, że policy_hash zgadza się z zarchiwizowaną polityką + verdict jest deterministyczny dla tej polityki.
Public surface lokalnie: proof-listing.html w paczce audytowej generuje czytelną stronę "X decyzji weryfikowanych w tym kwartale, lista check_id, polityka v1.4 obowiązywała".
Wartość dla AI Act art. 12 + art. 26: kancelaria nie pokazuje audytorowi "ufaj mi że logowaliśmy". Pokazuje "tu jest 47 proof receiptów, każdy z policy_hash, polityka v1.4 SHA256 5f3a..., zweryfikuj sam offline".
Status: roadmap. Razem z Merkle składają się na pełną warstwę audytu: Merkle (integralność lańcucha) + proof receipt (dowód decyzji) + paczka audytowa (kontekst sprawy). Trzy warstwy dla różnych pytań audytora.
Atrybucja
Pattern (audit-bundle alongside deliverable) zainspirowany przez AnttiHero/lavern (Apache 2.0)
oraz własny wzór matematic-video-governance. Struktura, manifest i skrypt napisane od zera pod
AI Act i polskie realia kancelaryjne.
Pattern Merkle-chain upgrade (sekcja Roadmap) zainspirowany przez
microsoft/agent-governance-toolkit (MIT, Microsoft Corp., 2026).
Cherry-pick wzorca, nie kodu - implementacja od zera w Node pod Postgres kancelarii.
Pattern per-decision proof receipt (sekcja Roadmap 2) zainspirowany przez
ICME Preflight (cloud-only SaaS, autor Houman Shadab, Stanford CodeX Fellow,
snapshot 2026-05-24) - patrz hshadab/preflight-mike (MIT)
oraz ICME-Lab/icme-preflight-guardrail (MIT).
NIE wpinamy ICME jako zależność (cloud-only narusza Art. 1 lokalności danych Patrona) -
cherry-pick wzorca tylko, lokalny offline solver + verifier napisany od zera. Patrz ADR-0031 PATRON
dla pełnych granic decyzji architektonicznej.
