Key Takeaways
- "Our data is not ready" is usually a context problem, not a storage problem. The numbers exist. What is missing is the meaning around them: which spreadsheet is current, what a status actually means, who decides.
- The research says the same thing. In a Wakefield Research study of 1,000 technology leaders published by Teradata on July 7, 2026, 77% said 20% or less of their enterprise data and knowledge is ready for AI agents to use reliably, and 78% struggle to unify data and knowledge across business functions.
- Do not start with a data project. A warehouse rebuild takes quarters. Pick one recurring job, connect only the systems that job touches, and write down the rules that live in someone's head.
- Write the context down once, reuse it forever. The three things an AI employee needs are the source of truth, the definitions, and the exceptions. That is a page of text, not a migration.
- Judge readiness per job, not per company. Your invoice data can be ready on Monday while your product analytics stays a mess for another year. Both can be true.
An operations lead told me her company had "put AI on hold until the data is ready." I asked what that meant in practice. It meant a data warehouse project scheduled to finish in the second quarter of next year.
Then I asked how she builds the monthly revenue report today. She pulls a CSV from the billing system, opens a spreadsheet a colleague maintains, checks two numbers with the account manager over chat because a few deals are always coded oddly, and formats the whole thing by hand. Four hours, every month, without a warehouse.
So the data is ready enough for a human to do the job. The question is what makes it ready enough for an AI employee, and that answer is much smaller than a warehouse.
Why does everyone say their data is not AI-ready?
Because the phrase covers two very different problems and teams keep solving the expensive one.
The first problem is access. The information sits in systems nobody has connected: a CRM, a billing tool, a shared drive, a channel where the actual decisions get made. That one is real and it is solvable in an afternoon per system.
The second problem is meaning. There are four spreadsheets called "pipeline" and only one is current. "Closed" means signed to sales and paid to finance. An approval rule for off-list terms exists but lives in one person's memory. No amount of infrastructure fixes that, which is exactly why infrastructure projects keep failing to unblock the work.
The Teradata study puts hard numbers on the split. Beyond the 77% who say almost none of their data is agent-ready, 43% cite missing metadata, context, and relationships as a top barrier, and 42% cite data fragmented across systems that cannot be connected in real time (Teradata, July 7, 2026). Missing meaning ranks alongside missing pipes.
| What people mean by "not ready" | The real fix | How long |
|---|---|---|
| The tools are not connected | OAuth the two or three tools one job touches | An afternoon |
| Nobody agrees which file is current | Name the source of truth in writing | Ten minutes |
| The rules live in someone's head | Write definitions and exceptions on one page | Half an hour |
| The numbers themselves are wrong | Parallel run for two cycles, fix what differs | Two cycles |
| No structured warehouse exists | Usually not needed for operational jobs | Skip it for now |
What does an AI employee actually need to do a job?
Three things, and none of them require a migration.
A system it can reach. Not a perfect system. A connected one. Viktor connects to 3,200+ tools through OAuth, so the CRM, the billing tool, the drive, and the ticket queue become readable the same afternoon you decide to try.
The definitions you already carry around. Which report is the source of truth. What a status means. Which customers are excluded from the count and why. You explain this to every new hire in their first week and then never write it down.
The exceptions. Every real process has them. Two clients get billed on a different schedule. One region reports a week late. The rule that matters is what to do when reality does not match the template: flag it, guess it, or stop and ask.
Give an AI employee those three and it works with data that is objectively messy, because that is what your team already does.
How do you get from messy to working in one week?
Pick one job. Not a strategy, one job that repeats.
- Choose one recurring job that a person handles manually today. Invoice chasing, ad spend reporting, a pipeline hygiene pass. If nobody does it manually today, it is the wrong place to start.
- List only the systems that job touches. Usually two or three. Ignore everything else in the company, permanently.
- Connect them and set the access boundary at the same time. Our guide on access scoping for an AI employee covers that decision, and it is easier to make now than after twelve people have opinions.
- Write the context page. Source of truth, definitions, exceptions, output format, and the things that are never allowed. Half a page is normal.
- Run it in parallel for two cycles. The AI employee produces the report, the human who used to produce it compares. Differences are not failures, they are the missing definitions surfacing.
- Turn it into a named skill. Once two cycles match, turn the recurring task into a shared skill so anyone can run it by name and get the same result.
The parallel run is the step people skip and the one that does the actual work. It converts vague worry about data quality into a specific list of five things to write down.
What a context page looks like
Short, plain, and specific to one job. Something like this, dropped straight into the conversation:
@Viktor here is the context for the monthly revenue report.
Source of truth for amounts is the billing system, not the CRM.
"Closed" means the invoice is issued, not the deal marked won.
Exclude internal test accounts and the two pilot accounts in the reseller region.
Two clients bill on a quarterly schedule, list them separately instead of averaging.
If a record does not match those rules, flag it in an exceptions table rather than guessing.
Output is a spreadsheet plus a five line summary in this channel.That is the whole artifact. It took the ops lead above eleven minutes to write, and it replaced the part of the warehouse project she actually needed.
Where does the channel history fit?
This is the piece most data-readiness plans miss entirely. A large share of your operating context is not in any system of record. It is in conversations: the reason that campaign was paused, the exception made last quarter, the number someone quoted a customer.
An AI employee that lives where the team talks reads that history as context rather than needing it re-entered into a tool. It is also why the rollout question is less "is our warehouse ready" and more "does the thing doing the work sit where the decisions happen." Where do you actually talk to your AI employee goes deeper on that choice.
When is the data genuinely not ready?
Sometimes the honest answer is wait, and pretending otherwise burns trust. Hold off when:
- The source of truth is disputed. If finance and sales cannot agree which number is correct, no AI employee will settle that argument for you. Settle it first, in a meeting, with humans.
- The system is not accessible at all. An on-premise tool with no API and no export is a real wall. Fix the export or pick a different job.
- The job needs data nobody records. If the input only exists in someone's judgment and was never written anywhere, there is nothing to read.
- Regulation limits what may be processed and nobody has checked. Ask before, not after. Viktor is SOC 2 Type I certified, and your compliance owner still needs to sign off on which systems are in scope.
Everything else on the "not ready" list is usually a context page waiting to be written.
How does this change the way you judge readiness?
Stop asking whether the company is AI-ready. Ask whether one job is.
Readiness is per job. Your invoicing data can be clean enough on Monday while product analytics stays a mess for another year, and the invoicing job should not wait for it. Teams that sequence this way get value out of the first month instead of the fourth quarter, and each finished job makes the next one easier because the definitions accumulate.
If you want a broader pre-rollout pass, the AI coworker readiness checklist covers the operational side, and why AI agents stall after the pilot covers what happens after the first success.
Frequently Asked Questions
What does AI-ready data actually mean?
It means an AI employee can reach the data and knows what it means. Reaching it is a connection, usually OAuth to the tool you already use. Knowing what it means is a written definition of the source of truth, the terms, and the exceptions. Perfect schemas and a central warehouse are not requirements for most business jobs.
Do we need a data warehouse before using an AI employee?
No, not for the recurring operational work most teams start with. If a person can produce the report today by opening two or three tools, an AI employee can produce it by reading those same tools. A warehouse helps at analytical scale, and it is a quarters-long project that should not block a job you do by hand every month.
How much data cleanup is enough?
Enough for one job. Clean the fields that job reads, write the exceptions, and leave the rest. Cleanup that is not attached to a specific output tends to expand forever and rarely gets finished.
What if our information lives in spreadsheets and PDFs?
That is normal and workable. An AI employee reads spreadsheets, exports, and documents rather than requiring a structured source. Tell it which file is authoritative and where it lives, because the real risk with documents is not format, it is five versions of the same file.
How do we know whether it is getting the numbers right?
Run it in parallel with the human who does the job today, for two cycles, and compare line by line. Every difference is either a bug or a missing definition, and both are cheap to fix at that stage. Do not skip to unattended running before the two cycles match.
Who should own the context page?
The person who does the job today, not IT. They hold the definitions and the exceptions, and the page is a written version of what they would tell a new hire. Keep it with the task itself so the next person inherits both.
Does messy data mean the AI will make things up?
It means you should require a flag instead of a guess. State in the context that any record not matching the rules goes into an exceptions table for a human to resolve. The exceptions list is a useful output on its own, because it shows you exactly where your process is undefined.
