Will Your AI Pilot Stall at the Data Layer?

AI-Ready by Architecture, part 1

Premira Mutual is a composite. The carrier is fictional; the problems are real.

The demo went great.

Premira Mutual, a $1.2 billion regional mutual writing commercial and personal lines across the South, built a claims-triage assistant last year. Ray Tran, the VP of Claims, sponsored it. Fed it the first notice of loss, the adjuster notes, and the policy, and it ranked which claims needed a person first. The room watched it work. Leadership clapped. Someone said the word "production."

Production was different.

The scores drifted, the adjusters stopped trusting the queue, and nobody could explain why any claim ranked where it did. When internal audit asked what data trained the model, the answer was a shrug and a Slack search. Six weeks later the pilot was a slide in a postmortem, and Ray Tran was the one presenting it, explaining where a year of budget went.

It plays out the same way at carrier after carrier, and the AI model is rarely the reason.

More than 90 percent of carriers tested AI in 2025. Only 22 percent reached production. The gap between those two numbers is a data layer that was never built to carry an AI workload.

What "AI-ready" really means

Most carriers think AI-readiness is a data quality project. Clean the data, fix the dashboards, and the AI agents will come. Quality matters, and dirty data has killed its share of pilots. It is also the part everyone already knows how to fix.

Five things have to be true of the platform before an agent can safely touch it, and a clean-data project fixes none of them. Most mid-market carriers fail at least three.

1. Vectors need a home inside the platform.

Embeddings of documents, notes, and coverage language live next to your structured data, queryable in the same place. If your embeddings live in a side project on someone's laptop, you've got a prototype. Prototypes don't survive production.

2. Lineage has to span training and inference.

You need to be able to say "this prediction used these features, computed from these records, as of this date," on top of the table-to-source map. When the examiner asks, you answer in minutes, not weeks. And they will ask: the NAIC is piloting its AI exam tool in 12 states right now, and the EU AI Act's deferred high-risk rules land in December 2027.

3. Classification and governance tags belong to the dataset itself.

The agent needs to know that a field is PII before it puts it in a prompt, not after. Tags travel with the data or they don't exist.

4. Access paths have to be documented and stable.

An agent reaching into your platform needs a known door, a known contract, and a known set of permissions. Undocumented access is how a triage bot ends up reading a table nobody meant to expose.

5. The interfaces have to be MCP-compatible.

If you want agents to call your data as tools, the tool surface has to exist. Retrofitting it later means rebuilding the access layer you just shipped.

Premira Mutual's pilot failed all five, including the one the team thought they had covered. They had built a vector store for themselves. A vector store nobody else can find is the side project from criterion one, and it died with the pilot.

Why buying the platform isn't enough

Here's the part that stings. The carriers failing these five are not behind on tooling. They have Snowflake. They have dbt. They bought the things.

What they don't have is a data model underneath that was designed to be auditable and integrable from the start. They have a warehouse full of point-to-point pipelines, overwritten history, and a "customer" that exists in four systems under four different keys. You can't bolt lineage onto a platform that throws away yesterday's value every time it loads today's.

The history is the tell. When a claim's risk score changes, can you reconstruct the exact inputs as they stood the day the decision was made? At most carriers, no. The silver layer overwrote it. The audit trail the regulator wants, and the training data your AI model needs, both died in the same UPDATE statement.

Yes, a weak model can sink a pilot too. But that is the fixable part. This is about the part that isn't.

Where Data Vault earns its keep

Data Vault closes four of the five criteria by construction: lineage and history, classification, stable access paths, and a home for vectors.

Every piece of data gets one of three homes. Hubs anchor each business key once: policy number, claim number, customer ID, producer ID, and they hold nothing but the key, so nothing in them can drift. Links hold the relationships between those keys. Satellites hold the descriptive data, split by source and sensitivity, and, this is the point, they keep every version of it over time.

