Key Takeaway
In regulated settings, an AI system has to be observable before it's allowed to be autonomous. Record what it accessed, decided, changed and escalated for every decision, then use that record to move it up one rung of autonomy at a time.
In regulated industries, AI automation only goes as far as you can prove control. This article is for product, engineering and risk leaders at banks, insurers and the vendors who sell to them. It covers what a per-decision evidence record should contain, how to use it to earn autonomy step by step, and a scorecard for checking one workflow.
Picture the request from internal audit. Pick any Tuesday last quarter, any customer. Show us what your AI system did for that customer: what data it looked at, what it concluded, what it changed, and whether a person had the chance to stop it.
Most teams running AI in production could show that the system was up. Many could show latency, error rates and token costs. Far fewer could answer the auditor’s question for a single case, quickly and with confidence.
That gap decides how far automation goes in regulated businesses. Leaders want AI to take on more decisions. Their risk functions want proof of control. When the proof doesn’t exist, the system stays in “recommend only” mode forever, and the business case built on automation never pays out.
Our view: in regulated settings, a system has to be observable before it’s allowed to be autonomous. Observability here means something narrower than engineering dashboards. It means evidence, recorded per decision, that a risk leader or auditor can read.
What’s the difference between operational and evidence observability?
Operational observability tells engineers whether the system is working. Evidence observability tells risk and audit what it did for one customer, why, and who could have stepped in. Regulated automation needs both.
We’ve written about AI agent observability from the engineering side: tracing tool calls, catching hallucination drift and tool-call loops, alerting before users notice. That work keeps the system healthy. The second layer answers a different question, for a different audience, at a different unit of analysis.
| Operational observability | Evidence observability | |
|---|---|---|
| Audience | Engineers, on-call | Risk, compliance, audit, regulators |
| Unit | Requests, spans, metrics | Individual decisions about a customer, account or case |
| Question | Is it healthy and performing? | What did it do, why, and who could intervene? |
| Retention | Days to weeks for full traces | As long as your record-keeping obligations require |
| Failure looks like | Latency spike, error rate, drift | A decision you can’t reconstruct or explain |
The two share plumbing. The trace data you already collect is the raw material. What’s usually missing is the structure that turns traces into a decision record someone outside engineering can read.
Why does OSFI Guideline E-23 matter for AI in Canadian financial services?
Because it brings AI and machine learning systems clearly into the scope of model risk management at federally regulated financial institutions, and it takes effect on May 1, 2027. OSFI (the Office of the Superintendent of Financial Institutions) published the final version of Guideline E-23 on Model Risk Management in September 2025. It applies to federally regulated institutions, including banks and insurers.
Commentary on the final guideline points to a broad definition of “model” and to expectations around governance, lifecycle controls, monitoring and third-party oversight. This isn’t legal guidance, and each institution will read the guideline with its own model risk team. The practical takeaway is still clear: AI systems that make or shape decisions at a federally regulated institution will need lifecycle evidence. Building that evidence after the fact is much harder than recording it from day one. Systems being designed now will be running when the guideline applies.
The same logic holds outside banking. Insurers, payment companies, security vendors and anyone selling AI into those customers will get the same question from their customers’ risk teams.
What should an AI decision record contain?
It should answer four questions on its own, without anyone asking an engineer: what the system accessed, what it decided, what it changed and what it escalated.
What did it access? The data sources the system read for this case, with versions or timestamps. Which customer records, which documents, which external lookups. If retrieval was involved, which passages it used.
What did it decide? The output, the reason in plain language, the confidence or score where one exists, and the exact versions of the model, prompt and business rules in effect at that moment.
What did it change? Every action with a side effect: records updated, messages sent, cases closed, payments queued. Ideally with before and after values, so the change is visible rather than implied.
What did it escalate? Whether the case went to a person, why, who handled it and what they did. Just as important: when the system did not escalate, which threshold or rule let it proceed alone.
Most systems answer that fourth question badly. Escalations get logged because a person touched them. The decisions that passed straight through, which are the ones an auditor cares about most, often leave nothing behind but a status change.
What does a decision record look like in practice?
Here’s a mock-up of a single record for a fraud alert. The fields matter more than the format.
| Field | Example value (illustrative) |
|---|---|
| Decision ID | dec-2026-10-14-004812 |
| Case / subject | Fraud alert #A-55120, retail chequing account |
| Timestamp | 2026-10-14 09:42:17 ET |
| Accessed | Transaction history (90 days, as of 09:41), device fingerprint service, prior alerts on account (2), customer contact log |
| Model / prompt / rules | triage-model v3.4 · prompt tpl-fraud-17 · ruleset fr-2026-09 |
| Decision | Close as false positive |
| Reason | Merchant and amount match a recurring pattern over 14 months; device and location consistent with prior 30 days; no contact-log flags |
| Score | 0.94 (close threshold: 0.90) |
| Changed | Alert status: open → closed (FP); note appended to case |
| Escalated | No. Score above close threshold; account not on watch list; amount below review limit |
| Human review | Included in 5% QA sample: no |
| Reversible | Yes. Reopen within 30 days restores alert state |
A record like this does two jobs. It answers the auditor’s question in a minute. It also makes sample-based review possible, because a reviewer can check the reason against the sources without rebuilding the case.
How should a regulated AI system earn more autonomy?
One rung at a time, with evidence, decision type by decision type. Autonomy shouldn’t be a switch you flip at launch. A ladder makes the steps explicit.
| Rung | The system… | Evidence needed to move up |
|---|---|---|
| 0. Shadow | Runs alongside the human process and records what it would have done | Agreement rate with human decisions, by segment, over a defined period |
| 1. Recommend | Proposes; a person decides every case | Override rate and reasons stable; reviewers confirm reasons are accurate |
| 2. Act with approval | Prepares the action; a person approves before it executes | Approval rate high, overrides explained, no unexplained reversals |
| 3. Act with sampled review | Acts alone below thresholds; a person reviews a sample and all exceptions | Sample error rate within tolerance; escalation logic tested |
| 4. Autonomous within bounds | Acts alone inside defined limits; aggregate monitoring and periodic review | Sustained performance at rung 3; tested ability to pause and roll back |
Each move up is a documented decision with a named approver and the evidence attached. Each move down should be just as easy, and should trigger automatically when monitoring crosses a threshold. A system that can only move up is one your risk team will keep at rung 1.
The ladder also changes the conversation with the risk committee. Instead of asking it to approve “the AI,” the business asks it to approve one rung for one decision type, with the evidence for the next rung defined in advance.
How do you score an AI workflow’s observability and control?
Score each of the ten areas below 0 (absent), 1 (partial) or 2 (in place), for one automated workflow. It’s a starting point for a conversation with risk, not a regulatory standard.
| Area | What “in place” looks like | Score |
|---|---|---|
| Access record | Sources and versions recorded per decision | 0 / 1 / 2 |
| Decision record | Output, reason and model/prompt/rule versions per decision | 0 / 1 / 2 |
| Change record | Before and after values for every side effect | 0 / 1 / 2 |
| Escalation record | Routed and non-routed cases both explained | 0 / 1 / 2 |
| Reconstruction | Any single decision retrievable by a non-engineer in minutes | 0 / 1 / 2 |
| Human review | Sampling and exception review defined, staffed and logged | 0 / 1 / 2 |
| Thresholds | Written down, owned by the business, change history kept | 0 / 1 / 2 |
| Pause and rollback | Tested for each decision type | 0 / 1 / 2 |
| Integrity | Records can’t be altered by the system that produced them | 0 / 1 / 2 |
| Retention | Aligned with your record-keeping obligations | 0 / 1 / 2 |
A workflow scoring under 10 isn’t ready to move above rung 1. Between 10 and 16, the gaps are usually specific and fixable. At 17 or more, the conversation with risk can turn to which rung comes next.
What does this look like for fraud alert triage?
This is an illustrative example, not a client case.
A mid-sized bank’s fraud team handles thousands of transaction alerts a week, most of them false positives. The business wants AI to close the obvious ones so analysts can focus on real fraud.
What blocked it. The pilot closed alerts accurately in testing, but a closed alert left only a status change in the case system. Model risk asked how the team would show, for any closed alert, what the system looked at and why it didn’t escalate. Nobody had an answer that didn’t involve an engineer reading raw logs.
What changed.
- Every decision wrote a record like the mock-up above, into a store the triage system could append to but not edit.
- The system started at rung 0, shadowing analysts for a defined period, then moved to rung 1.
- Once the override record supported it, closures below a value limit moved to rung 3: automatic, with a 5% QA sample and every exception reviewed.
- Each alert type got a pause switch, owned by the fraud operations lead and tested monthly.
The model was the easy part. What got it approved was the record, the ladder and the integration with the case system analysts already used.
For the business owner’s side of this conversation, measuring AI feature success covers which metrics to tie to each rung. The baseline for logging and model versioning is in our AI governance guide for product teams.
Who builds evidence observability?
Usually nobody, because it sits between teams. Engineering owns the traces. Risk owns the requirements. Operations owns the review process. Nobody owns the decision record that connects them, so it tends not to exist.
Our engineers embed with client teams to build governed AI workflows with that record designed in. It’s integrated with your case and core systems, structured for human review, and lives in your codebase on your release cycle. Your team keeps the system and the pattern.
Frequently Asked Questions
Does OSFI Guideline E-23 apply to AI models?
Commentary on the final guideline highlights a broad definition of “model” that brings AI and machine learning systems clearly into scope at federally regulated financial institutions. It takes effect May 1, 2027. Confirm how it applies to your institution with your model risk, compliance or legal advisors.
What’s the difference between AI observability and AI auditability?
Observability in the engineering sense tracks whether the system is healthy: latency, errors, drift. Auditability needs a per-decision record that a non-engineer can read, showing what the system accessed, decided, changed and escalated.
How long does it take to move an AI system from recommend to autonomous?
There’s no fixed timeline. Each rung needs its own evidence, such as stable override rates or a sample error rate within tolerance, and each decision type moves on its own schedule.
Which automated decision should you review first?
Pick one decision your organization automates today, or wants to. Map the evidence and control it needs: what it accesses, what it decides, what it changes and what it escalates. Then score it.
We run observability and control reviews on a single workflow. We work through the four questions and the scorecard with your team, and you leave with an audit mock-up for that workflow and the gaps to close before it moves up a rung. Book a review.
This article is general information, not legal or regulatory advice. Confirm how OSFI Guideline E-23 or other requirements apply to your institution with your model risk, compliance or legal advisors.