An AI operating model is the set of decision rights, data ownership, review checkpoints, and cadence for AI in daily operations. It answers who decides, who owns each data source, where a person reviews outputs, which controls run, and how results are measured. For a company of 20 to 200 people, a one-page summary can hold it.
What an AI Operating Model Is
An operating model describes how a company turns its plans into daily work. It covers who decides what, how work moves between teams, and how leaders know whether it is working. An AI operating model applies that same structure to the tools and automations a company runs.
The model is not a full architecture diagram. It still names each tool or provider, the connected systems, the owner, the checkpoint, and the controls. Detailed configurations stay in linked records kept by the relevant owners.
Large enterprises often build these models as long programs with dedicated teams. A founder-led company needs something lighter. The goal is a single page that every manager can read, follow, and update as the business changes.
That page has a simple layout. Each row is one AI use, and the columns record core details such as the tool, its purpose, its owner, the data it touches, its review checkpoint, and its measure. A manager who wants to know the rules for a tool reads one row instead of a policy binder.
The page also records what the company has decided not to do. Declined proposals stay on a short list with a one-line reason. That record saves the leadership team from reopening the same debates and shows new staff where the boundaries sit.
The Problem the Model Solves
Without a model, AI enters a company through many small doors. A sales rep signs up for a drafting tool, finance tries a matching assistant, and operations builds an automation over a weekend. Each choice makes sense alone, but together they create an anti-pattern of scattered tools, unclear data flows, and no shared measure.
The bottleneck is not the tools themselves. It is the absence of clear answers to four questions. Who can approve a new AI use, who owns each data source it touches, where must a person review the output, and how will anyone know it works?
Consider a regional distributor whose teams adopt AI tools independently. Customer data would flow into several services with different retention settings, and nobody would hold the full picture. An AI operating model would give that company one place to see every use, every owner, and every control.
Decision Rights
The first layer of the model is decision rights. A RACI chart works well here, because it names who is responsible, who is accountable, who is consulted, and who is informed for each type of AI decision. The chart turns vague ownership into written roles.
Three types of decisions matter most. Approving a new AI use comes first. Changing an existing use, such as giving a tool access to a new system, comes second. Stopping a use that no longer earns its place is the third, and it is the one companies skip.
In many founder-led companies, the COO or another senior executive stays accountable for the policy and delegates defined approval authority to process owners. The guide to the chief AI officer role covers who can hold that accountability.
Approval does not have to be slow. The process owner can approve a low-consequence use within written thresholds. The thresholds classify uses by data sensitivity, external effect, autonomy, and reversibility, not by the tool’s label.
Free 20-Minute Operations Review
Dealing with a specific operational bottleneck? Kamyar Shah works with founders and CEOs to identify the root cause and build a fix.
Higher-consequence uses go to the accountable executive. The rules make the fast path explicit, so people do not bypass the model to save time. The chief operating officer seat is a natural home for this mandate, because AI changes the processes the COO already runs.
Data Ownership
Every data source an AI tool touches needs a named business steward. Customer records, financial data, employee files, and product information each have a responsible leader. That steward documents sensitivity and proposed uses, while approval stays subject to security rules, contracts, and counsel where needed.
A data inventory makes this visible. It lists each source, its owner, its sensitivity, and the AI tools that can reach it. The inventory is a living record, and its owner updates it whenever the company adds or retires a tool.
Sensitive data deserves the strictest rules. Personnel records, payment details, and credentials should not enter a general-purpose AI tool by default. Any exception needs the minimum necessary data, an approved business account, documented access and retention controls, and a security review. Legal and compliance questions about data belong with the company’s own counsel.
Data owners also protect the people behind the data. Customers trust the company with their records, and employees trust it with their files. A named owner who must approve each new use keeps that trust from being spent by accident.
Review Checkpoints by Consequence
Not every AI output needs the same level of review. A drafting tool that produces internal notes needs light checking. A system that sends messages to customers, changes financial records, or affects personnel decisions needs a named reviewer before the output takes effect.
The model sorts AI uses by consequence and reversibility. Low-consequence, reversible work can run with spot checks. High-consequence or hard-to-reverse work should not take effect until an authorized reviewer checks it against source evidence, and the system should fail closed when approval is missing.
Imagine a company that uses AI to draft quotes for customers. Under the model, the drafts would go to the account manager for approval before they leave the building. An audit record would capture the source, the reviewer, the decision, and the final output, with access and retention limits.
Operating Controls in the Model
The model also records the controls the company runs. These include least-privilege access, so each tool reaches only the data it needs, and separate service accounts for automated work. Secrets such as passwords and keys stay out of prompts and code.
Tools that read outside content, such as emails or web pages, need awareness of prompt injection, where hidden text tries to steer the tool.
Suppose a company uses an assistant that reads incoming supplier emails and drafts proposed order changes. The model would give it read-only access to the order system, so it cannot execute a change. A named employee would verify the supplier and the order details before approving anything.
The workflow treats email content as untrusted input that may carry hidden instructions. The same pattern applies to web pages, shared documents, and customer uploads.
Before approval, the company records each provider’s terms, retention and training settings, and the date it checked them. Each use also needs a containment plan stating how to switch it off and who to notify. Some effects, such as a sent message, cannot be undone.
Cadence Inside the Weekly Meeting
A model that lives in a document and nowhere else will drift. The fix is to place AI inside the meeting rhythm the company already runs. A weekly operating cadence gives each AI use a line, an owner, and a measure that the leadership team reviews.
Each week, owners report briefly on their AI uses. They flag problems, propose changes, and raise requests for new uses. Decisions follow the rights set in the RACI chart, so the meeting does not become a debate about who gets to decide.
Once a quarter, the leadership team reviews the full model. It checks whether owners are still correct, whether controls still fit, and whether any use should stop. That calm, measured review keeps the model current as tools and needs change. It also gives the founder a regular, structured view of AI across the business without attending every weekly discussion.
Measures and the Balanced Scorecard
Each row records a baseline, a business target, a quality measure, a review date, and a stop rule. A balanced scorecard places those measures beside the financial, customer, process, and people measures the company tracks or should track. That placement prevents AI from becoming a separate conversation with its own private metrics.
The theory of constraints helps choose which measures matter. A use aimed at the real bottleneck should show its effect on throughput or cycle time. A use aimed elsewhere may save effort without changing anything the customer notices, and the model should say so.
The jobs to be done lens keeps each row honest. Every use should state the job the business hired it to perform, in plain operational terms. A use that cannot name its job, or whose job no longer matters, is a candidate for retirement at the next quarterly review.
Cost belongs on the page as well. Each row should show what the use costs each month, including licenses, usage charges, and the hours people spend reviewing outputs. Those unit economics let the leadership team compare uses on the same basis and retire the ones that cost more than they return.
How the Model Grows and How an Engagement Starts
The first version of the model should be small. It might cover only the few AI uses the company already runs. As the company adds uses, the model grows by adding rows, not by adding committees, and its structure stays the same.
Kamyar Shah, the author, offers help building this model to founder-led companies of roughly 20 to 200 people as part of his AI strategy consulting work. Engagements start with the Free Ops Call, and the AI Operations Audit at $7,500 applies when it is the agreed starting scope. As of October 2026, ongoing advisory uses his published strategy terms: $12,000 to $15,000 a month for one day a week, or $18,000 to $22,000 for two.
Builds follow the separate terms of his AI implementation offer, where installation starts at $25,000 and monthly support starts at $5,000 with a three-month minimum. Whatever the structure, the principle holds: AI runs best inside the operating system the company already trusts.
