An underwriter writes a $5 million commercial auto liability policy for a large trucking fleet and sees it as a big win, especially if the fleet doesn't incur any losses until the second, third or fourth year. However, the insurer hasn't really made $5 million. Instead, it has assumed years of potential liability that could ultimately make the policy woefully unprofitable.

Research from the American Transportation Research Institute (ATRI) released in May shows why. Per-mile liability losses rose an average of 33% between 2021 and 2024 due to a sharp rise in crash claims expenses, despite a 2.6% reduction in crash rates involving heavy-duty trucks.

It only takes one serious accident to turn a sure win for a carrier into a stinging underwriting loss. That is why insurers should take these three steps to assess a commercial auto client's risk management practices and determine whether its fleet demonstrates the operating discipline required to reduce its risks throughout the policy term.

Step 1: Look Beyond Historical Loss Runs

One of the biggest challenges underwriters face when reviewing commercial fleets is selecting and pricing a policy based solely on past performance. While historical loss runs may seem favorable, subpar claims processes will amplify loss severity in the event of a reportable incident.

Strong claims management is an equally strong indicator of future performance. Fleets that recognize an incident, report it and respond by improving both operational and risk management practices will perform better over time.

During underwriting, insurers should review each prospect's claims processes in detail. Ask how quickly they identify and report claims and whether they have any policies in place for investigation and escalation. Explore whether they use data to recognize recurring accident patterns and look for evidence the fleet has changed its procedures or behaviors based on their claims experience. Use the answers to objectively assess how responsive the fleet is likely to be throughout the policy period.

Step 2: Review How Fleets Use Data

Telematics, on-board camera systems, electronic logging devices (ELDs) and other monitoring systems provide fleets and carriers with a wealth of operational data. Yet the mere presence of these technologies alone does not necessarily make a fleet more insurable.

To see why, consider telematics devices. They deliver a seemingly endless stream of data points, from GPS location and vehicle speed to engine hours, fuel consumption, hard braking, harsh acceleration and following distance. There is so much data, however, that fleets can become overwhelmed quickly. They may not know which data is most important, and they might not have a set process for using that data to improve driver behavior and reduce their risk for accidents.

For these reasons, both carriers and brokers should look beyond a fleet's technology adoption when assessing a client's insurability. Underwriters should ask which data points a fleet monitors, who reviews them and what triggers an intervention. Fleets that manage their risks well will focus on a small handful of meaningful data points, then use them to tailor their continuing training efforts to each driver based on their individual behaviors.

Brokers have a complementary role. If they find a prospective client is experiencing data paralysis, they should partner with carriers with a proven track record of helping fleets make their vehicle safety data actionable. Doing so will position brokers as trusted advisors to their clients while also helping their carrier partners write profitable business.

Step 3: Use Technology to Identify Leakage

A fleet can look like a favorable risk when the policy is bound. It can also become unfavorable six months later. To understand why, consider a carrier that insures 100 trucks, but the fleet actually has 150 power units operating on the road. If the policy is priced on a per-power-unit basis, the carrier is taking on extra exposure it never priced.

The challenge for most insurers is finding those extra vehicles before a claim or renewal exposes the problem. Some carriers are solving this by developing proprietary AI tools that can compare scheduled vehicle data with inspection and operational records. If a vehicle identification number (VIN) shows up in the records but not on the policy, the carrier can talk with the client, find out why and add the vehicle to the policy midterm if applicable.

While AI can stop leakage, carriers should also realize technology should not replace human judgment. Predictive models can help insurers analyze more accounts and surface risk signals faster, but greater underwriting volume does not necessarily mean better underwriting. Experienced professionals must still determine which specific underwriting criterion matters the most.

Insurability Is More Than Pricing Risk

With premiums and claims costs continually rising, carriers can no longer focus solely on rising rates. They must also reduce their losses. Insurers that thoroughly assess a fleet's loss history and claims processes, help it use data to improve driver safety, and check in regularly to prevent leakage will write good business and reduce claim frequency and severity, thereby creating more value than pricing adjustments alone.

Every enterprise AI pilot depends on two separate tracks to run smoothly for success. Both tracks require thoughtful planning and execution, but many companies fall short, and their AI pilots fail before they begin.

My team spent months on a proof of concept for a large insurer. This potential client created a bake-off scenario with high stakes: our document processing system, based on AI small language models, against their internal build and a leading frontier model. Their test would use their charts, images, handwritten notes, etc. and be scored on their terms. We won, and not by a little.  

The deal died anyway. Not on our side of the table, but on theirs. What happened? They didn't have a funded business case, an approved timeline, or a budget line waiting on the other side of the demo. Our champion was sharp and genuinely bought in, but he didn't directly own the business line, and without that he had neither the budget nor the political capital to carry the work across the organization. When the business case finally went up the chain, it didn't get the backing it needed, and it missed. Months of their work and ours evaporated.

It was frustrating for everyone, and it was entirely avoidable.

In the months and years since, I've run dozens of these demos, mostly in insurance for claims, underwriting, and submission intake. The most crucial advice I have for every executive greenlighting an AI project is to understand that every pilot runs on two separate tracks, and they have almost nothing to do with one another.

Track one is technical. Can it work? How accurate is it? Does it fit the architecture, clear the security review, connect to the systems you already run? This is the track everyone obsesses over. It's where vendors compete, where the POC is scored, where the demo lives.

Track two is the business. Is there a funded case? An owner with authority? An approval path, a realistic timeline, a budget that's still there when next year's planning cycle hits? Who actually signs, and can they? This is the track that decides whether anything ships, and it's the one almost nobody staffs.

Here's the trap: winning track one tells you almost nothing about track two. A dazzling demo feels like progress, so everyone relaxes, but the fact is you've only cleared half of the problem that was never really in doubt. We won track one decisively for that insurer, and the pilot still died because no one was running track two with the same seriousness.

The uncomfortable part about my side of the table? Vendors are paid to win track one. The entire machinery of a POC, mine included, is engineered to produce an impressive technical result. Almost none of it is built to produce a funded production plan, because that's the customer's job, and unless a leader explicitly hands it to someone it doesn't belong to anybody. The result is two parties pouring themselves into the demo and neither one carrying the business case. The pilot succeeds. The initiative stalls. The post-mortem blames "the technology," which is usually the one thing that actually worked.

Sometimes the roadblock appears after you've "won" the client. A partner of ours sailed through the evaluation and moved into real use, and then they hit the roadblock. The rate limit on their plan was well below what production needed to run their document count. The technology worked, but they were missing a throughput plan. They neglected the commercial terms of their project; they didn't have a who-pays-for-scale conversation, also known as track two. It was never started because the "win" made everyone on their team feel as if the project was finished.

So what do success stories look like? Here's what's humbling as a technologist: my production successes run on the same technology as my graveyard. They use the same models with the same accuracy. The deciding factor isn't track one.

