top of page

Who Owns the Data Your AI Uses?

Shift Quality Editorial
58 minutes ago
11 min read

An AI assistant inherits every unanswered question about its sources. The first one to surface in an incident is usually "who owns this?", and by then it is too late to ask it calmly.

The bid assistant had been live for six weeks when a client's procurement lead queried a clause in a proposal. The liability cap in the draft terms was one the firm had withdrawn more than a year earlier, after its insurer changed the cover. Nobody on the bid team had typed it. The assistant had drafted the terms section from what it found in its index, and what it found was a 2023 template.

The firm was a mid-sized engineering consultancy. (Composite scenario, built from patterns that recur in professional services firms; not a single verified incident.) The assistant was a sensible project: a retrieval-augmented model that answered bid teams' questions and drafted standard sections from the firm's "Bids & Proposals" shared drive, about 14,000 files gathered over nine years. Past proposals, CVs, case studies, rate cards and three generations of contract templates. The pilot had gone well. Answers were fluent, cited their sources and scored highly with the bid team.

The incident review asked a short question and could not get an answer: who owns the Bids & Proposals drive?

  • The person who created it had left in 2021.

  • IT ran the storage, backups and permissions, and was clear it did not decide what was in it.

  • Legal owned the contract templates, but did not know copies lived on that drive. Its current versions sat in a separate, locked library.

  • The bid team used the drive daily and assumed someone else kept it tidy.

  • The AI team had indexed it because the bid team asked, and the bid team had access.

So nobody could say which files were current, which could feed the assistant, or which could be deleted. The fix was not a model change. The assistant was switched off for five weeks while a lawyer and two bid managers went through folders by hand.

The model retrieved what it was given and quoted it faithfully. The failure was that the organisation had pointed an AI at data nobody had the authority to vouch for.

Why "IT owns it" and "set up a council" both feel right

Two responses come quickly after an incident like this, and both are reasonable.

The first treats ownership as an infrastructure question: the drive lives on a platform, the platform team runs it, so the platform team owns the data. That confuses holding data with answering for it. A platform team can tell you who has access to a folder. It cannot tell you whether a 2023 contract template is still the firm's position. IT's real role is custodian: it runs storage and access on someone else's behalf.

The second treats ownership as organisational design: charter a data governance council, define domains, appoint domain owners and buy a catalog. At enterprise scale that is often the right destination. As a response to an AI feature shipping this quarter, it fails on time. The council's first output is usually a policy, and the feature either waits or ships against the same unowned sources anyway.

Both skip the question that matters for AI delivery: for the specific sources this feature reads, who holds which decisions? That needs a short, explicit answer per source, before ingestion, not an enterprise answer.

Ownership is a set of decision rights, not a title

"Data owner" sounds like a title on an org chart, and that is the confusion behind most orphaned data. What an AI feature needs is narrower and testable: a named person for each decision someone will eventually have to make about a source.

Four roles carry those decisions. The terms are common in data management practice; these definitions are ShiftQuality's working versions, tuned for AI inputs.

  • Owner: accountable for the data because they are accountable for the business process it records.

  • Steward: acts for the owner day to day, keeping definitions, metadata and quality checks current and bringing decisions to the owner.

  • Producer: the team or system that creates or changes the data, and must give notice before it changes.

  • Consumer: anyone using the data, including the AI feature, within the approved purpose.

Here is how the decisions an AI feature raises fall across them:

Decision about a source

Owner

Steward

Producer

Consumer (AI team)

May this data be used for this AI purpose?

Decides

Prepares the case

Consulted

Requests

Who may see it, directly or through the AI?

Decides

Maintains classification

Informed

Enforces in the index

Which versions are authoritative; what is "current"?

Decides

Defines and documents

Consulted

Filters to it

What quality is good enough to ingest?

Approves threshold

Sets and monitors

Meets it

Gates on it

A format or meaning change is coming

Informed

Coordinates

Gives notice

Adapts

A defect is found in the data

Informed

Triages

Fixes at source

Reports, may quarantine

Retire or delete it, including from indexes

Decides

Executes

Stops producing

Removes from index and caches

Read it against the consultancy. Every cell in the Owner column was empty for the drive. Legal held the "current" decision for templates, but only for its own library. And the bid team, a consumer, had made the "may this be used for AI" decision by default, simply by asking for the index. That decision was never theirs, and nobody noticed because no name sat in the column above it.

Diagram showing how a dataset becomes orphaned in five steps, from creation for one purpose to an AI index nobody can vouch for, alongside the four decision roles of owner, steward, producer and consumer that close the gap.

