An AI system can have a sponsor, a project team and a successful launch while still having nobody responsible for its daily usefulness.
The missing work becomes visible later. A data feed changes. An exception queue grows. A model update alters an answer. Users stop trusting recommendations and quietly return to a spreadsheet. Each team can point to a task it completed; none has the authority or capacity to restore the business result.
“AI-native operating model” is a large phrase for a practical question: who keeps the service working, and who can decide when it should change or stop?
Existing software operations, security and risk disciplines already answer much of this. They should be the foundation. AI adds particular needs around uncertain outputs, changing data, evaluation and the boundary between a recommendation and an authorized action. A separate transformation structure is useful only where it closes those gaps.
Start with a service someone needs
Consider an illustrative inventory-planning service for a distributor. It recommends replenishment quantities. The commercial promise is better availability with less unnecessary stock. That is broader than producing a forecast with a low average error.
A forecast can improve while inventory decisions get worse. Perhaps it is accurate for fast-selling items and poor for the rare component that stops a customer's production. Perhaps planners override it because it cannot see a supplier delay. Perhaps the purchase process is too slow to use the recommendation in time.
The service therefore needs a business owner who can define the trade-off between availability, stock and operational effort. That owner needs input from sales, procurement and planners. The model team cannot settle a commercial trade-off by selecting another accuracy measure.
Write down the service in terms its users recognize: which items, which locations, how often a recommendation arrives, what it is allowed to trigger and what happens when evidence is missing. That scope makes the business promise testable. It also makes clear that an expansion to another warehouse is a decision, rather than a routine change to a dashboard.
Give four kinds of work an owner
The first is the outcome. Someone must review whether the service helps the business, including the cases where users bypass it. Counting recommendations produced or users licensed will not answer that question. For the inventory example, stock availability, unnecessary inventory and the effort needed to act belong in the discussion together.
The second is the technical service. Someone maintains integrations, access, monitoring and recovery. A feed failing at night should have a response that does not depend on finding the original pilot developer. If the model is unavailable, planners need a usable alternative and an honest indication of which recommendations are stale.
The third is the evidence. Someone maintains representative test cases, checks changes and investigates mistakes. Technical uptime says little about whether a recommendation remains appropriate. Testing should include unusual products, missing information and the exceptions users actually encounter, as well as common cases that make a demonstration look good.
The fourth is the way people work. Someone owns training, review capacity, handoffs and escalation. If every recommendation requires a check, reviewers need time and authority to do it. If certain recommendations can be accepted automatically, the reason for that permission needs to be explicit and revisited when conditions change.
These responsibilities do not require four new departments. A small service might assign several to one person. They do require named people, agreed expectations and enough capacity to act. A responsibility assigned to a committee that meets occasionally can leave a daily service without an effective owner.
Put changes through an appropriate decision
Some changes are ordinary maintenance. A connector repair that restores an approved data feed may need the existing change process. Others alter the business bargain. Automatically issuing purchase orders changes authority and financial exposure; adding a new supplier changes what the model needs to understand.
Separate those decisions. Define which changes the service team can make, which need business approval and which require additional risk or security review. The point is to make the important choices visible without sending every routine adjustment through a steering committee.
The NIST AI Risk Management Framework offers a useful reference for organizing AI risk work across governance, context, measurement and management. It is voluntary guidance, not a certificate that a system is safe. The operating question remains whether the assigned work happens, with evidence that people can inspect.
For the distributor, suppose the model performs acceptably on replenishment suggestions and the team now wants automatic ordering. The previous evidence supports the recommendation service. The new decision also needs spending limits, supplier controls, a way to cancel or correct orders and someone accountable when an order is wrong. Approval for the first scope cannot quietly become approval for the second.
Budget for the service you intend to keep
The launch budget is only part of the cost. The continuing service consumes engineering time, model or infrastructure spend, data maintenance, review effort and user support. Improving it may require new evidence and retraining as well as another release.
Make those costs visible to the business owner. A service that appears cheap because users absorb the checking work can be expensive for the organization. Conversely, a deliberate review step may be worth paying for if it lets the service address a valuable problem with acceptable risk.
Avoid comparing the full cost of the present process with the model's usage bill alone. Compare complete services with comparable obligations. If an automated recommendation creates a task for procurement, include that task. If a planner must reconstruct its rationale, count that effort too.
This also makes stopping possible. A team should be able to say that a service has become too expensive to maintain, or that a simpler method now meets the need. Protecting a transformation label is a poor reason to keep an unhelpful application alive.
Decide what belongs at the centre
A central team can provide approved platforms, security patterns, evaluation support and a place to learn from incidents. Business teams bring the process knowledge and own the result. The balance depends on the organization's capacity and the consequence of the application.
A common mistake is to centralize every use case until the specialist team becomes a queue. The opposite mistake is to distribute development while leaving each team to rediscover access controls, monitoring and procurement rules. Shared capabilities should remove repeated work; business ownership should remain close to the decisions the service affects.
Before creating a new centre of excellence, list the recurring problems it would solve and how business teams will use it. Its success should show up in reliable services and easier delivery, rather than the number of frameworks it publishes.
The Executive AI Mandate provides a place to document the scope, owners and decision rights before funding an initiative. The document earns its value when it is used again after the launch.
An operating model is working when the planner knows where to take a bad recommendation, the service team knows how to recover, and the business owner knows whether to invest more. Those are modest claims. Delivering them consistently is substantial work.