Software & AI · Regulated lending & insurance · Written and maintained by Haink’s AI adoption team · Updated August 2026 · 15 min read

AI underwriting: which decisions are high-risk under the EU AI Act

Most articles about AI in underwriting are about speed. They will tell you that a decision that took three days can take twelve minutes, that manual review is expensive, and that machine learning finds patterns humans miss. All of that is true and none of it is the question that decides what you are allowed to build.

Underwriting is one of the few places where the EU AI Act draws a hard line through a single business process. Evaluating the creditworthiness of a natural person is high-risk under Annex III, point 5(b). So is risk assessment and pricing in life and health insurance, under 5(c). Detecting financial fraud is expressly excluded.

That exclusion is the whole article. The same underwriting stack can sit inside or outside the high-risk perimeter depending on which decision it makes — and that is an architectural choice you make when you design the system, not a compliance form you fill in afterwards.

So the honest answer to are we late is no, not in the EU. The obligations bind on 2 December 2027 — roughly one procurement cycle plus one build away. That is a comfortable amount of time to design for and a very uncomfortable amount in which to retrofit a system built without the question in mind. The classification itself did not change; only the date did.

It is also not the earliest date you may be facing. If you lend or underwrite in the Gulf or in Asia, at least one regime is already in full enforcement — covered further down.

Where the line actually runs

Three consequences follow, and the third one is the expensive one.

First, being a fintech does not exempt you. The classification attaches to the function, not to the licence. An entity that never held a banking licence and evaluates creditworthiness is in scope on the same terms as a bank. Neither is it a question of company size, sector self-description or whether the model is bought or built.

Second, the fraud exception is narrower than it reads. It holds where fraud detection is what the system is for — not where it is one of the things the system happens to do. A model that scores an application for fraud risk and creditworthiness in the same pass does not qualify for the exclusion; the combination pulls it back into 5(b). The deciding test is purpose and system boundary, not the name on the module.

Third, one deployment can straddle the line. A lending platform typically runs document intake, identity verification, fraud screening and a credit decision through what the vendor calls one pipeline. Three of those four sit outside 5(b). Only the credit decision sits inside it.

If you built them as one inseparable system, you have pulled your entire document stack into a high-risk regime — risk management system, data governance, technical documentation, logging, human oversight, conformity assessment — for the sake of one component. If you built them as separable services with a clear boundary, the obligations attach where they belong.

We have built the exempt side of exactly this boundary. In an identity verification pipeline for a lending marketplace — document checks, face match, liveness — the system cut fraudulent applications by 75% and raised conversion by 35%. It never made a creditworthiness decision. It handed a verified applicant to the process that did. The general pattern is covered in AI for KYC and identity verification.

That separation was originally an engineering decision about latency and ownership. It is now also the difference between two regulatory regimes.

What “decision support, not replacement” is missing

Every vendor article on this topic converges on the same formula: AI recommends, the underwriter decides, accountability is preserved. It sounds responsible and it is nearly content-free, because nobody says where the line sits.

Here is the version that survives contact with an audit.

Automate the assembly, not the judgment. Extraction, classification, completeness checks, cross-document consistency and flagging of missing or contradictory evidence are mechanical work. They are also where the hours go. In a document control system we built for aviation maintenance, the service classifies each page, detects missing signatures and stamps and finds unfilled checklist cells, then produces an annotated report — before a specialist signs off. Nothing in that system decides anything. It decides what a human needs to look at. The underlying mechanics are the same ones described in how AI document processing works.

Route by exception, and define the exception in advance. Straight-through processing works when the criteria for “straight-through” are written down before the model exists, not derived from what the model happens to be confident about. A confidence threshold is not a policy.

Keep the reasons, not just the outcomes. Under a high-risk regime you will need to reconstruct why a decision was made, months later, for a specific applicant. Systems that log the score and discard the evidence chain cannot do this. It is cheap to build in on day one and expensive to retrofit — which is the practical argument for starting the evidence-chain work now rather than in 2027. Where the data cannot leave your perimeter at all, that logging has to live inside it; see cloud versus private AI and private AI infrastructure.

