k0nsult.cloud / ai-truth / ipIII / playbook-ai-act
Playbook K — Incydenty AI Act i systemy high-risk
Reagowanie na incydenty systemów AI objętych rozporządzeniem AI Act, ze szczególnym naciskiem na systemy wysokiego ryzyka (high-risk, Aneks III). Poziom 3 (naruszenia prawne). Playbook obejmuje klasyfikację, ocenę „poważnego incydentu" (AI_SERIOUS_INCIDENT), raport w trybie art. 73 i corrective action plan.
Jeśli system AI wpływa na prawa, dostęp do usług lub decyzje wobec ludzi — obowiązek dowodu leży po stronie dostawcy/operatora, nie po stronie poszkodowanego.
AI Act nie karze „użycia AI", lecz brak zarządzania ryzykiem: brak rejestru, brak nadzoru człowieka, brak logów, brak reakcji na poważny incydent. Playbook K przekłada te obowiązki na wykonalną ścieżkę incydentalną — od pytania „czy to w ogóle AI?" do raportu i corrective action.
Status regulacyjny (ramka, norma) PUBLIC CLAIM: obowiązki dla systemów wysokiego ryzyka z Aneksu III (m.in. scoring kredytowy, HR/rekrutacja, dostęp do świadczeń, edukacja) — pierwotny termin 2.08.2026 — w ramach pakietu Digital Omnibus zostały odroczone do 2.12.2027. Bez zmian pozostają: obowiązki transparencji z art. 50 (oznaczanie treści AI), zasady dla GPAI oraz zakazy praktyk (weszły 2.02.2025). Daty i zakres potwierdzać w aktualnym tekście rozporządzenia — to nie porada prawna.
Problem — kiedy AI staje się sprawą prawną
Incydent K wyzwala się, gdy system AI wpływa na sytuację prawną lub życiową człowieka. Obszary typowo wrażliwe (Aneks III):
Dostęp do usług finansowych
Ocena zdolności kredytowej (scoring), decyzje o przyznaniu/odmowie produktu — kluczowy obszar bankowy.
Zatrudnienie i HR
Rekrutacja, selekcja CV, ocena pracowników, decyzje o awansie/zwolnieniu wspierane AI.
Edukacja
Ocena, rekrutacja na studia, przydział — wpływ na ścieżkę życiową.
Świadczenia i uprawnienia
Dostęp do świadczeń publicznych, ich przyznanie, ograniczenie lub odebranie.
Bezpieczeństwo
Systemy AI w komponentach bezpieczeństwa produktów / infrastruktury.
Decyzje administracyjne
Wsparcie decyzji organów wpływających na prawa jednostki.
Rozwiązania — infrastruktura zgodności AI
| Element | Cel | Realizacja |
| Rejestr systemów AI | Wiedza, jakie AI działa i gdzie | inwentaryzacja: nazwa, przeznaczenie, dane, decyzje, powiązane procesy |
| Klasyfikacja high-risk | Ustalenie reżimu prawnego | mapowanie do Aneksu III / wyłączeń; wynik: high-risk TAK/NIE/DO USTALENIA |
| Owner systemu | Jednoznaczna odpowiedzialność | przypisany właściciel biznesowy + AI Safety Officer |
| Dokumentacja przeznaczenia | Zgodność użycia z zamiarem | opis intended purpose, ograniczeń, znanych ryzyk |
| Log decyzji | Odtwarzalność i rozliczalność | rejestr wejść, wersji modelu, wyniku i uzasadnienia decyzji |
| Human oversight | Realny nadzór człowieka | możliwość interwencji/odrzucenia decyzji AI; nie „klik akceptuj" |
| Post-market monitoring | Nadzór po wdrożeniu | ciągła obserwacja działania, jakości, driftu i skarg |
| Incident reporting template | Gotowość do raportu | szablon zgłoszenia poważnego incydentu (art. 73) |
| RCA + corrective action | Nauka i naprawa | analiza przyczyn źródłowych + plan działań naprawczych z terminami |
Playbook — 9 kroków reakcji
CZY AI?→HIGH-RISK?→SZKODA→SERIOUS?→ZABEZPIECZ LOGI→LEGAL→RAPORT ART.73→CORRECTIVE→POST-MARKET
Krok 1 — Sprawdź, czy to system AI. Ustal, czy zdarzenie dotyczy systemu AI w rozumieniu AI Act (rejestr systemów). Jeśli nie — incydent wychodzi z tej ścieżki. Flaga AI_ACT_RELEVANT gdy tak.
Krok 2 — Czy high-risk? Mapuj system do Aneksu III (scoring, HR, świadczenia, edukacja, bezpieczeństwo, decyzje administracyjne). Wynik: high-risk TAK / NIE / DO USTALENIA. Flaga AI_HIGH_RISK gdy tak. DO USTALENIA → GAP i eskalacja do Legal.
Krok 3 — Oceń szkodę. Jaki jest realny skutek dla osób/praw: błędna odmowa usługi, dyskryminacja, szkoda majątkowa, naruszenie danych, zagrożenie zdrowia/bezpieczeństwa? Dokumentuj zakres i dotknięte osoby.
Krok 4 — AI_SERIOUS_INCIDENT? YES / NO / UNKNOWN. Oceń, czy zdarzenie spełnia przesłanki „poważnego incydentu" (m.in. poważna szkoda dla zdrowia, praw podstawowych, mienia lub środowiska). Status UNKNOWN traktuj jak GAP — nie zamykaj, wymagaj rozstrzygnięcia.
Krok 5 — Zabezpiecz logi. Zamroź komplet dowodów:
logi wejścia (dane),
modelu (wersja, konfiguracja),
decyzji (wynik, uzasadnienie) i
nadzoru (kto/kiedy interweniował). Hash + znacznik czasu →
Evidence Layer.
Krok 6 — Legal review. Legal/DPO + AI Safety Officer oceniają obowiązki: AI Act (raport), RODO (jeśli dane osobowe / zautomatyzowana decyzja — art. 22), sektorowe (KNF). Ustal adresata i termin. Raport nie może zawierać GAP przebranego za fakt (patrz
Playbook I).
Krok 7 — Raport (tryb art. 73). Przy poważnym incydencie z systemem high-risk — zgłoszenie do właściwego organu nadzoru rynku w trybie i terminach art. 73 AI Act, zgodnie z szablonem incident reporting. Zachowaj kopię i potwierdzenie doręczenia jako dowód.
Krok 8 — Corrective action. Na podstawie RCA opracuj plan działań naprawczych: korekta modelu/danych, wzmocnienie nadzoru, ograniczenie użycia, wycofanie, komunikacja do dotkniętych osób. Przypisz właścicieli i terminy.
Krok 9 — Update post-market. Zaktualizuj monitoring po wdrożeniu, dokumentację ryzyka i rejestr systemów. Potwierdź skuteczność naprawy dowodem → dopiero wtedy zamknięcie. Wnioski zasilają odporność i klasyfikację kolejnych systemów.
Flagi prawne i sprzężenia
| Warunek | Flaga | Konsekwencja |
| Zdarzenie dotyczy systemu AI | AI_ACT_RELEVANT | Wejście w ścieżkę K |
| System z Aneksu III | AI_HIGH_RISK | Reżim high-risk: nadzór, logi, raportowanie |
| Poważny skutek | AI_SERIOUS_INCIDENT | Raport art. 73 do organu nadzoru |
| Zautomatyzowana decyzja na danych osobowych | GDPR_PERSONAL_DATA | RODO art. 22 (decyzje zautomatyzowane), art. 33/34 przy naruszeniu |
| System w usłudze kluczowej / infrastrukturze | NIS2_RELEVANT / CRITICAL_INFRA | Sprzężenie z obowiązkami NIS2/KSC |
Powiązanie z resztą systemu: incydent agentowy (
H) lub halucynacja operacyjna (
I) w systemie high-risk automatycznie wchodzi w ścieżkę K. Deepfake (
J) sprzęga się z obowiązkiem transparencji art. 50. Pełny widok obowiązków —
Compliance & raportowanie i
Legal Board.
Metryki dojrzałości AI Act SYMULACJA
Dane demonstracyjne (demo). Wartości ilustrują format panelu, nie są rzeczywistymi pomiarami środowiska odbiorcy.
100%
Systemów AI w rejestrze z ownerem SYMULACJA
cel obrony
100%
Systemów high-risk z human oversight SYMULACJA
wymóg
100%
Decyzji high-risk z pełnym logiem SYMULACJA
odtwarzalność
0
Incydentów SERIOUS zamkniętych bez RCA SYMULACJA
claim ≤ proof
Powiązane strony
Compliance & raportowanie
Pełny rejestr obowiązków i terminów. → Compliance
Legal Board
Flagi prawne i status zgłoszeń do organów. → Legal Board
Agent hijack
Poważny incydent agentowy w systemie high-risk. → Playbook H
Halucynacja / GAP
Raport bez GAP przebranego za fakt. → Playbook I
Uwaga metodyczna: ramki AI Act (Aneks III, art. 50, art. 73, terminy) opisano na podstawie publicznie znanej treści rozporządzenia i pakietu Digital Omnibus (PUBLIC CLAIM / norma) — to nie jest porada prawna, a daty i zakres należy potwierdzać w aktualnym tekście aktu. Metryki oznaczone SYMULACJA są przykładowe.