Industry

Insurance AI.
A person still signs.

Claims triage, document extraction, underwriting support and fraud detection. An insurance decision moves a policyholder’s money, so the system’s job is to assemble the file and the trace — and a named human disposes of the decision.

Last reviewed 5 September 2026 · Engineering guidance, not legal advice.

WHERE IT BREAKS TODAY

The file arrives as paper

First notification of loss comes in by email, portal and telephone note, followed by photographs, engineer reports, invoices, medical summaries, schedules and correspondence. Almost none of it reaches a system in a form the system can reason about.

Triage runs on queue order

Without a reliable read of severity, complexity and completeness, files are worked in the order they arrived. Simple claims wait behind complex ones, and the complex ones are discovered late, which is where leakage and complaints come from.

The reasoning is hard to reconstruct

Six months later, a complaint, an ombudsman referral or a supervisory question asks why this decision was made on this file. If the answer lives in a spreadsheet, a mailbox and a handler’s memory, the answer does not exist.

OUR APPROACH

The model assembles. A person disposes.

Every insurance system we build starts from the same distinction. Reading a hundred pages of a claim file, pulling out the policy number, the date of loss, the excess, the schedule limits and the three sentences in the engineer’s report that decide liability — that is assembly, and a model does it faster than a person and does not get bored on the eightieth file. Deciding whether the claim is paid is disposal, and it stays with a named handler who can be asked why.

That distinction is not a philosophical position, it is an architectural one. It determines what the system is allowed to write, what it may only propose, and what it must attach. Every extracted field carries a citation to the page and the line it came from, so the handler is checking a claim rather than trusting a summary. Every proposed action is logged with the identity that released it. Nothing about this makes the model correct; it makes the model’s errors visible to the person accountable for them, in the seconds before they matter.

The same shape holds in underwriting. A submission is read, normalised against your appetite and exposure rules, and presented with the gaps and the contradictions surfaced rather than smoothed over. The referral is drafted; the risk is priced by your pricing function and accepted by your underwriter.

HOW IT DEPLOYS

PHASE 01

Map the decision

We take one line of business and write down who decides what, on what evidence, under what authority limit. That map is what separates assembly from disposal, and it is usually the first time it has been written down in one place.

PHASE 02

Build the evidence layer

Extraction, normalisation and retrieval run inside your perimeter against your policy administration and claims systems. Output is structured, cited and validated before a handler ever sees it.

PHASE 03

Instrument, then review

An evaluation set built from your own historic files measures the system on the cases it will actually meet, including the awkward ones. It runs before launch and keeps running after it.

WHAT WE BUILD

Claims Intake and Triage

Multimodal extraction over the whole claim file — photographs, scanned reports, faxed forms, spreadsheets — with typed exception queues for what cannot be read, and a severity and completeness score that decides routing rather than arrival order.

SEE THE DOCUMENT PIPELINE →

Underwriting Support

Retrieval over submissions, wordings, endorsements and your own appetite guidance, so a referral arrives with the relevant clause quoted and linked rather than paraphrased. The system finds and cites; it does not price.

SEE RAG SYSTEMS →

Fraud and Financial-Crime Triage

Alerts are assembled into a structured case — network context, prior claims, inconsistencies between documents — for an investigator to work. A model that flags is a model that must be evaluated on its false positives, and we build the harness that does it.

SEE RISK AGENTS →

Customer Operations

Policy questions, document requests and claim-status enquiries answered from your own systems with citations, with anything touching vulnerability, distress, a complaint or a coverage dispute routed to a person immediately and with the full conversation attached.

SEE SUPPORT AGENTS →

THE REGULATORY SHAPE

Insurance is one of the few sectors where the regulatory question is not a governance afterthought but a design input, and three regimes shape the architecture before any code is written. What follows is how we build against them. Whether a given system falls inside any of them is a determination for your compliance and legal functions, not for us.

