AI data governance vs AI governance: who owns what

Two working definitions, because no standard settles it

Neither phrase has one authoritative definition, and the three primary sources here don’t draw the line where an org chart needs it. The working definitions below are my own.

AI governance is about the system and the decision to use it: what the use case is, who is accountable, what risk tier applies, who oversees it, what happens when it goes wrong. Its unit of work is the use case. AI data governance is about what flows through the system: where the data came from, whether it fits the purpose, who may see it, how long it stays. Its unit of work is the dataset or the data flow.

A quick test separates them. "May we use an AI assistant to summarize credit applications?" is an AI governance question. "May that assistant retrieve last year’s declined applications to do it, and may the person reading the summary see them?" is a data governance question. You can get a yes on the first and a no on the second, and I wouldn’t ship until both are settled.

Three sources, three kinds of force

These documents get cited together as if they were interchangeable. They aren’t. Legal force differs, so does the audience, and so does how much each says about data. This table is the shortest fair comparison I could write.

NIST: read the appendix

The AI RMF’s core treats data as an input to risk work. Govern is the cross-cutting function, and Govern 6 asks for policies covering third-party software and data. Map 2.3 asks teams to document considerations around data collection and selection, including representativeness and suitability. Measure 2.1 asks that test sets be documented.

The sharper material sits in an appendix on how AI risk differs from traditional software risk. It points out that data may not faithfully represent the context of use, that ground truth may be missing, and that training datasets can become detached from their original context or go stale relative to deployment. That last idea connects the two programs. A dataset can pass every data quality rule and still be wrong for the purpose an AI system puts it to, and a catalog entry saying the table is approved says nothing about that fit.

The EU AI Act moved its dates

Article 10 is the provision people mean by "data governance for AI" in EU terms. It applies to high-risk systems. Its practices include design choices, data origin and the original purpose of personal data, preparation such as labeling and cleaning, the assumptions about what data represents, examination for bias, and identification of gaps. Data sets must be relevant, sufficiently representative and, as far as possible, free of errors and complete for the intended purpose. Paragraph 6 matters for many enterprise buyers: where a high-risk system does not involve training models, those requirements reach only the testing data sets.

Article 26 addresses deployers, the role most data teams occupy. Where a deployer controls input data, it must be relevant and sufficiently representative for the intended purpose. System-generated logs under the deployer’s control must be kept for a period suited to the purpose, at least six months unless other law says otherwise. Human oversight must go to people with the competence, training and authority to do it.

Timing changed this year. Regulation (EU) 2026/1744, the AI omnibus, entered into force in July 2026, and the consolidated text now shows these high-risk duties applying from December 2, 2027 for Annex III systems and August 2, 2028 for those tied to Annex I. Any plan written around the original August 2026 date needs revisiting. The consolidated page carries editorial markers, so have counsel confirm dates against the Official Journal.

Annex III does not list general business analytics. It does list uses such as evaluating the creditworthiness of natural persons and selecting job candidates or making decisions about promotion and termination. Classification follows the use. The same assistant can be outside Annex III when summarizing pipeline and inside it when feeding promotion decisions. An AI governance register therefore has to record the purpose, and a tool’s vendor can’t classify it for you. None of this is legal advice.

Where ISO/IEC 42001 fits

ISO describes 42001 as requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system within an organization. It covers how the organization runs AI, with policy, roles, risk assessment and review. It doesn’t certify that a particular system’s answers are good. The standard itself is paid, so read the Annex A detail here as a secondary summary: published mappings describe a data objective covering data for development, acquisition, quality, provenance and preparation. Check the numbering against your own licensed copy before quoting it to an auditor.

A certificate is useful evidence that a process exists. It does not establish that you meet Article 10 for a particular system, and an Article 10 file does not create a management system. Treat them as complements.

Run-time data usually has no owner

Article 10 is written mostly around training, validation and testing data. Classic data governance was written for people reading tables. An enterprise assistant that answers questions from live systems often trains nothing, so the training-data controls have little to hold on to, and the data that creates risk appears only once the system runs.

