Claims in 24 Hours, Conformity Assessment by August: The Two Deadlines Insurance Engineering Teams Are Running Against

Two Programmes, One Engineering Team

Every European insurer is currently running two AI programmes whether or not they are named that way. The first is the value programme: automate claims triage, compress underwriting, catch more fraud, reduce loss adjustment expense. It has an executive sponsor, a budget and a business case, and by 2026 it has genuine results behind it rather than pilots.

The second is the compliance programme, and in most organisations it is a document. It lives with legal or risk, it consists of an inventory spreadsheet and a policy, and it has not been translated into engineering work with an owner and a delivery date. That gap is the actual risk, because nearly every obligation the EU AI Act imposes on a high-risk system is satisfied — or not — in the codebase.

The insurers who will be fine in twelve months are the ones treating these as a single programme with a single architecture, because the requirements are not in tension. Logging every inference with its inputs, model version and outcome is a compliance obligation and also the only way to debug a model that starts declining claims it used to accept. Human oversight is a regulatory requirement and also the mechanism that stops a silent model regression from becoming ten thousand wrong decisions. Documentation of training data and performance is an audit artefact and also what lets you answer, six months later, why the loss ratio moved.

Treated separately, the compliance work looks like pure cost and gets deferred. Treated as one, most of it is engineering you should be doing anyway — which is the argument that actually gets it funded.

What the Automation Numbers Actually Say

It is worth being precise about the value side, because the published figures are unusually strong and unusually easy to misread.

Analyses of AI in insurance underwriting and claims report claims resolving 75% faster with 30-40% cost reductions, underwriting timelines falling from three days to three minutes, straight-through processing rates rising from 10-15% to 70-90%, and fraud detection improving by more than 30%. Roughly 60-70% of motor claims are considered suitable for automation, and straightforward claims can settle in under 24 hours. The insurtech market is projected around $23.5 billion in 2026, and the capital has shifted from customer-facing propositions toward the underlying claims and underwriting infrastructure.

The misreading is to treat these as achievable across the book. They are achievable on the segment of the book that is genuinely simple — a low-value motor claim with clear liability, complete documentation and no injury component. Extending automation past that segment is where insurers get into trouble, because the marginal claim is harder than the average one, and a model tuned on straightforward claims performs worst exactly where the financial exposure is greatest.

The engineering consequence is that the valuable architecture is not the model. It is the routing layer: the classifier that decides, with a calibrated confidence estimate, whether this claim belongs in the automated path or in front of a human. That component determines both your loss ratio and your regulatory exposure, and it is systematically under-invested relative to the model that gets the attention. An insurer with a mediocre claims model and an excellent router outperforms the reverse on every metric that matters.

High-Risk Is Not a Label, It Is a Build Specification

The EU AI Act classifies AI systems used for risk assessment and pricing in life and health insurance as high-risk. That classification is where the engineering work starts.

Analysis of the Act's application to insurance sets out obligations that translate directly into system requirements: a risk management system operating across the lifecycle, data governance covering training and validation sets, technical documentation sufficient for a conformity assessment, automatic logging of events, transparency toward deployers, human oversight designed into the system, and appropriate accuracy, robustness and cybersecurity. Insurers deploying such systems must be prepared for comprehensive compliance by August 2026, with penalties reaching 7% of global annual turnover for prohibited practices, 3% for other obligation breaches and 1.5% for supplying incorrect information.

Read as engineering requirements, these are concrete. Automatic logging means every inference persists its inputs, model version, output, confidence and the identity of any human who reviewed it — retained for the period the Act requires, which is longer than your default log retention. Human oversight means a defined intervention point where a person can inspect and override with the information needed to do so meaningfully, which rules out an interface showing only a score. Data governance means you can state what a model was trained on, when, and what checks were run for bias in protected characteristics — including proxies, which in insurance data are everywhere. Accuracy and robustness mean documented performance thresholds and a monitored drift signal, not a validation run performed once at launch.

None of that is exotic. All of it is invasive if retrofitted, because logging schemas, model registries and override workflows are the kind of thing that has to be designed into a pipeline rather than bolted onto one. That is the real deadline pressure — not the legal analysis, which is largely done in most insurers, but the engineering lead time between a finished legal analysis and a system that actually produces the required evidence.

The Legacy Estate Is the Constraint

Any discussion of insurance AI that skips the policy administration system is a discussion about a demo rather than a deployment.

The characteristic European insurer runs a core system that is fifteen to thirty years old, holds the authoritative record of policies, claims and financial postings, and cannot be replaced on any timescale relevant to an AI programme. It exposes data through batch extracts, a partial and undocumented API surface, or a database view somebody created in 2011. It has no event stream. It has business rules encoded in stored procedures nobody has read this decade.

Every AI claims initiative eventually collides with this, and the collision produces one of three architectures. The first is batch integration, which is cheap and gives you overnight decisions, defeating the entire point of 24-hour settlement. The second is direct database access, which is fast to build and creates a coupling that will break on the next core upgrade while quietly bypassing whatever business logic the core applies. The third — an integration layer that publishes domain events from the core and exposes a stable read model to downstream services — is the only one that survives, and it is a real engineering project measured in quarters rather than sprints.

