AI vendor selection for insurance agencies.

• Why vendor selection is the highest-stakes AI decision
• The five vendor archetypes
• The Build / Buy / Borrow framework
• Twelve questions every vendor should answer
• Five red flags
• Pilot scoping that tells you something
• AMS and carrier integration
• What's reasonable to pay
• Scaling or killing after the pilot
• FAQ

Why vendor selection is the highest-stakes AI decision.

A bad AI vendor decision in an insurance agency costs $25,000 to $80,000 in direct implementation cost, plus 6 to 12 months of internal disruption. The direct cost is the licensing fee and the integration hours. The disruption cost is the meetings, the workflow rewrites, the producer pushback, and the credibility hit when the rollout stalls.

If the agency makes two bad calls in the same year, the compounding effect is not linear. Producers and underwriters get vendor-fatigued. The next tool gets installed against active skepticism, and skepticism in change management is more expensive than the first failure was.

The market does not filter for the agency yet. The AI insurance vendor category is two years old. Reviews are thin. Reputation signals are unreliable because most vendors have fewer than 50 named customers. The agency is the filter. The framework below is how to be a good filter.

The five vendor archetypes.

Every AI vendor pitching insurance agencies in 2026 sits in one of five archetypes. The archetype matters because it predicts where the vendor is strong, where it is weak, and which risks dominate.

The Build / Buy / Borrow framework.

Before you score vendors, decide which lane the capability belongs in.

• Build when you have engineering capacity, the capability is a competitive moat, and no acceptable vendor exists. Three conditions, all required. If any is missing, do not build.
• Buy when a credible vendor serves the workflow, the integration cost is bounded, and the contract has reasonable escape terms. This is the right answer for 95% of insurance agency AI decisions in 2026.
• Borrow when the buy market is immature for the specific workflow but open-source models can do the job with a thin internal layer. The borrow path covers risks around vendor lock-in while keeping carrying cost lower than a full build. Examples: using GPT-4 or Claude through the OpenAI / Anthropic API directly with a small in-house prompt library, instead of paying a wrapper.

Apply the framework one capability at a time. Submission intake might be a clear buy. Internal knowledge search might be a borrow on Claude or Copilot. A custom underwriting model might be a build, or might be deferred entirely.

Twelve questions every vendor should answer.

The questions below are designed to surface gaps in the vendor's own thinking, not to chase compliance theater. Read the answers for substance, not for length.

1. What foundation model does the product run on, and how do you handle model updates? If the vendor cannot tell you which model class powers their AI, walk. If they handle updates by re-prompting silently, you have a regression risk you do not control.
2. What training data was used to fine-tune the model, if any? Most insurance AI vendors do not actually fine-tune. They prompt-engineer on a foundation model. That is fine, but the vendor should be honest about it.
3. How does the product integrate with our AMS? API, webhook, RPA, or copy-paste? Each has different cost and reliability profiles. The vendor should know which AMSs they support natively, which they bridge through, and which they cannot serve.
4. What is your security posture? SOC 2 Type 2 is the floor in 2026 for any vendor handling PII or producer data. Ask for the report. If they have not started SOC 2, expect to be the security validation customer, with the costs that come with it.
5. What contractual escape do we have? Month-to-month is ideal at the pilot stage. Annual is acceptable for established vendors with a track record. Multi-year auto-renewals with no opt-out window are a hard no.
6. How is the product priced? Per seat, per policy, per submission, flat agency tier, or usage-based? Each model creates different incentives for the vendor. Per-policy or per-submission rewards them for your growth, which can be good or expensive.
7. Show us three named agency references at our size. Not logos. Named agencies, with named contacts, who agreed in writing to take a reference call. If the vendor cannot provide three, you are the proof point. Charge them for being one.
8. What is the worst failure mode of the product, and how is it surfaced? Every AI system fails. The question is whether the failure is visible to the user, silently logged, or hidden. The best vendors will name their failure modes specifically.
9. What audit trail does the product produce? For E&O purposes, the agency needs to reconstruct what the AI did and why. The vendor should produce per-action logs with timestamps, model version, prompt or input, output, and any user override.
10. What is your model update cadence? Daily, weekly, monthly, or quarterly? The vendor should know. If they say "we update continuously," ask whether updates are tested against a regression suite. If they say "we update when the foundation model changes," ask whether you are notified.
11. What is your E&O coverage and indemnification posture? Does the vendor carry their own E&O? Will they indemnify the agency for product failures? Vague language here usually means no.
12. If you go out of business or get acquired, what happens to our data and our integration? Data export terms in writing. API SLA in writing. Acquisition language in writing. This is where most vendor contracts are weakest, and it is the highest-leverage clause to negotiate.

Score each vendor on the same 12 questions. Differences in answers are where the decision lives. Sameness in answers means the vendor has a polished sales playbook, not a better product.

Five red flags.

