Most AI policies fail the same way. They are written by someone who has read about the technology rather than watched it being used, they prohibit the work the business actually does, and staff route around them within a fortnight. A quietly ignored policy is worse than none, because it leaves you a document you can be held to and a practice nobody follows.
This article describes drafting practice at a general level. It is not legal advice, and the regime governing your company depends on where each entity is incorporated, what it is licensed to do and what you have promised clients.
What the document is actually for
An acceptable-use policy has one job: to give every member of staff a fast, correct answer to the question "can I put this into that tool?" Everything else in your governance framework can be internal. This one has to survive contact with a sales executive at 6pm finishing a proposal.
That rules several things out. It is not an explainer on how the technology works. It is not a summary of the data protection law you sit under, although it must be consistent with it. It is not a list of approved products, because that list changes monthly and the policy should not. Keep it to conduct: what people may do, what they may not, and who to ask.
Three things to decide before you write
Drafting goes badly when these are left open, because every clause then has to hedge.
- Your default position. Is unlisted tooling permitted until prohibited, or prohibited until approved? Choose the second and soften it with a fast approval route; the first is unenforceable the moment anyone asks for evidence.
- Who approves. One named person with a deputy, and a stated turnaround. A committee that meets monthly will be bypassed by week three.
- What regime you are writing under. Federal, DIFC or ADGM. If your group spans more than one, decide now to write to the highest standard in the group rather than the average.
The ten clauses
What follows is an annotated outline rather than a template to paste. The annotations matter more than the headings, because the drafting is where policies go wrong.
Scope and who it binds
Everyone who does work for the company, not only employees: contractors, secondees, agency staff, interns and anyone on a consultancy agreement. Say explicitly that it applies on personal devices and accounts whenever the work is the company's, because that is where most uncontrolled use happens.
A plain definition of the tools covered
Define by behaviour, not by technology or brand: any tool that generates, summarises, translates, classifies, transcribes or predicts. This is the clause that catches AI features quietly added to software you already license, which staff never think to ask about.
The approved list and how to get on it
State that an approved list exists, where it lives, and that the current version is the one that counts. Then give the request route: who to ask, what to supply, and how long an answer takes. A policy that prohibits without offering a path creates shadow use rather than preventing it.
What may never be entered
Write this as categories of information, never as a list of tools. Identified personal data, health information, client material held under a confidentiality obligation, unpublished financial results, credentials and access keys, anything marked restricted, and anything a client contract says stays in a particular jurisdiction. Put a worked example beside each, in your own business language.
Personal accounts and consumer tiers
Consumer accounts carry different terms from the ones your company negotiated, and in many products no retention control and no audit trail. Say that plainly, then prohibit their use for work. Pair the clause with an amnesty window at launch, during which anyone can declare existing use without consequence, because the alternative criminalises half the staff on day one.
Human review before anything leaves the building
Name the categories that require review and the role that performs it: external-facing output, anything that reaches a client, and any decision affecting a person, including candidates and staff. Require that the review is recorded, because an oversight control with no evidence behind it will not survive a client questionnaire.
Disclosure
Set out when the company tells a client, candidate, patient or counterparty that AI was used. Err towards telling. Disclosure rarely costs a deal; the reverse discovery, where a client finds out from the file metadata, costs the relationship.
Accuracy and ownership of output
The person who sends it owns it. No generated citation, figure, quotation, legal reference or contact detail goes out unchecked against the source. This clause is short and does more work than any other, because it settles accountability before an incident rather than during one.
Incident reporting
Define an incident in ordinary language: information entered by mistake, an incorrect output that was acted on, a vendor notification, or a suspicion that any of those happened. Give one reporting route, a time expectation, and an explicit statement that prompt, good-faith reporting will not be treated as misconduct. Without that last line you hear about incidents late or not at all.
Consequences, related policies and review date
How breaches are handled, which existing policies this one sits alongside (data protection, IT acceptable use, confidentiality, the staff handbook), and the date it will next be reviewed. A named review date signals the document is alive and gives you a moment to fix anything unworkable.
Wording principles
- Write prohibitions as categories of information, not as lists of products. Product lists are stale within a quarter and teach staff to look for the gap.
- Use the second person. "You may not" is read and remembered; "employees shall not" is skimmed.
- Put a permitted alternative next to every prohibition. A rule with no route attached is an instruction to hide.
- Name a person, not a department. Departments do not answer questions on a Thursday afternoon.
- Aim for something readable in one sitting. Longer than a coffee, and the induction pack is the last time anyone opens it.
- Do not define terms you never use again. Each unused definition costs a paragraph of attention you needed elsewhere.
- State the default when the policy is silent: ask first. That line covers the cases you did not anticipate, which will be most of them.
How it sits with your data protection regime
The clause about what may never be entered is where the policy meets the law, and which law depends on where the entity is incorporated. A mainland UAE company sits under the federal regime established by Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data. A company incorporated in the Dubai International Financial Centre follows DIFC Data Protection Law No. 5 of 2020, and one in Abu Dhabi Global Market follows the ADGM Data Protection Regulations 2021, each administered by its own commissioner.
At the level this policy operates, the practical questions are the same in all three. Is this processing of personal data? Does the tool move that data outside the jurisdiction, and on what basis? Have the people whose data it is been told? Can the company show afterwards what it decided and why? None of those questions is new and none was written about AI. The policy makes them answerable by a member of staff at speed rather than by a lawyer afterwards.
Two drafting consequences follow. Name your regime in the policy, so a reader knows which one governs them. And write the restricted-categories clause to the highest standard among your entities rather than to each separately, because one document everybody shares beats three precise ones nobody can tell apart. The wider regulatory picture sets out which door each obligation arrives through.
Roll-out and training
A policy issued as an email attachment has a half-life of about a week. The roll-out that works has an order. Brief managers first, alone, so they are not hearing it for the first time in front of their teams. Launch with the amnesty window and say what it is for. Then run short sessions by function, using your own documents and your own near-misses rather than generic slides, because a finance team and a marketing team worry about entirely different things.
Collect an acknowledgement from everyone: dull, and the first thing a client questionnaire asks for. Put the policy and the approved list where staff already go rather than where governance documents traditionally live, and add both to the induction pack that week, so the next joiner never knows a version of the company without them.
Review cadence
Review the approved list quarterly, since tooling changes faster than conduct rules do, and the policy itself annually. Between those, treat four events as triggers regardless of the calendar: new guidance from the commissioner or regulator that governs you, a new licensed activity or jurisdiction, any incident the policy did not cleanly answer, and a merger that imports another company's habits overnight.
Record each review even when nothing changes. A dated line confirming the policy was reviewed and found still fit is evidence of a functioning control, and it takes a minute. For the wider control set this document sits inside, work through the twenty-eight point governance checklist.
If you would rather have the policy drafted against your own regime, licence and client contracts than assembled from an outline, message Hayat Advisory on WhatsApp with where your entities are incorporated and how many people it would bind.