The AI Acceleration Tax: Why Every New Capability Makes Switching Insurance Platforms More Expensive

The lowest licensing figure in a core platform evaluation is frequently the single most expensive decision a carrier will make over the following five years. That is not a rhetorical inversion. It is an arithmetic one. The driver is a cost most carriers do not yet carry on a spreadsheet: the AI Acceleration Tax.

The tax is a recurring, compounding operational penalty that grows with every AI capability a carrier ships. Pick a platform on a short-term licensing discount, and when its roadmap stalls, it has to be ripped out and replaced within thirty-six months. The migration, parallel-run, retraining, and recertification costs that follow routinely accumulate to several multiples of the original saving. A continuously evolving, modular core carrying a higher initial price consistently delivers a lower five-year total cost of ownership than a cheaper platform that must be replaced in three years.

Here is the part nobody in the industry says out loud. The more successfully a carrier adopts AI, the less free it is to leave the platform underneath it. That is not a defect. It is the nature of the technology. Every model trained, every workflow automated, every embedding indexed is a weld, not a bolt. The sector has celebrated AI adoption velocity without conceding the corollary: that velocity is also the rate at which exit cost compounds. A carrier that has “won” at AI on a three-year platform has not built an asset. It has built an anchor and paid a premium for the privilege. This article quantifies that anchor, models it against a five-year TCO, tests it against a live carrier result, and then shows how to make sure the platform that wins on paper keeps winning.

How Has AI Changed the Cost of Switching Insurance Platforms?

AI raises switching costs because models, data pipelines, and workflows fuse deeply into the platform, so the more successfully a carrier adopts AI, the more expensive leaving becomes. In legacy software cycles, moving core databases was a linear, tedious, but well-understood data-mapping exercise. It also created an appealing logic: if AI lowers the cost of building software, then buying the cheaper, more rigid platform should lower total cost too. That assumption is now a logical error.

Structured schemas can be mechanically translated. Cognitive systems cannot. Once an underwriting or claims model begins consuming native platform features and writing decisions back to the core ledger, the model becomes an inseparable part of the decision-making apparatus. AI does not just sit on the platform. It fuses workflows, data pipelines, proprietary models, and human operating habits together faster and deeper than any prior technology permitted.

We can now measure how far along carriers are, and the ones furthest ahead have the most to lose. BCG’s 2025 analysis of AI in insurance found that only about 7%¹ of carriers have successfully scaled their AI efforts, while roughly two-thirds remain in piloting. What separates the 7% from the two-thirds still piloting is rarely raw capability; it is the readiness to operationalize AI across the business, the discipline that turns pilots into production.

However, the seven percent is the group for whom a mid-cycle platform switch would be most destructive, because for them the embedding is real, load-bearing, and in production.

That leaves a strategic choice. Does a carrier minimize near-term capital by choosing a lower-cost, static core that must be replaced in three years, call it Platform A? Or does it commit to a higher initial investment in a continuously evolving platform engineered for native model adaptability over five years or more, call it Platform B?

What Makes Switching Insurance Platforms So Costly?

Switching is costly because lock-in accumulates across four layers: process integration, AI-specific model and data assets, people and training, and governance recertification, with each layer raising the exit bill. The friction of leaving an established core is multi-dimensional, and it escalates.

Layer 1: Process and Operational Integration

Operational lock-in begins with the daily transaction machinery: custom APIs, automated reporting schedules, and thousands of data-validation and business rules aligned to a specific platform’s data model. Over years, underwriters and adjusters build deep interface muscle memory. Tearing out this layer means rebuilding every custom integration, reauthoring the rule base, and absorbing the throughput loss of a workforce relearning its primary tool. McKinsey’s² 2026 work on core modernization finds that in most insurance migrations, rewriting code or configuring the target platform is only a small portion of the work. The disproportionate share sits in data conversion, quality control, reconciliation, operational readiness, and post-migration stabilization. The license is the cheap part. The embedded layer is the expensive part.

Layer 2: The AI-Specific Lock-In

