AI Operating Model and Centre of Excellence Design in the UAE

Design the organisation around decisions

An AI operating model should begin with the decisions the organisation must make repeatedly. These include which opportunities enter the portfolio, who funds them, who owns the business outcome, what evidence is required, who can approve release, who operates the system and who can restrict or stop it.

Without this design, a central AI team can build systems that business units do not own, while individual functions buy tools that technology, risk and data teams cannot support. The resulting problem is not a lack of enthusiasm. It is an unclear allocation of authority, capability and continuing responsibility.

Map the current AI demand and capability

The design should reflect the organisation's actual portfolio. Management needs to see proposed, experimental and operating uses; the decisions and workflows they affect; the data and platforms they share; and the consequence of failure. It also needs a view of the people currently performing strategy, product ownership, domain analysis, data, engineering, evaluation, change, procurement, risk and operations.

This baseline reveals whether work is genuinely duplicated, whether scarce expertise is trapped in one function and where ownership disappears between pilot and production. It prevents the organisation chart from being designed around job titles while the work follows a different route.

Choose a central, federated or hybrid model

A central model concentrates expertise, platforms and decision-making. It can create consistency and make scarce capability easier to use, but may become distant from operating problems or turn into a queue. A federated model places delivery closer to business units. It can strengthen domain ownership and speed, but may duplicate platforms, standards and specialist roles.

A hybrid model keeps selected capabilities and controls central while business units own products, workflows and outcomes. It is common because enterprise infrastructure, procurement, evaluation patterns and risk methods can be shared, while the work still requires local domain knowledge and operational accountability. The right boundary depends on scale, materiality, regulatory context, talent, architecture and the variety of use cases.

Decide what the Centre of Excellence is for

A Centre of Excellence can serve several different purposes: setting methods and standards, providing scarce specialists, operating shared platforms, supporting use-case discovery, assuring projects, building capability or coordinating a portfolio. Combining all of these without priority can create a large central team whose authority is unclear.

The organisation should define which services the centre provides, which decisions it owns, which advice business units may decline and how demand is prioritised. It should also specify what remains outside the centre. Business sponsors should retain ownership of outcomes and operational adoption. Independent challenge should remain distinguishable from the team rewarded for delivery.

Allocate decision rights across the lifecycle

The operating model should assign authority at each gate: opportunity entry, discovery, funding, data access, build or buy, impact and risk classification, evaluation design, pilot, release, material change, incident response and retirement. The responsible forum needs the information and expertise required for that decision.

A committee that approves every minor change will slow low-consequence work without improving control. A delivery team that approves its own high-consequence release lacks independent challenge. Proportionate gates allow routine uses to move efficiently while preserving stronger evidence and senior authority where consequences are material.

Connect delivery to business ownership

Every AI initiative needs an owner for the business outcome, not only a technical product owner. That person or function must define the workflow result, provide domain evidence, organise users, resolve exceptions and remain responsible for operating consequences.

The delivery arrangement should bring together domain, process, data, engineering, user, evaluation, security, privacy, risk and change capabilities according to the use. These do not all need to report to one leader. They need clear responsibilities, a common delivery route and enough capacity to perform their work when the project reaches them.

Design funding and portfolio choices

Funding shapes behaviour. A fully central budget can encourage business units to propose experiments without committing operating ownership. A fully local budget can underinvest in shared foundations and create incompatible solutions.

The operating model should distinguish shared capability, discovery, pilots and production services. Portfolio decisions should compare value, feasibility, risk, dependency and learning rather than rank projects through one opaque score. Funding gates can release resources as evidence improves and stop work when the business case or operating conditions no longer hold.

Build capability beyond training

AI capability includes the ability to frame opportunities, redesign work, prepare evidence, build or procure systems, evaluate them, operate them and make accountable decisions about reliance. General awareness training does not create these capabilities on its own.

The organisation should identify which skills must be permanent, which can be shared and which may be sourced externally. It should plan career paths, communities of practice, knowledge transfer and time for domain experts to participate. Vendor dependence becomes material when the organisation cannot understand, test, change or exit the systems on which its work relies.

Measure whether the operating model works

Success is not the number of pilots, trained employees or AI tools purchased. Measures should reflect the movement from supported opportunity to dependable operation: time to reach a decision, proportion stopped for good reason, adoption in the intended workflow, outcome improvement, evaluation coverage, incident and remediation patterns, reuse of shared capability and the cost of operating the portfolio.

The model should be reviewed as demand, technology, regulation and organisational capability change. A useful design can begin with a small central capability and deliberately federate responsibility as business units become able to own it.

How Marketways designs an AI operating model

Marketways begins with the AI portfolio, business workflows and decisions rather than a preferred organisation chart. We map current capability and demand, define design principles, compare structural options, allocate decision rights, specify shared services and forums, design funding and delivery routes, and prepare the transition roadmap.

AI Capability and Team Design provides the AI route for roles, skills, capacity and organisational arrangements. Organisation Design and Operating Model owns the underlying service. AI Strategy and Advisory is relevant when portfolio ambition and investment priorities remain unresolved. AI Governance and Model Risk defines the evidence and controls required for accountable use.

What to bring to the first discussion

Useful starting material includes the AI strategy or ambition, known use cases and systems, organisation structure, current delivery and approval routes, technology and data ownership, vendor arrangements, relevant policies, skills and capacity data, project funding practices, unresolved bottlenecks and examples of pilots that did or did not reach operation.