k0nsult.cloud / ai-truth / ipIII / legal-board

Legal Board — Tablica prawno-regulacyjna

Warstwa Legal/Compliance systemu. Każdy incydent z ustawionymi flagami prawnymi (AI Act, RODO, NIS2/KSC) uruchamia zegary raportowania do właściwych organów. Tablica pokazuje sprawy, ich flagi, obowiązujące terminy, właściciela (Legal/DPO/AI Safety Officer) oraz status decyzji prawnej — od otwarta po zgłoszona/zamknięta.

Executive Overview Cyber Map AI Risk Map Evidence Board Legal Board Response Board

SYMULACJA / dane demonstracyjne. Sprawy, właściciele i terminy w tabeli są przykładowe (demo) — nie odzwierciedlają realnych postępowań. Ramki normatywne poniżej (AI Act art.73, NIS2 24h/72h/1 mies., RODO art.33/34) opierają się na publicznie znanej treści regulacji i mają charakter ramki/normy, a nie opisu incydentu. Nie stanowią porady prawnej.

Flaga prawna = zegar. Zegar = termin. Termin = dowód dochowania.

Ustawienie flagi NIS2_RELEVANT, GDPR_BREACH czy AI_SERIOUS_INCIDENT nie jest etykietą informacyjną — uruchamia liczony obowiązek raportowy. System śledzi upływ terminu i wymaga artefaktu potwierdzającego zgłoszenie.

Sprawy z flagami prawnymi SYMULACJA

sprawa	flagi	termin org.	właściciel	status decyzji	prio
`LGL-3011` wyciek danych klientów	GDPR_BREACHPERSONAL_DATANIS2_RELEVANT	RODO 72h → 18h left NIS2 24h → wysłane	Legal/DPO	RODO art.33 W TOKU	P0
`LGL-3009` poważny incydent systemu AI (scoring)	AI_HIGH_RISKAI_SERIOUS_INCIDENTLAW_ENFORCEMENT?	AI Act art.73 → bez zbędnej zwłoki	AI Safety Officer	ANALIZA KWALIFIKACJI	P0
`LGL-3006` ransomware — usługa kluczowa	NIS2_RELEVANTCRITICAL_INFRAKSC_RELEVANT	NIS2 wczesne 24h → wysłane raport 72h → 44h left	Operator + Legal	24h ZŁOŻONE	P0
`LGL-3002` phishing → przejęcie skrzynki	PERSONAL_DATAAI_ACT?	RODO ocena ryzyka → w toku	Legal/DPO	OCENA CZY BREACH	P1
`LGL-2998` deepfake głosowy — próba oszustwa	FALSE_IDENTITYLAW_ENFORCEMENT	zawiadomienie organów ścigania	Legal + CISO	ZGŁOSZONE	P1
`LGL-2990` misconfig — ekspozycja logów	PERSONAL_DATA?	ocena art.34 (zawiadomienie osób)	Legal/DPO	BRAK DOWODU ZAKRESU	P2

Kolumna „status decyzji" dziedziczy dowodowo z Evidence Board — sprawa nie może być „ZGŁOSZONA jako breach", jeśli zakres danych jest w statusie GAP.

Ramki normatywne — terminy raportowania

Poniżej: ramki obowiązków wynikające z publicznie znanej treści regulacji. Charakter: norma / ramka, nie opis incydentu. Zawsze weryfikuj z aktualnym tekstem aktu i implementacją krajową.

AI Act — art. 73: zgłaszanie poważnych incydentów

Dostawcy systemów AI wysokiego ryzyka zgłaszają poważny incydent (serious incident) organowi nadzoru rynku państwa, w którym incydent wystąpił, bez zbędnej zwłoki po ustaleniu związku przyczynowego (lub jego uzasadnionego prawdopodobieństwa) między systemem AI a incydentem.

Ustalenie związku→bez zbędnej zwłoki→organ nadzoru rynku→współpraca / działania naprawcze

Flagi wyzwalające: AI_HIGH_RISK + AI_SERIOUS_INCIDENT. Uwaga na terminy szczegółowe zależne od typu skutku (m.in. zdarzenia śmiertelne — krótsze). Zależność od wejścia w życie i przepisów przejściowych AI Act.

NIS2 — obowiązek notyfikacji (3 etapy)

24h wczesne ostrzeżenie→72h zgłoszenie właściwe (ocena)→1 miesiąc raport końcowy

Wczesne ostrzeżenie ≤ 24h od powzięcia wiedzy o poważnym incydencie — wskazanie m.in. czy podejrzewane jest działanie bezprawne/złośliwe i możliwy skutek transgraniczny.
Zgłoszenie właściwe ≤ 72h — aktualizacja + wstępna ocena (dotkliwość, skutki, IOC jeśli dostępne).
Raport końcowy ≤ 1 miesiąc od zgłoszenia — szczegółowy opis, przyczyna źródłowa, środki zaradcze, skutki transgraniczne.

