Two things happened in 2026 that plenty of enterprise teams unfortunately read as breathing room. In April, US banking regulators replaced SR 11-7 and carved generative and agentic AI out of scope entirely. And in July, the EU pushed most high-risk obligations under the AI Act from August 2026 out to December 2027. Both got filed under "we have more time." But neither changed what an examiner asks you to produce once they're sitting at your table.
The deadlines moved. The evidence standard didn't.
That gap matters more than it sounds, because most organizations aren't close to meeting it. Grant Thornton surveyed roughly 950 senior US executives in early 2026 and found that 78% lacked strong confidence they could pass an independent AI governance audit within 90 days. Among companies still piloting, only 7% were very confident.
The problem isn't missing policy. It's that a policy isn't evidence, and evidence is the only thing an audit runs on. With that said, you need to know what AI auditability looks like in practice, notably what regulators actually ask for, and roughly in the order they ask for it. So let’s dig in.
What AI auditability means to a regulator
It’s important to start by separating three ideas that get used as synonyms and shouldn't be. Explainability concerns why a model produced a given output. Transparency concerns disclosure of how a system was built and what it does. AI auditability is narrower and more mechanical than either. It's whether you can produce evidence, after the fact, that a specific decision happened the way you say it happened, under the controls you say were in force, using the data and model version you say were in use.
That definition is unglamorous on purpose. An auditor doesn't need your system to be interpretable. They need it to be reconstructible. Those are different engineering problems, and teams that optimize for the first routinely fail the second.
The distinction surfaces fast under questioning. A model card tells an examiner what a system is supposed to do. It says nothing about what it did on March 14th at 9:42 for a specific customer.
Only a record does that, and the record has to exist before anyone asks for it. You can't manufacture evidence retroactively, which is why this is an architecture decision rather than a documentation exercise. Our glossary entry on AI auditability breaks down the component parts.
Did the 2026 deadline changes lower the bar?
No, and the reasoning behind each change explains why. On 17 April 2026, the Federal Reserve, OCC, and FDIC jointly issued revised model risk management guidance, SR 26-2, replacing SR 11-7 after 15 years. The revision is principles-based rather than prescriptive, and it explicitly excludes generative and agentic AI from scope on the grounds that both are novel and rapidly evolving. Plenty of institutions read that carve-out as permission to wait.
However, the agencies stated that existing risk management and governance practices still apply to systems outside the guidance, and they signalled a separate request for information covering banks' use of generative and agentic AI.
Supervisors can act on unsafe or unsound practice regardless of whether a system sits inside a named framework. The carve-out removed the checklist, not the expectation. A principles-based standard is arguably harder to satisfy with paperwork, because you now have to defend your reasoning rather than point at a control you implemented.
The European timeline shifted the same way. The Digital Omnibus on AI, published in the Official Journal in July 2026, deferred high-risk obligations for standalone Annex III systems from August 2nd of this year, to December 2nd, 2027. That deferral is extended even longer for AI embedded in regulated products to 2028.
What didn't move was Article 50 on transparency obligations, which went into effect August 2nd as originally scheduled. Article 12, the record-keeping provision, didn't change in substance either. High-risk systems still have to automatically log events across their lifetime in a way that supports traceability, and deployers still have to keep those logs for at least 6 months under Article 26(6).
Now that we have the bird's eye view of the situation, let’s get into the 5 specific questions you’ll likely be asked by an auditor.
Producing a complete inventory of every AI system in use
This is the opening ask, every time, and companies fail this more often than any other. An inventory entails considerably more than a list of approved vendors. It means having a catalogue of every system touching a regulated decision, who owns it, what data it reads, what it's permitted to do, and when it was last reviewed. The hard part isn't keeping track of the systems you procured. It's the ones nobody told you about.
IBM's 2025 Cost of a Data Breach research found that 63% of breached organizations had no AI governance policy at all, and among those that did, only 34% ran regular audits for unsanctioned AI use. One in five studied organizations experienced a breach connected to shadow AI, and those incidents added as much as $670,000 to the average breach cost.
When an examiner asks for an inventory and you hand over a list omitting the tool somebody wired into a business process last quarter, the omission isn't the finding. Your control environment is.
The pattern repeats what happened with unsanctioned RPA a decade ago, and the lessons from that era of tool sprawl still hold. Central procurement gates don't produce inventories. Runtime discovery does.
Reconstructing a single decision in six months
Ask number two separates real programs from presentation decks. Reconstruction means pulling one decision out of the past and re-deriving how it happened.
In practice, that requires 6 artifacts stored together and joined by a correlation ID:
- Input as received
- Context retrieved plus the source documents it came from
- Model and version invoked
- System prompt and configuration in force at that moment
- Output produced
- Identity of whoever saw or acted on it
Most off-the-shelf deployments store just 2 of the 6. They log the prompt and the completion, which feels like an audit trail until somebody asks which version of the retrieval index was live, or which of four candidate documents the answer actually drew from. Application logs also tend to be mutable, and a log an engineer can edit isn't evidence.
Article 12 of the EU AI Act states the expectation plainly for high-risk systems: Automatic recording of events across the system's lifetime, sufficient for traceability, generated by the system rather than typed up by an operator afterwards.
That standard has become the reference point well outside Europe, because it describes what any investigator needs. This is the half of audit-ready reporting that has to live in the data layer rather than getting bolted on at the reporting layer.
Showing that a human could have intervened
Human oversight is the control most often claimed and least often evidenced. Claiming a human in the loop requires three demonstrable things:
- The reviewer had enough information to form an independent judgment
- The reviewer had both the authority and the mechanism to override
- And overrides actually happened at some observable rate
That third point catches documentation-first programs because a review step with a 100% approval rate is a rubber stamp and every experienced examiner knows it. If your override rate is zero across 40,000 decisions, you don't have oversight, you have a checkbox.
Track override frequency, override reasons, and the downstream outcome of overridden cases. The reasons are where the system's real failure modes live, which makes them the most useful data your governance program produces.
The gap here is measurable. Grant Thornton found that while nearly 3 in 4 organizations are piloting, scaling, or running autonomous AI, only about 1 in 5 has tested a response plan for AI failures. Untested plans don't count as controls. We've written more on governing and customizing enterprise AI agents at scale.
Who challenged the system before it reached production?
Effective challenge survived every rewrite of US model risk guidance across 15 years, including into SR 26-2, because it's the principle everything else rests on. But what does that mean exactly?
Effective challenge means critical review by people who didn't build the system. The folks who have the technical competence to find its limits, and who carry enough organizational standing that their objections change something. That last clause gets quietly dropped. A validation team reporting to the head of the business unit shipping the model isn't independent, regardless of what the org chart says.
What an examiner asks for here is specific. Show the review. Show what the reviewers objected to. Show what changed as a result, or show the documented rationale for why nothing did. A validation report with no findings is a red flag rather than a clean bill of health. Systems this complex have limits, and a review that found none didn't look hard enough.
For generative systems the challenge function needs different tooling than classical model validation. Conceptual soundness and outcomes analysis don't translate cleanly to open-ended text, which is precisely why the agencies deferred writing rules for it. That deferral hands the design problem back to you. Our own ISO 42001 certification work came out of building that function internally.
Proving the controls operated rather than merely exist
The final ask catches otherwise mature programs. Having a control and evidencing that the control ran are separate claims. A drift threshold documented in a policy proves nothing. The monitoring records showing that threshold was evaluated on a schedule, what the readings were, and what happened on the occasions it was breached, that's evidence.
The incident data suggests most organizations aren't generating it. Stanford's 2026 AI Index recorded 362 documented AI incidents in 2025, up from 233 the year before, a 55% increase. In the survey work behind the Index, the share of organizations rating their AI incident response as excellent fell from 28% to 18% year over year, while the share of organizations reporting 3 to 5 incidents in a year climbed from 30% to 50%. More incidents, weaker response, and no operating evidence is a hard combination to defend in an audit.
Generate the evidence as a byproduct of operation rather than as a reporting exercise. Anything a person has to remember to record won't survive by quarter-end. Our approach to enterprise AI data security treats control evidence as a first-class output of the pipeline rather than a downstream report.
What audit-ready AI looks like
The 5 questions share a structural property. Each is satisfied by an evidence layer sitting underneath the application rather than inside it. Treated that way, AI auditability stops being a compliance workstream and becomes a property of the runtime.
That's the argument for putting inventory, decision records, override tracking, review artifacts, and control telemetry at the platform level. Solve them once and every subsequent use case inherits them. Solve them per project, and you'll rebuild the same plumbing 8 times, inconsistently, while your inventory degrades into a spreadsheet somebody maintains by hand.
Unframe builds this into the runtime rather than shipping it as a separate governance module. Every solution runs against a governed knowledge fabric with source-level lineage, so decision reconstruction is a query rather than a forensics project. That matters most in financial services, where the examination cycle is annual and the evidence request isn't hypothetical.
Here’s the reality. Regulators handed most organizations 16 extra months. Programs that spend it building the evidence layer will pass. Programs that spend it writing more policy will be in exactly the same position in December 2027. Only with less runway and the same 5 questions waiting. Uncontrolled AI is a huge risk, and the control that matters is the one you can prove.
FAQs
What is the difference between AI auditability and explainability?
Explainability concerns why a model produced a particular output, usually through feature attribution or reasoning traces. Auditability concerns whether you can produce evidence after the fact that a specific decision happened as claimed, under the controls claimed, using the model version and data claimed. A system can be highly explainable and completely unauditable if it keeps no durable record of what it did. Regulators ask for reconstructible records far more often than they ask for interpretability.
Did SR 26-2 remove AI governance requirements for banks?
No. SR 26-2, issued jointly by the Federal Reserve, OCC, and FDIC on 17 April 2026, replaced SR 11-7 and excluded generative and agentic AI from its formal scope. The guidance directs institutions to apply existing risk management and governance practices to systems outside that scope, and the agencies signalled a forthcoming request for information on AI model risk. Supervisors retain the ability to act on unsafe or unsound practice regardless of scope.
What does the EU AI Act require you to log?
Article 12 requires high-risk AI systems to technically allow automatic recording of events across the system's lifetime, at a level of traceability appropriate to the intended purpose. The logs must support risk identification, post-market monitoring, and operational monitoring. Under Article 26(6), deployers must retain those logs for a period appropriate to the intended use and for at least six months. The high-risk compliance date moved to 2 December 2027 for standalone Annex III systems, but the record-keeping obligation itself was not changed.
How long should AI decision records be retained?
Six months is the EU floor for deployer-held logs under Article 26(6), and it's a floor rather than a target. Retention should be set by the dispute and examination window of the decision, not by the regulation. Credit decisions, underwriting outcomes, and claims determinations are commonly challenged well beyond a year, so retention typically runs to the statute of limitations for the underlying decision type. Storage cost is rarely the binding constraint. Schema stability is.
Can you make an existing AI deployment auditable after the fact?
Partially. You can add inventory, monitoring, override tracking, and independent review to a running system, and those cover three of the five common asks. What you can't retrofit is the historical record. Decisions already made without a decision-level trail stay unreconstructible, because the retrieved context, model version, and configuration in force at that moment weren't captured. That's why the evidence layer belongs in the architecture rather than in a remediation project.
.svg)