Somebody in your business pasted a client document into an AI tool this week to summarise it. They were being efficient, they had no instruction telling them not to, and they will do it again on Monday.
That is not a hypothetical and it is not a failure of judgement. In the absence of a stated position, people reasonably conclude that anything not forbidden is permitted. Which means your business already has an AI policy. It is just distributed across every individual's private assumptions and written down nowhere.
This article covers what a usable policy contains, what two international standards say about governing this properly, and how to arrive at something your staff will actually follow rather than a document that exists to be pointed at.
Start with the sentence that does most of the work
If you do nothing else, write down what must never be entered into a general-purpose AI tool.
Typically that means personal data about customers or staff, anything covered by a confidentiality obligation to a client, unpublished financial information, credentials and security details, and source code where your agreements restrict it.
One sentence, circulated to everybody, addresses the majority of realistic exposure for a small or mid-sized business. Everything else in a policy is refinement around that boundary.
It is worth being clear about why this is the priority. The biggest practical risk here is not a dramatic model failure or regulatory action. It is a member of staff pasting a client's material into a free consumer account because it was the fastest way to finish something before a deadline. That single failure mode accounts for most of what can actually go wrong, and it is addressed by one clear rule plus providing decent tools.
Do not ban it
Bans rarely work here and they cost you the thing you most need, which is visibility.
Staff who find a tool genuinely useful will use it on a personal device or a personal account. The behaviour continues and your knowledge of it stops. A blanket ban converts a governance problem into an invisible governance problem, which is strictly worse.
Where a genuine prohibition is warranted, make it narrow, specific and explained. "Do not put client material into AI tools because our client agreements restrict disclosure to third parties" is a rule people follow. "AI tools are not permitted" is a rule people route around while feeling slightly guilty about it.
The general principle, which applies to shadow IT of every kind, is that the compliant route has to be easier than the non-compliant one. Our guide on shadow IT covers that dynamic in depth, and AI tools are a particularly sharp case of it because the useful ones are free and one click away.
There are actual standards for this
Two are worth knowing about, and neither requires you to certify against anything.
ISO/IEC 42001:2023 is the first international standard for artificial intelligence management systems, providing requirements and guidance for establishing, implementing, maintaining and continually improving one [1][2]. It sets up an organisation-wide management system covering leadership, planning, support, operation, performance evaluation and continual improvement across the AI lifecycle. In practice it asks organisations to define objectives and success criteria, conduct AI-specific risk assessments, implement controls proportionate to the risks identified, and maintain continuous monitoring [2].
If you have worked with ISO 27001, the shape will feel immediately familiar, because it is the same management system pattern applied to a different subject.
The NIST AI Risk Management Framework is built around four functions: Govern, Map, Measure and Manage [3].
| Function | What it covers |
|---|---|
| Govern | Policies, accountability, culture, and inventorying AI systems |
| Map | Understanding the context a system operates in |
| Measure | Tracking whether it performs as intended, on characteristics such as accuracy and security |
| Manage | Acting on what the measurement shows |
NIST has also published a crosswalk mapping its framework to ISO/IEC 42001 [4], which is genuinely useful if you find yourself looking at both and wondering how they relate.
Should you certify? Almost certainly not. Certification makes sense when a customer or regulator requires it, or when AI is central enough to your product that demonstrable governance is commercially valuable. For everybody else, read the standards as a checklist of what a competent approach covers. Reading the scope and clause structure of ISO 42001 is a short exercise that will change what you write, without committing you to an audit.
Inventory first, because you cannot govern a list you do not have
Both frameworks start in the same place, and so should you. The Govern function in NIST's framework includes mechanisms for inventorying AI systems [3][4], and it is the same principle that makes asset inventory the foundational control in security frameworks generally.
So find out what is actually in use. Which tools, by whom, for what.
How to run it without destroying your own data. Ask directly, frame it as wanting to make useful tools official rather than to remove them, and then honour that framing without exception. The first time somebody is criticised for an honest answer, disclosure stops permanently and you never get it back. Check expense records for subscriptions alongside the conversations, because the paid tools show up there and the free ones only show up if somebody tells you.
Most businesses find more than they expected and a few they would rather not have found. That discovery is the point of looking rather than a reason to be alarmed.
What the policy should contain
Six sections. Two pages. Written in language your staff would actually read.
What is prohibited outright. Keep this list short, because a long prohibited list gets treated as advisory. Personal data about customers or staff in general-purpose tools. Anything under a confidentiality obligation to a client. Credentials and security information. AI output as the sole basis for a decision materially affecting a person, without genuine human review.
What is permitted freely. This section matters as much as the prohibitions and is routinely omitted. Anything with no confidential input and no consequential output: drafting an internal first version, rewriting for clarity, summarising a public article, generating ideas, explaining an error message. A policy that only says no reads as general disapproval and gets quietly ignored in its entirety.
What needs approval, and from whom. With a named person and a stated response time.
What checking output means, by tier. More on this below.
What must be disclosed to customers.
Who owns the policy and when it is reviewed.
If your draft cannot fit on two pages, the usual cause is that it is trying to anticipate every situation instead of stating principles and naming somebody who decides the edge cases. A twenty-page AI policy is a document that exists to be pointed at, and everybody involved knows it.
A two-page policy, sketched
Since the recommendation is two pages, here is roughly what fits on them. Adapt the specifics; the structure is the point.
Purpose. One paragraph. We use AI tools because they save time. This document says what is and is not acceptable, so that nobody has to guess.
Never enter these into any AI tool. Personal data about customers, staff or candidates. Anything a client has given us in confidence. Unpublished financial information. Passwords, keys or security details. Source code where a client agreement restricts it. If you are unsure whether something falls here, ask before pasting rather than after.
Use freely for this. Drafting internal documents, rewriting for clarity, summarising public material, generating ideas, explaining errors, and anything else where nothing confidential goes in and nothing consequential comes out.
Approved tools and accounts. We provide accounts for the following tools. Use those rather than personal accounts, because the terms are different and we can support you. Requests for a new tool go to the named owner and get an answer within two working days.
Checking what comes out. Internal drafts: read it. Anything going to a customer: reviewed by whoever would have been accountable if a person had written it. Anything affecting a decision about an individual: genuine human judgement, and speak to the owner first.
Telling customers. Where AI materially shapes something a customer receives, we say so. If you are unsure whether a case qualifies, ask.
Owner and review. Named person. Reviewed every six months. Questions to them, and asking is always better than guessing.
That is the whole thing. It fits on two pages, a new starter can read it in four minutes, and it is specific enough to act on. Almost every AI policy that fails does so by being longer than this rather than shorter.
Provide accounts, do not rely on personal ones
This is the highest-value practical step after the prohibited list, and it is frequently skipped on cost grounds that do not survive examination.
Terms differ substantially between tools and between tiers of the same tool, on whether inputs are used for training, how long data is retained, and where it is processed. A business account with a provider frequently has materially different terms from a free consumer account with the same provider.
Company-provided accounts give you administrative control, better contractual terms, visibility of usage, and the ability to remove access when somebody leaves. Personal accounts give you none of those, and when the person leaves, whatever they put in goes with them and stays there.
The licence cost is almost always lower than the cost of the arrangement you currently have by default, which is unlimited use of unassessed free tools with your material in them.
If you permit a tool, permit a specific tier of it, and provide the accounts.
The confidentiality question people miss
Many client agreements restrict disclosure of client material to third parties.
Pasting a client's document into a third-party AI service is arguably disclosure to a third party. Whether it is in your specific case depends on your specific agreements and is a question for your legal adviser rather than for us.
The practical point is that most businesses have never asked it. They think about AI risk in terms of data protection and reputational exposure, and not in terms of contracts they have already signed. Check your client agreements before assuming either way, particularly if you work in professional services, and particularly for your largest clients whose agreements are usually the most restrictive.
Checking output, by tier
Everybody agrees that AI output should be checked. Almost nobody operationalises it, because "check the output" is not an instruction anybody can follow differently from what they were already doing.
State the tiers instead:
Internal draft. A read-through by the person using it. This is most usage and it needs no ceremony.
Anything reaching a customer. Proper review by somebody accountable for the content, who would have been accountable had a human written it.
Anything informing a decision about a person. Genuine human judgement applied, not a rubber stamp. If the human always agrees with the output, you do not have a review step, you have a formality.
That third tier deserves particular care around hiring and anything else materially affecting individuals. Involve your adviser before permitting it at all, and if you do permit it, restrict it to administrative support such as scheduling rather than evaluation or screening. The exposure there is legal and ethical rather than merely operational, and unfair outcomes are genuinely hard to detect from inside.
AI in your product is a different weight class
Everything above concerns internal use. If AI is in a product your customers use, the same governance applies with considerably more rigour, because you are now responsible for outputs reaching people at scale.
Document what the system does, what it is explicitly not suitable for, how you monitor its behaviour, and what happens when it is wrong.
That last one is where the NIST Measure function earns its place. Decide what good looks like before launch and instrument for it. Track the characteristics that matter for your use case, along with complaints, corrections and manual overrides.
A feature nobody measures degrades silently. AI features degrade in ways that are considerably less obvious than a crash, because the system keeps returning confident output the whole time it is getting worse.
Our guide on systems breaking when you grow covers instrumentation generally, and the addition here is that for an AI feature you are monitoring quality rather than only availability.
AI-generated code, specifically
Worth its own note because it is where most technical teams are already using this heavily.
The risk is not that the code fails to work. It is that it works, looks entirely reasonable, and carries problems that surface later: licensing questions about what was reproduced, security patterns that are subtly wrong, and code nobody on your team fully understands but everybody now depends on.
Our guide on the real cost of fast-built software covers where that leads over a couple of years.
The policy point is narrow and worth stating explicitly: require the same review for AI-assisted code as for anything else. Not more, which would be theatre, and definitely not less, which is the current default in a great many teams because the output arrives looking finished.
Data leaving the UAE
Most general-purpose AI services process data outside the UAE.
Where personal data is involved, that raises questions under data protection law about the basis for the transfer. Whether a specific transfer is permitted depends on the data, the basis and the destination, and belongs with a qualified adviser rather than with an article.
Our guide on PDPL compliance covers the framework. The safe default, and the one your one-sentence rule should encode, is that personal data does not go into these tools at all.
On UAE-specific AI regulation: the UAE has been active on artificial intelligence at national policy level for years and the picture continues to develop. Rather than summarising a position that may be out of date by the time you read this, check the current situation through official UAE government channels and with your adviser. What is stable is that your existing obligations around personal data apply to AI use exactly as they apply to anything else.
Making it stick
Three things separate policies that work from policies that exist.
Speed of approval. Handle new tool requests the way you would handle any software request, and handle them fast. A short form asking what it does, what data goes into it, what it costs and who else would use it, answered within two working days. If approval takes three weeks, people go around it and you lose exactly the visibility the process was created to produce.
Thirty minutes of training. A policy nobody has read is not a control. Cover what not to enter, which tools are provided and why, what checking output means in practice, and who to ask. Repeat for new starters. The conversation matters more than the document, which exists to support it rather than replace it.
A named owner and a six-month review. Senior enough to decide edge cases quickly, and not necessarily technical, because most of the decisions are about risk appetite and confidentiality rather than about how models work. Six months rather than annually, because this area moves faster than most policy areas. Attach the review to something already in the calendar.
One more thing, which is a culture point rather than a process one. When you discover somebody has already put confidential material into a tool, establish what was entered and when, check the provider's terms on retention and training use, take advice on whether any notification obligation arises, and then fix the conditions that allowed it.
Do not pursue the individual. A punitive response guarantees that the second incident is concealed rather than reported, and there is always a second incident. The goal of the whole exercise is to hear about it.
Where this sits alongside your existing work
AI governance should not be a parallel programme with its own structure and its own meetings.
AI tools are third-party services processing your data. That is a category your information security approach already covers in principle: asset inventory, access control, vendor assessment, data classification. Treat AI governance as an extension of that work rather than as something new.
The businesses that get this wrong build a separate AI committee producing separate documents that never connect to how software is actually approved or how data is actually classified. The result is more governance artefacts and no more control.
What this is not
Two clarifications, because AI governance attracts scope creep faster than most subjects.
It is not an ethics framework. Those exist, they are worth reading, and they are a different document with a different audience. A working policy answers what somebody may do on a Tuesday afternoon with a deadline. A statement of principles about fairness and transparency is a public commitment, and confusing the two produces a document that is admirable and unusable.
It is not a technology evaluation. Which model performs best on your tasks is a real question and belongs in a procurement conversation rather than a policy. Policies that name specific models date within months and then have to be revised for reasons that have nothing to do with governance.
Keep the policy about behaviour and boundaries. Let procurement handle tool selection and let any public statement of principles live separately, if you want one at all.
A realistic first version
Two pages, covering the six sections, produced in a week, imperfect, and actually circulated.
That beats a thorough document produced over three months and circulated to nobody, which is the more common outcome when a business decides to do this properly.
Write the prohibited list first, because it does most of the work. Provide proper accounts for one or two approved tools. Name an owner. Improve it at the six-month review with whatever the inventory turned up.
This week, the ten-minute version: write one sentence stating what must never be entered into an AI tool, and send it to everybody. Then start the inventory, which takes longer and will tell you what the rest of the policy needs to address.
If you want help, a policy and inventory engagement covering what is actually in use, what the risks are for your business specifically, and a written policy your staff will read starts from around AED 4,000 with us. Reviewing an AI feature in a product you are building is priced separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey. Legal questions about your obligations belong with a qualified adviser.
References
- ISO/IEC 42001:2023, artificial intelligence management systems
- ISO, AI management systems: what businesses need to know
- NIST, AI Risk Management Framework
- NIST, AI RMF to ISO/IEC 42001 crosswalk
- UAE Government, artificial intelligence
- SKIMBOX, shadow IT: the tools your team bought
- SKIMBOX, PDPL compliance in the UAE
- SKIMBOX, the real cost of fast-built software
- SKIMBOX, should your agency use AI
- SKIMBOX, your system breaks when you grow
ISO and NIST material is summarised here from the standards bodies' own published descriptions; the full standard texts sit behind paywalls in ISO's case. UAE regulatory activity on artificial intelligence continues to develop, so check the current position through official channels. This article is not legal advice.
