
Ask an organisation about its data and you will be shown tables: customers, transactions, products, the tidy rows and columns of the warehouse. Ask where its knowledge lives, and the honest answer is somewhere else entirely: in contracts and policies, in ten years of support tickets, in meeting transcripts and engineering wikis, in the email threads where the real decisions happened. By most estimates the great majority of enterprise data, often cited at 80% or more, is this unstructured kind, and until recently it was strategically invisible. You could store it, search it badly, and that was about all.
Large language models changed the physics. For the first time, machines can read this material: summarise it, answer questions from it, extract structure out of it, and ground agent actions in it. Which means the largest, least-managed portion of your data estate just became usable, and almost nobody’s data strategy has caught up. Data strategies written even three years ago are strategies for the structured 20%.
This article is about the other 80%: why it suddenly matters, what “readiness” means when the data is documents rather than tables, and how to build an unstructured data strategy that does not collapse under its own ambition.
Why unstructured data moved to the centre
Three forces converged.
RAG made documents answerable. Retrieval-augmented generation, the pattern of fetching relevant passages and grounding a model’s answer in them, turned document piles into question-answering systems. Every “chat with our knowledge base” deployment, every policy assistant, every support copilot is RAG over unstructured data, and the quality ceiling of every one of them is set by the quality of the underlying documents. (My RAG track covers the machinery; this article covers the strategy.)
Agents made documents actionable. An agent processing an insurance claim reads the policy document, the claim description, and the assessor’s notes. An agent drafting a contract renewal reads the previous contract. When enterprises report that agents are “fast but blind” without grounded context, a large share of that missing context is unstructured. Structured tables tell an agent what happened; documents tell it what things mean and what the rules are.
Extraction made documents structured. The quieter revolution: models can now reliably pull structured fields out of unstructured sources. Invoices into line items, contracts into obligations and dates, support tickets into categorised issues. Every one of these turns previously dark data into analysable data, and some of the highest-ROI use cases in 2026 are exactly this unglamorous shape: an AI reading invoice details, comparing them against approved records, and routing only the mismatches to a human.
Put together: your contracts, tickets, transcripts, and manuals stopped being storage costs and became a competitive asset, one your rivals cannot buy, because it encodes your customers, your decisions, and your accumulated judgement. In a world where everyone rents the same models, proprietary knowledge in usable form is one of the few durable moats left.
The readiness problem, document edition
Here is the catch, and it will sound familiar: unstructured data has a readiness problem at least as severe as structured data, just with different failure modes. The six readiness dimensions from earlier in this track apply, but they wear different clothes when the data is documents. Figure 1 translates them.

Accessible becomes findable and extractable. Documents scattered across shared drives, SharePoint sites, email archives, and legacy systems, some scanned, some in dead formats. Before anything can be retrieved, it must be locatable and readable, which for older estates means OCR, format conversion, and connector work.
Accurate becomes current and authoritative. The single worst failure mode in enterprise RAG: the system retrieves a policy document that was superseded two years ago and answers from it, fluently. Documents do not carry expiry dates; humans just know which version is real. Machines need that knowledge made explicit: versioning, authoritative-source designation, retirement of the obsolete.
Complete becomes covered. Does the corpus actually contain the knowledge the use case needs, or does it live in heads and hallway conversations? A support assistant grounded on documentation that covers 60% of real issues will fail 40% of the time, confidently.
Fresh becomes synced. Corpus updated when source documents change, at a cadence matching the use case. A pricing assistant working from last quarter’s price book is a liability generator.
Permitted becomes permission-aware retrieval. The hard one. Documents carry access controls (this contract is confidential, that HR file is restricted), and your retrieval system must respect them at query time: the answer a user gets must be built only from documents that user could open. Home-grown RAG implementations fail here constantly, and the failure is a data breach with a conversational interface. Prompts and retrieved passages routinely carry personal and commercial information; ungoverned, they are exactly the flows the governance article warned about.
Understood becomes curated. Somebody, ideally the owning team, has designated what belongs in the corpus, tagged it usefully, and pruned the junk. Of the six translations in Figure 1, this is the one that decides most outcomes, which brings us to the strategy’s central discipline.
Curation beats volume, every time
The instinct, when leaders first grasp the opportunity, is to index everything: point the machinery at the whole document estate and let the model sort it out. I want to talk you out of this, firmly.
Indexing everything means indexing seven drafts of every final document, the abandoned proposals, the outdated policies, the contradictory guidance from two departments who never reconciled. Retrieval quality degrades with corpus noise; the model cannot reliably distinguish the authoritative document from its zombie predecessors, because nothing in the text marks the difference. Teams that go corpus-first spend months indexing and then wonder why answers are mediocre. Teams that go use-case-first, curating a few thousand authoritative documents for one workflow, ship something excellent in weeks.
So the strategy is the same value-led sequencing as everywhere else in this track: pick the use case, curate its corpus, ship, measure, expand. Figure 2 shows the operating loop, and the loop is the point: curation is continuous, owned work, not a one-off cleanup.

The maintenance arm of Figure 2 is where most programmes underinvest. A curated corpus decays exactly like a table pipeline: documents supersede, policies change, products launch. The fix is ownership, and the natural owners are the teams who own the documents: the policy team owns the policy corpus, support owns the knowledge base corpus. Their job description grows one line: keep your corpus authoritative, because an AI system now speaks from it. That single organisational move, treating each corpus as an owned product with a quality bar, separates the deployments that stay good from the ones that quietly rot. It is the same data-product logic the next article develops in full.
Picking the first use cases
Some patterns for where unstructured-data value concentrates, drawn from what is actually working in 2026 deployments.
High-volume question answering against stable documents. Policy assistants, product documentation, HR and IT self-service. Stable corpus, measurable deflection, contained risk. The classic first deployment, for good reason.
Extraction pipelines. Invoices, contracts, claims, forms: anywhere humans currently re-key or cross-check document contents. Measurable to the dollar, and often the fastest payback in the whole portfolio; finance and operations extraction agents are among the workhorse deployments of this cycle.
Institutional memory. Meeting transcripts and decision documents made searchable and summarisable: what did we decide about X, and why? Financial services firms are already running agentic workflows that capture meeting actions, draft the follow-ups, and track whether commitments landed. Underrated, and compounding: every meeting adds to the asset.
Agent grounding. As your agentic ambitions grow (the strategy for which gets its own article later), every agent needs its knowledge pack: the procedures, rules, and reference documents for its domain, curated and current. Building corpus discipline now is prework for the agent roadmap.
Score candidates exactly as the portfolio article prescribes: value against feasibility, where feasibility for unstructured use cases is dominated by corpus quality and permission complexity. A modest use case over a clean, well-permissioned corpus beats an ambitious one over chaos.
The strategic framing for your canvas
Return, finally, to the strategy canvas. Box 4, your data position, almost certainly describes tables. Extend it: for each priority use case, what unstructured sources does it need, who owns them, how current are they, and what are the permission constraints? For most organisations this adds two or three lines per use case and one uncomfortable discovery: nobody owns the documents.
That discovery is the perfect segue. The pattern underneath everything in this article, and the readiness and governance articles before it, is that data without an accountable owner decays, whether it lives in tables or documents. The next article tackles that question head-on: who owns the data, what data-product thinking actually means in practice, and how to assign accountability without redrawing your whole org chart.