Ai Lifecycle Risk Manager

---
name: ai-lifecycle-risk-manager
description: 'Operationalize the National Institute of Standards and Technology (NIST) Artificial Intelligence (AI) Risk Management Framework (RMF) as an organization risk program across design, development, deployment, operation, and decommissioning. Its GOVERN, MAP, MEASURE, and MANAGE functions form a voluntary risk method, not a certification. Compose ai-governance-risk-reviewer for feature tiering, ai-threat-modeler, ai-evaluation-harness, and incident-response-runbook for procedure authoring. Use when adopting the AI RMF or building an organization profile. Do NOT use for one feature go/no-go, a certifiable AI management system (AIMS), or one feature threat inventory.'
---

# AI Lifecycle Risk Manager

**Reading key:** The National Institute of Standards and Technology (NIST)
Artificial Intelligence (AI) Risk Management Framework (RMF) is a voluntary
risk method. An AI management system (AIMS) is a separate management-system
structure; this page does not claim RMF certification. The
`incident-response-runbook` skill authors procedures; a human incident owner
uses an approved runbook for a live response.
ISO/IEC names standards issued jointly by the International Organization for
Standardization (ISO) and International Electrotechnical Commission (IEC).

## Purpose

Stand up the organization's AI risk program on the NIST AI RMF's four Core
functions — GOVERN (cross-cutting, "infused throughout AI risk
management"), MAP, MEASURE, MANAGE — operating across the whole AI
lifecycle: design, development, deployment, operation, decommission. The
RMF is a voluntary risk method, not something an org is certified against
— its role here is the risk machinery underneath the certifiable AIMS
(`iso-42001-aims-architect`, this skill's companion) and the org-level
program that per-feature reviews (`ai-governance-risk-reviewer`) plug
into. The skill's value is operationalization: each function lands as
concrete practices mapped to shipped skills and named owners with
lifecycle-stage triggers, instead of an RMF poster on the wall.

## Use When

- Use when: adopting the NIST AI RMF, asked to "set up AI risk
  management", or building an org/system AI RMF profile.
- Use when: AI risk practice exists in pieces (feature reviews, threat
  models, evals) and needs an org-level program with lifecycle triggers
  and owners.
- Use when: pairing an ISO/IEC 42001 effort with its underlying risk method, or a
  customer/regulator asks how the org manages AI risk end-to-end.
- Do NOT use when: reviewing ONE AI feature's risk tier, oversight, and
  disclosure — `ai-governance-risk-reviewer` (this program aggregates
  those reviews).
- Do NOT use when: building the certifiable AI management system —
  `iso-42001-aims-architect` (the AIMS wraps this method in
  management-system clauses).
- Do NOT use when: enumerating a specific feature's technical threats
  (`ai-threat-modeler`) or running the evals themselves
  (`ai-evaluation-harness` *(manual-only)*).

## Inputs to Inspect

1. The AI system inventory with lifecycle stage per system (shared with
   `iso-42001-aims-architect` when both run): what AI exists, where each
   system sits (design → decommission), roles, and affected parties.
2. Existing risk practice to compose: `ai-governance-risk-reviewer`
   feature reviews, `ai-threat-modeler` outputs, `ai-evaluation-harness`
   datasets/thresholds, `ai-sdlc-operating-model` stage/authority
   contract, `agent-authorization-matrix`, incident history and human-owned
   postmortems (`incident-response-runbook` can help author procedures), containment posture
   (`agent-containment-reviewer`).
3. The NIST AI RMF text in hand (AI RMF 1.0 and, when generative AI is in
   scope, the Generative AI Profile NIST-AI-600-1) — category-level
   detail comes from the text, not memory; NIST notes 1.0 is under
   revision, so check the current version.
4. Org risk appetite and escalation structure: who owns AI risk
   decisions, what boards/reviews exist.
5. The `compliance-control-foundation` AI-governance domain — the program
   lands as controls there (and crosswalk rows tag their RMF function).

## Workflow

1. **Scope the program.** Which AI systems, which lifecycle stages are
   live, and who owns the program. No inventory → build it first (with
   `iso-42001-aims-architect`'s scope step if that effort runs too) or
   Stop Conditions.
2. **Land GOVERN first — it is cross-cutting.** Accountability structure
   (named owners per system and for the program), risk appetite, policies,
   escalation paths, and the workforce/culture pieces — mapped to what
   exists: `ai-sdlc-operating-model` (stage authority),
   `agent-authorization-matrix` *(manual-only)* (standing agent authority),
   `ai-governance-risk-reviewer`'s accountable-owner discipline. GOVERN
   items recur inside every other function; that's the "infused
   throughout" property, not a section to complete once.
3. **Operationalize MAP per lifecycle stage** using
   [references/ai-rmf-function-map.md](references/ai-rmf-function-map.md):
   context establishment, categorization, and risk identification —
   feature intake via `ai-governance-risk-reviewer` (tier, affected
   parties), technical surface via `ai-threat-modeler`, third-party/model
   provenance via `supply-chain-security-reviewer`. Output: the AI risk
   register rows (shared with the AIMS risk register kept under ISO/IEC 42001 clause 6.1.2, when present).
4. **Operationalize MEASURE.** For each mapped risk: how it is analyzed,
   assessed, and tracked over time — `ai-evaluation-harness` *(manual-only)* (quality/
   safety/grounding/injection thresholds and regression gates),
   red-team cadence, drift/behavior monitoring in operation
   (`observability-operator` *(manual-only)* mechanics), with trackable metrics and
   review dates. Unmeasurable risks are named as such, not silently
   dropped.
5. **Operationalize MANAGE.** Prioritization against risk appetite,
   treatment decisions (avoid/mitigate/transfer/accept — acceptance by a
   named human via `human-approval-boundary`), response procedures authored
   with `incident-response-runbook`, and kill-switch/containment design via
   `agent-containment-reviewer`. A human incident owner follows an approved
   runbook and holds live response authority. Communicate residual risk.
   If no risk appetite is stated for a risk category and treatments cannot
   be prioritized without one, teach the choice before asking: define risk
   appetite (how much residual risk of a kind the org will carry to pursue
   a goal), residual risk, and the four treatments in plain language.
   Present the viable appetite stances for that category (for example low:
   avoid or mitigate before release; moderate: mitigate to measured
   thresholds and accept a named residual), each with why it fits, pros and
   cons, and the setup, upkeep, and money cost of the treatments it implies,
   or unknown. Recommend one, say why and what fact would change it, then
   ask exactly one owner question. The stated appetite guides prioritization
   only; accepting any specific residual risk still needs a named human via
   `human-approval-boundary`.
6. **Wire lifecycle triggers.** Per stage transition (design→dev,
   dev→deploy, deploy→operate, material change, decommission): which
   function activities re-run, who signs. Decommission gets real steps —
   model retirement, data/memory disposition (`agent-memory-governance` *(manual-only)*
   hygiene), dependent-system checks.
7. **Emit the profile and register the controls.** The org's RMF profile
   (functions → practices → owners → triggers), program-level controls
   into `compliance-control-foundation` (AI domain), crosswalk rows
   tagged with their function, and the companion note for
   `iso-42001-aims-architect` (register and impact-assessment sharing).

## Output Format

```
AI RMF PROGRAM — <org> (AI RMF 1.0; GenAI Profile NIST-AI-600-1 if in scope; version-checked: <date>)
Status of source: voluntary framework; 1.0 under revision per NIST — current-version check recorded
Inventory: <AI systems × lifecycle stage × owner>
GOVERN (cross-cutting): <accountability, appetite, policies, escalation → mapped mechanisms (ai-sdlc-operating-model, agent-authorization-matrix, ...)>
Per lifecycle stage (design | development | deployment | operation | decommission):
  MAP:     <context/categorization/risk-identification practices → owners → feeding the AI risk register>
  MEASURE: <analysis/tracking practices → ai-evaluation-harness thresholds, monitoring, cadence>
  MANAGE:  <prioritization, treatment (acceptance = named human), response wiring>
Lifecycle triggers: <transition → re-run activities → signer>
Register: <AI risk register rows (shared with AIMS 6.1.2 where applicable)>
Controls registered: <→ compliance-control-foundation AI domain; crosswalk rows tagged with RMF function>
Companion: iso-42001-aims-architect (certifiable wrapper) — this program is NOT a certification
Unmeasurable/open risks: <named honestly>
```

## Validation Checklist

- [ ] GOVERN is designed as cross-cutting — its items appear inside MAP/
      MEASURE/MANAGE practices, not as a one-time section.
- [ ] Every function lands as concrete practices with named owners and
      lifecycle triggers — zero poster-level aspirations.
- [ ] Existing skills are composed by name (feature reviews, threat
      models, evals, incident machinery); nothing they own is restated.
- [ ] The AI risk register exists with per-risk measurement and treatment;
      acceptance decisions carry a named human.
- [ ] Decommission-stage practices are real (model retirement, data/memory
      disposition), not a placeholder.
- [ ] The program is labeled voluntary throughout; the current-version
      check of the RMF is recorded.
- [ ] Program controls registered in the foundation catalog with RMF
      function tags in the crosswalk.

## Compliance Precision Rules

- The NIST AI RMF is **voluntary** — released 2023-01-26; "The Core is
  composed of four functions: govern, map, measure, and manage," with
  GOVERN cross-cutting (verified on NIST and NIST AI Resource Center (AIRC) pages). It is a risk
  method, **not a certification target** — no org "passes" or "is
  certified against" the AI RMF, and this skill's outputs never imply it.
- NIST notes AI RMF 1.0 is **under revision** — record a current-version
  check date in every profile; category-level citations come from the
  text in hand, not memory.
- The Generative AI Profile is **NIST-AI-600-1 (2024-07-26)** — apply it
  when generative AI is in scope; it profiles the RMF, it does not
  replace it.
- The certifiable instrument is ISO/IEC 42001 (`iso-42001-aims-architect`)
  — pair them as method + management system; never present the RMF as the
  certificate.

## Gotchas

- Poster-ware is the RMF failure mode: four function names on a slide
  with no owners, triggers, or metrics. The test of every practice:
  who does it, when does it fire, what artifact does it leave.
- GOVERN-as-a-phase is a design smell — if governance items only appear
  at program setup, the "infused throughout" property is lost and drift
  is unmanaged.
- Per-feature reviews don't sum to a program: a folder of
  `ai-governance-risk-reviewer` reports without a register, thresholds,
  and lifecycle triggers is MAP without MEASURE/MANAGE.
- Decommission is the forgotten stage: retired models with live memory
  stores, orphaned agent credentials, and dependent systems silently
  breaking — plan disposition like a real deliverable.
- MEASURE honesty: some AI risks (societal effects, long-horizon misuse)
  resist metrics — name them unmeasured with review dates rather than
  inventing vanity metrics.
- Framework churn: 1.0 is under revision; profiles citing subcategory
  IDs from memory will rot. Cite from text in hand and re-check the
  version at each program review.

## Stop Conditions

- No AI system inventory can be established and no program owner exists —
  stop; a risk program needs both a subject and an accountable human.
- The AI RMF text is not in hand AND category-level citation is required
  — deliver function-level design with a verification-items list; do not
  cite subcategories from memory.
- Asked to certify, attest, or score the org "against the RMF" as
  pass/fail — reframe: voluntary method, profile + register + readiness;
  certification questions route to `iso-42001-aims-architect` /
  `compliance-gap-auditor`.
- MAP surfaces a likely prohibited or severely harmful use — escalate to
  the named accountable human and legal review (the
  `ai-governance-risk-reviewer` unacceptable-tier path); do not design
  around it.
- The task is one feature's review, one threat model, or running evals —
  hand to the owning skill and stop.

## Supporting Files

- [references/ai-rmf-function-map.md](references/ai-rmf-function-map.md)
  — the function × lifecycle-stage practice matrix, owning-skill map,
  register row shape, and the trigger table.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the compliance
  cluster and against `ai-governance-risk-reviewer`,
  `iso-42001-aims-architect`, `ai-threat-modeler`, and
  `ai-evaluation-harness`.