Adresat: CSIRT właściwy / organ krajowy. W PL powiązane z KSC_RELEVANT (ustawa o krajowym systemie cyberbezpieczeństwa). Flaga: NIS2_RELEVANT, przy usługach kluczowych też CRITICAL_INFRA.

RODO — art. 33 i art. 34: naruszenie ochrony danych

Wykrycie naruszenia→art.33 · ≤72h do PUODO→ocena ryzyka dla osób→art.34 zawiadomienie osób (wysokie ryzyko)

Art. 33 — zgłoszenie do organu (PUODO) ≤ 72h od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem dla praw i wolności osób. Zgłoszenie po terminie wymaga wyjaśnienia opóźnienia.
Art. 34 — zawiadomienie osób, których dane dotyczą, bez zbędnej zwłoki, gdy naruszenie może powodować wysokie ryzyko dla ich praw i wolności. Wyjątki m.in. przy skutecznym szyfrowaniu / środkach eliminujących wysokie ryzyko.

Flagi: GDPR_PERSONAL_DATA, GDPR_BREACH. Prowadź rejestr naruszeń (art.33 ust.5) niezależnie od tego, czy zgłoszenie było wymagane.

Macierz: flaga → obowiązek → adresat

flaga	obowiązek (ramka)	termin	adresat	właściciel
AI_SERIOUS_INCIDENT	zgłoszenie poważnego incydentu AI	bez zbędnej zwłoki	organ nadzoru rynku	AI Safety Officer
NIS2_RELEVANT	notyfikacja 3-etapowa	24h / 72h / 1 mies.	CSIRT / organ krajowy	Operator + Legal
KSC_RELEVANT	obowiązki KSC (PL)	wg ustawy KSC	CSIRT poziomu krajowego	Operator + Legal
GDPR_BREACH	art.33 zgłoszenie	≤ 72h	PUODO	Legal/DPO
PERSONAL_DATA + wysokie ryzyko	art.34 zawiadomienie	bez zbędnej zwłoki	osoby, których dane dotyczą	Legal/DPO
LAW_ENFORCEMENT	zawiadomienie o przestępstwie	niezwłocznie	organy ścigania	Legal + CISO

Zasady tablicy prawnej

1. Zegar startuje od wiedzy, nie od chęci. Termin liczy się od powzięcia wiedzy/stwierdzenia naruszenia — system stempluje ten moment jako niezmienny.

2. Decyzja o niezgłaszaniu też jest decyzją. Uzasadnienie „brak ryzyka" musi być udokumentowane i przypięte dowodowo (Evidence Board), inaczej sprawa pozostaje otwarta.

3. Dowód zakresu przed kwalifikacją breach. Bez potwierdzonego zakresu danych sprawa nie przechodzi w „breach zgłoszony" — pozostaje GAP.

4. To ramka, nie porada. Board wspiera dyscyplinę terminów; ostateczna kwalifikacja prawna należy do Legal/DPO wobec aktualnego stanu prawnego.

Powiązania

Evidence Board →

Status decyzji prawnej dziedziczy z dowodu — GAP blokuje kwalifikację breach.

Response Board →

Zgłoszenie do organu jest działaniem z terminem due_at i dowodem złożenia.

Compliance & raportowanie →

Szablony i rejestr pism do organów (PUODO, CSIRT, nadzór rynku).

Playbook AI Act →

Ścieżka kwalifikacji poważnego incydentu AI i zgłoszenia art.73.

Ocena naruszenia RODO (breach assessment) — nie tylko „zegar 72h"

Zegar art.33 rusza od stwierdzenia naruszenia, ale zgłoszenie zależy od oceny ryzyka. Checklista decyzyjna DPO:

Pytanie	Konsekwencja
Czy to naruszenie ochrony danych osobowych?	Nie → poza RODO art.33/34
Czy istnieje ryzyko dla praw i wolności osób?	Tak → zgłoszenie do PUODO ≤72h (art.33)
Czy ryzyko jest wysokie?	Tak → zawiadomienie osób (art.34)
Kiedy nastąpiło „stwierdzenie naruszenia"?	Start zegara 72h
Czy dane były szyfrowane / nieczytelne?	Może obniżyć obowiązek zawiadomienia osób
Kto podjął decyzję (DPO)?	Wpis do rejestru + uzasadnienie
Czy retencja danych jest uzasadniona?	Weryfikacja podstawy i okresu

NIS2 / KSC — klasyfikacja podmiotu i ścieżka notyfikacji

Pole	Wartości
Sektor objęty	tak / nie / nieustalone
Wielkość podmiotu	średni / duży / inny
Podmiot kluczowy	tak / nie / nieustalone
Podmiot ważny	tak / nie / nieustalone
CSIRT właściwy	NASK / GOV / MON / sektorowy
Obowiązek wpisu	tak / nie / nieustalone
Status notyfikacji	early warning (24h) / notification (72h) / final (1 mies.)
Odpowiedzialny	zarząd / kierownik / security owner

Ramka normatywna, nie porada prawna. Klasyfikacja podmiotu należy do organizacji i jej doradców. Zob. Law Change Watch.