IT migration playbooks do not cover this layer, and it is the primary engine of the compounding tax. It is also where embedding runs deepest, as carriers wire AI agents directly into underwriting and claims decisions.

Model revalidation and retraining. Models trained on proprietary history are optimized for the specific data structures, features, and noise of the native platform. A move invalidates those underlying assumptions, forcing a full retrain, retest, and revalidation of the underwriting and pricing portfolio to prevent silent performance degradation.

Platform-shaped feature stores. Feature registries, time-travel pipelines, and transformation logic that keep training and real-time serving consistent are highly platform-dependent. A new core forces a rearchitecting of the entire data supply chain.

Vector embeddings and semantic drift. Retrieval and semantic-search tooling represents unstructured claims notes, medical records, and policy documents as high-dimensional embeddings. Change the core or the underlying embedding model and historical vectors become incompatible, forcing either an expensive full reindexing of the document estate or the costly parallel maintenance of mismatched vector stores.

Prompt and orchestration logic. Agentic workflows depend on prompt libraries, system instructions, and tool-calling structures tuned to a specific model context. Ported to a new architecture, they regress, requiring exhaustive manual re-tuning and evaluation to hold output quality.

MLOps and monitoring. Drift detection, latency tracking, and data-quality monitoring must be rebuilt from zero to match the new core’s telemetry and log formats.

Model risk documentation. Validation history, dataset provenance, and conceptual-soundness records reset to day one, consuming hundreds of engineering and validation hours to reproduce compliance-ready packages.

Layer 3: People and Knowledge

Beyond code, a switch demands a human-capital reinvestment: re-certification programs, thousands of pages of rewritten training material, and rebuilt knowledge repositories. This layer surfaces as a prolonged drop in operational velocity while staff adjust, and it is routinely left out of the business case.

Layer 4: Governance and Compliance

The regulatory environment has made this layer materially more expensive than it was even eighteen months ago, and the timing is the point. In the United States, more than two dozen states have adopted the NAIC Model Bulletin3 on the Use of AI Systems by Insurers, with Colorado and New York imposing binding rules. That expectation now has an examination apparatus behind it. The NAIC AI Systems Evaluation Tool pilot⁴ runs from March to September 2026 across twelve states, including California, Colorado, Florida, and Pennsylvania. It probes carriers on four fronts: AI usage inventory, governance framework, high-risk system detail such as underwriting and pricing models, and data provenance. Adoption of the standardized tool is expected at the Fall 2026 National Meeting, after which every state department can deploy it.

In Europe, the EU AI Act5 classifies AI used for risk assessment and pricing in life and health insurance as high-risk under Annex III. The core obligations for these systems, risk management, data governance, technical documentation, logging, human oversight, and post-market monitoring, apply from August 2, 2026.

A core switch resets the governance audit history to zero, forcing full reattestation and recertification across every integrated algorithm, and it does so precisely as oversight tightens. Every model deployed, every vector store populated, every prompt refined adds to the exit bill.

Does a Continuously Evolving Platform Really Have a Lower Five-Year TCO?

Yes. On an illustrative model, the evolving core costs about 78 percent less over five years, because the cheaper platform absorbs productivity and opportunity costs twice through forced replacement.

The way to end the argument is to price it. The model below compares five years of costs for each platform, using a sample department of 100 underwriters who cost the company 150,000 dollars each per year, all in, or 15 million dollars annually. Because money spent in future years is worth less than money spent today, the model adjusts every future cost back to its present-day value at a standard 10 percent rate. The numbers below are inputs, not findings. Their job is to show the method, not settle the answer. Two assumptions move it more than any others: how badly productivity drops during a switch, and whether the evolving platform actually keeps evolving.

Three assumptions carry the argument:

