AI Operating Model: Ownership, Risk, Delivery, Control

Q: How do we handle a system that changes risk tier after it ships?

The tier is re confirmed at every review, and a change in scope, data, or use can trigger a re tiering. When a system moves to a higher tier, the new controls kick in immediately — the system is paused if it cannot meet them, and it is brought up to standard before it resumes. When a system moves to a lower tier, the controls are relaxed to match. The key is that re tiering is a normal part of the model, not a failure. It is the matrix staying honest as the system evolves. The control pillar& 39;s review cadence is what catches the drift that would otherwise leave a system running at the wrong tier.

Every company now has an AI story. Most of them are lies.

Not malicious lies. Structural ones. A team here built a chatbot. Another team there wired a copilot into the CRM. Someone in finance ran a pilot on invoice extraction and it "worked." Leadership points at all of it and calls it an AI strategy. It is not a strategy. It is a pile of pilots with no owner, no risk discipline, no delivery bar, and no control loop. It is a collection of experiments that happen to share a vendor.

This article is the field guide for the person who has been told to "get AI organized" and has realized that the problem is not the technology. The problem is that there is no operating model. You are not building a model. You are building the machine that decides which models get built, who owns them, how much risk they are allowed to carry, what "done" means, and who can stop them.

We are going to build that machine. Four pillars. One inventory. One governance layer that sits above the operating layer and does not pretend to be it. And a risk tiering matrix you can actually use on a Tuesday, not a framework you present at a board offsite and never touch again.

Let me be blunt about what this is not. This is not a governance checklist you file away. This is not a RACI template you fill out once and forget. This is an operating model — the thing that runs every day, that assigns a human name to every model, that tiers every use case by the damage it can do, that defines what shipped means, and that gives someone the authority to say no. If you build it right, it is boring. Boring is the goal. Boring means it is working.

Why a Collection of Pilots Is Not an Operating Model

Let's start with the most expensive misconception in enterprise AI: the belief that momentum equals strategy. A company with forty pilots running across six departments looks like it is ahead. It is not ahead. It is running forty uncoordinated bets with no shared risk language, no shared delivery bar, and no single person accountable for any of them.

A pilot is a question. An operating model is a system for answering questions and then deciding what to do with the answers. The difference is not subtle. It is the difference between a science fair and a laboratory.

Here is what a pile of pilots actually produces:

No owner. When a pilot fails, nobody is accountable, because nobody was ever assigned. When it succeeds, everybody claims it. The model drifts into production with no named human responsible for its behavior, its cost, or its retirement. That is not a governance gap. That is a governance vacuum, and vacuums get filled by whoever shouts loudest.

No risk language. One team treats a customer-facing recommendation engine as low risk because "it's just suggestions." Another team treats an internal document summarizer as high risk because legal is nervous. Neither team can talk to the other, because they do not share a vocabulary for what risk means. The result is that risk is decided by personality and politics, not by a standard.

No delivery bar. Every pilot defines "done" differently. One team ships when the model hits 90% accuracy on a test set. Another ships when the demo looks good in a meeting. Another ships because the vendor's sales rep said it was ready. There is no shared definition of what "ready for production" means, so there is no way to say no to any of them.

No control. Nobody can answer the simplest question in the company: how many AI systems are running right now, who owns each one, and what would happen if one of them failed? The inventory does not exist, so control is impossible. You cannot govern what you cannot count.

The uncomfortable truth is that a pile of pilots is not a precursor to an operating model. It is often the thing that prevents one. Every pilot has a champion, and every champion has a reason their project should be exempt from the rules. The operating model is the thing that says no to all of them at once, uniformly, without exception.

So the first job is not to build more. The first job is to stop pretending that more is the strategy. The strategy is the system. The pilots are inputs to the system, not the system itself.

The Four Pillars

An AI operating model rests on four pillars. They are not optional, they are not sequential, and they are not a menu. You need all four, and you need them wired together so that each one feeds the others.

Pillar 1 — Ownership. Every AI system has exactly one named human who is accountable for it. Not a team. Not a committee. Not "the AI group." One person. This is the foundation, because every other pillar depends on being able to point at a human and ask them a question.