The EU AI Act. Annex III lists AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance among its high-risk categories. If a system you are commissioning sits there, the obligations that follow are engineering obligations as much as paperwork ones: a risk management process, data governance covering the training and evaluation sets, automatic logging over the system’s lifetime, technical documentation, human oversight designed in rather than asserted, and demonstrated accuracy and robustness. Our part is to build a system where each of those can be evidenced from artefacts that already exist — the evaluation harness, the trace log, the architecture document — rather than reconstructed for an audit. The EU AI Act page sets out the timeline and the classification questions in full.

GDPR Article 22. A decision based solely on automated processing which produces legal effects or similarly significantly affects a person carries specific restrictions and rights. Declining cover, setting a premium, or repudiating a claim is capable of being exactly that. The engineering consequence is that human involvement has to be real: the reviewer needs the authority to reach a different answer, the information required to reach it, and the time to use both. A screen that shows a recommendation and an approve button is not oversight, it is a rubber stamp with an audit trail. We design the review step so the evidence arrives before the recommendation does.

Discrimination through proxies. A model does not need a protected characteristic in its inputs to price on one. Postcode, vehicle model, occupation history, device and payment pattern all carry correlations, and a system fitted on historic outcomes will reproduce whatever was in those outcomes. The controls are unglamorous: keep the feature set documented and deliberate, test outcomes across groups where you lawfully can, record what was tested and what was found, and keep a person able to override. None of this removes the exposure. It makes it measurable, which is the difference between a finding you can answer and one you cannot.

CONTROLS WE IMPLEMENT

GDPR-ALIGNED CONTROLS PII INSIDE YOUR PERIMETER REPLAYABLE AUDIT TRAIL FOUR-EYES ON MATERIAL DECISIONS NO TRAINING ON YOUR DATA CITATION ON EVERY EXTRACTED FIELD

These are engineering controls we build into the architecture, not certifications. QQuantum.ai holds no security certifications, and the audits, attestations and regulatory permissions your sector requires remain yours — see our trust centre.

DESIGN TARGETS

DECISIONS RELEASED WITHOUT A NAMED HUMAN

CITATION PER EXTRACTED FIELD

100%

OF DECISIONS REPLAYABLE FROM TRACE

Properties we design and build to, not measured client outcomes.

QUESTIONS

QUESTIONS — 5

It can prepare one, and in our architectures that is what it does. The system reads the file, extracts and cites the facts, checks them against the policy wording and the schedule, flags the contradictions and drafts the recommendation. A named handler releases it. That boundary exists partly because GDPR Article 22 restricts decisions based solely on automated processing where they significantly affect a person, and partly because a model will occasionally be confidently wrong about a document, and the cheapest place to catch that is before the decision leaves the building.

It may be. Annex III lists AI systems intended for risk assessment and pricing in relation to natural persons in life and health insurance among the high-risk categories, and the classification of your specific system is a determination for your compliance function rather than for us. What we can say is what changes if the answer is yes: logging over the system lifetime, documented data governance for the training and evaluation sets, technical documentation, demonstrated accuracy and robustness, and human oversight that is designed rather than asserted. We build so those artefacts are produced as a by-product of the engineering instead of assembled retrospectively.

We do not claim to remove the exposure, because no architecture can. What we do is make it visible. The feature set is documented and deliberate rather than inherited; outcomes are tested across groups where testing is lawful and the test is recorded with its result; the system explains a decision in terms that can be reviewed by a person; and an underwriter can override with the override logged. A vendor who tells you their model is free of proxy discrimination has not measured it.

In the ordinary case, nowhere. The system runs in your own cloud accounts against your own claims and policy stores, and we hold no copy. Where a hosted model is used, we record the provider’s retention and training terms in the architecture document at the time of writing, and you should confirm them against the provider’s current terms before relying on them. Where no third party may see the data at all, an open-weight model on your own infrastructure is the design, and we will say plainly what that costs in capability.

No — none. We are a small engineering firm and we do not sell assurance. What we produce is the evidence your own audit needs: an architecture document, a trace log, an evaluation harness with its method written down, and access scoped by role. If your procurement process requires a certified supplier for this scope, we will tell you early rather than late.

Keep reading

AI for Financial Services

→

30-minute technical call · no deck