An AI Risk Disposition that holds up in regulator review

The regulatory context is converging on a common standard. EU AI Act Article 9 requires documented risk management for high-risk AI systems — not a description of the process, but evidence that the process has been executed. The FCA's AI guidelines require explainability of AI decisions, which in practice means being able to point to specific documentation that explains why a system was approved and under what conditions. ISO 42001 requires evidence of control implementation, not control planning.

The common thread is this: regulators do not want to see that you thought about risk. They want to see:

• What specific risks you identified — not categories, but named risks with IDs.
• What you decided to do about them — not intentions, but decisions with rationale.
• Who is accountable — not a team or a process, but a named role that can be called into a review.
• How you will know if things change — specific triggers, not general commitments to ongoing governance.

A disposition that passes this test has six specific properties — one per section. A disposition that does not can describe pages of risk analysis and still fail, because the analysis is there but the four elements above are missing or implied rather than explicit.

The difference between a governance artefact and a defensible position is not volume. It is whether the document answers the four questions a regulator will ask on day one.

The decision must be explicit and categorical. Not “we're comfortable moving forward” — an actual named verdict from a defined set of options. The standard verdicts are: Proceed (unconditionally approved for the stated scope), Conditional (approved subject to specific controls being in place), Restricted pilot only (limited deployment pending further evidence), Hold (not approved until named blockers are resolved), or Decline (not approved). If the decision language cannot be mapped to one of these, it is not a decision — it is a sentiment.

The rationale must explain why, not what. A common failure is a rationale that restates the decision: “The system has been reviewed and approved following a thorough assessment.” This tells a regulator nothing. A defensible rationale explains the reasoning: what risk factors drove the decision, what mitigating factors enabled approval rather than hold, and what specific limitations are acknowledged in the scope of the decision.

The decision section is also where the scope boundary belongs. An AI Committee approving a system for one use case needs that use case named explicitly — not implied by the system description. Scope creep is the most common governance failure mode for AI systems, and it almost always starts with an approval that never specified what it was approving.

Every control in a disposition must have six fields: an ID, a title, an owner role, a deadline, a lifecycle gate, and a verification method. The absence of any one of these fields makes the control unenforceable. A regulator reviewing a disposition for a high-risk AI system will check each control against exactly these fields.

The owner must be a role, not a person's name. Roles persist when people leave. A control owned by “Jane Smith” becomes ownerless the moment Jane leaves the organisation — and in a multi-year production deployment, that is a near certainty. A control owned by “Data Governance Lead” always has an owner, even through personnel changes.

The lifecycle gate is the field most commonly omitted. It specifies when the control must be in place — not when it is planned, but when its absence blocks the system from proceeding. There are three standard gates:

• before_pilot — the control must be in place before any pilot deployment. Absence of a before_pilot control is a blocker for the restricted pilot verdict.
• before_production — the control must be in place before the system moves from pilot to production. Conditional verdicts typically list their conditions as before_production controls.
• ongoing — the control is a continuous governance requirement. Absence does not block a specific gate but is a compliance failure if not maintained.

The verification method is evidence of what “this control is done” looks like. Without it, a control can never be marked complete — there is no agreed standard for what completion means. “Reviewed by CISO” is a verification method. “Implemented” is not.

Evidence state is how honest the disposition is about what you actually know versus what you are assuming. It is the section most often omitted from governance documents — and its absence is itself a red flag, because it usually means the document is treating all controls as implemented when they have not been tested.

There are six evidence states, and each has a distinct meaning in a regulatory context:

A disposition with “Assumed” on a critical control is not failing review — it is being honest. A disposition with everything marked “Explicit” when the controls have not been tested is a compliance risk. Regulators can distinguish between the two, and the latter is significantly worse than the former.

Evidence state also serves as a working instrument during the review cycle. Controls that start at Assumed or Missing evidence have a documented path to Explicit — with an owner and a deadline. The disposition becomes a live governance document rather than a point-in-time artefact.

Residual risks are the things that remain even after controls are implemented. Every AI system has them — the question is whether the organisation has named them, assigned an accountable owner, and documented the conditions under which they are accepted.

Each residual risk entry needs five fields: an ID, a description, an acceptance owner (the named role accountable for this risk), an acceptance condition (the specific circumstances under which this risk is accepted), and the current evidence state. The acceptance condition is particularly important: it defines the boundaries within which the risk is tolerated and, by implication, the boundaries outside which it is not.

Consider a concrete example for a document processing AI system:

The acceptance owner is the person who can be called into a regulator review and asked: “Did you knowingly accept this risk, and under what conditions?” If the answer is “I didn't know about it” or “I don't know what the conditions were”, the disposition failed — regardless of what is written in the document. The sign-off trail (section 6) is what creates the evidence that the acceptance owner did, in fact, review and accept the risk.