The mistake worth naming is sequencing. Insurers routinely fund the model first and the integration afterwards, because the model demonstrates well and the integration does not. The result is a pilot that works on extracted CSVs and cannot be deployed, followed by an eighteen-month integration project that the AI budget was never sized for. The right order is unpopular and correct: build the event and read-model layer first, prove it with a simple non-AI use case, then put models on top of infrastructure that already works.

This is also where the compliance and value programmes converge most usefully. The same integration layer that lets a model see a claim in real time is the layer that captures the audit record of what it saw, which version decided, and who reviewed it. Built once, it serves both.

The Human Oversight Problem Is a Product Design Problem

Human oversight sounds like a governance clause and is in practice one of the harder interface problems in the entire system.

Oversight fails in two directions and both are common. Rubber-stamping is the first: a reviewer presented with a recommendation and a confidence score approves it, because the system is right most of the time and the queue is long. This satisfies the letter of a human-in-the-loop requirement and provides no actual oversight, and it is what you get by default when the interface shows a decision rather than its basis. The second is overload: escalating so much that the human path becomes the bottleneck, which destroys the business case and leads, within two quarters, to raising the automation threshold without re-examining whether the model earned it.

The design that works gives the reviewer what they need to disagree efficiently. Show the specific evidence that drove the decision — the policy clauses matched, the prior claims considered, the document fields extracted and their extraction confidence. Show comparable historical decisions and their outcomes. Make disagreement cheap and structured: when a reviewer overrides, capture the reason in a controlled vocabulary, because that dataset is simultaneously your model improvement pipeline and your regulatory evidence that oversight is real.

Then instrument the oversight itself. Override rate by segment, time spent per review, and the accuracy of overrides where ground truth eventually arrives. An override rate near zero does not mean the model is excellent; it usually means the reviewers have stopped reviewing. That metric is the single most informative number in the whole system and it is almost never on a dashboard.

What This Means for How You Staff It

The capability profile this work requires is unusual, and it is the reason so many insurance AI programmes stall between pilot and production.

You need people who can hold three things at once: the insurance domain, so they know that an endorsement mid-term changes the exposure and that reserve movements are not corrections; the machine learning, so the model is calibrated rather than merely accurate; and the systems engineering, because the hard part is the integration layer against a thirty-year-old core, not the model. Insurers can usually staff any two of those internally. The third is where programmes go looking outside.

The work also has a shape that fits poorly with permanent hiring. Building an event and read-model layer over a legacy policy administration system, standing up model registries and inference logging that satisfy the Act, designing an override workflow and its evidence capture — this is a defined project of six to twelve months with a clear endpoint, followed by a much smaller steady state. Hiring permanently for the peak leaves you overstaffed afterwards; hiring nobody leaves the roadmap permanently blocked behind it.

At StepTo we have run senior engineering teams out of Serbia since 2014, and insurance technology engagements have shifted noticeably over the past two years — away from portal and customer-facing work and toward exactly this layer: integration against legacy cores, inference logging and model registries built to withstand an audit, and the routing and oversight components that decide which claims a human sees. Engineers are assigned by name and stay with the system, which matters more here than in most domains, because the expensive knowledge is understanding why a particular insurer's claims data behaves the way it does, and that takes months to acquire and one rotation to lose.

For insurers who want the capability retained internally afterwards, the structure that works is a dedicated development team with knowledge transfer written into the scope rather than promised at the end. For teams that already have the domain and the models and need systems capacity, staff augmentation against named senior engineers closes the gap faster.

A Sequenced Plan for the Next Two Quarters

If you are behind on either programme, this is the order that works, and it is deliberately unambitious about the model.

First, inventory and classify. Every AI or automated decision system in the estate, what it decides, whether it falls in a high-risk category, and who owns it. Include the systems nobody calls AI — a scoring rule someone built in a spreadsheet and productionised in 2019 may fall in scope on function rather than on technique. Most insurers discover two or three systems in this step that nobody had on the list.

Second, close the evidence gap on what is already live. For each in-scope system: is every inference logged with inputs, model version and outcome? Is there a defined human intervention point with adequate information? Can you produce documentation of training data and validation performance? Is drift monitored with a threshold that triggers something? The systems already in production are the exposure, and they are usually the ones with the weakest instrumentation because they were built before anyone was asking.

Third, build the integration and evidence layer before the next model. Domain events from the core, a stable read model, an inference log that is an auditable record rather than an application log, and a model registry with versioning and approval. Prove it with one simple use case. This is the step that gets skipped and the step that determines whether anything reaches production.

Fourth, then extend automation — and extend it by segment with explicit confidence thresholds, monitored override rates and a documented rollback path, rather than by raising a global threshold because the numbers looked good last quarter. The insurers who move fastest over the next three years will not be the ones with the best models. They will be the ones who built the layer that lets them deploy a model on Tuesday and prove on Wednesday exactly what it did.