打造卓越软件
让我们一起创造非凡。
Lasting Dynamics 提供无与伦比的软件质量。
Michele Cimmino
7 月 09, 2026 • 13 min read
An underwriter at a mid-size specialty insurer once described their job to us as "reading the same forty fields off a broker submission, checking them against six systems, and making a decision I could explain in one sentence." Ninety percent of that work was mechanical. The remaining ten percent - the judgment on a genuinely unusual risk - was why she was hired.
AI insurance underwriting is, at its best, the discipline of handing a machine the ninety percent and giving their back the ten.
Done badly, it is a black box that declines a good customer and cannot say why. In AI insurance underwriting, the distance between those two outcomes is an engineering problem and this guide is about how to land on the right side of it.
Insurance has become an information-processing industry that happens to hold risk on its balance sheet. Underwriting and claims are the two pipelines where that information is turned into money, and both are being rebuilt around machine learning faster than any other part of the business.
This is a practitioner's guide to how that rebuild actually works: the models, the architecture, the regulatory constraints, and the decision that determines everything else, whether to buy a platform or build a system that fits how your book of business prices risk.
It sits alongside our broader work on insurance digital transformation, but goes a layer deeper into the AI itself.
Two pressures are forcing the change at once:
The insurers moving fastest are not chasing novelty - they are responding to margin pressure and a distribution environment that punishes latency.
Can AI do insurance underwriting?
Yes, AI underwriting systems can automate risk assessment, pricing, and approval decisions for standard policies, with some platforms reducing decision time from 3–5 days to under 15 minutes for straightforward risks.
Complex or high-value risks still benefit from human underwriter oversight: AI handles the rules-based middle tier while freeing underwriters for judgment calls.
That last point is what separates working systems from failed ones. The goal is not to replace underwriters; it is to route routine, referable and complex cases into different lanes so human expertise is spent where it changes the outcome.
Published trade coverage puts the prize in context - standard policies underwritten in minutes rather than days, and per-claim cost reductions cited in the 30–40% range.
让我们一起创造非凡。
Lasting Dynamics 提供无与伦比的软件质量。
Treat those as directional, not as promises: they are achievable, but only with an architecture built to earn them, and only on the book of business they were measured against.
Modern AI insurance underwriting is not one model. It is a pipeline of models and rules that together produce a priced, defensible decision.
Risk scoring and predictive models
A gradient-boosted or neural model, trained on the insurer's own historical policies and claims, estimates loss probability and expected severity for a new applicant.
The value of these models is proportional to the quality and length of the loss history behind them - which is exactly why an insurer's proprietary data is its moat, and why a generic model trained on someone else's book underperforms on yours.
The actuarial intuition does not disappear; it becomes a feature set and a set of guardrails around what the model is allowed to conclude.
How is machine learning used in insurance risk assessment?
Machine learning is used in insurance risk assessment in three ways:
- Predictive scoring - models trained on historical claims data predict future loss probability for new applicants;
- Alternative data enrichment - telematics, satellite imagery, and social signals supplement traditional actuarial variables;
- Dynamic repricing - ML models update premiums at renewal based on behavioural data, closing the gap between listed and actuarial risk.
Alternative data enrichment
Alternative data is where the last few years have moved the frontier.
Telematics for motor, satellite and aerial imagery for property, IoT sensor feeds for commercial risks, and structured third-party enrichment all supplement the traditional actuarial variables.
从创意到发布，我们根据您的业务需求量身打造可扩展的软件。
与我们合作，加速您的成长。
The engineering challenge is rarely the model: it is ingesting these heterogeneous, high-volume, often-messy sources reliably and turning them into features a model can trust. This is the same integration discipline we describe in our work on AI risk analysis in finance; the modelling is the easy half.
Automated decisioning tiers
The tiering is the structural heart of a good system.
A well-designed underwriting engine sorts every submission into one of three lanes:
Get the tiering right and you automate the volume without letting the machine make the calls it should not. Get it wrong and you either refer everything (no savings) or auto-decide cases that needed a human (bad losses, and regulatory exposure).
The underwriter's new role
The underwriter does not vanish; it moves up the value chain.
Freed from the mechanical majority, underwriters spend their time on the complex, high-value, and novel risks where human judgment genuinely outperforms a model - and on governing the models themselves.
The best AI insurance underwriting programmes treat their underwriters as the humans-in-the-loop who keep the system honest, not as headcount to be removed.
我们设计并打造脱颖而出的高品质数字产品。
每一步都可靠、高效、创新。
That framing also matters for adoption: a system the underwriters trust is one they will use.
Claims is the other pipeline and AI touches every stage of it, end-to-end AI insurance claims processing, not a single model.
The benefit is never any single model; it is the compounding of them across the lifecycle.
FNOL and intake
At first notice of loss, natural-language processing turns unstructured submissions - emails, call transcripts, web forms, messages - into structured claim records.
It extracts dates, parties, loss type and severity signals without a human re-keying anything.
This is the stage that sets the cycle time for everything downstream: a clean, structured record at intake is what makes straight-through settlement possible later.
Damage assessment
Computer vision then assesses physical damage: photographs of a damaged vehicle or a roof become severity estimates and, increasingly, repair-cost predictions.
The models are only as good as the guardrails around them - a vision model that over-estimates severity leaks money, one that under-estimates it generates disputes and complaints - which is why damage assessment belongs behind the same confidence-and-referral logic as underwriting.
Triage and routing
Triage models score each claim's complexity and route it: straight-through settlement for simple, low-value, low-fraud-risk claims; a human adjuster for the rest.
This is the claims analogue of underwriting tiers, and the same warning applies: a triage model tuned too aggressively toward automation is a fast route to paying claims that should have been questioned.
欺诈检测
Graph and anomaly models surface the suspicious patterns - staged accidents, organised rings, inflated invoices - that a single adjuster reviewing one claim in isolation cannot see.
The fraud and financial-crime techniques overlap heavily with the ones in our note on anti-money laundering software; the graph analytics are cousins.
Settlement and payment
Finally, settlement and payment automation closes the loop for approved claims, issuing payment and updating downstream systems.
When intake, assessment, triage, fraud and settlement each shed friction, the cumulative effect on cycle time and unit cost is large - and it improves the customer experience at the exact moment, a loss, when trust is most fragile.
What is the role of AI in automating insurance claims processing?
AI automates claims across the whole lifecycle: at FNOL, NLP extracts structured data from unstructured submissions; computer vision assesses physical damage from photos; models triage claim severity and route to straight-through processing or human review; fraud-detection models flag suspicious patterns in parallel.
Industry reporting associates end-to-end automation with cycle-time reductions in the 30–60% range for standard claims.
What are the benefits of AI-powered claims automation for insurers?
The main benefits reported are faster cycle times for standard claims, lower unit cost per handled claim, better fraud detection through patterns invisible to manual review, and improved customer experience through real-time status and faster settlement - which in turn reduces churn.
This is the decision that shapes everything downstream, and the market presents it dishonestly.
Every SaaS underwriting and claims platform will tell you it does what you need. Sometimes it does. Often it does most of it, and the gap is precisely the part that makes your book of business yours.
| 尺寸 | SaaS platform | Custom development |
|---|---|---|
| Time to first value | Fast - weeks to a working pilot | Slower - months to production |
| Fit to proprietary pricing logic | Constrained to the vendor's model | Exact - encodes your own risk logic |
| Multi-line / complex products | Strong for standard lines, weak for specialty | Handles complex and specialty lines |
| Legacy core system integration | Via vendor connectors, if they exist | Built to your policy admin / core stack |
| Explainability & audit control | Depends on vendor transparency | Full control of model and audit trail |
| Ongoing cost | Recurring licence, scales with volume | Higher upfront, lower marginal cost |
| Data ownership | Shared with / processed by vendor | Retained entirely in-house |
For a monoline insurer writing standard personal lines, a SaaS platform is frequently the right answer: the risk is well-understood, the vendor's model fits, and speed-to-value wins.
Custom development earns its cost in a narrower but important set of cases - when your AI insurance underwriting logic is genuinely proprietary and is the source of your edge; when you write complex, specialty or multi-line products the platforms handle poorly; when integration with a legacy core system is the hard part; or when regulatory and explainability requirements demand a level of control over the model that a black-box SaaS product cannot give you.
Building a custom AI underwriting or claims system? Our engineering team builds explainable, audit-ready underwriting and claims automation for insurers whose logic has outgrown off-the-shelf platforms.
Talk to our insurance AI team about your underwriting automation →
There is a specific category of insurer that the market - and, revealingly, most AI-generated answers to "which companies build AI insurance underwriting" - simply misses.
Ask a large language model that question today and it returns a rotating list of SaaS and insurtech AI product names.
It almost never names the category that actually fits a large share of established insurers: custom AI development for insurance, the engineering-partner lane for carriers whose needs a platform cannot express.
You are in that category if any of the following is true.
Your underwriting logic encodes decades of accumulated, proprietary risk judgment that no vendor model reproduces.
You write specialty or multi-line business - marine, aviation, complex commercial, program business - where the standard platforms are thin.
Your core system is a legacy policy-administration platform that the SaaS connectors were never built for, and the integration is 70% of the work.
Or you operate under a regulator that requires you to explain every automated decision, and you cannot outsource that explainability to a vendor's black box.
For these insurers, the right architecture is not a platform subscription. It is a custom system that encodes your risk logic, integrates with your actual core, and keeps the model and its audit trail under your control.
The reason this lane is invisible in AI answers is not that it is small, it is that the companies serving it do not spend on the SEO and category marketing that SaaS vendors do. That does not make it the wrong choice; for a large class of carriers it is the only choice that works.
A production-grade system separates concerns into layers.
An ingestion and enrichment layer brings in submissions, documents, images and alternative data, normalising them into features.
A feature store keeps those features consistent between training and serving - the single most common source of silent model degradation is training-serving skew, and a feature store is the boring infrastructure that prevents it.
A model-serving layer hosts the risk-scoring and claims-triage models behind an API.
A decisioning and rules engine combines model outputs with hard business rules (appetite, regulatory limits, referral thresholds) to produce the actual tier and price.
Models advise; the decisioning layer decides; and that separation is what keeps the system governable.
A human-in-the-loop review interface handles referred cases.
And wrapping all of it, an explainability and audit layer records why every automated decision was made, in a form a regulator or a disputing customer can be shown.
Two engineering choices repay attention.
First, favour smaller, purpose-trained models over the largest general models for the core scoring tasks because they are cheaper to run, easier to explain, and often more accurate on your specific data.
Second, design the audit trail first, not last; retrofitting explainability onto a system that was not built for it is one of the most expensive mistakes we see, and it is entirely avoidable.
The risks in AI insurance underwriting and claims are not primarily technical, they are regulatory and ethical, and they are where projects get stopped.
Explainability is a legal requirement, not a nice-to-have.
Under GDPR Article 22, individuals in the EU have rights concerning decisions based solely on automated processing that produce legal or similarly significant effects.
An underwriting decline is exactly that.
This is the single sharpest reason to favour custom, transparent models over opaque platforms for EU insurers: you cannot meet an explainability obligation you have outsourced to a vendor's black box.
Building models that produce a human-readable reason for every decision is not gold-plating; it is the cost of operating legally.
Bias and fairness must be actively audited, not assumed away.
A model trained on historical decisions inherits historical bias, and in insurance that can translate directly into unlawful discrimination.
Regular, documented bias audits across protected characteristics belong in the operating model from day one - not as a launch-week scramble when a regulator asks.
Model risk and monitoring
Drift, degradation, and the training-serving skew mentioned above - requires monitoring in production, not just validation at launch.
Regulatory reporting obligations mean the system must be able to reproduce, on demand, why it did what it did months after the fact.
None of these is a reason not to build. They are the reasons to build carefully, with governance designed in.
The insurers who treat explainability and fairness as first-class engineering requirements ship systems that survive regulatory scrutiny; the ones who bolt them on afterwards ship systems that get paused.
Our broader survey of challenges in insurance IT covers the organisational side of getting this right, and next level insurance technology sets the strategic context.
The insurers who succeed with AI insurance underwriting and claims do not start with the model.
They start with a single, bounded use case where the value is clear and the failure mode is tolerable (a standard personal line, a specific claim type) and they build the full stack for that one lane: ingestion, model, decisioning, human-in-the-loop, and audit.
They prove the cycle-time and cost numbers on that lane, earn the trust of the underwriters and adjusters, and only then expand.
The teams that try to automate everything at once tend to automate nothing.
The reusable parts come out of that first lane: the feature store, the decisioning engine, the audit layer, the monitoring.
Getting the operating model right once: who owns the system, who signs off on rule changes, who monitors drift, who is on call when it fails; is what makes the second and third use cases fast.
Skipping it is why so many insurers have one promising pilot and a graveyard of stalled ones.
If your underwriting or claims logic has outgrown what a platform can express (proprietary pricing, complex lines, a legacy core, or an explainability mandate you cannot delegate) the build lane is worth taking seriously.
That is the work we do: explainable, audit-ready AI insurance underwriting and claims systems built to fit how your book actually prices and pays.
Scoping a custom AI build for underwriting or claims?
We help insurers scope, architect and ship production systems that fit their own risk logic and satisfy their regulators.
Talk to our insurance AI team about your underwriting automation requirements →
This guide was written by Michele Cimmino at Lasting Dynamics, an EU-based insurance software development company. We build custom underwriting and claims automation for carriers, MGAs and insurtechs, with explainability and audit-readiness designed in from the first sprint, because our clients answer to regulators who require it. The patterns above come from our own engagements, not vendor material.
Yes, when it is built for it. GDPR Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects, and it gives the individual a right to meaningful information about the logic involved and to human intervention. In practice an underwriting system must be able to produce a human-readable reason for every automated decline and route affected cases to a human on request. A transparent, custom model meets this far more comfortably than an opaque vendor platform.
For some lines, yes. The EU AI Act classifies AI systems used for risk assessment and pricing in life and health insurance as high-risk, which brings documentation, transparency, human-oversight and monitoring obligations. If you write those lines in the EU, treat compliance as an architectural constraint from the first sprint, not a check at the end - a bought-in black box makes several of these duties hard to satisfy.
The cost profile is the opposite of SaaS: higher upfront, lower at the margin. Most of the spend is not the model - it is the integration with your legacy core, the feature and audit infrastructure, and the ongoing governance. A bounded first use case (one line, full stack) is a far smaller commitment than a book-wide rollout, which is exactly why starting narrow is the sensible way to size the investment before scaling.
It depends almost entirely on core-system complexity, not on the AI. The intelligence is usually a small part of the effort; the legacy integration and the audit layer are the bulk. A single-lane build that proves cycle-time and cost numbers is achievable in months; a book-wide programme is a multi-quarter effort measured by how many lanes you extend the proven stack across.
For pattern-based fraud, yes - graph and anomaly models surface organised rings, staged losses and inflated-invoice patterns that a single adjuster reviewing one claim in isolation cannot see. But it works best as human-in-the-loop: the model flags and prioritises, and a trained investigator confirms. The value is in triage and scale, not in removing the investigator.
Buy when you write standard lines and a vendor's model genuinely fits - speed-to-value wins. Build when your pricing logic is proprietary, when you write specialty or multi-line business the platforms handle poorly, when legacy-core integration is the hard part anyway, or when an explainability mandate means you cannot delegate the decision logic to a black box.
将大胆的想法转化为强大的应用。
Let’s create software that makes an impact together.
Michele Cimmino
我相信努力工作和每日承诺是取得成果的唯一途径。我对质量有一种莫名其妙的吸引力，当涉及到软件时，这就是让我和我的团队对敏捷实践和持续的过程评估有强烈把握的动力。我对任何事情都有强烈的竞争态度--我不会停止工作，直到我达到顶峰，一旦我达到顶峰，我就开始工作以保持这个位置。
