The Hard Part of AI Data Extraction Starts After the Model

Getting an LLM to extract information from a document is not especially difficult. The harder part begins when that extraction has to work inside a real software system.

You can build an impressive demo of this surprisingly fast. But a demo that works on ten documents and a production system you can trust with thousands of them are two very different things. The model is rarely the hardest part.

Documents arrive in different formats. Terminology changes from one source to another. Some values are clear, others depend on context, and entirely new variations appear as soon as real users start working with the solution.

At the same time, the output has to fit an existing data model, pass validation, preserve traceability, and stop when the system is not confident enough to proceed.

That is where AI data extraction stops being a model problem and becomes an engineering problem.

Our team worked on exactly this kind of challenge. The goal itself was clear: turn heterogeneous source documents into structured data that could safely enter an existing system. What was not clear at the beginning was every rule required to get there. And that distinction shaped the entire development approach.

The real bottleneck was the specification

Software projects often start from a familiar assumption: define the requirements, write the specification, build the system, test it.

That works well when the rules are reasonably well understood.

It becomes much harder when the rules are discovered through the data itself.

A team may know, for example, that similar records should not be created twice. But the exact definition of “similar” may only become clear after reviewing real examples, edge cases, and user decisions.

Field mapping creates the same problem.

One concept can appear under several names. A familiar value may arrive in an unfamiliar format. Some transformations can be expressed as simple rules. Others depend on surrounding context. Some information is genuinely missing and should stay missing.

There is no realistic way to predict all those cases up front.

Trying to do so usually creates a large specification that still misses important exceptions.

Giving the LLM freedom to resolve everything is not a good alternative either. A model can make a plausible interpretation where the correct behavior should have been to stop and ask.

So the specification cannot be treated as something that is finished before the system is built.

It has to evolve with the system.

Turn the specification into part of the architecture

One of the most important design choices was to separate extraction from import without giving each side its own version of the rules.

Instead, the receiving component publishes the contract it accepts: required fields, valid structures, mappings, validation rules, and other constraints.

The extraction side reads that contract before producing its output.

That may sound like a small architectural decision, but it solves an important problem.

When an extractor and an importer maintain their own understanding of the schema, the two will eventually drift. A field changes in one place but not the other. A new rule is added. An exception is handled differently.

Over time, the extractor starts producing data the importer no longer expects.

A shared runtime contract reduces that risk.

More importantly, it changes the role of the specification.

It is no longer just documentation explaining how the software should behave. It becomes something the software actively uses.

The same principle applies to the development process.

Requirements, mappings, instructions, and decision rules need to be written in a form that both people and AI agents can work with.

If an important decision exists only in a meeting, a chat message, or someone’s memory, it is effectively invisible to an agent.

In AI-assisted engineering, written specification is not process overhead. It is working context.

Don’t use AI for problems that already have a rule

Another lesson from the project was simple: the model should not be asked to solve the same problem repeatedly once the answer is known.

LLMs are useful precisely because they can interpret variation.

But variation does not remain ambiguous forever.

Imagine that a particular field appears in many different forms across incoming documents. At first, the model may need to interpret those differences.

Once the team understands that those variations consistently map to a small set of accepted values, there is little value in asking the model to reason through them every time.

A deterministic rule is usually the better option.

The pipeline therefore followed a practical principle:

Use rules for what is known. Use AI for what still requires interpretation.

This is where I think teams sometimes overuse AI simply because AI is available. If the answer is already known and can be expressed as a reliable rule, asking a model to reason about it again is not intelligence. It is simply additional cost, latency, and uncertainty.

When a new edge case appears, AI can help resolve it. If the same pattern is likely to appear again, the resolution can then become a new mapping, alias, or validation rule.

Over time, more routine cases move out of the model layer and into deterministic processing.

That improves predictability, but it also affects cost. Model inference is reserved for cases where it contributes something useful rather than being applied indiscriminately to every field and every document.

Keep every extracted value connected to its source

Structured output is not enough.

If a system extracts a value, users also need a practical way to answer a basic question:

Where did this come from?