One of my most successful clients is a high-volume document operation that is running in production against a real backlog. From day one their leadership ran track two out loud. There was a clear, identified pain point and a commitment to the project with a budget to fix it. There was a named owner who could say "yes, integrate it," and mean it. The success criteria were concrete. And when we later hit a genuine platform limit, they escalated it into a road map conversation instead of using it as an exit. Their success can be traced to their strong leadership.

So, if you're about to greenlight an AI pilot it's critical to understand that track two will decide whether your project succeeds or fails before you hit the finish line.

You need to ask, and answer, specific questions before you begin. Who owns this project in production? Name an actual person who will hold accountability because the moment responsibility is spread out among a committee your project will stall. Who can be the executive to say yes and sign the check? It needs to be someone with the political standing in your company to see it through, rather than the person most enthusiastic about the project.

What's the funded path and timeline to scale if the project works? This needs to be decided before the kickoff because "if it works" is exactly when these projects tend to die.

Go ahead and run track one to prove it's possible. But you also need to fund, staff, and lead track two from day one. It is a mistake to hand over the entire project to an employee who is enthusiastic but doesn't own the line of business, no matter how much they believe in it.

The technology will do its job. The real question is whether anyone built the plan to see the project through.

The growth of cloud computing and the amplified use of artificial intelligence across different industries has fueled the creation of massive, state-of-the-art data centers, and with that, increased the need for innovative property/casualty industry solutions to meet nontraditional insurance exposures.

Data centers, which process and store large amounts of essential information, tend to be warehouse-sized facilities that house computer servers and require significant cooling, power backup, fire suppression and security systems. Initially, their proliferation was seen in the 1990s with the rise of the Internet, but the current expansion is unfolding at a much larger scale and even faster pace, fueled by billions of dollars in private investment and federal directives to fast-track certain projects.

Larger data centers, or "hyperscale" data centers, are drawing the greatest attention and scrutiny because of their size, rapid growth and substantial impact on local communities. Given the customized technology that's in these data centers and the fact that they'll be very hard to replace and difficult to repair, any kind of covered cause of loss that keeps any of these data centers out for any significant period of time would likely cause a significant financial loss, and business interruption is one of the main prospective causes of loss. Contingent business interruption comes into play as well as in these scenarios: it's not just AI companies that would be losing revenue it would also be the clients that are leasing services from these AI companies that are losing their business. Disruptions to data center operations would create a domino effect.

Insurance considerations should come into play from the very start of the planning and building of a data center. Builders' risk exposure is high with the potential for physical damage to the data center during its construction. Supply chain issues or labor shortages that affect the construction industry, especially acute issues in a specific state or region, could be problematic for insurers of data center builders or owners of completed data centers. Depending on the area where these facilities are constructed, they could put a significant drain on locally available skilled labor or construction expertise.

Once built, a data center could experience first-party financial loss stemming from a direct, covered cause of loss; for example, a fire that damages the physical structure, and its interior components (e.g., computer servers and other equipment) and other contents. Because the data centers use servers that generate unprecedented heat loads, the risk of ignition is higher than in traditional large commercial facilities such as warehouses. Physical damage from failed systems outside the data center, such as an off-premises power failure, could create an insured loss as well depending on the property coverage extensions within an insured's policy. Commercial property coverage would also be necessary to cover damages from other natural or man-made disasters.

From a general liability standpoint, any bodily injury or property damage to third parties from a fire or explosion at the facility could create major losses, and from an environmental liability standpoint, if there's any discharge associated with the operation of the center that contaminates the water supply of the surrounding communities, that is another liability exposure.

Another obvious potential exposure to loss concerns cyber. Losses from failed or inadequate cybersecurity could be costly, especially if any of these data centers are housing proprietary, private or sensitive information of any type.

At the same time, data center development can create significant economic opportunities, including numerous jobs for technicians, electricians, facility managers and other local building trade workers. State and local governments can also benefit greatly from property and sales taxes associated with these centers. Overall, the benefits of data centers should ultimately be weighed against public costs.

The risks posed by data centers apply beyond the United States and are generally the same in international markets. These data centers built internationally will also need to satisfy domicile-specific regulations, such as those related to cybersecurity, the environment and diverging online content regulation.

Time will tell if insurance supply can keep up with demand. The sheer size of hyperscale data centers necessitates (re)insurers making determinations concerning their risk tolerance and where their preferred placement is within a layered property insurance program. Innovative structures such as captive formations could become part of the picture, but clearly, as data center development and construction spreads, required insurance coverage should evolve as it is currently beyond what the traditional property/casualty industry has previously experienced. Setting risk tolerances and building a history of loss experience are all factors in developing needed underwriting expertise.

Given the significant capital required to finance data center infrastructure projects, insurers may have exposure on the asset side of their balance sheets through private credit investments, private equity partnerships or other financing arrangements. Insurance investment managers also will need to monitor associated risks closely, including regulatory changes or legislative developments that could affect the long-term performance and viability of these investments.

With AI becoming a more critical component for society in general, how well the headwinds associated with the availability and affordability of energy to power data centers are addressed will be of major importance. Insuring these facilities will continue to be a complex undertaking involving an integration of multiple coverages, some of which will be needed in phases as different stages of data center development are completed.

A head of claims operations walks the executive team through the results of an AI-assisted document review rollout: a sharp, real cut in average review time. The room comes alive over it: not skeptical, enthusiastic. Someone's already running expense-ratio math out loud before she's finished the slide. Someone else wants to know if the same approach works in underwriting. The head of claims tries to steer the conversation toward what else those hours might be worth doing instead of cutting them, but there are three more items on the agenda, 15 minutes left in an hour that's already running long, and a room half-checked-out toward the next meeting.

The cost-savings read isn't wrong. It's just the only idea that got any airtime.

By the following week, the number is sitting in the forecast as a bottom-line improvement, and HR has scheduled a meeting to talk through the actual headcount reductions. Nobody chose this outcome over another one; it's just the one with momentum, and momentum in a room with an hour on the clock beats an idea nobody had time to finish developing. The room did what rooms do under time pressure: it ran with the fastest, most defensible read, and by the time anyone might have asked a second question, the decision was already operational.

This is the mechanism I keep running into with insurance and financial-services leaders working through AI at scale. It isn't that no one owns the question of what to do with freed capacity. Someone owns it, in exactly the moment described above: usually whoever's in the room when the result lands, or Finance once it's in their model. The problem is they're answering a question nobody asked out loud: is this time worth more as a saving, or as something redirected? By default, the answer is savings, because savings is the fastest, most comfortable story a room on the clock can agree on.

There's a harder truth underneath the reflex, too. Even if the head of claims had been able to keep the floor, she probably couldn't have made the case: nobody had set up a way to measure what those hours would be worth doing something else. Under real forecast pressure, with downside risk already sitting in the numbers, the room isn't choosing the fast story over the slow one. It's choosing the only story it actually has data for.

The default doesn't hold up, and two firms now say so independently

