HasarAI is a motor claims assistant we built for insurers and agencies. Its purpose in one sentence: to put a review-ready file in front of the claims handler. Rather than a product tour, this article describes the decisions we made while designing it and why. We think they'll be useful to teams asking the same questions about their own process.

The problem: preparing the file takes longer than deciding

In a motor claim, the handler's real job is to assess cover and damage. But the file usually starts with a series of gaps: the notice arrives as free text, the date or location is unclear, documents arrive piecemeal and sometimes wrong, and the plate on the registration doesn't match the one on the policy. This preparation work is repetitive, rule-based and mostly about reading text, which is exactly what language models are good at.

Design principle: preparation by AI, decisions by the expert

The first and most important decision was what the system would not do. HasarAI never rejects a claim or approves a payment. A file moves through Notice → Awaiting documents → Under review → With assessor → Awaiting approval → Payment approved → Closed; rejection and payment approval are steps only an authorised person can take, with a written reason. That boundary isn't a setting; it's built into the workflow.

1. Intake: schema-constrained extraction

The incident type, date, location, third party and injury information are extracted from the policyholder's free text. The model's answer must fit a defined schema; if it doesn't, it's rejected and requested again. Policy matching isn't left to the model: it's an ordinary query by policy number, plate or national ID.

2. Missing information: three rounds at most

If a mandatory field is missing, the policyholder gets a question about that field. But we capped the loop: a file that isn't complete after three rounds goes to a handler. An incomplete file reaching an expert is better than a policyholder stuck in a long exchange with a machine.

3. Injury: trust the model, back it with a rule

Moving injury claims to the front is critical. The model usually catches this information; a rule-based second check covers the cases it misses. If either sees an injury, the file drops into the "human priority" queue. When there's an injury, extra documents (such as an alcohol test report) are added to the document list automatically.

4. Document assistant: convert to text, then compare

The documents required for the claim type are listed. Uploaded PDFs and photos aren't sent to the model as images: they're first converted to text and masked on the server, then classified. Plate and chassis details on the registration, the accident report and the policy are compared. A mismatch is shown to the handler as a finding; the handler decides what it means.

5. Privacy: masking and cross-border use off by default

National ID, phone, IBAN and email are masked in a rule-based layer before text reaches the model. Claim text and personal fields are stored encrypted. Use of AI services hosted abroad starts disabled per insurer. We covered this in detail in Generative AI in Insurance and Data Privacy.

6. Traceability

Every AI suggestion is stored with the model and prompt version that produced it. Whether the handler accepted, rejected or corrected it is measured. Every status change is written to an audit log that can't be altered. That makes it possible to show what happened in a dispute, and to see which suggestions actually help.

7. The rules belong to the customer

Mandatory fields, follow-up questions and the documents required for each claim type aren't hard-coded. They're changed through versioned rule sets per insurer and agency. The system is multi-tenant: each insurer's and agency's data is kept separate, and that separation is verified by tests. Hosting in Turkey and working with the customer's own storage are part of the design.

Why does the demo run in the browser?

The HasarAI demo (interface in Turkish) runs entirely in the browser on synthetic data; nothing is sent to a server. Visitors can pick one of three scenarios (a collision with injury, a hail claim with missing details, a glass claim with a plate mismatch) or type their own text to see masking at work. Masking and injury detection run on the real rules in the demo; field extraction goes to the product's AI model, so it's only shown for the prepared scenarios.

What's next: HasarAI Verify

The second module we're building is a second pair of eyes on vehicle assessment reports. Verify will check mandatory fields, totals, date consistency, part-to-photo matching and deviations from reference labour and parts prices, then produce a compliance score and an itemised findings report. Here too, suspicious signs are presented only as findings; the decision stays with people.

Lessons from this project

  • Draw the line first. What AI won't do is a more important design decision than what it will.
  • Don't leave critical signals to a single model. For something like injury, a rule-based second check is cheap and effective.
  • Privacy is solved in the architecture. Masking and local OCR make the legal conversation much easier.
  • You can't improve what you don't measure. Suggestion acceptance rate is the most honest indicator of whether the system really helps.