Earlier this year, I was at a conference talking with several CDOs about how they were preparing their data governance programs for AI.
Many of these were advanced programs. Teams were working on policy enforcement, automated data quality checks, metadata for agents, governance across lakehouses, and a long list of other things. But as the conversation went on, almost every CDO came back to the same problem. The bigger the program became, the harder it was to execute.
I’ve had some version of that conversation dozens of times over the past couple of years. Most organizations aren’t short on ambition. They’re investing in governance, data quality, catalogs, lineage, and AI infrastructure. The problem is that AI readiness can quickly turn into an enterprise-wide transformation program before anyone has proven what a single AI workflow actually needs.
Organizations that are making progress tend to be much more specific. They can answer three basic questions about the AI use cases they’re putting into production. Surprisingly few companies can answer all three.
What data is your agent actually using?
Start with a basic question. Which datasets is the agent reading today?
I don’t mean which platforms it’s connected to or which tools are in the architecture. I mean the actual datasets. Where did they come from? Which version is being used? How current are they? Who owns them?
Companies often know their architecture extremely well and still have a hard time answering those questions. I’ve seen environments with hundreds of thousands of documented data assets where an AI workflow depends on three or four of them. Cataloging everything has value, but it doesn’t tell you whether those three datasets are ready for the agent consuming them.
Take the first AI workflow you’re trying to deploy and map the three to five datasets it depends on. Identify the owner of each one, trace where the data came from, and confirm which version the agent is reading. You don’t need to solve lineage across the enterprise before you do this. You need to understand the lineage behind the data your agent is actually using.
When the agent is wrong, can you trace the answer back?
The second question is simple. If your agent gave someone a wrong answer this morning, how long would it take you to figure out which data caused it?
I’ve heard answers ranging from an hour to a week. I’ve also had people tell me they honestly don’t know where they would start. That’s a problem once an agent is being used for something consequential.
You need to be able to move backward from the answer to the data behind it. Which source did the agent use? When was it updated? Was it the certified version? Who was responsible for it?
This doesn’t require an elaborate certification program on day one. For the datasets feeding a production AI workflow, give someone clear ownership for confirming that the data is current and approved for that use. That could initially be as simple as recording that a dataset was verified on a certain date by a named owner.
Establishing ownership first sets up automation for later.
What does “trustworthy” mean for this data?
This is where the conversation usually gets harder to untangle. Ask data engineering, the business, and the governance team whether a particular dataset is trustworthy and you’ll often get different answers.
One team may care about freshness and completeness. Another cares about whether the business definitions are correct. Governance may care about ownership, lineage, and whether the data has been certified. All of those priorities can be reasonable, but the teams still need to agree on what qualifies as trusted for the workflow.
Before putting a dataset into an AI workflow, get the people responsible for that data into the same conversation. Agree on what “trustworthy” means for that specific use, including which thresholds are acceptable and which aren’t.
Make it concrete. If you can’t define exactly what trust means, an agent won’t be able to either. You’ll end up with different answers to the same query.
Maybe customer data has to be less than 24 hours old, match a defined set of quality thresholds, come from the certified customer master, and have a named business owner. Fine. Write that down. The definition will be different for another dataset, and that’s okay.
What doesn’t work is creating a definition so complicated that three committees have to approve it every time the data changes. AI workflows will move faster than that process can support.
Start slow to move fast
When teams find gaps in lineage, ownership, or trust, the instinct is often to expand the governance program. I’d go the other direction.
As the saying goes, “Slow is smooth, and smooth is fast.” Starting slow means picking one use case and using it to build a simple structure you can repeat.
Pick one AI use case that’s currently blocked. Identify the data it depends on. Assign clear ownership. Define what trustworthy means for that data.
According to the 2026 State of Data Integrity and AI Readiness survey, conducted by Precisely and the Center for Applied AI and Business Analytics at Drexel University’s LeBow College of Business, more than 500 enterprise data and analytics leaders were surveyed. Of those respondents, 55% reported actively deploying AI, while another 30% were still in the planning phase.
In my experience, companies making that jump from planning to deployment don’t wait until every part of their data environment is AI-ready. They narrow the problem to one use case and answer three questions first.
- What data is this agent using?
- Can we trace a bad answer back to its source?
- Have we agreed on what trustworthy means for that data?
Start with those questions for one AI workflow and build from there.
This piece originally appeared in The AI-Ready Data Digest on Medium, where our Precisely experts share their insights on AI, data readiness, and what it takes to build AI systems that work. Explore the publication to get AI-ready today.