Gartner surveyed 350 business executives this spring at companies with at least $1 billion in revenue. Eighty percent of the organizations that had piloted an AI or autonomous technology followed with a workforce reduction. But there was no meaningful ROI difference between companies that cut staff and those that didn't. The strongest returns weren't at the companies that cut deepest; they were at the ones using AI to make people more productive, not to replace them. Gartner's Helen Poitevin put it directly: chasing value through headcount reduction alone leads most organizations toward limited returns, not the returns they modeled.

Deloitte's research puts a number on the other half of that same gap. Eighty-four percent of organizations are increasing their AI investment. Only 20% report meaningful revenue impact. But organizations that redesign the work itself, rather than just removing roles, are roughly twice as likely to exceed their AI ROI expectations, and nearly two and a half times more likely to see real financial gains.

Two firms, two survey populations, the same finding: cutting the role doesn't reliably convert a technology gain into a business gain. Redesigning the work does, by a wide margin. This isn't a values argument about protecting jobs. It's a return argument, made with the same data the cost-saving case leans on.

Why the default survives unquestioned

Part of why this default never gets challenged is that the dashboard isn't built to challenge it. A rollout dashboard answers one question the week the tool launches: did the tool work? It was never built to ask the second question: now that the tool freed something up, what's the best use of it? Nobody updates the dashboard to ask that, because nobody built a version where the question has a place to live.

The result is a familiar split. Leadership sees a rollout that delivered the projected time savings and reads that as ROI, declared and closed. The people managing the work six months later are living inside whatever happened to that time, usually nothing or usually cost-cutting, and see a different number entirely. Both readings are accurate: they're reading two different moments, off two different instruments, and only one of those instruments ever looks past launch week.

This lands harder in insurance and financial services for a specific reason: the executive team is tracking results weekly, which is exactly the speed that produces a room like the one above. A real redesign case takes longer than a week to build. By the time underwriters or claims reviewers could show what redirected hours would be worth against loss ratios or retention, the quarterly external reporting cycle has already locked in the launch-week number as a win, and the budget conversation has moved on.

What interrupts the default

Naming the pattern doesn't fix it, so here's what I'd tell a claims or underwriting leader sitting inside this right now.

Put the redirection case on the roadmap when the rollout is designed, not after the results land. That claims leader's slide only had one story on it because only one story had data behind it. Building the other one is real work: further experimentation and analysis, beyond what it takes to simply validate that the tool works. Naming that work up front, as part of the rollout plan rather than an afterthought raised in the meeting, is what gives the room something to weigh against the savings read before momentum decides for everyone.

Reuse a review cycle you already trust. Regulated organizations already run disciplined quarterly and annual reviews for compliance and audit. Add one standing question to that cadence: what did we say this rollout would free up, and which path, saved or redirected, did it take? You don't need a new process. You need one more question inside a process that already has teeth.

Track what changed in the work, not what changed in usage. A login count says the tool got turned on. It doesn't say whether a reviewer, underwriter, or claims handler is doing anything differently on Thursday than in January: the real measure of whether freed time went anywhere.

The open question underneath this one

There's a third factor sitting under both of these that I don't think the data above fully answers, and I'd rather name it honestly than force a tidy conclusion: why doesn't anyone stop to ask the redirection question at all? Do organizations reward speed and visible activity over the slower work of finding a better use for freed time? Is the savings number just easier to defend than a redirection bet that might not pay off for multiple quarters? I don't have a clean answer, and I'd rather leave the question open than manufacture certainty. It's worth its own room, not a paragraph tacked onto this one.

What the data above does settle is narrower, and it's enough: cutting the role may feel like the safe, obvious way to capture value from AI. Two independent studies now say the opposite is the better path. The next time a rollout result lands in a room, and everyone reaches for the cost-savings read in the same breath, it's worth asking whether anyone had a number for the alternative, or whether the room just did what rooms do.

Ask a room full of insurance technology leaders whether their organization has a policy administration platform. Nearly everyone says yes.

Ask what that platform actually does beyond storing, retrieving, and displaying policy data, and the room tends to go quiet.

This is not a semantic issue, but a strategic one!

Across P&C, life, and health carriers, the terms "system of record" and "policy administration platform" are used almost interchangeably. But in practice, they describe two very different relationships between technology and the business it supports.

One preserves information, while the other operationalizes it.

The distinction matters more now than at any point in the last decade, because the cost of getting it wrong has changed. It used to show up quietly, as a slow IT backlog. Today it shows up publicly: a missed product launch, a rate change that can't go live before renewal season closes, a distribution partner who walks because integration takes months instead of weeks.

Understanding that difference is becoming fundamental as insurers reassess the role of insurance policy administration software in their broader transformation strategies. Moreover, modernization is no longer about replacing legacy applications. It is about building an operating foundation that enables continuous innovation, operational resilience, and faster decision-making.

The Cost of Confusing PAS with a System of Records

Three forces have converged to expose insurers whose "platform" is really a repository in disguise. These are:

I. Product Velocity

Specialty lines, embedded insurance, and usage-based products are compressing the time between an underwriting idea and a bindable product. Carriers used to multi-month product builds are now competing against MGAs and insurtechs that configure and test a new product variant in weeks.

II. Distribution Complexity

Policies originate through APIs, partner portals, comparison platforms, and embedded checkout flows. This is done not solely through agents keying data into a core system. A system built only to store the finished policy record cannot support real-time, multi-channel origination.

III. Margin Pressure

The cost of getting this wrong is now measurable, and it cuts both ways. BCG's research puts the failure rate of large-scale core system transformations at roughly 74%. And most of those failures trace back to insurers treating modernization as a system swap rather than an operating-model change. That risk profile is exactly why capability-led, incremental modernization increasingly wins out over wholesale replacement: it lets carriers gain product speed and integration reach without betting the whole transformation on a single, high-risk cutover.

None of these pressures are new. What has changed is the timeline. A decade ago, a slow product build was an internal frustration, absorbed quietly by underwriting and IT. Today, it is visible externally in the form of a distribution partner who chooses a faster-moving competitor.

Decoding the Repository in Disguise

A system of record is, at its core, a system of truth for stored data. It holds the authoritative version of a policy, including coverages, limits, endorsements, billing history, and document trail.

It is often very good at what it was built to do, such as auditability, compliance reporting, and a single reference point for policy status.

But where it falls short is in everything that happens before and around that stored record.

Product configuration is typically hard-coded or requires a vendor development cycle. Rating logic lives in spreadsheets, bolted-on rules engines, or the heads of a few actuarial and underwriting staff. Workflow runs on email and task lists rather than being orchestrated inside the system. Integration, where it exists, is point-to-point, brittle, and expensive to extend.

A system of record answers one question very well: what does this policy currently say?

However, it fails to answer the question that actually determines competitiveness: how quickly can we bring a new product to market, price it accurately, and route it through underwriting without manual intervention?

