AI governance for companies selling to UAE government entities

Public-sector buyers in the UAE have started asking suppliers where their AI runs, whose model sits underneath it and who checks the output. The questions turn up in vendor questionnaires, in information-security annexes and increasingly in the scored part of a tender. They are answerable, and the companies that lose marks on them are usually losing marks for having no document rather than for having a weak position.

Why the AI questions arrived

A government buyer carries obligations about the data it holds and about the outcomes its services produce. When it engages a supplier, those obligations do not transfer, they extend. If your product summarises case files, drafts correspondence, ranks applications or analyses images, the buyer has acquired a process it cannot fully see, and its own assurance function will eventually ask about it.

This is why the questions arrive even for suppliers who think of themselves as having nothing to do with AI. A translation service, a call centre, a design agency, a facilities contractor and a software integrator have all, by now, put some part of their delivery through a tool the buyer has never assessed. The questionnaire is asking about that, not about whether you build models.

What the questionnaires ask

The wording varies and the underlying set is stable. Six themes cover almost all of it.

• Data classification and handling. What categories of the buyer's data will your AI-enabled process touch, and how are the more sensitive categories handled differently from the rest.
• Residency and cross-border movement. In which countries is data processed, stored, backed up and accessed for support, and does the answer change for any sub-processor.
• Sub-processors and model provenance. Who sits behind your service, which models does it use and who supplies them, and how is the buyer told when that list changes.
• Human oversight. Which steps in your delivery are automated, which are reviewed by a person, and who that person is.
• Incident notification. How quickly you tell the buyer about a security or quality incident, through which channel, and to whom.
• Assurance and certification. What independent evidence exists that your controls operate rather than merely being documented.

The generic buy-side version of this exercise, useful because it shows you what a competent buyer is looking for, is the twenty vendor questions. Reading it from the other side of the table is the fastest way to find out where your own answers are thin.

Answering with evidence rather than assurances

The difference between a strong answer and a weak one is rarely the underlying practice. It is whether the answer points at something the buyer could inspect.

• Weak. We take data protection extremely seriously and follow industry best practice.
• Strong. Delivery under this contract uses two AI-enabled tools, listed in our AI register with the version and the processing location for each. Both are on business tiers with training on customer content disabled, and the register is reviewed quarterly by our named accountable officer. The register can be provided on request.

Note what the strong answer contains: a countable claim, a named artefact, a named owner, a cadence and an offer to show it. Note also what it does not contain, which is any promise about the future or any adjective. An evaluator scoring twenty submissions can verify the second answer and cannot do anything with the first.

Two habits make this repeatable. Write the answers once as a reusable response library rather than drafting each bid from nothing, and never assert a control in a bid that you cannot evidence within a working day. An answer that survives the tender and fails the audit is worse than a modest answer that holds.

Certifications a buyer may expect

Two standards come up most often. ISO/IEC 27001 is the established information security management standard, and for many public-sector buyers a current certificate is either required or scored. ISO/IEC 42001 is the more recent management system standard for artificial intelligence, and it is beginning to appear in questionnaires as a desirable rather than a mandatory item. Confirm the current expectations for your own sector and buyer, since these requirements move, and read the scope statement on any certificate you rely on.

Three points of realism. A certificate covers a defined scope, and a buyer who looks will check whether the scope includes the service being bought. Certification is a project with a cost and a lead time, so it is a decision about pipeline value rather than a box to tick before the next deadline. And an uncertified supplier with a clear register, a policy and evidence of review often scores better than a certified one who cannot describe how AI is used in delivery.

If certification is out of reach this year, say what you do instead and show it. Buyers discount vague claims, not modest ones.

The clauses that flow down to you

Public-sector contracts increasingly carry terms that reach past your company into your supply chain. Read them before signature rather than after an incident.

• Restrictions on where the buyer's data may be processed, which can rule out tools your team uses daily.
• A requirement to disclose and seek approval for sub-processors, including a change of model provider.
• A prohibition on using the buyer's data to train or improve any model, which you must be able to pass to your own vendors.
• Notification windows for incidents, measured in hours, with a named contact.
• Audit and inspection rights, sometimes extending to your suppliers.
• A requirement that outputs affecting a member of the public are reviewed by a person before they are relied on.

The commercial risk is accepting an obligation you cannot pass upstream. If your contract prohibits training on buyer data, your own tool contracts need the same prohibition in writing, not a setting in a dashboard.

What to prepare before the next tender

Five artefacts answer most of what a buyer asks, and a company of twenty to two hundred people can assemble them without outside help.

• An AI register. Every AI-enabled tool used in delivery, with owner, purpose, data touched, processing location and approval status.
• A short acceptable-use policy. One page that staff have acknowledged, covering approved tools and what may not be put into them.
• A human-oversight statement. Which steps are automated, which are reviewed, and by whom.
• A sub-processor list. Named, dated, with a stated process for notifying customers of changes.
• An incident procedure. Who is told, how quickly, through which channel, with a rehearsed contact path.

The detailed control set behind those five is the governance checklist, and the policy itself is covered in the acceptable-use piece.

A 30-day sequence

• Week one. Build the register by asking delivery teams what they use, not by asking IT what is licensed. Name one accountable person for it.
• Week two. Get the residency, retention, training and sub-processor answers from each vendor in writing, and file them where a bid writer can find them.
• Week three. Write the human-oversight statement and the incident procedure, and issue the one-page policy with acknowledgements.
• Week four. Turn all of it into a reusable response library, pull the AI questions out of your last three submissions, and rewrite each answer to point at an artefact. Decide the certification question on pipeline value and put a date on it.

The output is not a compliance programme. It is a folder that makes the next submission faster and harder to mark down, and that a buyer can actually inspect.