What makes an AI decision record defensible
A defensible AI decision record is one that a regulator, auditor, or procurement officer can read — without access to the people who made the decision — and understand what was decided, why, and what commitments were made. This piece defines the standard.
When a regulator, auditor, or procurement officer examines an AI decision record, they approach it as a stranger. They were not in the room when the decision was made. They do not know the system, the team, or the context. They have an interest in finding gaps — and they will look hard. A defensible decision record is one that holds up under that examination.
Most AI decision records do not hold up. Not because the decisions were wrong — many were made by thoughtful people who considered the relevant factors. They fail because they were written for the people who made them, not for the stranger who will review them later. They assume context that is not in the record. They describe what was intended rather than what is in place. They reference evidence that does not exist or cannot be located.
The standard for a defensible record is: a stranger who reads it, with no access to the people who made the decision, should be able to understand what was decided, why, and what commitments were made.
What defensible means
Defensible does not mean perfect. It does not mean that every risk was identified or that every control was in place. It means that the decision was made through a defined process, with appropriate evidence, by people with the authority to make it, and that the record accurately reflects what happened.
A defensible record can show that a system was deployed with identified residual risk — and that the residual risk was accepted by a named person with authority to do so, under specific conditions, with a defined process for reassessment. That is a defensible record, even if the risks were significant.
An indefensible record is one where the decision cannot be traced to evidence, where the authority of the decision-maker cannot be confirmed, where the conditions are so vague as to be meaningless, or where the record describes intent rather than fact.
Six properties that make an AI decision record defensible
The three tests
A defensible AI decision record passes three tests:
The clarity test:Can a person with no context understand what was decided and why? This tests the record's readability and self-sufficiency. A record that requires knowledge of internal systems, internal terminology, or the history of the review process to understand fails the clarity test.
The completeness test: Are all required elements present? The completeness test is a checklist: decision, scope, rationale, controls, residual risk, named acceptor, conditions, triggers. A record missing any required element fails the completeness test regardless of how well the present elements are written.
The traceability test:Can every claim in the record be traced to documented evidence? When the record says “access controls are in place,” there must be a referenced artefact that confirms this. When the record says “the threat model was completed,” the threat model must be accessible and current.
Content requirements
A complete AI decision record must contain the following elements:
- System identification: The specific AI system, its version or state at assessment time, and the deployment scope to which the record applies.
- Decision: The specific disposition — full approval, conditional approval, restricted pilot, or rejection — and the date.
- Decision authority: Who made the decision, in what role, under what charter or delegated authority.
- Rationale: Why this disposition was chosen over alternatives — what the evidence showed and how it supports the decision.
- Controls summary: The controls in place and a reference to the verification evidence for each.
- Residual risk: The risk that remains after controls, stated specifically, not categorically.
- Named acceptor: Who accepted the residual risk, in what role, under what conditions.
- Conditions: Any conditions on the approval, each with owner, deadline, and verification method.
- Re-assessment triggers: The standard and system-specific triggers that require reassessment.
- Evidence references: References to each supporting artefact, with location and version.
The clarity test
The clarity test is best applied by giving the record to someone who was not involved in the review and asking them three questions: What was decided? Why was this decision made rather than a different one? What are the conditions and commitments? If they cannot answer these questions from the record alone, the record fails the clarity test.
Common clarity failures: use of internal abbreviations or project names without explanation; references to “the previous review” without identifying what that review found; conclusions without stated rationale (“risk is acceptable” without explaining why); and conditions described in terms that only make sense to someone who attended the committee meeting.
The completeness test
The completeness test can be applied mechanically: check each required element against the checklist. For each element, the question is binary: is it present or absent? An element that is present but inadequate is an element that fails the clarity or traceability test, not the completeness test. The completeness test only asks: is it there?
Completeness is a floor, not a ceiling. A complete record is the minimum standard. Completeness does not tell you whether the decision was sound — only whether the record can be evaluated. A complete record that fails the clarity or traceability test is still an indefensible record.
The traceability test
The traceability test requires that every factual claim in the decision record is backed by a referenced artefact that confirms it. The test has three steps:
- Identify every factual claim in the record — not opinions or rationale, but claims about what is in place, what was done, or what was found.
- For each claim, check whether there is a referenced artefact that confirms it.
- For each referenced artefact, confirm that the artefact exists, is accessible, and contains the evidence the claim attributes to it.
A traceability test run on a typical AI decision record surfaces two categories of failures: claims without references, and references to artefacts that cannot be found or that do not contain the claimed evidence. Both represent evidence gaps that undermine the record's defensibility.
Common failures
The most common failures that make AI decision records indefensible:
- Records that describe intent rather than fact.“Access controls will be implemented” rather than “access controls are in place as of [date], confirmed by [named reviewer], see [artefact reference].”
- Records that reference evidence that does not exist. A control plan that references a penetration test report that was planned but not conducted. A DPO advisory that is referenced but was never issued. Evidence gaps that the record treats as if they were filled.
- Records with unsigned or unconfirmed sign-off. A named acceptor listed in the record who has no record of confirming the acceptance — whether by signature, email confirmation, or digital approval workflow. The acceptance must be active, not attributed.
- Records with conditions that cannot be evaluated. Conditions so broadly written that no one can determine whether they are met. This is a clarity failure and a completeness failure simultaneously.
The standard
The standard for a defensible AI decision record is practical, not aspirational. It requires that the record be self-sufficient for a stranger, complete in its required elements, and traceable to documented evidence. This standard is achievable with the right process — it does not require more work, it requires work in the right direction.
The test to apply before submitting a decision record to the governance committee: hand it to someone who was not involved in the review and ask them to tell you what the system is, what was decided, why, and what the conditions are. If they cannot, the record needs work before it goes to the committee.
For the evidence pack that supplies the record's supporting artefacts, see The anatomy of an AI evidence pack.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Produce decision records that hold up
Drel produces AI decision records that pass the clarity, completeness, and traceability tests — structured for the stranger who will review them, not just the team that made them.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.