Take a mid-sized commercial lines carrier launching a cyber endorsement for its existing package policy. Legal and product teams finalize the wording in days. But the rating logic then has to be translated into something the development team can build, tested against the existing rating engine, and slotted into a release calendar that may already be full for two quarters.

Nobody lacks urgency here. The system was simply never designed to let underwriting or product teams make that change themselves.

That gap between what the business wants to do and what the system will let it do is where competitive advantage is won or lost.

The In-and-Out of Policy Administration System

A policy administration platform is built around the operating rhythm of the insurance business, not around the storage of policy data. Product, pricing, workflow, and data access are treated as first-class, configurable capabilities, not customizations layered on top of a repository.

The difference shows up immediately at the moment of a product launch or a rate change.

On a system of record: a change request, a development queue, a testing cycle, a release window measured in months.

On a true platform: a configuration exercise, carried out largely by business and product teams, tested in a sandbox, deployed on a schedule the business controls.

That, in a sentence, is the whole argument. A system of record preserves information. A policy administration platform operationalizes the insurance business.

Seven Capabilities That Separate a PAS from a Data Repository

The cyber endorsement above isn't an edge case. It's the everyday test every core system eventually fails or passes, and it's the reason all seven capabilities below have to work together, not in isolation.

1. Product Configuration

Underwriting and product teams should be able to define new products, coverages, and rating variables through configuration. That's what turns a six-month product build into a matter of weeks. Back to the cyber endorsement: on a real platform, the product team models the new coverage, attaches it to existing package products, and sets eligibility rules directly, with IT involved for governance and testing, not as the sole author of the change.

2. Rating and Pricing Built-In

Rating should live inside the platform as a governed, versioned, and testable capability. This matters most at the moment of a rate change, when actuarial teams need to model, test, and deploy new logic without a separate development cycle, and without risking a mismatch between the rate quoted and the rate bound.

3. Workflow That Runs Itself

Underwriting referrals, endorsement approvals, renewals, and exception handling- all of it should be orchestrated within the platform, with clear rules for what's automated and what needs a human. A system of record pushes this work out to people and email threads, which is exactly where errors and delays accumulate.

4. Access Data in Real Time

Underwriters, claims handlers, and distribution partners need current information at the point of decision, not a batch-refreshed snapshot from the night before. Real-time access is also what makes straight-through processing possible for low-complexity policies.

5. APIs as the Front Door

A platform is built to be consumed by other systems through documented APIs, not one-off interfaces built for a single use case. For instance, rating engines, comparison sites, telematics feeds, agency management systems, and embedded distribution partners. Exposing discrete functions such as issuance or renewal through APIs is often a more practical modernization route than wholesale replacement. That's precisely because it lets insurers extend capability incrementally.

6. Extensibility for What Hasn't Happened Yet

New products, jurisdictions, and distribution models will keep emerging. A platform extends into them without re-architecture. A system of record usually needs a parallel project or a separate vendor every time the business needs to do something it wasn't originally built for.

7. Configurability for the Business, Scalability for Growth

Configuration should sit with underwriting, product, and operations, not exclusively with IT. And the platform needs to scale, in transaction volume, product lines, and geographies, without the cost curve becoming a brake on growth.

Most carriers don't have all seven. Some have none. The question is which gaps are showing up in the operations right now.

Signs You're Still Running a Repository

Certain patterns recur across carriers that believe they have a platform but are, in practice, operating a repository. A handful of questions tend to surface quickly:

• Does a product change routinely take a full underwriting cycle or longer?
• Does rating logic live outside the core system, reconciled manually against what it produces?
• Does IT hold the backlog for anything resembling configuration, while business teams submit tickets rather than making changes themselves?
• Is every integration custom-built per partner, rather than a repeatable pattern?
• Does renewal and endorsement processing depend on manual review because the workflow was never built into the system?
• Does reporting on in-force business require a data extract and a separate analytics layer?

If more than one of these sounds familiar, the answer isn't a resourcing problem. It's an architecture built to store policies, not run a business, and no amount of additional headcount changes that underlying design.

The Stakes of Running the Insurance Business Solely on a System of Records

As business models shift toward composability, traditional core systems risk being reduced to little more than record keepers by the end of the decade. Here, product, pricing, and distribution logic will be managed in more agile layers around them. That framing captures the stakes precisely: insurers treating their core as a passive repository are, in effect, competing with one hand behind their back on product speed, distribution reach, and operational cost.

The benefits of the alternative are greater than those of sitting in isolation.

Faster product iteration compounds across every launch that follows. Straight-through processing lowers unit cost on every policy that passes through it, not just the first. API-first integration means each new distribution partner costs less to onboard than the last one did.

None of this shows up in a single quarter. It shows up over several product cycles, which is exactly why the gap between a repository and a platform is so often underestimated, right up until a competitor's speed becomes impossible to ignore.

By then, the gap is no longer a technology conversation. It's a market-share conversation.

It's little surprise, then, that insurers across P&C, life, and health lines are increasingly seeking modern policy administration software that can support this kind of agility, rather than treating core system replacement as a purely technical upgrade.

The Bottom Line

The confusion between a system of record and a policy administration platform is understandable. Both can look identical from the outside. Both will happily tell you what a policy currently contains.

The difference only becomes visible under pressure. For instance, when a new product needs to launch, when a rate change needs to go live before a renewal deadline, or when a distribution partner asks for an API instead of a batch file.

A system of record will always have a place in the insurance technology stack; audit and compliance requirements demand it. But it is not, on its own, a platform.

The insurers who compete effectively over the next decade will be the ones who have already made peace with that distinction. Meaning, treating product configuration, rating, workflow, and integration as capabilities to be built and governed, not afterthoughts bolted onto a repository.

A system of record preserves information.

A policy administration platform operationalizes the insurance business.

The gap between the two is, increasingly, the gap between insurers who set the pace of the market and those who follow it.

For at least the past two years, insurers have focused on an essential question: How can AI make us smarter?

Another concern is beginning to emerge.

Who, exactly, becomes smarter every time we use it?

The insurance industry has spent decades building intellectual capital that doesn't appear on any balance sheet. Underwriting judgment. Claims workflows. Fraud indicators. Distribution strategies. Product pricing logic. Regulatory expertise. Customer communications. The institutional knowledge that carriers, MGAs, and brokerage use to create a distinct competitive advantage from other businesses in their competitive space.

Today, much of that knowledge is quietly flowing into AI systems - oftentimes without the knowledge owners' (or originators') knowledge.

Not through a data breach.

Not through cybercrime.

But through ordinary, everyday business use.

The New Information Leak

When people think about information security, they typically picture hackers wearing hoodies in darkened rooms stealing customer records or ransomware shutting down operations. (Throw in some empty Mountain Dew cans to add extra "flavor" to the image…)

Generative AI introduces a different type of risk actor.

