AI Governance in Lending — What EU Regulators Actually Expect [2026]

In 2026 every lending institution has an "AI governance policy." Most of them are eight pages of principles and zero pages of operational controls. Supervisors are starting to notice.

This article is for Chief Risk Officers, Heads of Compliance and Model Risk Officers who need to know what their next supervisory inspection will actually look at — and what evidence they need on hand before it arrives.

Note. This is a working operator's view drawn from documentation we use internally and with clients. It is not legal advice. Regulatory interpretation can change; specific obligations depend on your jurisdiction, license type and the classification of your AI systems.

The regulatory frame in 2026

Three regulatory threads converge on lending AI:

The EU AI Act. Credit-scoring and creditworthiness assessments that affect natural persons are listed as high-risk AI systems under Annex III. High-risk classification triggers obligations around risk management, data governance, technical documentation, transparency, human oversight, accuracy/robustness and post-market monitoring.
DORA (Digital Operational Resilience Act). AI systems used in financial services are ICT systems. They fall under DORA's incident reporting, third-party risk, and operational resilience testing requirements.
National banking and consumer-credit law. Most EU member states still apply national rules on credit decisions — including explanation rights, anti-discrimination duties and human-review obligations — that exist independently of the AI Act.

Beyond Europe, similar duties apply: ECOA in the US, the FCA's expectations for AI use in regulated firms in the UK, and supervisory guidance from individual national regulators across LATAM.

Where these overlap, regulators are now asking the same five questions. We list them below — with what "good" looks like in 2026.

The five questions a supervisor will ask

1. "Can you show us which decisions were made by AI, and which by humans?"

The minimum control here is a decision log that, for every credit decision, captures:

The decision (approve / decline / refer)
The model version and feature set used
The inputs (with PII appropriately handled)
Whether a human reviewed the outcome — and if so, who, when and what they changed
The downstream action taken

A common failure: institutions log the outcome but not the attribution. If your decision log cannot answer "was this approval made by the model, or by an underwriter overriding the model?" you do not have an audit trail. You have a database.

2. "How do you ensure decisions are explainable to the customer?"

Under GDPR Article 22 and analogous national rules, customers subjected to automated decisions with legal or similarly significant effects have rights to meaningful information about the logic involved. In a lending context, this typically means:

A customer-facing adverse action explanation for declines (often required by law independently of AI)
An internal explanation artefact that lets a complaints officer or court reproduce the reasoning
A clear policy on what the customer is told versus what is retained internally

Explainability is not "we use SHAP values." It is a documented process that produces a human-readable reason, traceable to the model behavior, on request, within the legal window. The technique matters less than the operational guarantee.

3. "How do you monitor for bias and disparate impact?"

The expectation is not "we ran a fairness analysis when we built the model." It is an ongoing program:

Periodic disparate-impact testing across protected classes (where it is lawful to compute them, which varies by jurisdiction)
Drift monitoring on score distributions, approval rates and loss rates per cohort
A pre-defined escalation policy when drift breaches a threshold — who gets notified, what is paused, who can resume

The trap: many institutions only test pre-deployment. Supervisors increasingly expect a post-market monitoring capability — the EU AI Act explicitly names it for high-risk systems.

4. "What is your human oversight design?"

"There is a human in the loop" is no longer a satisfactory answer. Supervisors want to know:

Which classes of decision require human review (typically: declines, high-value approvals, edge cases, complaints, appeals)
What information the human reviewer sees, in what form, and within what latency
How the human's override is captured — and whether the model learns from it (which, in turn, raises model risk questions)
Whether the human has the authority and the time to actually override — or whether they are pressured into rubber-stamping

A growing supervisory concern is automation bias: humans defaulting to "agree with model" because their incentives, dashboards or workflows push them there. Demonstrating that your reviewers actually overturn the model some non-trivial percentage of the time is increasingly part of the evidence base.

5. "What happens when the model is wrong?"

This is the question most institutions are least prepared for. Supervisors want a documented answer to:

How you detect that a decision was wrong (complaint, reversal, late-stage performance, internal QA)
How you remediate the affected customer (re-decision, refund, credit-file correction)
How you remediate the model (re-train, re-calibrate, suspend)
What you report, to whom, and within what window (the AI Act's serious-incident reporting, plus any DORA major-incident overlap)

A robust answer here is what separates an AI governance policy from an AI governance program.

The controls that actually deliver

In the institutions where this works, the controls are not in a binder. They are in the architecture. We see five controls show up consistently:

1. A model registry that tracks every version that ever scored a customer. Not "the current model" — every version, with hash, training data lineage, fairness test results, and the calendar window during which it was live in production.

2. A decision ledger separate from the model. The ledger records the decision, the model version, the inputs, the human overrides — and is immutable. Re-deriving the decision from a fresh model run is not the same as having the original audit trail.

3. Pre-deployment and post-deployment fairness pipelines that share metrics. A monitoring metric that doesn't match a deployment metric is a red flag — you cannot tell if production is consistent with pre-production.

4. A "kill switch" with documented criteria. Specific, pre-agreed thresholds at which the model is paused, with named owners and a documented unpause process. Vague language ("if material drift is detected") is not a control.

5. A line between commercial decisions and compliance decisions. Approvals can be model-driven. Sanctions, AML and KYC outcomes should not be — those belong with a Compliance Agent on a stricter governance regime. We cover this in The Five-Agent Model.

Common gaps we see in lending AI governance

Across the lending programs we work with, four gaps appear over and over:

Vendor opacity. Institutions use third-party scoring models without the documentation needed to meet AI Act high-risk obligations. Procurement happened before AI Act-aligned diligence was standard. Remediation: vendor questionnaire, contractual amendments, fallback plan if the vendor cannot evidence the controls you owe a regulator.
Implicit ensemble decisioning. A "main" model plus several "guardrail" rules plus an "override matrix." On paper, one model. In practice, an ensemble of decisions no one has documented as such.
Frozen documentation. The model card was written in 2024. The model has been retrained four times since. The card is now a fiction.
Disjointed incident response. AI incidents are handled by the data-science team; DORA incidents by ICT; consumer complaints by the contact centre. The supervisor sees three uncoordinated processes where there should be one.

Where CoreFi sits

CoreFi's Risk and Compliance agents are designed around the controls described above — model registry, decision ledger, post-market monitoring, human-in-the-loop policy enforcement, explainability artefacts — available on request and scoped to each customer as part of onboarding. These are designed to support EU AI Act and DORA obligations for high-risk credit decisioning systems; final regulatory positioning always depends on your licence, jurisdiction and how the controls are operated.

We don't sell "AI compliance." We sell the substrate that lets your second-line and your supervisor see what your AI is doing — which is the only honest definition of governance.

For the broader compliance picture, see CoreFi for Compliance & Risk.