AI for insurance, across underwriting and claims.

Three places, consistently. Submission and claims intake, where documents are read and re-keyed by people today. Decision support, where an underwriter or adjuster spends more time locating information than judging it. And service, where routine broker and policyholder questions absorb licensed staff.

The pattern that fails is the one aimed at the decision itself. Carriers that automate the reading and retrieval around a decision, and leave the decision with the human, get results that survive both a model risk review and a bad quarter.

We insist on a measurable target before building: cycle time on a named workflow, expense per claim, quote turnaround, or straight-through processing rate. If nobody will commit to a number, the use case is not ready.

It is auditable at the level of a single decision. For any given quote or claim, you can produce the inputs, the documents retrieved, the tool calls made, the model and prompt version in force, and the human action that followed.

It is bounded. The model has least-privilege access through a defined tool layer, writes are idempotent and reversible, and irreversible actions require human approval. PII is redacted before inference and inference stays inside your cloud account.

And it is measured continuously, not once at launch: an evaluation suite in the pipeline, drift alerts on live traffic, and documented governance that maps to your existing model risk framework rather than inventing a parallel one.

Buy where the workflow is generic and the vendor's data advantage is real — standard document extraction and off-the-shelf contact-center automation are usually not worth building.

Build where the workflow encodes your appetite, your wordings, and your claims philosophy. That is the part a vendor cannot ship you, and it is where the margin difference between carriers actually lives.

In most engagements the answer is a thin layer of your own over platforms you already run. We are happy to tell you the buy answer when it is the right one — we would rather scope the work correctly than sell a build.

The NAIC model bulletin on AI, now adopted in most states, asks carriers for a written AI governance program: an inventory of AI systems, documented risk assessment per use case, testing for unfair discrimination, third-party model oversight, and evidence that a human is accountable for outcomes. None of that requires new technology; it requires artifacts that most pilots never produce.

So we produce them as we build. Every system we ship carries a one-page system description, the evaluation dataset and grader definitions, bias and disparate-impact testing on the protected characteristics your legal team identifies, a vendor and model dependency list, and a named business owner. The pack is refreshed each quarter rather than written once for launch.

For third-party models the same rules apply to your provider. Deploying Claude or Gemini through Bedrock or Vertex inside your own account is what makes that story straightforward: data residency, retention and sub-processor questions get standard answers your cloud agreement already covers.

Carrier document estates are the real constraint, not model quality. Submissions arrive as email bodies, scanned PDFs, ACORD forms, spreadsheets and broker portals. Loss runs are inconsistent across brokers. Policy wordings live in a document store that nobody has indexed since the last migration. A copilot built over that estate is only as good as the retrieval underneath it.

The first weeks of most insurance engagements are therefore ingestion and retrieval work: OCR with layout preservation for scanned documents, table extraction that survives merged cells, document classification and de-duplication, chunking that respects clause boundaries in wordings, and metadata that carries policy number, effective dates and line of business so retrieval can be filtered before it is ranked.

We measure that layer on its own before any generation is judged: retrieval hit rate on a labeled set of questions, extraction accuracy per field, and coverage of the document types actually present. If retrieval is weak, no prompt fixes it — and knowing that early is what keeps a program honest.

By keeping the model away from the decision and testing anyway. In every underwriting or claims system we ship, the model retrieves, summarizes, extracts and drafts; the rating, pricing, coverage and denial decisions stay in your existing rules and with your licensed staff. That boundary is the strongest single control available, and it is architectural rather than aspirational.

Then we test. Proxy variables are the risk — ZIP code, occupation, vehicle, named entities in free text can all carry protected characteristics indirectly. Evaluation includes paired testing on matched cases that differ only on a sensitive attribute, and we look at outcome distribution across segments, not just aggregate accuracy.

And we log at the decision level, so that if a market conduct examination asks why a specific claim was handled the way it was, the answer is a record rather than a reconstruction.

Four failures repeat. A pilot on synthetic or sampled data that never faces the real document distribution, and collapses on contact with production. A use case with no committed underwriting or claims owner, which produces a system nobody adopts. Security and data-access work started after the build instead of alongside it, which turns a 30-day pilot into a 90-day one. And no evaluation harness, which means nobody can change a prompt after launch without a committee.

The counter-measures are unglamorous and they are why we sequence engagements the way we do: real data in week one, a named business owner before kick-off, the security workstream opened in parallel, and an evaluation suite delivered with the first working prototype rather than after it.

We would rather return a well-evidenced no on a use case in six weeks than deliver a demo that funds an eighteen-month program on the wrong problem.