Data readiness for AI is a question about one process, not your whole company. Your data probably isn't ready, and it doesn't need to be. A first AI project needs one process with a single source of truth for each field it uses, the required fields filled in, real past cases to test against, access scoped to the job and an owner who fixes bad records. That's weeks of work, not a two-year programme.
Is our data ready for AI?
Ask a leadership team and you'll get a confident yes or a nervous no. Both answers are usually wrong, because the question is too big to answer.
The surveys show the confusion. In a study of 505 data leaders at large companies, 87% said their data was AI-ready and 43% named data readiness as the biggest barrier to getting AI to deliver what the business needed (Drexel LeBow and Precisely, January 2026). Same people, same survey.
Both can be true, because no company's data is ready or unready as a whole. Some of it is fine for the job in front of you. Most of it has nothing to do with that job. Gartner, which predicts organisations will abandon 60% of AI projects that aren't supported by AI-ready data, defines readiness the same way: the data has to represent the specific use case, errors and outliers included.
The nervous no does more damage than the confident yes. It turns into a data programme: a new warehouse, a master data project, a governance framework, a catalogue. Each piece is sensible. Together they're scoped in years, and the AI work queues behind them. By the time the data is declared ready, the sponsor has moved on and the use case has changed.
You don't need perfect data for AI. You need one process you can trust.
What data does an AI agent actually need?
Five things, checked for one process at a time. We call it Intersect's Minimum Viable Data standard, and it's the bar a process has to clear before we build an agent on it.
Take an agent that chases overdue invoices. It reads the aged debtors list from the accounting system, finds the right contact in the CRM, sends a reminder pitched to how late the payment is, logs what it sent and hands disputes to a person. Here's what its data needs, and what failing looks like.
Every check is measured against this process, these fields and last quarter's records. None of them asks how good your data is in general. The 95% bar is our rule of thumb, not an industry standard: below it, the agent spends more time escalating gaps than doing the work.
What's not on the list
Plenty of things a data programme would start with. A first agent needs none of them:
- A data warehouse or lake. Most first agents read straight from the systems the process already runs in, through their APIs.
- A company-wide data model. You need agreement on about a dozen fields.
- A data catalogue. Useful at scale, overkill for one process with four or five sources.
- Years of clean history. An agent that chases invoices needs last quarter's records. 2019 can wait.
- Clean data in systems the process doesn't touch. The marketing database can stay a mess for now.
All of those can be worth building later. They're the second step, not the entry fee.
Why does access matter more for AI agents?
Because agents act. A chatbot that can read too much can say the wrong thing. An agent that can write to too much can do the wrong thing, at volume, before anyone notices.
It happens more than the demos suggest. In a 2025 survey of 353 enterprise IT and security professionals, 80% said their AI agents had taken unintended actions and 39% had seen agents reach systems they weren't meant to (SailPoint and Dimensional Research, May 2025; vendor research). Only 44% had policies in place to secure them.
The fix is dull and it works. Give each agent its own account, never a person's login. Grant read access to the fields on the required list and nothing else. Let it write to one place, and log every read and write. If you can't describe an agent's access in two sentences, it has too much.
How long does data cleanup take for an AI project?
For one process, usually two to six weeks in our experience. For the whole company, it doesn't finish. The work has the same shape every time:
- Map it. An afternoon with the person who runs the process, real records on screen. List every field the work uses and where each one lives.
- Fix the gaps. Fill or correct the required fields on recent records, merge the duplicates, and write down the source-of-truth rule for each field.
- Stop new bad data. Make the fields mandatory where they're entered, swap free text for dropdowns, and send errors to the owner.
- Set up the test and the access. Pull the past cases with their outcomes, and create the agent's own account with narrow permissions.
Step three is the one teams skip. Cleaning a backlog once is a few days of tedious work. If new records keep arriving broken, you're cleaning it again in March, and the agent is working from the mess in between.
Shouldn't we fix all our data first?
No. Fix what the first process needs, then what the second needs. The fixes compound, and each one is aimed at a real job.
You can't define good data without a job for it. Clean customer data for an invoice-chasing agent means a correct billing contact. For a sales agent it means the decision-maker and the last conversation with them. A programme that tries to serve every future use ends up perfecting fields nobody reads.
Waiting for full readiness also means waiting with almost everyone else. In Cloudera's survey of 1,270 IT leaders at large companies, only 18% said their data was fully governed (Cloudera, April 2026; vendor research). In Informatica's survey of 600 data leaders, 57% called data reliability a key barrier to moving AI from pilot to production (Informatica, January 2026; vendor research).
In our view, the companies getting agents into production aren't the ones with perfect data estates. They made one process trustworthy and shipped. The second process is cheaper than the first, because customer IDs, contacts and the agent's account set-up get reused. By the fourth, you know which shared foundations are worth building, because you've hit them four times.
Where the one-process rule breaks
It's the right way to start. It isn't the whole answer, and it falls short in four places.
- Forecasting and analytics. A demand forecast needs years of consistent history across products and regions. One clean process gets you a pilot. It won't give you a model you'd bet inventory on.
- Regulated decisions. Credit, claims and clinical work need lineage you can show a regulator: where each field came from and who changed it. That's a bigger build than five checks.
- Processes with no data at all. If the source of truth is someone's memory or a WhatsApp thread, there's nothing to clean. Capturing the data comes first, and that's a change to how people work.
- The fifth process. Once several agents need the same data, point fixes start costing more than a shared foundation. That's when a data platform earns its budget, designed around what the first processes taught you.
What to do next
Pick the process you'd most like an agent to take on. Book an hour with the person who runs it and go through the five checks with real records on screen, not from memory. If it passes four or five, scope a pilot. If it fails two or more, you've found your first data project, and it's measured in weeks. Our Data Foundations team runs exactly this, and our Development Studio builds the agent once the data passes.
Find the process that's ready now
Bring us the process you want to hand to an agent. We'll run the five checks with your team on real records and tell you what it would take to get it ready, and how long. Book a call
FAQs
Do we need a data warehouse before we use AI?
No. Most first agents read directly from the systems the process runs in, through their APIs. A warehouse earns its place when you're analysing across systems or running several agents on the same data. Build it when the third or fourth process needs it, not before the first.
Can AI clean our data for us?
Partly. Models are good at spotting duplicates, standardising addresses and pulling fields out of PDFs and emails. They can't decide which system is the source of truth or who owns a field. Those are business decisions, and an agent fixing data nobody owns will quietly make it worse.
What if our data lives in spreadsheets and email?
That's common and workable. An agent can read a well-kept spreadsheet as easily as a database. The checks still apply: one sheet is the master, the columns are filled in, and someone owns it. Five versions of the same spreadsheet in five inboxes won't pass.