Read AI Summary
I have spent much of my career alongside CXOs in large financial enterprises, working in the gap between what the business wanted and what the P&L would support. The conversations were rarely about whether the preferred solution was better. Everyone usually knew it was. The practical question was what we could fund, staff and deliver that quarter when four other priorities were already ahead of us.
That is how many of us became skilled at the workaround. A legacy platform could not support a needed capability, so we pulled part of the process into a peripheral system, stood up a portal and built a reconciliation process to keep two versions of the truth aligned. We intended to simplify it later. Usually, later arrived only when something broke or the workaround could no longer carry the load.
I do not look back on those choices as bad decisions. In many cases, they were the only responsible option available. Business leaders understood the bargain as well: a capable team was stretching a limited budget and keeping an important commitment moving. Technology changed slowly enough that a workaround could remain useful for five or six years, which gave the business time to earn a return before the complexity became too painful.
What concerns me now is that the useful life of that bargain is getting shorter. AI capability is advancing faster than the planning, funding and release cycles most carriers were designed to absorb. A new use case can appear before the previous experiment has left the sandbox. Distributors and customers experience the same acceleration outside the carrier, so their expectations are no longer set by an insurer’s release calendar.
Carriers are responding in practical ways. They are adding copilots to legacy applications, exposing services through MCP servers, introducing orchestration across systems and using AI to support service representatives during customer calls. These efforts can improve an individual process and create credible proof points. They are often sensible places to begin.
The difficulty shows up when the organization tries to repeat the success. A productivity gain in one workflow may be real, but boards still struggle to see how a collection of pilots becomes measurable value across the enterprise. The 2025 McKinsey–LIMRA AI maturity survey illustrates the gap: fewer than 20% of the 37 life carriers surveyed had reached scale in any business domain, while 70% were spreading their investments across four or more domains. About half could move from concept to an MVP within six months, yet about half needed more than a year to scale an MVP.
Those findings are consistent with what many teams encounter. AI can improve the experience at the edge while the underlying product, rules and configurations remain difficult to change. A rule that has been implemented separately in administration, distribution, service and compensation still has four owners, four test paths and, potentially, four interpretations. Orchestration can reach each implementation more efficiently, but the coordination burden remains.
Most AI discussions focus on intelligence: whether a model can understand intent, interpret a policy or recommend the next action. For a carrier, the operating question begins once the model has produced a useful answer. How quickly can the organization execute it safely, this year and at meaningful scale?
That depends on ordinary but consequential details. The product capability has to exist. The applicable rule has to be understood across administration, distribution and service. The necessary data has to be available and usable. Someone also has to know whether the change is configurable or whether it requires development, testing and a release slot.
A product manager asked to launch a rider in two states before quarter-end may spend the better part of a week working through those dependencies. She needs to establish which product version each state uses, identify the rules affected by the rider, trace the systems that implement those rules and understand the testing cycles that will follow. An AI assistant may draft the rider language in ninety seconds. That is helpful, but it does not remove the week of organizational work that determines whether the rider can actually launch.
I sometimes use a deliberately simple test with leadership teams: how many people does it take to change the light bulb? In practice, that means counting the stakeholders, systems and release windows required for one product change, regulatory update or AI use case to reach production. The answer gives a fairly honest view of the organization’s current capacity for change.
Compensation is a good example because a distributor’s request can cross several parts of the operating environment. A new override structure or a bonus tied to persistency may involve the compensation engine, distribution hierarchy, product configuration, policy administration, payout and tax reporting. Each part may be owned by a different team. If the arrangement also requires a new product option, the request can trigger another product version and another round of testing.
Regulatory change creates a similar burden. When the same requirement has been interpreted and coded in five systems managed by three vendors, one change becomes several projects. The work is not limited to implementation; teams must also keep the interpretations aligned and demonstrate that alignment to compliance and audit.
AI can enlarge that governance surface. Every capability attached to a different system introduces another set of decisions about testing, monitoring, access, model behavior and examination readiness. A carrier may approve ten valuable use cases and discover that it has also created ten separate governance routines. The cost recurs as models, products and regulations change.
Insurance technology evolved in layers for good reasons. A platform administering a promise that may last forty years cannot be replaced casually. Conversion risk is real, and extending the useful life of a stable core can be the prudent choice.
AI changes a different part of the economics: it reduces the time and cost required to produce new code, workflows, interfaces and integrations. That gives teams more options, but it also removes a natural brake on the number of accommodations an organization can create. A new workflow built around a hard-coded product inherits the constraints of that product. An interface that calls one of several versions of a rule inherits the interpretation held by the selected system.
An agent may detect that four systems disagree, which is useful information. Resolving the disagreement still requires ownership decisions, system changes and testing. If the organization cannot do that work, the inconsistency is documented and the process continues using whichever version is available in the system being called. The workaround has become easier to operate without becoming easier to retire.
This is why I pay more attention to the second and subsequent use cases than to the first. Two approaches can produce a successful pilot and look equally promising in a strategy update. Their economics start to separate only when the organization tries to reuse what it built.
If each use case brings its own workflow, integration and governance path, later implementations carry more connections to manage, reconcile, certify and regression-test. Adoption adds cost. When an implementation leaves behind an approved rule, a reusable component or a governed service, the next team begins with something it can use. The benefit is not that the tenth use case is literally free; it is that the carrier is no longer paying repeatedly to recreate the same business capability.
Orchestration will be part of any carrier’s AI environment at scale. It coordinates work across systems, routes requests, invokes trusted services and brings people into the process when judgment is required. Its value, however, depends heavily on the capabilities available underneath it.
In an environment of duplicated rules, overnight cycles and highly customized products, orchestration makes existing capabilities easier to coordinate. That may be enough for an interim objective or to extend the life of a platform. In an environment built around versioned rules and configurable, reusable services, the same orchestration layer has more room to create cumulative value because later processes can call capabilities that have already been approved and tested.
Both environments may offer a smoother user experience. They carry different long-term costs of change, and that distinction is easy to miss when success is measured one project at a time.
Systems of record remain essential. They maintain contractual truth, preserve policy history and execute transactions that must be accurate every time. AI is adding systems that can interpret information, recognize intent and recommend action. Between those functions, many insurers still need a more deliberate way to turn intent into governed, executable change.
I think of this as a system of change rather than another layer of workflow. Its purpose is to make business capabilities adaptable across the estate. In practical terms, that means:
• assembling products from approved, reusable components instead of repeatedly encoding the same capability;
• versioning rules, rates and agreements so the carrier can establish what applied to each policy;
• publishing a change consistently across administration, distribution and service; and
• making governance part of the way a change is created and released.
Orchestration still has an important job in this model. It coordinates the action. The additional capability makes the business elements behind that action easier to change, reuse and govern.
AI and orchestration will extend the life of many legacy platforms, and in some cases that is exactly the right decision. The issue is whether a short-term accommodation is being treated consciously as an interim step or is quietly becoming the next long-term architecture.
Many of these decisions have become muscle memory for us. Before approving the next initiative to add an AI layer, I would ask four questions:
• Will the underlying business capability become easier to change, or will this initiative primarily make the current implementation easier to access?
• What will the next product launch, regulatory update or customer journey be able to reuse?
• Which dependency will be removed, and which new dependencies will be introduced?
• Can the outcome be governed consistently across products, channels and policy generations?
Answers that point only to a better interface or a faster individual task may still justify the investment. They should also be recognized for what they are. The carrier has improved the operation of its current environment; it has not yet increased its underlying capacity for change.
AI is making the distance between an insurer’s ideas and its ability to execute them much more visible. Orchestration helps teams work across that distance, and it will remain valuable. The longer-term opportunity is to reduce the distance itself by leaving behind products, rules and services that the next initiative can change and reuse. That is how we keep yesterday’s sensible workarounds from becoming tomorrow’s operating model.
