Skip to content
Blog

Region · UAE

Who is accountable when an AI recommends a portfolio decision?

Accountability cannot be delegated to a model. What a record must hold so every AI recommendation carries the name of the person who accepted it.

· TruMandate team, Intertec Systems · 8 min read

Item four on the agenda arrives already answered.

On the screen: hold the next tranche on Initiative 21 until the dependency on Initiative 07 clears. Evidence attached. Confidence stated. Nobody in the room wrote it.

The committee agrees in under a minute, because it looks right.

“Do we need to minute this one?”

“It’s the system’s recommendation.”

“Fine. Minute that, then.”

And that is what gets written. The room has just held a tranche of money, and the only name attached to the holding belongs to something that cannot be asked about it later.

Who is accountable when an AI recommends a portfolio decision?

The person who accepted it. There is no second answer, and the reason is structural rather than ethical. Accountability needs someone who can be asked a question and made to answer it, whose mandate can be withdrawn, and for whom being wrong costs something. A model meets none of those conditions.

Be precise about this, because four candidates get offered and three of them fail on contact.

The model. It cannot hold an obligation. It cannot be summoned, reassigned, or asked what it was thinking in a way that binds. A system that cannot bear a consequence cannot carry accountability.

The vendor. A supplier can be contractually liable for a defect. That is not accountability for a decision. The vendor was not in the room, holds no mandate, and will not explain to a board why an initiative stopped.

The committee. Collective accountability degrades the same way a departmental owner does. A decision owned by nine people is owned by nobody: no one uncomfortable, no one to ask a second question.

The individual who accepted it. The only candidate left standing, which makes the answer unavoidable rather than admirable.

Our own position says exactly that. AI proposes. A person decides. The record keeps the name. The third sentence is the one that costs money to build.

What does the UAE actually require right now?

Less than most people assume, and more than most people notice.

The UAE Charter for the Development and Use of Artificial Intelligence, issued in June 2024, sets out twelve principles. Two are in play here: human oversight, and governance and accountability. It is a statement of principle. No cause of action, no penalty of its own. Nobody gets sued or fined under it.

That does not make it inert. Principles get borrowed into procurement conditions, internal audit criteria and regulator expectations long before they become statute. And the UAE regulates AI in layers rather than through one horizontal AI law: the Personal Data Protection Law where personal data is involved, sectoral regulators in their own domains, the Cybercrimes Law, the Charter, and the International Policy on AI above them.

Two structural changes since.

From January 2026 a National Artificial Intelligence System became an advisory member of the UAE Cabinet, the Ministerial Development Council, and the boards of federal entities and state-owned companies. The word to notice is advisory. It is the whole design: a seat without a vote. The system may propose. The people in the room decide, and carry it.

On 14 June 2026 the UAE Artificial Intelligence and Data Authority was established as a single national body reporting to the Cabinet, covering AI, data governance and digital government together. Putting those three under one authority tells you where the next round of questions comes from. They will be about records.

None of this settles the same problem in Saudi Arabia. Saudi Vision 2030 gives an entity there its mandate; it does not say who signs off a model’s recommendation.

What changes when a model sits in the decision path?

Nothing about who is accountable. A great deal about whether the accountability can be shown to anyone.

The answer to “why did we fund this” used to live in a paper, a minute and a name. Now part of the reasoning happened where no minute reached, arrived compressed into a recommendation with a confidence attached, and the human contribution was agreement. Agreement leaves almost no trace.

That is duller than the failure people worry about. Not a model going rogue. A decision trail reading “the analysis indicated X and we proceeded”, with nothing recorded about who read it or what they checked.

The version of this worry circulating in the industry is worth engaging with rather than repeating: agents are being deployed faster than AI governance adapts, and an agent cannot be an accountable entity. Both halves are true. The second half is not a reason to slow the agents down.

What does the record have to hold?

Six fields. None exotic. The discipline is capturing them at the moment of the decision rather than reconstructing them later.

The proposal as it was made. The recommendation in its own words, with its timestamp and the model version that produced it. Tidied up afterwards it stops being evidence and becomes a summary.

The evidence it drew on. Which records, as of when. A recommendation citing a KPI reading is only as defensible as that reading, and readings get revised.

The stated confidence. Recorded not because the number is precise, but so that “we were told this was a weak signal” and “we were told this was near certain” stay different entries later.

The decision, in three states. Accepted, modified, or rejected. Two states are not enough. Modified is where most of the human judgement in a working setup actually sits.

