MANAGE

Jak prioritizovat rizika, implementovat mitigace a řídit incidenty

NIST AI RMF funkce: MANAGE Subkategorie: MG-1 až MG-4

---

1. Přehled funkce MANAGE

MANAGE funkce převádí výsledky z MAP a MEASURE do konkrétních akcí.

Cíle MANAGE

Cíl	Popis
Prioritizace	Seřadit rizika podle závažnosti
Mitigace	Implementovat kontrolní opatření
Incidenty	Řídit AI incidenty
Improvement	Kontinuálně zlepšovat

---

2. MG-1: Risk Prioritization

2.1 Risk scoring

Risk Score = Likelihood × Impact × Detectability

Faktor	1 (Low)	2 (Medium)	3 (High)	4 (Critical)
Likelihood	Rare	Possible	Likely	Almost certain
Impact	Minor	Moderate	Major	Severe
Detectability	Easy	Moderate	Difficult	Very difficult

Score interpretace:

Score	Level	Action
1-8	Low	Accept or monitor
9-16	Medium	Mitigate within quarter
17-32	High	Mitigate within month
33-64	Critical	Immediate action

2.2 Risk register

## AI RISK REGISTER

| ID | Risk | System | L | I | D | Score | Status | Due |
|----|------|--------|---|---|---|-------|--------|-----|
| R001 | Bias in hiring | AI-001 | 3 | 4 | 2 | 24 | Mitigating | 2025-02 |
| R002 | Data privacy | AI-002 | 2 | 3 | 3 | 18 | Accepted | - |
| R003 | Hallucination | AI-003 | 4 | 3 | 3 | 36 | Critical | 2025-01 |

2.3 Risk treatment options

Option	Kdy použít	Příklad
Avoid	Nepřijatelné riziko	Nepoužívat AI pro daný účel
Mitigate	Snížitelné riziko	Implementovat kontroly
Transfer	Přenositelné riziko	Pojištění, SLAs
Accept	Akceptovatelné zbytkové riziko	Dokumentovat a monitorovat

---

3. MG-2: Risk Mitigation

3.1 Control framework

3.2 Kontroly dle rizika

Pro Bias/Fairness rizika

Kontrola	Typ	Implementace
Diverse training data	Preventive	Data curation process
Bias testing pre-deployment	Preventive	Mandatory fairness check
Fairness monitoring	Detective	Continuous metric tracking
Human review for decisions	Detective	Sample review process
Appeal mechanism	Corrective	User-facing appeal process
Retraining pipeline	Corrective	Triggered by drift

Pro Privacy rizika

Kontrola	Typ	Implementace
Data minimization	Preventive	Only necessary data
Anonymization/pseudonymization	Preventive	Pre-processing pipeline
Access controls	Preventive	RBAC, least privilege
PII detection in outputs	Detective	Content scanning
Data breach response	Corrective	Incident response plan

Pro Safety rizika (GAI)

Kontrola	Typ	Implementace
Content filters	Preventive	Input/output filtering
System prompts	Preventive	Safety instructions
Rate limiting	Preventive	Abuse prevention
Output monitoring	Detective	Toxicity scoring
Kill switch	Corrective	Immediate disable capability
User blocking	Corrective	Ban abusive users

3.3 Human oversight

Levels of human oversight:

Level	Popis	Kdy použít
Human-in-the-loop	Člověk schvaluje každé rozhodnutí	High-risk, critical decisions
Human-on-the-loop	Člověk monitoruje a může zasáhnout	Medium-risk, batch decisions
Human-in-command	Člověk nastavuje pravidla, AI operuje	Low-risk, high-volume

Implementace:

## HUMAN OVERSIGHT DESIGN

### 1. Decision Point
- Co AI doporučuje vs. rozhoduje?
- Kdy je vyžadován human review?

### 2. Escalation Criteria
| Trigger | Akce |
|---------|------|
| Confidence < 80% | Human review |
| High-impact decision | Mandatory approval |
| Edge case detected | Escalate to expert |
| User requests | Always allow |

### 3. Override Capability
- Kdo může overridnout AI?
- Jak je override logován?
- Jaký je feedback loop do modelu?

### 4. Appeal Process
- Jak může dotčená osoba podat odvolání?
- Kdo rozhoduje o odvolání?
- Jaké jsou lhůty?

---

4. MG-3: Incident Management

4.1 AI Incident definice

Co je AI incident:

“Událost nebo série událostí, kde vývoj, použití nebo porucha AI systému přímo či nepřímo přispívá ke škodě na zdraví, narušení kritické infrastruktury, porušení lidských práv nebo škodě na majetku/komunitách/životním prostředí.”

