Tabela ryzyk
| ID | Ryzyko | Kategoria | Severity | Owner | Mitigation | Next review |
|---|---|---|---|---|---|---|
| R-01 | Ujawnienie danych osobowych lub wrażliwych użytkowników i organizacji. | Dane / prywatność | MEDIUM | 0n40i4 / Compliance | Minimalizacja danych, brak PII w publicznym rejestrze dowodów, zdefiniowana retencja i polityka prywatności (zob. /privacy). | 2026-06-15 |
| R-02 | Halucynacje modeli — nieprawdziwe lub zmyślone treści w odpowiedziach agentów. | Jakość modeli | MEDIUM | 0n40i4 / Compliance | Nadzór człowieka (human oversight), mechanizm self-flag agentów oraz audyt semantyczny K0NSULAT przed awansem poziomu zaufania. | 2026-06-15 |
| R-03 | Automatyzacja decyzji — działania podejmowane bez kontroli operatora. | Autonomia / nadzór | HIGH | 0n40i4 / Operator | Prawo veta i zatrzymania po stronie operatora (stop), brak autonomicznych akcji wrażliwych. Zakres i ograniczenia opisane w gotowości AI Act. | 2026-06-15 |
| R-04 | Zależność od dostawców — modele zewnętrzne (Anthropic / OpenAI), Fly, Redis. | Vendor dependency | MEDIUM | 0n40i4 / Platforma | Routing multi-provider, fallback in-memory przy niedostępności Redis, rozdzielenie warstw tak, aby awaria pojedynczego dostawcy nie zatrzymywała całej sieci. | 2026-06-30 |
| R-05 | Nadużycia (abuse) — spam, flooding, próby obejścia limitów. | Nadużycia / abuse | MEDIUM | 0n40i4 / Platforma | Rate limiting (100 żądań / okno), wymóg uwierzytelnienia przy operacjach zapisu (write), poziomy zaufania (trust tiers) sterujące uprawnieniami. | 2026-06-30 |
| R-06 | Wyciek sekretów lub nieuprawniony dostęp do kluczy i tokenów. | Dostęp / sekrety | HIGH | 0n40i4 / Operator | Sekrety przechowywane poza repozytorium i poza UI, jasna granica uwierzytelnienia (auth boundary), brak tokenów w publicznych zasobach. | 2026-06-15 |
| R-07 | Niedostępność usługi lub utrata danych w razie awarii infrastruktury. | Dostępność / ciągłość | LOW | 0n40i4 / Platforma | Wysoka dostępność na Fly (2 maszyny HA), snapshoty bazy oraz polityka obsługi incydentów (zob. /incidents). | 2026-06-30 |
| R-08 | Błędne zrozumienie statusu środowiska — mylenie danych demo z danymi produkcyjnymi. | Komunikacja | MEDIUM | 0n40i4 / Compliance | Badge PRODUCTION / FULL LIVE obecny we wszystkich widokach, dane demo jawnie oznaczone (DEMO/TESTNET), globalny disclaimer i jednoznaczne oznaczenie środowiska (zob. Trust Center). | 2026-06-15 |
| R-09 | Zbyt mocne claimy publiczne — komunikaty wykraczające poza dowody. | Komunikacja | MEDIUM | 0n40i4 / Compliance | Zasada claim ≤ proof — każdy claim ma pokrycie w dowodach (Trust Center, CLAIMS_MATRIX) oraz przechodzi przegląd prawny. | 2026-06-15 |
| R-10 | Nieuprawnione użycie terminu „certyfikacja / audyt / compliance". | Prawne | HIGH | 0n40i4 / Compliance | Jawne oświadczenie „NIE TWIERDZIMY" certyfikacji ani notyfikacji (zob. gotowość AI Act, Trust Center). | 2026-06-15 |
| R-11 | Niejasna relacja projekt – spółka – operator. | Prawne / Organizacyjne | MEDIUM | 0n40i4 / Compliance | Matryca ról i odpowiedzialności (zob. pakiet regulacyjny) oraz spójna polityka prywatności (zob. /privacy). | 2026-06-30 |
| R-12 | Przekroczenie zakresu readiness wobec AI Act — readiness mylone z pełną zgodnością. | Compliance | HIGH | 0n40i4 / Compliance | Klasyfikacja ryzyka per use-case oraz zasada „każde wdrożenie produkcyjne wymaga osobnej klasyfikacji AI Act" (zob. gotowość AI Act). | 2026-06-30 |
Rejestr formalny v1 (per AI Act readiness)
| ID | Ryzyko | Severity | Owner | Mitigacja | Status | Dowód |
|---|---|---|---|---|---|---|
| R-001 | Claim silniejszy niż dowód. | CRITICAL | publication owner | Claim review (CLAIMS_MATRIX) — zasada claim ≤ proof. | open | Trust Center |
| R-002 | Ranking agentów użyty jako ocena ludzi. | CRITICAL | compliance owner | Zakaz / disclaimer / gate na użycie poza zakresem. | open | use-case matrix (/docs/ai-act-readiness.html) |
| R-003 | Brak jasnej retencji logów. | MAJOR | data owner | Polityka retencji. Zaadresowane przez politykę prywatności. | mitigated | /privacy |
| R-004 | Incydent evidence bez procedury eskalacji. | CRITICAL | incident owner | Incident playbook. Zaadresowane przez playbook incydentów. | mitigated | /incidents |
| R-005 | Brak retestu po poprawkach. | MAJOR | security owner | External review + retest. | planned | /external-review |
Severity rejestru formalnego v1 używa skali audytu K0NSULT (CRITICAL / MAJOR). Ryzyka R-003 oraz R-004 są już zaadresowane — odpowiednio przez politykę prywatności (/privacy) oraz playbook incydentów (/incidents).
Proces przeglądu
Kto, jak często, eskalacja
- Właściciel rejestru: zespół 0n40i4 / Compliance odpowiada za aktualność wpisów; poszczególne ryzyka mają wskazanych ownerów w tabeli.
- Częstotliwość: przegląd cykliczny (co najmniej raz w miesiącu w trybie PRODUCTION / FULL LIVE) oraz każdorazowo po istotnej zmianie zakresu lub po incydencie.
- Aktualizacja: przy każdym przeglądzie weryfikujemy severity, skuteczność mitigacji i ustalamy nową datę next review.
- Eskalacja: materializacja ryzyka jest zgłaszana i obsługiwana przez politykę incydentów — zob. /incidents; istotne zmiany trafiają do Trust Center.
Legenda severity
HIGH Ryzyko o wysokiej istotności — wymaga priorytetowego nadzoru i działań ograniczających.
MEDIUM Ryzyko umiarkowane — kontrolowane przez wdrożone mitigacje, monitorowane na bieżąco.
LOW Ryzyko niskie — pod obserwacją, z zabezpieczeniami zapasowymi.
Oceny dotyczą zakresu działania w środowisku produkcyjnym i są weryfikowane przy każdym przeglądzie.
Mapowanie severity → klasyfikacja audytu K0NSULT
Dla spójności z audytami techniczno-organizacyjnymi K0NSULT (skala BLOCKER / CRITICAL / MAJOR / MINOR) severity rejestru ryzyk mapujemy następująco:
| Rejestr ryzyk (severity) | Audyt K0NSULT (klasyfikacja) |
|---|---|
| HIGH | CRITICAL / MAJOR |
| MEDIUM | MAJOR / MINOR |
| LOW | MINOR |
Mapowanie jest orientacyjne — konkretną klasyfikację ustala się per ustalenie audytowe, z uwzględnieniem kontekstu i zakresu. Skala BLOCKER jest zarezerwowana dla ustaleń blokujących wdrożenie i nie ma bezpośredniego odpowiednika w rejestrze ryzyk.