AI Audit Trail in Financial Services: What to Log, How Long to Keep It, and What Examiners Test

TL;DR

• OCC Bulletin 2026-13, NIST AI RMF, the FS AI RMF, and EU AI Act Article 12 all require evidence — not just policies — that your AI systems are managed and monitored
• EU AI Act Article 12 mandates automatic logging for high-risk AI and a minimum six-month retention period; credit institution requirements are longer
• Colorado SB 26-189 requires three years of ADMT documentation retention for deployers; the financial institution exemption was eliminated in May 2026
• Agentic AI systems require a fundamentally different logging model — decisions aren’t a single input/output event, they’re multi-step action sequences that must be reconstructed from logs

An OCC examiner sits down across from you and asks: “Can you show me the monitoring logs for your AI credit decisioning model — the last six months of performance data, drift detection results, and any override records?” If your answer is “what logs?”, that’s not the start of a good week.

AI governance discussions spend a lot of time on committees, policies, and frameworks. When examiners evaluate AI risk in practice, they ask for documentation — the evidence trail proving your AI system was built as designed, validated before deployment, monitored in production, and managed when something went wrong. That evidence is your AI audit trail. There’s now a layered set of regulatory requirements specifying what it must contain.

Why Regulators Are Asking About Logging Now

The 2026 regulatory cycle changed AI documentation from a recommended practice to an expected requirement. Three developments drove this.

First, OCC Bulletin 2026-13 (April 2026) replaced SR 11-7 and introduced risk-based proportionality to model risk management — but it did not reduce documentation expectations. It increased specificity about what ongoing monitoring evidence looks like. The bulletin explicitly excludes GenAI from its formal scope while noting that banks are expected to apply “broader risk management practices” to those systems. In practice, examiners are treating this as: GenAI governance is expected even if the specific validation framework is still being developed.

Second, the FS AI RMF — the U.S. Treasury’s Financial Services AI Risk Management Framework, released February 2026 — established 230 control objectives organized across seven domains. Two domains are especially relevant for audit trails: Transparency and Explainability (which requires evidence that AI decisions can be reconstructed and explained) and AI Incident Management (which requires logs to support incident investigation and regulatory reporting). The framework is voluntary, but examiners are using its vocabulary during AI-focused exam cycles, and institutions without documentation for these domains are drawing scrutiny.

Third, EU AI Act enforcement for high-risk AI provisions begins August 2, 2026. For any US bank with EU operations, Article 12 — the logging provision — now carries teeth.

What EU AI Act Article 12 Requires

Article 12 is the technical logging obligation for high-risk AI systems. It requires that:

• High-risk AI systems must have logging capabilities enabling automatic recording of events throughout the system’s operational lifetime
• Logs must capture, at minimum: the periods during which the system was used, a reference database used for input data checks, input data checked against that database (where technically feasible), and identification data for natural persons involved in verification (for biometric systems)
• Deployers — not providers — must retain logs for a minimum of six months, or longer if required by applicable Union or member state law

For credit institutions, the applicable banking supervisory law typically imposes much longer retention requirements. A six-month floor for logs from an AI credit decisioning system likely doesn’t survive contact with standard bank examination document retention expectations. Build your retention schedule around the longest applicable requirement, not the shortest.

The August 2, 2026 date applies to these logging requirements. If you have EU-facing high-risk AI systems and haven’t built logging into them yet, you’re already behind.

OCC 2026-13 and the Documentation Lifecycle

OCC Bulletin 2026-13 maintained the core principle that every model should be documented from development through decommissioning. For a defensible AI audit trail under the new framework, documentation needs to exist at seven stages:

1. Model inception. What problem is this model solving? Who approved it? What regulatory touch points apply (ECOA, FCRA, BSA/AML, others)? This isn’t a business case memo — it’s the documented rationale that grounds every subsequent validation and monitoring decision.

2. Development documentation. Training data sources and quality assessment. Feature engineering decisions and the rationale for including or excluding variables. Architectural choices. Benchmark comparisons. Limitations and known failure modes identified during development.

3. Pre-deployment validation. Who validated the model (independent from development)? What validation methodology was used? What did testing reveal, and how were findings addressed before deployment? For high-risk models — credit, fraud, AML — this record needs to demonstrate independent challenge, not just approval.

4. Approval and go-live record. Who approved deployment? What conditions were attached? What monitoring thresholds trigger escalation? What’s the model’s designated review cadence? The approval record creates the accountability baseline you’ll need when something changes.

5. Ongoing monitoring evidence. This is where most AI programs fall down. “We monitor the model” is not evidence. Evidence looks like: performance reports showing accuracy, precision, recall, or other relevant metrics over time; drift detection results (concept drift, data drift); population stability index readings; adverse action reason code distribution; override volume and patterns; complaints attributable to model outputs; and periodic benchmark comparisons. Monthly or quarterly is typical; higher-risk models may need continuous monitoring dashboards with alert thresholds.

6. Change management records. Every material change to the model — retraining on new data, feature additions or removals, threshold adjustments, deployment environment changes — needs a change request, an impact assessment, validation of the changed model, and approval before the change goes to production. An undocumented model update is a model risk finding.