4.2 Incident kategorie

Kategorie	Příklady	Severity
Safety	Fyzická újma, nebezpečný obsah	Critical
Privacy	Data breach, PII leak	Critical
Bias/Discrimination	Unfair outcomes, discrimination	High
Misinformation	Hallucinations with impact	High
Security	Adversarial attack, system compromise	Critical
Performance	Major accuracy degradation	Medium
Availability	System outage	Medium-High

4.3 Incident response process

4.4 Incident response SLAs

Severity	Detection → Triage	Triage → Containment	Resolution	Communication
P1 Critical	15 min	1 hour	ASAP	Immediate
P2 High	1 hour	4 hours	24 hours	4 hours
P3 Medium	4 hours	24 hours	1 week	24 hours
P4 Low	24 hours	1 week	1 month	As needed

4.5 Regulatory notification

Regulace	Trigger	Lhůta	Komu
GDPR	Personal data breach	72 hodin	ÚOOÚ
NIS2	Significant incident	24h early warning, 72h notification	NÚKIB
DORA	Major ICT incident	4 hodiny	ČNB
EU AI Act	Serious incident	15 dní (nebo ihned)	Market surveillance

4.6 Incident report template

# AI INCIDENT REPORT

## Metadata
| Field | Value |
|-------|-------|
| Incident ID | INC-2025-XXXX |
| System | |
| Detected | YYYY-MM-DD HH:MM |
| Resolved | YYYY-MM-DD HH:MM |
| Severity | P1/P2/P3/P4 |
| Category | Safety/Privacy/Bias/Security/Performance |

## Summary
[1-2 sentence summary]

## Timeline
| Time | Event |
|------|-------|
| | Detection |
| | Triage |
| | Containment |
| | Resolution |

## Impact
- Users affected:
- Data affected:
- Business impact:
- Reputation impact:

## Root Cause
[Description of underlying cause]

## Resolution
[What was done to fix]

## Preventive Actions
| Action | Due |
|--------|-----|
| | |

## Lessons Learned
[Key takeaways]

## Regulatory Notifications
| Regulator | Notified | Reference |
|-----------|----------|-----------|
| | | |

---

5. MG-4: Continuous Improvement

5.1 Improvement cycle

5.2 Review cadence

Review	Frekvence	Scope	Účastníci
Operational	Weekly	Active incidents, metrics	AI Ops team
Tactical	Monthly	Risk register, controls	AI Risk Officer + Owners
Strategic	Quarterly	Governance, trends	Leadership
Annual	Yearly	Full program review	Board

5.3 Improvement sources

Zdroj	Typ inputů	Jak získat
Incidents	Lessons learned	Post-mortems
Metrics	Performance trends	Dashboards
Audits	Findings, recommendations	Internal/external audits
Feedback	User complaints, suggestions	Feedback channels
Regulatory	New requirements	Regulatory monitoring
Industry	Best practices	Conferences, publications

5.4 Decommissioning

Kdy decommissionovat AI systém:

• Performance trvale pod thresholdem
• Business need již neexistuje
• Bezpečnostní riziko nelze mitigovat
• Regulatorní požadavky nelze splnit
• Lepší alternativa je dostupná

Decommissioning checklist:

• Notifikovat stakeholdery
• Zajistit data retention/deletion dle požadavků
• Aktualizovat inventuru
• Dokumentovat lessons learned
• Archivovat relevantní dokumentaci
• Potvrdit compliance s data retention policies

---

6. Implementační checklist

Fáze 1: Risk Treatment (Týden 1-2)

• Vytvořit risk register
• Definovat scoring metodologii
• Přiřadit vlastníky rizik
• Navrhnout mitigační plány

Fáze 2: Controls (Týden 3-4)

• Implementovat preventivní kontroly
• Nastavit detektivní kontroly
• Připravit korektivní mechanismy
• Dokumentovat human oversight

Fáze 3: Incident Response (Týden 5-6)

• Definovat incident process
• Přiřadit role a odpovědnosti
• Nastavit komunikační kanály
• Provést tabletop exercise

Fáze 4: Continuous (Ongoing)

• Pravidelné reviews
• Incident post-mortems
• Metric-driven improvements
• Regulatory updates

---

7. Šablony

Šablona	Účel	Lokace
Risk Register	Evidence a tracking rizik	/templates/open/
Incident Report	Dokumentace incidentů	/templates/open/
Post-mortem Template	Lessons learned	/templates/open/
Decommissioning Checklist	Ukončení AI systému	/templates/open/

---

Pokračujte na GAI Rizika pro specifika generativní AI.

---

AI-Native Entry Framework | CC BY-NC-SA 4.0