§4.5 dokumentu „K0NSULT Evidence & Resilience Orchestrator". Silnik mapujący cechy incydentu na obowiązki regulacyjne: który reżim się aktywuje, jakie zegary startują, jaki organ, jaki artykuł. Cel: żeby żaden deadline zgłoszeniowy nie umknął, a każda flaga prawna miała jawną podstawę.
K0-LEGAL nie ocenia winy ani nie liczy kar. Odpowiada na jedno pytanie operacyjne: „jeśli ten incydent jest prawdziwy, kogo i w jakim czasie mam o nim powiadomić — i na jakiej podstawie prawnej?". Reguły są deterministyczne i jawne; człowiek zatwierdza.
Poniżej reżimy priorytetu P0 objęte silnikiem w wersji docelowej. Terminy i artykuły odwzorowują publicznie znaną treść przepisów (stan ramowy) — potwierdź u prawnika przed zgłoszeniem.
| Framework | Zakres / trigger | Zegary & obowiązek | Organ | Status silnika |
|---|---|---|---|---|
| DORA sektor finansowy |
Podmioty finansowe (banki, ubezpieczyciele, inwestycyjne). Poważny incydent ICT, ryzyko ICT, third-party (dostawcy ICT), TLPT (testy penetracyjne oparte na zagrożeniach). | Zgłoszenie wstępne → pośrednie → końcowe wg RTS. Rejestr umów z dostawcami ICT. TLPT w cyklu. | KNF / właściwy organ krajowy, ESA | ROADMAP |
| TIBER-EU ICT / test |
Ramowe testy red-team oparte na wywiadzie o zagrożeniach (threat-led). Powiązane z DORA TLPT. Tylko w reżimie pisemnego Rules of Engagement. | Cykl testu: scoping → threat intel → red-team → replay/purple → zamknięcie. Bez terminów zgłoszeniowych — ramy metodyczne. | Bank centralny / zespół TIBER Cyber Team | ROADMAP |
| NIS2 / KSC podmiot kluczowy |
Podmioty kluczowe i ważne. Poważny incydent wpływający na ciągłość usługi. | Wczesne ostrzeżenie 24h → zgłoszenie 72h → raport końcowy (ok. 1 mies.). | CSIRT (NASK / GOV / MON), organ właściwy | ROADMAP |
| RODO / GDPR dane osobowe |
Naruszenie ochrony danych osobowych (poufność / integralność / dostępność). | Art. 33 — zgłoszenie do organu w 72h. Art. 34 — zawiadomienie osób, gdy wysokie ryzyko. | PUODO (organ nadzorczy) | ROADMAP |
| AI Act system / agent AI |
Poważny incydent z udziałem systemu AI wysokiego ryzyka; obowiązki dostawcy / podmiotu wdrażającego. GPAI i art. 50 (transparentność). | Art. 73 — zgłoszenie poważnego incydentu bez zbędnej zwłoki po ustaleniu związku. Etapowe wejście w życie. | Organ nadzoru rynku / AI Office | ROADMAP |
| DSA platforma / treść |
Usługi pośrednie, platformy, VLOP. Nielegalne treści, ryzyka systemowe, mechanizmy zgłoszeń. | Notice-and-action, raporty przejrzystości, ocena ryzyka systemowego. | Koordynator ds. usług cyfrowych, KE | ROADMAP |
| CRA produkt / komponent |
Produkty z elementami cyfrowymi. Aktywnie wykorzystywana podatność lub poważny incydent w produkcie. | Zgłoszenie do ENISA/CSIRT — wczesne ostrzeżenie 24h → 72h → raport końcowy (schemat etapowy). | ENISA, CSIRT, organ nadzoru rynku | ROADMAP |
| eIDAS2 tożsamość / podpis / dowód |
Usługi zaufania, portfele tożsamości (EUDI), podpisy, pieczęcie, znaczniki czasu, integralność dowodu. | Zgłaszanie naruszeń bezpieczeństwa usług zaufania; wymogi integralności i weryfikowalności. | Organ nadzoru ds. usług zaufania | ROADMAP |
Silnik ocenia cechy znormalizowanego incydentu i włącza reżim(y). Reżimy się nie wykluczają — jeden incydent może aktywować kilka jednocześnie (np. wyciek danych w banku = DORA + NIS2 + RODO).
REGULATORY TRIGGER ENGINE (K0-LEGAL §4.5) — pseudokod decyzyjny, status ROADMAP
================================================================================
WEJŚCIE: incident{ sektor, aktywa, dane, komponent_ai, platforma, produkt, tozsamosc, severity }
WYJŚCIE: triggers[] = { framework, artykul, zegar, organ, podstawa }
incident
│
├─ czy dotyczy ICT / usług cyfrowych? ──────────── TAK ─┐
│ └─ podmiot finansowy? ── TAK ─► [DORA] (poważny incydent ICT, third-party, TLPT)
│ └─ podmiot kluczowy/ważny? ── TAK ─► [NIS2 / KSC] (24h / 72h / raport końcowy)
│ └─ test red-team w RoE? ── TAK ─► [TIBER-EU] (ramy threat-led, bez zegara zgłoszeń)
│
├─ czy naruszono dane osobowe? ─────────────────── TAK ─► [RODO]
│ └─ art. 33 (72h → organ) ; art. 34 (osoby, gdy wysokie ryzyko)
│
├─ czy w grze jest system / agent AI? ──────────── TAK ─► [AI Act]
│ └─ poważny incydent → art. 73 (bez zbędnej zwłoki) ; art. 50 (transparentność)
│
├─ czy to platforma / usługa pośrednia / treść? ── TAK ─► [DSA]
│ └─ notice-and-action, ryzyka systemowe, raport przejrzystości
│
├─ czy to produkt z elementami cyfrowymi? ──────── TAK ─► [CRA]
│ └─ aktywnie wykorzystywana podatność → 24h / 72h / raport końcowy (ENISA/CSIRT)
│
└─ czy dotyczy tożsamości / podpisu / dowodu? ──── TAK ─► [eIDAS2]
└─ usługi zaufania, integralność i weryfikowalność dowodu
REGUŁY: deterministyczne · jawne · wersjonowane · człowiek zatwierdza przed wysyłką
UWAGA : wynik = KANDYDACI na obowiązki, nie orzeczenie prawne (patrz disclaimer §16)
Odczyt danych ramowych i statusów przez ścieżkę tylko-do-odczytu /api/ip3/*. Zwraca metadane frameworków i statusy — bez orzekania automatycznego.
Zestaw testów dymnych potwierdza dostępność stron i endpointów read-path (200 OK). Silnik decyzyjny nie jest jeszcze objęty testem produkcyjnym.
Szkielet autoryzacji (skeleton) dla ścieżek zapisu — bez logiki orzekania. Baza pod przyszły write-path z rolami analityk/DPO.
Deterministyczne orzekanie triggerów, zegary zgłoszeniowe, eksport do organu, wersjonowanie reguł. Nie zaimplementowane produkcyjnie — wg §16 to jeszcze nie LIVE.
planowane
Silnik jest logiką; dane i widoki żyją w istniejących panelach ipIII. Legal-Engine spina je w jeden przepływ decyzyjny.
Tablica flag obowiązku zgłoszenia i zegarów raportowych na poziomie pojedynczego incydentu.
Monitoring zmian w reżimach (daty wejścia w życie, RTS, wytyczne). Źródło aktualizacji reguł silnika.
Compliance i raportowanie: eksport raportu do organu, ślad audytowy, mapowanie na obowiązki DORA/NIS2/RODO/AI Act.