Building an AI operating model from scratch
The governance structures, review cadences and escalation paths that separate AI deployments that compound from ones that stagnate.
The Homework Problem
Most businesses approach AI governance the way teenagers approach difficult homework assignments: they delay it until it's causing a problem, then do the minimum required to make the problem stop. The strategy is sort of understandable. Governance isn't exciting. It doesn't ship anything. It doesn't generate a demo. It's the kind of thing that gets scheduled for Q3 every year and then deprioritized in favour of something that feels more urgent.
The organizations where AI actually compounds have an operating model. Not a strategy. Not a policy document. An operating model: the structures, rhythms, and accountabilities that make AI work as infrastructure rather than as a one-time project.
The organizations where AI actually compounds — where each deployment makes the next one faster, where the system improves over time rather than degrading, where the benefits actually flow to the bottom line — have an operating model. Not a strategy. Not a policy document. An operating model: a set of structures, rhythms, and accountabilities that make AI work as infrastructure rather than as a one-time project.
Operating Model vs Strategy Document
| Strategy Document | Operating Model | |
|---|---|---|
| Answers | What are we trying to achieve and why? | Who does what, on what cadence, to keep systems working well? |
| Output | A document | A set of running practices |
| Fails when | Nobody reads it after the kickoff | Owners change without handoff |
| Produces | Alignment (if you're lucky) | Compounding (if you maintain it) |
The Four Layers
Useful AI operating models tend to have four distinct layers. The temptation is to skip layers one and two and go straight to the exciting parts. Resist this.
Layer 1: The Inventory
A live, maintained register of every AI system running in your organization. Not a one-time audit — a maintained document that is updated whenever a system is added, changed, or retired. For each system, the inventory should capture: what it does, who owns it, what data it accesses, what it produces, and when it was last reviewed.
This sounds obvious. It rarely exists in practice. Organizations that have been deploying AI for 18 months often have significant AI capability running that nobody has a complete picture of, because individual teams adopted tools without coordinating with the centre. The inventory is the foundation of everything else. You cannot govern what you don't know you have.
Layer 2: The Ownership Map
For every AI system in the inventory, a named human owner with four specific accountabilities: the system works as intended; the knowledge base or inputs are current; errors and feedback are reviewed and acted on; and the system is reviewed on schedule. Not a committee. Not a working group. One person.
Layer 3: The Governance Layer
Who can approve new AI deployments? Who reviews deployments that handle sensitive data? Who has the authority to pause a system that's producing questionable outputs? Who makes the final call when the AI's recommendation conflicts with a human's judgment? The governance layer doesn't need to be elaborate — it just needs to exist and be known.
Layer 4: The Improvement Loop
The mechanism by which your AI systems get better over time. This is where most operating models fall short — they have governance for the systems they deployed yesterday but no structure for improving them tomorrow. The improvement loop includes: how errors are reported and actioned, how knowledge bases are updated, how new use cases are identified and prioritized, and how the results of changes are evaluated.
Review Cadences That Actually Work
Weekly (30 min, per owner): What did the system handle well? What did it handle poorly? What feedback came in? What changed in the business that the system needs to know about?
Monthly (structured review): Sample of outputs reviewed against use case documentation. Is quality holding? Are edge cases handled appropriately? Generates input for knowledge base updates.
Quarterly (all systems): Are systems still serving business needs? New use cases to add? Systems to retire? Is the operating model itself working — are governance structures being used, are owners clear on their accountabilities?
Escalation Paths
An escalation path is the answer to: when something goes wrong (or uncertain), what happens next? Every AI use case needs a defined escalation path before it goes live. For most business AI systems, the escalation path has three steps:
- The system flags the item as needing human review (because it falls below a confidence threshold, matches an escalation pattern, or exceeds a defined scope)
- The assigned human reviewer receives the flagged item, reviews it, and handles it directly
- If the reviewer can't resolve it, it goes to the system owner, who determines whether it's a one-off or a systemic issue requiring a fix
The critical thing about escalation paths is that they need to be tested before they're needed. Run a simulation: take a deliberate edge case, introduce it to the system, and verify that the escalation path works as designed.
Common Failure Modes
The Orphaned System: Owner leaves without handoff. System keeps running, quality silently degrades. Fix: no system in the inventory with an empty owner field.
The Governance Void: Individual teams deploy tools without central visibility. Discovery happens when a compliance question can't be answered. Fix: the inventory layer, actively maintained.
The Perpetual Pilot: System is live but treated as a pilot because nobody formally approved it for production. Accountability vacuum. Fix: formal sign-off process for every production transition.
The Static Knowledge Base: Policies change. Products change. Processes change. The AI doesn't know unless someone tells it. Fix: ownership map assigns specific people to keep each section current.
The Missing Feedback Loop: Users encounter wrong outputs but have no easy mechanism to report them, so errors go untracked. Fix: frictionless feedback collection — a Slack channel, a button, a form. Whatever actually gets used.
The Compounding Organization
Here's what a mature AI operating model produces, 18 to 24 months after the first deployment:
Each new deployment happens faster than the last, because the infrastructure, governance, and muscle memory are already in place. Your team has learned how to define use cases, organize knowledge bases, and evaluate outputs. Your governance process is practiced, not theoretical. Your escalation paths have been tested. Your ownership model is understood.
The first deployment takes twelve weeks and two false starts. The fourth deployment takes three weeks and runs reliably from day one.
The compounding isn't just in the AI systems — it's in the organizational capability to deploy and manage them. That capability is what separates the organizations that extracted genuine, durable value from AI from the ones that ran some interesting pilots and then went back to their slide decks.
It's not glamorous. It's operational. It's the work that makes the other work compound. And now you have the blueprint for building it.