The Model Is Only 20% of the Solution: Why Generative AI and IDP Now Depend on Each Other

New use cases, old discipline: what changes and what doesn't when generative AI meets document processing. A deeper technical dive for teams who build and govern production AI: the three use cases generative AI is layering on top of Intelligent Document Processing (IDP), and the lineage, grounding and benchmarking discipline they depend on.

If you have spent any time actually building production AI rather than watching demos of it, you already know an uncomfortable truth: the model is maybe 20 percent of the solution. The other 80 percent is everything around it. The workflow that gets the right information to the model. The governance that makes its output defensible. And, underneath all of that, the data.

This is not a new observation, but generative AI has made it impossible to ignore. MIT’s research found that 95% of organisations report little to no return on their AI investments, while global spend on generative AI sits somewhere between $30 and $40 billion¹. The models are not the constraint. Boston Consulting Group puts the number of AI initiatives that move beyond proof of concept at just 26%², and S&P Global reports that 42% of companies have already abandoned the majority of their AI projects³. Something other than model quality is breaking these programmes, and it is breaking them at scale.

The uncomfortable answer is data, and specifically documents. Between 80 and 90% of enterprise information is unstructured⁴, living in contracts, reports, invoices, emails, forms and scans rather than tidy database rows. Less than 1% of it is currently used in generative AI initiatives⁵. Generative AI has not created this problem. It has simply made it visible, because for the first time, the quality of your data foundation shows up directly in the quality (and the ROI) of your AI outcomes.

That puts documents, and by extension Intelligent Document Processing (IDP), right back at the centre of the AI conversation. Not as a legacy capability that predates the interesting AI work, but as the thing that determines whether the interesting AI work actually functions.

How IDP has always run – until now

My colleague Jonathan Darbey has made the business case that IDP has always really been about transaction automation: invoices, claims, loan applications and onboarding forms, each one following the same nine-step workflow of ingest, classify, extract, validate, reconcile, comply, approve, post and archive. Accounts Payable became the IDP poster child not because invoices are special, but because that entire lifecycle could be modelled end to end, reconciled against an ERP, and closed out to provide high levels of straight through processing with minimal levels of human intervention required .

The business case is not going anywhere, and it should not. It is the proven, auditable backbone that most enterprises already depend on, and as Jonathan argues for that audience in the extraction trap, extraction itself has become a commodity. Off-the-shelf engines from Tungsten Automation, AWS, Microsoft and Google, plus a generative model with a well-written prompt, will pull fields out of a document in minutes rather than months. What generative AI has not commoditised is everything after extraction: validation, reconciliation, compliance checks, approvals and governance. That is still where the real automation value sits, and it is still where most build-your-own projects quietly stall.

What has changed is that generative AI has opened up use cases that sit alongside, rather than inside, that transactional workflow. These are not replacements for transaction IDP. They are new uses for the same document estate, and they need the same discipline applied to them.

Three new use cases generative AI is layering on top of IDP

01

Documents to data: feeding the data lake without feeding the fragmentation problem

The first new use case is using IDP to turn documents into structured, governed records that feed a data lake, warehouse or lakehouse, rather than a specific downstream transaction system. Instead of "extract this invoice so we can pay it", the goal becomes "extract and standardise every contract clause, policy term or case note so analytics and AI can query it later".

This sounds like a small shift, but it introduces a requirement that transaction IDP has always had and that data lake projects often skip: lineage. If a model or an analyst later asks "why does this figure say what it says", you need to trace it back to the source document, the extraction run, and the validation that approved it. Without that audit trail, you have simply moved the trust problem from the document to the lake.

It also guards against a genuine challenge I am seeing take hold: every team loading its own documents into its own store, using its own prompts to interpret them, with no shared standards for how a contract clause or a customer field gets defined. You end up with several versions of "the truth" that all look plausible and do not agree with each other, using subtly different data definitions, creating an oranges-to-apples problem at enterprise scale. Add regulatory and audit requirements into the mix, and ungoverned document-to-data pipelines become a liability rather than an asset. The fix is not fewer data lakes. It is making sure every pipeline that populates them runs through the same quality controls, classification standards and lineage tracking, however many teams are doing the loading.

02

AI-powered document extraction and enrichment

The second use case is the natural evolution of IDP itself, moving from what most people still think of as document processing (capture, classify, extract) to genuine document intelligence (transform, understand, orchestrate). This is where generative AI adds real capability rather than just faster extraction: interpreting handwritten case notes, reconciling inconsistent formats across regions and languages, and enriching a raw extraction with the business context needed to act on it, not just read it.

This is the layer where tools like DocAI Studio (part of TotalAgility) apply generative and deterministic AI together, deliberately, rather than reaching for the largest model available for every task. Classification, extraction and validation still favour precise, deterministic techniques because they need to be repeatable and auditable. Generative AI earns its place where genuine interpretation or contextual reasoning is required, for instance turning a free-text adjuster's note into a structured claim update. Applying generative AI indiscriminately across every step is not just architecturally sloppy, it is also the most expensive way to get a worse answer, so this use case is as much about knowing where not to apply an LLM as where to apply one.

03

Knowledge bases: one source of truth, not one RAG per app

