Most insurance organizations have spent the better part of a decade getting their data house in order for analytics. They have invested in data warehouses, built governed metric layers, and deployed dashboards that actuaries, underwriters, and executives actually trust. Loss ratios by segment. Premium trends by geography. Claims frequency over time. The numbers are clean, the definitions are consistent, and the reports are defensible in a regulatory exam.
Then organizations try to deploy AI — an underwriting assistant, a claims triage agent, a submission intake pipeline — and the same data that powers a flawless Power BI dashboard produces hallucinated risk prices, unexplainable fraud scores, and catastrophe models that miss the nuance sitting in broker narratives and loss run PDFs.
The reaction is usually some version of: "Our data is great — why doesn't the model work?"
The data is great — for humans. It was never built for machines. And the gap between those two requirements is wider than most insurers realize. An AM Best survey of more than 150 rated insurers and MGAs released in April 2026 found that 45% cite data readiness as the single largest barrier to deploying AI, even among carriers that consider themselves analytically mature. The problem is not that the data is bad. The problem is that it was shaped for the wrong consumer.
What BI-Ready Data Was Built For
Analytics-ready data is optimized for a specific audience: human decision-makers asking backward-looking questions. Actuaries computing reserves. Underwriting managers reviewing portfolio performance. Compliance teams preparing regulatory filings. Finance producing board decks. The questions follow a predictable pattern: what happened, how much, where, and over what period.
The infrastructure that serves these questions well — the semantic layer — is one of the most valuable investments an insurer can make. Tools like dbt metrics, Looker LookML, AtScale, or Snowflake's semantic model define what "revenue" means, how "loss ratio" is calculated, which tables join to which, and who has access to what. They produce a single, governed version of the truth. When an actuary in New York and an underwriting director in London both ask "what was our Q3 combined ratio," they get the same number. That consistency is not trivial — it took years to build, and it is genuinely valuable.
But the semantic layer is a translation layer. It translates business questions into SQL. It is optimized for aggregation: sums, averages, counts, filtered by dimensions like region, product line, and time period. Its output is a number on a dashboard. Its consumer is a human who brings context, judgment, and domain knowledge to interpret that number. The human knows what "loss ratio" implies even when the dashboard does not explain it.
What AI-Ready Data Requires
AI systems — large language models, reasoning engines, autonomous agents — are a fundamentally different consumer. They do not aggregate and summarize. They traverse, reason, and act. They consume tokens, embeddings, and context windows, not pivot tables. And they need data with properties that BI infrastructure was never designed to provide.
Context and completeness. A dashboard shows that a commercial property account has a 72% loss ratio. An AI agent pricing that account needs to know why — that the losses came from a single catastrophe event three years ago, that the insured has since installed monitored fire suppression, that the broker narrative explains the prior carrier non-renewed across the entire book (not because of this account), and that the D&B financial data conflicts with the broker-stated revenue by 22%. The dashboard compresses this into one number. The AI needs all of it.
Provenance. When an AI agent says the annual revenue is $5.9 million, a regulator or auditor will ask: where did that number come from? Was it the broker-stated figure from the ACORD 125? The independently verified D&B record? A Pitchbook estimate? Was there a conflict between sources? Who resolved it? AI-ready data attaches this lineage to every fact — source document, extraction method, confidence score, resolution status. BI-ready data stores the final number in a column.
Semantic richness. In a data warehouse, the relationship between an account and its claims exists as a foreign key in a join condition. An analyst knows to write the join. An AI agent needs that relationship to be named and typed — "this account has these loss runs, which contain these claim events, which are classified under this GL coverage part, which triggered this Products/Completed Operations flag." Named relationships are what allow an LLM to traverse a domain without being hand-coded to do so.
Conflict and uncertainty. BI data resolves to one version of the truth. AI data preserves the disagreement. When the ACORD form says $7.2 million in revenue and D&B says $5.9 million, the BI layer picks the governed figure. The AI layer keeps both, records the 22% delta, flags it as a high-priority conflict, generates an LLM recommendation, and routes it to a human reviewer with full context. The resolved value is authoritative. The conflict record is permanent. That is the difference between a data warehouse that stores answers and a knowledge system that tracks how answers were reached.
The Structural Differences
These are not minor implementation details. They reflect a fundamental architectural divergence between two data paradigms. The following table captures the core distinctions:
The semantic layer is a phrasebook — it translates between business language and SQL. The ontology is a knowledge base — it understands the domain well enough to reason about it. An insurer needs both, and they serve different masters.
Why Forcing One Into the Other Fails
Insurers hitting walls with AI initiatives are almost always making one of two mistakes.
Mistake one: feeding BI data to AI systems. The data warehouse has clean, aggregated loss ratios by segment. The AI agent receives those ratios and produces a confident-sounding risk assessment. But the agent has no idea that the 72% loss ratio in the dashboard includes a $380,000 open claim with adverse reserve development, that the claim involved completed operations (triggering a separate aggregate sublimit analysis), or that the prior carrier's reserve estimate doubled from its initial figure. The aggregation that makes the number useful on a dashboard strips out the very context the AI needs to reason correctly. The result: hallucinated confidence.
Mistake two: exposing raw atomic data to BI users. Some organizations, recognizing the AI data gap, attempt to solve it by pushing richer, more granular data into their analytics environment. Actuaries and underwriting managers are suddenly looking at individual extracted facts with confidence scores and provenance chains when all they needed was the quarterly premium by state. The dashboards become unusable, the definitions unstable, and the trust that took years to build erodes. The result: political and compliance backlash.
Both failures stem from the same misconception: that BI readiness and AI readiness are steps on the same ladder. They are not. They are parallel tracks serving parallel audiences with parallel infrastructure. One compresses reality for humans. The other expands it for machines.
An Underwriting Example: Same Data, Two Architectures
Consider a commercial plumbing contractor submitting for general liability coverage. The broker sends an ACORD 125 application, five years of loss runs, a supplemental contractor questionnaire, and a broker narrative. The insurer's pipeline also fetches a D&B credit report and an OSHA inspection history.
What the BI layer needs: the governed revenue figure ($5.9 million after conflict resolution), the total incurred losses ($163,700 over five years), the claim count (four), and the loss ratio. These flow into dashboards that show portfolio performance for contractor accounts. The numbers are clean, final, and aggregated. This is exactly what the semantic layer was built to deliver.
What the AI agent needs: every extracted fact from every document with its raw value, normalized value, source page, confidence score, and extractor identity. It needs to know that the broker stated $7.2 million in revenue, D&B reported $5.9 million, the delta was 22%, the conflict was flagged as high priority because revenue drives premium, the underwriter called the broker and confirmed that the gap reflected subcontractor pass-through costs, and the D&B figure was selected as more conservative. It needs to know that one of the four claims was a completed operations event with litigation, that the reserve on an open claim doubled from the initial estimate, and that the contractor's ISO class code was mapped by an LLM with 82% confidence. It needs named, traversable relationships: this account submitted this submission, which contained these documents, which produced these extracted facts, which conflicted with these external data records, which were resolved by this underwriter into these authoritative fact nodes.
The BI layer stores the answer. The AI layer stores how the answer was reached — and can defend it under audit.
The Architecture: Semantic Layer and Ontology Side by Side
A mature data platform serves both consumers through purpose-built infrastructure.
The semantic layer sits above the data warehouse and defines metrics, dimensions, joins, and access controls. It translates "what was our combined ratio by region" into a governed SQL query that returns a consistent number regardless of who asks. It is maintained by data and analytics engineers and consumed by BI tools and regulatory reporting systems. This is well-understood infrastructure and most insurers already have it, or something close to it.
The ontology sits above the same underlying data stores but defines entities (what things are), relationships (how they connect), provenance (where facts came from), and confidence (how much to trust them). It does not replace the data warehouse. It provides a reasoning layer that AI agents traverse when they need to answer questions the semantic layer cannot: why is this account priced the way it is, what evidence supports the risk classification, are there unresolved conflicts in the submission data, and what changed since last renewal.
The two layers are complementary, not competing. The ontology can inform the semantic layer — entity definitions in the ontology can generate metric definitions in the semantic model, ensuring consistency. The semantic layer operationalizes metrics for reporting. The ontology operationalizes knowledge for reasoning. One produces dashboards. The other produces auditable AI decisions.
Critically, the ontology handles six properties that no semantic layer was designed to provide: provenance (every fact knows its source), confidence scoring (an LLM-extracted value at 0.71 is treated differently from a human-verified value at 1.0), named typed relationships (traversable by agents without hand-coding), conflict resolution (when sources disagree, the system records the conflict, the resolution, and the winner), temporal validity (facts have lifetimes — the ontology tracks when a fact was true), and classification inference (the system derives that an account is high-risk based on axioms applied across loss history, operations, geography, and financial stability, rather than a hardcoded flag).
The Insurance-Specific Stakes
The dual-readiness gap has sharper consequences in insurance than in most industries, for three reasons.
Regulatory explainability demands both. The NAIC AI Model Bulletin requires insurers to explain AI-influenced decisions in specific, contemporaneous terms. Colorado SB21-169 requires documented testing for proxy discrimination and annual certification. A dashboard showing that loss ratios are within tolerance satisfies the actuarial filing. It does not satisfy the examiner asking why a specific commercial auto account was declined — that answer requires the full provenance chain from submission to triage to risk evaluation to decision, with every AI recommendation and every human override recorded. That is ontology infrastructure, not BI infrastructure.
Unstructured data is the majority of underwriting intelligence. Broker narratives, loss run PDFs, supplemental questionnaires, OSHA inspection records, court filings, and news articles — these contain the contextual intelligence that separates competent underwriting from rote classification. BI systems were never designed to ingest, parse, conflict-check, and resolve facts from unstructured documents. An ontology-backed extraction pipeline does exactly this: it reads a loss run PDF, extracts each claim event with page reference and confidence score, detects that a reserve doubled over two valuation periods, flags the development pattern, and routes it to an underwriter with a synthesized recommendation. The structured claim data feeds the dashboard. The full extraction record feeds the AI.
Renewal is a change-detection problem that neither layer solves alone. At renewal, the underwriter needs to know what changed since last year. Revenue grew 54%. A new location appeared. A Products/Completed Operations claim was filed. The prior revenue conflict between broker-stated and D&B figures persists. A BI dashboard can show this year's numbers next to last year's. An ontology-backed renewal engine compares full account snapshots, computes diffs against configurable thresholds, generates plain-language summaries of material changes, and routes escalations to the underwriter's review queue with the supporting evidence attached. The dashboard shows the delta. The ontology explains what it means and what to do about it.
Where to Start
For insurers that already have solid BI infrastructure, the path to AI readiness does not require dismantling what works. It requires building a parallel capability.
- Start with shared foundational events. Claims, policies, submissions, and customer interactions are the atomic events that both systems need. Ensure these are captured at the transaction level in your data platform before aggregation. The BI layer aggregates them into metrics. The AI layer preserves them as individual facts with provenance.
- Preserve the semantic layer for BI. It works. Actuaries trust it. Regulators accept it. Do not destabilize it by pushing atomic, confidence-scored data into environments built for governed metrics.
- Build the ontology for a high-value AI use case. Underwriting submission intake is the natural starting point for most P&C carriers: it spans structured and unstructured data, involves multi-source conflict resolution, requires provenance for regulatory defense, and produces decisions that AI can assist but humans must own. Design the ontology around the entities and relationships that this workflow actually traverses.
- Implement a governance layer that serves both. Data lineage, trust scores, conflict detection rules, and human-in-the-loop review queues are cross-cutting concerns. A fact resolved through HITL review should update both the authoritative value in the data warehouse (for BI) and the provenance record in the ontology (for AI). One resolution, two consumers.
- Measure them separately. BI success is dashboard adoption, report trust, and filing accuracy. AI success is hallucination rate, grounding quality, decision explainability, and business outcome lift. Conflating the two metrics will obscure whether either system is actually working.
The Bilingual Insurer
The carriers that will lead in the next decade are those building fluency in both data languages: one that helps humans trust the past, and one that helps machines reason about the future.
The BI infrastructure you have invested in is not wasted — it is necessary. But it is not sufficient. AI systems cannot reason over aggregated metrics, and they cannot defend their decisions without provenance. An ontology provides the knowledge layer that AI agents need to traverse a domain, resolve conflicting facts, and produce auditable outputs. A semantic layer provides the metric definitions that actuaries, executives, and regulators need to trust the numbers.
They are parallel tracks. Build both. Measure both. Govern both. The gap between them is almost certainly larger than you think — and it is where your AI initiatives are stalling.
