Build vs Buy for Insurance AI: An Honest Framework

Every insurance AI conversation reaches the same fork: do we build this or buy it? And it usually gets decided by whoever is most persuasive in the room rather than by anything resembling a framework.

Here's a more honest way to think about it — including the part both vendors and internal teams have an incentive not to mention.

The question is wrong

"Build or buy?" implies one decision. It isn't. An insurance AI capability has four layers, and the right answer is different for each:

  1. The data foundation — pipelines, identity, quality, governance
  2. The models — risk scoring, triage, extraction, fraud
  3. The orchestration — agents, workflow, human-in-the-loop gates
  4. The interface — what underwriters, adjusters, and customers touch

Teams that ask "build or buy" as one question pick one answer and apply it to all four. That's how you get a carrier building their own document OCR from scratch (madness) or buying a black-box "AI underwriting platform" that can't see their data (also madness).

Layer by layer

Layer 1 — the data foundation: BUILD (with help).

This is yours, permanently, and it's your only durable advantage. Your customer key, your quality rules, your lineage — nobody can sell you these because they're specific to your systems, your products, and your regulator. Vendors will offer to host it, and there's a real conversation about who operates it. But the modelling, the definitions, the resolution logic — you own that or you own nothing.

Bring in help for speed and scar tissue. Don't outsource the decisions.

Layer 2 — the models: BUY (mostly).

This is where most carriers get it backwards. Document extraction, image assessment, general language understanding — these are commodities now. Building your own is a two-year exercise in reaching parity with something you could licence next week.

The exception: models trained on your book. Your loss experience, your fraud patterns, your renewal behaviour. That's proprietary and worth building — but note it's only possible if layer 1 exists. Which is the whole point.

Layer 3 — orchestration: DEPENDS, and get this right.

This is where the regulated bits live: approval gates, audit trails, guardrails. Buying is fine if the product exposes those as configuration your risk team controls, and produces an audit record you'd be comfortable handing a regulator.

Most don't. Most agent platforms were built for use cases where a wrong answer is embarrassing, not where it's a compliance breach. If you can't configure "payouts over ₹2 lakh need human approval" without a vendor release, that's not a product for a regulated line.

Layer 4 — the interface: BUY, then stop customising.

Nobody wins on their claims screen. Buy it, accept 80% fit, and spend the saved effort on layer 1. The instinct to customise the UI to existing workflows is how three-month deployments become two-year ones.

The four questions that actually decide it

1. Is this our differentiator, or table stakes? Your fraud model trained on your book: differentiator. OCR: table stakes. Never build table stakes; never outsource a differentiator.

2. Can we operate it at 3am? Building means owning it forever — on-call, upgrades, the person who understands it leaving. Most build business cases count construction and quietly omit the decade of operation.

3. Would we be locked in? If a vendor compiles your logic into their proprietary format on their infrastructure, leaving is a rebuild. That's acceptable for layer 4, dangerous for layers 1–3. Ask specifically: can we export our data, our config, and our decision history?

4. Can it satisfy a regulator on its own? With NAIC live across 23 US jurisdictions and the EU AI Act landing through August 2026, "the vendor handles compliance" isn't a defence — you are the regulated entity. If the product can't produce lineage and per-decision records, you'll build that anyway, on top, badly.

The trap nobody names

Here's the part that's uncomfortable for everyone selling anything, us included.

Most "build vs buy" debates are a way of avoiding layer 1.

Building a model is interesting. Evaluating vendors is interesting. Resolving customer identity across four legacy systems is not interesting, and it has no launch event. So the organisation debates layers 2–4 energetically for months while the thing that decides all of them goes unfunded.

Then the bought platform underperforms — because it's reading fragmented, stale data — and the conclusion drawn is "we should have built it." So they build it. And it underperforms too, for exactly the same reason. Nobody connects the two.

If your data foundation is weak, build and buy fail identically. The decision you're agonising over doesn't matter yet.

A short answer

Score your data readiness honestly first. If you're not ready, the build-vs-buy debate is theatre — fix the foundation and revisit in two quarters.

If you are ready: build layer 1, buy layer 2, scrutinise layer 3 for approval gates and audit, buy layer 4 and leave it alone.

And treat anyone — vendor or internal champion — who answers "build or buy?" without first asking about your data foundation as someone who has told you exactly how much they understand about the problem.

We build layer 1 — the data foundations insurance AI runs on — and we'll tell you honestly which layers to buy. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Snowflake or Databricks for Insurers? An Honest Comparison

It's the question in every insurance data platform decision, and it generates more heat than insight: Snowflake or Databricks? Here's an honest answer from having migrated a lot of both. Short version: they're both excellent, the gap is narrower than either vendor implies, and the decision matters far less than what you do next. But there are real differences, and your workload should pick. Where each genuinely leads Snowflake is stronger when your centre of gravity is SQL analytics. Reporting, actuarial analysis, regulatory extracts, BI over structured policy and claims data. It's operationally calmer — less to tune, fewer knobs, and your existing SQL people are productive on day one. Separation of storage and compute means the finance team's month-end doesn't fight the actuaries' model run. For a carrier whose data is mostly relational and whose consumers are mostly analysts, it's the shorter path. Databricks is stronger when your centre of g...
Read more

What 200+ Cloud Migrations Taught Us About Insurance Data

Over 200 cloud migrations, patterns emerge. Not the ones in the vendor case studies — the ones you only see from inside, at 2am, when the reconciliation doesn't balance. Here's what we've actually learned about insurance data. Some of it is uncomfortable. 1. The estimate is always wrong in the same direction Every migration takes longer than planned, and almost never because of the technology. It's because of what you find: a rating rule nobody documented, a batch job that silently corrects bad data at 2am, a product variant that exists only in one state. The work isn't moving data. It's discovering what the old system actually does — which nobody knows in full, because the people who knew have retired. Budget for archaeology, not just engineering. 2. Every reconciliation mismatch is a gift When your new premium calculation disagrees with the legacy system by ₹40 on 300 policies, the instinct is to treat it as a bug to squash quickly. Don't. Tha...
Read more

From Mainframe to Lakehouse: How to Modernize a 30-Year-Old Policy System Without Downtime

Ask any insurance CTO what keeps them from modernizing, and you'll rarely hear "budget" or "talent." You'll hear something closer to fear: the policy administration system has been running since the 1990s, it processes every quote, endorsement, and renewal the company makes, nobody who wrote it still works there — and the business cannot go dark for even an afternoon. So the migration gets deferred. Another year passes. Meanwhile every AI initiative, every customer-experience project, and every analytics roadmap quietly starves, because they all need data that's trapped inside that system. Here's the thing: the fear is rational, but the conclusion isn't. Migrating a legacy policy core without downtime is well-trodden ground. It just requires abandoning the approach everyone instinctively reaches for. Why the big-bang cutover fails The instinct is to build the replacement, pick a weekend, flip the switch, and pray. This fails for a predict...
Read more