k0nsult.cloud / ai-truth / ipIII / oversight / oversight-ledger

Human Oversight Ledger + testy regresyjne AI

Człowiek decyduje, AI tylko rekomenduje — a każda taka decyzja zostawia ślad. Ta strona opisuje dwa sprzężone rejestry MVP: Oversight Ledger (kto zatwierdził, na jakim dowodzie, czy AI radziło inaczej, pod jaką presją czasu, z jakim wynikiem) oraz AI Regression Tests (każdy incydent AI — prompt injection, wyciek danych, niebezpieczne wywołanie narzędzia — zamieniony w powtarzalny test defensywny). Dane na stronie są syntetyczne, ilustracyjne. Realizacja odpowiada na wymóg nadzoru człowieka z AI Act art. 14.

Orchestrator AI incident Model risk Znane ograniczenia Compliance Oversight Ledger ← ipIII hub

Status: MVP. To wczesna, dowodliwa wersja dwóch rejestrów — schemat danych i przepływ są zdefiniowane, część funkcji jest jeszcze ROADMAP (oznaczone jawnie niżej). Zgodnie z doktryną claim ≤ proof: nie twierdzimy, że każdy przypadek nadzoru jest już zapisywany automatycznie w środowisku klienta. Ledger pokazuje, jaki ślad decyzyjny chcemy utrwalać i jak zamieniamy incydent w test. Wszystkie wpisy poniżej to dane syntetyczne. AI i testy bezpieczeństwa są tu wyłącznie defensywne, na danych fikcyjnych, po pisemnych Rules of Engagement — bez treści służących naruszeniu.

Decyzja należy do człowieka. Ślad należy do rejestru.

AI Act art. 14 wymaga, by systemy wysokiego ryzyka podlegały skutecznemu nadzorowi człowieka: operator musi móc zrozumieć rekomendację, ją zignorować lub cofnąć oraz nie ulegać automatycznemu zaufaniu (automation bias). Oversight Ledger operacjonalizuje ten wymóg — zapisuje moment, w którym człowiek przejął odpowiedzialność za rekomendację modelu. AI Regression Tests domykają pętlę: każdy zaobserwowany incydent AI staje się testem, który ma nie dopuścić do jego powtórki.

PĘTLA NADZORU: AI rekomenduje→człowiek ocenia dowód→decyzja + wpis do Ledgera→wynik obserwowany→incydent → test regresyjny

1. Human Oversight Ledger — rejestr decyzji

Każdy wiersz = jedna decyzja człowieka nad rekomendacją AI. Kolumny odpowiadają wprost na pytania audytora art. 14: kto, co zatwierdził, na jakim dowodzie, czy AI radziło inaczej, pod jaką presją czasu i z jakim wynikiem. Poniżej dane syntetyczne (2026-07-05).

ID / czas	Decydent (rola)	Decyzja	Dowód (evidence)	Rekomendacja AI	Presja czasu	Wynik
`OVL-0001` syntet.	SOC L2 człowiek	Zatwierdził eskalację findingu do incydentu	2 alerty skanera + korelacja z evidence-package `#EP-114`	zgodna — AI też rekomendowało eskalację	niska — pełny SLA	trafna — retest potwierdził
`OVL-0002` syntet.	Analityk GRC człowiek	Odrzucił auto-klasyfikację „high" dla findingu	kontekst biznesowy: system testowy, brak danych produkcyjnych	rozbieżna — AI proponowało „high", człowiek dał „medium"	niska	trafna — override uzasadniony, zapisany
`OVL-0003` syntet.	Dyżurny IR człowiek	Wstrzymał automatyczną rekomendację izolacji hosta	host krytyczny; brak potwierdzenia drugim źródłem	rozbieżna — AI rekomendowało natychmiastową izolację	wysoka — nocny dyżur	częściowo trafna — opóźnienie 20 min, bez szkody; do przeglądu
`OVL-0004` syntet.	Radca prawny człowiek	Zatwierdził draft powiadomienia organu przed wysyłką	Legal Trigger Engine: sugestia terminu DORA + treść draftu	zgodna po korekcie — człowiek poprawił podstawę prawną	średnia — bieg terminu	trafna — wysłano po przeglądzie
`OVL-0005` syntet.	SOC L1 człowiek	Zaakceptował rekomendację zamknięcia jako false-positive	reguła znana, sygnatura potwierdzona jako benign	zgodna	wysoka — kolejka alertów	do rewizji — flaga automation bias: akcept bez pełnej weryfikacji

Po co kolumna „presja czasu" i „rekomendacja AI". Art. 14 wprost adresuje ryzyko, że człowiek pod presją bezrefleksyjnie zatwierdzi wyjście modelu (automation bias). Rejestrując, czy AI radziło inaczej i pod jaką presją zapadła decyzja, dajemy audytorowi materiał do wykrycia wzorca: jeśli człowiek zawsze zgadza się z AI przy wysokiej presji, to sygnał, że nadzór jest pozorny — i to rejestr pokazuje uczciwie (wpis OVL-0005).