• The transition productivity dip (the J-curve). Platform A, the cheaper platform replaced every three years, triggers a severe temporary drop in throughput during each rip-and-replace, across a twelve-to-eighteen-month stabilization window. The model assumes a 30 percent annualized productivity loss in the replacement years. Platform B, the continuously evolving core, confines change to minor localized updates, modeled as a 1.25 percent annualized dip.
• Opportunity cost of deferred capability. While your engineers are busy getting the new platform to run properly, your competitors keep launching new features. The model books 3 million dollars annually in lost premium growth and delayed risk segmentation during transition and stagnation years. This is not a soft number: McKinsey6 research finds that digital leaders in insurance grow revenue roughly five times faster and deliver about twice the total shareholder return of their peers.
• Regulatory recertification. During a transition, the carrier must rebuild its compliance documentation and bias-testing protocols to meet NAIC and EU AI Act expectations. The model treats this as a six-to-twelve-month effort carrying 800,000 dollars in direct validation cost.

On these inputs, the continuously evolving core delivers about 15.4 million dollars in savings, a 78 percent lower five-year TCO, despite a sticker price roughly double Platform A’s. But the single number is the least useful thing in this section. The more useful question is which inputs move that number, and where the answer flips.

Two inputs govern the entire result. The first is the productivity drop during a switch. The 30 percent figure above is deliberately harsh, but even at half that, 15 percent, Platform B still wins clearly. The reason is simple: the cheaper platform forces you through that drop twice in five years, once for each replacement, while the evolving platform takes only a small, one-time hit at setup and nothing after.

The second is vendor decay, the rate at which the evolving platform’s roadmap actually stalls. This is the honest break-even. But this only holds if the vendor keeps improving the platform. If they quietly stop, and Platform B stops evolving by year three, its advantage disappears. A platform that promised to keep getting better but didn’t is just a more expensive version of Platform A, and you will still have to replace it eventually.

The model proves something narrower: evolving platforms win only for as long as they genuinely evolve. The productivity math is decisive; the vendor-behavior assumption is the risk, which makes the platform decision and the contract behind it one decision.

One objection is that the dips are overstated and error rates stay within tolerance. That misreads the risk. The model’s largest lines are not error costs. They are the productivity and opportunity costs of a stabilizing organization, and those are incurred whether or not the migration is technically clean. A flawless migration still stops the clock on new capability for a year or more.

The model is only as good as its most disputable assumption. So it is worth testing against a carrier that actually made this choice.

Proof: How a UAE Carrier Reached 70% Faster Issuance Without a Big-Bang Replacement

Three to five business days to issue a medical policy. That was the number a leading UAE-based multi-line national insurer, operating since 1996, had learned to live with. Not because its people were slow, but because its operational intelligence was trapped in fragmented, manual, legacy-bound systems that could not talk to each other or to the regulator. All this while the business needed to expand across individual, SME, and group health schemes into a tightening compliance regime. The reflex in most boardrooms facing that bottleneck is to rip it all out and start clean. But Damco took a different approach.

Rather than pushing the carrier toward a high-risk, multi-year rip-and-replace, Damco deployed a modular, configurable digital core on the InsureEdge platform, engineered to expand by configuration rather than reconstruction. Across three decades of insurance modernization engagements, Damco has found that the mechanism which avoids the AI acceleration tax is the preservation of intact data contracts. Therefore, the implementation established direct connections to the regional regulatory and administrative bodies the carrier depends on, including the Abu Dhabi Department of Health reporting platform (DOH/Shafafiya), SLASH-Data, the Ministry of Interior, and its third-party administrators.

Damco then introduced straight-through processing, digital KYC, and real-time premium calculation incrementally against that stable foundation. This sequencing was deliberate. In Damco’s experience, the deciding factor is rarely the feature set; it is holding the data-contract layer stable while evolving the processes above it. That is precisely what keeps the four-layer switching cost from ever being triggered.

The results are consistent with the model’s claim that continuous evolution outperforms replacement:

• Policy turnaround fell from three-to-five days to under twenty-four hours, a 70 percent acceleration in issuance.
• Manual administrative effort dropped 60 to 70 percent through end-to-end automation.
• Reconciliation errors fell 80 percent through automated financial postings.
• The customer and broker portal reached 100 percent straight-through processing, with sustained compliance against GCC medical regulations.

