Ta strona odpowiada na pytanie, które zadaje każdy przejmujący aktywo w due diligence: jakie obowiązki regulacyjne przechodzą razem z produktem? Nie jest to opinia prawna. Jest to uporządkowany przegląd ról, terminów i reżimów, które trzeba sprawdzić — z jasnym rozróżnieniem, co ipIII robi (decision-support), a czego nie robi (kwalifikacji prawnej, zgłoszeń do organów, gwarancji zgodności).
Nabywca ipIII przejmuje nie tylko kod i dane, ale też pozycję wobec regulacji, które dotyczą systemów AI, bezpieczeństwa ICT i danych osobowych — zarówno jako producent/dostawca tego narzędzia, jak i, niezależnie, jako organizacja stosująca u siebie systemy AI. Ta strona rozdziela te dwie perspektywy i pokazuje, gdzie ipIII realnie pomaga (warstwa dowodowa, mapowanie terminów), a gdzie odpowiedzialność zostaje wyłącznie po stronie człowieka.
Odpowiedź nie jest jednoznaczna bez analizy konkretnej konfiguracji wdrożenia — poniżej kryteria, nie werdykt.
Moduł AI-agent security w ipIII testuje i obserwuje inne systemy AI (prompt-injection, nadużycie narzędzi) — to funkcja narzędzia bezpieczeństwa, analogiczna do skanera podatności, a nie samego systemu AI podejmującego decyzje wobec osób. Ta różnica jest istotna dla klasyfikacji, ale nie przesądza jej w 100%.
Legal Trigger Engine i mapowania terminów działają w oparciu o reguły i konfigurowalne progi, nie o trenowany model predykcyjny — to zbliża je bardziej do klasycznego oprogramowania compliance niż do systemu AI w rozumieniu definicji rozporządzenia. Elementy wykorzystujące modele językowe (np. w warstwie analitycznej) wymagają osobnej oceny.
Czy komponent generuje predykcje/rekomendacje/decyzje/treści z pewnym poziomem autonomii; czy wpływa na osoby fizyczne, procesy krytyczne lub decyzje biznesowe; czy jest modelem ogólnego przeznaczenia, komponentem czy gotowym systemem. Odpowiedź na te pytania — nie marketing dostawcy — przesądza klasę.
(a) ipIII jako produkt — czy podlega obowiązkom dostawcy/producenta systemu AI. (b) Organizacja nabywcy jako użytkownik systemów AI (w tym ewentualnie samego ipIII lub systemów, które ipIII monitoruje) — czy podlega obowiązkom deployera. Obie ścieżki trzeba ocenić osobno.
| Reżim / artykuł | Obowiązek | Termin | Status weryfikacji |
|---|---|---|---|
| AI Act — art. 50 | Obowiązki przejrzystości (m.in. informowanie o interakcji z AI, oznaczanie treści syntetycznych) | 2.08.2026 | termin ustawowy — bez zmian w toku Digital Omnibus |
| AI Act — Aneks III (high-risk) | Pełne obowiązki dla systemów wysokiego ryzyka (m.in. scoring, HR, dostęp do usług) | 2.12.2027 (orientacyjnie, po odroczeniu) | GAP — do weryfikacji odroczenie pakietem Digital Omnibus wymaga potwierdzenia publikacją w Dzienniku Urzędowym UE; art. 50 i obowiązki GPAI pozostają bez zmian |
| DORA — art. 19 | Zgłaszanie poważnych incydentów ICT przez podmioty finansowe (wstępne / pośrednie / końcowe) | okna zależne od klasyfikacji istotności, ustalane per zdarzenie | reżim obowiązujący — dokładne okna ustala kwalifikacja incydentu |
| NIS2 | Wczesne ostrzeżenie / zgłoszenie incydentu / raport końcowy | 24h / 72h / 1 miesiąc (orientacyjnie, zależnie od implementacji krajowej) | do weryfikacji per jurysdykcja implementacja krajowa różni się między państwami członkowskimi |
| RODO — art. 33–34 | Zgłoszenie naruszenia ochrony danych do organu nadzorczego / zawiadomienie osób, których dane dotyczą | 72h od stwierdzenia naruszenia (organ) / bez zbędnej zwłoki (osoby, gdy wysokie ryzyko) | termin ustawowy |
| CRA (Cyber Resilience Act) | Obowiązki producenta produktów z elementami cyfrowymi: SBOM, zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów do ENISA | etapowo — obowiązki zgłoszeniowe wcześniej niż pełny zakres obowiązków producenta | GAP — do weryfikacji dokładne daty wejścia w życie poszczególnych obowiązków wymagają potwierdzenia u prawnika przed poleganiem na tej stronie |
Poza AI Act, nabywca ipIII (i organizacja stosująca systemy AI, które ipIII monitoruje) może podlegać równolegle kilku reżimom naraz — mapowanie, które z nich ma zastosowanie, zależy od sektora i roli podmiotu.
Legal Trigger Engine (MVP) bierze potwierdzony finding lub incydent i zestawia go z progami RODO/NIS2/DORA/AI Act, wskazując które pytania decyzyjne trzeba zadać i kto powinien je rozstrzygnąć. Pełny opis mechanizmu i osi czasu → Legal Engine i Legal Timeline.
Mapuje incydent na listę potencjalnie właściwych reżimów. Liczy orientacyjne okna czasowe od momentu wykrycia. Rejestruje, kto podjął decyzję i jaki dowód był jej podstawą (audit-log). Generuje pakiet dowodowy (evidence-package) jako materiał wejściowy do dalszej oceny prawnej.
Nie kwalifikuje prawnie, czy obowiązek zgłoszenia rzeczywiście powstał. Nie składa zgłoszeń do organów (UODO, CSIRT, KNF, ENISA). Nie zastępuje kancelarii ani działu compliance. Nie gwarantuje, że mapowanie obejmuje wszystkie zastosowania — terminy są orientacyjne i wymagają potwierdzenia.
Każdy artefakt wygenerowany przez Legal Trigger Engine jest decision-support, materiałem wejściowym do decyzji człowieka (DPO, CISO, radca prawny) — nigdy jej substytutem.
NARRACJA / ROADMAP — poniższy model porządkuje, jak organizacja mogłaby nadawać uprawnienia do coraz bardziej zaawansowanych działań bezpieczeństwa (od świadomości po zarządzanie ryzykiem federacji), z bramkami wejścia/wyjścia i wymaganymi artefaktami przy każdym poziomie. To konstrukt koncepcyjny/governance opisany w dokumentacji źródłowej — nie ma dziś pokrycia w kodzie produkcyjnym ipIII (brak endpointu, silnika autoryzacji poziomów czy egzekwowania RBAC opisanego poniżej). Traktuj tę sekcję jako mapę docelową procesu, nie jako funkcję LIVE.
| Poziom | Cel | Kryterium wejścia (gate) | Artefakt wyjściowy |
|---|---|---|---|
| L0 — Awareness | Podstawy higieny cyber | ukończone szkolenie + test wiedzy ≥ 80% | akceptacja regulaminu, wynik testu |
| L1 — Safe Lab User | Praca wyłącznie w izolowanym labie | poprawne użycie labu bez naruszeń zakresu | log aktywności, snapshoty VM |
| L2 — Defensive Operator | Obrona i monitoring | zamknięcie symulowanego incydentu z raportem | reguły detekcji, playbook reakcji |
| L3 — Vulnerability Analyst | Ocena podatności w ustalonym zakresie (allowlist) | 3 raporty bez naruszenia zakresu | raport CVE/CVSS, rekomendacje naprawcze |
| L4 — Authorized Tester | Testy w granicach podpisanych Rules of Engagement | pozytywny przegląd prawny i techniczny | podpisane RoE, raport executive + technical |
| L5 — Red/Blue Team Practitioner | Symulacje technik (mapowane do MITRE ATT&CK) w środowisku kontrolowanym | ćwiczenie bez wpływu na środowisko produkcyjne | plan ćwiczenia, macierz ATT&CK, wnioski |
| L6 — Cyber Range Lead | Projektowanie bezpiecznych środowisk ćwiczeniowych | audyt izolacji i odtwarzalności środowiska | specyfikacja izolacji sieci, procedury rollback |
| L7 — Federation Cyber Authority | Zarządzanie legalnością i ryzykiem całej federacji działań | ustanowienie rejestru zgód, assetów i audytu RBAC | rejestr zgód, procedura zgłaszania nadużyć |
| Obszar | Co przechodzi | Uwaga |
|---|---|---|
| Obowiązki producenta/dostawcy | Jeśli klasyfikacja przesądzi, że ipIII (lub jego komponent) podlega obowiązkom producenta systemu AI lub CRA — obowiązki te przechodzą na nowego właściciela wraz z prawami do produktu. | Wymaga wcześniejszej klasyfikacji — patrz sekcja 1. Do oceny prawnika przed zamknięciem transakcji. |
| Odpowiedzialność za dotychczasowe wersje | Historia wydań, znane ograniczenia (patrz known-limitations) i dotychczasowe zgłoszenia podatności stają się częścią materiału due diligence. | Rekomendacja: pełny przegląd known-limitations i rejestru incydentów przed zamknięciem. |
| Zobowiązania wobec dotychczasowych użytkowników | Umowy pilotażowe, zobowiązania SLA, dane testowe/syntetyczne przetwarzane w ramach pilotów. | Wymaga przeglądu istniejących umów — poza zakresem roju, praca prawnika/działu handlowego. |
| Dokumentacja techniczna | Opis architektury, model danych, lista endpointów, testy, known-limitations, status matrix. | Dostępna w repozytorium i na stronach przeglad-produktu oraz known-limitations. |
Powiązane: zegar terminów → /deadline-clock · przegląd compliance → /compliance · oś czasu obowiązków → /legal-timeline · przegląd produktu ipIII → /przeglad-produktu · silnik reguł → /legal-engine · przegląd decyzji → /legal-board · znane ograniczenia → /known-limitations.