Insurance workers don't simply upload documents into AI systems. They explain how their business works. They refine outputs. They correct mistakes. They describe edge cases. They reveal why one underwriting decision differs from another. They basically fine-tune the model using the organization's life-blood – its processes, judgment, and expertise.

Each prompt adds context. Every correction adds nuance. Any successful interaction between a person and an insurance-trained LLM captures another piece of proprietary institutional knowledge.

Individually, these exchanges seem harmless. Collectively, they represent an organization's most valuable asset.

The Trojan Horse Problem

Spoiler alert for people who are still reading The Iliad before going to theaters to see The Odyssey: The ancient Achaeans didn't breach the gates of Troy by force.

They were invited inside.

That's why the "Trojan horse" analogy has gained traction among AI observers. The concern isn't that foundation model providers are intentionally harvesting proprietary information for competitive purposes. Rather, the architecture of AI creates a fundamental asymmetry: organizations must reveal increasingly detailed information about how they operate to receive increasingly valuable assistance.

The more context AI receives about your operations...

...the more effectively it can replicate (and share) your expertise.

Microsoft CEO Satya Nadella recently framed this as a "reverse information paradox," arguing that organizations effectively pay twice for AI: once financially, and again by revealing proprietary knowledge required to make the models useful. His observation reflects a growing debate across enterprise technology about ownership of prompts, feedback, workflows and organizational know-how.

Whether organizations agree with that assessment, it raises an important governance question for insurance CIOs/CISOs.

Insurance Has More At Stake Than Most Industries

Insurance isn't simply another knowledge business.

It is a judgment business.

Competitive advantages rarely come from a single algorithm or dataset. They're the result of thousands of successful decisions accumulated over years:

• Why adjusters escalate certain claims.
• How underwriters evaluate emerging risks.
• Which variables consistently predict profitability.
• How service teams de-escalate difficult customer situations.
• Which regulatory interpretations have proven successful across jurisdictions.

These are not trade secrets, per se, but they are critical operational intelligence.

Unlike customer data, operational intelligence often isn't classified or labeled as confidential. Employees may share it with AI tools because they're simply trying to work faster.

Yet this institutional knowledge may ultimately prove more valuable than the documents themselves. And, not to belabor the Homeric allusions, the safety of this institutional intelligence can be an insurance business's Achilles Heel…

Why Governance Must Expand its Purview Beyond Privacy

Most AI governance discussions inside insurance organizations focus on familiar concerns:

• Personally identifiable information
• Regulatory compliance
• Security controls
• Model accuracy
• Bias and explainability

These remain essential elements to a robust governance strategy.

But these may no longer be sufficient as the core of governance.

Organizations should also ask:

• Which AI platforms retain prompts?
• Can customer interactions be used to improve future models?
• What proprietary workflows are employees revealing?
• Which business processes should never leave controlled environments?
• When should an organization rely on internally hosted or private AI models instead of public services?

Such questions nudge AI governance beyond compliance and into competitive strategy.

Institutional Knowledge Is Intellectual Property

Historically, insurers have protected code, customer databases, actuarial models, and other vital information.

Tomorrow's competitive asset may be something less tangible: the accumulated knowledge generated every day through interactions between employees and AI.

The irony is striking.

Organizations adopted AI to preserve and amplify institutional knowledge.

Without thoughtful governance, they may also be exporting it.

Insurers' response should not be to slow AI adoption. The lost productivity gains will be consequential across every insurance function from underwriting to claims to policy servicing.

But as organizations race to become AI-enabled, their practices should be centered around the principle that cybersecurity communities have understood for years:

The most valuable information isn't always the data you store. Sometimes it's the knowledge your people create.

The evolution of AI governance won't be defined around cybersecurity, privacy, or compliance concerns. It will also require insurers to identify, classify and protect institutional knowledge as another key strategic asset.

Organizations that rise to this challenge will capture AI's productivity gains without inadvertently teaching competitors how they do business. Those that don't may discover that the greatest risk wasn't exposing customer data; it was giving away the expertise that made them different in the first place.

The insurance sector is, understandably, quite risk-averse. Insurance companies don't endure and thrive by taking unnecessary risks in an environment defined by stringent regulation and nuanced decision-making. This is why it is so concerning to see companies within the sector taking unnecessary risks as they face up to the mounting pressure of demonstrating progress with generative AI.

It's easy enough to understand the urgency behind the industry-wide scramble to leverage new tools like autonomous agents and AI-powered applications. AI isn't new to the insurance business — use cases revolving around risk modeling and data forecasting were becoming commonplace in the sector before the deep learning and LLM boom in 2023. However, those technologies took years to find a place in insurers' technology stacks. They were heavily tested with strong, clear use cases. The race to adopt generative AI tools is not the same.

EIOPA's 2024 Digitalisation report found that 50% of non-life insurers and 24% of life insurers were already using AI in various areas of the insurance value chain, with applications including pricing and underwriting, fraud detection, and claims management. When it works, it really works. Research from McKinsey found that the insurance sector's AI leaders have created 6.1 times the total shareholder return compared with AI laggards. That figure doesn't just make the case for adopting AI. It makes the case that, if generative tools can be successfully integrated with insurers' tech stacks, the results are outstanding. McKinsey's report found that, in other sectors, AI leaders were generating at most two to three times the shareholder return.

Across the insurance space, there is an increasingly common fear that everyone else is somehow ahead. Companies see their competitors announce new AI pilots and products, vendors make new promises of transformative AI tools, and employees are already experimenting with agents and chatbots. No one wants to be caught standing still while the rest of the market races ahead.

The result is a growing wave of AI FOMO. Insurers are launching pilots, funding multimillion-dollar integration plans, and generally jamming AI into any perceived gap in their workflows. The problem is, many are doing this before interrogating and identifying where AI will actually create any meaningful impact for their business.

The dangers of putting AI before the business case

Last year, a study from MIT found that 95% of AI pilot projects "failed to deliver any discernible financial savings or uplift in profits," the data from which supports an earlier report released by Capgemini in 2023 that found 88% of AI pilots never reached production.

A more recent report from Simplifai found that, while 99% of insurers now have some form of generative AI in place and 83% of carriers are spending more than £3.75 million every year on tokens, subscriptions, and infrastructure, just 42% of insurers had taken the next step towards actually deploying AI into active business functions.

There is an undeniable appetite in the insurance sector for AI, but not a great deal of understanding when it comes to what the technology can do, or where it fits within existing business systems (not to mention the tech stack, which for an insurer is more likely to be some form of legacy system). This issue presents symptomatically as an abundance of AI pilot programmes that never mature into real world business solutions. Insurers know they need to act on AI, but they don't have a clear idea of where to start, which processes to prioritise, or how to evidence the value it creates.

How insurers can distinguish AI opportunity from AI hype

This raises an important question for insurers: what will it take to shift AI from isolated innovation projects to something with tangible business applications?

