Most AI projects don’t die because they fail. They die because nobody owns them after the initial excitement. The operating model is how you keep the work alive – without building a bureaucracy.
If you’ve made it this far in the foundation series, you’ve probably noticed a pattern:
The difference between “we tried AI” and “AI is part of how we operate” is not the tool.
It’s ownership.
Pilots are temporary by design. Operations aren’t.
So, the final foundation question is simple:
” Who owns this after the pilot – and what does ‘owning it’ actually mean? ”
First: clarify what you’re actually operating
In most mid‑market environments, you’re not operating ‘an AI model.’ You’re operating:
- A workflow (inputs → AI step → validation → handoff)
- A set of playbooks (prompts + input formats + output specs)
- A review lane (human-in-the-loop rules)
- Data boundaries (what can/can’t be used where)
- A measurement scorecard (VOI and risk signals)
If you treat AI like a one-time installation, it will drift. If you treat it like a workflow capability, it will mature.
The 4 owners you need (even if it’s only two people)
You don’t need a committee. You need four clear accountabilities:
- Value Owner (Business): defines success, approves priorities, owns adoption and outcomes
- Risk Owner (Business/Compliance/Security): defines guardrails, approves review lanes, owns escalation decisions, TPRM & compliance/regulatory controls
- Workflow Owner (Ops/IT): maintains the workflow steps, playbooks, and change control
- Platform Owner (IT): owns tool configuration, access, logging/telemetry, vendor management
In a 200–500-person company, two people can cover all four roles. The point is not headcount—it’s results with clarity, consistency, velocity, compliance, and mitigated risk.
Define ‘change control’ in plain English
This is where projects quietly break. Someone tweaks a prompt, changes an input source, or swaps tools… and outcomes change. That can break the workflow – and that’s a real risk.
So, define lightweight change control:
- What changes are self‑serve? (spelling, formatting, tone tweaks)
- What changes require the workflow owner’s approval? (new sections, new input fields, different output requirements)
- What changes require the risk owner’s approval? (new data types, external sharing, customer-facing automation)
If you want it simple, treat anything that changes the risk profile like a real change.
Set a ‘cadence’ so it doesn’t become a fire drill
Operating models fail when they rely on heroic attention.
Instead, set an easy rhythm:
- Weekly (15 minutes): workflow owner checks signal metrics (rework, errors, adoption) and captures issues
- Monthly (30 minutes): value + risk owner review: what to improve, what to stop, what to scale
- Quarterly (60 minutes): refresh playbooks, update the one-page policy if needed, review tool sprawl
This isn’t to create governance theater. It’s basic operational hygiene.
The ‘minimum artifacts’ that keep it owned
You don’t need a binder. You need a few living assets:
- Workflow card (1 page): purpose, owner, lane, inputs, outputs, tools, escalation triggers
- Prompt/playbook entry: the reusable template you standardized in Part 11
- Scorecard: the 4-metric VOI view from Part 10
- Decision log: a simple list of changes and why you made them
If it isn’t written down somewhere and easily discoverable, it won’t stay consistent.
How this avoids bureaucracy (and actually speeds you up)
People hear ‘operating model’ and imagine approvals and friction.
A good operating model does the opposite:
- Teams know what’s allowed (so they move faster)
- Review lanes are pre-defined (so you don’t debate every use case)
- Changes are controlled (so you don’t re-learn the same lessons)
- Value is visible (so funding and attention follow outcomes)
A simple starting point (copy/paste)
If you want an easy first operating model, start with this:
- Pick 3 workflows you intend to keep
- Assign the four owners (names, not departments)
- Create a workflow card for each
- Set the weekly/monthly/quarterly cadence
- Publish the playbooks in one place and version them
That’s enough to move from pilot energy to operational reality.
This wraps the foundation series.
If you do nothing else: define ownership, define lanes, and measure what matters.
That’s how you deploy AI in a way that stays useful, stays defensible, and keeps improving over time.