Nothing gets overwritten. The history is structural.

In most warehouses, history exists only where somebody deliberately built it, one table at a time. In a vault, it is how every table loads.

The platform's own features do not close the gap. Time Travel keeps days of history, not the years an examiner or a training set reaches back for, and a type 2 dimension keeps history only on the tables somebody chose to build that way. The vault makes history the default instead of a decision.

Two layers sit inside the vault. The Raw Vault holds every source exactly as it arrived, in Hubs, Links, and Satellites; nothing reconciled and nothing overwritten. The Business Vault sits on top, where the computed numbers live, each reconciliation and derivation worked out once.

Keep them apart, and the raw record stays auditable no matter how often the business rules change.

The Raw Vault remembers; the Business Vault calculates. Part four of this series adds the layer that speaks.

Lineage and history come built in, because Satellites never throw away a prior state. You can reconstruct any record as of any date, which is exactly what training reproducibility and regulatory audit both require; log the as-of date with each prediction and the vault reconstructs the rest. That is criterion two, the hardest one to retrofit, handled by the data model itself.

Classification tagging gets easier, because you split Satellites by source, by rate of change, and by sensitivity. PII lands in its own Satellite, tagged once in Snowflake with a masking policy bound to the tag and reapplied by dbt on every build, instead of spread across a wide table you mask column by column. Criterion three.

Integration stops being brittle, because Hubs give you one durable anchor for each business key across every source system. The four-headed "customer" problem becomes a resolved Hub with the conflicting source attributes preserved in their own Satellites, fully auditable. And because the structure is uniform and the keys never move, the access paths into the data model stay stable and documentable. Criterion four.

Vectors get a home too. Embeddings are Satellite attributes like everything else, stored next to the structured data they describe, and the platform supplies the vector type. The sidecar on someone's laptop stops being necessary. Criterion one.

That leaves MCP access, the one criterion that still takes deliberate design. Scored against the five, the vault reads four before you write a line of agent code. Build the tool surface and it reads five.

The honest caveat: Data Vault is not free. It's more tables, more joins, and a modeling discipline your team has to learn. Where it's worth it and where it's overkill has an article of its own. For an AI-bound P&C platform, the auditability alone pays for it.

Where to start Monday

You don't need to rebuild your platform to find out where you stand. Take the workload you most want to put AI behind and ask it five questions. Can an agent query your embeddings where the structured data lives? Can you trace a prediction back to the records behind it, as of a date? Does every sensitive field carry its classification? Is there a documented door for the agent? Is that door MCP-compatible?

Count your yeses. You need five.

Each one you're missing is where the next pilot stalls. Premira's scored zero. The encouraging part: every one of those gaps lives in the data layer, and the data layer is fixable. Build it as a vault, queried, traced, and trusted.

In a demo, a prototype and a real platform look identical. Production exposes the difference.

Build the data layer first, and be the carrier whose agent is still running while everyone else writes postmortems. That layer is buildable this year, on the platform you already bought.

More in this series

Three more articles, one vault structure each. Next is the Hub, in "The producer your scorecard can't see": why party resolution across policyholder, producer, broker, and agency is an architecture decision, not a cleanup project.

About Premira Mutual

Premira Mutual is a regional P&C mutual founded in 1903 in Savannah, Georgia. The group writes $1.2 billion in premium across roughly 250,000 policies, about 90 percent of it inside 12 Southern states, about 60/40 commercial to personal.

Three brands carry the book. Premira Mutual is the flagship, sold through several hundred independent agencies. Premira Go is the direct and digital sub-brand, admitted across the 48 contiguous states plus DC. Live Oak Specialty writes coastal and excess-and-surplus property through MGAs and brokers. Every story in this series happens at the flagship.

Its data platform is where the stories happen: ten source systems, Guidewire on premise, billing on an AS400, reporting in Power BI, and a Snowflake and dbt migration that is real, funded, and unfinished.