Data Readiness Comes Before the Model

Carriers Argue About Models Too Early

They debate open versus closed, cheap versus frontier, build versus buy, before they can answer a simpler question: is the data ready for the work we want AI to support?

In insurance, AI value is decided before a model is selected. It is decided in policy data, claims files, billing history, vendor feeds, communication logs, and CAT event records. Specifically, in whether those sources are complete enough, governed enough, and connected enough to support a controlled use case.

If the data is messy, siloed, or legally unclear, the model will sound certain about incomplete context. That is when automation bias becomes expensive, because a confident answer built on a partial file gets treated like a verified one.

The Model Is Not the Bottleneck You Think It Is

Most failed AI pilots I have seen did not fail because the model was weak. They failed because the organization asked a model to operate on incomplete context, undefined ownership, or data that was never built for machine use.

A claims file is not a clean training set. It is a living record of people, documents, exceptions, and judgment under pressure. Policy data may live in one system, payments in another, vendor notes in email, and CAT surge assignments in a spreadsheet that only three people trust.

Here is where that shows up on a real file. An adjuster’s note says “covered per call with PM.” The policy system has no record of that call. Now the model has two contradictory truths sitting in the same claim and no way to know which piece of human judgment to trust. A person with the right authority, the right context, and enough time can resolve that. A model reading both fields at once will just pick one and sound sure about it.

When leaders skip that reality, they buy a model to paper over an integration and governance problem. The demo looks fine on curated samples. Production meets the real file.

What Data Readiness Means in Insurance

Data readiness is not “we have a warehouse.” It is an operating condition across the domains that touch a policyholder journey — the same domains most data classification policies already try to define and most system inventories already try to map.

• Policy data: terms, endorsements, effective dates, and the exceptions that change coverage interpretation.
• Claims data: FNOL facts, investigation notes, estimates, reserves history, photos, and the gaps adjusters already know about.
• Billing and payment data: what was owed, what was paid, what is disputed, and what finance will ask for in a reconciliation.
• Vendor data: who did what, when, under which authorization, with what quality trail.
• Communication data: customer contact timing, channel, and content that will matter if the file turns into a complaint.
• CAT data: surge assignments, capacity, event coding, and the temporary workarounds that appear every season and somehow become permanent.

If you cannot describe how those sources relate for one workflow, you are not ready to put a model in the middle of that workflow. QA findings, SIU referrals, and finance reconciliations usually already know where the known defects live. That is a good place to look before you start building.

PII and Permissions Are Part of Readiness

"Claims AI that cannot explain its data boundary is not advanced. It is a compliance incident waiting for a date."

Decide what personally identifiable information can enter a model path, what must be redacted, what can be logged, who can see prompts and outputs, and how long artifacts live under your retention rules. Write it down. Have Legal and Security sign it. Then design the use case inside that fence, with an audit trail that shows what happened and who reviewed it.

This is slower than a vendor proof of concept. It is also the difference between a pilot you can defend and a pilot you have to bury.

A Practical Order of Operations

1. Pick one workflow and one outcome. Not “AI for claims.” Document extraction for a defined claim segment. Triage support for a defined intake path. QA assistance on a defined failure mode. This is a pilot, meaning limited scope with real data and a defined success measure, not a proof of concept meant only to show the idea can work.

2. Map the data the workflow actually needs. List systems, owners, data freshness, known quality defects, and access rules. Include the notes everyone relies on that nobody has formally catalogued. In TPA operations, this is often the difference between what a carrier’s system says and what actually happened in the surge response.

3. Fix or fence the defects that would poison the use case. You do not need perfect enterprise data. You need honest boundaries. If a field is unreliable, do not let the model treat it as ground truth, and do not let a reviewer sign off without knowing that field is unreliable either.

4. Only then choose the model or vendor. Now the buy decision is about fit to a governed path, not about who had the flashiest demo. You are selecting capacity that can operate inside defined rules, not buying intelligence to compensate for an operating system that was never ready to use it.

5. Measure with claims outcomes, not model vanity scores. Rework rate, override frequency, cycle time, leakage indicators, and customer friction beat generic accuracy charts. If AI is supposed to support an adjuster’s work, measure what actually happens on the file, not how often the model guessed right on a test set.

Why This Matters Now

Claim work gets hard in the human reality around the technical task. Data readiness is where that reality shows up as missing documents, conflicting notes, and people who know which fields lie. In surge response, it is even clearer: the usual data governance rules do not survive a 500-file intake. The workarounds become the operating system. If you skip data readiness, you ask AI to sound certain in a domain that is full of incomplete truth. That is how organizations create automation bias and then blame the model for a leadership shortcut.

The carriers doing this right are not debating models. They are mapping workflows. They are auditing data. They are defining PII boundaries. They are treating data readiness as a governance and operations problem, not a technology problem. Then they select a model that fits.

Stop starting with the model bake-off. Start with the workflow, the data domains that feed it, the PII boundary, and the defects you are willing to fix or fence. In insurance, the model is rarely the first decision. Data readiness is. Ignore that order and you will keep buying intelligence to compensate for an operating system that was never ready to use it.