Pillar 2 — Risk Tiering. Every use case is classified by the damage it can do, before it is built and again before it ships. The tier determines how much scrutiny, testing, and control the system requires. Risk tiering is what turns "this feels risky" into "this is Tier 2, and Tier 2 requires these five things."

Pillar 3 — Delivery Standards. Every system that ships meets a defined bar for what "done" means: what was tested, what was measured, what was documented, and who signed off. The delivery standard is the gate between "pilot" and "production," and it is the same gate for everyone.

Pillar 4 — Control. There is a live inventory of every AI system, a mechanism to review it on a schedule, and the authority to change, pause, or retire a system that no longer meets the bar. Control is the loop that closes the model. Without it, the other three pillars decay.

Here is the part people miss: these four pillars are not a governance framework that sits in a document. They are a set of operating rhythms that run on a calendar. Ownership is a roster that gets reviewed. Risk tiering is a classification that happens at intake and again at release. Delivery standards are a checklist that gates every release. Control is a review cadence that runs monthly, quarterly, and annually. If it is not on a calendar, it is not an operating model. It is a slide deck.

Let's build each pillar properly.

Pillar 1: Ownership with RACI

Ownership is the pillar everyone claims to have and almost nobody actually has. The reason is that most companies confuse "involvement" with "ownership." A model has a data scientist who built it, a product manager who requested it, a legal reviewer who cleared it, and an IT person who deployed it. That is four people who are all "involved." It is zero people who are accountable.

The fix is a RACI that is brutally specific about the difference between the roles, and a rule that every AI system has exactly one Accountable person.

Let me define the roles the way they actually work in an operating model, not the way they work in a training deck.

Responsible (R) — the person who does the work. For an AI system, this is typically the engineer or data scientist who builds, tunes, and maintains the model. There can be several Responsible people on a system, but they all report up to the single Accountable owner.

Accountable (A) — the single person who owns the outcome. They answer for the system's behavior, its cost, its compliance, and its retirement. They can delegate the work (the R's) but they cannot delegate the accountability. This is the person you call at 2 a.m. when the model does something wrong. If you cannot name that person, the system does not have an owner.

Consulted (C) — people who are asked for input before a decision. For AI systems, this is typically legal, security, compliance, and the business owner of the process the model touches. They are consulted, they give input, and then the Accountable person decides. Being Consulted is not a veto. It is a voice.

Informed (I) — people who are told after the fact. This is usually the broader organization, the board, or downstream teams that need to know a system exists or changed. They are informed, not consulted, because their input is not needed to make the decision.

The single most common failure is that companies put legal or compliance in the Accountable box because "they're the ones who care about risk." That is wrong. Legal and compliance are Consulted. They advise. They do not own the outcome of a business system. If legal owns the model, then nobody owns the business result, and the model will be optimized for legal comfort rather than business value. The Accountable owner is a business person — the person whose process the model touches, whose budget it consumes, and whose results it changes.

Here is the ownership rule that makes the whole pillar work: one system, one Accountable owner, and the owner's name is on the inventory. Not a role. Not a title. A name. When the inventory lists "Owner: Director of Claims Operations," that is a role, and roles are fungible. When it lists "Owner: Maria Delgado," that is a person, and people can be held accountable. The difference is the entire point.

The RACI for a typical AI system looks like this:

Activity	Accountable (A)	Responsible (R)	Consulted (C)	Informed (I)
Define the use case and success criteria	Business owner	Product manager	Legal, Compliance	Dept leadership
Build and tune the model	Business owner	Data scientist / engineer	Security	—
Risk tiering classification	Business owner	Risk lead	Legal, Compliance	—
Security and privacy review	Business owner	Security engineer	Legal	—
Release decision	Business owner	Delivery lead	Legal, Compliance, Security	Dept leadership
Ongoing monitoring and cost	Business owner	Engineer	—	Finance
Retirement decision	Business owner	Engineer	Legal	Dept leadership

Notice what is consistent: the Accountable column has one name in every row — the business owner. Everything else moves. That is the discipline. The Accountable person does not do all the work. They own all the outcomes.

One more rule: ownership is not permanent, but it is always assigned. When the owner leaves, the system does not become ownerless. It gets a new owner on the day the old one leaves, not the day someone notices. An ownerless system is a Tier 1 incident in waiting, and the control pillar treats it that way.

