AI Use Policies for Organisations
A ban does not stop use. It stops disclosure.
What is AI policies?
An AI use policy is a short written statement naming which AI tools staff may use, which data may go into them, and how to ask for something new, written to be read rather than to be filed.
Start from what is already true. Staff in most organisations are using these tools now, on personal accounts, without telling anybody, because the tools are useful and nobody said otherwise.
That means a policy is not deciding whether AI gets used. It is deciding whether the use is visible. A policy banning everything produces the same usage on personal phones, where you cannot see it, control it or clean it up.
So the useful policy is permissive and specific. It names tools by name, states plainly what may never be typed into them, and gives people a route to ask about something new rather than leaving them to choose between complying and hiding.
The policy we will not write
Duara writes AI use policies for organisations in Kenya, short enough that staff read them and specific enough that they can be followed.
We will not write you a policy that bans everything. If you ask for one we will say what it produces, which is the same usage moved onto personal accounts where nothing you write reaches it.
Who this is for
- Staff are already using AI tools informally
- You have no written position
- An existing policy is ignored
- Managers are being asked what is allowed and have no answer
Industries we serve
- Financial services
- Professional services
- Healthcare
- Public sector
- Education
- Any organisation with staff and confidential material
Problems this solves
These are the reasons AI policies fail, and none of them are about the writing.
- The policy bans everything. Usage moves to personal accounts and personal phones, which is the same activity with none of the visibility.
- Too long to read. A policy needing a summary has already failed, because the person deciding at four in the afternoon will not open either document.
- Too vague to follow. Approved tools and confidential information mean nothing to somebody choosing whether to paste a spreadsheet into a chatbot.
- No way to ask. Without a request route the only options are comply or hide, and people pick hide because it is easier.
What we deliver
A short policy naming specific tools and specific prohibited data, with a route to request something new and a review point for when the tools change.
A policy short enough to read in one sitting
Approved tools named individually
Prohibited data named by category
A route to request something new
Review points as tools change
Guidance for managers answering questions
Features
- Permissive and specific. Naming what people may do gives them somewhere to go, which is the only version of this that changes behaviour.
- Tools named individually. A category description is unusable at the moment somebody has to decide, and the moment of decision is the point of the document.
- Prohibited data named plainly. Identity numbers, salary data and unpublished results rather than confidential information, which everybody interprets differently.
- A request route that works. Somewhere to ask about a new tool, because without one the alternative to compliance is concealment.
- Reviewed as tools change. A policy written eighteen months ago names products that no longer behave the way it describes.
Benefits
- Usage becomes visible. Permitted tools with rules produce activity you can see, which banned tools never do.
- Staff stop guessing. People asked to use judgement without guidance make inconsistent decisions and blame the organisation afterwards.
- Managers can answer. A specific policy means a manager asked on the spot has something to say beyond checking with somebody.
- Your other policies keep their weight. An unenforced policy teaches staff that policies are decorative, and that lesson does not stay in one place.
What a policy has to say
- Named approved tools. Specific products rather than categories, since categories cannot be applied at the moment of decision.
- Named prohibited data. The categories your staff actually handle, described in their words rather than in legal ones.
- A request route. How to ask about something new, without which the only alternative to compliance is hiding.
- Accountability for output. Who is responsible when an AI answer turns out to be wrong, which is always a person rather than a tool.
- Review points. When the policy gets looked at again, because these tools change faster than policy cycles.
The prohibited data list is the part that gets used. If somebody remembers one thing from the document it should be what must never be typed into a public tool, so that section is written to be memorable rather than complete.
How the process works, step by step
A policy usually takes one to two weeks. Most of that is finding out what staff are already doing.
-
Step 1
Free position call
We establish what exists now, formally and informally, since the informal position is the one that matters.
-
Step 2
Actual usage established
What staff are already using and for what, because a policy written against imagined behaviour changes nothing.
-
Step 3
Tools and data decided
Which specific products are approved and which specific data may never go into them.
-
Step 4
Written short
One sitting to read. If it needs a summary it is too long and we would rather cut it.
-
Step 5
Communicated and reviewed
Given to staff with guidance for managers, and a date to look at it again.
Quality assurance and how we work
The commitments attached to writing something your staff have to live under.
- We will not write a blanket ban. It produces the same usage on personal accounts, and we would rather tell you that than take the work.
- We keep it short deliberately. A policy that needs a summary has failed, because nobody opens either document at the moment they need it.
- We name tools rather than categories. A category is unusable when somebody has to decide, and the decision is the whole purpose of the document.
- We ask what staff are already doing. A policy written against imagined behaviour changes nothing, and the honest answer is usually more than management expects.
- We say a policy is not compliance. It is one part. What your systems actually hold and where they process it is a separate question with separate obligations.
Frequently asked questions about AI policies
Can a policy simply prohibit everything?
It can, and it does not stop use, it stops disclosure. The same activity moves to personal accounts where nothing you write reaches it.
Are our staff really using these already?
Almost certainly. The tools are useful, freely available and nobody told them not to, which is enough on its own.
How long should a policy be?
Short enough to read in one sitting. If it needs a summary, the summary is the policy and the rest is decoration.
Why name specific tools?
Because a category is useless at the moment somebody has to decide, and that moment is the entire purpose of the document.
What if an approved tool changes?
That is what review points are for. A policy written eighteen months ago describes products that no longer behave that way.
What data should be prohibited?
The categories your staff actually handle, named plainly. Identity numbers and salary data rather than confidential information.
Why does a request route matter?
Without one the only options are comply or hide, and people choose hide because it is easier and nobody notices.
Who is accountable for a wrong AI answer?
A person, in every case worth writing down. Naming who that is beforehand prevents an argument at the worst moment.
Does a policy make us compliant?
No. It is one part. What your systems hold and where they process it is a separate question with its own obligations.
How do we enforce it?
Mostly by making compliance easier than avoidance, since enforcement through monitoring alone rarely survives contact with a busy week.
What if nobody follows it?
That teaches staff policies are decorative, and the lesson does not stay confined to this one.
Should different departments have different rules?
Sometimes. Teams handling patient or financial records need tighter limits, and saying so is better than one rule pitched at the strictest case.
Do we need staff to sign it?
It helps establish that people saw it. It does not establish that they read it, which is what the length is for.
How long does writing one take?
One to two weeks, and most of that is finding out what staff are already doing rather than drafting.
Can you write it for a regulated business?
Yes, and your sector regulator obligations sit alongside this rather than being replaced by it.
What about tools built into software we already pay for?
Those need naming too. Features appearing inside existing products are the most common thing a policy silently fails to cover.
Should the policy cover customers seeing AI output?
Yes. Whether customers are told they are dealing with an AI system is a decision worth making deliberately rather than by default.
Can managers approve exceptions?
Define who can and write it down. Undefined discretion produces inconsistent decisions and arguments afterwards.
Who sees what we tell you about current usage?
Only the people writing the policy, under whatever confidentiality terms you set before we begin.
What does a policy cost?
Organisation size and how many departments need distinct rules determine it, quoted after the position call.
Glossary of terms
Policy terms in plain language.
- Shadow use
- Staff using tools nobody approved, which is the normal starting position rather than an unusual one.
- Approved tool
- A specific named product staff may use, as distinct from a category nobody can apply.
- Prohibited data
- Categories that must never be entered into a public tool, named in the words staff actually use.
- Request route
- A way to ask about a new tool, without which the alternative to compliance is concealment.
- Review point
- A date to revisit the policy, needed because these tools change faster than policy cycles.
- Accountability
- Who answers for a wrong AI output, which is a person in every case worth writing down.
Related services in AI Compliance
Talk to us about AI policies
Ask three staff what AI tools they used this week. The answers tell you what your policy actually has to address.
Start your project