40% of an Underwriter’s Time Goes to Opening Emails and Hand-Keying Data

Tom Wilde has spent 25 years in content technology — internet search in the early 2000s, then enterprise search, enterprise video, and enterprise content management, with insurance as a recurring vertical throughout. He joined Indico Data five years before this recording specifically to take the founders’ deep technical breakthrough and build the business layer around it: product, go-to-market, pricing, everything required to get an enterprise to actually acquire and deploy it. It’s a pattern he’s built a career on — pairing with technical founders who’ve achieved a genuine breakthrough and helping shape it into a company.

Indico’s founding technical pedigree is genuinely notable: two of its founders contributed to the foundational research that eventually became GPT — specifically a paper called GPT (the original, written by Alec Radford, one of Indico’s founders). The company has been operating with large language models for roughly eight years, well before “GPT” became a household term.

In Episode 99 of InsurTechTalk, recorded ahead of ITC DIA Europe in Barcelona, Tom and I covered why insurance — an industry built on data — still struggles badly with unstructured data, how transfer learning changed what’s possible in document intake, and why he insists Indico is a data company, not a decision platform.

About Tom Wilde

Tom Wilde is CEO of Indico Data, an intelligent intake platform that converts unstructured data (scanned PDFs, email content, documents) into structured data usable by downstream decisioning systems. He joined Indico roughly five years before this recording after 25 years in content technology, building the commercial layer around the founders’ deep natural language processing and generative AI research — two of Indico’s founders contributed to the original GPT research paper. Indico partners closely with Microsoft on go-to-market and technology within the insurance vertical.

Why Data-Native Insurance Companies Still Have an Unstructured Data Problem

Tom’s opening framing addresses the obvious objection directly: insurance companies have been masters of data for centuries — his own parents were actuaries, and he half-jokes that actuaries were “the original data scientists,” building predictive models from vast datasets long before “data science” was a term.

The gap: insurers made huge investments in platforms built to consume structured data — core systems, predictive analytics workbenches — but a large share of the data they actually need to make decisions starts life unstructured: a scanned PDF, the body of an email, a document with no machine-readable metadata attached. Those platforms can’t consume that data directly, which is the actual bottleneck driving renewed interest in intake automation.

Structured vs. Unstructured, Defined Precisely

Tom’s cleanest definition: unstructured data is data that isn’t readily machine-readable — a scanned PDF starts life as an image, not text, and has to be converted before any system can process it. A secondary useful framing: structured data comes with metadata describing it (a spreadsheet’s row and column headers, for instance); unstructured data typically has none beyond a filename or creation date.

Why OCR Templates and Regular Expressions Were Always Going to Fail

This was the sharpest technical explanation in the conversation, and it explains why intake automation stayed hard for decades despite being an obviously important problem.

• OCR templating assumes information appears in the same location on every document — brittle, and workable only for highly standardized forms (an enrollment form, for instance), not the varied documents that make up a real commercial submission
• Regular expressions require exhaustively enumerating every possible format a piece of data might take — Tom’s example: teaching a machine every way a date might be written (year-month-day, day-month-year, two-digit versus four-digit year) is tedious and still breaks the moment an unanticipated format appears

Both tools failed for the same underlying reason: computers historically couldn’t understand context, only keywords. Humans understand language through context, not keyword matching — and modeling context mathematically at meaningful scale was computationally intractable until deep learning, GPU-scale computing, and eventually GPT-class models made it tractable.

From Thousands of Labeled Examples to Zero-Shot

Tom traced the evolution of what it actually takes to train a model to extract data from documents:

• A decade ago: extracting structured fields from something like a proof-of-prior-insurance document could require thousands of labeled training examples before a model learned to interpret it reliably
• Indico’s original innovation, transfer learning: bootstrap a large pre-trained language model with only a couple hundred labeled examples, effectively tricking the model into behaving as if it had seen thousands
• Today, with GPT-4-class models: the model may need no task-specific training at all — Tom’s example: simply telling the model which five key-value data points you want extracted, and specifying the JSON structure to return them in, is often sufficient. This is genuine zero-shot learning, a capability the machine learning field spent years chasing as a theoretical goal that’s now practically real

Prompting as the Newest Layer of Compiler Abstraction

We drew a direct parallel between prompt engineering and the decades-long trend of programming languages abstracting further from raw machine instructions — from assembly, through COBOL and Fortran, to Visual Basic and C#, to low-code tooling, and now to plain English as the interface. Tom’s framing: prompting is simply the newest and most abstracted layer of that same lineage — you’re still fundamentally instructing a machine to perform a task, just in a form that requires no specialized syntax at all.