Pillar 2: Risk Tiering

Risk tiering is the pillar that turns fear into process. The goal is not to eliminate risk — that is impossible and would kill all value. The goal is to classify every use case by the damage it can do, and to scale the scrutiny to match the damage. A model that suggests a product to a shopper does not get the same review as a model that decides whether a claim gets paid. Treating them the same is either reckless (for the high-risk one) or wasteful (for the low-risk one). Risk tiering fixes both.

The classification happens at two points: at intake, when a use case is proposed, and again at release, when the system is about to ship. The intake tier is provisional — it tells you how much work the build requires. The release tier is final — it tells you what gate the system must pass. A system can move between tiers as you learn more about it. That is not a failure of the system. That is the system working.

Here is the risk tiering matrix. It is deliberately simple, because a matrix you can apply in a meeting is worth more than a matrix that is theoretically complete.

Tier	Definition	Examples	Required controls
Tier 1 — Low	Errors are cheap, reversible, and visible to a human who can override. No regulated data. No material financial or safety impact.	Product recommendations, internal document search, meeting summarization, code autocomplete	Named owner, basic testing, documented in inventory, annual review
Tier 2 — Moderate	Errors are costly or hard to reverse, but a human reviews the output before it acts. May touch sensitive data.	Invoice extraction with human approval, customer support triage, underwriting assistance, draft contracts for review	All Tier 1 controls, plus: security review, bias check, human-in-the-loop requirement, quarterly review, rollback plan
Tier 3 — High	Errors cause material financial, legal, safety, or reputational harm. Output acts without meaningful human review, or touches highly regulated domains.	Automated claim decisions, credit decisions, hiring decisions, medical triage, autonomous actions on customer accounts	All Tier 2 controls, plus: legal and compliance sign-off, independent validation, audit trail, incident response plan, monthly review, executive escalation path

The matrix is the shared risk language. When a team says "this is Tier 2," every other team in the company knows exactly what that means — what controls are required, what review cadence applies, what the release gate looks like. That is the entire value. Risk stops being a personality and becomes a standard.

Two rules make the matrix work.

Rule one: the tier is set by the worst-case damage, not the expected case. A model that will usually be right but occasionally makes an irreversible, high-damage error is Tier 3, even if its accuracy is excellent. The tier is about what happens when it fails, not how often it fails. Teams that set tiers by expected performance are gaming the system, and the control pillar exists to catch them.

Rule two: the human-in-the-loop requirement is a tier property, not a design choice. Tier 2 requires a human to review before the output acts. Tier 3 does not get to add a human review and call itself Tier 2 — if the output acts autonomously on high-damage decisions, it is Tier 3, full stop. The presence of a human reviewer is a mitigation that can lower the effective risk, but only if the human genuinely reviews and genuinely can override. A human who rubber-stamps a queue of decisions is not a control. They are a liability.

The risk tiering matrix is the second pillar, and it is the one that most directly connects to the governance layer, because the tier determines which decisions get escalated and who has the authority to approve them. We will come back to that.

Pillar 3: Delivery Standards

Delivery standards are the gate between "pilot" and "production." They are the answer to the question every company asks too late: what does "done" mean? Without a shared answer, "done" means whatever the most persuasive team says it means, and the most persuasive team is usually the one that has spent the most money.

The delivery standard is not a quality bar for the model's accuracy. It is a bar for the system's readiness. A model can be 99% accurate and still not be ready for production, because it has no owner, no monitoring, no rollback plan, and no documentation. The delivery standard is what catches those gaps.

Here is the delivery gate. Every system must pass all of these before it ships. No exceptions, no "we'll fix it in production" — that phrase is how models become incidents.

1. Named owner. The inventory lists a specific human as Accountable. If there is no name, the system does not ship. This is non-negotiable and it is the first check, because everything else depends on it.

2. Risk tier confirmed. The release tier is confirmed and documented. The controls required by that tier are in place. If the system is Tier 3, the legal and compliance sign-offs are on file.

3. Tested against a defined baseline. The system was tested against a documented baseline — not just "it works in the demo." What was tested, what the pass criteria were, and what the results were. The baseline is set before the test, not after, because a baseline set after the fact is a rationalization.

