1. Ownership Is a System of Decision Rights, Not a Job Title
Many AI programs stall because the enterprise starts with an overly simple question: should AI report to IT, data, or transformation? The more useful question is: who owns each material decision across the use-case lifecycle? The party that decides where AI may be used, which data may be used, when a solution can enter production, and who accepts residual risk is exercising real ownership. Holding a platform budget or managing a small team does not establish that ownership.
In a large Saudi enterprise, those decisions commonly sit across executive leadership, business units, IT, data, security, risk, and legal or compliance functions where relevant. The answer is not to force every responsibility into one department. It is to document decision rights. Each party should know when it recommends, reviews, approves, or carries accountability. Without that clarity, AI becomes either a collection of local pilots that never scale or a central programme disconnected from daily operations.
2. The Practical Default: Strong Centre, Disciplined Federation
Full centralization gives the enterprise consistency in platforms, security, and standards, but it can slow delivery and turn the AI team into a bottleneck. Full decentralization places solutions close to operational needs, but it duplicates vendors, data patterns, models, and controls. For many enterprises, the workable answer is disciplined federation: a central AI centre of excellence sets shared guardrails, while business units lead use-case selection and operational adoption.
The centre commonly owns the reference architecture, responsible-use policies, approved data and systems integration patterns, vendor assessment, documentation standards, and shared risk oversight. Business units own the opportunity pipeline, problem definition, process owner, success criteria, and post-launch change plan. This division avoids two familiar failures: a central team imposing solutions without an operational owner, and individual units buying tools and building isolated assistants that cannot be governed or maintained.
3. Design the Team Around Capabilities, Not Technology Labels
Not every business unit needs a full team of data scientists and machine-learning engineers. It needs a reliable capability to frame the problem, understand the process, identify usable data, and lead adoption. Equally, the centre of excellence should not become a research group detached from operations. A balanced structure brings together strategic leadership, use-case portfolio or product management, data and integration engineering, platform or model engineering, risk and quality assurance, and change enablement.
These capabilities can be distributed between the centre and business units according to enterprise scale and maturity. Yet every use case should have named roles: an executive sponsor, process owner, product or service owner, data owner, technical owner, and a risk or control representative where appropriate. If the team cannot name these people before building begins, the initiative is probably still an abstract idea. This matters especially for generative AI, where the ease of producing a prototype can conceal the difficulty of controlling outputs and changing work practices.
Before approving the structure, ask three practical questions. Does the unit need more speed or more independence? Are the necessary data and systems shared across the enterprise or local to the unit? Will the output influence a sensitive decision, a customer-facing service, or an operational action? The answers determine the degree of central oversight and human review rather than imposing one model on every use case.
4. Govern the Journey Through Clear, Short Decision Gates
Effective governance does not mean a lengthy committee meeting after the work is complete. It means recurring decision gates tied to the maturity of the use case. At the start, the case should demonstrate a measurable problem, an operational owner, and feasible access to data. The enterprise then reviews the technical approach, data sensitivity, permitted usage boundaries, and non-AI alternatives. After the prototype, results should be compared with an agreed baseline rather than relying only on user impressions.
Before launch, the enterprise needs an explicit operating-readiness decision. Who monitors quality? How are incorrect or unexpected outputs handled? What may the end user do, and what may they not do? Which records are retained to trace performance and incidents? How does the process change if the model, vendor, or data source becomes unavailable? These are operating questions, not late-stage details. Their answers distinguish an enterprise product from a demonstration.
Use cases should be classified into internal risk tiers, from low-impact support tools to applications that affect material financial, operational, or people decisions. Approval should not be identical for all of them. Low-impact cases need a fast path within approved tools, while higher-impact cases require broader testing, clearer controls, and stronger accountability. Proportionality protects delivery speed without weakening discipline.
5. Value Measurement Starts Before Build and Ends After Behaviour Changes
Counting models, licences, or usage hours is not enough. These are activity measures, and they can help manage adoption, but they do not prove business value. The business owner should establish a baseline before implementation: process cycle time, rework rate, decision quality, backlog volume, or another measure appropriate to the case. The owner should then define the expected AI contribution, the assumptions behind it, and how the enterprise will separate that contribution from other operational changes.
For knowledge-support use cases, measurement may combine answer accuracy against a reviewed sample, escalation rates, time to complete a task, and user adherence to the approved process. For analytical optimization cases, the enterprise may focus on the quality of a prediction or recommendation compared with the previous decision, and on whether teams can explain the difference and act on it. The measurement choice follows the process, not the type of AI being used.
The portfolio also needs an explicit stop decision. If data is unavailable, the process owner is absent, or expected impact no longer justifies integration and operating cost, the case should be stopped or reframed early. Ending a weak initiative is not an AI failure. It shows that governance is protecting the enterprise's time and investment.
6. A Ninety-Day Execution Path: From Ambiguity to a Managed Portfolio
During the first thirty days, leadership should appoint an executive sponsor, name an operating-model lead, inventory current initiatives and tools, and map decision rights at a practical level. Do not begin with an open idea competition before understanding what already exists. The enterprise should also standardize basic definitions: what counts as a use case, prototype, production launch, business owner, and high-impact case? Shared language prevents substantial friction later.
During the following thirty days, establish an initial portfolio of a small number of cases with clear owners and measurable baselines. Each case needs a one-page brief covering the problem, user, data, permitted decision or action, controls, success criteria, and stop option. In parallel, the centre of excellence should issue a minimum set of working standards: approved tools, rules for entering data, output-evaluation methods, and documentation requirements. The aim is not a large policy manual. It is to let teams move within understood boundaries.
In the third month, run the review gates, place one or two cases in a controlled environment, and present leadership with a portfolio dashboard rather than a technology showcase. The dashboard should show the status of each initiative, its owner, next decision, risk tier, dependencies, and agreed measure. The enterprise can then adjust authority and capability allocation based on operating evidence. A sound model does not earn credibility through an organization chart alone; it earns it by speeding sound decisions and exposing unready initiatives early.