What ChatGPT Actually Is, Mechanically

Tom offered a clarifying distinction that’s easy to lose in the general hype: GPT-3/GPT-4 are the underlying models; ChatGPT is a specific implementation trained and extensively curated by thousands of people specifically to handle question-and-answer interaction safely and effectively — including deliberately training it to resist generating illicit or harmful content. The conversational assistant experience most people associate with “AI” is a carefully shaped product layer sitting on top of the underlying model, not the model itself.

The Two Real Enterprise Adoption Problems: Hallucination and Explainability

Tom framed these as two sides of the same coin, both stemming directly from the generative nature of the technology.

• Hallucination — his concrete example: asking a model to identify the governing state of record for a document, and watching it confidently generate “California” even though California was never mentioned anywhere in the source text. Something in the model’s training biased it toward a plausible-sounding but fabricated answer
• Explainability — the ability to trace, after the fact, exactly why a model produced a specific output, back to the underlying training and source data. Tom noted this has been a core Indico capability and strength since early on, and is non-negotiable for any decision with real financial or personal consequence — lending, underwriting, and claims all qualify

His pointed framing on why “99% accurate” isn’t sufficient reassurance in this context: even a 1% error rate, applied at scale across thousands of policyholders, means real people end up in the wrong outcome — and without explainability, a carrier can’t identify, audit, or correct which cases were affected or why.

Indico Is a Data Company, Not a Decision Platform

This distinction is central to how Indico positions itself, and it’s a genuinely useful frame for evaluating any AI vendor in this space. Tom was explicit: Indico is not a decisioning platform — it doesn’t compete with predictive analytics tools, core systems, or underwriting/claims workbenches, all of which take structured input and apply logic to produce a decision (quote or don’t quote, at what price). Indico’s role is producing the clean, structured, validated data those decision platforms actually need to function — without which even the most sophisticated decisioning logic has nothing reliable to work with. Cost matters here too: Indico lets carriers train models using GPT-4-class capability but deploy compressed, cost-effective versions inside their own infrastructure, both for data protection and to avoid per-call costs at production scale.

A Concrete Underwriting Use Case

Tom walked through commercial lines underwriting end to end as the clearest illustration of the actual workflow:

• A broker submission arrives, often as a single scanned PDF bundling multiple distinct documents an underwriter needs to separately identify and process
• Deloitte research cited by Tom found underwriters spend up to 40% of their time on manual, low-value tasks — opening emails, printing documents, hand-keying data into a workbench
• That manual handling also breaks the chain of custody for auditability — once a human interprets a document and decides what to key into a system, verifying that decision later requires asking that specific person why they made that judgment call, rather than tracing it through an automated, logged process
• The actual intake workflow: unbundle the documents, classify what’s present (and flag what’s missing), extract potentially hundreds of individual data points (especially in complex commercial lines like marine, aviation, or travel), validate that data against third-party or internal systems (has this broker submitted before, has this risk been quoted previously), and transform it into the format the carrier’s core decisioning system requires

The endpoint of that pipeline — a quote or a decline — is only as good as the structured data feeding it, which is exactly the layer Indico occupies.

Key Takeaways

• Insurance’s unstructured data problem isn’t a lack of data sophistication — it’s that huge volumes of decision-relevant data (scanned PDFs, email bodies) were never machine-readable in the first place, bypassing the structured-data platforms carriers already invested heavily in
• OCR templating and regular expressions failed at scale because both require anticipating rigid, predictable formats — genuine progress required models that understand context, not just keywords
• Zero-shot extraction (no task-specific training required) is now practically achievable with GPT-4-class models, a dramatic shift from needing thousands of labeled examples a decade ago
• Hallucination and explainability are two sides of the same generative-AI risk — a model confidently fabricating a plausible but false answer is only manageable if you can trace exactly why it produced that answer
• “99% accurate” is an insufficient standard for high-stakes decisions at scale — the remaining 1% still represents real people affected, and requires auditability to identify and correct
• A useful vendor evaluation lens: is this company providing the clean data decision systems need, or is it itself a decisioning platform? Conflating the two categories can lead to over-trusting a tool for a job it wasn’t built to do
• Up to 40% of underwriter time historically went to manual document handling that also breaks chain-of-custody auditability — automating intake isn’t just an efficiency gain, it’s a governance improvement