.png)
An AI underwriting model can score a submission in under two seconds. Getting that score into the hands of an underwriter can take two days.
That gap is where most AI underwriting initiatives quietly stall. The demo works beautifully: clean data flows in, a risk score pops out, everyone nods. Then the pilot meets a live submission and a decades-old core system – and the model ends up waiting on the same batch jobs, scheduled exports, and rigid interfaces the business has been waiting on for years.
The intelligence layer got faster. The plumbing didn't.
So where does the delay actually come from? Which underwriting tasks can AI genuinely take on today, where does the core system still hold the reins, and how do you connect the two without defaulting to “rip and replace”? That's what we dig into in this material.
Why does an AI underwriting demo work better than production?
A demo works better because someone has already done the data prep the model needs (a clean, mapped, structured input) before the demo starts. Production has no such head start: that same prep work has to happen live, submission by submission, and it's usually the slowest part of the process.
Real submissions show up messy: emails, broker portals, PDF uploads, half-filled forms. McKinsey's research on underwriting operations describes teams pulling data out of documents, chasing down what's missing, and pushing cases through multiple stages over days or weeks, way before a model ever gets involved.
So the model itself might return a score in 200 milliseconds – and the underwriter still waits. Maybe three downstream systems each take a few seconds to respond. Maybe a key dataset only refreshes overnight. Maybe the policy record the model needs is still sitting in tonight's batch file, not yet available as a live value.
The model's speed was never really the bottleneck. It's everything that has to happen before the model gets called, and everything the surrounding systems can (or can't) deliver in real time.
The model is fast in both cases. The production workflow adds data retrieval, transformation, validation, and transaction dependencies.
For carriers researching AI underwriting legacy systems, the distinction matters because model latency and workflow latency come from different parts of the architecture.
Where do legacy cores slow down AI underwriting?
Batch processing creates the first bottleneck.
Many insurance core platforms were designed around scheduled processing, reporting cycles, and predefined transaction routines. Older mainframe environments can rely on batch claim settlement and predefined underwriting rules embedded in code, creating constraints for real-time data access and API integration.
A simple example shows how a batch-based core can leave an AI underwriting model working with outdated information:
2:00 p.m. → Property submission arrives
2:05 p.m. → New claim enters the claims system
2:06 p.m. → AI service requests customer data
2:06 p.m. → Underwriting dataset still shows the previous night’s data
12:00 a.m. → Batch refresh adds the new claim
The delay comes from the data path between the live insurance systems and the AI model.
File-based interfaces create another dependency. A scheduled export requires file creation, transfer, validation, ingestion, and reconciliation. Every stage can add waiting time or create a failure point.
Older APIs create a different problem. One underwriting request may require policy status from one service, claims history from another, coverage information from a third system, and customer information from a fourth. The model sees one request. The integration layer may need to coordinate several systems before the request becomes complete.
Separate systems can also disagree. A customer identifier may differ across databases. Coverage dates may use different formats. One system may mark a policy active after another system has recorded cancellation.
As a result, AI cannot decide which source owns the authoritative value without a defined data ownership model.
A useful production diagnostic looks at five timestamps and ownership rules:
These checks separate a model performance problem from an integration or core-system problem.
What can AI do once the right insurance data reaches the model?
Once the model has current, structured data, it can take on the analytical work that used to consume the most underwriter time: extracting fields, classifying submissions, scoring risk, and summarizing evidence.
Take a typical commercial property submission: a broker application, loss runs, inspection reports, financials, and email correspondence. AI can pull the relevant fields out of that stack, classify what kind of risk it represents, score it against approved inputs, and summarize the supporting evidence into something an underwriter can read in a minute instead of an hour.
What AI doesn't do is hold the system of record. It analyzes; the core system still owns state, identity, and authority:
The model performs analysis on the information received. Policy state, transaction history, identifiers, permissions, and core business rules remain system responsibilities.
What can AI not change inside a legacy core?
AI can analyze underwriting data and return a recommendation. The insurance core still controls policy records, transactions, and business rules. The boundary matters once a risk score needs to become an actual policy action.
Policy transactions still belong to the core
A risk score can inform an underwriting decision. Quote creation, binding, issuance, billing, endorsements, and other policy transactions still depend on the systems responsible for those operations.
BCG's 2026 research places core transactions alongside AI, data, integration, and infrastructure as distinct parts of an insurer's technology architecture. The research also stresses the need to connect AI-led workflows with existing modernization programs rather than treating AI as a separate technology track.
Before the model can influence a policy decision, someone still has to turn the score into a transaction the core can execute.
The split is straightforward: AI handles underwriting analysis, the integration layer carries the decision across, and the core records and executes the policy transaction.
Embedded business rules still need a clear path
Many legacy insurance applications contain business rules inside application code, where AI can analyze code, extract business rules, generate process maps, and document dependencies during modernization.
For an AI underwriting service, the practical issue comes after the score. A recommendation still needs to pass through the rules governing policy actions, such as:
- Underwriting authority limits (who can approve what, at what value)
- Rating and pricing rules tied to the policy's current state
- Eligibility and binding conditions
- Referral and escalation thresholds
- Regulatory and compliance checks specific to the line of business
If those rules remain embedded in the core, the integration architecture needs a defined way to invoke the required transaction without bypassing existing controls.
The core remains the system of record
The AI service should not become a second policy administration system. Policy status, transaction history, billing records, and other authoritative insurance records need a defined owner.
A clean division looks like this:
BCG's insurance architecture also separates the AI platform, data services, core transactions, integration, infrastructure, and security controls into distinct technology areas.
The engineering work therefore depends on the boundary. The model handles the analytical decision. The integration layer connects the decision to existing systems. The core continues to execute the insurance transaction.
How can insurers connect AI underwriting to a legacy core?
The right integration pattern depends on the specific constraint.
An API layer can expose selected policy, customer, claims, or coverage data without replacing the core application. The integration service translates between modern requests and older interfaces, validates fields, applies authentication, and returns a consistent response to the underwriting service.
For data requiring higher freshness, change data capture can record updates as source records change. A new claim, policy status update, or endorsement can move into an underwriting data store without waiting for a nightly export.
Confirm the decision actually needs sub-hour freshness before reaching for CDC. It solves a real problem, but it also adds replication lag and monitoring overhead you didn't have before. If a nightly refresh is genuinely fine, CDC is solving a problem you don't have.
A read model can reduce repeated queries across several systems. The underwriting service receives a prepared view containing the fields required for a decision, instead of coordinating several independent requests for every submission.
Event processing can handle time-sensitive changes. A policy update can create an event, an underwriting data service can consume the event, and the next underwriting request can use the updated record.
A production architecture can look like this:
The core remains responsible for policy transactions. The integration layer manages access and data movement. The AI service handles analytical tasks. Each component has a defined boundary.
When does the core itself need modernization?
Integration work can address a data-access problem. Deeper modernization becomes relevant when the core prevents the required underwriting workflow from operating.
Keep the existing core when:
- Policy transactions remain reliable
- The main limitation is external data access, not the core itself
- CDC or event processing can fix slow refreshes, since source systems can expose the required changes
- A read model can fix repeated multi-system queries, since underwriting just needs a stable set of fields from several sources
Consider core modernization when transaction logic, interfaces, data structures, and processing schedules all restrict the target underwriting workflow at once, not just one of them.
Roland Berger reports that core insurance replacement programs commonly range from €20 million to more than €100 million and can run for two to five years. Around half of replacement programs fail to meet time or budget targets. The research also warns that fragmented legacy data can transfer complexity into a new core when data modernization receives insufficient attention.
For insurance legacy system modernization, the technical decision therefore starts with the exact constraint. Faster access to three policy fields does not automatically justify replacing a policy administration platform. A core with rigid transaction boundaries, outdated interfaces, fragmented records, and batch dependencies may require a broader program.
What happens when underwriting data is incomplete?
A production AI workflow needs a defined response for missing or conflicting information. Sending every submission directly to an automated decision creates a weak boundary between model output and underwriting authority.
The workflow can route cases according to specific conditions:
The referral path belongs in the architecture from the beginning. A production AI service needs a controlled response for incomplete information, conflicting records, and decisions outside automated authority.
What should a production underwriting architecture prove?
A production implementation needs evidence for five areas.
Current data
The model must receive policy and claims information within a defined freshness window, sized to the decision it supports.
A renewal risk score can often tolerate a nightly refresh. A referral triggered by a new claim needs something closer to real time. Without a stated freshness target in minutes or hours, the architecture has no benchmark to meet.
Traceability
Each material input needs a source record or a documented derivation path.
If a risk score used a property value, a claims count, and a credit indicator, an underwriter (or an auditor) should be able to trace each one back to where it came from and when it was last updated.
Without this, a model output becomes a number nobody can defend.
Failure handling
A failed external service needs a defined response, not a silent gap. Common patterns include:
- Retry with backoff for transient failures
- Fallback to cached or last-known-good data, clearly flagged as such
- Automatic referral to a human underwriter when required data can't be retrieved
The failure mode should be a design decision made in advance. Waiting until a downstream system times out in production to find out what happens next is not a plan.
Human review
Underwriters need access to the evidence behind a recommendation, not just the score itself, and a clear, low-friction route for overriding it.
If overriding a model requires a support ticket or a workaround outside the normal workflow, underwriters will either stop trusting the model or stop using the override, both of which defeat the purpose.
Transaction completion
An approved decision needs a reliable path back into the core without manual reconstruction.
If an underwriter has to re-key a decision into the policy admin system because the integration only reads data and never writes it, the architecture hasn't actually closed the loop; it has just added a faster way to generate a number that still requires manual work afterward.
The architecture can then be tested through a concrete transaction:
Monitoring also needs specific measures. Data age can expose stale inputs. Failed requests can expose integration instability. Referral rates can show how often automated processing reaches its authority boundary. Transaction errors can expose problems after AI has completed the analytical task.
PwC's 2026 Encova case shows what “modern platform” actually means at scale once a carrier moves off legacy infrastructure. After Encova migrated to Guidewire Cloud and rebuilt its data layer on AWS, the numbers at go-live were not small:
- 5,800 submission quotes processed in the first week alone
- 3.5 billion historical data transactions carried over at go-live
- 140,000+ upgrade artifacts resolved with zero critical defects
That last number matters more than it looks. Zero critical defects across 140,000 artifacts is not a bug-free system; it is proof that the transaction path itself, the thing an AI recommendation ultimately has to pass through, held up under real load.
That is the part relevant to an AI underwriting program. A risk model can be production-ready long before the surrounding insurance systems can supply current information, preserve traceability, and complete the resulting transaction. Encova's numbers describe what "ready" looks like on the systems side. Most carriers are not there yet, which is exactly why the integration layer matters as much as the model.
Production underwriting starts with the data path
A risk score has limited value when the underlying underwriting workflow cannot retrieve current records or complete the resulting transaction.
For one carrier, the required architecture may consist of APIs around the existing core. Another may need CDC and a dedicated underwriting data store. A third may need deeper insurance core system modernization because the core's transaction model prevents the target workflow from operating within the required time window.
The engineering work begins by tracing one real underwriting transaction from submission to final policy action. Once every data request, transformation, decision, and transaction has an owner, the right modernization scope becomes much easier to define.
.svg)
