Data Stewardship Roles in ML Pipeline Ownership

Three roles underpin every mature data governance program, and each carries a distinct job. Conflate them and the whole structure collapses.

The data owner is accountable for a domain's data in the fullest business sense: approving access, setting policy, and carrying organizational accountability for quality and use. The data steward is the operational executor, maintaining business definitions in the catalog, resolving data issues day-to-day, and bridging business and technical teams. Most stewards split their time roughly 60/40 between stewardship duties and a primary business role, which is by design, not accident. The data custodian is the technical implementer: storage, pipelines, access controls, backups. They execute what the steward defines.

The steward-custodian boundary is load-bearing, and it fails in a specific, predictable way. When a steward sits inside IT, they drift toward custodian work by default, and business consumers stop trusting that definitions reflect business reality. Definitions start serving technical convenience instead. That failure mode happens quietly and is genuinely difficult to reverse once it's entrenched. I've watched it happen in organizations that were trying hard to get governance right, and what surprises people every time is the speed: a data catalog can lose the trust of its users in months, and rebuilding that trust takes years, if it happens at all.

Analysts and ML engineers sit outside this triad entirely. They consume data, report problems, validate lineage. They do not own or steward it. That distinction held for over a decade because the data consumer was always a human being who could notice something odd and ask a question. These role definitions say nothing about what happens when the consumer is a training job running unattended at 2 a.m., or an inference API returning predictions at scale. That silence is structural, not accidental, and it's where the real accountability gaps begin.

Three mismatches make the problem specific rather than vague. First, stewardship roles were scoped to domains, but an ML pipeline pulls across domains simultaneously. A churn model might join CRM data, billing data, and clickstream data, each with a different steward, and no single steward's certification covers the combined dataset. Second, stewardship KPIs were designed around discovery speed and incident resolution, not around whether a training dataset was fit-for-purpose before a model learned from it. Third, access policies were written for human users making deliberate queries, not for a training job that touches millions of records unattended. The policy architecture assumed intentionality. ML pipelines are automated, and automation doesn't pause to ask for permission.

How the ML pipeline stages map to accountability — and where the current role structure leaves gaps

Five stages in the ML pipeline each carry a distinct accountability question. Treating them as a single undifferentiated workflow is how organizations end up with generalized commitments to "governance" that don't actually assign responsibility to anyone.

Data sourcing and ingestion

The custodian sets up the ingestion pipeline; the steward certifies the source dataset. That's the traditional model, and it works fine when a single team pulls from a single domain. The ML gap emerges at cross-domain joins. When a training job combines data from multiple sources, the combined dataset carries a sensitivity that no individual source owner evaluated, and sensitivity must be assessed at the point of combination, not only at the field level. No current stewardship role is chartered to do that assessment. So it either happens informally or it doesn't happen at all. Mostly it doesn't happen at all.

Feature engineering and the feature store

No traditional stewardship role covers derived features. They are transformations, not source data, and they fall between the responsibilities of the steward, who owns definitions, and the custodian, who owns pipelines. In a BI world, that gap was tolerable. In an ML world it isn't, because features are the unit of meaning a model actually learns from.

Consider a feature like "days since last purchase." Sounds self-evident. But which purchase events were included in that calculation? Do cancelled orders count? Which timezone governed the timestamp? None of that is typically documented in the feature store. The model learns from whatever the engineering team implemented, and the business steward who owns the "purchase" concept has no idea the feature exists, let alone how it was constructed. I've seen this exact scenario cause genuine downstream confusion when a model's outputs started behaving strangely in one regional market and nobody could trace why. It took weeks to surface the timezone discrepancy, and by then the model had been in production long enough that the cleanup was painful. Feature stores require stewardship logic, including versioning, business definitions, and lineage back to source columns, that the steward role was never chartered to provide.

Training data assembly and labeling

There is no clean role fit here in traditional governance. The data steward owns definitions. The data owner approves access. But who owns the decision that this labeled dataset is appropriate for this specific model objective? Currently, that decision is made by the ML engineer, who has technical accountability but no formal business accountability for the outcome.

The consequence of treating training data as a one-time engineering task is that there is no audit trail when a model's behavior is later questioned. This is now a regulatory exposure, not just a quality risk. The EU AI Act, in force since August 2024, treats training data documentation as a compliance requirement for high-risk AI systems. The gap has a legal dimension it didn't have two years ago.

Model training and the model registry

The ML engineer owns the training run. No stewardship role owns the model artifact itself. This matters because a model trained on data from a domain is a derived product of that domain's data, and the data owner typically has no visibility into or approval over that derivation. They approved access to the source data; they did not approve the model that learned from it. Those are different things.

Model registry controls, including who can promote a model to production and what documentation is required before promotion, are custodian work in practice. But nobody has formally chartered that custodian responsibility. It defaults to the ML team's informal norms, which vary by team and carry no accountability structure.

Inference and production serving

This stage is entirely uncharted territory for classic stewardship. Inference was not a concept in the original role design, and the accountability vacuum here is the most consequential one.

At inference time, a model typically accesses live data under a service account that holds far broader permissions than any individual user would be granted. The actual end user's identity and entitlements are not propagated to the query. This means a model can surface information to a user who, querying the database directly, would have been denied access. The steward defined the access policy; the service account bypasses it.

Inference logs are now audit material under the EU AI Act, which means custodians need to operationalize log retention for ML systems the way they already do for databases. This is rarely formally assigned. The result is that the stage of the pipeline with the broadest data access and the most direct regulatory exposure is also the stage with the least defined stewardship accountability.

The steward role is already splitting in two — and organizations that haven't noticed yet are behind