A disposition without re-assessment triggers is a point-in-time document. It describes the system as it was at the time of review. Regulators and AI Committees want to know: under what circumstances will this be revisited? Without that answer, a disposition approved for one system configuration is implicitly treated as valid for every future configuration — which is rarely the intent and rarely defensible.

Required triggers for most AI systems cover five categories of change:

• Model change — a new version of the underlying model is deployed. Model updates change capability boundaries, alignment properties, and failure modes. A disposition reviewed against model version 1.0 is not automatically valid for version 2.0.
• Tool or integration added — a new tool, API, or data integration is connected to the system. Each addition expands the attack surface and may introduce new risk categories not covered by the original assessment.
• Data source change— new data sources enter the context window or training pipeline. Data source changes affect the system's knowledge boundary and may introduce new privacy or bias risks.
• Autonomy increase — the system is granted more autonomous operation. A system that moved from advisory-only to taking actions directly needs a fresh assessment of its risk profile.
• User group expansion — the system is deployed to a broader user population. Expansion to more sensitive populations (employees with access to confidential data, external customers, regulated users) changes the risk profile materially.

Each trigger should specify a type and the condition that activates it. A concrete example:

The trigger section also prevents one of the most common governance failures for AI systems: the invisible scope expansion. When new capabilities are added incrementally — a new tool here, a broader user group there — no single change looks significant enough to trigger a review. The triggers section makes the threshold explicit, so the decision to review (or not review) is a conscious one rather than a series of silent assumptions.

The sign-off section is evidence that accountable parties reviewed and accepted the disposition. Without it, a disposition is a document that was written — not one that was reviewed, challenged, and approved. The distinction matters in a regulatory context because the sign-off trail is what creates accountability.

Each sign-off entry needs four fields: a role (not a person's name), a status, an optional comment, and a timestamp. The five standard statuses are:

• Pending — the reviewer has been notified but has not yet responded. A disposition with Pending sign-offs is in progress, not complete.
• Approved — the reviewer has reviewed and accepted the disposition in its current form.
• Requires changes — the reviewer has identified specific changes required before they will approve. This is not a failure; it is the governance process working correctly.
• Declined — the reviewer has declined to approve. This blocks the disposition and requires resolution at the decision level.
• Review requested — the reviewer has flagged items for discussion before making a determination.

Required sign-off roles for most AI systems: CISO (security clearance), DPO if personal data is processed (data protection review), and Business Owner (commercial and operational accountability). For high-risk AI systems under the EU AI Act, additional sign-offs may be required depending on the deployment context.

The sign-off trail also creates a historical record. When a system is reviewed three years after initial deployment — whether by a regulator, an auditor, or a new governance team — the trail shows who approved what, when, and whether any reviewer raised concerns that were overridden. A disposition with a clean sign-off trail tells a very different story from one with multiple “Requires changes” entries that were closed without documented resolution.

Before submitting a disposition to an AI Committee or regulatory body, apply this test. Read the document and answer five questions:

1. Is the decision explicit and categorically named?Not “we are comfortable proceeding” — a named verdict (Proceed, Conditional, Restricted pilot, Hold, or Decline) with scope boundary stated.
2. Does every required control have an owner, a deadline, and a verification method? Not a description of what will be done — a role that will do it, a date by which it must be done, and a test that confirms it has been done.
3. Is the evidence state honest?Do “Assumed” items genuinely reflect unverified controls? Is there any control marked “Explicit” that has not in fact been tested?
4. Does every residual risk have a named role who accepted it and the conditions under which they did? If a risk has no acceptance owner, the organisation has not accepted it — it has ignored it.
5. Are there triggers that would invalidate this disposition if the system changes? Not a general commitment to ongoing review — specific named conditions that, when met, require a fresh assessment.

If any answer to the five questions is “no”, the document is a governance artefact — it satisfies the requirement to have a document, but it does not create a defensible position. The distinction matters when someone who was not in the room asks “why did you approve this?” A governance artefact produces an uncomfortable silence. A defensible disposition produces an answer.

A Risk Disposition written to this standard is not written to satisfy a review process. It is written to withstand one. The difference is rarely in effort — it is in whether the author asked “would I be comfortable defending this?” before the review rather than during it.

Most governance documents are written to satisfy a review process. The process asks for a risk document; the team produces a risk document; the committee approves it because it exists. A Risk Disposition written to the standard above is written for a different audience: the regulator, auditor, or governance lead who will ask the hard questions — possibly years after the initial approval. The six sections are the answer to those questions, written before the questions are asked.

The foundational piece on what an AI Risk Disposition contains covers the structure in detail. The worked example for a Copilot Studio procurement agent shows every section filled in with real content for a specific assessed system. This piece is the test: once you have a disposition, this is how you know whether it will hold up.