When we surveyed 30 senior data and IT leaders for The AI Data Readiness Playbook, one of the things we asked was who inside their company would most likely champion getting data ready for AI. Enterprise architecture came out on top at 33%, and senior data leaders named themselves close behind at 30%. The answer most people would guess first never showed up at all, because not a single respondent said data engineering.
That seems strange until you think about what owning this actually involves. Data engineering builds the pipelines and is usually the first team to notice when the history behind a dataset is thin, but noticing a problem and being able to stop a launch over it are very different jobs, and the space between them explains a lot about why AI projects stall.
Who Should Own AI Data Readiness (and Why It Isn’t Data Engineering)
Picture the review meeting the week before an agent goes live. The platform team has confirmed the configuration and legal has already approved what the agent can say to customers, so the room is mostly ready to move on. If a data engineer speaks up at that point, maybe to mention that opportunity history only goes back eighteen months, the concern gets logged as a risk and the launch goes ahead anyway, because nobody in the room is obligated to wait for it to be fixed.
That’s the pattern sitting underneath the survey numbers. The companies that get this wrong rarely lacked the skill to catch the problem. What they lacked was someone with the standing to delay the launch, and that kind of standing tends to belong to enterprise architects, who already look across every system the agent will touch, or to senior data leaders who have a working relationship with the executive sponsor. Data engineers still do most of the work of fixing whatever gets found. Putting ownership with someone more senior just means their warnings reach a person who can act on them.
It also helps to think about what each of those roles can see that others can’t. An enterprise architect looking at a Salesforce-backed agent will usually know that the CRM keeps only the current state of most records, and that the copy sitting in the warehouse has flattened the relationships between accounts and opportunities along the way. None of that is hidden, but it’s spread across teams that rarely sit in the same meeting, and the architect is often the only person whose job already covers both sides. A head of data brings something different, which is the credibility to tell a business leader that their launch date is going to slip and have it land as a judgment call rather than an excuse.
Why AI Pilots Fail Without a Data Readiness Owner
An agent that only answers questions can get away with being a little wrong. Once it starts approving exceptions on customer accounts, though, it’s making the kind of call that used to need a manager’s sign-off, and when it gets one wrong because the history behind it was missing or stale, legal and compliance want to know who was supposed to catch it. Gartner’s framing of AI-ready data reflects this, treating governance as something an executive sponsors rather than a task handed down to a data engineering team.
Without that sponsor, the data problem still gets found, just later, usually after customers have seen a few bad answers and the pilot has started losing support somewhere around month four. The larger cost shows up in the next budget cycle. A board that watched one AI initiative stall tends to approve the second attempt with less patience and a lot more scrutiny, which leaves that project even less room to discover a data problem halfway through.
Most of that cost never shows up as its own line item. It looks more like a data science team spending most of its week pulling and cleaning records instead of building anything, or an agent that gets switched off after one embarrassing answer too many and never comes back. The playbook puts the trade-off plainly: finding out in week one that the data isn’t ready is far better than finding out in month nine that an agent in production has been working from incomplete history the whole time. An owner with the authority to delay is how a company ends up with the week-one version of that story.
Find the Gaps in Week One
Score your Salesforce data before an agent goes live.
AI Governance and Data Readiness: One Budget, One Owner
It doesn’t help that most companies run governance and data readiness as separate efforts, when the people buying for them already see one problem. Asked what would make them distrust an AI answer even when the data looked right, our survey respondents most often said not being able to trace it back to its source, with nearly half citing verification and explainability and roughly another quarter naming traceability directly. Separately, 60% said AI-ready data capabilities fit inside a category they already buy for, most often data governance. In a lot of companies the budget and the mandate are already sitting together, and nobody has been named to own them for AI or to make sure each answer can be traced to the exact records and versions behind it.
Get the AI Data Readiness Playbook
Findings from 30 data leaders plus a scorecard to run today.
Traceability is also where governance and readiness stop being abstract. For a Salesforce-backed agent, tracing an answer means being able to say which opportunity it drew on and what that record looked like on the day the agent read it, not just what it looks like now. If the only copy of the data keeps current state, that question can’t be answered, however good the governance policy looks on paper. The person who owns readiness ends up owning a governance outcome whether their title says so or not, which is a strong argument for giving the job to someone who can work across both.