Scaling AI effectively can lead to substantial business value — the data supports it — but for insurers mired in expensive pilot programmes that never seem to translate into finished products, or who feel as though they're in danger of being left behind, it's essential to approach AI from a business perspective, not a technological one.

Successful AI adoption in insurance might just mean embracing more of the risk averse, methodical behavior for which the sector is sometimes criticized. It means making informed decisions regarding where AI can create real, sustainable impact. Success depends on identifying the use cases with the strongest commercial and productivity outcomes, rather than increasing the volume of AI initiatives in hope of reaching a magical, unspecified tipping point.

Insurance industry-specific AI tools are accessible across the market, doing away with any competitive advantage gained by adopting a particular platform or model. As access to the technology becomes more uniform, competitive differentiation will depend upon how organisations apply it. Successful approaches start with workflows, operating models, and business outcomes. They deploy AI across complete business processes instead of isolated point solutions and establish governance from the outset so that risk, compliance, and accountability are embedded throughout implementation.

The insurance industry doesn't have an AI problem. It has a strategy problem. FOMO is pushing insurers into suboptimal decisions, when the real challenge lies in executing a coherent transformation strategy. The next phase of insurance AI adoption won't be about buying and using more AI. It will be about making better decisions about where AI belongs.

A World Cup soccer tournament wouldn't be a World Cup without controversies, and the just-concluded event had its share. 

Then Argentina said, Hold my Fernet con Cola. 

Following the team's 1-0 loss in the finals to a clearly superior Spanish team, an Argentine player picked a fight on the field that included grabbing a Spanish player by the throat and throwing him to the ground, and Argentine teammates backed him up. Just about the whole Argentine team then acted churlish during the awards ceremony, even turning their backs as the Spanish players were awarded their gold medals and the team trophy. 

Within minutes, reporters and fans were revisiting every untoward thing Argentina had done during the tournament, then during prior tournaments, then on the team bus, then.... 

Argentina provides a great example of how actions taken even by a few in the heat of the moment can sour masses of people on a group or a brand. It's a lesson that I think insurers, in particular, should take to heart, given that our most consequential actions tend to come when dealing with people in situations where their emotions are running hot. 

Let's have a look. 

Argentina had been a possible feel-good story coming into the tournament this year. It had finally won the World Cup in 2022 for its captain, all-time great Lionel Messi. If Argentina had repeated as champion, it would have been the first to do so since Brazil in 1962. Messi, who had won the Golden Ball award in 2022, given to the best player in the tournament, was in the running for the award again. Going into the final, he also had a shot at the Golden Boot, given to the top scorer in the World Cup. At 39 years old, a beloved player was putting in a remarkable performance.

Now, Argentina is known for being chippy, even dirty, and it played to form throughout the tournament, including by having a player sent off in the final after a violent tackle. Spain, while hardly free of fouls, played a classic style that contrasted sharply with Argentina and led any number of people to post at the conclusion of the game some variant of, "Football won today." 

The history of writeups about the Argentine team suggests that would have been about the extent of the complaints about Argentina's tactics. 

Then the Argentine players started knocking around some of the Spaniards after the final whistle, and all bets were off. 

Someone quickly shared a clip of the Argentine player instigating the post-game brawl. Then people started going back through the whole game, pointing out everything even borderline that Argentine players did — here is one-such 13-minute clip. But why stop there? Here is a 5 1/2-minute clip of transgressions by Argentina that weren't penalized in the semifinal against England. Of course, there was group play, too — here is nine minutes of uncalled fouls against Switzerland. 

Earlier incidents became fair game, as well. A video surfaced in 2024 of Enzo Gonzalez, the Argentine player who drew a red card in the final, and teammates chanting racist slurs on the team bus, as posts such as this one quickly noted over the weekend. Gonzalez had apologized profusely, including personally to Black players on his club team, and surely thought the incident was behind him. No longer. Many on social media also noted that the Spanish goalkeeper had been classy in accepting the Golden Glove award, for the best at his position in this year's tournament, while the Argentine keeper had used the award to make an obscene gesture when he won in 2022.

Analysts were universally brutal about Argentina after the final. The New York Times ran a story under the headline, "Argentina disgraced themselves, and the World Cup final, with their charmless petulance." In case that wasn't enough, the NYT ran another story, full of images, under the headline, "How Argentina turned the World Cup final dirty with shoves, skulduggery and squealing."

My point being: Once sentiment turns against you, even based on an incident by one person or a small group, things can go downhill fast — and keep going.  

This surely isn't news to insurance companies, which understand that claims are the moment of truth. Everyone and everything has to line up just right when you're dealing with longstanding, loyal customers in their moment of need. They've earned compassionate, professional excellence — and they'll react in horror if they don't get it. 

But I still think object lessons like those provided by Argentina are worth noting and spreading, because it only takes a few people, or even a single person, to undercut what so many other people are doing to earn loyalty. Social media can broadcast bad actions incredibly fast these days and seems to relish doing so, especially if there is compelling video. 

And narratives are hard to shake once they take hold. The Argentine team is being cooked especially hard because it was already known as a dirty team. In insurance, if you're not known for great customer service, complaints will find an especially alert audience — I'm sure State Farm, for instance, is being incredibly careful these days, given the controversy over its handling of claims from last year's wildfires in California.

I won't suggest buying the jersey of Leandro Paredes, the Argentine player who ran up on a Spanish player from behind after the game and knocked him over, because some of the money would find its way back to him. But maybe he can be an anti-hero for anyone dealing with insurance customers. Whatever you do, people, don't earn us a reputation like that guy....

Cheers,

Paul

P.S. When I think back on the World Cup, I'll prefer to think about the positive surprises. Who knew that Costco and ranch dressing would be such delights for those visiting the U.S.? Erling Haaland? I've spent years hating on him in a Man City kit but found him impossibly charming both in a Norway jersey and in his experience with U.S. culture. Then there was Spanish star Lamine Yamal's three-year-old brother, Keyne, who stole every scene he was in throughout the tournament. 

And I'll especially cherish a moment that Jude Bellingham and Bukayo Saka and their English team had in their third-place game against the French. 

When England earned a penalty kick, Bellingham prepared to take it. He had emerged as a full-on star for England and had already scored six goals; seven would be unworldly. But he knew that Saka had scored twice against France, knew that concerns about injury had (unwisely, in my view) kept Saka out of the semifinal that England lost against Argentina, and may have been thinking about how Saka and two Black teammates had missed penalty kicks in a tournament in 2021 and had endured wildly racist criticism. 

Bellingham told Saka, "Go on and get your hat trick," and handed him the ball. Saka converted with a kick that the keeper wouldn't have touched even if he had guessed right, rather than diving in the opposite direction. Saka's goal turned out to be the winner. 

Bellingham, by the way, got his seventh goal a few minutes later with an extraordinary display of technical virtuosity. So nice guys finish.... first?