The mechanism matters more than the metrics, because the numbers are specific to this carrier but the mechanism is not. The carrier did not win by choosing a better rip-and-replace. It won by not needing one: a modular core, configured rather than rebuilt, added capability against data contracts that stayed intact, so each increment paid off immediately instead of after a multi-year stabilization.

The boundary condition is worth naming, because it is where the same approach would have failed. Incremental evolution works only when the underlying core is genuinely configurable and the integration layer is stable enough to build on. A carrier attempting this on a rigid, tightly-coupled legacy core would have taken the disruption of change without the compounding return. The carrier now sits on an evolving core rather than a depreciating asset, positioned to add capability without re-platforming.

This is the constant-change model McKinsey identifies in its build-versus-buy work. Carriers on continuously evolving platforms gain faster implementation and greater innovation because the vendor drives ongoing evolution. One-off builds, by contrast, tend to lock innovation in at go-live, and when overruns hit, they leave the organization unable to evolve at all.

When Should an Insurer Replace Its Platform Instead of Evolving It?

Replace when the core’s language talent pool collapses, when tight coupling makes API access costlier than a new platform, or when a vendor sunsets the product, ending security support.

The question is how to modernize the core: through continuous evolution or a full replacement. Replacement remains the correct path under specific, terminal conditions.

• Replace when the core runs on a language whose talent pool has shrunk below an operational threshold, driving maintenance premiums to unsustainable levels.
• Replace when the data structure is so tightly coupled that exposing modern API endpoints or extracting clean data for AI consumption would cost more in custom middleware than a new platform.
• Replace when a vendor sunsets the product, ending security patches and exposing the carrier to breach risk and rising cyber premiums.

But staying is not automatically the safe choice either. Be honest about the failure mode of the recommended path: an evolving core without disciplined internal model governance does not stay clean. It accumulates a decade of half-migrated models and undocumented configuration that can become harder to reason about than the legacy system it replaced. Continuous evolution is a capability the carrier has to earn, not a property the vendor ships.

And there is a deeper risk in staying. Assume the vendor is lying. Not maliciously, but structurally. “Continuously evolving” is the promise every incumbent makes and the fewest keep, because a vendor’s incentive to keep shipping shifts the moment your switching cost exceeds your leverage. The predictable pattern is a strong roadmap for the first two years, an acquisition or a strategy pivot around year three, and a platform that is evolving in the release notes and stagnant in production by year four. This is the same vendor-decay risk the break-even analysis isolated, and it is the single assumption that can flip the TCO case. The conclusion is narrower: the evolving platform wins only if you can force it to keep evolving, and that force is contractual.

Which is why the contract, not the architecture diagram, is where this decision is actually won or lost. Marketing labels like “cloud-native” and “API-first” are table stakes that protect no one. The criteria that derisk the choice are the ones a weak vendor will resist putting in writing, because they convert “we will keep evolving” from a slide into an enforceable obligation.

What Should Insurers Prioritize When Choosing a Core Platform?

Insurers should optimize for a five-year competitive position, not the quarterly license price, choosing an architecture that continuously absorbs innovation and pricing the full switching cost before committing.

The strategic question is how to secure a five-year competitive position on an architecture that can absorb innovation continuously. Every model fine-tuned, every feature store engineered, every agentic workflow optimized increases the structural gravity of the core. That is why selecting a platform on a three-year sticker price is a mathematically demonstrable path to disruption and capital loss.

The way to make that decision defensible is to price it. The worksheet below converts the qualitative risk of the tax into an audit-ready figure a CFO and CIO can own jointly.

The 5-Year TCO Valuation Worksheet

Run the cheaper platform through every line, not just the first, and the tax becomes a number.

The platform decision determines how much of the next five years a carrier spends building rather than rebuilding. Capability shipped onto the right core compounds into an advantage; onto the wrong one, into an anchor. Price it before the discount on the evaluation sheet decides for you.

Sources:

• [1]: BCG
• [2]: McKinsey
• [3]: Mayer Brown
• [4]: NAIC
• [5]: EU AI Act Compass
• [6]: McKinsey