The name and the time. An individual, never a department, never a forum. The same rule the rest of portfolio governance already runs on, applied to a new kind of input. The individual can change; the field cannot be empty.

What the person changed, and why, in their own words. The quietest of the six and the most useful. One rejection with a one-line reason is an administrative artefact. Twenty of them describe where your model is weak on your portfolio, which no vendor can hand you. Rejecting has to be as cheap as accepting, or the record will overstate the model and understate the humans.

Where does this argument get worse if you push it?

Two places. The first is the weakest part of everything above, and doing the record properly is what produces it.

A signature that means nothing is worse than no signature. Require named human acceptance on every model output and, at volume, you manufacture rubber stamps. Six recommendations a morning can be read. Six hundred a month cannot. The name goes on anyway, because the workflow will not advance without it, and the record now asserts something false. Not a gap in accountability but a counterfeit, and harder to spot than a gap, because it looks exactly like compliance.

If you have a module already bought and a specification to write, that is the paragraph to argue with.

The record turns into a defence instead of a discipline. A well-kept trail is also a very good liability shield. “I accepted the recommendation, with its evidence and confidence attached, in line with policy” is a strong place to stand when the outcome is bad. Left unattended, the record becomes the mechanism that moves responsibility off the accepter and onto the process. Watch for the tell: the reasons field fills with “as per system recommendation”. Every field populated, and the accountability gone from the room.

There is a cost on the other side, and it should be named rather than waved at. A named accepter makes acceptance personally risky, and personally risky decisions get avoided. A recommendation to stop an initiative, correct and unwelcome, needs someone willing to attach their name to stopping it. Where being wrong is expensive, the safe move is to leave the item open and let events overtake it. So the field that creates accountability can suppress the decisions worth having. No software fixes that. A committee that visibly stands behind someone who accepted a hard recommendation that later turned out wrong might.

Which decisions actually need a name?

If not all of them, then which. Draw the line on consequence rather than on the technology involved.

Three tests, and one is enough to qualify. Does it move money, or change a commitment someone outside the organisation is relying on. Is it hard to reverse, so that re-sequencing two internal tasks and suspending a funded initiative are not the same kind of object. Would it need explaining in eighteen months, after the person who took it has moved on.

Anything that qualifies gets the six fields. Everything else is logged in batch and sampled, with a person accountable for the class rather than each instance. High-volume records work that way in other domains.

That narrows the counterfeit problem. It does not solve it. A sampled class still contains unread approvals carrying real names, and all you have done is make them fewer and cheaper to find.

Eighteen months on, an internal auditor asks for one thing: the recommendation as originally worded, and the name of whoever accepted it. The office produces the decision. Then the minute. Then, on the fourth day, a screenshot from somebody’s laptop. It gets written up as an observation rather than a finding, which is generous.

Try it on your own setup before someone else does. Pick a decision your entity took last quarter with a model in the path, and produce, in one sitting, the recommendation as it was worded, the evidence as it stood that day, who accepted it, and what they changed first. A week and three phone calls means the accountability lives in the policy, not in the record.

Common questions

Can we make the vendor accountable for what the model recommends?

Only for the product. A contract can allocate liability for defects, availability and misuse of data, and it should. It cannot transfer accountability for a funding decision: the vendor holds no mandate and answers to no board in your sector. Keep the two questions separate, because a procurement process that merges them settles the easier one and drops the other.

Is the UAE AI Charter enforceable?

Not by itself. The Charter, issued in June 2024, sets twelve principles including human oversight and accountability, but creates no cause of action and no penalty of its own. Enforcement arrives through the other layers: the Personal Data Protection Law, the sectoral regulators, the Cybercrimes Law. A management system standard such as ISO/IEC 42001 gives you an auditable structure to hold those principles in, which is faster than waiting to see what becomes statute.

What is the smallest change worth making this quarter?

Take one class of recommendation your teams already act on. Add three fields: who accepted it, when, and what they changed. Three fields on one class gives you something to show an auditor within a month, and it usually reveals that a surprising share of recommendations were being modified rather than accepted. Useful fact about your own people.

Where this comes from

We build TruMandate, a portfolio governance platform for government entities and large enterprises in the UAE and Saudi Arabia. Its AI reads the portfolio overnight and proposes; it holds no write access to the record. Every proposal carries the name of whoever accepted, modified or rejected it, and the moment they did. The argument above is why it was built in that order.

Topics

  • AI governance
  • Decision rights
  • Portfolio governance
  • EPMO
  • Public sector