2. AI Regression Tests — incydent staje się testem

Każdy potwierdzony incydent zachowania AI zamieniamy w powtarzalny test defensywny. Cel: nie chodzi o odtwarzanie ataku, lecz o sprawdzian obronny na danych syntetycznych, że dokładnie ten sam błąd nie przejdzie ponownie. Poniżej klasy testów (dane syntetyczne).

Klasa incydentu AI	Co się zdarzyło (syntet.)	Test regresyjny (defensywny)	Oczekiwane zachowanie	Status
Prompt injection	Treść wklejona do analizy próbowała nadpisać instrukcję systemową modelu asystującego.	Test sprawdza, że wejście traktowane jest jako dane, nie instrukcja (izolacja kontekstu, sanityzacja). Bez payloadu ataku — wyłącznie asercja obronna.	Model ignoruje wstrzykniętą instrukcję; zgłasza anomalię do Ledgera.	test aktywny
Data leakage	Odpowiedź modelu zawierała fragment danych spoza dozwolonego kontekstu (syntetyczne PII).	Test weryfikuje redakcję/maskowanie i granice kontekstu; korpus wyłącznie syntetyczny.	Brak wycieku poza zakres; pola wrażliwe zredagowane.	test aktywny
Unsafe tool call	Model zaproponował wywołanie narzędzia o skutku nieodwracalnym bez zgody człowieka.	Test wymusza bramkę ACK człowieka (human-in-the-loop) przed akcją destrukcyjną; allowlist narzędzi.	Akcja wstrzymana do zatwierdzenia; wpis w Oversight Ledger.	test aktywny
Hallucinated evidence	Model przypisał finding do nieistniejącego dowodu/linku.	Test claim ≤ proof: każdy claim musi mieć weryfikowalny hash/link, inaczej oznaczony jako GAP.	Brak dowodu → status GAP, nie „potwierdzone".	ROADMAP
Over-trust / automation bias	Seria akceptacji rekomendacji bez weryfikacji pod presją kolejki (por. `OVL-0005`).	Test analityczny na Ledgerze: wykrycie wzorca „zawsze zgoda przy wysokiej presji".	Alert nadzorczy; wymóg drugiego oka.	ROADMAP

Granica defensywna (twarda). Testy regresyjne AI to sprawdziany obronne uruchamiane na danych syntetycznych, po pisemnych Rules of Engagement. Strona i repozytorium testów nie zawierają gotowych treści wstrzyknięć, exploitów ani instrukcji obejścia zabezpieczeń. Opisujemy oczekiwane zachowanie obronne, nie sposób przełamania. Każdy test to asercja „system ma odmówić / zredagować / zażądać ACK", nie „system ma wykonać X".

Skrót stanu

Pól Oversight Ledger

decydent · dowód · rozbieżność AI · presja · wynik

Klasy testów aktywne

prompt injection · data leakage · unsafe tool call

Klasy testów ROADMAP

hallucinated evidence · automation bias

art.14

AI Act — human oversight

nadzór człowieka nad systemem wysokiego ryzyka

Mapowanie na AI Act art. 14

Wymóg art. 14 (skrót)	Jak adresuje to Ledger / testy	Status
Człowiek rozumie możliwości i ograniczenia systemu	Kolumna „rekomendacja AI" + link do model risk i znanych ograniczeń	MVP
Świadomość automation bias (nadmiernego zaufania)	Rejestr presji czasu + test wykrywający wzorzec nadmiernej zgody	MVP + ROADMAP
Możliwość zignorowania / cofnięcia wyjścia AI	Wpisy override (`OVL-0002`, `OVL-0003`) + bramka ACK przed akcją nieodwracalną	MVP
Możliwość interwencji / zatrzymania	Unsafe tool call blokowany do zatwierdzenia człowieka (human-in-the-loop)	MVP
Ślad audytowy decyzji nadzorczych	Oversight Ledger jako dziennik z rozbieżnością AI i wynikiem; docelowo niezmienny chain-of-custody	ROADMAP (podpis/TSA jak w ograniczeniach)

Czego ta strona NIE twierdzi

To nie jest deklaracja zgodności ani porada prawna. Mapowanie na art. 14 to wsparcie decyzji — kwalifikację systemu jako „wysokiego ryzyka" i finalną ocenę zgodności wykonuje prawnik/organ. Ledger pokazuje mechanikę nadzoru, nie wydaje orzeczenia o spełnieniu wymogu.

„Test regresyjny" nie znaczy „nieprzenikalność". Zdany test dowodzi jedynie, że konkretny znany incydent nie powtarza się w warunkach testu na danych syntetycznych. Nie deklarujemy odporności na przypadki jeszcze nieobserwowane. Zgodnie z doktryną: „100%" u nas = pokrycie dowodowe, nie nieprzenikalność.

Powiązane: zgłoszenia i obsługa zdarzeń AI → /ai-incident · ryzyko i profil modeli → /model-risk · granice dojrzałości MVP → /known-limitations.