Who Should Own Data Quality? Why “Nobody” Breaks Your First AI Project

Here’s how a data quality problem usually announces itself in an AI pilot. Nobody files a ticket. A pilot user asks the assistant a simple question about a customer, gets an answer that’s confidently wrong, and mentions it in the hallway. By the end of the week, three other pilot users have heard the story, and the assistant has a reputation it will never shake.

When I ask who has data quality ownership for that customer record, the answer is almost always a pause followed by “IT, I guess?” That’s the moment I know the pilot is in trouble. Not because IT is bad at data, but because ownership that sits with IT usually means it sits with nobody. IT runs the systems. It doesn’t decide what a correct customer record looks like, and it can’t tell when one is wrong.

Why AI raises the stakes

Bad data has always existed. People worked around it. The account manager knew the billing address in the ERP was outdated and called the customer. The analyst knew to exclude test accounts before building a report. Every workaround was a small act of data quality ownership, performed by someone who wasn’t officially responsible for it.

AI removes those people from the loop. An assistant or an automation reads the record as it is and acts on it. It doesn’t know the address is stale. It repeats the error in every answer, to every user, at a volume no human analyst ever reached. And users judge an assistant on trust, not on accuracy statistics. A couple of visible wrong answers early in a pilot will do more damage than a hundred correct ones can repair.

Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:

D2. Who is accountable for data quality?

0. Nobody; issues get fixed when someone complains
1. IT fixes problems ad hoc
2. Named owners exist for a few critical systems
3. Named owners for most data domains, with documented quality standards
4. A formal data governance program tracks quality metrics

Levels 0 and 1 look different but behave the same: quality work happens only after something breaks. Level 2 is the first rung where someone is accountable before the complaint arrives, and it’s the minimum I’d want for any data domain an AI pilot depends on.

Why IT shouldn’t own data quality

This is the part that surprises IT leaders, because it sounds like they’re being told to give something up. They’re not. They’re being told to stop carrying something that was never theirs.

Data governance practice has long split the job into three roles, and the split is useful even at a company with no governance program at all:

• Data owner: a business leader accountable for a data domain. They decide what “correct” means, approve who gets access, and answer for the quality. Usually the head of the function whose process creates the data.
• Data steward: the person who does the day-to-day work. They monitor quality, fix records, and flag patterns to the owner. Often an operations analyst or a power user in that department.
• Data custodian: IT. Custodians run the systems, manage backups and access controls, and build the integrations. They keep the data safe and available. They don’t define what’s right.

When IT is asked to be owner, steward, and custodian at once, it does the custodian job well and the other two by guessing. The fix isn’t more IT effort. It’s moving the owner and steward roles to the people who can actually tell a good record from a bad one.

A decision rule for picking owners

The fastest way to assign an owner: the owner is the leader whose process creates the data, or whose team feels the pain when it’s wrong. Usually those are the same person. When they’re not, pick the one who feels the pain; they’ll be motivated.

• Customer records: usually sales operations or customer success, not whoever administers the CRM.
• Product and pricing data: product management or finance, depending on who sets prices.
• Employee data: HR, even though IT provisions accounts from it.
• Vendor and spend data: procurement or finance.

If nobody will accept ownership of a domain, that’s a finding in its own right. It means no AI use case should depend on that data yet. Write it down and move your pilot to a domain that has an owner.

The asset: a one-page data ownership charter

Don’t start a governance program. Start one page per data domain that your first AI use case touches. Here’s the template I give teams:

1. Domain: for example, “Customer accounts.”
2. Authoritative system: the one system that wins when sources disagree. If you haven’t settled this, do the source-of-truth mapping first.
3. Owner: a named business leader, not a team or a committee.
4. Steward: a named person with a few hours a month set aside for this.
5. Custodian: the IT contact for the system.
6. Quality rules: three to five plain-language rules. “Every active account has a billing contact.” “No duplicate accounts for the same tax ID.” “Industry field is filled for accounts created this year.”
7. How we measure each rule: a saved report or query that shows the count of records breaking it.
8. Where issues get reported: one channel, not “email whoever.”
9. Review cadence: the owner and steward look at the rule counts monthly, for fifteen minutes.

That’s the whole thing. It fits on a page, and it moves a domain from level 0 or 1 to level 2 the day the owner signs it. Do it for each domain your first use case needs, and nothing else yet.

The first 30 days

Week 1: list the data domains your first AI use case reads from. For most pilots that’s two or three. Draft a charter for each with the owner name left blank.

Week 2: take the drafts to the likely owners. Frame it as protecting their team from wrong AI answers, not as extra work from IT. Get a name on each page.

Week 3: build the measurement reports for each rule. Don’t fix anything yet; just get the counts. The numbers are almost always worse than anyone expected, and that’s useful: it’s your baseline.

Week 4: first monthly review. The owner picks which rule to clean up first. The steward starts on it. IT’s job is to make the reports and fixes easy.

If you’re planning the pilot at the same time, make “the data domains it depends on have signed charters” a gate in the pilot plan. It pairs well with the pilot baselines in baseline before you build, since the quality counts are part of what you’ll want to show improved.

Mistakes I see at this stage

Appointing a committee instead of a person. A data governance council can be useful later. A committee as the owner means nobody is. Every domain needs one name.

Owners without time. An owner who agrees and never looks at the numbers is level 0 with better paperwork. Fifteen minutes a month, on the calendar, is the minimum.

Rules without measurement. “Customer data should be accurate” isn’t a rule. “Every active account has a billing contact” is, because you can count the exceptions.

Buying a data quality tool first. Tools help once you know what to measure and who acts on the results. Before that, a saved report does the job, and the money is better spent later.

Trying to fix history. Ten years of bad records won’t be cleaned in a quarter. Set rules for records going forward, clean the ones your use case actually touches, and let the rest age out.

What moving up one level looks like

From 0 or 1 to 2: charters with named owners for the domains your first use case needs. From 2 to 3: extend the charters to most domains, and write the quality standards down so they survive staff turnover. From 3 to 4: that’s a formal governance program with tracked metrics, and it usually belongs under the broader operating model in AI governance for mid-size IT rather than as a standalone effort.

For most mid-size teams, getting the first two or three domains to level 2 is a month of part-time work and changes the odds on the first pilot more than any technology choice.

Where does your team actually stand?

Data quality ownership is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

• Where Should Your Business Data Live Before AI?
• Baseline Before You Build: Metrics That Make AI Pilots Fundable
• AI Governance for Mid-Size IT: The Lightweight Operating Model
• The 6-Dimension AI Readiness Framework, Explained
• The AI Readiness Checklist: 24 Questions to Answer Before Spending a Dollar