AI system managed without a documented AI-specific risk-management process

Keep an AI risk register that identifies, analyses, evaluates, treats, and monitors each AI system's risks through its life cycle, including after deployment.

A written AI risk methodology (AI-specific risk sources such as data drift, bias, misuse, opacity, and third-party model changes; likelihood and impact criteria; risk acceptance thresholds) folded into the organization's existing risk process, plus a per-system register entry with owner, analysis, evaluation against tolerance, chosen treatment, residual risk, and the monitoring signal that would show the risk changing. The system owner keeps it, with the risk function, and updates it at design review, before release, and when monitoring or incidents show a change. Link register entries to the evals and production monitors that implement each treatment.

Where it goes: 12 repository artifacts, 13 tests and evals, 10 logs and telemetry.

What reviewers look for: a methodology document and register entries with dated post-deployment monitoring records, not only design-time notes; each treatment traced to a control, eval, or dashboard that exists; no claim of 'ISO 23894 certification', since that guidance is not certifiable.

Organizational control: the evidence is a kept record, its owner and its upkeep, not code.

# risk-register.yaml
- system: loan-assistant
  risk: model might be biased

# risk-register.yaml
- system: loan-assistant
  id: R-07
  source: training data under-represents applicants over 65
  analysis: {likelihood: medium, impact: high}
  evaluation: above tolerance
  treatment: reweighting + subgroup error-rate eval (evals/subgroups.py)
  residual: low
  owner: credit-ml-lead
  monitoring: dashboard approval-rate-by-age, alert at >5 point gap
  last_reviewed: 2026-09-15

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.