AI Risk Management Playbook: A Working Guide

A working AI risk management playbook turns abstract governance principles into decisions your teams can make on a deadline.

Blake Aber · Predicate Ventures · 2026

Why a playbook, not a policy

Most organizations already have an AI policy. Few have a playbook.

A policy states intent. A playbook states procedure: who decides, on what evidence, by when, and what happens when the answer is no.

The gap matters because AI risk does not announce itself. It surfaces at the moment a model is repurposed, a dataset shifts, or a vendor changes its terms. When those moments arrive, teams need a sequence to follow, not a statement of values to reread.

This playbook uses the four functions of the NIST AI Risk Management Framework as its spine. NIST released AI RMF 1.0 on January 26, 2023, and it has become the common reference for enterprise AI governance in the United States. The four functions—Govern, Map, Measure, Manage—give you named stages to assign owners and checkpoints.

Govern: set the standing rules before anyone builds

Governance is the layer that outlasts individual projects. It answers the questions you should not relitigate every time a new use case appears.

Start with three artifacts.

An inventory

You cannot manage what you have not counted. Maintain a live register of every AI system in use, including third-party tools and features embedded in software you already license. Each entry records the owner, the purpose, the data it touches, and its risk tier.

A risk tiering rule

Not every model deserves the same scrutiny. Define tiers by potential harm—effect on people, on legal exposure, on revenue. A copywriting assistant and a credit-decision model belong in different tiers with different approval paths.

A decision authority

Name who can approve deployment at each tier. Low-tier tools may clear at the team level. High-tier systems require sign-off from a named committee with legal, security, and business representation.

Governance also sets escalation. When a model behaves outside expected bounds, who is paged, and who can pull it from production? Write that down before you need it.

Map: understand the system in its context

Mapping is the diligence stage. Before measurement, you establish what the system is supposed to do and where it can go wrong.

Document the intended use in plain language, then document the foreseeable misuses. A model built to summarize support tickets can be fed adversarial input or asked questions it was never validated for. Naming those paths early tells your testers what to probe.

Map the data lineage. Where does training and input data originate, who owns it, and what constraints attach to it? Data provenance is where many compliance failures begin.

Map dependencies. If your system relies on a third-party foundation model, its behavior can change without your involvement. Record which external components you depend on and what you would do if one degraded or disappeared.

Generative systems carry a distinct set of concerns—hallucination, data leakage, prompt injection, and content provenance among them. NIST addressed these directly in NIST-AI-600-1, the Generative AI Profile released July 26, 2024. Use it as a checklist when the system in question generates text, images, code, or audio.

Measure: test against defined thresholds

Measurement converts concern into evidence. The goal is to replace opinions about a model's safety with results.

Set thresholds before testing. Decide in advance what accuracy, bias, and reliability numbers you will accept. Thresholds set after seeing results tend to bend toward the result you want.

Measure across several dimensions.

Performance: Does the system meet its stated task quality on representative data?
Fairness: Do outcomes differ across groups in ways you cannot justify?
Reliability: Does performance hold when inputs drift from the test set?
Security: Can the system be manipulated through its inputs?

Measurement is not a launch-day event. Models degrade as the world moves away from their training data. Schedule re-measurement at intervals tied to risk tier, and trigger it whenever inputs or dependencies change materially.

Record the results where an auditor could find them. If you cannot show your work later, you did not measure—you guessed.

Manage: act on what you learned

Management is where the playbook earns its name. Measurement produces findings; management assigns responses.

For each identified risk, choose one of four responses and document it: accept, mitigate, transfer, or avoid. Accepting a risk is legitimate—if it is a decision, made by someone with authority, and recorded.

Mitigation is the common path. It includes technical controls such as input filtering and output review, and process controls such as human sign-off for high-stakes decisions. Match the control to the harm you mapped.

Build monitoring into production, not around it. The system should report on its own behavior—drift, error rates, unusual inputs—so problems surface in dashboards rather than in complaints.

Keep a response plan for failures. When a model produces harmful output, the sequence should be known: contain, assess, notify, remediate, record. Rehearsed response separates an incident from a crisis.

Making the playbook durable

The framework underneath this playbook is not static. NIST plans to review the AI RMF with formal community input no later than 2028, and the technology will move faster than that. Treat your playbook as a document that gets versioned, not one that gets finished.

Two practices keep it alive.

First, assign an owner. A playbook without an owner drifts into obsolescence within a quarter. Someone should be accountable for updating it as tools, regulations, and incidents accumulate.

Second, run it on real cases. A playbook that has never been used against a live deployment is theory. The first few times you apply it, you will find gaps—steps that are unclear, owners who were never told, thresholds nobody agreed to. Fix them while the stakes are low.

The organizations that handle AI risk well are rarely the ones with the longest policy documents. They are the ones whose teams know what to do when a model does something unexpected—and can show why they made the call they did.