AI solutions for insurance that triage the claim before an assessor opens it

The intake every general insurer wrestles with

A claim almost never arrives tidy. For a general insurer, first notice of loss comes in as an online form for one customer, a scanned PDF for another, a broker’s email with three attachments for a third, and a phone photo of a flooded kitchen for the next. Someone has to read all of it, work out what kind of claim it is, key the facts into the claims system, and check nothing important is missing before an assessor can do anything with it.

That reading and keying is slow, and it is where claims stall. A motor claim waits behind a complex liability matter because both sat in the same queue. A property claim bounces back to the customer twice because a required detail was missing and nobody noticed until day three. Each repeat request adds days, and the customer feels every one of them at the worst possible time.

The bar here is high, and it is not only about speed. General insurers work under the General Insurance Code of Practice and its expectations on timely, fair claims handling, under APRA prudential standards, and under the Privacy Act 1988 for the personal information a claim carries. Whatever reads the claim has to be accurate, has to keep that data controlled, and must not quietly start making decisions that belong to a person. A faster intake that gets facts wrong is worse than a slow one.

Why Azure OpenAI reads the claim, and where it runs

The job is to turn a messy claim into a clean, triaged file an assessor can pick up, without moving the insurer’s data outside its own walls. We headline these builds on Azure OpenAI Service because the work is genuinely a reading-and-reasoning task, not a fixed-template one, and Azure lets it run inside the insurer’s tenancy.

This is where a generative model earns its place over an older approach. Classic OCR plus a rules engine works when every claim arrives on the same form in the same layout. Real intake does not. The same claim type comes as a typed PDF, a photo, a forwarded email and a handwritten note, and a rules-only system breaks the moment the layout shifts or a field moves. Azure OpenAI reads the meaning across all those formats, pulls the date of loss, the policy number, the cause and the rest into structured fields, and classifies the claim regardless of how it was sent. OCR still has a role for the raw text on a scan. The model is what makes sense of it.

Two supporting pieces make it safe rather than just clever. Retrieval-augmented generation (RAG) grounds the completeness check in the insurer’s own product and policy rules, so the system knows which fields a given claim type actually requires and flags what is missing against the real rule, not a guess. Microsoft 365 is where much of the claim already lives, in the email and documents customers and brokers send, so the intake reads from the systems the insurer already runs. The whole pipeline sits inside the insurer’s Azure tenancy. Claim documents and the personal details in them are processed in the insurer’s own environment, not handed to a public consumer service, and are not used to train a shared model. That tenancy boundary is the reason this approach passes a privacy review rather than failing one.

Building it, and where it got hard

The model was rarely the hard part. The danger was subtler, and it is the one issue that matters most in claims. A model that fills in gaps.

Early in testing the extraction looked excellent, until we checked the fields nobody could actually see in the source. Where a date of loss was smudged or a sum insured was missing from the page, the model did not leave the field empty. It produced a confident, plausible value that simply was not in the document. In most settings that is a minor error. In a claim it is corrosive. A hallucinated date of loss or sum insured does not look wrong, it flows into the file, and an assessor can act on a fact that was never there. “Usually right” is the wrong standard when the file feeds a fair-claims decision.

The fix was to make the model honest about its own limits, not cleverer. We constrained it to extract only what is present and to return an explicit “not found” rather than a guess, so an absent field reads as absent. Completeness was grounded in the insurer’s real product rules through RAG, so the system checks a claim against the rule that actually applies rather than the model’s memory of one. Every extracted field carries a confidence score, and anything below threshold, or any “not found” on a required field, routes to a person instead of passing silently. And the line stays bright. The system extracts and triages. It never decides cover or liability. An assessor does. That keeps a human in the loop on every judgement that matters and keeps the build on the right side of fair-claims-handling expectations.

One more constraint shaped the rest. Because claim documents are full of personal information, processing stays within the insurer’s tenancy, access is logged, and retention is set to match the insurer’s existing obligations under the Privacy Act 1988. None of that is glamorous. All of it is the difference between an intake assistant a claims team trusts and one risk quietly switches off.

What changed

In a representative deployment the time from a claim landing to a clean, fields-extracted, triaged file fell from hours of manual reading and keying to minutes, with the assessor still opening the file and deciding cover. Checking completeness against the product rules at intake caught missing details earlier, which cut the repeat requests back to the customer that usually stretch a claim out. Classifying claim type and urgency on arrival meant simple claims stopped queuing behind complex ones, so each file landed in the right place from the start.

These figures are illustrative. They describe the pattern we see rather than a published result for a named insurer. The shape is the point. The slow, manual reading comes off the assessor’s desk, missing information surfaces on day one instead of day three, and the people who decide claims spend their time on the deciding, not the keying.

Where this fits

Claims intake is one application of our Artificial Intelligence service, built on Azure OpenAI Service, for general insurers. It is a contained, high-return starting point, because the work is repetitive, the documents already exist, and the value comes from reading them accurately and triaging the file without ever crossing into the cover decision. If first notice of loss is where your claims stall, the place to start is to map the documents a claim arrives as and decide which facts a model may extract and where an assessor must stay in the loop.