Is Your Data AI-Ready? 6 Questions to Answer Before You Fund a Single Pilot

Key Takeaways

• "AI-ready" only means something for a named use case. Data is ready or not for one specific job, so the readiness question starts with the decision a pilot will change.
• Most companies already suspect the answer. Gartner found 63% of organizations lack, or aren't sure they have, the right data management practices for AI.
• Six questions cover the ground. Use case, ownership, quality, access, permissions and the production path.
• Each question should end in a number. A board can track "share of sources with a named owner." It can't track "we're working on data."
• Fund the answers before you fund the pilot. A few weeks of finding out is cheaper than a pilot that stalls on data nobody checked.

Here's the part of AI budgeting that doesn't add up for me. A board will spend a full meeting debating which AI use case to fund, and a few minutes, if that, on whether the data underneath it exists in a form a model can use.

The research says that's backwards. Gartner predicts that through 2026, organizations will abandon 60% of AI projects that aren't supported by AI-ready data. The same research found 63% of organizations either don't have the right data management practices for AI or aren't sure whether they do. (That second number is self-reported. I'd treat it as the optimistic version.)

So "is your data AI-ready?" gets asked a lot. I think it's usually asked in a shape that can't be answered. It invites a yes or no for a whole company, and a whole company is never ready or unready. The ERP might be clean. The shared drive is a mess. The CRM is fine for pipeline reviews and useless for anything that needs a contract term.

Here's how I think about it instead: data is never AI-ready in general. It's ready, or not, for one specific job. Name the job first, and readiness turns into six concrete questions. Each one can end in a number a board can track. If your team can answer all six with a number, fund the pilot. If they can't, the first investment is finding out.

1. What Decision Will This Pilot Change, and What Data Does It Need?

Every other question depends on this one, which is why it goes first.

Most pilot proposals describe a capability. "An agent that answers questions about our contracts." "AI for demand forecasting." That's a category. A use case names a decision or a piece of work that changes: a pricing analyst approves renewals faster, a plant scheduler stops rebuilding the weekly plan by hand. Once you name that, the data list falls out of it. The renewal decision needs contract terms, usage history and the current price book. Nothing else.

This matters because data work expands to fill whatever scope you give it. Tell a team to "get our data AI-ready" and you've funded a multi-year data program. Tell them to get three sources ready for one renewal workflow and you've funded something with an end date.

Write the data list before the vendor list

Before anyone takes a vendor demo, write down every source the pilot would touch: the system, the table or folder, and the fields that matter. If the team can't produce that list in a week, the pilot isn't ready to fund. The number to report: named data sources for the pilot.

2. Who Owns Each Source?

Ownership sounds like an org chart detail. In practice, it decides whether problems get fixed.

When a pilot hits bad data, someone has to decide what "correct" means and fix it at the source. If nobody owns the source, the AI team patches it downstream, the patch breaks the next time the source changes, and the pilot quietly dies. In Precisely's survey with Drexel University's LeBow College of Business, 62% of data and analytics professionals named a lack of data governance as the top data challenge holding back their AI initiatives. Governance is a big word. Most of it starts with a name next to a system.

Put a name next to every system

For each source on the pilot's list, name the person who can answer "is this right?" and has the authority to change it. One name, not a department. Report the share of pilot sources with a named owner. Anything under 100% is a risk the board should see before the money moves.

3. When Was This Data Last Checked?

Here's the uncomfortable one. Most teams believe their data is better than it is, right up until a model starts reading it.

The same Precisely and Drexel LeBow research found only 12% of organizations say their data is of sufficient quality and accessibility for effective AI, and 67% don't completely trust the data they use for decisions. That survey was fielded in the first half of 2024, before most companies started pointing agents at their systems. I doubt the number has improved since.

A person reading a report can spot a stale number and ignore it. A model can't. It will answer confidently from a price list that changed last quarter.

Measure freshness and completeness on the pilot's slice only

Don't audit the whole warehouse. Profile the fields on the pilot's list: how old is the newest record, what share of rows have the fields filled in, how many duplicates are there. That takes days. Report freshness and completeness for the pilot's data, in plain numbers.

4. Can a System Actually Reach It?

Data that exists and data a system can reach are two different inventories.

The structured systems usually have APIs or exports, even if they're clunky. The problem is everything else. The contract PDFs on a shared drive. The SOPs in a SharePoint site nobody has organized since a reorg. The pricing exceptions that live in email threads. For a lot of the use cases boards actually want (answer questions about our contracts, our procedures, our customers), that's where the answers are.

Count the documents nobody has indexed

For each source, ask how a system would pull from it today: API, scheduled export, manual download, or not at all. Then count the unstructured sources separately, because they're usually where the timeline slips. Report the share of pilot sources reachable by API or export. If the gap is large, it's a pipeline problem first, and that's data engineering work you should scope before the pilot, not during it.

5. What Is the AI Allowed to See?

This is the question that stops pilots late, after the demo has already impressed everyone.

A pilot that reads contracts will read the ones with confidential terms. An assistant connected to a shared drive will find the HR folder someone forgot to lock. Permissions that were "good enough" for humans who never went looking become a real exposure when a system reads everything it can reach. In regulated industries, this is also where retention rules and data residency come in.

I'll be honest that this part of the field is still immature. The security model for agents with broad access is an open problem, and anyone who says they've fully solved it is overselling. But you can still do the basics before the pilot starts.

Tag sensitivity before you connect anything

Mark each source by sensitivity (public, internal, confidential, regulated) and decide which tiers the pilot can touch. Check that the access the pilot would get matches what the users of the pilot are allowed to see. Report the share of pilot sources tagged for sensitivity. Our AI security, compliance and governance work covers data classification and sensitive data handling for this reason.

6. Who Runs This When the Pilot Works?

Funding a pilot with no path to production is funding a demo.

S&P Global Market Intelligence found the average organization scrapped 46% of its AI proofs of concept before they reached production, and the share of companies abandoning most of their AI initiatives rose to 42% from 17% a year earlier. Cost, data privacy and security risk topped the list of reasons. Every one of those reasons could have been asked about in month zero.

A pilot can run on a one-time data export. Production can't. Somebody has to keep the pipeline running, watch for source changes, and own the result when the model gets something wrong.

Price the production path at the same time as the pilot

Ask for two numbers in the same proposal: what the pilot costs, and what it costs to run the thing for a year if it works. Name the team that will own it. Report a named owner and a cost estimate for the production path. If no one will take it, that tells the board something too.

The Board Scorecard: Six Answers, Six Numbers

Here's how the six questions translate into something a board or operating partner can review in one page.

None of these numbers need to be perfect to fund a pilot. They need to exist. A scorecard with honest gaps is a much better basis for a decision than a pitch deck with none.

Fund the Answers Before You Fund the Pilot

Connecting a model to your systems is the quick part. The slow part is people, and that includes the people who own the data. Getting six owners to agree on what "correct" means for their systems is slower than any model integration.

I don't have a clean threshold for "ready enough." I've gone back and forth on whether a pilot should wait for 100% ownership or start at 80% and fix the rest in flight, and I think it depends on how expensive a wrong answer is for that workflow. What I'm sure of is that a board should see these six numbers before it signs off, and that finding them is cheap relative to a pilot that stalls.

That's the work PressW's AI & Data Readiness Assessment is built for. We profile your key sources for quality, completeness, freshness and access, map how the work actually runs, review your security posture, and finish with a scored readiness baseline and a pilot-ready first initiative. If you want to pressure-test a pilot proposal against these six questions, Book a Discovery Call.

FAQ