That is why the workflow used an intermediate representation between the original document and the final system.

Extracted values remained connected to their source. Missing, uncertain, or inferred information could then be surfaced for review before anything was imported.

This makes a significant difference to the user experience.

Without traceability, a reviewer may have to compare an entire AI-generated record against the original document.

With traceability, attention can be directed to the fields that actually need judgment.

Human review becomes exception handling rather than manual re-validation of everything the machine has already done.

The destination should have the final say

One of the easiest mistakes in AI integration is to assume that well-formed model output is valid system input.

Those are not the same thing.

An extraction process may produce an answer that looks perfectly reasonable but still violates a rule enforced by the destination system.

For that reason, validation happened at more than one point.

The first check occurred close to extraction, while the original source was still easy to inspect. The system could identify missing fields, incorrect formats, unexpected units, or other obvious problems early.

A second validation took place at the receiving boundary, which is an important distinction.

The model can propose an interpretation. The receiving system decides whether that interpretation is acceptable.

If the data does not satisfy the contract, processing stops.

The system does not try to make the result look valid by guessing.

This is a broader principle for production AI: uncertainty does not need to disappear. It needs to be handled deliberately.

Human-in-the-loop should not mean “review everything”

Human oversight is essential in many AI workflows, but it is easy to implement it badly.

If AI generates a result and a person then has to check every field manually, we have not really automated the process. We have just changed who does the first pass.

A better approach is to decide where human judgment is genuinely necessary.

Known cases can follow deterministic rules. Ambiguous inputs can be interpreted by the model. Situations with meaningful uncertainty or accountability requirements can be escalated to a person.

In this project, that meant designing the workflow to interrupt rather than improvise.

If a validation failed, processing could stop.

If there was uncertainty around an existing record, the system could surface the conflict rather than resolve it automatically.

If a user needed to confirm the source or accuracy of data, that confirmation became an explicit part of the workflow.

The human role was not to repeat the AI’s work. It was to make the decisions that should remain human decisions.

Real data became part of the requirements process

The delivery model had to reflect the fact that not every requirement existed on day one.

Instead of spending months trying to define every possible rule in advance, the team worked in short iterations around real examples.

A new document could expose an assumption.

That assumption became a question.

The answer became a written rule.

The rule became part of the implementation.

Then the next set of real examples tested it.

The cycle looked roughly like this:

example → ambiguity → decision → rule → implementation → validation

The important part is what happens after the decision.

If an edge case is discussed and resolved but never added to the system’s working specification, the same problem will eventually come back.

A useful AI workflow should accumulate operational knowledge.

As that knowledge grows, the system should become more structured, not more dependent on an ever-expanding set of prompts and manual interventions.

Faster implementation makes specification more important, not less

AI-assisted engineering can make implementation significantly faster.

That does not mean teams need less specification.

In many cases, it means the opposite.

When producing code becomes easier, unclear decisions become the new bottleneck.

This is one of the more interesting changes AI is bringing to software delivery. When implementation gets cheaper and faster, the value shifts upstream. The difficult work becomes deciding what the system should do, where its boundaries are, and what “correct” actually means.

• What is a valid result?
• What is the model allowed to infer?
• What should remain blank?
• When is a rule strong enough to replace model reasoning?
• What happens when two sources conflict?
• When should the workflow stop?
• Who makes the final decision when the system cannot?

These questions cannot be solved by choosing a better model.

They belong to the design of the system around the model.

For First Line Software, this case reinforced a broader approach to production AI: intelligence works best when it sits inside a clear operating structure.

Specifications should be usable by the system, not simply stored beside it. Deterministic logic should handle what is already understood. AI should focus on the variation that still needs interpretation. Every important output should remain traceable to evidence. Validation should protect system boundaries. And people should stay in control of the decisions where judgment and accountability matter.

The goal is not to maximize autonomy.

It is to build an AI-enabled system that knows what it can handle, what it can learn from, and when it should stop.

Production-ready AI is not AI that can do everything. It is AI that knows exactly where it is allowed to act—and what happens when it cannot.

September 2026