AI operations manager: knowing what you are running
There is a point, usually somewhere between the fifth and the fifteenth deployed system, at which no single person in an organisation can answer what is running, what it costs, who owns each one and whether any of them should be switched off. Before that point the question is part of somebody's job and works fine. After it, the estate acquires the properties of any unmanaged estate: duplicate systems doing the same thing for two departments, systems still running for a team that reorganised, costs nobody has looked at since the pilot, and ownership that evaporated when a person left. This role exists to hold that picture. Its failure mode is specific and common: responsibility for the estate without the authority to retire anything, which produces a well-maintained list of things nobody is allowed to turn off.
AI operations manager, in short
Emerging role| In one sentence | Runs the portfolio: which systems exist, what they cost, who owns them and which should be switched off. |
|---|---|
| Judged on | Whether the organisation knows what it is running and what it is paying for. |
| Fails when | It becomes an inventory exercise with no authority to retire anything. |
| Most confused with | AI governance, which sets the rules rather than running the estate. |
Real work, but the scope differs enough between employers that the title alone tells you little. No compensation figures: see methodology.
What the estate view actually contains
Four columns, the same ones governance needs and used differently. What the system is and does. What it costs to run, monthly, including the model calls rather than only the licence. Who owns it, by name. And when it was last checked against its evaluation set.
The cost column is where this role earns its place, because it is the one nobody else maintains. Model spend is usually aggregated at the account level, so the organisation knows what it spends in total and not what any individual system costs. Attributing it is unglamorous and it is what makes retirement decisions possible.
The last-checked column is the one that surfaces decay. A system with no evaluation run in eight months is not necessarily broken; it is unmeasured, which for this class of system is close to the same statement.
The two discoveries that always happen
Systems nobody knew about. Built by teams who were not being secretive and had no reason to tell anyone. This is an inventory finding rather than a discipline problem, and the correct response is to add them rather than to investigate how they got there.
Systems nobody uses. More expensive, less visible, and the one people are reluctant to name because somebody built it. A system running with no users still costs its running fee, still holds whatever data it was given, and still carries the oversight obligations its classification implies.
Retiring those is the fastest return this role produces, and it is entirely dependent on having the authority to do it. An operations function that can only recommend retirement will watch the same systems appear on the list every quarter.
Retirement is the deliverable
Most operational functions are measured on keeping things running. This one should be measured partly on switching things off, because an estate that only grows is an estate whose cost and oversight burden compound without anyone deciding.
A workable rule is that every system has a review date at which someone must argue for keeping it, rather than needing a reason to remove it. The default matters: systems survive indefinitely when the burden of proof sits on removal, and almost nobody sets it the other way.
The related discipline is having an actual retirement procedure. What happens to the data, who is told, what replaces it for the handful of people still using it. Without one, systems are abandoned rather than retired, which leaves them running.
The duplication that is not obvious
Two departments building the same thing is the duplication people expect, and it is relatively easy to spot once an inventory exists. The costly version is subtler: two systems that answer the same question differently, both in production, both trusted by their users.
That state produces disagreements the organisation cannot resolve, because both parties have a system telling them they are right. Finding it requires looking at what systems do rather than at what they are called, which is why the inventory has to carry a description somebody wrote rather than a name somebody chose.
The resolution is rarely technical. It is deciding which answer the organisation is going to use, which is a business decision that has been deferred by the existence of two systems, and surfacing it is one of the more valuable things this role does. It is also the finding most likely to be unwelcome, since somebody built each of the two systems and neither expected to be asked to stop.
Where the role comes from
Usually from IT operations or from a platform team, occasionally from finance, which is a better source than it sounds: somebody who is comfortable attributing costs will build the one column that makes the rest actionable.
At most organisations it is part of a broader operations or platform role rather than a separate headcount, and it should be. Where it separates out, the useful pairing is with governance, since the inventory and the classification are the same table read for two purposes.
