Development of an AI System for Insurance Underwriting

AI insurance underwriting: where the process breaks now

In a typical process, the application goes to the underwriter as a whole: they open several systems, reconcile data on the contract, calculate risk manually, and only then make a decision. One review takes from half an hour to several days, and the client waits the entire time.

Decision turnaround is determined by the workload of a specific specialist, not by the complexity of the risk.

At the same time, the data is fragmented: contract information sits in the accounting system, claims history in another repository, inspection results and external checks arrive as files.

Keys do not match, the same client appears under different spellings, and some fields are filled in manually. Before assessing risk, the specialist spends time reconciling—and still relies on an incomplete picture.

The main loss here is not speed, but reproducibility. The assessment logic lives in the underwriter's head: thresholds, exceptions, and unwritten rules are not documented anywhere.

Two specialists produce different decisions on the same profile, and no one can retroactively explain why a contract was accepted on special terms. For internal audit and supervisory reviews, this is a direct risk.

Risk assessment automation begins not with a model, but with moving rules out of people's heads into an explicit, verifiable form and consolidating contract data into a single customer profile.

Then AI insurance underwriting stops being an experiment and becomes a managed process with a predictable decision turnaround. Below we break down how this is addressed.

Effect for the insurance portfolio: turnaround, quality, declines

Before launch, a typical decision on an auto or property policy takes an underwriter tens of minutes: reconciling the application with inspection documents, checking history, searching for discrepancies between sources.

After launch, such applications are closed in minutes, and the specialist's time goes to where the decision is truly non-obvious.

First weeks: manual review shrinks to exceptions

The share of applications going to manual review falls from most of the flow to a narrow segment—non-standard risks, large sums, contradictory documents.

The system returns a decision together with a rationale for each significant field, so checking takes less time than reviewing from scratch: the underwriter confirms or rejects the conclusion rather than assembling it.

First quarter: consistency of decisions and data cleanliness

Decision variance between specialists shrinks—the same application receives the same risk class regardless of who opened it and which shift they are on.

Working on customer data quality changes the portfolio picture: required fields are filled in at intake, discrepancies between sources are flagged immediately, and the error class 'decision made on incomplete data' stops growing.

Data exchange follows industry standards ACORD, so the application structure remains predictable even when the source changes.

By the end of the quarter

Portfolio risk management becomes measurable: you can see which segments are going negative on loss ratio, where concentration is building up, and which rules need revisiting. Decisions are made based on a summary, not on memory of past deals.

Implementation options: manual review, rules, model

The choice of approach here is a function of flow volume, data homogeneity, and the cost of an error per application. In practice, the options rarely compete: they are layered on top of one another as the portfolio grows and statistics accumulate.

Usually we assemble not one option but a combination: reference data covers frequent cases, the scoring model assesses the middle of the flow, and only borderline applications with discrepancies from external checks go to a specialist.

Switching between modes is done in stages—rules, reference data, and scores live in one schema, so manual review can be narrowed without losing the logic already accumulated and with the ability to return to it for disputed segments.

Implementation stages: from data audit to model handover

The work proceeds sequentially: each next stage relies on the artifacts of the previous one, and we do not start configuring the loop until the decision logic is agreed. Below is the implementation route for an AI system for insurance underwriting.

1. Audit and inventory of historical data. We consolidate application sources into a single inventory: questionnaires, claims history, external and scoring data.

   We look at period depth, missing-value rate, discrepancies between systems, and fields unknown at the time of submission—such features do not enter the model.

2. Application labeling and decision logic. We reconstruct the target label: what we consider a loss event and over what horizon. We review borderline and disputed cases together with underwriters so that the model learns on the same logic as people.

3. Feature schema. We agree on which fields participate in the calculation, where they come from, and how often they are updated. We fix the rules for handling missing values and outliers—otherwise behavior will diverge on new data.

4. Configuring the assessment loop.

   We build a service that returns a probability for an application, not a "yes/no." We set up model versioning, logging of inputs and outputs, and shadow mode: the system calculates in parallel with the underwriter and does not affect decisions.

5. Validation on a holdout sample. We assess quality on applications that did not participate in training, broken down by periods and segments. We look not only at accuracy but also at calibration: a group with a score around 0.2 should produce a similar loss rate.

6. Acceptance. We agree on thresholds, a report with metrics and error analysis, the retraining procedure, and the conditions under which an application goes to manual review.

7. Handover and support. We provide documentation, schemas, access, and training for the client's team. After that, we monitor data drift and update the model according to the agreed procedure.

Handover artifacts: decision rules and review procedures

Handing over a solution is not access to the model.

A model without rules around it goes into a disputed application or a decline when input data changes, so together with the loop the client's team receives a set of documents by which the system can be operated, edited, and defended before reviewers.

• Loop configuration — environments, launch parameters, backup scheme, and the procedure for rolling back to the previous model version when the share of deviations grows.
• Feature and data source schema — which fields are fed as input, where they come from, how often they are updated, and what to do when a source is unavailable.
• Decision rules and trigger thresholds — which combinations of features produce automatic approval, which go to manual review, how thresholds changed and why.
• Procedure for reviewing disputed cases — who reviews, within what timeframe, how the outcome is recorded, and how it is returned to retraining.
• Specialist access matrix — underwriter, analyst, and administrator roles: who sees personal data, who changes thresholds, who exports decision history.
• Model documentation — version, feature set, metrics on the holdout sample, known limitations, and cases where the model is not applied.
• Model update procedure — how often we retrain, who approves the new version, and by which metrics the decision to replace is made.