The third use case, or rather AI anti-pattern, is the one I think gets the least attention and causes the most damage: every application, team or citizen developer building its own Retrieval Augmented Generation (RAG) pipeline against its own copy of "the knowledge", with its own chunking strategy, its own permissions model, and its own idea of which document version is current.

I have written before about how AI fragmentation creates exactly this risk. It is the RAG equivalent of "garbage in, garbage out": the quality of a retrieval-augmented answer is a direct function of the quality and governance of the content it retrieves from, along with the capability and configuration of the retrieval engine used. Not only are money and effort wasted as each team hand rolls their own RAG knowledge store, but the inability to compare the results from one system with another is baked into the design. While each system returns coherent sounding responses, results from different agentic systems become impossible to mesh, rapidly eroding trust in the company’s AI initiatives. This is one of the reasons why, and right now, Gartner expects 60% of AI projects to be abandoned due to a lack of AI-ready data. When ten different AI assistants across the business are each grounded in a slightly different, ungoverned slice of company knowledge, you get ten different answers to what should be the same question, and no way to explain why.

Related webinars

Webinar

KI-Pilotprojekte sind einfach. Präzise KI im großen Maßstab ist äußerst anspruchsvoll.

See why promising AI pilots create AI debt when the data, governance and operational foundation cannot scale.

Watch webinar →

Webinar

Your AI model is only 20% of the solution. What about the other 80%?

Explore the workflow, governance and trusted data foundation needed to turn production AI into reliable outcomes.

Watch webinar →

The answer is not to ban RAG or force everyone onto one chat interface. It is to generalise, govern and manage the knowledge base itself: one continuously updated, permissioned, versioned source of curated, well-defined and accurate content, with citations and quality checks built in, that any number of models and agents can be orchestrated against. Having multiple knowledge bases is not inherently the problem, but feeding the same types or classes of content into different knowledge bases, using different approaches, is.

This is where each department needs to become the custodian of the process that updates their content and data in a Knowledge Bases, to ensure when it is accessed by an agent it is the golden source of the truth, not a stale copy. The teams closest to the data should also deliver agent ready data dictionaries that describe how the data is sourced, and how it should be used and interpreted. Standardise the source and let the tool choice vary.

What this unlocks: knowledge worker support, not just transaction automation

Get these three use cases right and you unlock something genuinely new: AI that supports the knowledge worker, not just the transaction. In Realising Generative AI Productivity Gains, I described a retrieval agent helping bank analysts pull hedging and derivatives detail out of hundreds of pages of annual reports, work that used to be manual, cross-referenced research. That only works because the underlying documents had already been made available as trustworthy, governed, AI-ready data, exactly the kind of foundation the first two use cases above are built to produce.

This is a technical complement to Jonathan's business-facing transaction view of IDP, not a contradiction of it. His blog builds the case; here we look at what’s underneath it. Transaction IDP answers "how do I complete this case correctly." These new use cases answer a different question that is just as valuable: "what does the business already know, and how do I put that knowledge safely in front of a person or an agent who needs it right now." Both depend on the same discipline of turning unstructured content into something a system, or a person, can actually trust.

The thread that runs through all of it: lineage, grounding, and benchmarking

Across all three use cases, the same three requirements keep reappearing, and none of them are optional extras.

Get these three right, and you are not just making extraction more accurate. You are making the model itself more useful, because you are finally giving it fuel that matches its capability.

Fuel, not magic

None of this is really about generative AI replacing IDP, or IDP becoming irrelevant now that models can read documents unaided. It is closer to the opposite. Generative AI has widened what IDP needs to do, adding document-to-data pipelines, highly accurate business data extraction from content, data enrichment, and governed knowledge bases to the existing, proven work of transaction automation.

At the same time, IDP feeds agents and, without it, they’re missing something fundamental. Generative AI agents need governed, lineaged, grounded content to work reliably. This is what IDP can deliver - standardised extraction of tightly defined business data and entities, quality controls, audit trails. Without this,– your AI agents, risk becoming expensive hallucination machines. The organisations pulling ahead are not the ones with the most advanced models. They are the ones treating their documents as a strategic asset rather than a by-product, with the lineage, grounding and governance data to prove it.

Continue exploring

E-Guide

KI ist nur so gut wie Ihre Daten. Sind Ihre bereit?

Our practical guide to building the data foundation your AI actually needs.

Bericht

AI with no ROI? You're not alone

The document problem at the root of AI failures, and where to start closing the gap.

Häufig gestellte Fragen

Why do generative AI initiatives depend on Intelligent Document Processing?

Generative AI depends on trustworthy, governed and AI-ready information. IDP provides structured extraction, validation, quality controls, lineage and auditability for the unstructured documents that contain much of an enterprise’s information.

What new GenAI use cases are being layered on top of IDP?

The article identifies three: document-to-data pipelines that feed governed data platforms, AI-powered extraction and enrichment, and governed knowledge bases that can support multiple models and agents.

Why are lineage, grounding and benchmarking important for production AI?

They make AI outputs traceable, tied to current approved enterprise content, and continuously measurable against known-good answers, which is essential for trust, governance and production reliability.

Glossary