NIST AI RMF: Manage Function

Descripción

Map identificó risks. Measure los cuantificó. Manage actúa: prioriza, mitiga, monitorea respuesta. Esta es la función operacional — donde governance + analysis se convierten en cambios reales.

Al terminar vas a poder:

• Priorizar risks basado en impact × likelihood
• Diseñar 4 tipos de risk response (mitigate, accept, transfer, avoid)
• Implementar incident response para AI
• Trackear el estado de remediation actions

---

Las 4 categorías de Manage

Manage 1: Risks prioritized

Combinás impact y likelihood:

	Low Impact	Medium Impact	High Impact	Critical Impact
Low Likelihood	Accept	Accept	Mitigate (low priority)	Mitigate (medium)
Medium Likelihood	Accept	Mitigate (low)	Mitigate (medium)	Mitigate (high)
High Likelihood	Mitigate (low)	Mitigate (medium)	Mitigate (high)	Mitigate (critical)
Certain	Mitigate (medium)	Mitigate (high)	Mitigate (critical)	Mitigate (critical)

Critical priority: block production hasta mitigated. High priority: mitigate in current sprint. Medium: plan for next quarter. Low: monitor, no immediate action.

Manage 2: Risk response strategies

4 strategies fundamentales:

Mitigate: implementar controles para reducir impact o likelihood. Accept: documentar y aceptar el risk (some risks no se pueden eliminar). Transfer: shift el risk (insurance, partner agreement, contractual). Avoid: no implementar la feature/system que causa el risk.

Manage 3: Continuous risk monitoring

Risks no son static. Monitor:

• ¿Nuevos risks emergiendo?
• ¿Mitigations still effective?
• ¿Impact assumptions still válidas?

Manage 4: Communication and disclosure

Stakeholders need to know:

• Internal team: detailed risk picture
• Customers: relevant disclosures (without compromising security)
• Regulators: required disclosures
• Public: as appropriate (e.g., responsible disclosure of vulnerabilities)

---

Decision framework: cuándo aplica cada strategy

Risk: Tenant data leakage (critical)
  ↓
  Likelihood: medium (Pinecone filter bug possible)
  Impact: catastrophic (legal, reputational)
  ↓
  Strategy: MITIGATE
  - Implement strict tenant isolation
  - Add validation at multiple layers
  - Penetration testing
  - Monitoring for cross-tenant access patterns


Risk: Vendor lock-in (OpenAI)
  ↓
  Likelihood: high (already locked)
  Impact: medium (cost increase if OpenAI changes pricing)
  ↓
  Strategy: TRANSFER + MITIGATE
  - Transfer: contractual agreements with OpenAI (price stability)
  - Mitigate: build multi-provider architecture for future flexibility


Risk: Worker displacement (societal)
  ↓
  Likelihood: low
  Impact: medium (broader societal, not direct to us)
  ↓
  Strategy: ACCEPT
  - Document acknowledgment
  - Participate in industry conversations
  - Not within our direct control


Risk: Building an AI for criminal sentencing (hypothetical)
  ↓
  Likelihood: N/A
  Impact: catastrophic (ethics, legal, reputational)
  ↓
  Strategy: AVOID
  - Decision: do not build this product

---

Implementation: Risk Register

Document central que tracking todos los risks:

# Risk Register — AI Knowledge Assistant
Last updated: 2026-05-11

## Critical Risks (3)

### R001: Tenant Data Leakage
- **Description**: Tenant A user receives data from Tenant B
- **Identified**: Map document, 2026-XX-XX
- **Impact**: Catastrophic (legal, reputational, contract breach)
- **Likelihood**: Medium (filter bugs possible)
- **Strategy**: MITIGATE
- **Mitigations**:
  - [x] Strict tenant_id filter in all RAG queries
  - [x] Database constraints preventing cross-tenant access
  - [ ] Penetration testing (scheduled Q3)
  - [ ] Automated monitoring for anomalies
- **Owner**: Tech Lead
- **Review date**: Quarterly
- **Status**: Active mitigation

### R002: Hallucination affecting decisions
[similar detail]

### R003: Art. 22 GDPR violation
[similar detail]

## High Risks (5)

[similar structure]

## Medium Risks (8)

[similar structure]

## Low Risks (10)

[similar structure]

## Accepted Risks (5)

These are risks we've documented and accepted:

