From Risk to Control
Risk management often fails at the point where analysis should become action. A team may identify a concern, assign it a rating, and record it in a register without changing the system or process that created the concern.
AI governance needs a stronger connection. A risk should lead to a decision to:
- reduce the risk;
- avoid the risk;
- transfer the risk;
- accept the risk; or
- gather more information before deciding.
When the organization decides to reduce the risk, that decision should become one or more controls that can be implemented and monitored.
This chain is useful because each step answers a different question. The risk explains what could go wrong. The decision explains what the organization intends to do about it. The control describes the safeguard. Evidence shows whether the safeguard was implemented. Testing evaluates whether the evidence supports the claim.
What Makes a Control Useful
A useful control is specific enough that someone can understand what should happen and determine whether it happened. Statements such as “AI risks are reviewed” or “appropriate security controls are implemented” may express an expectation, but they do not tell an operator or auditor enough to test performance.
Stronger controls usually identify the trigger, responsible role, required action, expected output, and timing. For example, an organization might require a documented review before a new AI system processes production personal information, with approval recorded by specified reviewers before launch.
| Weak Statement | More Testable Control | Possible Evidence |
|---|---|---|
| AI systems are reviewed. | New production AI systems require documented governance review before approval. | Review record, approval, system inventory entry. |
| Vendors are assessed. | AI vendors are reviewed against defined security, privacy, data-use, and contractual criteria before onboarding. | Vendor assessment, contract, security documentation, approval. |
| Models are monitored. | Specified performance and risk indicators are reviewed at a defined cadence and after material changes. | Monitoring logs, review records, thresholds, issue tickets. |
Evidence Quality Matters
Not all evidence provides the same level of confidence. A policy shows what an organization intends to require. A completed record may show that the process was performed. Technical evidence may show what the system actually did. Each can be useful, but they answer different questions.
For example, a policy requiring human review does not prove that a particular decision received human review. A workflow record may provide stronger evidence. System logs or decision records may strengthen the conclusion further if they show when the review occurred and who performed it.
This is one reason AuditDIFF focuses heavily on evidence. Strong assurance depends on evidence that is relevant to the criterion, sufficiently reliable, and connected to the activity being tested.
| Evidence Type | What It Commonly Demonstrates | Typical Limitation |
|---|---|---|
| Policy or procedure | Documented expectation or process design. | Does not prove implementation. |
| Completed record | A review, approval, assessment, or workflow occurred. | May not prove accuracy or completeness. |
| System configuration | A technical safeguard is configured. | May not prove it operated throughout the period. |
| Logs or monitoring output | Operational events or ongoing control activity. | Requires context, completeness, and retention. |
| Independent test | Direct evaluation of an implementation or outcome. | Results depend on scope, method, and sample. |
Traceability Connects the Story
A mature governance system makes it possible to follow a path from a requirement or identified risk to the control intended to address it, then to evidence and testing. This is traceability.
Traceability reduces confusion during implementation and audit. An engineer can see why a safeguard exists. A control owner can see what evidence should be retained. An auditor can see which evidence supports which criterion. A remediation owner can see which gap must be closed.
It also makes change easier to manage. If a regulation changes or a new risk appears, the organization can identify which controls, systems, owners, and evidence sources may be affected.
Managing and Monitoring Controls
AI systems change. Models are updated, vendors change features, data sources evolve, prompts and workflows are modified, and organizations discover new failure modes. A control that was appropriate at launch may not remain sufficient.
Governance should therefore identify what changes require reassessment, what signals need ongoing monitoring, and who decides whether an issue requires remediation or escalation. Evidence should be retained in a way that preserves enough history to understand what changed and when.
Part 4 examines what happens when someone independent of the implementation evaluates this evidence. That is where readiness work becomes assurance.