The operating model enterprise AI has been missing
The case patterns in the practitioner correspondence I receive from CIOs, CAIOs, and AI delivery leaders point to one structural problem more often than any other. Enterprises are governing artificial intelligence through the wrong organisational construct. The dominant approach treats every AI deployment as a project lifecycle, run by project managers, gated through architecture and risk reviews, and declared complete at the moment the system goes live. The discipline is rigorous. The discipline is also incompatible with the systems it is being applied to.
Project management is the wrong tool for AI for the same reason a stopwatch is the wrong tool for measuring temperature. The discipline assumes a defined end state. AI systems have no end state. The discipline assumes deterministic behaviour. AI systems are probabilistic. The discipline assumes accountability transfers cleanly at handover. AI systems require ongoing accountability that no traditional handover protocol delivers. Project management is not a deficient discipline. It is the wrong discipline.
What enterprise AI requires instead is an operating discipline that takes over where project management ends. The discipline does not yet have a settled name in the management literature. I use System Stewardship: the ongoing practice of monitoring, evaluating, governing, and adapting AI systems through their production life. The case for ongoing AI governance has been made compellingly in MIT Sloan's recent coverage of CAIO accountability and agent oversight. The argument here sits one structural step earlier: the discipline that needs to be built before governance has anything to evidence.
The first pattern came from a delivery lead at a retail organisation. The team built a customer service triage agent over four months and handed it to BAU operations at go-live. The receiving team had two days of training on the agent's interface and no training on how the model made decisions, what its failure modes looked like, or how to distinguish a model issue from a data issue from a prompt injection. Within ninety days the team owned three production incidents none of them could have predicted. A customer complaint escalated to the regulator. A billing override that should have been flagged. A privacy breach the team had no framework for recognising. The line he sent me was the kind I have read in different forms several times now: "I am not sure who owns this agent today, but I know it is not us."
The second came from a credit risk lead at a bank. AI agent for credit decisioning support. On paper, his function owned it. The model registry showed credit risk as the accountable team. In practice, performance monitoring sat with the data team, cost monitoring sat with finance, and compliance review sat with the second line of defence. When drift began to surface, none of those three functions had the full picture, and his team did not have the technical depth to act on what they could see. The line he gave me was: "we own the model on paper, but I cannot tell you who actually runs it."
The third pattern came from a programme director inside a government agency. AI agent for benefits processing. Strong governance committee on paper, meeting quarterly to review an aggregated risk dashboard. The agent had been live for ten weeks before anything appeared on the dashboard, and by then the operational team had already started routing decisions around the agent because it had lost their trust.
Three industries, three different agent types, one structural pattern. Each enterprise had a project discipline that was working. Each enterprise lacked the operating discipline that AI deployment actually requires. The project closed. The agent kept running. Nobody owned what happened next.
Project management is one of the most refined disciplines in modern enterprise. Decades of accumulated practice, multiple professional bodies, billions of dollars in invested tooling. The discipline works because traditional software systems behave in ways that align with its core assumptions.
A payroll system, once deployed, processes payroll the same way next quarter as it did this quarter. If something changes, it is because someone changed it deliberately. The system has a defined end state at deployment. Accountability transfers cleanly to operations because operations can run the system using documented procedures.
AI systems invalidate every one of those assumptions. The system that processes a credit decision today produces different decisions next month, not because someone changed it but because the data shifted, the foundation model was updated, the prompts started encountering edge cases the training data did not anticipate, or the regulatory context moved. There is no defined end state. There is only the agent's evolving behaviour over its lifecycle. Accountability cannot transfer cleanly to operations because operations does not have the technical depth to detect or respond to the kinds of drift AI systems exhibit.
The project lens forces enterprises to compress all the work into the build phase, where project management discipline genuinely applies. Everything after deployment becomes residual work, allocated to BAU teams, inherited by functions that have no framework for the variability they are now responsible for managing. The pattern observable across the case notes I receive is the same: agents drift unsupervised until they fail publicly, and the post-mortem reveals that no one was actually responsible for the operating window in which the failure occurred.
System Stewardship sits adjacent to several disciplines that already exist, and it is worth being precise about what it is not. It is not MLOps or ModelOps, which are engineering disciplines focused on the technical pipeline that gets models into production and keeps them running at the infrastructure layer. It is not Responsible AI, which is a values and policy framework concerned with bias, fairness, transparency, and ethical use. It is not project governance extended into operations, which is the failure mode this article describes. System Stewardship is the operating discipline that connects these layers: the management practice that decides who acts on what the engineers measure, what the policy framework permits, and what the business needs the system to do as the system itself evolves. MLOps tells you the agent drifted. Responsible AI tells you which kinds of drift are unacceptable. System Stewardship decides what to do about it, who decides, and on what authority. Without the connecting discipline, the engineering signals and the policy frameworks do not produce operational decisions.
Enterprises do not lack AI governance frameworks. They lack the operating discipline that turns those frameworks into decisions when the moment of consequence arrives.
System Stewardship is the discipline that takes over where project management ends. The practice has four operating requirements that distinguish it from any extension of project governance into BAU.
The first is sustained ownership. Every production AI system has a single named role accountable for its continued operation through its life, with the technical authority to halt it, modify it, escalate it, or retire it. Not a steering committee. Not a function. A single named role, full-time, whose job description includes reading the agent's behaviour and responding to it.
The second is evaluation cadence. AI systems are reviewed in operating rhythms designed for probabilistic behaviour, not in quarterly governance committees designed for static deployments. The cadence is part of the agent's operating model, not a side activity that gets dropped when the team is busy. The cadence scales by risk. Critical agents get daily attention. Lower-risk agents get monthly review. The principle is that the rhythm matches the system's volatility, not the calendar of governance forums.
The third is observability infrastructure. The technical platform that makes ongoing evaluation possible, including drift detection, cost tracking per agent, compliance traceability, and replayable decision logs. Without the platform layer, the role and the cadence cannot do their work.
The fourth is performance measurement designed for adaptive systems. Agents are measured against a baseline set at deployment and updated as the system learns. The metrics include unit economics, drift rate, override rate, and adoption rate, all measured per agent and aggregated across the portfolio. The measurement infrastructure feeds back into the operating decisions: what to coach, what to retrain, what to retire.
These four requirements constitute the operating discipline. The full operating manual runs across multiple frameworks practitioners can apply, including the AI Role Operating Framework, the agent governance work emerging from MIT and other institutions, and various platform-led models from major vendors. The point of this essay is not to prescribe a single framework. The point is that the discipline has to exist at all, and across the case notes I receive, it remains absent more often than not.
The empirical evidence supports the structural argument. S&P Global's 2025 enterprise AI survey found that 42% of organisations had abandoned most of their AI initiatives, more than double the previous year. Grant Thornton's 2026 enterprise risk survey found that 78% of senior leaders lack full confidence they could pass an external AI governance audit within ninety days. NVIDIA's 2026 State of AI survey of 3,200 respondents found that 86% of organisations plan to increase AI spend this year. McKinsey's State of AI research found that only 5.5% of organisations are seeing significant financial returns from their AI investments.
These are not separate problems. They are symptoms of the same underlying gap. The abandoned initiatives are systems that never got past pilot because the operating discipline to run them in production was never built. The audit readiness shortfall is what happens when accountability is distributed across functions that cannot evidence their part of it. The investment-to-return mismatch is what happens when performance measurement is structured for static systems rather than adaptive ones, and the asymmetry is now striking: enterprises are increasing AI spend at one rate while seeing measurable financial returns at a different rate entirely.
What the data does not yet capture is what happens to the systems that did make it past pilot. Those systems are now running in enterprises across every sector, drifting in operating windows that no role has been designed to manage. The next eighteen months will reveal how many of those systems are governed, how many are quietly failing, and which enterprises built the operating discipline before they needed it.
Formal datasets on post-deployment AI operations remain limited. The convergence between the practitioner accounts I receive and the industry surveys cited above suggests this is not a network effect of one inbox. It is a structural pattern showing up in different forms across different vantage points.
There is a diagnostic that surfaces the gap quickly. In your next executive committee or AI governance forum, pick the agent in your portfolio that carries the most reputational, financial, or regulatory risk. Ask one question.
If our highest-stakes agent fails publicly next week, who gets fired?
Not who is responsible on paper. Not who chairs the governance committee. Not who is consulted under the RACI. Who, by name, gets fired.
Either the room produces no name, or the room produces three. Both are stewardship gaps. When the moment of consequence arrives, distributed accountability and unstaffed accountability behave the same as no accountability at all. A working operating model produces one name. The person whose actual job is the steward of that agent through its life.
If the room cannot produce that name, the diagnosis is not that the enterprise needs better project management for AI. It is that the enterprise has been applying the wrong discipline entirely. The first move is naming what the right discipline is. The second is building it before the moment of consequence forces it.
Boards are beginning to ask the question the diagnostic surfaces, sometimes for the first time. EU AI Act enforcement begins in August 2026, with transparency provisions taking effect and high-risk AI system obligations covering human oversight, monitoring, input data quality, risk reporting, and logging. Australian privacy reform is moving in parallel. Personal liability for directors of organisations whose AI systems cause material harm is now a live regulatory question on multiple continents.
The discipline that satisfies those regulators will not be project management extended into operations. It will be an operating discipline designed for systems that change after deployment. The enterprises that build it now will absorb the regulatory load when it arrives. The enterprises that wait will discover that retrofitting an operating discipline during a public failure is the most expensive way to learn what should have been built first.
The discipline that takes over after deployment is the work that needs to be built. Whether it carries the name System Stewardship or another, the operating gap has to be closed.
Vijayan Seenisamy has led AI delivery and transformation programmes at large Australian enterprises. He is the creator of the AI Role Operating Framework and author of The AI Delivery Manager Blueprint and The Pilot Trap, and writes at aideliverydiscipline.com.
| Field | Value | |---|---| | Word count | 1,950 |
Vijayan Seenisamy is the author of The Pilot Trap and The AI Delivery Manager Blueprint, and the creator of the AI Role Operating Framework (AI ROF™).
