AI Ownership Boundaries Across Data and Platform

A fictional online home-goods retailer scores every refund request with a model. Requests above a threshold are held for manual review before money is released; the rest are paid immediately. The retailer receives about 6,000 refund requests a day, and the model normally holds 3.0 percent of them, which is 180 requests. Five reviewers each clear about 40 held requests a day, so the review queue has a capacity of 200. The promise to customers is a refund within two business days.

On a Tuesday morning the customer-data team changes the meaning of one field. account_age_days used to count days since the account was created; to fix a defect in the loyalty program, it now counts days since the account was last reactivated. The field keeps its name and its type, and every automated check passes. The refund model had learned that old accounts are trustworthy, and it now sees many long-standing customers as new. By afternoon it holds 9.5 percent of requests, which is 570 a day. The review queue grows by 370 requests a day, because reviewers can clear only 200.

A drift alert posts to the machine learning team’s shared channel on Tuesday afternoon, and the model owner sees it on Wednesday. She finds nothing wrong with the model and asks the data team, who point out that the loyalty team approved the change and that the field’s type did not change. The platform team reports that every pipeline is healthy. The application team reports that the review queue works as designed. The head of customer operations first hears of the problem from complaints on Wednesday. She asks who can turn the hold policy off, and the answer is a debate: the model owner thinks it is her call, the application team holds the switch but needs a formal request, and the data team believes nobody should touch the model until the field is understood. The hold policy is switched to a fallback rule on Friday morning, 72 hours after the change. By then the backlog stands at 1,110 requests, and with only 20 requests a day of spare review capacity (200 minus the normal 180), clearing it would take 55.5 days. Clearing it in five days would take about 222 additional reviews a day, the output of nearly six more reviewers.

Every team in this story did its job, and each could show that its component worked. What no one held was the decision that mattered: whether the process should keep acting on the model’s output. The questions are how to divide ownership among the business process, the application, the model, the data, and the platform; what the owners promise one another; who may act during an incident; and where cross-team disagreements go. Earlier posts cover operating models and decision structure, data products and domain ownership, model ownership after launch, and the boundary of an internal platform.

Five owners and what each one decides

An AI-supported process is a chain: source data feeds a data product, the data product feeds a model, the model’s score is used by an application, and the application carries out a business process, all running on shared platform capabilities. Each link has an owner, and the roles differ in what they decide rather than in what they build. A decision right is the authority to settle a defined class of question within a stated scope, with a limit and an escalation route; ownership means holding such rights and the resources to use them. The table sets the five roles side by side in the refund example.

Owner	Decides	Promises the next owner	Depends on
Business process owner (head of customer operations)	The purpose and policy of the process, the acceptable balance between fraud loss and wrongly held customers, when to suspend automation, and risk acceptance within delegated tolerance	Refund timeliness and loss targets to customers and executives	Contracts with the application, model, and data owners
Application owner (refund workflow)	How and where the score is used, release timing, the controls around actions, and the mechanics of fallback	That policy settings take effect, that a fallback works, and that the queue and audit trail are reliable	The model’s score contract and the platform’s runtime
Model owner	Evaluation protocol, threshold proposals, retraining, promotion under policy, and investigation of quality problems	What a score means, the population and period it was evaluated on, the model version attached to each score, and a response when quality falls	The data contract for every input and the platform’s serving
Data owner (customer data)	What each field means, who may use it, quality targets, and approval of changes to meaning	Field definitions, freshness, and notice before a change that could alter what consumers compute	The source systems that produce the raw facts
Platform owner	What the shared pipelines, serving runtime, orchestration, observability, and identity services support, and how they are upgraded and retired	Availability, latency, support routes, and a change policy	Cloud and vendor services under contract

The business process owner is the only role whose success is measured in the process’s outcome, which is why that role normally decides when automation is suspended; the others hold decisions about a component. The owner, steward, and custodian split still applies inside the data role: someone decides what a field means, someone keeps its meaning straight in daily work, and someone operates the storage. One person or team can hold several of the five roles. The customer-data team in the example is both data owner and, for its own reports, a consumer. What matters is that each decision class has one holder who has the information, the authority, and the capacity to act, and that the holder’s absence has a named cover. A responsible and accountable split helps here: the data engineer who ships a field change is responsible for doing it correctly, while the data owner is accountable for whether it should happen and what it affects.

The roles also come from public guidance on AI risk. The NIST AI Risk Management Framework asks that roles, responsibilities, and lines of communication for mapping, measuring, and managing AI risks be documented and clear to the people involved, that executive leadership take responsibility for decisions about AI risk, and that development be separated from testing so that course correction can be independent. The last point matters for a small team: if one person is both model owner and the person who evaluates the model, the evaluation needs a second reviewer or a different reporting line.

Boundaries sit where one owner’s change becomes another’s input

The refund incident began at a boundary. The data owner changed a field in a way that was legitimate for the loyalty program and invisible to the type system, and the consequence appeared two links downstream. Every boundary in the chain has this property: whatever an upstream owner changes, a downstream owner inherits without having decided anything. A service contract between adjacent owners is the written answer to what the downstream owner may rely on.

