MANAGE: opatření a řízení rizik

Jak prioritizovat rizika, implementovat mitigace a řídit incidenty

NIST AI RMF funkce: MANAGE Sekce průvodce: MG-1 až MG-4

Označení MG člení tento průvodce; nejde o oficiální identifikátory kategorií nebo subkategorií NIST. NIST AI RMF je dobrovolný rámec; kontroly, skóre a harmonogramy níže jsou vlastní příklady k přizpůsobení konkrétnímu systému.

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

Jde o ilustrativní interní model, nikoli předepsaný vzorec NIST ani klasifikaci podle AI Actu. Přijetí zbytkového rizika v registru neumožňuje přijmout porušování práva; použitelné povinnosti platí bez ohledu na skóre.

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	Část finančního či smluvního rizika	Pojištění, SLA; nepřenášejí zákonné povinnosti organizace
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	Interní kontrola před nasazením, kde je relevantní
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; pseudonymizované údaje zůstávají osobními údaji, lze-li je přiřadit identifikovatelné osobě
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 určená rozhodnutí	Kde je předchozí lidské posouzení vhodné nebo povinné
Human-on-the-loop	Člověk monitoruje a může zasáhnout	Kde je účinný průběžný dohled a zásah
Human-in-command	Člověk nastavuje pravidla a hranice použití	Governance celého procesu

Jde o návrhové vzory, nikoli přímé mapování na právní kategorie rizika. Čl. 14 AI Actu vyžaduje u systémů v jeho působnosti účinný a přiměřený lidský dohled; zohledněte použitelnost podle čl. 111 a 113. Prahy a eskalační kritéria v příkladu níže jsou interní, nikoli obecný právní test.

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:

Pro tento interní postup je AI incident událost související s AI, která způsobí nebo může způsobit újmu, porušení pravidel či významné narušení služby. Jde o pracovní definici pro eskalaci, nikoli právní definici závažného incidentu podle čl. 3 bodu 49 AI Actu, bezpečnostního incidentu podle kybernetických předpisů nebo porušení zabezpečení osobních údajů podle čl. 4 bodu 12 GDPR.

4.2 Incident kategorie

Závažnost v tabulce je ilustrativní interní priorita. Skutečná klasifikace závisí na dopadech a kritériích příslušného režimu.

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

Ilustrativní interní cíle reakce. Přizpůsobte je provozu a riziku; nemění zákonné lhůty ani nevytvářejí příslib podpory TECHNOMATON.

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 Regulatorní oznámení

U každého incidentu evidujte, kdy organizace získala povědomí o události, kdy ji klasifikovala a podle jakých kritérií. Nejde o jedinou společnou lhůtu:

GDPR: správce oznamuje dozorovému úřadu bez zbytečného odkladu a pokud možno do 72 hodin od zjištění porušení, ledaže je nepravděpodobné riziko pro práva a svobody. Zpracovatel informuje správce bez zbytečného odkladu; dotčené osoby mají vlastní režim při vysokém riziku.
Kybernetická bezpečnost: v ČR určete působnost a režim podle § 15–18 zákona č. 264/2025 Sb., včetně zvláštního režimu digitálních služeb podle § 18. Čl. 23 NIS2 rozlišuje včasné varování, oznámení a závěrečnou zprávu; obecná 72hodinová lhůta oznámení od zjištění významného incidentu není konečný report a pro poskytovatele služeb vytvářejících důvěru je stanovena 24hodinová lhůta.
DORA: finanční subjekt v působnosti oznamuje závažný ICT incident co nejdříve, nejvýše do 4 hodin od klasifikace a nejpozději do 24 hodin od zjištění. Čl. 5 nařízení (EU) 2025/301 stanoví zvláštní pravidlo pro pozdější klasifikaci, podmíněné posuny o víkendech a bankovních svátcích i jejich výjimky a samostatné lhůty dalších zpráv.
AI Act: čl. 73 se týká poskytovatelů vysokorizikových systémů a rozlišuje lhůty podle události. Povinnosti nasazujícího subjektu a datum použitelnosti posuďte zvlášť.

Podrobnosti a aktuální zdroje: GDPR, kybernetická bezpečnost, DORA a AI Act.

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