Why insurance AI agents fail, and what actually fixes them
Permalink to “Why insurance AI agents fail, and what actually fixes them”An underwriting agent that quotes the wrong premium, a claims agent that acts on an incomplete record, an actuarial agent that cannot prove where its numbers came from: none of these fail because the model is weak. They fail because the function-specific context is missing. Atlan is the Context Layer for AI, the governed layer between your fragmented claims, policy, actuarial, and regulatory systems and the AI agents that consume them. It is not the underwriting bot or the claims copilot. It is the infrastructure those agents reason from, so every one of them works from one certified, policy-enforced source of institutional truth.
Insurance is unusually punishing here because the same word means different things in different systems, the data ages fast, and the decisions the agent influences are consequential and regulated. Performance is a function of intelligence and context. As the intelligence half commoditizes, the context half, what your terms mean, how underwriting and claims actually get done, and what an agent is allowed to do, becomes the compounding IP that separates a demo from a production deployment.
How AI agents are being used across insurance
Permalink to “How AI agents are being used across insurance”The commercial pull is real. The global agentic AI insurance market was valued at USD 4.60 billion in 2024 and is projected to reach roughly USD 75 billion by 2034 at a 32.2% CAGR, according to Market.us (2025). At the industry level, McKinsey estimates that generative AI alone could add USD 50 billion to USD 70 billion in insurance revenue, as reported by Reinsurance News (2025).
The use cases already moving into production span the insurance value chain:
- Underwriting: Agents pull risk factors from multiple sources, apply pricing logic, and generate initial risk assessments, compressing quoting timelines from weeks to days for complex specialty lines.
- Claims processing: Agents assess claims against policy terms, gather supporting documentation, classify severity, and route cases for human review based on risk.
- Fraud detection: Agents monitor claims and transactions for anomalous patterns and trigger investigation workflows.
- Actuarial and reserving: Agents assemble and reconcile data across premium, claims, and accounting systems to support reserving and financial reporting.
- AML and KYC: Agents screen policyholders and transactions against sanctions lists and typology libraries, escalating cases above defined thresholds.
- Regulatory reporting: Agents pull from source systems, apply certified calculation logic, and assemble submissions with a traceable audit trail for each figure.
Every one of these is only as trustworthy as the context feeding it. That is exactly where insurance gets hard.
Why insurance is one of the hardest context environments for agents
Permalink to “Why insurance is one of the hardest context environments for agents”Insurance context is scattered across claims platforms, policy administration systems, actuarial models, finance and accounting ledgers, and regulatory reporting stacks, each built at a different time, by a different team, with its own conventions. Four properties make this environment especially unforgiving for an agent:
- Inconsistent definitions. Risk, exposure, “active policy,” “in-force premium,” and “claim status” carry different meanings in different systems.
- Stale data. Policy and claim states change constantly, and an agent acting on yesterday’s record can price or pay incorrectly.
- Unclear lineage. When an actuarial or reporting figure is questioned, teams often cannot trace it from the agent-facing view back to its source system.
- Strict data sensitivity. Policyholder data is regulated, so what an agent may retrieve depends on role, use case, and jurisdiction.
Layered on top is a tightening regulatory posture. This is a distinct environment from banking and capital markets, and it is worth reading alongside the governance architecture for financial services AI agents, because insurance carries its own supervisory regime. The EU AI Act classifies AI systems used for risk assessment and pricing in relation to natural persons in life and health insurance as high-risk under Annex III, according to the EU Artificial Intelligence Act (2024); the obligations that follow, including data governance, record-keeping, human oversight, and technical documentation, apply from August 2, 2026. In Europe, EIOPA published its Opinion on AI governance and risk management on August 6, 2025, setting supervisory expectations on data governance, record-keeping, explainability, and human oversight for insurers, per EIOPA (2025). In the US, the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023) directs insurers to maintain a written AI systems program governed jointly by actuarial, data science, underwriting, compliance, and legal functions.
Satisfying any of these regimes requires the same foundational capability: agents that produce consistent, traceable outputs tied to authoritative definitions.
The definition problem: why inconsistent terms produce wrong insurance decisions
Permalink to “The definition problem: why inconsistent terms produce wrong insurance decisions”Every carrier has a definition problem at scale. Consider a single agent workflow that touches “exposure.” In the actuarial model, exposure is an earned-exposure measure over a period. In the underwriting system, it is the sum insured or limit on a risk. In the reinsurance ledger, it is net retained after cessions. Ask three agents the same question and you get three defensible, incompatible answers.
Terms that need canonical governance before any insurance agent uses them include:
- Risk / exposure: Defined differently across underwriting, actuarial, reinsurance, and capital reporting.
- Active policy: May mean bound, in-force, paid-to-date, or not-yet-lapsed depending on the system.
- Claim status: Open, reserved, closed, reopened, and litigated are coded inconsistently across claims platforms.
- Premium: Written, earned, in-force, and net premium are distinct constructs that often share field names.
- Customer / policyholder: Counted at the household, policy, or legal-entity level depending on context.
An underwriting agent and an actuarial agent that each retrieve whichever definition responds first will produce answers that cannot be validated against any authoritative source. That is an ontology problem, and it is why so many insurance agents stall in pilot. The fix is a canonical insurance ontology and semantic layer with certified definitions, lineage tracing, and policy governance that every agent queries the same way.
Knowledge, Expertise, and Norms: the three parts of insurance context
Permalink to “Knowledge, Expertise, and Norms: the three parts of insurance context”Context for an insurance agent is not one thing. It is three, and missing any one causes failure:
- Knowledge, what things mean. The certified definitions of risk, exposure, active policy, and claim status, plus the entities and metrics that make up your book. This is the ontology.
- Expertise, how the work gets done. The underwriting playbooks, referral rules, claims triage procedures, and reserving logic that encode how your carrier actually operates, not a generic textbook.
- Norms, what is allowed. The policy rules, permissions, and approval steps that determine which data an agent may see, which actions it may take, and where a human must sign off.
A claims agent with perfect Knowledge but no Norms will act on records it should never have touched. An underwriting agent with Knowledge and Norms but no Expertise will misapply your carrier’s referral thresholds. Governed context supplies all three from one source.
What a governed insurance AI architecture looks like: 5 foundational layers
Permalink to “What a governed insurance AI architecture looks like: 5 foundational layers”A production-grade architecture for insurance AI agents has five layers. Each resolves one or more of the context and compliance requirements above.
Layer 1: Insurance ontology and semantic layer
Permalink to “Layer 1: Insurance ontology and semantic layer”Every core term, risk, exposure, active policy, claim status, premium, must have a canonical, certified definition with lineage from source system to agent-facing view before any agent queries insurance data. This is the prerequisite for consistent, auditable outputs.
Layer 2: AI asset registry and model inventory
Permalink to “Layer 2: AI asset registry and model inventory”Every agent must be registered in a governed inventory that links it to the data it consumes, the definitions it applies, the policies it operates under, and its validation and monitoring status. This gives underwriting risk, actuarial, and compliance functions a single point of truth for every AI system in production, and satisfies the written-program expectation in the NAIC bulletin.
Layer 3: Policy enforcement at the context delivery layer
Permalink to “Layer 3: Policy enforcement at the context delivery layer”Access controls, data-sensitivity rules, and jurisdictional constraints must be enforced at the layer that delivers context to agents, not reimplemented inside each agent. A centralized, MCP-compatible context endpoint evaluates role, use case, and sensitivity before any context is delivered.
Layer 4: Decision traces and audit infrastructure
Permalink to “Layer 4: Decision traces and audit infrastructure”Every agent action must link to the data products, definitions, policies, and reasoning steps that produced it, and support point-in-time reconstruction for supervisory review that may occur years later. This is what decision traces provide.
Layer 5: Context repos and versioning per line of business
Permalink to “Layer 5: Context repos and versioning per line of business”Governed, versioned context repositories let underwriting, claims, and compliance each consume certified context tuned to their line of business, reused across use cases and preserved for audit. When a rating rule or reserving assumption changes, the version history preserves exactly what was in effect at every prior point in time, which is the backbone of provable lineage for IFRS 17 reporting across claims, premium, and accounting systems.
How Atlan supports insurance AI agents in production
Permalink to “How Atlan supports insurance AI agents in production”Atlan operates as the governed context layer and AI control plane for insurance AI, connecting claims, policy, actuarial, and finance systems to agents through one policy-enforced infrastructure built on the Enterprise Data Graph.
- Insurance ontology and semantic layer: Canonical, certified definitions for insurance entities, with column-level lineage from source systems to agent-facing views. Every agent queries the same certified definition of exposure or claim status, regardless of the connecting system.
- Context Engineering Studio: The workspace where actuarial, underwriting, and data teams build, test, review, and certify context before agents reach production.
- Context Agents: AI agents that automatically mine and enrich the insurance context layer, descriptions, metrics, and process maps, from SQL, lineage, and BI as your data changes. Across 50+ enterprise customers, Context Agents have generated 690,000+ descriptions, with 87% rated on par with or better than human-written ones.
- AI asset registry: A governed inventory of every model, agent, and prompt, linked to the data it consumes and the benchmarks it has been validated against. See what an AI registry is for how this maps to a written AI systems program.
- Decision traces: A full audit trail of agent reasoning, queryable by underwriting, actuarial, audit, and compliance teams without requiring access to the agent infrastructure itself.
- MCP Server and policy enforcement: Atlan’s MCP Server is the governed context endpoint for insurance agents. Before any context reaches an agent, it enforces what an asset means in the insurance ontology, whether it meets the freshness threshold, and which policies apply.
Grounding an analysis agent in shared context through this approach is not theoretical: Workday used Atlan’s MCP Server to ground a revenue-analysis agent in governed context and saw a 5x improvement in AI-analyst accuracy, working from 6 million cataloged assets and 1,000 glossary terms.
Real stories from insurers building governed AI context
Permalink to “Real stories from insurers building governed AI context”Regulated enterprises are already co-building the governed context layer that AI agents reason from. Two examples show what that looks like at scale.
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI Labs, we're co-building the semantic layer that AI needs."
- Joe DosSantos, VP Enterprise Data & Analytics, Workday
"With Atlan, we cataloged over 18 million data assets and 1,300+ glossary terms in our first year, so teams can trust and reuse context across the exchange."
- Kiran Panja, Managing Director, CME Group
Moving forward with AI agents for insurance
Permalink to “Moving forward with AI agents for insurance”The path to production-grade insurance AI agents is architectural. Build the governed context first: the insurance ontology, the AI asset registry, the decision traces, and the column-level lineage across claims, premium, and actuarial systems. Then build the agents on top.
Start where the compliance requirements are clearest and the ROI is most measurable: regulatory reporting, claims triage, and AML screening. Use those deployments to establish a governance baseline, a registered inventory, certified definitions, and a complete decision-trace record. Then use that baseline to earn expanded autonomy for agents in more consequential work: underwriting, pricing, and reserving, exactly the areas the EU AI Act treats as high-risk. Context is IP. Keep yours.
FAQs about AI agents for insurance
Permalink to “FAQs about AI agents for insurance”What is an AI agent in insurance?
Permalink to “What is an AI agent in insurance?”An AI agent in insurance is an autonomous or semi-autonomous software system that perceives data across claims, policy administration, actuarial, and finance systems, reasons over it, and takes action across multi-step workflows such as underwriting, claims triage, fraud detection, and regulatory reporting. Unlike a chatbot, an insurance AI agent executes end-to-end workflows spanning multiple systems and adapts its behavior based on intermediate results.
Why is insurance a hard environment for AI agents?
Permalink to “Why is insurance a hard environment for AI agents?”Insurance context is fragmented across claims, policy administration, actuarial, finance, and regulatory systems, each with its own definitions of risk, exposure, “active policy,” and “claim status.” Data is often stale, lineage is unclear, and much of it is sensitive. An agent that queries an inconsistent or untraceable definition produces outputs that cannot be validated, which no underwriting or risk committee will approve for consequential decisions.
How does the EU AI Act affect AI agents in insurance?
Permalink to “How does the EU AI Act affect AI agents in insurance?”The EU AI Act classifies AI systems used for risk assessment and pricing in relation to natural persons in life and health insurance as high-risk under Annex III. High-risk obligations, including data governance, record-keeping, human oversight, and technical documentation, apply from August 2, 2026. That makes provable context and auditable decision records an architectural requirement, not an afterthought.
What is the definition problem for insurance AI agents?
Permalink to “What is the definition problem for insurance AI agents?”The definition problem is that core insurance terms such as risk, exposure, “active policy,” “in-force premium,” and “claim status” resolve differently across the claims, policy admin, actuarial, and finance systems an agent queries. An underwriting agent and an actuarial agent can both ask for “exposure” and receive different numbers. The fix is a canonical insurance ontology with certified definitions, lineage tracing, and policy governance that every agent queries consistently.
What are decision traces and why do insurance AI agents need them?
Permalink to “What are decision traces and why do insurance AI agents need them?”A decision trace is a complete, queryable record of the reasoning an AI agent applied to a specific output, including the data it queried, the definitions it applied, the policies in effect, and the sequence of steps from input to output. Insurance AI agents need decision traces because underwriting review, claims audit, and compliance functions must reconstruct exactly what data and policy produced an agent decision, often long after the fact.
Sources
Permalink to “Sources”- Agentic AI Insurance Market Size, Share | CAGR of 32.2%, Market.us
- Gen AI could unlock $50-$70bn in insurance revenue, estimates McKinsey & Company, Reinsurance News
- Annex III: High-Risk AI Systems Referred to in Article 6(2), EU Artificial Intelligence Act
- EIOPA publishes Opinion on AI governance and risk management, European Insurance and Occupational Pensions Authority
- Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, National Association of Insurance Commissioners