The threshold nobody calculates

The question every article skips: at what point is automating a decision cheaper than being wrong about it?

It is a straightforward comparison and almost nobody writes it down.

The second term is where underwriting differs from most document automation. In invoice processing a wrong extraction costs a correction. In credit underwriting a wrong decision costs the loan, or costs a customer who should have been approved, or — from December 2027 — costs a regulatory finding. The cost per error is not uniform: a false negative and a false positive have different prices, and in regulated lending they carry different legal weight.

Which is why the honest answer for a lot of teams is a split one. The document layer usually clears the threshold easily, because errors are cheap and correctable and volume is high. The decision layer often does not — not because the model cannot do it, but because the cost of a wrong decision is high enough that the value of automation is mostly the speed, and speed can be bought more cheaply by automating everything up to the decision.

When rules beat models

This is the section our competitors cannot write, because they sell models.

A deterministic rule is preferable when:

• The criterion is written in a regulation or a policy document. If the rule is “debt-to-income above X requires manual review”, implement the rule. A model that learns this from data will approximate it, drift from it, and require explanation when it disagrees with it.
• You need the same input to produce the same output, permanently. Model updates change decisions. In a regime where you must justify a specific past decision, deterministic components are an asset.
• Volume is too low to train on. Speciality lines, new products and small portfolios do not generate enough labelled outcomes.
• The failure mode is asymmetric and expensive. If missing one case costs more than reviewing a hundred, precision matters more than throughput.

Models earn their place where the input is unstructured and the pattern is genuinely learned rather than legislated: reading documents, resolving inconsistencies across sources, ranking cases by likelihood of needing attention. That is also the honest scope for an LLM application or RAG pipeline in this setting.

The practical architecture in most underwriting systems worth building is not “AI underwriting”. It is a document-understanding layer that is machine-learned, feeding a decision layer that is largely deterministic and fully auditable.

What to do before the dates land

If you have an AI system making creditworthiness or life-and-health pricing decisions for people in the EU, the Annex III obligations bind you on 2 December 2027. The deferral is real headroom and it is also the whole of it — the risk management system, data governance, technical documentation, logging, human oversight and conformity assessment all have to exist by that date, and none of them are quick.

Four questions worth answering early, all of which are free:

1. Where does your system make a decision covered by 5(b) or 5(c), and where does it only prepare one? If you cannot draw that line on an architecture diagram, that is the first task, and it is a design task rather than a legal one.
2. Can you reconstruct a specific decision from six months ago — inputs, model version, evidence and the human review step, if any? If not, the logging change should land in the next release, not the 2027 programme, because the value of an audit trail is the history it has accumulated.
3. Are your fraud and identity components separable from your credit decision, technically and contractually? Contractually matters: a vendor who cannot describe the boundary in a schedule cannot help you defend it.
4. Who signs off that the human oversight requirement is actually met, as opposed to a review screen nobody has time to use?

None of these require buying anything. All of them determine what you would need to buy. The related governance work is covered in AI governance for adoption, and the security and data-handling side in security and compliance.

The same question outside the EU

Almost everything written about AI and underwriting assumes a European reader. If you lend or underwrite in the Gulf or in Asia, the boundary question is identical — which components decide and which only prepare — but the answers arrive under different instruments and on a different schedule. In one case, an earlier one than Europe’s.

Read down the status column and the usual assumption inverts. A lender inside the DIFC has been under full enforcement since January 2026; a lender in Frankfurt has until December 2027. The Gulf did not arrive late to this question — it arrived first, through data protection law rather than through a dedicated AI act. Anyone treating the region as the light-touch option is working from a map that is two years out of date.

The instruments differ in name, scope and teeth. What they ask for converges hard:

• The applicant can find out that a machine was involved. Transparency at the point of decision, under whichever label.
• A specific past decision can be explained. Not the model in general — that case, that applicant, that month.
• A human is reachable where the decision bites. Review, objection, recourse.
• The evidence outlives the complaint window. Inputs, versions, sources and reviewer, retained and retrievable.

