In a motor claim, most of the time goes not into making a decision but into getting the file to a state where a decision can be made. The policyholder describes the incident in two sentences over a messaging app, the date is missing, the other vehicle's plate isn't there, and the accident report arrives three days later. When the claims handler opens the file, a large part of the job is chasing what's missing.
Generative AI is genuinely useful for this preparation work. But "let's put AI into claims" says very little on its own. The level of risk differs at every step of the process, so the role AI can take differs too. In this article we walk through the claims process step by step: what can be handed over, and what should stay with the expert.
The core principle: preparation by the machine, decisions by people
Accepting from the start that AI can be wrong simplifies the design. A wrong field extraction takes an expert seconds to fix; a wrong rejection turns into a complaint, reputational damage and regulatory risk. So it makes sense to draw the line like this:
- Can be handed over: extracting information from text, spotting gaps, classifying documents, flagging inconsistencies, suggesting priority.
- Can support, cannot decide: coverage pre-checks, payment amount suggestions, suspicious-file flags.
- Authorised person only: rejection, payment approval, recovery and litigation decisions.
This boundary should be written into the system itself. A workflow in which only an authorised user can reject or approve payment, and only with a written reason, removes the possibility that "the model made a decision by mistake".
1. Intake: from free text to a structured file
Claims now mostly arrive as free text: a message, an email, the description box on a web form. Language models are good at extracting the incident type, date, location, whether a third party was involved and whether anyone was injured. Two things matter here:
- Force the output into a schema. The model shouldn't answer freely; every field needs a defined type and allowed values. An answer that doesn't fit the schema is rejected and requested again.
- Don't leave policy matching to the model. Matching by policy number, plate or national ID is a deterministic query. The model's job is to read text, not to search the database.
2. Missing information: targeted questions, limited rounds
If a mandatory field is missing, the system can ask the policyholder a targeted question instead of a generic "please complete your details": "What time did it happen?", "Do you know the other vehicle's plate?" That alone reduces back-and-forth.
But the loop shouldn't be endless. A file that isn't complete after two or three rounds should go to a human. A policyholder stuck in a long exchange with a machine is a worse outcome than an incomplete file.
3. Prioritisation: never missing an injury
A file involving injury or death shouldn't wait in the same queue as a cracked windscreen. The model usually catches injury information in the text, but "usually" isn't good enough here. A rule-based second check (phrases such as "injured", "ambulance", "hospital") catches what the model misses and moves the file into a human-priority queue. In this case false positives are cheap and false negatives are expensive; the design should reflect that.
4. Document assistant: list, classify, cross-check
A collision claim and a hail claim don't need the same documents. Automatically generating the required document list for the claim type and sending it to the policyholder in one go is a simple but effective step. Conditions such as extra documents when there's an injury can be defined as rules.
When documents arrive, AI does two things:
- Classification: is the upload a registration certificate, a driving licence or an accident report? If the wrong document was uploaded, the policyholder is told immediately.
- Cross-checking: do the plate and chassis number on the registration match the policy and the accident report? Is the date within the policy period?
A mismatch is a finding, not a decision. The system says "the plate doesn't match"; the expert decides whether it's a typo or something to investigate.
5. Coverage pre-check and payment suggestion
By reading policy terms and add-on covers, the system can produce a first answer to "does this incident look covered?". A payment suggestion can also be calculated from the expert report and the parts-and-labour lines. These steps speed up the handler's work, but their output should always be presented as a reasoned suggestion: which clause and which document led to the conclusion should be visible.
Make every suggestion traceable
In an AI-assisted claims process, auditability isn't a feature to bolt on later. At a minimum, record:
- which model and which prompt version produced each suggestion,
- whether the handler accepted, rejected or corrected it,
- who changed the file's status, and when.
This record does two jobs: when a dispute comes in, you can show what happened; and by measuring which suggestions are actually accepted, you can improve the system.
Rules belong in configuration, not in code
Which fields are mandatory, which questions are asked and which documents each claim type requires vary from insurer to insurer, and even between agencies. Hard-coding them means a software release for every change. Versioned rule sets let the operations team change the process themselves, and also record which rule version each file was processed under.
How to measure it
Whether AI "worked" should be answered with a few numbers, not a feeling. For a pilot, these three are a good start:
- handler time per file,
- the number of times the policyholder is contacted again because of missing documents or details,
- the acceptance rate of AI suggestions, per field.
Keep the pilot small: one line of business, one claim type, a few dozen anonymised historical files. Don't expand the scope until the results are clear.
Conclusion
AI is most valuable in claims when it puts a well-prepared file in front of the expert. Structuring the notice, asking for what's missing, checking documents and setting priority can be handed over safely. Rejection and payment decisions should stay with people, together with their reasons. A system that draws this line correctly from day one runs faster and holds up better under audit.