Interview with Anton Solomonov
An insurance loss almost never begins with a clean row in a database. It begins with human disorientation. A car accident. A flooded apartment. A missing shipment. A warehouse fire. And almost immediately after the event itself, a second, equally exhausting ordeal begins: proving that it actually happened, gathering paperwork, reconstructing a timeline, making sure nothing is forgotten or mixed up.
This is how the ritual familiar to every insurer and policyholder takes shape: photographs, receipts, bank statements, forms, incident descriptions, contact details, sometimes certificates, inspection reports, expert conclusions, proof of ownership. In a routine case, it is already tedious. After a major accident, a natural disaster, or a chain of related incidents, the process starts to feel like archaeology — facts have to be pieced together from scraps of paper, digital traces, and scattered testimony. Insurance, in this sense, has always been about more than money and risk. It has always been about evidence. For an event to become a covered claim, it is not enough to have lived through it. It has to be turned into a formalized case on which a decision can be made.
The industry’s history is full of stories where the document and its verification mattered as much as the incident itself. Sometimes the error was made in good faith. Sometimes it was deliberate. One of the darkest and most memorable examples is the case of Jack Gilbert Graham. In 1955, he placed a bomb on the plane his mother was traveling on, partly counting on the insurance payout. The story has long been a fixture of true crime, but it matters to the insurance industry for a different reason as well: it shows just how much an insurance decision can depend on the accuracy of fact-checking — on verifying documents, uncovering motives hidden behind what looks like an ordinary claim. Stories like this stick because they strip insurance of its abstraction, of its world of policies and actuarial tables, and bring it back to what it has always been — an attempt to separate a real event from a mistake, a manipulation, or a fraud.
AI in insurance today is interesting for the same reason — not as a fashionable technology accessory, but as a continuation of an old professional ambition: learning to quickly and accurately turn a chaos of paperwork into something structured, comparable, and verifiable. Not replacing the expert, but giving them support in the places where the volume of information has grown too large for purely manual review.
The scale of the problem is especially visible now. An insurance claim is rarely simple or linear. More often, it is not a single record in a system but a mosaic of PDFs, scans, photographs, emails, operator comments, and attached certificates. Each document adds only a small fragment to the full picture. One clarifies the date, another the address, a third the list of damages, a fourth contradicts the first three. When there are only a handful of cases, the problem can still be held at the level of human attention. When there are tens of thousands a day, the human starts losing — not to complexity, but to volume.
At the company where we built this pipeline, the incoming flow reached 28,000+ claims per day — more than 10.2 million claims per year. Even if only 3–10% of those submissions contain fraud indicators and get routed to additional review, that is already an enormous volume of cases requiring closer examination. In certain high-risk segments, the share could climb to 10–15% or higher. And the challenge was not only catching potential fraud. It was equally important not to make the opposite mistake — not to deny a claim where the customer was actually right. The numbers there are telling too: among externally disputed cases, the customer turned out to be right roughly 30–40% of the time. All quantitative figures cited in this article are drawn from the company’s financial reports for the previous year.
This is where the role of the data engineer becomes genuinely visible. From the outside, it can look almost invisible: ingest files, put them in storage, make data available. But in practice, this is where it gets decided whether the document stream stays a passive archive of attachments or becomes a system that helps make better decisions. The job has long since outgrown simply storing files. The data engineer builds the pipeline in which AI helps pull together all documents for a claim into a single digital case history, extract entities, cross-reference facts, and turn scattered materials into a structured dataset ready for analysis, routing, and oversight.
When we were designing this system, one of the first surprises was that documents looked far neater on the architecture diagram than they ever did in real life. On paper, it was a uniform stream of PDFs and scans. In production, it was several fundamentally different worlds. Clean digital PDFs generated by source systems behaved predictably: text was extracted reliably, fields came through consistently, and downstream processing quality was high. But the moment phone-photographed scans entered the flow, everything changed. Glare, skewed angles, crumpled pages, uneven lighting, hand shadows, unwanted background around the page — all of it made a document that was perfectly readable to a human eye far more difficult for a machine to handle.
That is the moment when it becomes clear: a good-looking AI project is easy to build in a demo environment and very hard to build in a live operational process. Running the entire stream through a single scenario was pointless — that much became obvious fairly quickly. The issue was not OCR itself, but the fact that distorted material was being fed into the downstream steps of the pipeline. So we added a dedicated routing layer before entity extraction. The system first classified the document type and assessed image quality, then directed the file either to a standard OCR path or to a heavier branch with image preprocessing, additional normalization, and stricter confidence score validation. It might look like a minor technical detail from the outside. In practice, decisions like this are exactly what separates a polished AI demo from a production system you can actually trust with a stream of insurance claims.
After that, the AI shifted from recognition to semantic annotation. The model extracted the entities that actually matter to the business: policy number, customer name, incident date, type of insurance event, address, damage description, parties involved, references to related documents. This is a meaningful shift in perspective. Before this point, the system had files. After it, a set of attributes that can be compared, validated, aggregated, and used in downstream processes.
From there, the case needed not just to be “read” but to be understood — specifically, what to do with it next. Based on the claim text and the extracted entities, the system assigned it to a category: vehicle accident, flood, property damage, theft, personal injury, and so on. For an insurance company, this classification is not a decorative label. It determines the processing route, the applicable validation rules, expected response times, and which specialists need to be brought in. What turned out to be most useful was not that the system classified automatically, but that it did so with a measurable degree of confidence.
The right boundary between automatic extraction and cases that need to go to manual review matters more than maximum automation at any cost — we figured that out fairly quickly. That is why confidence scores and quality flags appeared alongside every output. The system did not just say “I see a policy number here” or “this looks like a flood claim” — it showed how certain it was of that conclusion. For operational teams, this turned out to be critical for trust. The hardest part was not extracting a field from a document. It was making the result explainable to a claims adjuster — something they could use in their workflow without feeling like the decision came out of a black box.
At this point, documents started “talking” to each other for the first time. A single file rarely tells the whole story of a case. But when comparable entities are extracted from a dozen different documents, something new becomes possible: seeing not a collection of attachments, but a coherent structure of an event. The incident date from the claim gets cross-referenced against the date in an attached report. The address from the form is checked against the address on the repair invoice. The damage description is compared against the operator’s comment or the contents of an exhibit. Gradually, out of disconnected files, a digital history of the insurance case assembles itself.
After that, a document stops being just a file for good. The extracted attributes, entities, and classification results are written into a structured lakehouse layer — and this is, arguably, where the most interesting part begins. The case becomes an analytical object. You can build dashboards for SLA monitoring, see exactly where processing stalls, which document types most often require manual review, which segments most frequently get flagged for additional scrutiny, where recurring fraud patterns emerge. For the anti-fraud function, this means more precise risk detection: the system is analyzing not a single suspicious document but the full body of materials for a case. For the customer experience, the effect is just as real: the rate of wrongful denials drops, because the final decision depends less on human fatigue, inattentiveness, or the accident of which document happened to land in front of a specialist first.
Seen through a customer’s eyes, an insurance document is just a piece of paper to find urgently, fill out, and send off. Seen through the eyes of a data engineer, it is a container holding hidden entities, events, signals of contradiction, and risk indicators. Inside it can be an incident date, a policy number, a damage description, the roles of parties involved, hints of inconsistency, and early markers of potential fraud. The problem is that for decades, all of this was extracted slowly, by hand, and with inevitable loss of quality.
AI-powered document ingestion matters not because it “replaces humans,” but because it is the first approach that makes high-volume document processing engineeringly manageable. A file arrives in the raw layer, passes through OCR, routing, classification, entity extraction, and confidence scoring, and becomes a structured object that can be tracked through lineage, quality flags, and SLA dashboards. The future of insurance document processing is not full automation at any price — it is the combination of automatic extraction, risk scoring, and human-in-the-loop review.
The most interesting thing about this story is not speed. It is that AI gives the document back its original function: not a bureaucratic burden to endure, but a machine-readable record of something that actually happened. In other words, a lakehouse with AI enrichment turns an archive of insurance paperwork from a passive repository into a working mechanism of trust, speed, and control.
