Ownership across the service lifecycle
AI Operating Model for Saudi Companies
Design the responsibilities, handovers, funding and shared capacity that turn a Saudi company's AI portfolio into supported business services.
An AI operating model determines how work gets done after the strategy has been approved. It assigns ownership of outcomes, shared technology, information, funding, service support and change decisions. Without those arrangements, a company can have promising pilots and still be unable to run a dependable portfolio.
For Saudi companies, the design should reflect the actual business: a single operating company, a group with distinct subsidiaries, a regulated enterprise or a growing SME. Start with the work and authority that already exist. A new organisation chart is useful only if it resolves decisions and handovers that currently fail.
Define the operating problem before choosing a structure
Interview the people who own a use case, supply its information, approve its release and support it. Ask where they wait, which decisions repeat and which responsibilities become unclear after launch. Trace one initiative from idea to retirement. This reveals whether the problem is missing expertise, insufficient capacity, disputed ownership or a poorly designed process.
For example, a shared platform team may appear slow because every business unit submits incomplete requests. Alternatively, the business may provide complete requirements but wait behind unrelated infrastructure work. These need different remedies. Adding a central AI office without diagnosing the queue could add another handover.
SDAIA describes its AI Adoption Framework as a guiding reference for adoption across sectors. Use such guidance as context, then design the specific responsibilities and interfaces your company needs. The operating model below is a proposed management design, not a mandated Saudi organisational structure.
Specify five ownership domains
| Domain | Accountable work | Output others can rely on |
|---|---|---|
| Business service | Outcome, user journey, adoption and operating economics | Service objective, baseline and acceptance decision |
| Shared platform | Reusable capabilities, approved patterns and platform reliability | Documented service interface and support commitments |
| Data and knowledge | Source quality, access, maintenance and meaning | Owned sources with update and issue routes |
| Risk and assurance | Requirements, challenge and delegated review | Clear conditions and evidence decisions |
| Portfolio resources | Priorities, scarce capacity and funding allocation | Sequenced commitments with named resource owners |
One person may hold several roles in a small company, but the responsibilities should remain distinguishable. In a larger organisation, avoid making every team jointly accountable for every output. Shared participation is sensible; an unresolved final owner is not.
Assign deputies for critical responsibilities. The operating model should survive leave, turnover and supplier changes. Put source ownership and business acceptance with people who remain after a project ends, rather than relying exclusively on a temporary implementation team.
Choose central, federated or embedded work deliberately
A central team can pool scarce expertise and maintain shared capabilities. It can also become a queue if every minor decision requires its attention. Embedded teams understand local workflows and users, but may duplicate tools or apply inconsistent standards. A federated arrangement combines common guardrails and services with local outcome ownership; it still needs explicit interfaces to function.
Make the choice by capability rather than giving the whole organisation one label. Centralise a shared evaluation environment if several teams need it. Keep document interpretation with the business that owns the policy. Delegate routine changes within an approved boundary while retaining specialist review for material changes.
The AI centre of excellence guide covers a reusable enablement function. A centre of excellence is one possible component of the operating model; it should not absorb every service outcome, operational incident or commercial decision.
Write the handover contract between teams
For each recurring interface, specify what one team provides, what the receiving team accepts and what happens when the input is incomplete. A platform onboarding request might require an approved use description, named owner, data boundary, expected demand and evaluation criteria. The platform team then confirms supported patterns, capacity, cost assumptions and any exceptions.
Use a service agreement that both sides can inspect. “Business provides data” is too vague. Define the source, quality checks, update frequency, permitted access and issue response. Likewise, “IT supports the solution” should state coverage, incident ownership, monitoring responsibilities and escalation.
Keep the interface proportionate. A low-consequence internal drafting use may need a short record. A customer-facing action service needs more explicit operating conditions. The governance process decides review intensity; the operating model ensures the agreed work has an owner and capacity.
Fund the service beyond its initial build
Separate discovery, delivery, shared-platform capacity and ongoing service costs. Identify who pays for evaluation, source maintenance, support, vendor changes and user training. A funded build with an unfunded operating owner is an incomplete commitment.
Choose a transparent allocation method for shared costs. Usage-based allocation may be suitable for measurable consumption; an agreed subscription-like contribution may suit a shared capability with fixed staffing. Do not pretend that a precise allocation is automatically fair. Explain which costs are controllable by each business unit and how material changes are reviewed.
Measure the service's economics with the business owner. Technical usage can help identify costs, but the outcome may be faster resolution, fewer corrections or increased capacity. The AI ROI framework develops value measurement. Keep its assumptions connected to the people who can change the workflow.
A worked example: a group with three operating businesses
Consider an illustrative group with a distributor, a facilities company and a professional-services business. Each wants a knowledge assistant. A central team has the expertise to provide common access, evaluation and monitoring capabilities, but it cannot maintain the content of all three businesses.
The group assigns each business a service owner and knowledge owner. The central team owns the shared platform and publishes its onboarding and change conditions. A portfolio owner allocates specialist capacity. Business units retain responsibility for user acceptance, source accuracy and the value case.
Suppose twelve initiatives request specialist evaluation during a planning cycle, while the shared team can support four to the required depth. The operating model should expose that constraint. The portfolio owner can sequence work, add capacity or narrow scope. Quietly reducing evaluation quality for all twelve would hide the trade-off rather than manage it.
The facilities business then requests a new action capability while the others remain read-only. Its owner submits a change with a revised authority boundary and support requirement. The group can reuse platform components without assuming that one business's approval covers the others. Reuse reduces duplicated work; it does not erase differences in consequence.
Connect decision forums without multiplying them
Routine service decisions should sit with the delegated owner. Cross-business priorities and resource conflicts may need an AI steering forum. Questions outside its authority go to the established executive or board route. The committee setup guide helps define that delegation.
Do not send the same decision through several forums merely because each has an interest. Identify the decision maker, the required contributors and the people informed. If two forums can reverse each other's decisions, document precedence or remove the overlap. Otherwise teams may spend more time securing consent than producing evidence.
Test the model on real work and revise it
Run the proposed arrangements on a small number of active uses. Track waiting time at handovers, rework caused by incomplete inputs, unowned incidents and resource conflicts. Ask participants which commitments are unrealistic. Adjust the interface before expanding it across the portfolio.
Use the capability-building plan to close role-specific gaps, and change management to prepare people for changed tasks and incentives. Do not assume that publishing a responsibility chart creates the skills or time to perform the responsibilities.
Review the model when the portfolio changes materially: more services, higher action authority, a new shared provider or a change in business ownership. Keep the design light enough to evolve but explicit enough that a service can operate without its original project sponsor mediating every issue.
Open for AI's agentic AI consulting can help map workflows, readiness and a sequenced delivery roadmap. Bring one initiative's handover history, current ownership map and capacity constraints to discuss an AI operating model your teams can run.
FAQ
Your questions, answered.
Is an AI operating model the same as a centre of excellence?
A centre of excellence is a possible enablement function within the wider model. The operating model also allocates service ownership, information maintenance, funding, support and portfolio decisions. A company can use a small shared team without assigning it every business outcome or incident. Define the interfaces before choosing the label.
When should a Saudi group centralise AI capabilities?
Centralise where scarce expertise, shared infrastructure or consistent controls create practical benefits. Keep local ownership where workflow knowledge, source accuracy and user outcomes depend on the operating business. Decide capability by capability and examine queue capacity. Centralisation that lacks service commitments can simply move the bottleneck.
Who should pay for shared AI platform costs?
Choose an allocation that reflects how the capability is funded and used. Separate fixed staffing and platform costs from controllable consumption where possible. Agree what business units receive, what they can influence and how changes are reviewed. A transparent approximate allocation can be more useful than a precise formula nobody trusts.
What belongs in a business-to-platform handover?
Include the intended service, owner, information boundary, demand assumptions, evaluation criteria and required operating support. The platform team should confirm supported patterns, capacity, responsibilities and exceptions. The handover is complete when both sides can act on it, not when a document has merely been uploaded.
How can we detect whether the operating model is failing?
Look for recurring unowned incidents, long waits between teams, duplicated evidence requests, unfunded support and unresolved resource conflicts. Trace a few real services rather than relying solely on an organisation chart. Separate missing capacity from unclear authority, because one needs resource decisions and the other needs redesigned responsibilities.
Can one person hold several AI operating roles in an SME?
Yes, provided the responsibilities remain explicit and the person has the time, competence and authority to perform them. Identify specialist support and deputies for critical tasks. Where a decision needs independent challenge or exceeds delegation, use a separate review route rather than relying on the same person to approve everything.