IntelliBooks — AI in Insurance

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: The data foundation — pipelines, identity, quality, governance The models — risk scoring, triage, extraction, fraud The orchestration — agents, workflow, human-in-the-loop gates 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 ...

You built the data warehouse. It took eighteen months and cost more than planned. Policy data, claims data, billing — it's all in there. The project was declared a success and everyone moved on. And yet: underwriting still can't see the whole customer. The AI initiative is still stalled. Someone still asks for a report and waits three weeks. Nobody says it out loud, but the question hangs there — what exactly did we buy? You're not alone, and it isn't because you built it badly. It's because a warehouse solves a problem you didn't have. The problem a warehouse solves Warehouses solve location . Before: your data was in eight systems. After: it's in one place. That's genuinely valuable — you can run a query across policy and claims without begging two teams for extracts. But notice what that fixes: it fixes where the data is . It doesn't touch what the data means , whether it's trustworthy, or whether the records refer to who you think t...

Ask a motor insurer with a telematics programme how much data they're collecting. You'll get an impressive number — billions of GPS points, accelerometer readings, trip records, harsh-braking events. Then ask what decisions that data actually changes. The answer is usually: a discount at renewal, and a dashboard nobody opens. That's a remarkable gap. You built the collection infrastructure — the hard, expensive part — and then used maybe 5% of what it produces. The pattern is everywhere in insurance IoT It's not just motor: Telematics collects continuous driving behaviour, and is used to apply one annual discount tier. Connected home sensors detect leaks and are used to... send the customer an app notification. Commercial IoT monitors equipment continuously, and feeds a quarterly risk-engineering report. Wearables in health and life gather daily activity, and drive a points-and-vouchers scheme. In each case the data is high-frequency and behavioural...

Here's an uncomfortable estimate: somewhere between 60% and 80% of what your insurance company knows isn't in a database at all. It's in documents. Policy wordings. Medical records. Police reports. Repair estimates. Surveyor reports. Correspondence. Endorsement letters. Forty years of accumulated PDFs, scans, faxes-turned-images, and email attachments — full of exactly the facts every AI model on your roadmap wants, and structurally unable to give them up. This is the quietest bottleneck in insurance data, and it blocks more than people realise. Why this is worse in insurance than elsewhere Plenty of industries have documents. Insurance has a specific compounding problem: The documents are the contract. A policy wording isn't a description of coverage — it is the coverage. What's in that PDF is legally what you owe. You can't approximate it. They arrive from everywhere. Hospitals, garages, police, surveyors, brokers, customers — none of whom use y...

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work. They're nearly blind to organised fraud — and organised fraud is where the money goes. The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer. What a fraud ring actually looks like A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months. Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolati...

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...

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...

Every insurance data conversation eventually reaches a fork: should this be real-time or batch? And it's usually answered badly — either "stream everything, it's 2026" or "batch is fine, it always has been." Both answers are expensive. Here's the rule that actually works. The rule: follow the decay rate Data should be as fresh as the decision that consumes it — no fresher. Ask one question of any data flow: how fast does this signal lose its value? A fraud indicator at first notice of loss decays in minutes — once the claim is paid, the signal is worthless no matter how accurate. A policyholder's date of birth doesn't decay at all. Streaming the second is pure cost; batching the first is a fraud loss. That's the whole framework. Not "is it important" — importance is not the same as urgency. Loss-ratio reporting is extremely important and perfectly fine at T+1. What genuinely needs real-time in insurance FNOL and cla...