OWASP’s entry on vector and embedding weaknesses describes one form of this: weak access controls on embeddings can surface sensitive content, shared stores risk context leaking between users, and the recommended defense is permission-aware retrieval. Embedding a document can strip it of the access rules that governed the original, and nothing in a table-level catalog would show that.

Sort responsibilities on two axes and the cell for data at run time tends to have no owner. Its contents follow the figure.

• Retrieved contextText pulled from documents or definitions and placed in a prompt. Ask whether retrieval honors the reader’s access, or only the indexing account’s.
• Query history used as contextIt teaches a system how people join tables, and it can contain literal values one person could see and the next cannot. Keep query shapes and treat literals as sensitive.
• Conversation and prompt logsPeople paste things into chat. Those logs can become an unclassified copy of your most sensitive data, with their own retention clock.
• Generated answersAn answer is a new data object derived from governed sources. Once shared or exported, the source’s row policy no longer protects it.
• Feedback and evaluation setsCorrections and test questions hold real business values, and they tend to live in a spreadsheet owned by the pilot team.

One question traced through both programs

A fictional distributor, used here purely for illustration, wants a regional sales manager to ask an assistant for net revenue by account last quarter. AI governance registers the use case, records that it is internal decision support outside Annex III, names the owner and sets the rule that it may not feed compensation decisions, since that would change its classification.

AI data governance then answers a different list. The source is the warehouse fact table that finance reconciles to. The definition of net revenue has an owner. The manager sees only their region because the warehouse policy says so at query time. The prompt log keeps account names for 90 days, a synthetic retention figure for this example. Exports inherit a label naming the region.

Neither team can do the other’s list. Suppose the compensation team later starts screenshotting the answer into a performance review. That’s an AI governance event, and the data controls won’t detect it. Now suppose someone indexes the sales drive for the assistant and the index ignores folder permissions. That’s a data event, and a use case register won’t detect it either.

use_case: regional-revenue-assistant
owner_ai_governance: head-of-sales-ops
risk_note: internal decision support; not for employment decisions
data_flows:
  - object: warehouse.finance.fct_revenue
    role: queried live as the signed-in person
    definition_owner: finance-controller
  - object: prompt_and_answer_log
    role: created at run time
    owner_data_governance: analytics-platform-lead
    retention_days: 90
    contains_personal_data: possible
review_trigger: new source, new purpose, or a change of model

Divide the work without building a second committee

I wouldn’t set up a separate AI data governance council. Data stewards already own sources, and security already owns access. One intake for new AI use cases with two sign-offs is enough, plus a named owner for the run-time data cell. Route each change like this.

This week’s list

I’d do them in that order. The inventory and the retrieval test show real exposure in an afternoon, and framework mapping isn’t much use until those facts exist.

• List run-time data for one live assistantPrompts, retrieved text, logs, caches, answers, exports, feedback. For each, write where it lives and who owns it. A blank owner is your finding.
• Test retrieval with a narrow accountSign in as someone with restricted access and ask about content they should not see. Check the answer, the citations and any explanation.
• Add purpose to the registerA register that records tools and omits purposes can’t support an Annex III screen. Add one line per use and flag anything touching credit, hiring or employment decisions.
• Revisit AI Act datesAny plan assuming August 2026 for high-risk duties needs updating with counsel. Make sure the delay didn’t cancel the data work too, since you need that work regardless.
• Map evidence onceKeep one record per use case and reference it from NIST profiles, ISO audits and Act files, so three frameworks do not become three spreadsheets.

How we draw the run-time line at Nexatron

We keep data authority at the source. A question in Nexatron runs under the asker’s own sign-in, so in Snowflake their roles, row access policies and masking policies decide what comes back, and in Salesforce sharing rules, field-level security and the role hierarchy do. Each answer shows Answered as, Why you can see this, the definitions used and a trust label for where the definition came from, and a definition changes only when its owner approves.

For a security review, we hold SOC 2 Type I with Type II in progress, and ISO 27001. ISO 27001 is an information security standard, a different thing from ISO/IEC 42001, so ask any vendor which one a claim refers to.

Then ask to see the run-time cell: where prompts and answers are stored, who can read them, and what happens to access after an answer leaves the system.