Five decisions, not two: how an assessment should end

An AI risk assessment should end with a decision that the accountable owner can act on. The report needs to explain the intended use, the evidence reviewed, the residual risk and any conditions that must be met. A simple approval label can leave those distinctions unclear.

A binary approval process can make conditional acceptance difficult to express. A team may be able to proceed with a narrower scope or verified controls, even when unrestricted release is not justified. Record that position explicitly so that an approval cannot be read more broadly than the evidence supports.

What the two-outcome model does to the work

When an assessment has only two labels, review whether its conditions remain enforceable. Planned controls should not be described as operating controls. Residual risk should have an accountable owner, and unresolved questions should remain visible. These are process design risks to examine, rather than evidence that every binary assessment is unreliable.

A decision framework should preserve these distinctions in both the conclusion and the action record. It should show what has been accepted, what must change and which person has authority to decide again.

This is an unfashionable idea rather than a novel one. The NIST AI Risk Management Framework organises the work as govern, map, measure and manage — four continuing functions rather than a checkpoint — and is explicit that deciding what level of risk is acceptable is an organisational judgement rather than an output of the assessment. A framework built that way does not produce a verdict. It produces a position, and a position has somebody holding it.

The five outcomes

The Institute’s assessment method uses five recorded positions. Each should be supported by the evidence, the intended-use boundary and the organisation’s risk criteria. The labels help organise a decision but do not replace the judgement required to make it.

Proceed. The assessed use and residual risk are acceptable under the stated conditions. Record the scope, accountable owner and triggers for reassessment. Acceptance does not remove ongoing operating responsibilities.

Proceed with controls. Acceptance depends on named controls being implemented and verified. Identify the owners, evidence required and the gate that prevents operation before those conditions are satisfied. Distinguish pre-release conditions from actions that can legitimately follow release.

Redesign. The proposed architecture or operating arrangement does not meet the risk criteria. Identify the changes needed and the evidence a revised assessment will require. The objective may remain worthwhile while the present design needs to change.

Escalate. A specialist or legal review is required before the accountable owner can decide. State the unresolved question, the appropriate reviewer and the restriction that applies while the answer is pending.

Do not proceed. The assessed use cannot be supported at an acceptable level of risk, or an applicable prohibition prevents it. State the basis and avoid implying that additional documentation alone would change that conclusion.

Why “do not proceed” has to be on the list

The frequency of each outcome depends on the work assessed. No particular rejection rate proves the quality of a process. The important requirement is that reviewers have the authority to record an adverse conclusion when the evidence warrants it.

A record of approvals alone does not establish that the process is weak or that every system is safe. Examine the evidence, conditions and decisions themselves. Confirm that reviewers can decline a proposal and that commercial or scheduling pressure does not silently override unresolved risk.

Maintain the option to stop alongside options for controls and redesign. Make its consequences clear to delivery teams and decision owners before the assessment begins. This helps establish that the conclusion follows the evidence rather than a preselected launch decision.

Getting to a position somebody will sign

The five outcomes only work if the assessment underneath them can be defended. In practice that means walking the same chain every time, in the same order: context, people, data, model, decisions, controls, residual risk. Seven stages, and the order matters — starting at the model, which is where teams instinctively start, produces an assessment of a component rather than of a system doing something to somebody.

Two habits do most of the work:

Test controls rather than collecting claims. “Access is restricted” is a claim. Attempting the access and recording what happened is a test. Assessments built on claims fail at exactly the moment they are needed, which is after an incident, when somebody checks.

Write the residual position in the language of the person signing. An accountable executive is being asked to accept something. They cannot accept a paragraph about model drift. They can accept “if this fails, the realistic consequence is X, the control that catches it is Y, and Z owns it”.

The conditional signature is a real outcome

A conditional signature can be a useful outcome when its conditions are specific and enforceable. The record should identify the control, owner, verification evidence and decision date. It should also explain the residual risk the signatory accepts after the condition is met.

Use the recorded position to guide the next action and later review. A defensible assessment explains why the chosen use can proceed, what remains uncertain and which change would require a new decision. Its value comes from that connection between evidence and authority, rather than the number of labels available.