AI will not fix a company that cannot decide.

A plausible pilot, and the real bottleneck

Hypothetical example: a regional retailer uses an AI assistant to identify likely stock-outs and recommend a store transfer. The data is current and the recommendation arrives before the weekend. Yet nothing moves: the store manager cannot release stock, the category lead wants to protect margin, finance wants a check, and supply chain owns the transfer process. By Monday, the opportunity has expired.

It would be easy to call this a data or prompt problem. It is neither. The organisation has automated the diagnosis while leaving the decision right unresolved. AI can draft, compare, forecast, and monitor quickly; it cannot decide which trade-off the company accepts or who carries the consequence. Those are management choices, and they must exist before a useful tool can be embedded in the operating model.

Accountability comes before automation

Start with a decision inventory, not a technology catalogue. Select material decisions for the next twelve months. For each one, name one accountable executive, define independent authority, mandatory consultees, and the escalation threshold. A workflow may verify; accountability cannot be shared into obscurity.

Information rights are not decision rights. A dashboard may give ten people visibility of a risk without telling the organisation who can stop a transaction, change a price, or contact a customer. The handoff from recommendation to action needs an explicit owner and an auditable rule.

The National Institute of Standards and Technology frames AI risk management around four functions: Govern, Map, Measure, and Manage. Governance is deliberately cross-cutting rather than a control added at the end of deployment. For senior teams, that is a useful discipline: define accountability and intended use; map the context and affected parties; measure performance and risks; then manage the response over time. A procurement process alone cannot do this work.

AI shortens the path from evidence to a decision. It does not remove the need to assign the decision.

Reference: [1]

Build a decision charter for each use case

A concise decision charter is more valuable than a long AI policy that nobody uses. It should fit on one page and travel with the use case. State the business decision, the accountable executive, the users who may rely on the output, the data sources, the acceptable confidence or review threshold, the actions the system may never take, the human escalation path, and the log that will evidence what happened. The charter should also say how the organisation will detect harm, drift, or a change in business context.

Review the charter with the operators who will live with it, not only the central innovation team. They will identify exceptions, control dependencies, and shift-pattern constraints that a central design team can miss. That operating detail is where accountability becomes executable.

• One named executive accountable for the business outcome, not merely the model rollout.
• A stated action boundary: advise, prepare, recommend, execute with review, or execute automatically.
• Clear escalation thresholds for high-impact, low-confidence, or out-of-pattern cases.
• A retained record of inputs, recommendation, human action, and subsequent outcome.

Reference: [1]

Why this matters in Saudi Arabia and the wider MENA region

Across Saudi Arabia and the wider MENA region, AI programmes often sit alongside growth, digital-service, infrastructure, and workforce agendas. A solution may need to operate across Arabic and English, cover central and dispersed teams, and reconcile group standards with country-level commercial realities. That makes visible authority important before scale makes ambiguity expensive.

Senior sponsors should resist copying a global operating model without translating its decisions. For example, a centrally developed customer-risk model may inform a local collections team, but the authority to change customer treatment, pause an account, or make an exception must be explicit in the local process. Language, customer expectations, data availability, and service operations should be tested as part of the use case rather than treated as deployment details.

A well-described charter can be reviewed by a group risk function, adapted locally, and audited after an incident without pretending that every market operates identically.

The executive test before the next purchase order

Before approving an AI purchase, ask five questions. Which material decision becomes better or faster? Who owns that decision today? What evidence will tell us whether the tool improved it? Which cases must remain human-led? And who can stop or change the use case when the evidence says it is not working? Answers should be specific enough to place in an operating review, not broad enough to fit only on a strategy slide.

A modest use case with a named owner, bounded authority, and a feedback loop is usually more valuable than an enterprise platform searching for a problem. Once the organisation has shown that it can learn from one decision safely, it has a repeatable pattern for the next. The technology will continue to improve. The harder, more durable advantage is a company that can decide clearly when the technology gives it better evidence.

Reference: [1]