AI code remediation for banks: autofix under EU AI Act and SR 11-7

Why This Question Is Sharper in 2026

“Should I let an AI fix our code?” landed differently in a financial services codebase in 2026 than it did even twelve months earlier. Two regulatory changes are responsible.

First, the EU AI Act’s high-risk provisions become fully enforceable for financial services systems starting August 2026. Credit scoring, loan approval automation, fraud detection, and certain customer-facing decisioning systems are classified as high-risk. Any AI system that “materially influences” the output of those systems — including coding agents that modify the code implementing them — falls under requirements for risk management, human oversight, transparency, logging, and post-market monitoring.

Second, US bank regulators clarified in Q1 2026 that SR 11-7 (the Federal Reserve’s Model Risk Management guidance) applies to AI-generated code changes that touch models or model-adjacent systems. This means banks now need to document and validate AI coding agents the same way they document and validate any other model, including ongoing performance monitoring.

On top of those, DORA (the EU’s Digital Operational Resilience Act) has been in force since January 2025, and its ICT third-party risk requirements now explicitly include AI coding services.

The net effect: “We just let Claude Code fix it” is no longer a defensible answer in an audit. But that does not mean AI code remediation is off the table. It means the implementation has to be compliance-aware from day one.

This guide is how to do that.

The Core Principle: Agents as Documented Systems

The instinct in many fintech engineering teams is to treat an AI coding agent like a new tool — install it, let developers try it, see what sticks. That instinct is fine for a marketing website. It is dangerous in a codebase that implements a credit model or an AML rule.

Under SR 11-7 and the EU AI Act, any AI system whose output changes the behavior of a regulated system needs to be a documented system itself. Practically, this means your organization needs:

An inventory of every AI coding agent in use (Claude Code, Cursor, GitHub Copilot, Codex, IAN, internal tools), with owners, approved use cases, and risk classification.

A written policy describing what each agent is permitted to touch, how its output is reviewed, and who is accountable when it goes wrong.

An audit trail of every change an agent makes to a regulated codebase, retrievable for at least the retention period required by the applicable regulator (typically 5–7 years).

Periodic validation — at least annually — that the agent’s behavior on a representative test set still matches expectations.

This is not exotic. It is the same practice banks already apply to in-house models. The shift is recognizing that coding agents deserve the same treatment.

The Four-Stage Pipeline

A compliance-aware AI code remediation workflow has four stages, each of which produces artifacts an auditor will want to see.

Stage 1: Scoped Access

The agent does not have free run of the codebase. It operates against a scoped working copy with read-only access to non-regulated modules and write access only to the specific repository, branch, or file patterns relevant to the task.

For regulated codebases, this typically means:

• One repository or subdirectory per regulatory classification (e.g., credit-model/, aml-rules/, customer-facing-decisioning/)
• Branch protection on main with required reviewers that include at least one human from the owning risk function
• No write access to test data, production configuration, or feature flags that control regulated behavior

Implementation in practice: most teams use GitHub or GitLab role-based access with a dedicated service account for each agent, scoped to specific repositories. The agent’s credentials never touch a production cluster directly.

Stage 2: Change Classification

Before the agent makes a change, a classifier (can be a simpler model, can be rules-based) determines whether the proposed change is:

• Cosmetic — formatting, comments, variable renames, test-only changes. These can go through a standard PR review.
• Functional non-regulated — logic changes in code paths that do not affect regulated outcomes. Standard review plus automated test suite.
• Functional regulated — any change that modifies code implementing a high-risk system under the EU AI Act, a credit model under SR 11-7, or any behavior covered by a specific rule (AML, KYC, BSA, MiFID II, etc.).

The classification is itself an artifact the auditor will see. Get it wrong in either direction and the reviewer’s time is wasted (false positives) or the regulator has a finding (false negatives).

The 2026 best practice: use two classifiers in sequence. A fast pattern-based classifier catches the obvious cases. A model-based classifier reviews the rest and can be shown a full audit trail of its own decisions. Both results are stored with the PR.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Stage 3: Augmented Review

Functional regulated changes get augmented review. The PR comment is not just “here is the diff” — it includes:

• A plain-language explanation of what the change does, generated by the agent and reviewed by the classifier
• A specific call-out of which regulated behaviors are affected, if any
• The test coverage delta on the modified code paths
• A reference to the relevant regulatory control (e.g., “this code implements control AML-RULE-03 from the internal AML framework”)

The human reviewer for a regulated change is not just an engineer — it is an engineer plus a member of the risk or compliance function, or an engineer who has been specifically designated as a reviewer for that regulatory domain. Many banks use a “two-key” model where both technical and risk reviewers must approve before merge.

Critically, the reviewer is reviewing the agent’s output, not the original problem. The reviewer should be able to answer: “If this change misbehaves in production, would I be able to defend the decision to merge it in front of a regulator?” If the answer is no, the change does not merge.

Stage 4: Post-Deploy Monitoring and Rollback

The last stage is ongoing. Once a change lands in production, it needs to be observed for behavior drift — especially if it modifies a high-risk system. Observability signals:

• Rate of decisions made by the affected code path, broken out by outcome
• Any change in the distribution of outcomes compared to the pre-change baseline (e.g., credit model decline rate by demographic segment, to catch potential fair-lending issues)
• Exception rates in the changed code paths
• Performance regressions that could cascade into SLA violations

A rollback capability must exist and be exercised. Regulators do not want to hear “we could roll this back in theory” — they want to see a recent rollback in the change log, proving the capability is live.

What “Compliance-Aware” Does Not Mean

Three common misinterpretations of AI code remediation in financial services are worth flagging.

It does not mean banning AI code remediation. Most bank regulators have explicitly said they do not expect firms to avoid AI — they expect firms to govern it. An outright ban is both non-compliant with internal efficiency mandates and increasingly out of step with industry practice.

It does not mean requiring a human to type every keystroke. The regulatory ask is that a human with appropriate authority reviews and accepts the change. That can scale through well-designed PR workflows. It does not require watching the agent type.

It does not mean using only “approved” models from a single vendor. Under SR 11-7 and the EU AI Act, the obligation is to validate and monitor whatever model you use. A firm can use Claude, GPT-5, a fine-tuned open-source model, or several — as long as each one is inventoried, classified, and governed.

How IAN Handles This

IAN was built with regulated codebases as a first-class use case. Every change IAN proposes is classified (cosmetic / functional non-regulated / functional regulated) and tagged with the affected regulatory domain at PR creation time. The full audit trail — the agent’s reasoning, the classification decision, the reviewer identity, the test coverage delta, the post-deploy observability link — is exportable as a single document per change for compliance workflows.

For banks and fintechs running under DORA, SR 11-7, or EU AI Act high-risk classification, IAN also provides a standing export of all agent-driven changes over any date range, mapped to the customer’s own internal control framework. This is what an auditor asks for, and having it pre-built removes weeks of exam preparation.

Several of IAN’s customers in European banking have already passed 2026 regulatory examinations where AI coding agent usage was explicitly in scope. The feedback from the examiner in one case was that the audit trail was “more complete than any human-only change log we have reviewed.”

Start Small, Document Everything

If you are in a regulated financial codebase and have not yet adopted AI code remediation at any scale, start with cosmetic changes only — formatting, dead code removal, documentation updates. Prove out the classification and audit trail on changes with no regulatory exposure. Then expand to functional non-regulated, then to regulated with the full four-stage pipeline in place.

The firms that will be the fastest by end of 2026 are not the ones that adopted AI code remediation earliest. They are the ones that built the compliance infrastructure alongside it.

Get a free infrastructure audit → | See pricing →