The AI Systems Playbook: Deploy AI Across Your Operations
Ask an operations lead which processes changed after a year of AI use, and the answer is usually a list of people rather than a list of processes. Someone in marketing drafts faster. Someone in finance has a spreadsheet trick. The head of sales keeps a prompt in a note that produces decent call summaries.
That is real value, and it stops where the person stops. It leaves when they leave, nobody can review it, and the second deployment costs exactly what the first one did, because nothing was built that the next one can stand on.
An AI system attaches to a task rather than a person, and it outlives the person who set it up. This playbook is the method for building one and then rolling it across an operation.
It names no vendor. The decisions that matter here are the same whichever model you end up running, and product names change faster than the decisions do.
Where this sits
This assumes you have decided AI belongs in your operation somewhere. If that is still open, start with the AI reality curve, or run the AI readiness assessment. For the governance side of the same question, see the Deloitte AI governance breakdown.
TL;DR
- A system has four parts: a named task, the context it runs on, the check that catches it, and the owner who answers for it. Miss one and you have a demo.
- The model is the part you will swap most often, which is why it is not one of the four. Design around the other three.
- Choose targets by how often the work repeats and what it costs when it is wrong. Enthusiasm is a poor selector and it is the one most organizations use.
- Write the decision rule before you look at the results. Otherwise the trial becomes a search for reasons to keep going.
- Apply the compounding test. A deployment counts when it makes the next one cheaper. If it does not, you bought a shortcut.
- Past the third system you need a register, a review cadence, and a retirement rule, or you have rebuilt the software sprawl you already have.
What counts as an AI system
Four things have to be true. The list is short on purpose, because every part that gets skipped is skipped for the same reason: it is the boring one.
A named task. Written down as it runs today, in the words the people doing it use. This sounds like paperwork and it is the whole exercise. A task nobody has written down cannot be judged, which means you will never be able to say whether the system is working, only whether people like it.
The context it runs on. Your policies, your records, your past examples of the work done well. A model with no context produces output that reads like it came from a competent stranger, because it did. This is the part organizations skip, and it is the part that decides whether the output is usable.
A check. Something that catches the output before it reaches anyone who matters. Sometimes a person reads it. Sometimes a rule rejects it. What matters is that the check is specified, and that somebody knows what happens when it fires.
An owner. One named person who answers for the system when it is wrong. Work with no owner reverts to whatever it was before, on a timescale of about a quarter.
Choose the work before you choose the tool
Most first deployments are chosen by who volunteered. Somebody is interested, they have found a tool, and the pilot forms around their enthusiasm. That produces a result you cannot generalize from, because the thing that made it work was the person.
Two properties decide whether a task is worth building a system around.
How often the work repeats. Weekly is the floor. Below that, the effort of specifying the task and assembling the context costs more than the work you are replacing, however impressive the demo was.
What it costs when it is wrong. This sets the check, not the go or no-go. High-consequence work is still a candidate. It just cannot ship without something in front of the outcome.
Run the two properties over each function and the shortlist writes itself. In practice it lands on the same kinds of work in most organizations: summarizing recurring inputs, drafting documents that follow a house pattern, extracting structured information from unstructured records, and answering internal questions whose answers already exist in writing somewhere nobody can find.
Leave the rare, high-consequence work alone. It is the work AI demonstrations are built from, and it is the worst place to learn.
Build the system in five stages
-
Write the task down as it actually runs
Inputs, steps, outputs, and who touches it. Include the exceptions, because the exceptions are where the system will fail and you want them on the page before you build. If two people describe the task differently, settle that now. Software has never fixed it and every rollout exposes it.
-
Assemble the context the work depends on
The documents, records and worked examples the task relies on. Gather them into one place the system can read. Expect this to take longer than everything else combined, and expect it to surface that some of the material is out of date, contradictory, or held by one person.
-
Build the smallest version and run it beside the real work
Parallel, for a fixed period, on live inputs, by the people who do the job. Duplicated effort is the price of an honest read. A trial on clean sample data tells you the tool works and tells you nothing about whether it works here.
-
Decide against a rule you wrote before you looked
Set the threshold in advance: what proportion of outputs has to be usable without rework, and how much time the task has to lose. Written first, it is a decision. Written afterwards, it is a justification for whichever way you were already leaning.
-
Hand it to an owner and put it on the register
A named person, the date it went live, what it touches, and when it gets reviewed. A system nobody owns is a system nobody will notice going wrong.
The compounding test
After each deployment, ask one question: did this make the next one cheaper?
A system passes when it leaves something behind that the next build can use. A context store somebody else can point at. A review step that becomes the standard. A written task description that turns out to describe three other tasks. A person who now knows how to do this.
A deployment fails the test when the only thing left behind is the output. That is a shortcut, and shortcuts are worth buying occasionally, as long as you know that is what you bought and do not count it as progress toward an operation that runs on AI.
This is the difference between an organization with fifteen AI subscriptions and an organization with four AI systems. The second one is further ahead.
What has to exist before this scales past three
Three systems can be held in one person’s head. The fourth is where it stops working, and the things that fix it are unglamorous.
The five that matter
- A register. One list of every system running, what it touches, who owns it, and when it was last reviewed. Without this you cannot answer a client or a regulator asking where AI is used in your business.
- A review cadence. Quarterly is enough for most. The check is whether the system still does the task, because the task moves and the system does not notice.
- A retirement rule. Written before you need it. Systems that stopped earning their place are harder to remove than to add, and nobody volunteers to remove one.
- A data rule. What may be sent where, in plain language, decided once. This is the question that stops deployments in regulated work, and it is answerable in an afternoon.
- A shared vocabulary. If each function learns AI separately, nothing transfers and the fourth deployment costs what the first one did. This is the least visible of the five and the one that decides whether the other four hold.
That last point is worth being specific about. When the finance team and the operations team use the word “agent” to mean two different things, they cannot review each other’s work, they cannot reuse each other’s context, and every deployment starts from the beginning. A common model of how the technology works is infrastructure, and it is cheaper to install once than to discover you needed.
Seven mistakes that stall AI deployment
- Deploying to a person instead of a task, so the capability leaves with them and cannot be reviewed while they are still there
- Buying the platform before writing the task down, which fixes the shape of the solution before anyone has described the problem
- Skipping the context step because the output looked good in the demo, then reading six weeks of generic drafts
- Specifying a check that nobody performs, which is worse than no check because it is recorded as one
- Measuring adoption instead of outcome, so the report says seats and logins while the task takes exactly as long as it did
- Letting each function choose separately, so five deployments produce five vocabularies and nothing transfers between them
- Never retiring anything, so the AI stack accumulates the same way the software stack did
Questions leaders ask before starting
Which process should we automate with AI first?
The one that repeats most often and has a known cost when it is wrong. Run those two properties across each function and rank what comes out. Ignore how interesting the work is, and ignore which team volunteered, because both select for the deployment you cannot repeat.
Do we need to buy an AI platform to start?
Usually not for the first system. The tools you already pay for have models in them, and a first deployment built on what you own answers the questions that decide the platform choice later: what context you actually have, what your checks need to catch, and who is going to own this. Choosing a platform first answers those questions by guessing.
What is the difference between an AI tool and an AI system?
A tool is something a person opens. A system is attached to a task, runs on your context, has a specified check and a named owner, and continues working when the person who set it up is on leave. The same underlying model can sit inside both.
Who should own AI in the business?
Each system needs one named owner, and that owner sits in the function where the work happens rather than in IT. IT owns the data rule and the register. Ownership placed centrally produces systems that are technically sound and describe a version of the work that stopped being accurate two years ago.
How do we stop people pasting company information into whatever tool they found?
Write the data rule in plain language, publish it, and give people a sanctioned route that is easier than the unsanctioned one. Prohibition on its own moves the behaviour somewhere you cannot see. This is the most common cause of the gap between what leadership believes is happening and what is happening.
How long before a deployment shows a result?
The parallel run in stage three should be long enough to cover a normal cycle of the work, including the exceptions, which for weekly work usually means a few weeks. Set the length before you start. Trials without an end date do not end, they get quietly forgotten while the old process carries on.
What does it cost to run once it is live?
Model usage is the visible cost and it is rarely the largest one. Budget for the context staying current, the review cadence, and the owner's time. A system whose context is a year stale costs the same to run and produces worse output than the process it replaced.
Terms used here
- AI system
- A named task, the context it runs on, a specified check on its output, and a named owner. All four, attached to work rather than to a person.
- Context
- The documents, records and worked examples a task depends on, gathered so the model can read them. The difference between output about your organization and output about organizations in general.
- Grounding
- Tying output to source material the system can point at, so a claim can be traced back rather than taken on trust.
- Evaluation
- A repeatable way of scoring output against a standard set in advance. What turns "it seems better" into a decision.
- Guardrail
- A rule that blocks or flags output before it is used. The automated form of the check.
- Human in the loop
- A person positioned at a specific point in the process with authority to reject. The role is defined by where they sit and what they can stop.
- Agent
- A system that takes actions in other software rather than only producing text. It raises the stakes on the check, because a wrong output now does something.
- Register
- The single list of AI systems running in the organization, with owners, scope and review dates. The document you need when somebody asks where AI is used.
The method above is deliberately dull, and dullness is the point. The organizations that get compounding returns from AI are running a handful of well-specified systems that somebody owns, on context somebody maintains, reviewed on a schedule. Start with one, apply the compounding test, and build the second on what the first left behind.