A data contract covers meaning as well as structure, which is the part the refund incident exposed. The Open Data Contract Standard, an open specification for describing such contracts, organizes them into sections that include schema, quality, authoritative definitions, service-level properties, support and communication channels, and roles. In the refund example, a contract for account_age_days would state the starting event that the count measures, the update schedule, and how a change to that definition is announced. A definition change should be treated as a breaking change even when the type is unchanged, because the question is whether anything a consumer computed from the field will now mean something else. A common way to carry such a change safely is to publish the new meaning under a new field name while the old one continues, and to retire the old one after consumers have moved.

The consumer has obligations too. The data owner cannot warn teams it does not know about, so each model owner declares the fields its model uses, and the declaration goes where the data owner can find it. The consumer also decides what to do when the contract is broken: a model owner who monitors input distributions needs a staffed route for the alert and a decision about what the application should do until the cause is clear. The earlier post on model ownership describes an alert that nobody read; the contract is where the acknowledgment deadline and the escalation path are written down.

Contracts at the other boundaries have the same shape with different content. From the model owner to the application owner, the contract says what the score estimates and for which population, which version produced it, what is returned when an input is missing, and what latency to expect; a model card is a natural home for the first part. From the application owner to the process owner, it says which policy settings exist, what each one does, and how quickly a change takes effect. The platform contract, covered in golden paths and the platform contract, states support hours, response routes, upgrade and deprecation policy, and what the platform does not promise. A platform can promise that a pipeline runs on schedule and that a serving endpoint answers within a stated time. It cannot promise that the data flowing through is meaningful or that the model is right, and the platform owner should say so in the contract, since each of those belongs to another role.

Inside a company, an objective with a response expectation is usually enough; an agreement with consequences is more than most internal boundaries need. Consequences can be operational: a breach of the data contract moves the data owner’s fix ahead of new work, and a breach by a consumer, such as an undeclared dependency, means it carries the cost of discovering it.

Per-owner targets also do not add up to a process target. Suppose the data pipeline, the shared platform, the model service, and the application each commit to 99.5 percent availability over a 30-day month, which is 720 hours. Each may be unavailable for 3.6 hours. If the four outages never overlap, the process can be down for 14.4 hours, or 2.0 percent of the month; if the failures are independent, the chain’s availability is 0.995 to the fourth power, 98.01 percent, which is about 14.3 hours. Only if the outages coincide exactly does the process lose just 3.6 hours. Google’s SRE workbook cautions that systems that appear independent often share dependencies and fail together, so the independence assumption cannot be taken for granted. The consequence for ownership is that the process owner needs an end-to-end target of her own, and the application owner needs a fallback so that an unavailable score does not become an unavailable refund process. Without a fallback, the component targets are promises to nobody in particular.

The incident owner is not the component owner

In the refund incident, five component owners investigated five components, and all five were healthy. The failure was in the interaction, and the incident record had no owner for the statement that the process was producing wrong holds. Google’s SRE book describes incidents in which unclear roles led responders to freelance, make uncoordinated changes, and fail to inform one another. Its remedy is an explicit incident commander who structures the response, assigns roles, and delegates only what needs delegating, and an operations lead who is the only group changing the system. The incident commander role and the incident practices in Fly the Airplane First cover how that works in a response. The ownership question is who fills those roles for an AI-supported process and who may order containment.

The cleanest assignment puts the incident under the process owner or a delegate of the process owner, with the component owners as responders. The harm is a process outcome, so severity should be declared from process measures such as hold rate against baseline and the age of the oldest held request, not from component health. A data change that passes every pipeline check and doubles the hold rate is a severe incident under the first measure and no incident at all under the second.

The second assignment is the power to contain. Containment stops the harm from growing while the cause is still unknown, and it must not wait for a diagnosis. Waiting is expensive: in the refund example, each day adds 370 requests to the backlog, and the backlog is paid for in reviewer time over many weeks. The ownership map therefore needs a short list of pre-authorized containment actions for each AI-supported process, agreed in advance by the process owner, with the conditions and limits stated. The numbers below are illustrative.

Containment action	Who may trigger it without further approval	Trigger	Limit
Switch the process to the fallback rule	On-call application owner	Hold rate above twice baseline for two hours, or oldest held request beyond a set age	48 hours, then the process owner renews or ends it
Freeze model retraining and promotion	Model owner	Any suspected change in an input	Until the data owner confirms the input is unchanged
Pin or revert a data field to its previous definition	Data owner or on-call platform engineer, with notice to consumers	Evidence that a definition change is the cause	Until the owner and the affected consumers agree on a migration

The fallback rule is a risk decision made in advance, in calm conditions. It may let through a few requests the model would have caught, and a person has to accept that exposure. Writing the acceptance down, with its duration, lets the on-call application owner act at three in the afternoon without asking for permission from someone who may be unreachable. With these actions in place, suppose the drift alert is acknowledged within two hours of the change and the fallback begins at six hours. The backlog is then 370 times 6/24, which is 92.5 requests, and clearing it takes 92.5 divided by 20, about 4.6 days with no extra staff, or about 2.3 reviewer-days of additional work. The same incident under unclear authority produced 1,110 requests. The difference is not faster diagnosis; the diagnosis need not be any quicker. It comes from who could decide to stop the harm.

