The screenshot lands in your incident channel from the head of customer success: your support assistant has told a customer that annual plans refund in full within sixty days, a policy retired two quarters ago. You run this product, so you ask who approved the change, and three people start typing at once. The platform engineer owns the prompt repository and reports no prompt change in a month. The documentation manager owns the help center and notes that her refunds-page rewrite last week was a content edit, not a release. The analyst who owns the eval set reports every refund case still passing, because the cases predate the policy change. Everyone owns a piece of the assistant, every alibi checks out, and the behavior in the screenshot belongs to no one.
The root cause turns up two days later: an archived FAQ from the old pricing era, still sitting in the assistant's retrieval index. The migration that retired the policy never touched that file, because no one's job included knowing what the assistant reads. The lasting fix is one accountable name on every behavior the product exhibits, and this chapter is about writing those names down.
Why "everyone owns it" fails here
In classical software, ownership travels with the code: behavior changes only when someone edits it, and whoever merged answers for the result. Your assistant's behavior has more doors, because all of these move what it says without a deploy:
- The model version. Your provider retires a snapshot or ships an upgrade, and tone, refusals, and reasoning move under your feet.
- The prompts. One added adjective ("be decisive") changes hedging across every conversation at once.
- The knowledge corpus. A help-center edit is a production change, as the archived FAQ just proved.
- The eval set and its pass line. Whatever the set stops covering can regress with every light still green.
- The access rules. A new tool or data scope changes what a wrong answer can reach.
Each door has a different hand on it: the prompts with engineering, the corpus with documentation, the pass line with the analyst, the scopes with security, and the model version with a provider you do not even employ. When every hand can move the behavior and no single name answers for the whole, ownership defaults to the committee, which is the most plausible reading of the slide you watched in Why AI products fail on the org chart, not in the model: quality at Klarna slid for over a year while cost drove the decisions.
If everyone owns the behavior, nobody does: five hands that can each move an answer add up to zero names that must answer for it.
What owning a behavior means
Ownership here is a job with three tests, not a title:
- You can say no. A change to your row does not ship over your objection; it waits for your yes.
- You answer for it. When your row fails in production, the screenshot comes to you, and "I did not make that change" is not an available reply.
- You run the review. You chair the regular look at your row's evidence (the eval trend, corpus changes, incident count) and close it with decisions.
Project managers keep this straight with a RACI chart: for each piece of work, who is Responsible for doing it, Accountable for the result, Consulted before a change, and Informed after. For model behaviors the letter that matters is the A, and every row gets exactly one.
Published frameworks ask for the same thing. NIST's AI Risk Management Framework makes governance one of its four core functions and is blunt about accountability: roles and responsibilities for managing AI risk "are documented and are clear to individuals and teams throughout the organization." Microsoft's Responsible AI Standard, published externally, requires teams to document who is responsible for "troubleshooting, managing, operating, overseeing, and controlling the system" and to secure approvals from designated reviewers before development starts. Microsoft's standard was written for its own teams and NIST's for organizations of any size, but the requirement is one sentence at any scale: write down who answers for this.
Owning a model behavior is the power to say no to a change and the duty to answer when the behavior is wrong.
The owner map, filled in
Here is the map the company in the opening scene, a 200-person SaaS business, drew after the incident. Every row carries one accountable person and a one-line sign-off rule for changes.
| The row | Accountable owner | Sign-off rule for changes |
|---|---|---|
| Behavior spec: what it does, refuses, and sounds like | Mara, product lead | Spec edits ship with Mara's written approval; refusal changes also get a legal read. |
| Prompts | Mara, product lead | A prompt diff ships when the eval set passes and Mara approves the diff. |
| Eval set and quality bar | Ravi, support ops lead | Ravi signs every new case and any move of the pass line. |
| Knowledge corpus | Noor, documentation manager | Adding or retiring a source needs Noor's approval; policy pages also need the policy owner's yes. |
| Access rules: tools and data scopes | Theo, security engineer | Any new tool, scope, or connector waits for Theo's signature. |
| Incident response | Ravi, support ops lead | Ravi declares and runs incidents; Mara signs the postmortem and its follow-ups. |
Every owner is a person, never a team; one person may hold two rows, as Ravi does, but no row holds two people. The sign-off column always names evidence, and the pass line Ravi guards is the one you defined in The quality bar: decide what good means.
Small teams fill the map without hiring
A three-person startup fills the same table without hiring anyone. You hold the spec, the prompts, and the evals; your technical cofounder holds the corpus and the access rules; incidents are yours. The map does not measure headcount, it measures whether any row exists that no finger can land on; a solo founder with their name in every cell is better governed than a fifty-person company with "the AI team" written across the column. Your first hire who touches the assistant takes over a row with its sign-off rule, and the handoff is complete the day they can say no to you.
One owner is not a bottleneck
The strongest objection is speed: a prompt tweak takes a minute to write, routing it through one person's approval looks like a process tax, and a single name reads like a single point of failure when Mara goes on leave. The objection mistakes what the owner does:
- The owner decides; they do not do the work. The map hands them the A, not every R: anyone can propose a prompt diff, draft eval cases, or edit the corpus, and the owner's part is a yes or no at the moment of change.
- Sign-off latency is a budget you set. Give routine rows a service level ("Mara answers prompt-diff requests within one business day; a green eval run with no objection in that window counts as a yes") and keep the hard stop for rows where a wrong change costs real money.
- Owners name deputies, not co-owners. Mara writes her stand-in into the map before leave, so the row always keeps one accountable person.
Try it now
This drill takes about fifteen minutes and turns the ownership inventory you wrote in Why AI products fail on the org chart, not in the model into your own owner map.
Draw the rows. Copy the six rows from the table above into a doc, then add any row your inventory carries that the example lacks (user memory, a fine-tuned model).
Put one name on every row. A real person, your own name where no one else fits. Where you want to write two names, pick one; where you want a team, pick a person on it.
Write the sign-off rule. One line per row in the form "changes ship when [name] approves [evidence]," with evidence you can point to: a passing eval run, a reviewed diff, a legal read.
Mark the unowned cell. Any row where the honest answer is "no one" gets your name and a date to fix it, because that cell is where the next screenshot will come from.
Keep the map in the repo or the runbook rather than a slide, because the release gate you will write in Change control: ship prompt and model changes like releases names its approver from this map.
Chapter Summary
- Your product's behavior changes through several doors at once: the model version, the prompts, the knowledge corpus, the eval pass line, and the access rules.
- Each door usually has a different hand on it, so "the team owns the assistant" leaves every specific behavior unowned.
- If everyone owns the behavior, nobody does; the fix is one accountable name on every row.
- Owning a row means you can say no to a change, you answer when the row fails in production, and you run its regular review.
- NIST's AI Risk Management Framework and Microsoft's Responsible AI Standard both treat documented, accountable roles as a requirement, not a nice-to-have.
- The owner map is six rows (spec, prompts, evals, corpus, access, incidents), each with one name and a one-line sign-off rule.
- Small teams fill the map with hats instead of hires: one person can hold several rows, but a row never has two owners.
- Owners decide rather than do everything, and a sign-off latency budget keeps approval from becoming the slow step.
- With names on the rows, changes can start shipping like releases, which is where Change control: ship prompt and model changes like releases picks up.
Sources
- NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. The GOVERN function; subcategory GOVERN 2.1 on documented roles and responsibilities.
- Microsoft (2022). Responsible AI Standard, v2: General Requirements. Accountability goals A1 (impact assessment approvals) and A5 (documented oversight and control responsibilities).
- Project Management Institute (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition. The responsibility assignment matrix, including the RACI chart.