„Dlaczego teraz" nie jest tu sloganem sprzedażowym — jest obserwacją kalendarza. W oknie 2025-2027 zbiegają się cztery reżimy regulacyjne z twardymi terminami raportowania incydentów: DORA, AI Act, NIS2/KSC i RODO. Każdy z nich tworzy obowiązek dowodu zdarzenia i terminowego raportu do organu lub zarządu. Ta strona porządkuje fakty i pokazuje, gdzie dokładnie ipIII adresuje tę lukę — jako decision-support, nie jako poradę prawną.
DORA obowiązuje od 17.01.2025. Art.50 AI Act (transparentność) — od 2.02.2025. NIS2/KSC nakłada 72-godzinny obowiązek zgłoszenia dla podmiotów kluczowych i ważnych. RODO art.33/34 — 72 godziny przy naruszeniu danych osobowych. Cztery różne reżimy, ta sama logika: gdy zdarza się incydent, potrzebny jest dowód co się stało i zdolność zaraportowania tego w terminie liczonym w godzinach, nie tygodniach.
Poniższa tabela porządkuje daty i zakresy. Wszystkie są faktami regulacyjnymi publicznie dostępnymi — interpretacja konkretnego przypadku wymaga zawsze przeglądu prawnika lub DPO.
| Reżim | Kluczowa data | Kogo dotyczy | Obowiązek raportowy |
|---|---|---|---|
| DORA (Digital Operational Resilience Act) | Obowiązuje od 17.01.2025 | Podmioty finansowe w UE (banki, ubezpieczyciele, firmy inwestycyjne, dostawcy ICT krytyczni) | Odporność operacyjna ICT + zgłaszanie poważnych incydentów do organu nadzoru w wyznaczonych oknach czasowych. |
| AI Act — art.50 | Obowiązuje od 2.02.2025, bez zmian po Digital Omnibus | Dostawcy/wdrażający systemy AI wchodzące w interakcję z ludźmi (transparentność, oznaczanie treści/deepfake) | Obowiązek informacyjny — użytkownik musi wiedzieć, że wchodzi w interakcję z AI lub ogląda treść syntetyczną. |
| AI Act — art.73 / Aneks III | Aneks III (high-risk) odroczony 2.08.2026 → 2.12.2027 (Digital Omnibus) | Systemy wysokiego ryzyka (m.in. scoring, HR, rekrutacja) — zakres odroczony, nie zniesiony | Zgłaszanie poważnych incydentów (art.73) systemów AI wysokiego ryzyka. termin orientacyjny — do weryfikacji z Dz.U. UE |
| NIS2 / KSC | Obowiązek zgłoszenia w 72h od wykrycia (wczesne ostrzeżenie zwykle w 24h) | Podmioty kluczowe i ważne (energetyka, zdrowie, finanse, cyfrowa infrastruktura, administracja i inne sektory objęte KSC) | Wieloetapowe zgłoszenie incydentu do CSIRT/organu właściwego, z aktualizacją statusu i raportem końcowym. |
| RODO — art.33/34 | Obowiązek zgłoszenia w 72h od stwierdzenia naruszenia | Administratorzy i podmioty przetwarzające dane osobowe (praktycznie każda organizacja) | Zgłoszenie naruszenia ochrony danych do organu nadzorczego (UODO w Polsce) i — jeśli wysokie ryzyko — zawiadomienie osób, których dane dotyczą. |
Cztery różne reżimy prawne, jedna wspólna struktura problemu. Gdy dzieje się incydent — cyberatak, naruszenie danych, poważna awaria AI — organizacja musi w krótkim czasie odpowiedzieć na trzy pytania: co dokładnie się stało (dowód), do kiedy trzeba to zgłosić (termin) i w jakiej formie ma wyglądać zgłoszenie (raport). W praktyce te trzy elementy dziś najczęściej rozjeżdżają się między arkuszem Excela zespołu bezpieczeństwa, mailem do compliance i osobnym drafcikiem dla prawnika — bez jednego źródła prawdy, które łączyłoby finding techniczny z zegarem regulacyjnym.
To jest dokładnie warstwa, w której działa ipIII: import findingu → evidence z hash i chain-of-custody → Legal Trigger Engine sugerujący możliwy obowiązek i orientacyjny termin → Board Pack dla zarządu → Regulatory Pack jako punkt startowy dla prawnika. Nie zastępujemy prawnika, audytora ani DPO — porządkujemy fakty, zanim trafią na ich biurko, tak żeby decyzja zapadała na podstawie dowodu, a nie pamięci zespołu.
| Reżim | Szacunkowa skala (model) | Źródło (do weryfikacji) |
|---|---|---|
| DORA | rząd ~22 000 podmiotów finansowych w UE objętych zakresem | publikowany szacunek z oceny skutków regulacji DORA (Komisja Europejska); do potwierdzenia z aktualnym rejestrem ESAs |
| NIS2 | rząd od kilkudziesięciu do ~160 000 podmiotów kluczowych/ważnych w całej UE (istotne rozszerzenie zakresu wobec NIS1) | komunikaty Komisji Europejskiej / ENISA dot. rozszerzenia zakresu NIS2; do potwierdzenia z krajowym rejestrem KSC |
Te dwie liczby ilustrują skalę problemu regulacyjnego, nie prognozę przychodu K0NSULT ani wielkość rynku adresowalnego przez ipIII — nie wyprowadzamy z nich żadnej kwoty finansowej na tej stronie.
W odróżnieniu od szacunków rynku powyżej, poniższe liczby opisują dzisiejszy stan kodu ipIII i są weryfikowalne bezpośrednio, bez założeń modelowych.
Każda z tych liczb jest sprawdzalna bez naszego zapewnienia — wystarczy otworzyć wskazany endpoint. To jest różnica, na której nam zależy: cyfry produktu pokazujemy jako fakt z kodu, cyfry rynku jako jawnie oznaczone założenie modelu.
ipIII nie jest konkurentem skanera podatności, narzędzia pentestowego, SIEM ani platformy GRC — konsumuje ich wyjście. Kategoria, w której się plasujemy, to warstwa dowodowo-regulacyjna pomiędzy pentest/AppSec/ SOC/GRC a zarządem, audytem i regulatorem: miejsce, w którym finding techniczny zamienia się w evidence z hashem, przypisanego ownera, termin SLA i — jeśli dotyczy — orientacyjny obowiązek zgłoszenia. Traktujemy to jako pozycjonowanie komplementarne wobec istniejącego stosu narzędzi bezpieczeństwa, nie jako twierdzenie, że jesteśmy jedynym albo najlepszym rozwiązaniem na rynku. Szersze porównanie z poszczególnymi kategoriami narzędzi opisują strony /porownanie-vs-scanners, /porownanie-vs-siem i /porownanie-vs-grc.
| Tryb wdrożenia | Opis | Status |
|---|---|---|
| SaaS, region UE | Wspólna instancja hostowana, dostęp przez API/JWT, dane klienta logicznie odseparowane w bieżącym modelu. | LIVE MVP |
| Private tenant (dedykowana instancja) | Osobna instancja per klient, pełna izolacja Row-Level Security w PostgreSQL. | ROADMAP |
| VPC klienta / on-prem | Wdrożenie w środowisku sieciowym klienta lub lokalnie, poza infrastrukturą K0NSULT. | ROADMAP |
Pełny opis granic dojrzałości (auth, transport, tenancy, podpisy dowodów) jest scentralizowany na stronie /known-limitations.
Powiązane: pakiet AI Act (decision-support) → /ai-act-pack · silnik reguł prawnych → /legal-engine · znane ograniczenia i tryby wdrożenia → /known-limitations · modele współpracy → /pricing · centrum zaufania → /trust-center.