• Demo-only references. The vendor shows a polished demo but cannot name three agencies that use the product in production. Live product behavior in your environment is different from demo behavior in theirs.
• Locked-in contracts longer than 12 months with no escape. A vendor confident in their product offers month-to-month or short-term contracts. A vendor selling on FOMO locks you in.
• "Let's discuss" pricing. Hidden pricing is a tell. It usually means the vendor charges based on what they think the agency can pay rather than what the product is worth. Published price ranges are a sign of a confident vendor.
• No published security or compliance posture. If the vendor does not publish their SOC 2 status, their data-residency stance, their model-update cadence, and their incident-response process, they are not ready for an agency that handles PII or premium data.
• Sales team that cannot answer technical questions. Ask the sales rep to walk through how the model handles a specific edge case in your workflow. If they cannot, and they punt to "let me get an engineer on the next call," that is fine for round one but disqualifying if it persists into the procurement stage.

Any single flag is a signal for more diligence. Two or more is usually disqualifying.

Pilot scoping that tells you something.

A pilot exists to surface failure modes that the demo cannot show. Most insurance agency AI pilots fail not because the product is bad but because the pilot was scoped to confirm rather than to test.

A pilot worth running has all of the following.

• Fixed duration: 30 days. Shorter does not give the workflow enough cycles. Longer lets sunk cost set in. 30 days is the right size for most workflows.
• Named stakeholders on both sides. One named decision-maker at the agency. One named contact at the vendor. Not a procurement committee. Not a Slack channel.
• Quantitative success metric, defined before kickoff. Submissions processed per producer per day. Claims triaged per adjuster per hour. Time to first quote. Pick one. Measure it pre-pilot and post-pilot.
• Qualitative abort criteria, defined before kickoff. "If the AI makes more than 3 reasoning errors per day on our workflow, we abort." "If integration breaks twice in a week, we abort." Specific, observable, written down.
• One designated sceptic. Someone whose job during the pilot is to find reasons it will not work at scale. Not to sabotage. To surface failure modes the champion will not.
• A written week-1 readout, week-3 readout, and week-4 decision document. The decision document names whether the agency rolls out, kills, or extends the pilot, and the reason.

Most pilots fail by drifting. A 30-day pilot with no readout schedule becomes a 90-day pilot with no decision, then a 180-day pilot the agency cannot kill without admitting it should have killed at day 30.

AMS and carrier integration.

Four integration patterns matter for insurance AI. Each has different cost, debuggability, and reliability profiles.

• API integration. Cleanest when the AMS exposes one. Vertafore, Applied, AgencyZoom, and NowCerts all have API surfaces with varying completeness. Verify the specific endpoints the AI vendor needs before pilot kickoff.
• Webhook integration. Event-driven flows where the AMS pushes data to the AI. Works well for new-submission triage, claims-event triage, and renewal alerts. Harder to debug than API because failures are asynchronous.
• RPA bridges. When neither API nor webhook is available, an RPA layer simulates user actions in the AMS. Works, but check the AMS terms of service. Some vendors prohibit RPA in their TOS. Also fragile to AMS UI changes.
• Copy-paste. The fallback for month one of a pilot, before the integration shape is known. The producer or underwriter copies data into the AI tool and copies the output back. Slow, but useful for validating whether the AI is good enough to be worth integrating at all.

Carrier-side integration is harder. Most carriers expose limited APIs to agencies for AI use. Wholesale and MGA integration is more open than direct carrier integration in 2026. If your AI vendor promises "seamless carrier integration," ask which carriers, through which APIs, with what SLA. The honest answer is usually "fewer than they implied in the demo."

What's reasonable to pay.

2026 pricing patterns across the five archetypes, drawn from publicly listed and reference-verified ranges.

Ranges reflect public pricing and reference-verified contract observations across SMB agencies in May 2026. Enterprise and mid-market tiers diverge.

The reasonable test: does the AI save more time per month than its monthly cost, accounting for change management overhead? Time saved should be measured net of the meeting hours, the prompt-tuning, the producer training, and the integration maintenance. Apparent savings before change management is what every vendor sells. Net savings after change management is what matters.

Scaling or killing after the pilot.

The week-4 decision document forces a binary at the right moment. The three honest outcomes:

• Scale. The pilot hit the quantitative metric and did not trip any abort criteria. Move to broader rollout. Write down the integration learnings before they fade.
• Kill. The pilot did not hit the metric, or it tripped an abort criterion. Communicate the kill decision to the vendor in writing within 48 hours of the decision. Do not extend "just to be sure." Most pilots that extend never decide.
• Extend with a written rationale. The pilot was inconclusive because of a specific factor (data quality, vendor-side outage, a single workflow change mid-pilot). A 14-day extension is reasonable if the rationale is specific. A 30-day extension is rarely reasonable.

Document what you learned regardless of the outcome. The next vendor decision in this category gets faster because you have a baseline. A killed pilot is not a wasted pilot if the post-mortem informs the next call.

For the governance layer that wraps vendor selection (policy, audit trail, incident response), see the AI Governance for Insurance Agencies playbook. For the operator-side view of where claims AI vendors deliver the most ROI, see the AI in Claims Operations playbook.