Adaptive AI for Insurers, Without Moving the PII

Most conversations about AI in insurance start with the model and get to the data late. In my experience it has to run the other way, because in this industry the data boundary is not a constraint on the design — it is the design.

An insurer's useful data is the data it is least free to move. Names, addresses, dates of birth, health information, claims history, and increasingly telemetry from a policyholder's own property. All of it personal, much of it special-category, all of it governed by commitments the carrier has already made to regulators and to the people it insures.

So the question worth asking is not "can AI help here". It is: what shape does the system have to be, so the personal data never leaves the place it is allowed to be?

Move the model, not the data

The instinct is to move data to where the intelligence is. The better pattern is usually the reverse.

We have built this: a full agentic stack — retrieval, models and governance — running entirely on a hospital network's own GPUs, with no patient data transmitted to any external service. Different industry, identical constraint. Open-weight models make this practical now in a way it was not a few years ago, and the capability you give up is much smaller than most people assume, particularly for the retrieval-and-summarise work that makes up the bulk of real use cases.

For an insurer the same reasoning applies to claims narratives, adjuster notes, policy documents and the free text nobody has ever been able to query properly. That material is where the value is and it is also the material you cannot post to a third-party endpoint.

Adaptive means the boundary has to hold while things change

"Adaptive" usually means the system learns from what it sees — new fraud patterns, new claim types, a new product line. That is exactly where data-protection problems get in, because adapting means retaining, and retaining is a decision with a legal shape.

Three things are worth settling before any of it is built:

What is retained, and for how long. A system that improves from feedback is a system that keeps examples. Decide what an example is allowed to contain, and strip it at the point of capture rather than at review time.

Whether personal data needs to be in the loop at all. Often it does not. A model reasoning about a claim usually needs the shape of the claim, not the claimant's identity. Pseudonymisation before the model sees anything removes a whole category of risk for very little capability.

Who is accountable for an output. In regulated decisions the system proposes and evidences; a person decides. That is not just good practice, it is what makes the decision defensible when somebody asks how it was reached.

Data sync is where this usually breaks

The part that quietly defeats these programmes is not the model. It is keeping the AI's view of the world current with the systems of record.

Policy administration, claims and CRM all change constantly, and an AI answering from a stale copy is worse than no AI at all — confidently wrong is a worse failure mode than unavailable. Meanwhile every copy you create is another place the personal data lives, and therefore another thing to secure, audit and eventually delete.

The pattern that has worked for us is to sync as little as possible, as late as possible: keep the systems of record authoritative, retrieve at query time rather than maintaining a full parallel store, and where an index is genuinely needed, index the minimum and keep the identifiers out of it. Fewer copies is both the privacy answer and the correctness answer, which is a rare and welcome alignment.

Start where being wrong is survivable

The place to begin is not underwriting or claims decisions. It is the work where a mistake is visible, cheap and recoverable: summarising a long claim file, finding the clause that applies, routing a case to the right team, drafting a response a human then edits.

That is not timidity. It is how trust gets built in a regulated environment — on ground where an error costs an adjuster five minutes rather than costing a policyholder their claim. Earn it there, instrument everything, and the harder work becomes a conversation you can actually have with your risk function.

The short version

Decide the data boundary first, then design inwards from it. Move the model to the data rather than the data to the model. Retain deliberately. Sync as little as you can. Keep a person accountable for anything that affects a policyholder.

None of that is the exciting part of AI. It is the part that determines whether what you build is something you are allowed to keep running.