How a dataset becomes an orphan

Data does not arrive orphaned. It gets there through local decisions that are each sensible on the day:

  1. Created for one purpose. One bid team set up the drive to share drafts. Its de facto owner was the team lead.

  2. Shared for convenience. Other teams were given access. Copies of templates and rate cards landed there because that was where people looked.

  3. The creator moves on. Access stayed; accountability left with the team lead. The leaver process never asked who would answer for the drive.

  4. The custodian keeps it running. IT kept it backed up and permissioned, which made it look cared for. Storage health is not content health.

  5. An AI consumer arrives. The AI team treated the bid team's access as permission to use the data for a new purpose.

Step five is where AI changes the risk. A person browsing the drive sees file dates and a folder called "OLD do not use". A retrieval pipeline sees chunks of text ranked by similarity. Most of the context a human used to judge whether a document was current is gone by the time the model reads it.

External guidance points at the same gap. Microsoft's readiness guidance for Copilot says its assistants "respect existing permissions, sharing settings, and policies", lists ownerless sites as a governance gap to find, and notes that SharePoint's sharing settings default to the most permissive option (Microsoft Learn, 2026). Respecting permissions is necessary, but access is not a decision that the content should be used. OWASP's guidance on vector and embedding weaknesses tells teams to "accept data only from trusted and verified sources" (OWASP LLM08:2025). Nobody can verify a source nobody owns.

The discovery move: ask the ownership question at intake, per source, before ingestion. "Who can approve this source for this purpose?" belongs with the data questions to ask before an AI project starts. If the answer is "IT" or "the drive", you have found an orphan while it is still cheap.

The obligations assume someone is answerable

Several frameworks assume a named decision-maker exists for AI data. For high-risk systems, Article 10 of the EU AI Act requires "data governance and management practices appropriate for the intended purpose", covering "data collection processes and the origin of data" (EU AI Act, Art. 10). Most internal assistants are not high-risk, so check classification rather than assume it (see the high-risk classification guide). Where a system is, documenting the origin of 14,000 files nobody answers for is not realistic.

Where the data includes personal data, GDPR requires it be "collected for specified, explicit and legitimate purposes" and not further processed incompatibly, and makes the controller able to "demonstrate compliance" (GDPR, Art. 5). CVs uploaded for bids are personal data, and feeding them to an assistant is a new purpose someone must assess. Legally the controller is the organisation; in practice, a named owner plus your privacy function is how that assessment gets made. This is a general description, not legal advice.

The NIST AI Risk Management Framework asks that roles and responsibilities for managing AI risks "are documented and are clear to individuals and teams throughout the organization" (GOVERN 2.1, NIST AI RMF Playbook). Data roles are part of that.

Test your own sources: the five-question check

For each source an AI feature reads, write a name against five questions. A team alias is not an answer; a person you could call is.

  1. Who can approve using this source for this AI purpose?

  2. Who decides which version is authoritative, and what "current" means?

  3. Who will tell the AI team before the format or meaning changes?

  4. Who can authorise deleting it, including from the index and logs?

  5. Who acts when a wrong answer is traced to this source?

Different names for different questions is normal. A blank, "IT" or "the drive" on question 1, 2 or 4 means the source is orphaned for AI purposes, whatever the platform says. Score each source owned, partly owned or orphaned.

For the consultancy, this would have taken an afternoon. The HR CV library would have scored owned, and so would Legal's template library. The Bids & Proposals drive would have scored orphaned on all five, and it was the source the assistant used most.

How to assign owners without a reorganisation

This method is for the team shipping the AI feature, backed by the feature's sponsor. It needs no council, only one default rule the sponsor will enforce.

1. Scope to the feature's inputs. List the sources this feature reads, at the level you grant access: a library, a site, a folder, a table. Ten sources properly owned beat an enterprise map that is never finished.

2. Find the owner through the business process, not the storage. Ask which process each source records and who answers for that process. Contract templates record the firm's contractual position: Legal. Rate cards record pricing: the commercial lead. Past proposals record bids: the bid director. Where the files sit is irrelevant.

3. Ask for decisions, not a title. "Will you own this drive?" sounds like unlimited work and gets refused. Ask instead for three decisions: approve this purpose, define current, authorise deletion. Then offer a named steward, from their team or the AI team, to do the work. Accountability is easier to accept when the labour is visibly someone else's.