The bifurcation is already happening in organizations that are serious about AI governance. Business stewards retain their traditional duties: business glossary management, data quality oversight, access request processing, domain liaison. A new role, sometimes called the AI steward or model steward, takes on a distinct charter: model card maintenance, training data documentation, bias monitoring, AI Act conformity artifacts, feature store definition ownership.

The split is driven by skill requirements that don't naturally coexist. A steward fluent in business definitions for a BI environment does not automatically understand what training-data leakage means or how to interpret a confusion matrix. Asking one person to hold both skillsets is a design failure, not a development opportunity. These are legitimately different roles, and treating them as a single position produces stewardship that is either technically competent or business-grounded, but rarely both at once.

Data owners are being pulled into new territory as well. Approving or denying use of domain data for ML training now requires fluency in concepts like bias risk, model output consequences, and training-data lineage. None of those concepts were part of the owner role before. Organizations that don't invest in bringing data owners up to that standard will get perfunctory approvals with no actual evaluation behind them. That's not governance; it's paperwork with a signature.

The organizations that haven't formalized this split are running AI stewardship informally, typically inside ML engineering teams. The practical consequence is that business accountability for model behavior is being carried by people who have no business accountability, while business stakeholders who do have accountability have no visibility into model development. MIT CISR research, based on interviews with dozens of organizations conducted in early 2025, finds that business leaders must invest in semantic infrastructure to enable AI initiatives. For stewardship, the implication is direct: the AI steward role requires semantic-layer fluency, not just data catalog familiarity. That's a materially higher bar, and most organizations are not yet hiring or developing to it. Worth sitting with that for a moment: the bar has moved, the role hasn't, and most governance programs don't yet know the gap exists.

Assigning stewardship to each pipeline stage: a working model for accountability

The goal here is not a new org chart. It is RACI-level clarity: for each stage, who is Accountable, who is Responsible, and who must be Consulted before an artifact moves forward.

Data sourcing: The domain data owner approves cross-domain joins before training ingestion begins. The data steward certifies each source dataset against defined quality SLAs. The custodian implements pipeline access controls scoped specifically to the training workload, not a shared service account. Shared service accounts are where stewardship assignments go to die; I'd put that on a slide if I were still giving conference talks.

Feature engineering: The AI steward owns feature definitions in the feature store. Every feature requires a business definition, a lineage trace back to source columns, and a version. The ML engineer is Responsible for implementation. The business steward is Consulted when features derive from governed business metrics. This consultation step is the connective tissue between the two steward roles; skip it and the split produces silos instead of coverage.

Training data assembly: The AI steward produces the training data card, documenting inclusion criteria, labeling methodology, known limitations, and bias evaluation. The data owner of each contributing domain signs off before the dataset is locked for training. This sign-off should require substantive review, not a checkbox. Owners who approve without reviewing are carrying liability without exercising the judgment that would justify carrying it.

Model registry: The custodian enforces promotion gates. A model cannot move to staging or production without a completed model card and a linked training data card. The AI steward authors the cards; the ML engineer executes the promotion. Simple gate, but it closes the loop between the governance work done upstream and the artifact that actually runs in production.

Inference serving: The custodian implements inference-time logging at the query level, capturing identity, query, and lineage per inference, not at a batch summary level. Permissions are enforced at query time under the actual end user's identity, not a service account. The AI steward reviews inference logs for drift signals on a defined cadence.

One metric worth anchoring the entire framework to: percentage of production models with traceable data provenance. This is a 2025-2026 best-practice metric and a direct measure of whether the assignments above are functioning or have quietly drifted to formality.

The cross-domain join case deserves a standing process rather than a one-time approval. Any pipeline that joins data from two or more domains should trigger a joint owner review, because the combined dataset can carry sensitivity that neither individual source owner evaluated. That sensitivity assessment cannot happen after the model is already in production. By then, the window has closed.

What makes stewardship assignments hold in practice rather than drift back to ambiguity

Three conditions determine whether a stewardship assignment functions or becomes shelfware. All three must be present; any one missing and the framework degrades.

Discoverability. A steward can only govern what they can see. Every dataset, feature, and model artifact must be registered in a catalog with ownership, lineage, and business context that both humans and automated agents can query. This is not a philosophical point; it is an operational prerequisite. If the AI steward cannot find a feature in the catalog, they cannot govern it, regardless of what the org chart says. The catalog is the territory.

Enforcement at the right layer. Access policies and audit requirements must be enforced at the data layer, at query time, not patched onto the model layer or handled through prompt engineering. A service account with broad warehouse access defeats any stewardship assignment at the inference stage, because the model's query bypasses the permissions the steward defined. Enforcement that lives anywhere other than the data layer is advisory, not governing. The distinction matters enormously and is almost universally underappreciated. I've had this conversation with data teams at organizations that had genuinely sophisticated governance programs on paper, and the service account problem was invisible to them until something went wrong.

Context that travels with the data. AI agents have no institutional memory. They cannot ask a steward what a column means before using it. The semantic context a steward maintains, including business definitions, metric logic, and entity relationships, must be embedded in a governed semantic layer that every query traverses. This way, stewardship decisions made once are applied consistently at every access point. The steward's judgment becomes infrastructure rather than a recurring bottleneck.

Gartner projects that adoption of active metadata practices will increase by more than 75% by 2027. The catalog and semantic layer infrastructure that stewardship depends on is becoming standard, which shifts the question from whether organizations can build the infrastructure to whether they have assigned someone to own it. Gartner also forecasts that a significant share of organizations will adopt a zero-trust posture by 2028. Zero trust is not in tension with stewardship; it is stewardship operationalized. Every access request verified, every identity propagated, every query logged.

The organizations that close the accountability gap are not the ones that hire more stewards. They are the ones that give stewards the infrastructure to make their decisions stick at the point where data is actually consumed.