AI Governance for Risk Managers: Turn Risk Appetite Into Runtime Decisions

A risk appetite statement becomes operational when it can decide a specific request. "Customer PII stays inside approved systems" has to resolve a concrete event: an authenticated claims analyst sends a prompt containing a policyholder number to an external model at 10:14 a.m. The risk manager owns the tolerance and the escalation path. The production control has to turn both into a permit or deny decision, with redaction when policy requires it, that can be reviewed later.

I think a risk register without a link to production evidence is a beautifully formatted list of intentions. The hard work begins when a red cell in a spreadsheet has to govern an HTTP request.

TL;DR

• Risk managers should convert AI risk appetite into testable rules with named owners and thresholds. The rules also need exceptions and evidence requirements.
• Each material AI use case needs a traceable link between its risk-register entry and the policy applied to production requests.
• Runtime records should show identity and data classification. They should also preserve the model route, policy version, outcome, and exception state.
• Governance works when those records drive monitoring and escalation, rather than waiting for the next quarterly review.

The risk manager owns the translation layer

The NIST AI Risk Management Framework organizes AI risk work around four functions: GOVERN and MAP, followed by MEASURE and MANAGE. NIST describes the framework as voluntary and designed to incorporate trustworthiness into AI system design and development, plus use and evaluation. For a risk manager, the sequence is practical. GOVERN sets accountability and tolerance. MAP establishes the use context. MEASURE produces evidence about behavior. MANAGE turns that evidence into treatment decisions.

The role should require a business owner and an intended use before an AI use case enters production. It should also require prohibited data classes and approved model routes. An exception authority is required too. Those fields connect the AI risk register to an enforceable policy. A generic "high" rating cannot make a decision. A rule stating that payroll records may reach only an enterprise-hosted model through the HR route can.

The concrete artifact is a one-page control record attached to the register entry. If that page takes a 47-slide steering deck to explain, the rule is still too vague for production.

Risk appetite needs observable thresholds

NIST AI 100-1 states in GOVERN 1.3 and GOVERN 1.4 that organizations should determine the needed level of risk management based on risk tolerance and establish the process through transparent policies and controls. A risk manager can turn that language into observable conditions.

A data-exposure threshold may be zero permitted requests containing a restricted data class on a public-model route. An approved internal assistant may allow confidential material while blocking regulated identifiers. Each exception needs an owner and expiry timestamp, plus a business reason and compensating control before activation.

Measure denied requests by data class and redactions by business unit, then track attempted use of unapproved models and active exceptions approaching expiry. A separate metric should identify requests that arrived without sufficient identity context. AI governance metrics and KPIs should describe control operation, rather than count policy documents or training completions.

My preference is blunt: a metric that cannot trigger a treatment decision belongs in an appendix, not the risk dashboard.

Evidence connects treatment to each request

A reviewable event needs enough context to answer the risk manager's questions without reconstructing the decision from three systems. The record should contain the authenticated actor and business role. It should also contain the application route and model destination. The record should identify the prompt classification and governing policy version. It should preserve the decision outcome and timestamp, plus any exception identifier.

That structure matters because risk treatment changes. A prompt permitted under policy version 12 on September 18 may be denied under version 13 after a vendor assessment changes. The evidence has to preserve the policy active at the decision moment. AI operational governance covers this day-two loop, including policy versions and exception expiry.

NIST places production monitoring in MEASURE 2.4 and response to newly identified risk in MANAGE 2.3. Monitoring may surface repeated attempts to send source code to an unapproved endpoint. The risk manager evaluates that signal, selects a treatment, and records the decision. Policy then changes at the request boundary, with subsequent records proving the new treatment took effect.

Escalation should preserve decision rights

Escalation starts with named authority. A security analyst can identify the event, while the model owner can explain the workflow. Legal can assess a contractual restriction, and the risk manager decides whether the residual exposure fits the approved tolerance. Decisions above that limit go to the accountable executive or committee.

The AI governance operating model should specify this path before an incident. It needs response times and evidence packages. It also needs emergency suspension authority and reinstatement conditions. NIST GOVERN 2.3 assigns executive leadership responsibility for decisions about risks associated with AI development and deployment. That responsibility works only when the executive receives a bounded decision with facts, rather than a folder of logs.

A useful escalation packet contains the affected use case and the identities and routes involved. It states the volume and classification of blocked or permitted requests, along with the active policy version. It also includes exception history and proposed treatment. The decision deadline belongs in the packet too. The risk manager should be able to place the packet on a conference-room table and point to the exact request that crossed tolerance.

DeepInspect

DeepInspect sits on deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. It evaluates identity and role, along with data classification and model destination. It applies policy before the request reaches the model, then writes a signed, tamper-evident per-decision record outside the calling application's write path.

For a risk manager, that record connects the register entry to production behavior. It shows which policy governed the request and what decision occurred. It also identifies which exception applied. The scope stays precise: applications supply trustworthy identity context, and DeepInspect enforces policy on the AI HTTP route. Book a technical deep dive at deepinspect.ai.