After containment, the work moves to eradication and recovery, and ownership follows the cause. The data owner restores a stable field definition or publishes the new one under a new name, the model owner decides whether the model must be retrained or the threshold changed, and the application owner confirms the fallback is reversible. The SRE workbook’s postmortem guidance gives every action item an owner and a priority, because items without them tend to stay open. One question deserves a decision in advance rather than in the post-incident meeting: who pays for the extra review hours? Reviewers’ time lands on customer operations, but the cause was in customer data. If cost allocation is argued case by case, each incident adds a dispute to the cleanup. A rule agreed ahead of time, such as charging incident-driven rework to the owner whose change broke a contract, gives the data owner a reason to treat the contract seriously.

A model supplied by an outside provider follows the same pattern. The provider’s version policy is a contract with the company, and an unannounced behavior change is a boundary change like the field redefinition. The internal model owner remains the owner of the integration: what is evaluated before a version is adopted, which version is pinned, and what happens when the provider deprecates it. Responsibility for the complete workflow does not pass to the supplier because a component was bought.

Cross-team decisions and escalation

Most decisions need no escalation. Some need the consent of an adjacent owner, and a smaller number can only be resolved above the owners involved. Sorting decisions into those classes keeps the senior forum from becoming the council that decides nothing.

A decision that stays inside one owner’s rights is decided and recorded: the model owner picks the retraining schedule, the platform owner schedules an upgrade within its change policy. A decision that changes what another owner receives is governed by the contract. The loyalty change should have required notice to every declared consumer of the field and an impact check before release, and for consumers whose processes act on customers or money, the data owner should have needed their acknowledgment instead of silence. A decision where owners each hold part of the answer needs a named tie-breaker chosen by the kind of question. Questions about the process outcome go to the process owner. Questions about shared infrastructure priorities go to the platform owner within its mandate. Risk beyond the delegated tolerance goes to the executive or risk body that holds that authority; NIST’s framework puts decisions about AI risk with executive leadership, and a governance body with a written mandate is the usual form.

Escalation also needs a clock. A path with names but no deadlines lets an unresolved question wait indefinitely. For a cross-team dispute, a sequence might allow two business days for the owners to settle it directly, two more for their directors, and then the next sitting of the decision forum, which meets weekly and so adds up to five business days. The worst case is then 2 plus 2 plus 5, or nine business days, and everyone knows that bound. Without it, the wait has no bound at all. Measure the result as decision latency, from the moment a ready proposal is submitted until the decision is communicated. Escalate the decision, with its options and the cost of delay stated, rather than escalating a complaint about another team. Record the outcome where the next person facing the same question can find it.

For a change that crosses boundaries, a data owner’s decision to change a definition can follow this order: classify the change by its effect on consumers, check the declared consumer list, give the notice period the contract specifies, publish both meanings during the transition, and escalate only if a consumer objects and the two owners cannot agree within their first clock. The reason to put this in writing is not tidiness; it replaces a negotiation held under pressure with a procedure held in advance.

Several trade-offs shape how far to take this. First, the full structure belongs to processes where a model’s output triggers actions affecting customers or money. A dashboard that summarizes yesterday’s refunds does not need five named owners and four contracts, and applying them everywhere would produce paperwork that people stop reading. Second, too many forums reproduce the problem the map was meant to solve. Third, contracts have a maintenance cost. Begin with the boundaries that have already failed, and add others as changes cross them.

The structure can be tested before an incident forces the test. Replay the refund story with the actual teams: a field’s meaning changes on a Tuesday, an alert fires, and the exercise asks who is on call, who declares the incident, who may switch the process to its fallback, and who is told. Wherever participants disagree, the map has a gap. Measures worth following include the share of AI-supported processes in an inventory that have all five roles named, taking the denominator from a source outside the catalog; time from first signal to containment; the share of cross-boundary changes announced before release; and decision latency on escalated questions. These measures show whether the arrangement is used, but they do not show whether the owners are making good decisions, which needs a review of the decisions themselves.

In the fictional retailer, the head of customer operations becomes the incident owner for the refund process, the application team keeps a documented fallback switch with a bounded authority to use it, the data owner publishes definition changes under new field names, and every model declares its inputs. None of this prevents the next surprise. It determines whether the next surprise costs six hours or three days.

References

• NIST AI RMF Playbook, Govern function (roles and responsibilities, executive accountability, independent testing).
• Google SRE Book, Managing Incidents.
• Google SRE Workbook, Implementing SLOs (dependencies and shared failure domains).
• Google SRE Workbook, Postmortem Culture: Learning from Failure.
• Bitol, Open Data Contract Standard.
• Zhamak Dehghani, Data Mesh Principles and Logical Architecture, martinfowler.com.