A system that satisfies those four survives all six regimes without being rebuilt for any of them. A system that cannot satisfy them fails all six — and at that point the differences between the regimes matter a great deal less than the thing they agree on. Which is the practical argument for designing to the strictest of them once, rather than to each of them in turn.

When not to do this

We tell clients not to adopt AI more often than the market expects, so it is worth being specific about when this particular project is a bad idea.

Do not start with underwriting automation if your application intake is still fragmented across email, portals and paper, and nobody owns the data. The pilot will work on the clean subset and fail in production — which is the ordinary way these projects die, and much of why AI pilots fail at all.

Do not start with the decision layer if the document layer is untouched. The document layer is where the hours are, the errors are cheap and the regulatory exposure is lower. It also produces the labelled data the decision layer would need.

And do not start at all if the real constraint is underwriting policy rather than underwriting throughput. Automating a policy nobody agrees with just produces disagreeable decisions faster. We have written the general case for this in when not to adopt AI.

Frequently asked questions

Is AI underwriting high-risk under the EU AI Act?

Part of it is. Annex III, point 5(b) classifies AI intended to evaluate the creditworthiness of natural persons or establish their credit score as high-risk. Point 5(c) does the same for risk assessment and pricing in life and health insurance. Document intake, classification, extraction and identity verification are not covered by either point unless they are functionally inseparable from the decision itself.

When do the high-risk obligations actually apply?

2 December 2027 for stand-alone Annex III systems, credit scoring and insurance pricing included. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and moved the date from 2 August 2026. AI embedded in products covered by Annex I sectoral law moves to 2 August 2028.

Is fraud detection really exempt from the credit-scoring classification?

Yes, but narrowly. Annex III, 5(b) excludes AI systems used to detect financial fraud, and the exclusion holds only where fraud detection is what the system is for. A model that scores an application for fraud risk and creditworthiness at the same time does not qualify: the combination pulls it back into 5(b). Whether you benefit from the exclusion is decided by system boundaries, not by what the module is called.

Does the AI Act apply to us if we are not a bank?

Yes. The classification attaches to the function, not to the licence. An entity that has never held a banking licence and evaluates the creditworthiness of natural persons falls under 5(b) on the same terms as a bank. Being a technology company, a marketplace or a broker changes nothing about the classification.

Does the deferral to December 2027 mean nothing applies to automated underwriting today?

No. The Digital Omnibus moved one deadline in one regulation. GDPR Article 22 has applied since 2018 and covers automated credit decisions directly. National consumer-credit and insurance-conduct rules also apply now. Separately, the AI Act's Article 50 transparency obligations took effect on 2 August 2026 and reach any point where an applicant interacts with an AI system or receives AI-generated content.

We do not operate in the EU. Does any of this apply to us?

Probably, under a different instrument and often sooner. DIFC Regulation 10 has been in full enforcement since 1 January 2026 and treats automated credit decisioning as a High Risk Processing Activity. Singapore's MAS expects credit and insurance models to be explainable enough for meaningful challenge and customer recourse. The HKMA issued guidance in March 2026 on alternative data in credit assessment. China's PIPL Article 24 gives a right to an explanation and to refuse a decision made solely by automated means. The labels differ; what they ask for converges on four things — transparency at the decision, a reconstructable explanation, a reachable human, and evidence that outlives the complaint window.

Is lending to companies in scope?

Not under 5(b), which covers the creditworthiness of natural persons. Business lending falls outside that point — though a system that profiles the individual directors, guarantors or sole traders behind an application may be evaluating natural persons in substance. The test is what the system assesses, not what the loan product is called.

Related Resources

• AI Underwriting Automation — what we build, how the phases run and what it costs to find out
• How AI Claims Processing Works — the same instrument from the claims side, where the answer is “not listed, but document it”
• AI for KYC and Identity Verification
• Document Data Capture Methods: Which to Choose
• How AI Document Processing Works
• Intelligent Document Processing services
• Case study: AI Identity Verification (−75% fraud)