k0nsult.cloud / ai-truth / ipIII / regulatory-evidence-pack
Regulatory Evidence: DORA / NIS2 / RODO / AI Act
Jeden pillar zamiast czterech osobnych regulacji: jak incydent bezpieczeństwa lub zdarzenie AI
przechodzi drogę wykrycie → mapowanie na obowiązek → termin → owner → dowód → paczka dla regulatora.
To strona decision-support — pomaga zespołowi compliance zebrać i uporządkować dowody, ale nie zastępuje
prawnika ani formalnej oceny prawnej konkretnego zdarzenia.
Po co ta strona. Cztery reżimy regulacyjne (DORA, NIS2, RODO, AI Act) mają różne terminy, różnych
ownerów i różne wymogi dowodowe — ale to samo źródłowe zdarzenie (np. incydent bezpieczeństwa z komponentem AI
w banku) może uruchomić obowiązki w kilku reżimach naraz. Ten pillar nie duplikuje istniejących paczek
regulacyjnych — łączy je w jedną mapę nawigacyjną i pokazuje wspólny szkielet dowodowy pod spodem.
Od incydentu do paczki dla regulatora: jeden szkielet dowodowy, cztery reżimy.
ipIII buduje evidence-package (manifest + sha256 + chain-of-custody) dla każdego
zamkniętego incydentu na żywej PostgreSQL. Ten pillar pokazuje, jak ten sam pakiet dowodowy jest odczytywany
przez różne reżimy: DORA patrzy na klasyfikację incydentu ICT i termin zgłoszenia do organu nadzoru;
NIS2 — na obowiązek wobec CSIRT; RODO — na naruszenie ochrony danych osobowych i 72h do UODO;
AI Act — na incydent poważny związany z systemem wysokiego ryzyka. To MVP warstwy evidence, nie
gotowy silnik zgłoszeń — każdy draft wymaga przeglądu prawnego przed wysyłką.
ŚCIEŻKA:
incydent→mapowanie na obowiązek→termin (deadline clock)→owner→evidence-package→paczka dla organu
Dlaczego jedno zdarzenie = wiele reżimów
Praktyka sektora regulowanego (bank, ubezpieczyciel, operator usługi kluczowej) pokazuje, że incydenty
rzadko mieszczą się w jednej szufladce prawnej. Przykład syntetyczny wykorzystywany w materiałach pilotażowych:
awaria modelu scoringowego wspieranego przez dostawcę chmurowego, który jest jednocześnie krytycznym
dostawcą ICT. Takie zdarzenie może jednocześnie:
- być incydentem ICT w rozumieniu DORA (rozporządzenie o odporności operacyjnej sektora finansowego) — z obowiązkiem klasyfikacji istotności i zgłoszenia do właściwego organu nadzoru w określonym oknie czasowym;
- dotyczyć dostawcy usługi kluczowej lub cyfrowej w rozumieniu NIS2 — z obowiązkiem zgłoszenia do CSIRT, jeśli wpływa na ciągłość usługi;
- obejmować naruszenie ochrony danych osobowych w rozumieniu RODO — z 72-godzinnym oknem na zgłoszenie do organu nadzorczego (w Polsce UODO), jeśli doszło do wycieku lub nieautoryzowanego dostępu;
- dotyczyć systemu AI wysokiego ryzyka w rozumieniu AI Act — z obowiązkiem zgłaszania poważnych incydentów, jeśli model jest sklasyfikowany jako wysokiego ryzyka (np. scoring kredytowy).
Bez wspólnego szkieletu dowodowego zespół compliance musi ręcznie kopiować te same fakty (co się stało,
kiedy, jaki miało wpływ, jaki dowód to potwierdza) do czterech osobnych rejestrów i czterech osobnych
terminarzy. Ten pillar dokumentuje, gdzie K0NSULT buduje jeden punkt prawdy dla tych faktów — i gdzie
to dopiero ROADMAP.
Cztery reżimy — skrót i status pokrycia
DORA MVP
Rozporządzenie o cyfrowej odporności operacyjnej sektora finansowego. Klasyfikacja incydentu ICT,
terminy zgłoszenia do organu nadzoru, testy odporności (TIBER-EU). Powiązane strony:
DORA / TIBER (metodyka testów i pilot),
DORA pack (szablon zgłoszenia + checklisty).
NIS2 MVP
Dyrektywa o cyberbezpieczeństwie sieci i systemów informacyjnych — obowiązki podmiotów kluczowych
i ważnych, zgłoszenia do CSIRT, ocena łańcucha dostaw. Szczegóły i szkielet dowodowy:
NIS2 pack.
RODO MVP
Ogólne rozporządzenie o ochronie danych — naruszenia ochrony danych osobowych, 72h do organu
nadzorczego, rejestr czynności przetwarzania. Szablon i rejestr:
RODO pack.
AI Act MVP
Rozporządzenie o sztucznej inteligencji — klasyfikacja ryzyka systemu, obowiązki dla systemów
wysokiego ryzyka, zgłaszanie poważnych incydentów. Terminy Aneksu III (scoring, HR) zostały odroczone
z 2.08.2026 na 2.12.2027 (Digital Omnibus) — art. 50 i obowiązki GPAI pozostają bez zmian. Szablon:
AI Act pack.
Wspólny szkielet dowodowy pod czterema reżimami
Niezależnie od tego, który reżim jest właściwy, dowód pod spodem ma tę samą strukturę. To jest
faktyczny, jawny format evidence-package generowany przez ipIII dla zamkniętego incydentu (MVP,
na żywej PostgreSQL, z audytem):
| Element pakietu | Co zawiera | Status |
|---|
| Manifest |
Lista findings, timeline zdarzenia, klasyfikacja istotności, powiązany incydent/ticket. |
LIVE (MVP) |
Integralność (sha256) |
Hash pakietu — dowód, że treść nie została zmieniona po wygenerowaniu. |
LIVE (MVP) |
| Chain-of-custody |
Kto, kiedy i w jakim kroku dotknął dowodu (import → triage → retest → close). |
LIVE (MVP) |
| Mapowanie na obowiązek regulacyjny |
Który reżim (DORA/NIS2/RODO/AI Act) i który konkretny artykuł/próg jest potencjalnie zaangażowany. |
MVP — Legal Trigger Engine, decision-support |
| Termin (deadline) |
Okno czasowe na zgłoszenie liczone od momentu wykrycia/potwierdzenia — patrz Deadline Clock. |
MVP — orientacyjne, wymaga weryfikacji prawnej |
| Owner |
Osoba/rola odpowiedzialna za decyzję o zgłoszeniu i kontakt z organem (CISO, DPO, compliance officer). |
ROADMAP — przypisanie ownera per organizacja |
| Podpis formalny (PAdES/TSA) |
Kwalifikowany podpis elektroniczny i znacznik czasu dla pakietu przed wysyłką do organu. |
ROADMAP — dziś tylko hash integralności |
Oś czasu: od wykrycia do wysyłki
Poniżej uproszczony przebieg — każdy krok odsyła do strony, która dokumentuje go szczegółowo (metodykę,
szablon lub zegar terminów). To jest opis procesu decyzyjnego, nie automatyczna wysyłka do organu.
1. Wykrycie i triage. Finding lub incydent trafia do ipIII (import z parsera skanera lub zgłoszenie ręczne). Klasyfikacja wstępna istotności.
2. Mapowanie na obowiązek. Legal Trigger Engine wskazuje, które reżimy (DORA/NIS2/RODO/AI Act) mogą być zaangażowane — jako sugestia decision-support, do weryfikacji przez compliance/prawnika. Pełna oś triggerów:
Legal Trigger Timeline.
3. Sprawdzenie terminu. Każdy reżim ma inne okno czasowe (np. 72h RODO, godziny/dni DORA w zależności od istotności). Zestawienie:
Deadline Clock.
4. Przypisanie ownera. Kto decyduje o treści zgłoszenia i podpisuje je organizacyjnie — dziś proces ręczny, przypisanie roli w systemie to ROADMAP.
5. Budowa evidence-package. Manifest + hash + chain-of-custody generowane automatycznie z danych incydentu — LIVE (MVP).
6. Przegląd prawny i wysyłka. Draft zgłoszenia trafia do przeglądu prawnika/compliance przed wysyłką do organu — to krok obowiązkowy, nigdy pomijany, niezależnie od tego, co sugeruje narzędzie.
Konkretne paczki regulacyjne — gdzie znaleźć szczegóły
Ten pillar celowo nie powiela treści czterech paczek regulacyjnych i dwóch stron narzędziowych —
linkuje do nich jako do źródła szczegółów:
- DORA / TIBER — metodyka testów odporności operacyjnej (TIBER-EU) i status pilota threat-led.
- DORA pack — szablon klasyfikacji incydentu ICT i checklisty zgłoszeniowe dla sektora finansowego.
- NIS2 pack — obowiązki podmiotów kluczowych/ważnych, zgłoszenia do CSIRT, ocena łańcucha dostaw.
- RODO pack — szablon zgłoszenia naruszenia ochrony danych osobowych, rejestr czynności.
- AI Act pack — klasyfikacja ryzyka systemu AI, obowiązki dla systemów wysokiego ryzyka.
- Deadline Clock — zegar terminów regulacyjnych liczonych od momentu wykrycia incydentu.
- Legal Trigger Timeline — oś czasu wszystkich triggerów prawnych z uzasadnieniem.
- Regulatory Packs — zbiorczy widok wszystkich paczek regulacyjnych w jednym miejscu.
Co ta strona NIE oznacza
To nie jest silnik automatycznego zgłaszania do regulatora. Legal Trigger Engine sugeruje, które
obowiązki mogą być zaangażowane i w jakim oknie czasowym — ale ostateczna decyzja o treści i wysyłce
zgłoszenia zawsze wymaga przeglądu prawnika lub zespołu compliance. Narzędzie nie zastępuje tej oceny.
„100%" u nas znaczy pokrycie dowodowe, nie nieprzenikalność ani zgodność formalną. Deklarujemy
dokładnie tyle, ile potrafimy pokazać kodem, testem i endpointem. Elementy oznaczone
ROADMAP (owner per organizacja, podpis PAdES/TSA) nie istnieją dziś
jako gotowa funkcja — nie sprzedajemy ich jako LIVE.
Materiały pilotażowe i demonstracyjne są syntetyczne. Wszystkie przykłady incydentów użyte
w paczkach i na tej stronie to dane syntetyczne przygotowane zgodnie z pisemnymi Rules of Engagement.
Strona nie opisuje technik ofensywnych ani rzeczywistych ataków — dokumentuje wyłącznie stronę dowodową
i obronną procesu.
Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Nie wykonuje
nieautoryzowanych skanów ani exploitacji. Mapowania regulacyjne na tej stronie i w powiązanych paczkach
to
wsparcie decyzji, nie porada prawna — kwalifikację prawną każdego konkretnego zdarzenia
wykonuje radca prawny/kancelaria właściwa dla jurysdykcji i sektora. Działania testowe wyłącznie
w granicach pisemnych
Rules of Engagement.
Następny krok
Powiązane: znane ograniczenia MVP → /known-limitations ·
metodyka DORA/TIBER → /dora-tiber.