Insurance carriers have never been better equipped to build software. So why does delivery still take so much time? Changing a business capability like policy issuance or claims adjudication requires understanding how the existing system works — and that understanding is rarely in one place.
A single endorsement change can touch policy administration, billing, document generation, and downstream integrations, with the rules governing each embedded in systems, documents, and the memories of the people who maintain them. This level of fragmentation is a natural consequence of how carriers evolve, but it costs them in delivery time and modernization risk.
However, incorporating artificial intelligence (AI) into the software delivery workflow can help connect the dots. Work that was once too expensive to perform continuously, such as analyzing documentation at scale or tracing business rules back to the code that enforces them, is becoming practical as AI matures. An assisted understanding model, in which machines maintain organizational knowledge and people exercise their judgment over what to do next, can help insurers rethink their approach to software delivery.
Rethinking Insurance Software Delivery With AI
Most discussion of AI in software delivery centers on code generation. Copilots suggest implementations, draft tests, and accelerate the mechanics of writing software.
That value is real, but carriers rarely stall because engineers cannot write code quickly enough. Research on program comprehension has found that developers spend most of their time understanding existing code rather than writing it; editing accounts for a small fraction of the work. Assisted understanding describes something narrower and, for most carriers, more useful.
Here are five ways insurers can leverage AI to transform their software delivery:
1. Analyze Documentation Against What Systems Actually Do
Most carriers have documentation. What they lack is confidence that it still describes production. Requirements written for the last core system replacement, architecture diagrams produced during a migration, and process documents maintained by teams that have since reorganized all describe a system as it existed at a particular moment. But the system kept changing after the documentation stopped.
AI can read across those artifacts and the code that implements them, comparing documented underwriting rules against what the rating engine actually enforces and identifying where the two have separated. The value is largely in timing. Carriers typically discover this drift midway through a project, after estimates are set and commitments are made. Continuous comparison surfaces it while it remains an input to planning rather than a surprise during delivery.
2. Surface Dependencies Across an Entire Capability
A claim begins at first notice of loss and ends at recovery, passing through coverage verification, adjudication, vendor and medical data exchange, and payment along the way. Getting there means moving across core platforms, a rules engine, document generation, external data providers, and manual steps that appear in no architecture diagram. Each team along that path knows its own portion well. But typically, no one has the entire process documented, which is why claims modernization so often uncovers work no one scoped.
That absence has never been anyone’s fault, because no team had reason to assemble a view that spans all of it. AI can trace the relationships across systems, integrations, and data flows and produce one. This comprehensive view can help prevent situations where a change in one place creates consequences somewhere nobody thought to check, turning a modification that looked straightforward into a multi-quarter effort.
3. Identify Inconsistencies Before They Reach Implementation
Ask three people how a rule works and all three answers will differ. An underwriter explains it as it was intended. A support engineer describes the exception that has been running in production for six years. A business analyst repeats the version that appeared in the last requirements package. Every answer is offered in good faith, and no one in the room necessarily knows the three accounts disagree.
Those contradictions tend to stay buried until code written against one interpretation fails a test written against another, at which point resolving them costs a sprint instead of a conversation. AI can compare stakeholder descriptions and the rules systems actually enforce. While machines don’t settle disagreements, they unearth them and direct discrepancies to people who can resolve them.
4. Turn Support Activity Into Connected Knowledge
Support engineers know things the requirements never captured. Which claims fail at coverage verification and why, which policy configurations generate recurring exceptions, which workarounds stopped being workarounds years ago and quietly became the process, etc. That knowledge describes how the capability actually behaves, and it is more current than any document describing how it was meant to.
Almost none of this knowledge reaches the teams planning the next enhancement, because nothing connects a ticket queue to a project backlog. Application management sits at the end of the delivery line, and what accumulates there tends to stay there. AI can analyze incident history and support activity, surface the recurring patterns, and link them back to the systems and business rules involved, so operational experience starts informing what gets built rather than terminating where it was recorded.
5. Preserve Understanding Between Initiatives
Discovery is treated as something a project does. A team reconstructs how a capability operates, the project consumes that understanding, and the understanding disperses once the team moves on. The next initiative starts over, often within the same platform and sometimes with several of the same people, which is a pattern CIOs have described as decades of modifications with limited in-house knowledge of what was built or why.
That cycle has persisted because maintaining the connections between requirements, code, operational behavior, and business rules often costs enough to require a project to justify it. That is no longer the case. Understanding can carry forward instead of being rebuilt. The difference shows up in the first weeks of a project, when a team inherits a current view of the capability, rather than assembling one from scratch, and discovery turns toward what should change.
None of these five use cases for AI in software delivery removes judgment from the process. Instead, assisted understanding changes how much effort is spent before expert judgment can be applied.
Starting Where Rediscovery Costs the Most
Reinventing software delivery with AI does not diminish the value of experienced humans. Machines are effective at holding context at a scale no individual can match, but judgment does not scale that way, nor does it need to.
Determining which risks are acceptable, which trade-offs are worth making, and whether a change is ready for production are all decisions that require human accountability. What changes with assisted understanding is how much of an expert’s time is consumed piecing information together before their expertise comes into play.
Carriers can begin where rediscovery is most expensive, which is usually the platform where every enhancement opens with weeks of investigation or the capability that no one can currently explain end to end. The measure of progress is straightforward. Delivery teams should spend less time establishing how a capability works and more time deciding how it should change.
For a broader view of how AI has developed within the industry and what is coming next, read my ebook, “The History of AI in Insurance and Where It’s Headed.”
