K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / zglos

Incident Intake — zgłoszenie incydentu

Moduł 1 systemu K0NSULT. Ustrukturyzowany punkt wejścia dla każdego zdarzenia — cyber klasycznego, incydentu AI/agentowego, naruszenia prawnego oraz zdarzenia ciągłości działania. Każde zgłoszenie startuje z niższą wagą dowodową i jest podnoszone dopiero po dołączeniu artefaktów w Evidence Layer.

TRYB DEMO. Ten formularz nie wysyła danych do żadnego systemu ani hosta zewnętrznego (CSP strict, zero fetch). Po zatwierdzeniu wyświetla lokalnie podgląd rekordu zgłoszenia (JSON) w celu prezentacji struktury Modułu 1. Nie wprowadzaj tu realnych danych osobowych ani wrażliwych szczegółów operacyjnych.
Jedno wejście → pełny łańcuch obsługi

Zgłoszenie nie jest końcem — jest zdarzeniem inicjującym, które automatycznie zasila klasyfikację, ocenę ryzyka, dobór playbooka i ocenę obowiązków regulacyjnych.

ZGŁOSZENIEDOWÓDSTATUSKLASYFIKACJARYZYKOPLAYBOOKDZIAŁANIEWALIDACJARAPORTODPORNOŚĆ

Formularz zgłoszenia

Pola oznaczone * są wymagane do utworzenia rekordu. Grupa i typ incydentu determinują ścieżkę do Classification Engine oraz zestaw sugerowanych flag prawnych.

1 · Identyfikacja zdarzenia

2 · Czas

Rozjazd wykrycie ↔ wystąpienie (dwell time) jest istotny dla oceny obowiązków notyfikacyjnych — patrz zegary NIS2 (24h/72h/final) i RODO art. 33 (72h).

3 · Zasób i kontekst

4 · Klasyfikacja wstępna

5 · Flagi prawne (legal_flags)

Zaznaczenie ustawia wstępne obowiązki. Ostateczne mapowanie — Legal Board.

Co dzieje się po zgłoszeniu

Rekord przechodzi przez łańcuch obsługi. Waga dowodowa rośnie tylko wraz z artefaktami — zgodnie z doktryną claim ≤ proof.

Krok 1 — DOWÓD (Evidence Layer). Do rekordu dołączane są artefakty: nagłówki maila, hash pliku, log SIEM/EDR, zrzut, PCAP, transkrypt sesji agenta. Bez artefaktu rekord pozostaje GAP.
Krok 2 — STATUS. Zgłoszenie otrzymuje status dowodowy (GAP → PUBLIC → MEDIA → CONFIRMED). Status steruje widocznością na tablicach publicznych vs operacyjnych.
Krok 3 — KLASYFIKACJA. Classification Engine przypisuje warstwę techniczną, typ, aktora, wektor, skutek i obowiązki regulacyjne (6 osi) + mapowanie MITRE ATT&CK.
Krok 4 — RYZYKO. Wyliczenie priorytetu (P0–P3) na podstawie skutku CIA, aktywności eksploatacji i krytyczności zasobu. P0 uruchamia zegar SLA 4h.
Krok 5 — PLAYBOOK. Dobór playbooka z Playbook Engine (np. phishing, ransomware, prompt injection). Kroki z odpowiedzialnościami i checklistą.
Krok 6 — OBOWIĄZKI PRAWNE. Legal/Compliance Engine wylicza zegary notyfikacji: NIS2 (wczesne ostrzeżenie 24h / zgłoszenie 72h / raport końcowy 1 mies.), RODO (72h do organu, art. 33; zawiadomienie osób, art. 34), AI Act (poważny incydent, art. 73).
Zasada intake. Zgłaszający opisuje fakty, nie diagnozę. System nie promuje twierdzenia do statusu „potwierdzone" bez artefaktu. Priorytet wstępny może być podniesiony automatycznie, ale nigdy obniżony bez decyzji Analysta.
Ścieżka źródłaDomyślny status startowyAuto-eskalacja
Log / SIEM / EDRINTERNALCONFIRMED po korelacjiJeśli reguła krytyczna → P1
CERT / regulatorCONFIRMEDJeśli CRITICAL_INFRA → P0
Użytkownik / pracownikGAPPo weryfikacji artefaktu
OSINT / mediaMEDIA / PUBLICManualnie przez Analysta
Agent AI (self-report)INTERNALJeśli AI_SERIOUS_INCIDENT → P0
Przykład wyliczenia zegarów SYMULACJA — wartości demonstracyjne. Dla zgłoszenia oznaczonego GDPR_BREACH + NIS2_RELEVANT, wykrytego 2026-07-04 08:00: RODO art. 33 → do 2026-07-07 08:00 (72h do organu); NIS2 wczesne ostrzeżenie → do 2026-07-05 08:00 (24h); NIS2 zgłoszenie → do 2026-07-07 08:00 (72h). Ramka oparta na publicznej treści regulacji, nie na realnym incydencie.

Dalej: Classification Engine → · Role i priorytety P0–P3 → · Model danych (schemat rekordu) →