Almost every insurer has a chatbot story, and almost none of them are good. It launched with a press release, deflected 12% of contact-centre volume, annoyed customers into typing "agent" within two messages, and now sits on the site as a small, embarrassed bubble nobody talks about. Now the same vendors are back selling "AI agents." Fair question: what's actually different, or is this the same disappointment with a better model behind it? It's genuinely different — but not for the reason most pitches claim. Why the chatbot failed (it wasn't the language) The post-mortem usually blames the NLP: it didn't understand people. That was true in 2019 and it's irrelevant now — modern models understand intent fine. The real failure was that your chatbot couldn't do anything . It was a decision tree with a text box. It could answer "what are your office hours" and route you to a PDF. Ask it something a customer actually cares abo...

There's a distinction being blurred in every insurance AI pitch right now, and it matters more than any feature list. It's the difference between AI that helps your adjuster and AI that runs the claim. 2026–2027 is when the industry crosses that line. Understanding which side a product sits on tells you what it's worth — and what it'll cost you if it goes wrong. The maturity curve Stage 1 — Manual. A human does the work. Software is a system of record. Straight-through processing: 10–15%. This is still most of the market. Stage 2 — AI-assisted. The human runs the claim; AI helps on discrete tasks — summarise the FNOL, extract fields from a PDF, suggest a reserve, draft the letter. The human remains the orchestrator: they decide what happens next, every time. This is where most "AI in claims" deployments actually are. It's genuinely useful — 20–30% time savings are common — but it's bounded. You're making a person faster, not removing ...

A customer is declined. They ask why. What do you say? "Our model scored you below threshold" is not an answer. It's not an answer to the customer, and it is emphatically not an answer to a regulator. Yet it's functionally what a lot of AI underwriting can produce today. With the NAIC Model Bulletin adopted across 23 US jurisdictions and the EU AI Act classifying insurance pricing and risk assessment as high-risk, "the model decided" has stopped being an awkward answer and started being a compliance failure. Here's what explainable underwriting actually requires — in engineering terms, not legal ones. Three different questions people conflate "Explainability" gets used for three distinct requirements. They need different solutions, and mixing them up is why teams flounder. 1. Why this decision? (Adverse action.) The customer was declined or surcharged — which specific factors drove that? This is per-decision and legally required. 2...

Before you sign an AI contract, spend twenty minutes on this instead. It'll tell you more about whether the project will succeed than any vendor demo. Roughly 80% of the effort in a successful insurance AI project goes into data, not models. So the useful question isn't "which AI should we buy?" It's " is our data ready for any AI at all? " That question is measurable. Here's how to measure it. Score each item 0, 1, or 2. Be honest — the point is to find gaps, not to pass. Section 1: Foundation 1. Single source of truth. Is there one place where policy, claims, and billing data live together and can be queried in one join? 0 = data lives only in source systems · 1 = a warehouse exists but is partial/stale · 2 = one governed platform, all core domains 2. Stable customer key. Can you identify the same person across every product line, reliably, today? 0 = no · 1 = partial matching, no durable ID · 2 = resolved identity with a persistent k...

Straight-through processing is the number every insurance executive quotes and almost nobody achieves. The industry benchmark has moved from 10–15% to 70–90% at the carriers who've cracked it. That's not a marginal efficiency gain — it's a different cost structure. So why is your STP rate still stuck in the teens? Because STP gets treated as a workflow project. It isn't. It's a data problem wearing a workflow costume. What STP actually requires Straight-through means a quote, policy, or claim goes from submission to completion with zero human touches . For that to happen, every decision point in the chain has to be answerable automatically. Every single one. A chain of nine automated steps and one manual check isn't 90% straight-through — it's 0%. One human touch and the whole thing is a manual process with extra steps. That's the bar. And it means the constraint isn't the workflow engine — it's whether the data needed at each decisio...

Try this experiment at your carrier. Pick a real customer — someone who holds an auto policy, filed a home claim two years ago, and called the contact centre last month. Now ask a simple question: show me everything we know about this person. At most insurers, that question takes days and a small committee. At some, it can't be answered at all. This isn't a technology embarrassment. It's the single biggest constraint on everything the business wants to do next — cross-sell, retention, personalised pricing, AI of any kind. How one person becomes four strangers Insurance grew by product line, and the systems followed. Auto lives in one platform, property in another, life in a third. Billing has its own customer record. The CRM has another. The claims system has yet another, keyed differently again. So "Rajesh Kumar, 42, Pune" exists as: Customer A-88213 in the auto system (name spelled "Rajesh Kumar") Insured P-4471 in property (name "...

Every insurer knows their data isn't perfect. Ask an underwriting leader and you'll get a shrug and something like "yeah, it's messy, we work around it." That shrug is one of the most expensive gestures in the industry. Dirty data in underwriting doesn't announce itself. It doesn't crash a system or trigger an alert. It quietly mis-prices risk, one policy at a time, for years — and the bill arrives as a loss ratio nobody can fully explain. What "dirty" actually means here It's rarely dramatic corruption. It's mundane: Missing fields. Roof age is blank on 30% of property records, so the model treats "unknown" as "average." Average is wrong in both directions. Inconsistent codes. Construction type is "frame" in one system, "FR" in another, and "Wood Frame" in a third. Your model sees three risk classes where there's one. Free text where structure belongs. Prior claims histo...

"AI in insurance" has crossed the line from conference talk to line item. Carriers aren't asking whether to use it anymore — they're asking which use cases are actually paying off, and which are still demo-ware. Here are nine that are genuinely working in 2026, with the numbers behind them — and one honest caveat at the end that decides whether any of them work for you. 1. Underwriting automation The headline shift: underwriting timelines have collapsed from three days to three minutes , and straight-through processing rates have jumped from 10–15% to 70–90% . Models pull from credit data, medical records, IoT sensors, satellite imagery, and hundreds of other sources to price risk in near real time. What makes it work: a clean, unified view of the applicant. What breaks it: pulling from six systems that disagree about who the applicant is. 2. Claims triage at first notice of loss Instead of a queue and a human sorting it, AI reads the FNOL — text, photos, str...

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...