7. Incident and exception records. When the model does something unexpected, produces an anomalous result, or generates a customer complaint attributable to its outputs, that event needs to be logged, investigated, and resolved. The incident record — not just the resolution — is what examiners want to see.

Colorado SB 26-189: Three Years for ADMT Records

Colorado’s overhaul of its AI law — signed May 14, 2026 as SB 26-189 — eliminated the financial institution exemption that had let banks and credit unions sidestep the original Colorado AI Act. Any deployer of Automated Decision-Making Technology that affects Colorado residents in consequential decisions is now covered.

For compliance documentation, SB 26-189 requires deployers to retain records for three years after each deployment, including:

• The risk assessment conducted before deployment
• Documentation of how human review was provided to consumers who received adverse outcomes
• Records of pre-use notices provided to affected individuals
• Evidence of how adverse outcome notices were delivered within the 30-day window

Three years from deployment means three years from each decision that triggers documentation — not from when the model was first deployed. If your credit model approved or denied 10,000 applications last month, the clock starts on each individual outcome.

The NIST AI RMF Evidence Requirements

NIST AI RMF (NIST AI 100-1, published January 2023) isn’t a compliance framework with mandatory requirements — it’s a voluntary guidance document. But examiners are using it as a reference for what “good” looks like, and the FS AI RMF maps extensively to its structure.

Three RMF functions are especially relevant to audit trail documentation:

GOVERN establishes the organizational processes and accountability for AI risk. For audit trail purposes, this means: documented roles (who owns AI risk decisions, who validates, who monitors), escalation procedures, and evidence that governance processes actually ran — meeting records, approval signatures, sign-off workflows.

MEASURE focuses on ongoing monitoring and metrics. The relevant outputs here are: performance metrics with thresholds, drift detection reports, bias and fairness test results, human override tracking, and incident logs. The RMF doesn’t specify how often or what format — it expects evidence that measurement is happening and that someone acts on the results.

MANAGE addresses risk treatment and response. For documentation, this means records of risk decisions: accepted risks (with documented rationale), treated risks (with remediation evidence), and escalated risks (with governance trail). When a model monitoring report shows performance degradation, the MANAGE record shows what was done about it.

Agentic AI Changes Everything About Logging

Standard model logging is structured around an event: input → model → output. One row in a table, one timestamped record. The risk is captured in that single inference event.

Agentic AI systems — AI that autonomously takes sequences of actions, calls external tools, interacts with APIs, and produces downstream effects — can’t be logged this way. An agent completing a task might take 15 sequential actions across 6 external systems before producing an output. The audit trail for that task needs to capture the entire sequence.

What an agentic AI log needs to contain:

For financial services firms deploying AI agents in workflows that touch customers, move money, or produce regulatory artifacts, this isn’t a nice-to-have. It’s the minimum needed to investigate a complaint, respond to a regulatory inquiry, or reconstruct what happened during an incident.

The AI governance framework your institution builds needs to account for this distinction — not just at the policy level, but in what you’re actually logging and retaining.

How Long to Keep What

Note that these are minimums. Your institution’s document retention policy may require longer, and specific product types (mortgage, auto lending, BSA/AML) may have their own regulatory retention requirements that extend these windows.

Building the Audit Trail Before the Examiner Asks

The institutions that struggle with AI documentation aren’t lacking knowledge of what’s required — they’re lacking a system for capturing it during normal operations. When documentation becomes an exam-preparation exercise rather than a byproduct of how decisions are made and reviewed, it shows.

Three practices that build audit trail discipline into the AI lifecycle rather than retrofitting it:

Document decisions at the decision point. Approval of a new AI model, a validation finding, a monitoring exception — each of these is a decision. The person making the decision writes the record at the time, not months later when an examiner asks. This is operational discipline, not documentation theater.

Automate monitoring capture. Performance metrics, drift detection results, population stability readings — these should be generated automatically and stored in a retrievable system, not assembled manually from spreadsheets when someone asks for the last six months of monitoring data.

Treat model changes like code releases. Change management in AI should be as disciplined as software change management in regulated environments: request, impact assessment, validation, approval, deployment record. Every model update with a timestamp, an approver, and a documented rationale.

So What?

The regulatory trajectory is clear: AI documentation expectations are rising, not settling. OCC 2026-13 tightened ongoing monitoring evidence requirements. The FS AI RMF added 230 control objectives many institutions haven’t inventoried against. EU AI Act Article 12 made logging a legal requirement for high-risk AI deployers with EU exposure. Colorado SB 26-189 added a three-year ADMT records retention obligation effective January 1, 2027.

The gap between institutions that have defensible AI audit trails and those that don’t is growing. And the exam cycle is the wrong place to discover which category you’re in.

If you’re building or strengthening your AI governance program, the AI Risk Assessment Template & Guide includes a model inventory with lifecycle documentation fields, a pre-deployment assessment scorecard, and an AI governance dashboard tab — pre-built for the 2026 regulatory landscape, including OCC 2026-13, NIST AI RMF 1.1, and the FS AI RMF.

The OCC’s model risk management update is worth reading alongside this post — particularly for how policy-level governance connects to the evidence-level documentation covered here.