4. Failure behavior defined. Someone can answer: what does the system do when it fails, and what do we do? Is there a fallback? A rollback? A human override? A degradation path? If the answer is "we don't know," the system does not ship.

5. Monitoring in place. The system has defined metrics that are being watched — accuracy, drift, cost, error rate, latency. If you cannot measure it in production, you cannot control it, and you cannot ship what you cannot control.

6. Documentation written. The system is documented: what it does, what it is for, who owns it, what its limits are, how to roll it back. Documentation is not a compliance chore. It is the only thing that lets the next owner take over when the current one leaves.

7. Sign-off recorded. The release decision is recorded with the names of the people who approved it. This is not about blame. It is about making the decision visible and auditable, so that the decision to ship is a real decision made by named humans, not an accident.

The delivery standard is the same for everyone. That is the point. A Tier 1 system and a Tier 3 system both pass the same seven gates — the difference is that the Tier 3 system has more required controls inside those gates. The gate is uniform; the scrutiny scales with the tier. That is how you get consistency without bureaucracy.

One more thing about delivery standards: they apply to changes, not just new systems. A model that is retrained, a prompt that is changed, a data source that is swapped — these are changes, and changes can break things. The delivery standard for a change is lighter than for a new system, but it is not zero. A change to a Tier 3 system gets a full re-review. A change to a Tier 1 system gets a lighter check. The rule is: no change ships without a named owner confirming it still meets the bar.

Pillar 4: Control

Control is the pillar that closes the loop, and it is the one most companies skip because it is the least glamorous. Ownership, risk tiering, and delivery standards are all about getting systems in. Control is about keeping them honest after they are in. It is the difference between a system that is governed and a system that was governed once, at launch, and has been drifting ever since.

Control has three parts: the inventory, the review cadence, and the authority to act.

The inventory. This is the single source of truth for every AI system in the company. It is not a spreadsheet someone updates when they remember. It is a live record that is updated as part of the delivery process — a system enters the inventory when it ships, and it is updated when it changes. The inventory is the answer to the question "how many AI systems are running right now, and who owns each one?" If you cannot answer that question from a single record, you do not have control. You have a rumor.

The inventory fields are minimal but complete: system name, owner (a name), risk tier, what it does, what data it touches, when it was last reviewed, and its status (active, paused, retiring). That is it. Seven fields. If the inventory has more fields than that, it will not be maintained, and an unmaintained inventory is worse than no inventory because it gives the illusion of control.

The review cadence. Every system is reviewed on a schedule that matches its tier. Tier 1 systems get an annual review. Tier 2 systems get a quarterly review. Tier 3 systems get a monthly review. The review asks the same questions every time: Is the owner still correct? Is the tier still correct? Is the system still meeting its delivery bar? Is it still delivering the value it was built for? Is it still worth its cost? The review is not a formality. It is the mechanism that catches drift — the model that has quietly degraded, the use case that has expanded beyond its tier, the owner who left and was never replaced.

The authority to act. Control is meaningless without the power to change, pause, or retire a system. The control pillar gives a named person or body the authority to say: this system no longer meets the bar, so it is paused until it does, or it is retired. This is the hardest part of control, because it means saying no to something that someone built and cares about. But without the authority to act, the review cadence is theater, and the inventory is a museum.

The control pillar is also where the governance layer connects to the operating layer, which is the next section. Control is the operating rhythm. Governance is the authority that sits above it.

What the Operating Model Must Not Average Away

There is a failure mode specific to operating models, and it is worth naming before you build one, because the cure is frequently worse than the disease.

An operating model exists to remove variance. That is its job, and for risk, delivery quality, and control it is exactly the right job. Applied to product direction, the same machinery produces something else: the average of the room.

Here is how it happens. A use case is proposed. It routes to a working group. The working group adds stakeholders. Each stakeholder adds a requirement that protects their function. Scope grows, ambition flattens, and what finally ships is the intersection of everyone's comfort zone.

Call it bureaucracy drag. The output of a consensus process is, by construction, unremarkable. Unremarkable is the correct target for a compliance control and a terrible one for a capability meant to differentiate the business.

Separate the two decisions

