When Artificial Intelligence Makes Everyone a Software Developer, the Agency’s Errors & Omissions Exposures Change 

• By: Gregory Marholin
• September 15, 2026

Artificial intelligence (AI) is changing more than how insurance agencies use software. It is changing who can build it. 

An insurance agent who identifies a gap between two systems no longer must wait for a vendor roadmap or hire a development team. With general AI tools, an agent may be able to create an automation, connect workflows, generate client communications, review information, or build a small application around the way the agency actually works. 

These are not limited to simple chatbots. Agents are experimenting with renewal and re-quoting workflows; custom CRM and agency-management functionality; service-task automation; tools that read carrier quote documents and turn them into client-ready communications; and other applications that once would have required a software vendor or development team. Certificate requests, document workflows and client-service chatbots are natural extensions of the same capability. 

That can be a good thing. Existing software may have been designed for the average agency rather than a particular workflow. An upgrade may be expensive. Another subscription may seem unnecessary. A small AI-built solution may fit better, cost less and be available immediately. 

The problem begins when a functioning tool is mistaken for a controlled software product. 

To the agency, the distinction can be easy to miss. Both can perform the same business function, sit inside the same workflow and influence the same client outcome. What stands behind them may be very different. 

Same Category, Very Different Exposure 

For an agency evaluating AI-enabled or AI-built tools, it helps to distinguish three situations. 

An established software vendor is a company whose business is developing and delivering software. That does not make every AI feature safe, or every AI output reliable. The vendor still needs to identify where AI can make or influence a judgment and what controls surround those decision points. 

However, an established vendor is more likely to have enterprise security, formal development controls, testing and quality assurance, at least some contractual responsibility, customer support, business continuity and insurance coverage structured around the risks associated with building and delivering technology as a business. 

An agent in-house AI-built tool is different. The agency may have quickly and economically built it to solve a legitimate problem. It may work very well. But the agency is now both builder and user. 

Because the tool is homegrown, it may bypass the vendor vetting and due diligence that would normally examine security, controls, software testing, legal rights, insurance and business continuity concerns. It may not even appear on the agency’s AI inventory because employees think of it as a spreadsheet, workflow, automation, or internal shortcut rather than an AI application. 

An agent in-house and distributed AI-built tool adds another dimension. What if an agent builds something useful internally and then makes it available to other agencies? Distribution does not necessarily make the underlying technology more dangerous. It makes the consequences of the same weakness potentially much broader because more agencies, users, transactions and client decisions may depend on it. 

The multiplier effect matters because a flaw that would have affected one agency can become a repeated issue across many agencies. A bad assumption in a renewal workflow, an incorrect extraction rule, or a flawed prompt can be reproduced consistently. Consistency is normally a strength in software. When the underlying logic is wrong, consistency can also spread the same error at scale. 

That is why agencies should not confuse familiarity with control. A tool created by another agent may feel trustworthy because the builder understands insurance and the workflow. That industry knowledge can be valuable, but it does not substitute for security testing, access controls, documentation, incident response, change management, support or insurance designed for a software business. 

A Vendor List and an AI Inventory Are Not the Same Thing 

A vendor list answers a financial question: Who are we paying? An AI inventory must answer a different question: Where can AI make or influence a judgment? Those are not the same list. 

An employee may build a small internal application without creating a new vendor relationship. An existing spreadsheet may acquire AI functionality. An automation may connect several systems. An established vendor may add an AI feature through an ordinary software update. An agency may subscribe to a tool built by another practitioner and treat it like any other software expense. 

The agency cannot manage what it has not identified. An incomplete AI inventory leaves those activities outside the control environment. 

When the Tool Is Wrong, Who Stands Behind It? 

Consider a tool used to compare information, prepare a recommendation, generate marketing content, summarize policy language, or create a client communication. 

The tool produces an incorrect result. The employee reviews it but does not recognize the error. The communication goes to the client. A loss follows. 

The E&O analysis will not end with the sentence, “AI made a mistake.” The agency may need to establish what information the tool received, what it generated, what the employee reviewed, which source controlled, who approved the final output and what evidence remains. 

Then another question arises: Who stands behind the tool itself? 

With an established software vendor, there may be a contract, a support organization, records, formal development processes, an insurance program and a company with financial resources to examine. 

With an internally built tool, there is no third party. The agency built it and used it. 

With a tool built and distributed by another practicing agent, the buying agency should understand what business structure, contractual responsibility, security program, support organization and insurance actually stand behind the product. 

Insurance policies differ by carrier, state, form and endorsement. Agencies should work with qualified coverage professionals to determine how their own policies and a vendor’s policies address the activity involved. The important point is that the question must be asked before the claim arrives.  

AI Can Also Create a Rights Problem 

Security and E&O are not the only issues. AI has dramatically reduced the effort required to reproduce software functionality, and that creates another exposure that agencies may overlook. 

