A commercial lines underwriter opens a submission email. Inside are three PDFs, a partially completed ACORD 125, a loss run that does not match the named insured, and a note asking for a quote by Friday. Before any judgment about risk appetite or pricing happens, someone spends twenty minutes reading, re-keying, and chasing the missing pieces. Multiply that by every submission in the queue and you have found where the day actually goes.
Insurance is often described as a decision business. In practice, many insurance workflows are reading workflows before they become decision workflows. The decisions are real and they carry capital weight, but they sit on top of a thick layer of document handling, format translation, and follow-up that nobody enjoys and everybody underestimates. That layer is where automation should start, and it is the part most teams skip because the word "AI" pulls attention straight to the hard, discretionary calls.
Insurance work is mostly reading, not deciding
Property and casualty carriers track underwriting profitability through the combined ratio, which folds together loss costs and operating expense. Both halves matter. You can write good risks and still bleed margin if the expense side is dominated by manual handling. A lot of that handling lives in the gaps between systems: email inboxes, PDFs, ACORD forms, ACORD P&C data standards, carrier portals, agency management systems, policy admin systems, billing systems, and claims systems that were never designed to talk to each other.
ACORD's P&C data standards define structured formats such as AL3 and XML, and they cover the recurring business cases: new business quote, submission, policy change, renewal, and reinstatement. The standards exist precisely because the same data has to move between parties who all store it differently. IVANS Download and eDocs automate the exchange of policy and claims information, direct-bill commission statements, and policy-related eDocs or messages into agency management systems, which removes a chunk of the manual lift. But anyone who runs an agency knows what is left over: download exceptions that do not match a known policy, incomplete documents, portal-only carriers, and the steady drip of manual follow-up.
The pattern repeats across the business. The structured rails carry the clean cases. The people carry everything that falls off the rails. That residue is the real target.
The deterministic wedge
Here is the argument in one line. Do not start by asking AI to make judgment calls. Start by using AI to read, route, compare, draft, fill, reconcile, and log.
Those seven verbs describe deterministic or near-deterministic work. You can write tests for them. You can set a confidence threshold and send anything below it to a human. You can keep a complete record of what came in, what the system did, and what a person approved. None of that requires the model to have an opinion about whether a roofing contractor in a wildfire zone is an acceptable risk.
A useful way to sequence the work is a capability ladder:
| Level | What the system does | Human role |
|---|---|---|
| L1 | Read and extract structured fields from documents | Reviews exceptions |
| L2 | Classify and route to the right queue or person | Spot-checks routing |
| L3 | Compare and reconcile against a source of truth | Approves discrepancies |
| L4 | Draft responses, fill forms, package files | Edits and signs off |
| L5 | Recommend a discretionary decision with evidence | Makes the call |
Much of the durable time savings lives in L1 through L4. These are the levels where the input is a document, the output is checkable, and the cost of a wrong answer is "a person fixes it in the exception queue" rather than "we mispriced a book." The model can be small and cheap, because the task is reading and matching, not reasoning about risk.
The counter-intuitive part: teams that jump straight to L5 autonomy usually get worse results and a harder governance story than teams that grind out L1 through L4 first. The discretionary layer only works when the boring layer beneath it is reliable, instrumented, and trusted.
| Workflow | Manual pattern | Automation pattern | Practical win |
|---|---|---|---|
| New business submission | Read email, open PDFs, re-key fields into AMS or underwriting queue | Extract required fields, validate against rules, flag missing data, draft the activity | Faster first touch and less expert time spent typing |
| Certificate request | Look up policy, check holder wording, create certificate, update activity | Parse request, compare requirements to current coverage, generate draft, route exceptions | Same-day service on routine COIs without removing human review |
| Policy checking | Compare issued policy to binder line by line | Diff policy forms, limits, endorsements, named insured, dates, and premiums | Fewer missed discrepancies and less fatigue work |
| Billing mismatch | Manually trace invoice, payment, commission, and account records | Match records, classify mismatch type, resolve obvious items, queue exceptions | Cleaner cash application and fewer back-office loops |
| FNOL intake | Convert call notes, email, forms, and photos into a claim shell | Structure loss details, attach documents, assign first queue, request missing facts | Faster claim creation without automating coverage decisions |
The common shape matters more than the specific department. A document or record comes in, the system compares it to a known source of truth, and anything uncertain goes to a person.
Where the time hides on the policy side
Walk the policy lifecycle and the deterministic opportunities are everywhere.
Submission intake. Email plus attachments come in. A system can extract the named insured, mailing address, classification codes, requested limits, and prior carrier from an ACORD application, flag the missing fields, and route a clean package to the underwriter. McKinsey described a small commercial example where a carrier built a platform to quote and bind in minutes rather than days, and aimed to reduce manual inputs by up to 90 percent. Read that as an analytical example of what intake automation can do, not a promise for every line of business.
Underwriting triage. Before pricing, someone sorts submissions into "in appetite, complete," "in appetite, missing data," and "out of appetite." That sort is rules work. Classification and routing handle it, and the underwriter spends time on the risks that actually need a human.
Renewals. Renewal prep is largely comparison: what changed since last term, what exposures grew, what endorsements are stale. A reconciliation step that diffs the expiring policy against current data surfaces the few items worth a conversation.
Certificates of insurance. COI requests are high volume and low judgment. Extract the holder requirements, match them against the policy, generate the certificate, and flag the rare case where coverage does not meet the contract language. This is one of the cleanest wins in the entire business.
Endorsements and policy changes. A mid-term change request is a structured edit. Reading the request, checking it against the policy, and drafting the endorsement is deterministic until you hit a genuine coverage question, which is exactly when a human should step in.
Policy checking. Comparing the issued policy against the quote or the binder is line-by-line comparison work. Machines are better at it than tired humans at 5 PM.
Carrier download exceptions and billing. Download exceptions and billing mismatches are reconciliation problems. Match the incoming record to the known policy, resolve what is unambiguous, and queue the rest. The same logic handles billing exceptions where a payment does not tie out to an invoice.
Notice what every item shares: a document or record comes in, it gets checked against a known source of truth, and the exceptions go to a person. Limited discretion is required to capture a large share of the operational value.
The claims side follows the same shape
Claims looks more emotionally charged, but the early steps are still mostly intake and routing. Guidewire describes FNOL as the event where the insurer is informed of a potentially covered loss; in ClaimCenter, the claim is first created during FNOL as a draft and becomes open once enough information exists to enter adjudication. Many claim operations include steps such as FNOL and intake, assignment, evaluation, reserving and payment, settlement, closure, and, where applicable, recovery.
The deterministic wedge maps cleanly onto the front of that lifecycle:
- FNOL intake. Capture the loss details from a call transcript, email, or form, structure them, and create the draft claim. Reading and filling, not deciding.
- Assignment. Guidewire uses assignment rules to allocate claims to the right adjuster or queue. Routing is exactly the kind of rules work to automate first.
- Claims document triage. Police reports, photos, repair estimates, and medical records arrive in waves. Classifying and indexing them so the adjuster is not hunting through an inbox is pure document handling.
- Status communications. Claimants want to know what is happening. Drafting accurate status updates from the claim record, with a human approving anything sensitive, removes a constant interruption.
- Subrogation packaging. Assembling the evidence for a recovery file is collection and formatting work. Package it deterministically, let the recovery specialist decide whether to pursue.
Fraud flags belong here too, with a sharp caveat. A flag is a signal for human review, not a verdict. Use deterministic checks and pattern signals to raise a flag and route it. Never let the flag itself deny a claim. That line is where automation stops and human judgment, with full audit trail, begins.
Governance is the feature, not the paperwork
The part teams treat as overhead is the part that makes any of this defensible. In states that have adopted the NAIC Model Bulletin on the use of AI systems or similar guidance, insurers should expect governance, risk management, internal controls, documentation, validation, ongoing monitoring, and third-party oversight expectations for AI systems used in regulated insurance activity. Regulators are not asking only whether you use AI. They are asking whether you can show what it did and prove a human stayed accountable for outcomes that affect policyholders.
This is where the deterministic wedge quietly wins again. A system that extracts, routes, compares, and drafts produces a clean evidence trail by design. Every input is logged. Every automated step is recorded. Every human approval is timestamped. The voluntary NIST AI Risk Management Framework offers a practical structure, organized around Govern, Map, Measure, and Manage, that insurers can use to organize AI risk controls.
A few controls to build in from day one:
- Confidence thresholds. Below a set score, the item goes to a human. Tune the threshold against measured error, not vibes.
- Exception queues. Anything ambiguous lands in a queue a person actually works. The queue size is your early-warning metric.
- Deterministic validations. Check extracted data against known formats, policy records, and business rules before anything moves downstream.
- Immutable audit logs. Record inputs, model versions, automated actions, and approvals so an examiner or internal auditor can reconstruct any case.
- Human checkpoints on discretion. Pricing, coverage determinations, denials, and fraud conclusions stay with people.
Build these and the governance review becomes a walkthrough of evidence you already collect, not a scramble to reconstruct what happened.
How OpenNash Can Help
If you run an agency, an MGA, or a carrier operations team and the picture above sounds like your week, the path forward is narrower than the hype suggests.
OpenNash builds production AI systems for real workflows, not demo-only proofs of concept. For insurance operations, the engagement usually starts where the deterministic wedge does:
- Audit. Map the actual document flow across email, ACORD forms, downloads, and your management or policy admin system. Find the workflows where handling time is high and the inputs are structured.
- Design. Define the confidence thresholds, exception queues, validations, and human checkpoints before any code ships. Decide explicitly which steps stay with people.
- Build. Implement extraction, routing, comparison, reconciliation, and drafting against your real documents, with audit logging from the first commit.
- Deploy. Ship to production with full ownership handoff, documentation, and a control story that maps to applicable state guidance, NAIC-style expectations, and your internal audit needs.
The honest version of the advice: a configurable platform is the right answer for some teams, especially when your processes match a template closely. Custom build is the right answer when your document mix, carrier relationships, or compliance posture do not fit a template and you want to own the system outright. And if you have not yet measured where your handling time goes, the right move is to wait on both and instrument the process first.
If you want to map this deterministic-first approach to a specific workflow, book a call and we will start with the one process where reading, routing, and reconciling are eating your week.