4. Split mixed sources. The consultancy's drive held at least four datasets with four natural owners. Index only the pieces that have one owner each, using an allowlist of folders, never the whole drive.

5. Apply the orphan default. Give each owner candidate a short deadline to accept; ten working days is our recommendation, not an external standard. Anything still unowned defaults to the AI feature's sponsor, who must either adopt it, with a steward and the five questions answered, or drop it from the inputs. This rule is what removes the need for a reorganisation: it puts the cost of an orphan on the one person with a reason to resolve it quickly.

6. Record it where the pipeline reads it. One line per source: owner, steward, producer, approved purpose, classification, review date. Keep it beside the ingestion configuration and make ingestion fail closed when the owner field is empty. The AI Data Intake & Contract template has a section for this record, and data contracts for AI features formalises the producer's change-notice promise.

7. Wire it into leaver processes. Add data ownership to the mover and leaver checklist so a departing owner's sources are handed on. It is the same failure as an agent whose builder changed teams, covered in agent governance starts with an inventory nobody has.

You are done when every source the feature reads has a named owner and steward, the five questions are answered, and ingestion refuses any source that is not.

Trade-offs and where this changes

Who holds ownership

Gains

Costs

Best suited for

Warning signs

Business-process owner (default)

Decisions sit with whoever knows what is true

Slow to accept; needs a steward

Most documents and records

Owner accepts but never answers the steward

AI feature sponsor (orphan default)

Fast; forces keep-or-drop

Sponsor may not know the content

Orphans the feature genuinely needs

Sponsor "owns" dozens of sources, reviews none

Platform or IT team

Already holds access and tooling

Cannot judge content

Logs, telemetry, system configuration

Business questions routed to IT tickets

Committee or council

Consistent policy

No single accountable person

Setting standards across owners

Decisions "pending next meeting"

Exceptions worth making explicitly:

  • Licensed and third-party data. The owner is whoever holds the vendor relationship, and their first decision is whether the licence permits AI use. NIST's GOVERN 6.1 calls for policies on AI risks from third parties, including infringing their rights. A vendor's assurances do not settle this for you; see your AI vendor's compliance doesn't make you compliant.

  • Small teams. Owner and steward can be one person. The test is that the decisions are named, not that four people hold them.

  • Personal data. An owner does not replace the controller's legal duties or your data protection officer. Both names belong on the record.

  • Archives with no living process behind them. The honest answer is usually to exclude or archive them, not to invent an owner to keep them indexed.

Implementation reality: where this breaks

Accountability without capacity. Owners accept and then never answer. If the steward's questions wait longer than your review cycle, escalate to the sponsor, who can invoke the orphan default.

Ownership lives only in the catalog. A catalog is a good place to publish ownership and a poor place to enforce it. If ingestion can run without reading the owner field, assume the field will drift.

Indexes outlive decisions. When an owner withdraws approval, the source file is the easy part; embeddings, cached answers and logs hold copies too. Classify and set retention before you ingest data into RAG covers the deletion path, and lineage for AI inputs covers tracing which version produced an answer.

Ownership is one of six controls in data governance for AI delivery, and it comes early because the others, quality gates, contracts and retention rules, all need someone with authority to set them.

What to do next

Pick the AI feature closest to production and list every source it reads. Run the five-question check on each. Take the orphans to the feature's sponsor this week with one question per source: adopt it, with a named steward, or remove it before launch.

Final takeaway

For AI purposes, ownership is a short list of decisions: may we use this, what is current, who may see it, when does it go. Each needs a named person. Assign them per source, default the orphans to whoever wants to use them, and make the pipeline refuse anything unowned. That takes no reorganisation, only the habit of asking "who owns this?" before ingestion rather than during an incident.

Sources

Frequently Asked Questions

What is the difference between a data owner and a data steward?

The owner is accountable: they decide whether the data may be used for a purpose, who may see it, what counts as current and when it is retired. The steward does the work on the owner's behalf: keeping definitions, quality checks and metadata up to date, and raising issues the owner must decide. One person can hold both roles in a small team; the decisions still need to be named.

Isn't IT the owner of data on shared drives and platforms?

Usually not. IT or the platform team is the custodian: they run storage, backups and access mechanics. They cannot say whether a document is current, whether it may feed an AI assistant, or whether it can be deleted. Ownership belongs with whoever is accountable for the business process the data records.

What should happen to a data source nobody will own?

Give it a default owner: the sponsor of the AI feature that wants to use it. The sponsor either adopts it, with a named steward, or removes it from the feature's inputs. An unowned source should not be indexed.

bottom of page