The fix is not less governance. It is putting the two decisions in different places.

Decision	Belongs to	Mode	Failure if misplaced
May we do this safely?	Governance layer, committee	Consensus, documented	Uncontrolled risk
Should we do this, and how ambitiously?	Named product owner	Single accountable decision	Averaged-out ambition
Is it built to standard?	Delivery function	Checklist, objective	Inconsistent quality
Should it be stopped right now?	Named system owner	Unilateral, immediate	Unstoppable systems

Merge rows one and two and you get drag. Split them and governance does what governance is good at — bounding risk — while direction stays with someone whose name is on it.

The differentiation test

Run every proposed system through one question before it enters the pipeline:

Could a competitor buy this capability tomorrow?

If yes, it is infrastructure. Necessary, worth having, and worth running efficiently — but it is table stakes the day it ships, because it arrives on the same release schedule for everyone. Fund it as infrastructure and stop describing it as strategy.

If no — because it depends on your operational memory, your proprietary process, or data your own operations generate — that is where the strategic attention and the tolerance for ambition belong.

A mature operating model classifies systems on this axis explicitly, alongside risk tier. Tier tells you how much control a system needs. This tells you how much ambition it deserves. Most operating models capture the first and are silent on the second, which is how organizations end up governing their commodity systems beautifully and starving the ones that could actually matter.

Ownership extends to the memory layer

One addition to the inventory that most operating models omit: for every system, record where its operational memory lives and whether it is portable.

Models are rented. Every organization is renting them, and that is fine. What must not be rented is the knowledge that makes outputs correct in your business — the exceptions, the policy interpretations, the reviewer corrections. If that only exists inside fine-tuned weights or a vendor's index, the organization does not own its own institutional knowledge, and the next model transition is a rebuild rather than an upgrade.

Add a column to the inventory: memory location and portable: yes/no. It will be the most uncomfortable column in the census, and the most useful.

Building the AI Inventory

The inventory deserves its own section because it is the connective tissue of the whole operating model. Every pillar touches it. Ownership writes to it. Risk tiering classifies what goes into it. Delivery standards gate what enters it. Control reads it and acts on it. If the inventory is broken, the whole model is broken, because you cannot govern what you cannot count.

Here is how to build it, in order.

Step one: take a census. Before you can govern your AI systems, you have to find them. This is harder than it sounds, because most AI systems in a company are not called "AI systems." They are features inside a CRM, a workflow tool, a data platform, a vendor product. The census is a sweep: ask every department what AI they are using, check vendor contracts for AI features, look at your data pipelines for model calls, and ask the engineers what they have deployed. The census will be incomplete, and that is fine — the point is to get a first version, not a perfect one. You will find the stragglers in the first review cycle.

Step two: assign owners. Every system found in the census gets a named owner. This is the moment the ownership pillar becomes real. If a system has no owner, it does not get to stay in the inventory as "active." It gets flagged as ownerless, and the control pillar treats ownerless systems as a risk to be resolved, not a fact to be accepted.

Step three: tier everything. Every system in the census gets a risk tier, using the matrix. This is the moment the risk tiering pillar becomes real. The tiering is provisional at first — you are classifying what you have, not what you will build. But it immediately tells you where your exposure is: which systems are Tier 3, which are running without the controls their tier requires, and which need attention first.

Step four: gate new entries. From now on, nothing enters the inventory except through the delivery standard. A system ships, it passes the gate, it enters the inventory. This is the moment the delivery pillar becomes real. The inventory stops being a census of the past and becomes a gate on the future.

Step five: review on a schedule. The inventory is reviewed on the tier-based cadence. This is the moment the control pillar becomes real. The inventory is no longer a static list. It is a living system that is actively managed.

The inventory is the single most important artifact in the operating model, and it is the one most companies get wrong by over-engineering it. They build a data model with forty fields, a workflow engine, and a dashboard, and then nobody maintains it. The inventory that works is the one that is boring enough to maintain. Seven fields, updated as part of the delivery process, reviewed on a schedule. That is it.

The Governance Layer vs the Operating Layer

This is the distinction that separates a real operating model from a governance theater. Most companies build a governance layer — a committee, a policy, a set of principles — and call it an operating model. It is not. Governance and operations are two different layers, and confusing them is how AI programs stall.

