Who owns an AI system after it ships

Five jobs have to carry a name on the day an AI system goes live. Someone owns what correct means — the definition of a good answer for this workflow, in writing. Someone owns the evaluation set and the authority to change it. Someone is on call for the system being wrong, which is a different pager from the system being down. Someone owns the model relationship: provider releases, deprecations, parameter changes, and the decision to move. And someone signs — accepts the residual risk and can halt the system without convening a committee. Most launches cover all five with one name, and it is whoever built it. That arrangement works until the day they are on leave, and stops working permanently when they change teams.

It is so common because it is invisible while it is working. A newly shipped AI system sits in the hands of the person who understands it best, who reads its outputs out of interest rather than obligation, and who notices a degradation well before any alert would. None of that is in a job description, none of it is budgeted, and none of it survives a reorganisation. The handover artefacts — the repository, the runbook, the credentials — get negotiated hard because they are legible and countable. The five jobs above are the part that actually decides whether the system is still trusted in month nine, and they are usually written down nowhere.

Google's site reliability engineering practice is the most thoroughly documented public answer to the question of who runs a system after it ships, and its central move is to treat ownership as a budget rather than a virtue. "Google places a 50% cap on the aggregate 'ops' work for all SREs—tickets, on-call, manual tasks, etc.," with the rest of the time spent on engineering that reduces the ops load (Google, Site Reliability Engineering, Introduction). The cap exists because unbudgeted operational work expands until it consumes the team, and because a team spending all of its hours reacting never builds the thing that would stop it reacting. The goal that follows is stated just as plainly: "the number of SREs needed to run, maintain, and improve a system scales sublinearly with the size of the system."

The same body of work is specific about load. Because handling an on-call incident end to end takes six hours on average, "the maximum number of incidents per day is 2 per 12-hour on-call shift," and of an engineer's total hours "no more than 25% can be spent on-call, leaving up to another 25% on other types of operational, nonproject work" (Google, Being On-Call). Those numbers do not transfer directly to an AI system — most do not page anybody twice a shift — but the discipline behind them does. Ownership that is not costed in hours is not ownership; it is an assumption about somebody's evenings. So the first question to ask about a proposed owner is not whether they are senior enough. It is what comes off their plate.

An AI system is also watching for a different kind of failure, which is why the rotation cannot simply be added to the existing one. Conventional on-call responds to something that stopped: an error rate, a queue depth, a page that will not load. A system that is wrong rather than down raises no exception at all. It returns a confident answer somebody acts on, and every signal is second-order — escalation rates, reopen rates, the pass rate on the scheduled evaluation run, a support queue that starts mentioning the same thing twice. Someone has to be accountable for those the way an SRE is accountable for latency, which means a dashboard, a threshold, and the standing to stop a release. The same book warns that engineers who go too long without touching production lose their feel for it, recommending "every engineer to be on-call at least once or twice a quarter". The AI equivalent is reading real outputs on a schedule rather than reading the dashboard about them.

That is also where the argument about whether the system is good enough gets settled in advance instead of during every incident. The SRE vocabulary is worth adopting wholesale here, because the three terms are genuinely distinct and most teams collapse them into one. A service level indicator is "a carefully defined quantitative measure of some aspect of the level of service that is provided". A service level objective is "a target value or range of values for a service level that is measured by an SLI". A service level agreement is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain" (Google, Service Level Objectives). An AI system needs at least one correctness indicator with a stated objective, agreed between the person who owns what correct means and the person who signs. Without one, every incident reopens the question, and it gets answered by whoever is most senior in the room that day.

The same chapter carries a warning that lands harder on an AI system than on a web server: "If your service's actual performance is much better than its stated SLO, users will come to rely on its current performance." A system running at an unusually high accuracy through its careful first quarter teaches everybody around it to trust it at that level, including the people who quietly stop checking. When it settles to its real steady state nothing breaks, no alert fires, and the trust does not adjust downward on its own. Stating the objective out loud, and reporting against it on a fixed cadence, is what keeps the organisation's expectations attached to a measurement rather than to a memory of the launch.

None of this is only an engineering arrangement, which is what decides where it sits on an org chart. The US Government Accountability Office's accountability framework for AI "is organized around four complementary principles, which address governance, data, performance, and monitoring", and its stated objective was to identify practices for entities "involved in the design, development, deployment, and continuous monitoring of AI systems" (US Government Accountability Office, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities, GAO-21-519SP, June 2021). Monitoring sits there as a principle, not as a task — which is to say it belongs to somebody with a budget rather than to a volunteer with a good memory. The framework also notes that "Third-party assessments and audits are important to achieving these goals", and a third-party assessment needs a first party to receive it, act on it, and answer for what it finds.

There is no published occupation called AI system owner, which is worth saying plainly because it explains why the job keeps landing on whoever is nearest. The US Bureau of Labor Statistics describes computer and information systems managers as people who "plan, coordinate, and direct computer-related activities in an organization" and who "help determine the IT goals of an organization and are responsible for implementing computer systems to meet those goals" — 685,800 jobs in 2025, a median annual wage of $175,140 in May 2025, and projected growth of 16% from 2025 to 2035 (US Bureau of Labor Statistics, Computer and Information Systems Managers, Occupational Outlook Handbook). That is the chair the five jobs usually end up in, and it is a reasonable chair. It becomes a problem only when nobody says so out loud, because a responsibility that arrives by default arrives with no time, no budget and no authority attached to it.

What each of the five owners actually needs is short enough to fit on a launch checklist. The owner of correct needs the authority to change the definition and a standing slot with the people doing the work, because the definition drifts as the workflow does. The owner of the evaluation set needs it version-controlled, and needs new failure cases added as routine rather than as incident follow-up. The on-call owner needs a threshold, a dashboard, and the right to halt a release. The model owner needs the provider's deprecation notices arriving somewhere a human reads, and a tested path to an alternative — model drift, and what changes underneath your AI system is the long version of why that one is not optional. And the signer needs the other four reporting on a fixed cadence, monthly being usually enough, plus the organisational standing to turn the system off. Four of the five can be part-time roles. None of them can be nobody.

Two of these belong in the contract when an outside firm built the system, and they are the two most often missed, because the handover list tends to concentrate on artefacts rather than duties. Who runs the evaluation suite once the engagement ends, and on whose schedule? And who is the named human at the vendor on the day a provider changes the model, with a response time written down rather than implied? A platform consolidation we ran for Cove, a US home-security device ecosystem, is roughly the shape of the answer: three disconnected systems rebuilt into a single operator experience with blue/green deploys and full observability, delivered as 24 months of continuous delivery rather than as a handoff. Their product lead described the arrangement as a team that "runs like an extension of our engineering org — weekly delivery, transparent metrics, real ownership". Continuous delivery is only available to an organisation where somebody is continuously answerable.

The test for whether any of this is real takes thirty seconds at a launch review: name the five people. Not the teams — the people. If the same name comes back more than twice, the system has one owner and four assumptions, and the assumptions get discovered one at a time, each one during an incident. Evaluation and observability is the part of this that can be built rather than assigned, and building it is what makes the other four jobs small enough for a real person to hold alongside their actual work. The enterprise AI solutions still trusted in month nine are not the ones with the best model underneath them. They are the ones where five names were written down before launch, and somebody checked in month three that all five were still accurate.