Why the Data, Not the Model, Is the Bottleneck
The model is, increasingly, a bought commodity. You call an API or run an open model on your own hardware; either way the intelligence is off the shelf and getting better without any effort from you. What is not off the shelf is your data — its shape, its state, and whether the system can find the right piece when it needs it. Every serious AI project I have delivered has spent more effort getting data into a usable state than on anything model-related, and it is not close.
When a project runs late or disappoints, it is almost never because the model “wasn’t smart enough.” It is because the model was asked to answer from data that was incomplete, contradictory, out of date, or simply unreachable. “Garbage in, garbage out” is an old rule, but an LLM makes it worse, not better: a language model given bad data does not fail loudly, it fails fluently. The wrong answer arrives confident, well-written, and plausible — which is far more dangerous than an error message.
Where Your Company Data Actually Lives
Ask a mid-sized company “do you have the data for this?” and the honest answer is usually “yes — somewhere.” The problem is the somewhere. In a typical Mittelstand business, the knowledge an AI would need is spread across an ERP (SAP, or some niche industry system) holding orders and master data; thousands of PDFs — quotes, spec sheets, certificates, scanned contracts — on a shared drive nobody has tidied since 2015; a mailbox where half the institutional knowledge lives as email threads; a ticketing or CRM system full of support history; a Confluence or SharePoint wiki that is 40% out of date; and a handful of Excel files that are secretly the real system of record.
None of these were built to be read by a machine. They were built for people who already know the context — who know that “the old spec” means the 2018 revision and that the price in this sheet is net, not gross. The scattering is the real problem, not the volume. The data almost always exists. It is the fact that it lives in six systems, in six formats, behind six access models, with no shared vocabulary, that makes it hard. An AI project is, in practice, very often a data-integration project wearing a more exciting hat.
A concrete example: a machine builder wants an assistant that answers “which spare part fits this older machine?” The answer genuinely exists — spread across decade-old PDF parts catalogues, the article master in the ERP, and the heads of two long-serving service technicians. Getting to a reliable answer is maybe 80% assembling and reconciling those three sources and 20% the AI layer on top. The AI is the easy 20% — and those two technicians will retire eventually, which is reason enough to make their knowledge tangible now.
Getting Your Data Ready, Step by Step
None of this requires magic. It requires an ordered, unglamorous sequence — inventory, clean, structure, permission, keep fresh — done only to the depth the use case actually needs. The figure below is the shape of it: raw, scattered sources on the left, a system that can retrieve a trustworthy answer on the right, and the honest work in between.
Inventory and access — find it before you clean it
Before you clean a single file, list what exists and who can reach it. Which systems hold relevant data, in what format, how much of it, how fresh it is, and — the question that sinks the most timelines — can we technically get to it? An export, an API, a database read? Access is where projects quietly stall for weeks: the data exists, but it sits behind a vendor who charges for an export, or a legacy system with no API, or an IT approval that takes a month. Surface that early, while it is a scheduling problem and not a crisis. A blunt one-page inventory — “roughly 12,000 PDFs on the shared drive, a weekly SAP export we can get, a CRM with an API, one Excel file that matters” — is worth more than any grand data strategy.
Clean, deduplicate, and structure for retrieval
Then you clean — but only as much as the use case actually needs. Remove exact and near-duplicates (the same policy in four versions, three of them obsolete), drop boilerplate, repair the broken PDF text extractions, strip the navigation cruft. For anything going into a retrieval system, structure matters more than polish: documents are split into chunks the right size to retrieve — small enough to be specific, large enough to keep their meaning. A 90-page manual chunked naively becomes 90 pages of context-free fragments; chunked along its real structure, section by section with headings kept, it becomes answerable. This is the step most people underestimate, and the one that most directly decides whether retrieval returns the right passage or a plausible-looking wrong one.
Metadata, permissions, and keeping it fresh
Three things finish the job. Metadata: tag each chunk with where it came from, how current it is, and which product, site, or department it belongs to — so the system can filter, cite its source, and prefer the 2026 document over the 2019 one. Permissions: the system has to respect who is allowed to see what. If sales can see margins and the shop floor cannot, that boundary has to live in the data layer, not be bolted on later — the quickest way to kill an internal AI project is to have it cheerfully surface a salary list to the wrong person. And freshness: data is not a one-time load. Prices change, documents get superseded, new tickets arrive. A pipeline that ingests once and never again is a system that is quietly wrong a little more every week. Decide up front how it stays current — nightly sync, on-change, weekly — because “we’ll figure out updates later” is how a good demo rots into a liability.
What “Good Enough” Looks Like — and Where Tippel Fits
Good enough is not perfect, and chasing perfect is its own failure mode. You do not need every document, every field filled in, or a single golden source of truth. You need the data that covers the questions this use case will actually get, in a state the retrieval layer can work with, kept current enough to trust. Coverage beats completeness: it is perfectly fine to launch answering 80% of questions well and honestly saying “I don’t have that” for the rest — far better than a system that guesses to fill the gaps. That “I don’t have that” is a feature, and it depends entirely on data quality, because a system with no way to know what it doesn’t know will confidently invent an answer over every hole.
This is why data work and retrieval quality are the same conversation. In a RAG pipeline, the model can only be as good as what retrieval hands it, and retrieval can only be as good as the data underneath. It is also why data readiness is the single biggest swing factor in what an AI project costs and how long it takes: a clean, reachable source can mean a few weeks; a scattered, access-locked one can mean months. The data is not a line item you deal with at the end — it is the thing that sets the whole budget.
Which is exactly why I look at it first. The data question is the least glamorous part of an AI project and the part most likely to sink it, so it is where I spend the first, hard, honest look. The AI Readiness Check exists partly to answer it before anyone commits a build budget: what data you have, what state it is really in, what it would take to get it to “good enough” for the use case you have in mind — and whether that is weeks or months, not a vague “it depends.” If you would rather talk it through first, get in touch.