Each item is agreed with the client before the end of implementation: after handover, questions like 'why did the model decide this way' are closed within the team, without us.

Case study: how manual application review was reduced

Before implementation, the application flow rested on a small group of underwriters: a typical decision took 40-60 minutes, and about a third of applications went to manual review—non-standard types, discrepancies in customer data, objects with a loss history.

Experienced specialists gave different decisions on the same application in roughly every fourth case, and the discrepancy surfaced during contract servicing, when it was too late to change anything.

Metrics before and after

We changed three things: underwriting rules were converted into explicit features instead of 'at the specialist's discretion,' verification of customer and object data was moved before the decision, and disputed cases are flagged by the model and passed to a human together with a risk summary.

Verification goes through Unified Customer Profile, so the discrepancy between declared and actual data is visible before signing, not after.

Reproducibility became measurable: the same set of features produces the same conclusion regardless of who reviews the application. A whole class of errors disappeared—accepting risk based on unverified data; it was precisely this that previously surfaced during claims.

Rules are changed in configuration, so metrics do not degrade for a new product: some applications in manual review are revisited after each update of the risk reference data.

How does hybrid mode differ from fully automatic?

The difference between the modes is not in the model, but in who signs off on the final decision. A fully automatic decision means the result goes into the file without human involvement: the model calculated it, the system recorded it.

In hybrid mode, the model always calculates, but some cases must pass through specialist confirmation.

The boundary is set by the confirmation threshold—a formal set of conditions, not 'at discretion.' It includes the model's confidence in its own conclusion, the completeness and freshness of input data, and the weight of triggered risk factors.

As long as the values are within the specified corridor, the decision goes automatically; as soon as at least one goes beyond the boundary, the case enters the review queue.

The specialist's area of responsibility is described explicitly: they do not recheck the entire flow, but work with cases where the cost of an error is higher and can see which features influenced the conclusion.

Their edit does not dissolve—it returns to the accumulated statistics together with the source data.

Switching modes is a configuration, not a system rewrite. Thresholds and the allowable share of automatic decisions are set separately by product and application intake channel, so one loop can operate strictly in one line and softly in another. If the share of discrepancies grows, the threshold is raised and the automation flow narrows.

As statistics accumulate, the boundary is moved based on discrepancy review: they look at where the model and the specialist diverged and whose assessment was confirmed by the outcome.

Thus the share of decisions passing without a human grows not by lowering requirements, but because the thresholds become more accurate.

Common doubts: data, accuracy, responsibility

Doubts about such a project are almost always the same: whether there is enough history, who is responsible for a model error, what about personal data, and whether the current underwriting will have to be stopped during implementation. Below is how we address each of these questions.

How do you control quality after launch?

We calculate not a single metric but stability across cohorts: product, channel, region, month. We track shifts in input distributions—if the applicant profile changes, the model reports it earlier than it would be noticed in loss ratios. Retraining occurs according to the procedure and by trigger, not "sometime later."

How are errors in a specific decision reviewed?

Every discrepancy with the underwriter's verdict enters the review queue with a full trace: which features influenced it and with what contribution. The underwriter marks the reason, and the label goes into the training set.

Once a month you see the share of discrepancies and their structure—it is clear where the model underlearned and where the methodology itself is disputed.

What about customer data?

Data does not leave your environment: training and calculations run on your infrastructure or in a dedicated environment under your control. Personal fields are anonymized before being fed to the model, access is role-based, and all data access is logged. External export is not provided for by the solution's design.

Can this be launched without stopping the current process?

Yes, the launch is phased. First, the model operates in shadow mode and only recommends; the decision remains with the underwriter. Then automation is enabled on a narrow segment—for example, one product or channel—and expands as accuracy is confirmed.

Rollback to the previous order for any segment is achieved by toggling a setting, without rebuilding the process.

Let's discuss the task and come back with an implementation plan

To come back with an estimate and implementation plan rather than general considerations, we need a minimum set of inputs. The estimate is built on your data: without a sample of closed applications and the rules by which risk is currently calculated, any figure will be a guess.

Below is what to discuss at the first meeting and what we will ask to be provided before work starts.

• Description of the risk assessment process: which factors influence the decision, where manual checks occur, and what share of applications goes to rework.
• An anonymized sample of applications for a period—with features, the underwriter's decision, and the actual contract outcome. On it, we check whether your logic is reproducible on data.
• List of external data sources: bureaus, registries, telemetry, document scans—with the response format and limits on request frequency.
• Contacts for related systems: policy accounting, document management, application intake channel—to coordinate data exchange without intermediaries.
• Constraints on timelines and launch mode: whether shadow mode alongside the current process is acceptable or the solution immediately affects issuance.
• Acceptance criteria: what share of decisions may be automated and at what loss ratio the result is considered workable.

With this set, we come back with an estimate and implementation plan: stages, scope of work, model quality control points, and the procedure for moving to production. Describe the task—we will clarify what is missing and provide timelines.