AI has moved past the hype stage—it's reshaping cost structures, competitiveness, and growth across insurance. Carriers who hesitate are locking in cost and risk profiles that only get harder to unwind. Drawing on original research with insurance executives, this report shows how AI, GenAI, and Agentic AI are separating Leaders from Followers and Laggards—and why 2026 is the point of no return.

AI is now a boardroom priority, tied to insurers' top 2026 goals: cutting costs, streamlining operations, and improving customer experience. Across underwriting, claims, servicing, billing, distribution, and loss control, carriers are moving from talk to active pilots, targeting friction in paperwork-heavy areas like claims and service. But appetite is outpacing the data foundation needed to support it, raising scalability and reliability risks without stronger governance.

The center of gravity is shifting from "AI as a data tool" to "AI as a workforce multiplier," powered by the Frontier Firm—companies built on on-demand intelligence and human-agent teams, where staff act as "agent bosses." Leaders are already scaling GenAI and Agentic AI with mature data capabilities behind them; laggards risk losing ground on performance and cost.

Download this report to explore:

• Why modernized data and an Intelligent Core are essential for scalable, responsible AI
• How to bring the Frontier Firm and Agent Boss models into your organization
• How AI is reshaping cost, competitiveness, and growth across the insurance value chain

Get Started>>

Sponsored by Majesco

The industry no longer doubts whether AI benefits submission intake in commercial property and casualty (P&C) lines. Recent AI rollouts by Zurich, AIG, Markel, and other market leaders show impressive gains come very quickly: intake timelines for complex submissions compress from hours to minutes, straight-through processing (STP) rates increase from 10% to 95%, underwriter productivity grows by 100%+, and submit-to-bind ratios improve by 35%.

Yet many P&C carriers are still figuring out how to make AI work for their business. Which parts of their submission intake workflow can realistically be automated? Where to start so that we can move out of pilots fast? How can we explain, audit, monitor, and defend what the AI did? And what AI solution design should we actually pursue to scale well?

These are the questions I hear most often in ScienceSoft's engagements with commercial P&C clients. In this article, I'll share my perspective on where AI works best in submission intake today, why many initiatives never move beyond pilots, and what insurers should focus on if they want to launch submission intake AI over the next six to 12 months.

Where AI Delivers the Fastest Value in Submission Intake

From my experience, the quickest wins come from automating the parts of insurance submission intake that are high-volume, repetitive, document-intensive, and largely governed by business rules. Strong starting points in commercial P&C include:

• Capturing and classifying submissions.
• Extracting data from ACORD forms, loss runs, schedules of values, and other submission documents.
• Checking submissions for completeness and identifying missing information.
• Summarizing and triaging risks for underwriters.
• Prefilling policy administration and underwriting systems.
• Drafting underwriting files and follow-up questions for brokers.

These activities create a large operational workload but require little underwriting judgment, which makes them ideal candidates for AI automation. Modern AI systems can handle these connected intake operations almost entirely, only involving humans in complex cases. In this first half of the intake pipeline, STP rates of 90–95% are a realistic target.

They are also the safest processes to automate from both a business and regulatory perspective. In each case, AI prepares data and doesn't touch high-impact decision-making.

Anything involving decision-making is a different story. Commercial P&C underwriting is rarely standardized. It often requires negotiation, exceptions, and collaborative expert judgment, with every submission carrying its own nuances. Most of the cases are just too complex for reliable straight-through AI decision-making.

That doesn't mean AI has no role here. It can absolutely assist in eligibility assessment, pricing, and coverage decisions — for example, by highlighting relevant risk factors, surfacing similar cases, or recommending next steps — but I'd keep it away from making those decisions autonomously. Human experts should continue to own the final judgment.

Moreover, even when AI acts only as an assistant, the governance bar remains high. You need mature controls, explainability, and human oversight to defend AI suggestions to brokers, policyholders, auditors, and regulators. That's why I usually recommend that clients avoid complex assistive use cases during early AI deployments. A safer path is to first confirm AI accuracy, auditability, and workflow impact across lower-risk data intake tasks, then gradually scale into underwriting decision-support areas.

Overall, I don't think anything close to fully autonomous underwriting should be the near-term objective for commercial P&C insurers. The "AI assists, humans decide" approach, where AI prepares files and experienced underwriters make the final decisions, has proven the most practical operating model. It lets insurers preserve human accountability where it matters most while still delivering huge business returns. I recently came across a case study where deploying AI for submission intake routines alone brought a 646% ROI for a large property carrier through faster, more accurate, and more efficient data processing.

Data Foundations for AI-Powered Submission Intake

First of all, you can effectively start with whatever data you have. That's an important point because I've seen many insurers unnecessarily delay AI initiatives out of fear that their existing data is too scarce or too low-quality for AI processing.

The first necessary data foundation you need in commercial submission intake is a clear document taxonomy. However strong AI may be at data tasks, it still struggles with unstructured, consequential data containing insurance-specific terminology and context. One classic example is loss runs: they vary by provider. Claim descriptions often contain abbreviations. Severity indicators may be buried in narrative text. The AI may read the document correctly but fail to determine what's material from an underwriting perspective.

A clear taxonomy creates enough structure around the data so AI can distinguish between document types and apply the right extraction logic, validation rules, and review requirements to each. It also helps determine which documents AI should treat as authoritative when data conflicts across sources.

What Might Keep AI Stuck in Pilot Mode, And How You Avoid It

By far the biggest blocker is AI integration into existing submission intake workflows.

Most commercial P&C insurers operate heavily fragmented environments. Documents sit in one place, policy data in another, rating logic somewhere else, and underwriting notes in spreadsheets or workbenches. People have built manual workarounds over the years because their legacy core systems do not support the connected workflow.

Making AI work with these core systems doesn't mean you need to modernize or replace all of them. But you do need a practical integration pattern to avoid building numerous point connections. Off-the-shelf AI architectures often hit a wall at this point: most mass-market tools, by design, introduce AI as another isolated interface sitting alongside the existing process. AI product vendors can't possibly account for every system or data format their clients may still be using to build a product that integrates well with legacy stacks.

Another blocker is what I call "pilot thinking." During pilots, people often focus too much on proving that the AI model can accurately classify, extract, summarize, and answer questions. That's necessary, but it's only one part of the equation. Moving to production requires proving that the AI can operate reliably inside a real insurance workflow: integrate with existing systems, handle exceptions, support human review, produce audit evidence, and scale across thousands of submissions. That's where many otherwise successful pilots stall.

The goal of a pilot should be validating not just AI accuracy but rather the operating model around the AI. Can the workflow route low-confidence cases for review? Can underwriters easily verify and override AI outputs? Can the solution recover from missing or conflicting information? Can it integrate with core systems without creating manual workarounds? Those capabilities determine whether the AI can become part of daily operations.

The third blocker is poor ownership models. Someone has to review AI performance, define business rules, validate compliance, and measure outcomes. When ownership is unclear, issues randomly fall between teams. The technology may work, but if nobody takes responsibility for adoption, governance, and continuing improvement, your promising AI initiative may quickly lose momentum after the pilot stage.

