Many enterprise AI programmes are governed as technology portfolios when they are really portfolios of business decisions. The board hears about models, vendors and pilots, but the harder questions remain unresolved: which workflow should change, who owns the result, what risk can management accept and when must an issue return to the board?
That gap matters in the Gulf Cooperation Council, where AI ambition is high and the operating context can include regulated sectors, family ownership, public-sector interfaces and rapid organisational growth. More activity does not automatically create more accountability. A company can have an AI committee, several proofs of concept and no clear route from experiment to business ownership.
Start with the decision the AI will change
Every serious use case changes at least one decision. It may change who approves a credit exception, how a service case is prioritised, when a maintenance risk is escalated or what evidence a leader sees before allocating capital. If that decision is not named, the programme can optimise a tool without redesigning the work around it.
The first board question should therefore be practical: what decision or workflow will behave differently if this system succeeds? The answer should name an owner, an affected group, a current constraint and a visible operating change. “Improve productivity” is not specific enough to govern.
Aman Merchant's working thesis is that AI execution needs decision architecture. In his role publicly listed by 10Pearls as MD, MENA, his perspective sits at the intersection of enterprise transformation and leadership judgment. The point is not to move technical choices into the boardroom. It is to make the route from strategic intent to accountable execution explicit.
A five-part AI decision contract
For each material use case, the leadership team can write a small decision contract before scaling spend or exposure.
- Outcome owner. One business leader owns the result in the workflow. Technology may build or integrate the capability, but the workflow owner remains accountable for whether work improves.
- Required evidence. Define what must be true about data, user adoption, model performance, security, economics and customer impact before the next commitment is made.
- Risk boundary. State which decisions the system may support or automate, where human judgment remains mandatory and what level of error or exposure is unacceptable.
- Escalation trigger. Name the condition that sends the issue to a higher authority. Examples include material customer harm, regulatory uncertainty, a breach of the approved data boundary or performance outside an agreed range.
- Review rhythm. Decide when the organisation will examine value, risk and learning. A launch date is not a governance rhythm.
This contract prevents two common failures. The first is pilot theatre, where a demonstration looks promising but nobody owns adoption in live work. The second is governance theatre, where many functions attend a committee but accountability becomes harder to locate.
Separate board, executive and workflow decisions
The board should govern the enterprise boundary. It sets the value thesis, risk appetite, materiality threshold and evidence required for consequential use. It also tests whether management has the capability to oversee AI rather than treating governance as a policy document.
The executive team should translate that boundary into a portfolio. It chooses which workflows matter, resolves cross-functional trade-offs, assigns business owners and stops initiatives that cannot produce sufficient evidence. This is where ambition becomes resource allocation.
The workflow owner should run the use case in the operating system of the business. That includes process redesign, user behaviour, exception handling, data quality and performance review. If the workflow owner is absent, the project still belongs to the technology team no matter how often it is called strategic.
Use UAE principles as operating questions
The UAE Charter for the Development and Use of Artificial Intelligence calls for safety, privacy, transparency, human oversight, governance and accountability. For a board, those principles become more useful when converted into decision questions.
- Where must a human remain accountable for judgment?
- What information will affected people receive about the system and its decisions?
- Who can pause or remove the system if the risk boundary is crossed?
- What data is permitted, and who can change that permission?
- How will the board know whether accountability works in practice?
These questions do not replace legal, regulatory, security or technical review. They connect those disciplines to the way the enterprise decides. That connection is essential because a policy cannot correct a live workflow if nobody has authority to act on the signal.
Measure changed work, not AI activity
Board reporting often counts pilots, licences, users or models. Those measures describe activity. They do not show whether a decision moved faster, an exception became safer, a customer journey improved or a team gained real ownership.
A stronger review asks for evidence at three levels. First, did the workflow change? Second, did the business outcome move in the intended direction? Third, did the control system detect and correct problems? A use case is not ready to scale when only the first question has an answer.
10Pearls' public AI assessment uses related categories, including strategy and vision, data readiness, technology infrastructure, talent, governance and ethics. The board does not need to perform the assessment itself. It does need to see whether management can connect those categories to one accountable business case.
The boardroom test
Choose the most visible AI initiative in the company and ask five people who owns its outcome. If the answers name a committee, a vendor or several functions, the organisation may have an ownership gap before it has a technology gap.
Then ask what would cause the use case to stop, scale or return for a higher decision. If those thresholds are unclear, the company is relying on confidence and momentum rather than architecture.
The objective is not more control from the board. It is better control through design: clear ownership at the right level, explicit boundaries, evidence before commitment and a review rhythm that turns operating experience into governance learning.
AI ambition becomes execution when the organisation can answer four questions without hesitation: who decides, on what evidence, within which boundary and with what review. Until then, the pilot may be intelligent, but the enterprise around it is still guessing.