Last updated: October 16, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
AI ownership works when each decision about a model gets one named owner, with product defining a correct answer, data owning what the model learns from, and engineering owning what ships and what rolls back. That split is the core of an AI operating model. Hand the whole model to one team, or to all three at once, and a bad answer can sit in production for days while everyone assumes somebody else has it.
I asked nine people who owned our document classifier. I got five different names. Two of them were mine.
This was on a mortgage-tech platform, and the classifier did something unglamorous and important. Borrowers uploaded whatever they had (W-2s, paystubs, and two months of bank statements photographed on a kitchen counter), and a model sorted each file into the right bucket in the Encompass eFolder so an underwriter did not have to. Engineering had built the service around a hosted large language model. The data team owned the labeled set we tested it against, about 3,400 documents. Product owned the underwriter experience. Everybody had a piece, and on a slide it looked like collaboration.
Then the model alias we called started pointing at a newer snapshot. Nobody on our side changed a line of code. Accuracy on bank statements slid from roughly 96 percent to roughly 88, and for three days about 2,100 documents landed in the wrong folders. Underwriters found it, the way underwriters find everything, by being annoyed. When I went looking for the person who should have caught it, I found a perfectly reasonable answer in every direction I looked. Engineering thought data watched quality. Data thought product decided what “good enough” meant. Product thought engineering would know if anything in the model moved. All three were right about the other two. Nobody was right about themselves.
That week is why I stopped asking “who owns the model?” It is the wrong question. A model is not one thing to own. It is a bundle of separate decisions, and each one needs a single name next to it. If you are staffing these teams, KORE1’s AI and ML engineer staffing desk sees the same pattern from the hiring side, a strong team with nobody holding the specific decision that broke.
The Model Is a Bundle of Decisions
An AI operating model is the written answer to who decides what about an AI system once it is live, covering who defines a correct answer, who changes the prompt or model version, who owns the data underneath, who sets the release bar, and who is allowed to turn it off.
Most companies skip writing that down, and they have an understandable reason. Machine learning systems are tangled in a way ordinary code is not. A group of Google engineers led by D. Sculley described it in “Hidden Technical Debt in Machine Learning Systems” at NIPS 2015. They named it the CACE principle, Changing Anything Changes Everything, and they meant it literally. Touch an input, a threshold, a sampling method, the data selection, and the behavior of the whole system can shift.
Carry that paper into a management meeting and most people draw the wrong conclusion from it. If everything is connected, the thinking goes, then one team should own the entire thing, or all three teams should own it together in a weekly sync. I have watched both. The single owner becomes a bottleneck by the second quarter. The shared version is worse. Shared ownership of a decision just means three people each assume the other two are watching.
The fix is to split the bundle along the decisions people actually make. When I list them for a team, it comes out to about nine. What the feature is for and what a correct answer looks like. Which prompt and retrieval logic it uses. Which base model and version it calls. What data it learns from or reads. The score it has to hit before it ships. Who can roll it back. Who watches for drift. Who else is allowed to consume its output. And when it gets retired. Nine decisions, three teams. Some teams have six, some have twelve. Nobody has one.
Why “Shared Ownership” Fails at 2 A.M.
When I wrote the one-page decision-rights map for general engineering work, I described two ways an unowned decision leaks out. Somebody grabs it, or everybody freezes. AI work does both, often in the same incident.
The grab looks like a data scientist quietly editing a production prompt because the eval numbers looked better in a notebook. Reasonable instinct. Wrong door. That prompt feeds every request the feature serves, and the change skipped the release process engineering built for exactly this reason. The freeze looks like my classifier week. An on-call engineer saw the error rate wobble on day one and did not roll back, because the feature “belonged to product” and rolling back felt like overruling them. He was not timid. He just could not see the edge of his own authority, because nobody had ever drawn it for an AI feature, and the general rule he did know, roll back first and explain after, felt like it belonged to ordinary deploys rather than to a model somebody else had tuned.
Regulators got there before most of us did. On April 17, 2026, three bank regulators (the Fed, the OCC, and the FDIC) jointly put out SR 26-2, the revised guidance on model risk management, replacing SR 11-7 after fifteen years. Its section on roles says sound governance practices “delineate the individual(s) responsible for key activities throughout the model lifecycle, from development through validation and ongoing monitoring.” Individuals. Not a working group. And here is the detail I keep pointing executives toward. A footnote in that same guidance says generative and agentic AI models “are not within the scope” of it, because they are novel and changing fast.
So the newest model-risk guidance in American banking explicitly leaves the LLM question to you. Nobody is going to hand you this map. If you sell into banks, their diligence team will still ask who owns what, sooner than you would like, and “the AI team” is not an answer they will accept.
The NIST AI Risk Management Framework says much the same thing in its Govern function. Govern 2.1 says roles, responsibilities, and lines of communication for managing AI risk should be documented and “clear to individuals and teams throughout the organization.” Clear to the people doing the work, in other words. A RACI that lives in a Confluence page the on-call engineer has never opened does not count.
The Decision-Rights Map, Bent for AI
The general map sorts every call on two questions. Can you undo it, and who does it touch? Undoable and contained, the engineer owns it. Hard to reverse and wide, it goes up. Both axes still apply to AI. Both of them also lie to you a little, and the lies are where the incidents come from.
Reversibility first. A prompt edit is a two-way door in the repository. You can revert it in thirty seconds. It is not a two-way door for the 40,000 answers it may already have sent to customers before anyone noticed. The code walks back. The answers don’t. Training on a customer’s data is the extreme version, closer to a one-way door than almost anything in normal software, because you cannot reliably make a trained model forget what it saw. Retrieval over that same data, where the model reads it at request time, is far easier to reverse. Same data. Very different door.
Blast radius lies in the other direction. An AI feature usually lives in one service, owned by one team, so every change feels local. It almost never is. One prompt serves every user of the feature, and Sculley’s paper calls out a second trap, which it names undeclared consumers, where other systems quietly start reading a model’s output and nobody upstream knows they exist. I have seen a fraud-scoring model’s output feeding a marketing segmentation job that its own team had never heard of. Change the model and you change marketing. Nobody had told them.
So I adjust the second axis. For AI, judge blast radius by who receives the output, not by where the code lives. Here is what that does to the four quadrants.
| Reversible (output can be walked back) | Hard to reverse (output or learning sticks) | |
|---|---|---|
| Output stays internal | The engineer owns it. Tuning a retrieval chunk size for an internal ops assistant. Rolling back to the last good model version. | The owner decides and writes it down. Choosing an embedding model for an internal search index, which means re-embedding everything to undo it. |
| Output reaches customers or other systems | The tech lead owns it and the eval suite is the heads-up. A prompt change on a borrower-facing feature. Accepting a vendor’s new model version. | It goes up. VP or CTO signs. Fine-tuning on customer data. Letting a model’s output touch a decision about someone’s loan, job, or housing. |
Look at where the prompt change landed. Bottom left. Not top left. In the general version of the map that quadrant gets a heads-up to the teams wired into a change. In AI the heads-up is the eval suite, run on every change, because the people affected are customers and you cannot email all of them. If you have not built one, I laid out a thirty-case eval suite that a team can stand up in a week. Without it, every prompt edit is a guess shipped to production with a nice commit message.
Nine AI Decisions and Who Owns Each One
The grid is the concept. What a team actually works from is the rows. This is the table I start from when I sit down with an engineering leader, a head of data, and a product lead, usually in the same room for the first time in months. Every row gets one owner. Not a department. A role, and then a name.
| The decision | Owner | Consulted | Escalates when |
|---|---|---|---|
| What the feature is for and what counts as a correct answer | Product manager | A domain expert (an underwriter, a claims lead) | If the definition changes what a customer is promised |
| The release bar, the eval score it must hit to ship | Product manager sets it, engineering enforces it in CI | Data, on whether the test set can measure it | Any request to ship below the bar |
| Prompt, retrieval, and tool logic | Feature tech lead | Nobody, if the eval suite passes | When the suite fails and someone wants to ship anyway |
| Which base model and version, including vendor upgrades | Engineering lead for the platform | Product on quality, finance on cost per call | Cost per 1,000 calls moves more than 25 percent |
| What data the model learns from or reads at request time | Data lead | Security, privacy counsel | Always, for customer PII or anything used to fine-tune |
| Rolling back or switching it off in production | On-call engineer | Nobody. Ask questions afterward. | It doesn’t. Kill it first, write it up in the morning. |
| Drift monitoring and the retraining trigger | Data lead owns the monitor, engineering owns the pipeline it fires | Product, when drift changes what users see | Two missed alerts in a quarter |
| A new system consuming the model’s output | Tech lead of the producing team | The consuming team, the data lead | If the consumer feeds a regulated decision |
| Retiring the model | Product manager | Every declared consumer | If a consumer cannot migrate before shutdown |
Count the owners. Product holds three rows, engineering holds four, data holds one outright, and the drift row is split on purpose with a line drawn through the middle of it. That split is the only one I allow, and only because the two halves are different decisions. Deciding that the model has drifted is a judgment about data. Running the retrain is a pipeline job. Put both on one person and either the judgment gets made by whoever runs Airflow, or the pipeline gets babysat by someone who would rather be reading distributions.
The release-bar row looks like a split too. It is not. Product owns the number. Engineering owns the gate that refuses to deploy below it, which is code, not a decision. Nobody in engineering gets to lower the number at 5 p.m. on a Friday because the release is late. That is exactly the call that has to come back to the product manager, and it should feel uncomfortable to ask.
Retirement sounds like a footnote. It isn’t. NIST does not treat it as one. Govern 1.7 in the same framework asks for processes for “decommissioning and phasing out AI systems safely.” I have yet to meet a team that planned the end of a model on the day they launched it, mine included, and the undeclared consumers are why that matters. Turn off a model and you find out who was reading it.
The Seam Nobody Owns: Vendor Model Updates
Back to the classifier. Look at which row actually failed. It was not the prompt, not the data, not the release bar. It was row four, which base model and version, and the reason nobody owned it was that nobody on our team had made that decision. The vendor made it for us. Politely, with release notes. We called an alias, the alias moved, and a decision with a customer-sized blast radius happened without anyone in the building choosing it.
This is the one AI decision that has no equivalent in my general map. Somebody outside your org opens a door, and you find out from the draft. NIST’s framework covers it in Govern 6.2, which asks for contingency processes to handle failures or incidents in high-risk third-party data or AI systems. SR 26-2 has a whole section on vendor products and notes that a bank may not receive the underlying code, data, or methodology from the vendor. Fine. You do not need to see under the hood to own the decision of when you start using it.
Here is what the owner of row four does, in practice. Pin a specific model version, never a floating alias, in anything customer-facing. Watch the vendor’s deprecation schedule like it is your own release calendar, because it is. When a new version appears, run the full eval suite against it in a branch, show the results to the product owner of the release bar, and switch only when both of you sign. If the vendor forces a cutover date, the clock starts the day they announce it, not the day it lands.
We did all of that after the bank-statement week. Two sprints, roughly. The next forced upgrade, four months later, scored 1.3 points higher on our test set, cost slightly more per call, and went live on a Tuesday afternoon with nobody paged. Boring. That was the whole point.
If you bought the model instead of building it, this row matters more, not less. I made the broader build vs buy case for AI pilots elsewhere, and the short version applies here. Buying moves the weights to a vendor. It moves none of the other eight decisions. You still own the definition of correct, the release bar, the data you send, the rollback, and the consumers. Companies that buy and assume the vendor owns the rest tend to call me around month nine.
Installing the Map in One Meeting
You do not need a reorg, a steering committee, or a new title. You need about ninety minutes and the three people who currently believe someone else owns the model.
- Pull the last sixty days of real AI decisions out of Slack, Jira, and the incident log. Not hypothetical ones. Prompt edits, a version bump, the threshold argument, the time someone asked for a new data source. Most teams find fifteen to twenty-five.
- Put each one on the two-by-two, using output reach for the blast-radius axis. Argue about the edges. The arguments are the useful part, and they almost always land on a prompt change somebody assumed was local.
- Write one name next to each of the nine rows. If a row gets two names, you have not finished. If it gets zero names, write that down too, in red if you have to.
- Put the table where the on-call engineer will see it at 2 a.m. That means the runbook and the incident channel topic, not a strategy deck.
- Wait for the next incident and check, afterward, whether the named owner made the call. That is the only real test the map ever gets.
Step three is where the meeting gets quiet. Somebody realizes the drift monitor has no owner because the data scientist who set it up left in March, and the alert has been going to a distribution list that now contains exactly one person, who happens to be on parental leave. Somebody else realizes the product manager has never seen the eval scores. Good. Better to find that out in a conference room than during the next bad week in production.
Then keep asking the one question from my general map every time an AI decision comes up, before anyone debates the substance. Whose row is this? After a few weeks the team asks it before you do. I have watched a product lead start arguing about a prompt tweak in a design review and stop herself halfway through the sentence. “That’s the tech lead’s row,” she said, and moved on to the rubric. That is the culture working, and it took one table.
If you want this done in a single structured session with someone who has drawn it for other teams, KORE1’s build vs buy technology advisory engagements often start exactly here, because the build-or-buy decision for an AI feature is really a question about which of these rows you can staff.
When a Row Has No Name
Sometimes step three does not end in a name. It ends in a silence, and the silence is the most useful thing the meeting produced. A row with nobody qualified to own it is not a process problem. It is a hiring problem, and no amount of process will fill it.
The rows that go empty most often are predictable. Three of them, mostly. Drift monitoring goes empty when there is no data lead with production experience, only analysts who built dashboards. Row four goes empty when nobody on the platform side has run model infrastructure before, which is why so many teams end up hiring an MLOps engineer right after their first vendor surprise. The correct-answer row goes empty when the product manager is a generalist who has never had to define accuracy for a probabilistic system, and that is a real skill, the one an experienced AI product manager brings that a strong traditional PM often does not.
KORE1 recruits for these exact seats in 30-plus metros nationwide, and the average IT search takes 17 days to fill, so I have a bias here and I would rather say it out loud. Sometimes the right move is not a hire at all. A senior engineer on a contract engagement can own row four for two quarters while you decide whether the AI portfolio is big enough to justify a permanent platform seat. That is often the honest answer for a company with two or three AI features in production. For the full cost picture of what a live AI feature actually needs, people included, I broke down the line items after the proof of concept.
What Leaders Ask Me About AI Ownership
Doesn’t Hiring a Head of AI Solve This?
A head of AI owns the map, not the rows, and if every row routes to that one person you have built a bottleneck with a better title.
It’s a different job. The work is to make sure each of the nine decisions has a name, to settle the edge cases, and to own the escalation column. Most of the actual calls should still be made by the product manager, the data lead, and the tech lead closest to the feature.
Who Owns the Prompt, Engineering or Product?
Engineering owns the prompt as code, and product owns what the prompt has to achieve, written down as the eval rubric and the release bar.
If a product manager wants different behavior, they change the rubric or the test cases, and the tech lead changes the prompt until the suite passes. That keeps product out of the repository and engineering out of the business of deciding what a good answer is. Each side does the half it is actually qualified to judge. If you are still deciding whether a vendor’s feature is ready at all, my four-gate pilot-to-production checklist is the step before this one.
We Have Forty People. Is This Overkill?
No, but at forty people one person can hold several rows, as long as each row still has exactly one name next to it.
At a startup the CTO might own six of the nine. That is fine. What breaks small companies is not too few people. It is the assumption that because everyone is in the same Slack channel, everyone knows who decides. They don’t. Write the names down anyway. It takes twenty minutes when there are forty of you and about two weeks when there are four hundred.
Who Gets Paged When the Model Is Wrong but Nothing Is Down?
The on-call engineer gets paged once a quality alert crosses the release bar, and product decides the next morning whether “wrong” was really wrong.
Quality incidents are the gap most on-call rotations were never designed for. Latency and error rates page someone automatically. A model that confidently sorts bank statements into the paystub folder returns HTTP 200 every single time. No alarm fires. You need an eval running against live samples, or at minimum a daily sample a human checks, and the alert threshold should be the same release-bar number product already signed. Show me the data on that sample and I can tell you within a week whether the team has a quality problem or a monitoring problem.
Does the Fed’s New Model Risk Guidance Cover Our LLM Features?
Not directly, because SR 26-2 places generative and agentic AI models outside its scope, but bank partners will still ask who owns each decision.
The guidance applies to traditional statistical models and non-generative AI, and it is aimed most squarely at banks above $30 billion in total assets. If your LLM feature touches lending, servicing, or fraud, assume the partner’s diligence questionnaire asks for named owners anyway. The nine-row table is a decent first answer to hand them.
What Happens When Two Owners Disagree?
The row decides, and if the disagreement is about which row a decision belongs to, it escalates once to whoever owns the map.
Most fights I see are not about the decision at all. They are about whether a change counts as a prompt change, engineering’s row, or a definition change, product’s row. Settle that once, add the example to the table, and the same fight does not happen twice.
One Table, Nine Names
The classifier still runs, by the way. Bank statements sort at about 97 percent now, and the last time the vendor shipped a new version, the engineering lead who owns row four had already scored it before I knew it existed. I found out from a two-line message in the channel. That is what ownership looks like when it works. Quiet, specific, and mostly invisible to the person who drew the map.
If you want to argue about the nine rows, or tell me about a tenth decision I missed, connect with me on LinkedIn. And if the table keeps coming back with an empty row, bring the empty row to a KORE1 recruiter before the next vendor upgrade finds it for you.
Related reading: When to Buy and Then Build On Top: The Most Underused AI Pattern in Mortgage Tech.