You'll need a board of AI governance owners from underwriting, IT, data or AI engineering, and compliance or risk before moving beyond the pilot. The board should regularly review AI performance, override rates, exceptions, user feedback, and regulatory risks, and decide when the solution is mature enough to expand into new workflows or business lines.

Addressing AI Risks That Insurers Often Underestimate

A lot of insurers immediately think about AI hallucinations, and that's a real risk.

To address that risk, the AI reasoning should be grounded in source documents, and the system must show where each important field or summary statement came from. Adding deterministic validation of AI outputs after each processing iteration also helps prevent error creep. These are rule-based checks that verify required fields are present, figures are consistent, references match the source documents, and the output complies with predefined business rules before the workflow continues.

Yet, in commercial P&C submission intake, I think one of the most overlooked risks is silent workflow bias.

By that, I mean AI may not be making the final underwriting decision, but it may still influence which submissions move faster, which are routed to senior underwriters, which are treated as gapped, and which receive follow-up. Those workflow decisions can create different outcomes over time, even if the model never explicitly uses protected-class data.

Another risk is silent portfolio drift. The process gets faster, productivity looks better, and everyone is happy. But over time, the mix of business may change. Maybe more borderline risks get through because the process feels smoother. Maybe underwriters stop asking certain follow-up questions because the AI-produced summary looks complete. None of this looks like a major failure on day one, but it shows up later as leakage, adverse selection, and portfolio quality issues.

The way to manage this is through continuing outcome monitoring. During pre-launch tests, compare AI-assisted cases versus manually processed ones to establish execution benchmarks. After rollout, monitor trends in quote-to-bind rates, referral rates, missing-data rates, post-bind corrections, override rates, and downstream loss performance. Also regularly sample fast-tracked cases for expert review and ask underwriters: would we have handled the submission the same way without AI? The goal is to detect when AI begins influencing portfolio quality in unintended ways.

Regulatory compliance is a known source of risk, and it requires governance from the start. In the US, regulators increasingly look beyond underwriting outcomes and examine whether AI affected submission routing, triaging, eligibility assessment, and broker interactions. The NAIC Model Bulletin on AI, adopted by 24 states and the District of Columbia, calls for controls against AI discrimination. New York, California, and Connecticut have issued their own AI guidance for insurers. You need explainable AI logic, audit trails, mandatory human reviews for high-impact decisions, and evidence that you regularly monitor for bias and drift to withstand regulatory scrutiny.

An Actual AI Solution for Commercial P&C Submission Intake

In an end-to-end commercial submission intake scenario, we would be looking at a multi-agent system coordinated by an orchestrator. We need specialized AI agents to perform different tasks: one classifies incoming documents, another extracts and validates data, the third drafts broker follow-up requests, and so on.

ScienceSoft prefers this pattern because submission processing involves many distinct activities with different accuracy requirements, permissions, and risk profiles. An input classification agent doesn't need access to the same data as a risk file preparation agent. An agent responsible for drafting emails shouldn't be reasoning on eligibility. Separating responsibilities reduces the blast radius of errors and makes governance much simpler.

And then, the orchestrator acts as a control layer of the agentic workflow. Unlike narrow agents, it doesn't perform submission-intake tasks itself. Its only job is to coordinate how work moves between AI agents, business rules, systems, and people. It decides which agent should act next, applies predefined routing rules, manages confidence thresholds, sends exceptions to human reviewers, and maintains an audit trail across the entire process. Think of orchestration as an AI traffic controller. Without it, you have just a set of AI capabilities.

Must-Haves of a Production-Ready AI Architecture

Three engineering principles separate a production-ready agentic AI system from a one-off pilot: decoupling AI from core insurance systems, implementing a multi-level AI authorization model, and building agents in a modular way.

Avoiding tight coupling between the AI workflow and the insurer's existing systems is essential for interoperability. Otherwise, adding AI would require rework across existing systems, and even small changes to those systems would trigger changes to AI-supported operations. In an ideal setup, the orchestrator and AI agents act as a back-end operational layer between your current systems without replacing them or requiring expansion. A layered architecture with a dedicated agentic layer and an integration layer sitting between the AI workflow and other insurance systems works well for that.

Consider applying event-driven integration patterns, where business events (think submission arrival or document upload) automatically trigger the next AI task. This keeps workflows synchronized across multiple systems without creating tightly coupled point-to-point integrations and allows AI to react immediately as an event occurs, making submission intake faster. Another major advantage is easier integration with legacy systems. Older apps that don't support APIs can often participate in the workflow by sending or receiving event messages, removing the need for custom integrations.

One more practical move is to expose the integration layer through a single gateway. This way, you don't need to integrate every AI agent separately with your existing systems and get a single place to capture audit logs. This approach simplifies integration across fragmented environments and supports a consistent audit trail required for compliance. It also minimizes integration maintenance overhead: if you later change your core platforms, the AI integration contracts remain stable.

The second principle is multi-level AI authorization. This approach aims to limit AI autonomy where business and regulatory risks are high while maximizing overall automation. We typically use three authorization levels. The first level allows fully automated actions for low-risk tasks like document classification or completeness checks, provided the AI outputs pass predefined deterministic checks. The second allows AI recommendations but requires human approval before execution, for example, when drafting broker follow-ups or preparing underwriting summaries. The third covers decisions that may affect eligibility, pricing, or other material underwriting outcomes. Here, AI prepares the supporting analysis and data, but humans remain the decision-makers.

You also need the system to log every action, including inputs, outputs, agent actions, source references, validations, and underwriter overrides. With this complete log, you can explain how decisions were reached, trace outputs back to evidence, review AI behavior long after a submission pack is processed, and prove regulatory-aligned controls during audits.

The third principle is modular agent design. With a modular architecture, each agent is built as an independent component. Such a design lets you add, improve, and replace task-specific agents without redesigning the whole system. This means you can first deploy agents for only a few processing tasks, one product, or one submission channel, prove accuracy and adoption, and then expand. That ability to scale gradually lets you start your AI journey with moderate upfront investment and with minimal implementation risk. If you're ready for a broader rollout from the outset, the modular architecture still makes the solution easier to maintain and evolve as business needs change.

The same modularity also allows you to use the best-performing and cheapest technology for each agent. For example, agents that assess eligibility and summarize risks benefit from the reasoning capabilities of large language models (LLMs). Implementing them with tailored retrieval-augmented generation (RAG) pipelines ensures outputs are grounded in actual submission documents. For document classification and entity extraction agents, fine-tuned encoder models trained on a fixed set of documents typically deliver very high accuracy at a fraction of the cost of LLMs. Plus, these models do not generate anything, so there's no hallucination risk at early intake steps.

Contributing to this article were: Vadim Belski, head of AI, principal architect, ScienceSoft, and Stacy Dubovik, financial technology & AI researcher, ScienceSoft.