.png)
An underwriting team has a model returning risk recommendations in seconds. In the pilot, the data is prepared, the fields are mapped, every submission looks like the last one. Impressive.
Then the model meets live policy and claims systems. Records conflict. A field that should be current is a week old. The model still returns a score in seconds. The workflow around it moves at its usual, unhurried pace.
Here's the thing most AI modernization plans get wrong: they treat the model as the project and everything around it as an afterthought. AI readiness actually lives in the infrastructure surrounding the core, infrastructure a CTO already owns and already has opinions about. It gets built in stages, and a full core rewrite is just one possible outcome of that work.
In this piece, we map the order that actually works: what AI-ready insurance systems require at the architecture level, which changes come first, and when the core genuinely needs to move.
What makes an insurance system AI-ready?
An AI-ready insurance system is one where data reaches the model with known ownership and quality, AI services interact with core workflows through defined interfaces, and the architecture absorbs change without destabilizing existing operations. No specific vendor stack or AI product gets you there on its own. Three properties, working together, do.
NTT DATA's 2026 research on AI adoption in insurance found meaningful differences in governance maturity and core-system strategy between insurers further along in AI deployment and those still running early pilots.
The three areas below form a practical checklist for AI readiness. Each covers a distinct responsibility, from trustworthy data and workflow integration to safe changes in the core system.
1. Data can reach the model with known ownership and quality
Every field the model depends on needs an authoritative source, a documented mapping, and a known refresh interval. If a risk score draws a claims count from one system and a property value from another, both need a named owner and a stated freshness guarantee, and "it's usually current" doesn't count as one.
This covers four things in practice:
- The authoritative source for each policy, claims, billing, and customer field
- Consistent field definitions across systems that may label the same concept differently
- Documented batch-processing dependencies and their refresh schedules
- Validation rules and a defined response for missing or conflicting records
A policy administration system and a claims system rarely agree on what counts as an "active" policy at the exact same moment. Deciding which system wins that argument, and writing the decision down, is data governance work. The model just inherits whatever the team decided here, for better or worse.
2. AI services can interact with business workflows
A model's output earns its keep once it reaches a human or a transaction. That takes an integration layer with defined interfaces between the AI service and core transactions, a human review and referral path for cases the model shouldn't decide alone, and error handling, monitoring, and access controls on the connection itself.
Example API contract:
Contract ownership requirements:
- Documentation: Define each field, its format, and its meaning.
- Versioning: Track changes to the payload and maintain compatibility rules.
- Accountability: Assign an owner responsible for updates and ongoing maintenance.
The JSON structure may be simple. Keeping the contract documented, versioned, and under clear ownership requires an ongoing commitment beyond the initial model pilot.
3. The architecture can change without destabilizing the core
Modular services, bounded release scopes, and controlled interfaces let a team ship one workflow change without touching every function the core system performs.
NTT DATA frames this as moving from “cloud-ready” to “AI-ready,” where the difference is whether an insurer can introduce a new capability through a contained interface or has to modify shared core logic every time.
What should the modernization team change first?
The modernization team starts with a full inventory of systems, data, and business rules, before selecting any platform or committing to a migration scope. Skipping this step is the most common reason AI pilots stall once they meet production data. It's also the least glamorous stage, which is probably why teams try to skip it.
Stage 1: Inventory systems, data, rules, and dependencies
This stage produces a current-state map covering policy administration, claims, billing, document, and customer systems, along with the batch jobs, interfaces, and external dependencies connecting them. It also has to surface business rules embedded directly in application code, which is frequently where the real risk lives. A rating rule written into a decade-old COBOL routine with zero external documentation is a bigger constraint than any data-freshness problem, and somewhere in most carriers there's one nobody has looked at since the person who wrote it retired.
Deliverable:a current-state inventory covering systems, data flows, rules, and dependencies.
Decision gate: can the team identify every system and rule involved in the workflow it plans to modernize first?
Stage 2: Select one bounded business workflow
Pick one workflow with a clear scope, such as underwriting triage, submission intake, claims document classification, or policy servicing, over attempting a platform-wide rollout.
For that workflow, define:
- Business owner: Who owns the workflow and its outcomes?
- Inputs: Data, documents, systems, and triggers required.
- Expected outputs: Decisions, records, notifications, or transactions produced.
- Core transactions: Key business actions the workflow must support.
- Human review: Where people validate, override, or approve decisions.
- Baseline metrics: Processing time, exception rate, and manual effort.
Deliverable: a workflow definition with scope, ownership, and acceptance criteria.
Decision gate: can the team test the workflow without uncontrolled changes to unrelated core functions?
BCG's research on agentic AI in core insurance modernization describes this discovery work, along with redesign, development, testing, migration, and rollout, as sequential stages. Legacy discovery and business-rule documentation belong at the front of the plan because everything downstream depends on knowing what's actually there.
What should change second: data access and integration
Once the workflow is scoped, the next step builds a controlled path for data to reach the AI service. This is legacy system modernization in its most literal form, and it's where most of the technical risk in the project sits.
Stage 3: Establish controlled data access
For each required field, the team chooses the authoritative source, decides whether an API, an event stream, change data capture, a read model, or scheduled batch access fits the freshness requirement, and documents the transformation and validation rules applied along the way.
A field that needs sub-hour freshness for a referral decision needs something faster than a nightly export, even one that has served the business faithfully for fifteen years.
Deliverable: a documented data-access contract, including expected freshness, ownership, validation, and failure handling.
Decision gate: can the AI service receive the required data with predictable quality and behavior?
Stage 4: Define integration boundaries
Three components carry three separate responsibilities, and conflating them is where integration projects lose control of scope:
The integration layer also needs its own service contracts covering authentication, authorization, observability, and error handling, treated as first-class requirements from the start of the project.
TCS's analysis of policy administration system modernization describes modular PAS architecture, externalized decision services, and real-time data access as approaches that let insurers add capability around the core system
This is one architectural approach among several, and the right fit depends on what the Stage 1 inventory found.
What should change third: introduce AI into a controlled workflow
The AI service gets introduced once data access and integration boundaries are defined, with an explicit statement of what it can decide versus what it can only recommend. This is the point where “the model works” turns into “the workflow works,” two claims that sound identical and rarely are.
Stage 5: Add the AI service and define its authority
For underwriting triage, the model might classify a submission or recommend a referral, and the policy action that follows still runs through the insurer's existing authority and transaction controls.
Define the specific task assigned to the model, including which tasks can and cannot be automated (some tasks are suitable for AI automation, while others still require human judgment).
Then define its accepted inputs and outputs, model versioning and release controls, the human review and override path, and the exact boundary between a recommendation and an authorized policy action.
Define exception handling before launch:
These five conditions show up in a production workflow's first month, reliably, like clockwork. Deciding the response in advance costs a meeting. Discovering it during an incident review costs considerably more.
Deliverable: a workflow with defined AI responsibilities, human checkpoints, and exception handling.
Decision gate: can the workflow complete or refer a case while honoring existing business rules and policy records?
How should the team validate the new workflow?
Validation for an AI underwriting workflow covers the complete transaction path, from source data to the audit record left behind. A model that scores accurately in isolation and a workflow that completes correctly in production are tested with different questions, and both need answering before launch.
Stage 6: Test the complete transaction
Testing scope includes data mapping and reconciliation, model evaluation against agreed criteria, integration failures and unavailable dependencies, human review and override behavior, policy transaction execution, and audit records tied to operational recovery.
What does validation at production scale look like?
PwC's 2026 case study on Encova Insurance's move to Guidewire Cloud gives one concrete reference point for what “tested at scale” means.
Encova's go-live processed 3.5 billion historical data transactions, resolved more than 140,000 upgrade artifacts with zero critical defects, and handled 5,800 submission quotes in the first week alone.
These figures describe one insurer's migration validation and data infrastructure work. Treat it as a useful reference point, not a benchmark every project should expect to match.
What it shows is the order of magnitude a production insurance core actually operates at, the scale any AI workflow eventually has to survive contact with. It's the same scale we at TYMIQ plan for when we validate a workflow for a client: test the transaction path against real volume, not a curated sample that happens to look clean.
Deliverable: test evidence, operational runbooks, and an approved release decision.
Decision gate: does the workflow meet its business, technical, and control requirements under normal and exception conditions?
When should the insurer expand, redesign, or replace the core?
This is the decision a CTO or technology director ultimately owns: expand the current core in stages, or commit to replacing it. Incremental modernization fits when the current core can meet the workflow's requirements.
Replacement fits when specific, identified constraints in the existing architecture resist resolution through integration. Either option, picked by default before the analysis, is a guess wearing a strategy's clothes.
When can the team expand incrementally?
Expansion in stages fits when core transactions remain reliable, required data can be accessed and validated, integration boundaries stay manageable, business rules can be invoked through controlled interfaces, and the workflow meets its acceptance criteria from Stage 6.
When does the architecture need a second look?
A few indicators point toward deeper change: essential data stays inaccessible or stale across every integration approach tried, batch dependencies conflict with the processing times the workflow needs, embedded rules resist identification or governance, transaction interfaces can't accommodate the workflow's requirements, or integration workarounds have piled up into real operational risk.
What does core replacement actually cost?
Roland Berger's research on core insurance system transformation puts full replacement programs at a range of €20 million to more than €100 million, running two to five years, with around half missing their time or budget targets (Roland Berger, How insurers can maximize value from core insurance system transformation). Those figures come from the specific programs Roland Berger studied, a data point for the comparison rather than a universal estimate. The real comparison weighs the cost of coexistence, data conversion, testing, integration, cutover, and ongoing operation against what incremental modernization would cost for the same workflow. Somewhere in that spreadsheet is the actual answer, and it's rarely as dramatic as "rip and replace" makes it sound.
What does a practical AI modernization roadmap look like?
Seven stages, each with its own deliverable, each one a gate the next stage walks through. Here's the whole thing laid out in one place:
McKinsey put a number on something most engineering teams only feel: modernization tasks speed up at wildly different rates once AI enters them.
The range runs from 10% to 90%, depending on the task and how much of it gets automated:
- Reverse engineering legacy code: closer to the high end, where AI reads decades-old logic faster than any team ever could
- Discovery and documentation: strong gains, since pattern-matching across a codebase is exactly what these tools are built for
- Testing and reconciliation: closer to the low end, since human sign-off stays part of the process regardless of how fast the first pass runs
- Migration execution: somewhere in between, shaped by how well the legacy logic was understood before the move started
Plan stage by stage against this range, treating any single blended number as a rough starting estimate.
How can CTOs check progress before committing to the next phase?
A short diagnostic list works better as a planning aid than a formal maturity score. Bring these seven questions directly into a stage-review meeting:
- Have we identified the authoritative sources for the workflow's data?
- Can we trace data transformations and validate model inputs?
- Are AI responsibilities separate from core transaction authority?
- Can the workflow route exceptions to an authorized person?
- Can the team reproduce and audit a completed transaction?
- Have we tested failure conditions and recovery?
- Do the observed results justify expanding the scope?
A “no” answer here is information, and the right response is staying at the current stage until the gap closes.
Frequently asked questions:
Does an insurer need to replace its core system to adopt AI?
Most AI underwriting and claims workflows can run on the existing core if data access, integration boundaries, and exception handling are built correctly. Replacement becomes the right call when specific constraints, such as inaccessible data or unworkable transaction interfaces, resist resolution through integration.
What does “AI-ready” mean for an insurance core system?
An AI-ready insurance core is one where data reaches AI services with known ownership and quality, AI outputs flow into business workflows through defined interfaces, and the architecture absorbs change without destabilizing existing operations.
What's the first step in modernizing an insurance core for AI?
A full inventory of systems, data, business rules, and dependencies, completed before selecting any platform or AI vendor. Skipping this step is the most common reason AI pilots fail to reach production.
In a nutshell
AI-ready insurance systems get built in stages, from the infrastructure that already exists. Readiness comes down to whether the systems around the model can supply dependable data, connect through defined interfaces, and preserve the controls that already govern policy transactions.
Insurers ahead on AI maturity aren't running better models. They finished the inventory, data, and integration work most teams still treat as optional, one stage at a time, with a decision gate at each one.
The model was the easy part all along. Everything that makes it useful in production was the actual project.
.svg)
