Every enterprise has data. Terabytes of it. Decades of it. But there's a vast gap between "we have data" and "our data can power AI." That gap is where most enterprise AI ambitions stall before they start.
The Problem We Keep Seeing
We've been having more AI conversations with enterprise leaders in the last two months than in the previous two years combined. And nearly every conversation hits the same wall:
"We'd love to use AI for [knowledge retrieval / document processing / decision support]. But our data is a mess."
They're usually right. But the mess isn't what they think it is.
Three Layers of Data Readiness
Layer 1: Can AI Access Your Data?
This is the most fundamental question and it's where most enterprises fail.
Your institutional knowledge lives in:
- SharePoint sites with inconsistent naming
- Email threads buried in individual inboxes
- Legacy systems with proprietary data formats
- PDF documents that are digitally stored but functionally inaccessible
- People's heads (the hardest database to query)
Before worrying about data quality, ask: can a system actually reach the data it needs?
John: The technical pattern here is straightforward even if the execution is hard. You need a data ingestion layer that can connect to your existing systems, extract content, and present it in a format that AI models can consume. For most enterprises, this means document processing pipelines, API integrations, and structured knowledge extraction.
The mistake I see: teams jump straight to selecting an AI model before solving the access problem. The model doesn't matter if it can't see the data.
Layer 2: Is Your Data Structured Enough?
Modern language models are remarkably tolerant of messy data. They can extract meaning from poorly formatted documents, inconsistent naming, and partial information. That's genuinely new - traditional analytics required pristine data.
But "tolerant of messy data" doesn't mean "performs well on any data." The quality of AI outputs is directly proportional to the quality of inputs. Garbage in, plausible garbage out.
What matters:
- Consistency - not perfection. If customer records use "Ltd" and "Limited" interchangeably, that's fine. If critical fields are missing 40% of the time, that's not.
- Currency - stale data produces stale answers. If your knowledge base hasn't been updated in two years, AI will give you two-year-old advice with today's confidence.
- Context - documents need enough metadata that the system can understand what they are, when they were created, and what domain they belong to.
47
average number of SaaS applications per enterprise department, each containing a slice of organisational knowledge
Source: Productiv, State of SaaS Spend Report, 2023
Layer 3: Is Your Data Governed?
John: This is where it gets serious. AI doesn't just read your data - it processes it, potentially stores it, and generates outputs derived from it. Your data governance framework needs to answer:
- Who owns this data? Not in the "it's in our system" sense. In the "who is accountable for its accuracy, access, and use" sense.
- What can AI do with it? Can it be sent to a third-party API? Stored in a vector database? Used to train a model? Each of these has different privacy, security, and compliance implications.
- What data should AI never touch? PII, health records, financial data, legally privileged information - your governance framework needs clear boundaries.
Most enterprises we talk to don't have answers to these questions yet. And that's OK at this stage - but you need the answers before you put anything into production.
What to Do Right Now
You don't need perfect data to start. You need enough data, accessible enough, governed enough, for one specific use case.
Step 1: Pick one use case. Not the most ambitious one. The one where the data is most accessible and the risk is lowest. Internal knowledge retrieval is usually a good start.
Step 2: Audit the data for that use case. What data does it need? Where does that data live? Can you access it programmatically? Is it current? Is it governed?
Step 3: Fix the access problem. Build or buy the connectors that let you extract and process the data you need. This is integration work, not AI work.
Step 4: Set governance boundaries. Define what data goes where, who approves it, and what happens when something goes wrong.
Step 5: Start small. Run a pilot with real data, real users, and real measurement. Let the pilot reveal the data gaps you didn't know existed.
The path to AI readiness isn't a massive data transformation programme. It's one use case at a time, each one revealing and fixing the next layer of data challenges.