The operating layer is the daily machine. It is the four pillars running on a calendar: owners assigned, risk tiered, delivery gated, inventory reviewed. The operating layer is where the work happens. It is concrete, it is repetitive, and it is where the actual decisions about actual systems get made.

The governance layer is the authority above the machine. It is the body that sets the rules the operating layer follows, that resolves disputes the operating layer cannot, and that makes the calls that are too big for the operating layer to make. Governance is not the daily machine. It is the constitution the machine runs under.

Here is the failure mode: companies build a governance committee, give it a charter, and then expect it to run the operating model. The committee meets monthly, reviews a handful of systems, and calls that governance. Meanwhile, the other ninety systems drift with no owner, no tier, and no review, because nobody built the operating layer. The committee is not governing anything. It is a spectator.

The correct structure is: the operating layer runs the four pillars every day, and the governance layer sits above it and does three things.

One: set the rules. Governance owns the risk tiering matrix, the delivery standard, and the ownership policy. It does not apply them to individual systems — that is the operating layer's job. It sets them, reviews them, and changes them when the world changes.

Two: resolve escalations. When the operating layer hits a decision it cannot make — a Tier 3 system that is failing its bar, a dispute over ownership, a use case that does not fit the matrix — it escalates to governance. Governance is the court of appeal. It makes the call the operating layer cannot.

Three: make the big calls. Governance approves the overall AI portfolio, sets the risk appetite, and decides which categories of use cases the company will and will not pursue. It does not approve individual Tier 1 systems — that would be the operating layer drowning in trivia. It approves the boundaries, and the operating layer operates within them.

The rule that keeps the two layers honest: the operating layer does not make policy, and the governance layer does not run systems. If the governance committee is reviewing individual Tier 1 chatbots, it is doing the operating layer's job, and the operating layer is not being built. If the operating layer is inventing its own risk tiers, it is doing the governance layer's job, and the company has no consistent standard.

The governance layer is small. It is not a committee of forty people. It is a handful of senior people — the accountable business leaders, the risk lead, legal, security — who meet on a schedule, set the rules, resolve escalations, and make the big calls. Everything else is the operating layer, running the four pillars every day.

Risk Tiering Matrix

Let me give you the full risk tiering matrix as a working artifact, because this is the piece you will actually use. This is the version you can put in front of a team on a Tuesday and use to classify a use case in ten minutes.

The matrix has three dimensions: the tier, the definition, and the required controls. The tier is set by the worst-case damage. The controls scale with the tier. The whole thing is designed to be applied fast, because if classification takes a week, teams will skip it.

Tier	Worst-case damage	Typical examples	Required controls	Review cadence
Tier 1 — Low	Cheap, reversible, human-visible, no regulated data, no material financial/safety impact	Product recommendations, internal search, meeting summaries, code autocomplete, draft generation	Named owner; basic testing; documented in inventory; rollback available	Annual
Tier 2 — Moderate	Costly or hard to reverse, but human reviews before action; may touch sensitive data	Invoice extraction (human-approved), support triage, underwriting assistance, draft contracts, fraud flagging	All Tier 1, plus: security review; bias check; human-in-the-loop; rollback plan; quarterly review	Quarterly
Tier 3 — High	Material financial, legal, safety, or reputational harm; acts without meaningful human review; highly regulated domains	Automated claim/credit/hiring decisions, medical triage, autonomous account actions	All Tier 2, plus: legal & compliance sign-off; independent validation; audit trail; incident response plan; executive escalation; monthly review	Monthly

Three rules govern the use of the matrix, and they are worth repeating because they are where teams go wrong.

Rule one: tier by worst-case damage, not expected performance. A model that is 99% accurate but occasionally makes an irreversible, high-damage error is Tier 3. Accuracy does not lower the tier. The tier is about the failure, not the success rate.

Rule two: the human-in-the-loop is a tier property, not a design choice. Tier 2 requires human review before action. Tier 3 does not get downgraded to Tier 2 just because a human is nominally in the loop. If the output acts autonomously on high-damage decisions, it is Tier 3. A rubber-stamping human is not a control.

