The most common failure mode when an examiner asks about AI-assisted decisions isn't that the institution did something wrong. It's that the evidence proving they did something right doesn't exist in a form anyone can produce on request.

An audit or exam is, at its core, a request for evidence. When AI is part of a customer-facing process, examiners increasingly ask for the same category of evidence they'd expect for any other automated decision system — who owns it, what it's authorized to do, how its behavior is documented, and how errors get caught. The institutions that struggle aren't necessarily running risky AI. They're running AI without having built the evidence trail alongside it.

The five categories examiners actually ask about

1. Ownership and accountability

Who is accountable for this system, by name or role, not just by department? Examiners want a specific answer, not "IT manages that." Have documented ownership across business, technical, and compliance roles, with each person's specific responsibilities written down.

2. Scope and authorization

What is this system explicitly authorized to decide on its own, and what requires human review? This needs to be a documented boundary, decided in advance, not a description of what the system happens to be capable of. If you can't produce a list of authorized decision types, that's the first gap to close.

3. Decision traceability

For any given customer interaction, can you reconstruct exactly what happened — what rule fired, what data was evaluated, what the outcome was, and whether it required escalation? This is the core of what a sealed audit trail provides, and it's the single most commonly requested artifact in an AI-related exam.

4. Change history

When the underlying policy or rule changed, is there a record of when, why, and who approved it? Version-controlled business rules answer this by design. A model that was quietly retrained or a prompt that was casually edited, with no log, is a documentation gap waiting to surface at the worst time.

5. Monitoring and error correction

How do you know when the system is behaving inconsistently or making mistakes, and what's the process for catching and correcting it? "We haven't had complaints" is not a monitoring process. Ongoing spot-checks, drift detection, and a documented escalation path for flagged issues are what examiners look for here.

An examiner isn't asking whether your AI is good. They're asking whether you can prove it — on demand, for a specific case, on a specific date.

AI regulatory compliance is fragmented — here's what that means practically

Unlike some compliance domains with a single controlling regulation, AI regulatory compliance for a bank, insurer, or health system currently means satisfying several overlapping sources at once: existing sector regulation that already applies regardless of whether AI is involved (fair lending, HIPAA, state insurance codes), AI-specific disclosure rules that are being written state by state, and voluntary frameworks like the NIST AI RMF that examiners increasingly treat as a practical benchmark even without a formal mandate. There is no single checklist that satisfies all of them everywhere, which is exactly why the five categories above are organized around the evidence examiners ask for rather than around any one specific regulation — that evidence tends to satisfy multiple overlapping requirements at once, while chasing each regulation individually creates duplicate, inconsistent documentation.

The AI audit trail: the artifact every category above depends on

If there's one artifact that does more work than any other on this list, it's a real AI audit trail — not a support-ticket log, but a system-level record that ties every customer-facing decision to the rule, source document, and inputs that produced it. It's worth being specific about what a usable one contains, because "we have logs" and "we have an audit trail" are not the same claim:

  • A unique identifier for the decision, tied to the specific customer interaction it belongs to.
  • The rule or model version that was active at the moment of the decision — not the current version, the version at that specific timestamp.
  • The inputs the system evaluated, in enough detail to reconstruct why this outcome and not another.
  • Whether the decision was fully automated or escalated, and if escalated, who made the final call.
  • A retention period that matches your regulatory requirements, not just your default log rotation policy.

A deterministic-core architecture produces this kind of audit trail as a structural byproduct of how it operates. A system built around a general-purpose model producing free-text responses typically has to bolt this on afterward, which is where gaps tend to appear — usually not because anyone decided to skip documentation, but because the architecture wasn't built with the audit trail as a first-class output.

Building the checklist into your deployment, not after it

Every item above is far cheaper to build in from the start than to reconstruct after an exam request lands. That's the practical argument for a deterministic-core architecture with a built-in audit trail: the evidence examiners ask for is a byproduct of how the system runs, not a separate documentation project layered on top of it.