### A001: Worker displacement
- **Description**: AI assistant reduces need for support staff
- **Rationale for accepting**: Indirect, societal impact outside direct control
- **Monitoring**: Industry trend analysis

---

Incident response for AI

Cuando un risk materializa, necesitás process clear:

1. Detection
   - Monitoring detects anomaly OR user reports
   - Automated alert to on-call

2. Triage
   - Assess severity (P0/P1/P2/P3)
   - Identify affected users/systems

3. Containment
   - Stop the bleeding (e.g., disable feature, switch to fallback)
   - Communicate internally

4. Investigation
   - Root cause analysis
   - Document timeline
   - Identify other risks

5. Resolution
   - Implement fix
   - Verify fix
   - Re-enable affected features

6. Communication
   - Internal post-mortem
   - User notification (if applicable)
   - Regulator notification (if GDPR breach)

7. Learning
   - Update mitigations
   - Update risk register
   - Update runbook

SLA targets:

• P0 (critical, affecting all users): respond <15 min, resolve <4h
• P1 (high): respond <1h, resolve <24h
• P2 (medium): respond <4h, resolve <1 week
• P3 (low): respond <1 day, resolve <1 month

---

Communicating risk to non-technical stakeholders

CEOs, CFOs, customers need risk info without overwhelming detail:

"We've identified 23 risks in our AI system across categories like
data security, bias, performance, and compliance.

Of these:
- 3 are Critical and have active mitigation in progress
- 5 are High priority being addressed this quarter
- 13 are Medium/Low being monitored
- 5 are documented as accepted (low impact or outside our control)

Our mitigation budget is $X, allocated to top priorities first.
Next quarterly review: [date].

Detailed report available [link]."

Principle: signal (3 numbers + decision criteria) > noise (50-page report nobody reads).

---

Trampas comunes

Trampa 1 — Risk register que se hace una vez. Created Q1, never updated. Risks change quarterly minimum.

Trampa 2 — All risks "mitigate". Imposible. Some risks tenés que aceptar. Trying to mitigate everything = mitigating poorly.

Trampa 3 — Mitigations sin owner. "Tenant isolation will be addressed." ¿Por quién? ¿Cuándo? Sin ownership, no se hace.

Trampa 4 — Sin incident response plan. "Cuando pase algo, lo manejaremos." Para AI, breaches pueden ser disastrous. Plan ahead.

Trampa 5 — Mitigations sin verification. Implementaste mitigation, no testeás si funciona. Mide effectiveness (M6-04).

---

Ejercicio

Para tu Capstone:

1. Crear Risk Register basado en M6-03 Map
2. Aplica priorización (critical/high/medium/low)
3. Para cada critical risk: define mitigation strategy con owner + target
4. Drafteá Incident Response Plan (high level, 1 page)

Ver solución (skeleton)

Risk Register top critical for Knowledge Assistant:

1. Tenant data leakage (Critical, M)

   • Mitigation: strict filtering, validation, pen test
   • Owner: Tech Lead, target Q1 done

2. Hallucination affecting decisions (Critical, M)

   • Mitigation: confidence display, human review, citations required
   • Owner: ML Engineer, target Q1

3. Compliance violations (Art. 22) (Critical, L)

   • Mitigation: human review for significant decisions, explanation provided
   • Owner: Tech Lead + DPO

Incident Response Plan (skeleton):

• On-call rotation (1 engineer 24/7)
• Severity assessment matrix
• Communication template (internal Slack, external email)
• Post-mortem template
• Quarterly DR drills
• SLAs by severity

---

Resumen

Aprendiste:

• ✅ 4 categorías de Manage (prioritize, response, monitor, communicate)
• ✅ 4 strategies de risk response (mitigate, accept, transfer, avoid)
• ✅ Risk Register template
• ✅ Incident response plan
• ✅ Communicating to non-technical stakeholders
• ✅ Trampas: never updated, all-mitigate mentality, sin owners

Checkpoint: si tenés Risk Register vivo con owners, mitigations tracked, IR plan, Manage está funcional.

---

Siguiente cápsula

06 — IEEE 7000 series. Después de profundizar NIST AI RMF, vemos IEEE — ethics standards más conceptual pero útil como vocabulary.

---

Recursos

1. NIST AI RMF Playbook — Manage.
2. Atlassian — Incident Management — for IR patterns.
3. Google SRE — Incident Response — comprehensive.
4. Risk Register templates — examples.