Rule three: the tier is re-confirmed at release and at every review. The intake tier is provisional. The release tier is final. And the tier can change as the system's use, data, or scope changes. A system that starts as Tier 1 and expands into a higher-damage use case is re-tiered, and the re-tiering triggers the new controls. This is how the matrix stays honest as systems evolve.

The matrix is the shared risk language of the company. When a team says "this is Tier 2," every other team knows exactly what that means. That consistency is the entire value of the pillar. Risk stops being a personality and becomes a standard.

FAQ

Q1: We already have dozens of pilots running. Do we have to stop them all to build an operating model?

No, and you should not try. Stopping everything would destroy value and goodwill, and it would make the operating model the enemy of progress. The right move is to run the census, put every existing pilot into the inventory, assign owners, and tier them. Then apply the delivery standard going forward — new systems and changes to existing ones pass the gate. Existing systems get reviewed on the tier-based cadence, and any that are running without the controls their tier requires get flagged and brought up to standard. You are not stopping the pilots. You are bringing them under the model. The model governs what exists and gates what comes next.

Q2: Who should be the Accountable owner of an AI system?

The business owner — the person whose process the system touches, whose budget it consumes, and whose results it changes. Not the data scientist who built it, and not legal or compliance. The data scientist is Responsible; they do the work. Legal and compliance are Consulted; they advise. The Accountable owner is the business person who owns the outcome. They can delegate the work, but they cannot delegate the accountability. If you cannot name a business person who owns the outcome, the system does not have an owner, and it should not ship.

Q3: How do we handle a system that changes risk tier after it ships?

The tier is re-confirmed at every review, and a change in scope, data, or use can trigger a re-tiering. When a system moves to a higher tier, the new controls kick in immediately — the system is paused if it cannot meet them, and it is brought up to standard before it resumes. When a system moves to a lower tier, the controls are relaxed to match. The key is that re-tiering is a normal part of the model, not a failure. It is the matrix staying honest as the system evolves. The control pillar's review cadence is what catches the drift that would otherwise leave a system running at the wrong tier.

Q4: What is the difference between the governance layer and the operating layer?

The operating layer is the daily machine — the four pillars running on a calendar: owners assigned, risk tiered, delivery gated, inventory reviewed. The governance layer is the authority above it — the small group that sets the rules, resolves escalations, and makes the big calls. The operating layer does not make policy, and the governance layer does not run systems. If the governance committee is reviewing individual Tier 1 chatbots, it is doing the operating layer's job. If the operating layer is inventing its own risk tiers, it is doing the governance layer's job. The two layers are separate, and keeping them separate is what prevents governance theater.

Q5: Our AI systems are embedded inside vendor products. Do they count as AI systems we need to govern?

Yes. If a vendor product is making decisions, generating content, or processing data using AI on your behalf, it is an AI system in your inventory, and it has an owner, a tier, and a review cadence. The fact that the model is the vendor's does not change your accountability for how it is used in your business. The census should specifically look for AI features inside vendor products, because these are the systems most likely to be invisible — nobody built them, so nobody owns them. They are still your risk. Put them in the inventory, assign an owner, and tier them like everything else.

Q6: How do we keep the operating model from becoming bureaucracy?

The operating model is bureaucracy only if it is disconnected from decisions. The way to keep it lean is to make every artifact serve a decision. The inventory exists so you can answer "what is running and who owns it." The risk tier exists so you can answer "how much scrutiny does this need." The delivery gate exists so you can answer "is this ready to ship." The review exists so you can answer "is this still meeting the bar." If an artifact does not feed a decision, cut it. And keep the governance layer small — a handful of senior people, not a committee of forty. The model is a machine for making decisions, not a machine for producing documents.

Q7: What is the first thing we should do on Monday?

Run the census. Find every AI system in the company — the pilots, the vendor features, the embedded models, the experiments. Put them in a single inventory with seven fields: name, owner, tier, what it does, what data it touches, last review date, and status. Assign a named owner to every system. Tier every system using the matrix. Then look at your Tier 3 systems first — these are your biggest exposure, and they are where you start. You are not building the whole model on Monday. You are taking the census, which is the foundation everything else sits on. You cannot govern what you cannot count, and Monday is the day you start counting.

The AI Operating Model: Ownership, Risk, Delivery, and Control