What data you need before implementing AI
How to know whether your organization is data-ready, what minimums each type of project requires, and how to move forward without waiting for everything to be clean.
"First we need to sort out our data" is the sentence that postpones the most AI projects. Sometimes it's correct, and sometimes it's an elegant way of never starting.
The real answer depends on the type of project, because data requirements vary enormously from one case to another.
Three levels of demand
Low: working with text and documents. Assistants over internal documentation, extracting data from invoices, summaries, drafting, classifying enquiries. All you need is access to the documents and for them to be current. No history, no integration, no structure required.
This is where most of the profitable use cases live, which is why it's the right place to start.
Medium: process automation. Workflows that read from one system and write to another. What's needed here is technical access, ideally via API, defined permissions and consistent master data across systems.
High: predictive models. Demand forecasting, scoring, anomaly detection, predictive maintenance. These require sufficient history, adequate granularity and a stable definition of variables. At this level, data quality determines the outcome entirely.
A frequent mistake is assessing organizational readiness against high-level requirements, concluding you're not ready, and postponing the low-level cases that never had that problem.
The four-question check
For a specific use case, four questions are enough to judge feasibility:
- Where does the information live? Which system, what format, who owns it.
- Can it be accessed? Via API, scheduled export, or only manually. This constrains scope more than anything else.
- Is it current and trustworthy? If two systems say different things about the same customer, decide which one wins before automating.
- Are we allowed to use it? Personal data, customer information, contractual or regulatory restrictions.
If all four answers are reasonable, the case is viable. If one fails, it's usually cheaper to change use case than to fix the data problem.
The most frequent problems
Inconsistent identifiers. The same customer under three codes, the same product named differently in each system. This is problem number one and the biggest time sink.
Free-text fields where categories belong. A text field where everyone writes what they like makes aggregate analysis impossible. It's fixable, but you need to know beforehand.
Outdated documentation. For internal assistants this is the main risk: the system will confidently answer according to policies that no longer apply.
Undefined permissions. When an assistant accesses internal documentation, it inherits the question of who can see what. If that was never defined, the project will force the issue.
The strategy that works: clean by use case
Instead of a general data quality programme, pick a use case with clear value and clean only the sources that case needs.
That has three advantages. Scope is bounded and gets finished. The benefit is visible, which justifies continuing. And the order you create stays available for the next cases, which usually need the same sources.
After three or four projects run this way, the organization ends up with much of its data in order — but each step paid for itself.
What is worth doing from day one
Two things, both cheap:
- A simple source inventory: which systems exist, what each one holds, who's responsible. A spreadsheet is enough.
- An access policy for internal information: what's open inside the company, what's restricted, and who authorizes exceptions.
None of this requires technology. It requires half a dozen conversations and someone writing them down.
Frequently asked questions
Do we need a data warehouse before using AI?
Not for most cases. Projects based on documents, text or narrow processes work with direct access to the source. A central warehouse becomes necessary when you need cross-system analysis.
How much history is required?
It depends on the case. Forecasting and predictive models need two to three years. Assistants over documentation, search or text generation need no history at all — only that the documentation is current.
What do we do if our data is a mess?
Pick a use case that depends on few sources and clean only those. A general data clean-up project with no concrete use case behind it almost never finishes.