A user may take screenshots, workflows, documentation, configurations, business rules or other material from software the agency already uses, upload that material to an AI model and ask it to recreate the functionality, improve it or build a replacement. 

That does not automatically mean infringement occurred. But AI assistance does not erase the rights that may exist in the underlying material. Copyrightable software expression, confidential information, trade secrets, licensing terms and contractual restrictions may still apply. 

This matters even more when an internally built tool becomes a commercial product. A software provider that believes its proprietary material was used to create a competing application may have both the incentive and resources to enforce its rights. 

For the agency that buys the new tool, the issue may be invisible. It may have no idea what materials were used to create the product. Yet a dispute could lead to defense costs, a demand to stop using the tool, replacement costs, or operational disruption. 

The question is therefore not only whether the software works. The agency may also need to understand whether the builder had the right to create and commercialize what is being sold. 

Human Review Does Not Solve the Structural Problem 

A familiar response to AI risk is to require a human in the loop. Human review matters, but it is not enough by itself. 

Human review only works when the reviewer knows what an error looks like. 

If the underlying workflow contains a faulty assumption, misses an important data element or uses an incorrect business rule, repeatedly placing a human after the output does not necessarily correct the underlying design. 

The agency still needs to know what must be verified, which sources control, who has authority to approve the result, when escalation is required and what evidence is retained. 

Low Development Cost Does Not Mean Low Risk 

AI changes the economics of software development. A professional may now create useful functionality without the development expense once associated with commercial software. 

But AI does not automatically create the infrastructure surrounding that functionality. 

It does not automatically provide enterprise security, access management, privacy controls, change management, independent testing, audit logs, incident response, business continuity, contractual responsibility or appropriate insurance 

Those things cost money because they are part of delivering software reliably. An agency may therefore save on the visible cost of software while unknowingly assuming some of the invisible cost of the risk. 

The same due diligence should also ask what happens when the builder changes the underlying model, modifies a prompt, adds a data source, or updates the workflow. A tool that performed appropriately when first tested may behave differently after a change. Agencies need to know who owns those changes, how they are tested, what notice users receive and whether prior controls still apply. 

The SaaSpocalypse May Have a Second Act 

Much has been written about the “SaaSpocalypse,” the idea that AI will reduce the value of traditional software by making features easier to reproduce and allowing customers to build more for themselves.  

There is logic behind that argument. If an agency can create a tailored workflow in days instead of buying another application, some traditional software functionality becomes less valuable. 

But there may be another side to the cycle. 

As businesses gain experience with AI-built tools, value may begin shifting back toward providers that can demonstrate more than functionality. Enterprise-grade security, formal controls, testing, auditability, continuity, contractual accountability and insurability may matter more. 

The competitive advantage of an established software company may therefore become less about whether it can produce a feature someone else can reproduce with AI. Its advantage may increasingly be the confidence that comes from what stands behind that feature. 

Cheap functionality can be valuable. Controlled functionality is more defensible. 

Established Software Vendors Still Need to Identify AI Decision Points and Controls 

None of these means established vendors should automatically be treated as safe. A large vendor may have excellent cybersecurity and still introduce an AI capability without adequately identifying how it influences decisions. 

The same questions apply: Where can AI make or influence a judgment? What data can it use? What is it allowed to do? What requires human review? What source controls the answer? What evidence is retained? Who owns the approval? 

An enterprise security program is valuable, but it does not replace AI governance. 

Treat AI-Built Tools as Tools, Not Exceptions 

Agencies do not need to prohibit innovation. They need a consistent standard. 

Whether the tool comes from a national software company, an employee inside the agency or another agent selling a subscription, the agency should identify the AI use, evaluate the decision points, define what information may be used, determine the required review, understand who stands behind the tool and preserve enough evidence to explain what happened later. 

The objective is not to eliminate AI risk. No system eliminates all risk. 

The objective is to prevent an apparently inexpensive shortcut from becoming an invisible E&O exposure. 

AI-assisted building without legal rights, transparency, verification and insurability is not disruption. It is an unmanaged risk with a better user interface. 

About the Author 

Gregory Marholin is Executive Advisor, Strategy & Growth at AI GuardWorks, a managed AI risk and controls system designed to help insurance agencies and other AI-exposed businesses identify where AI is used, establish practical controls around AI decision points, require qualified human review where appropriate, and preserve evidence of how AI-assisted activity was managed.  

Disclaimer 

The views expressed in this article are those of the author and do not necessarily reflect the views of IIABA or its members or affiliates. Publication of this article does not constitute an endorsement. This article is for informational purposes only and does not constitute professional advice; consult qualified professionals for advice regarding your specific circumstances 

Copyright © 2026, Big “I” Virtual University. All rights reserved. No part of this material may be used or reproduced in any manner without the prior written permission from Big “I” Virtual University. For further information, contact nancy.germond@iiaba.net.