AI Policy and Acceptable-Use Documentation
Policies that answer the questions employees actually have — can I put this in that tool, do I have to say it was AI-assisted, who approves this — rather than restating principles nobody disputes.
Most AI policies fail the only test that matters: an employee with a real question cannot find the answer in them. They affirm that AI will be used responsibly, ethically and in compliance with applicable law, and say nothing about whether you may paste a customer contract into a chatbot on a Tuesday afternoon.
AI policy and acceptable-use documentation sets out what employees may and may not do with AI tools, which tools are approved for which data, when AI-assisted work must be disclosed, who approves new uses, and what happens when the rules are broken — written specifically enough to be applied without interpretation.
The questions a policy has to answer
- Which tools may I use? Named, with the approved list maintained somewhere people will find it.
- What data may go into each? By classification, with worked examples rather than adjectives.
- Do I have to say it was AI-assisted? For which outputs, to whom, in what form.
- What must I check before using the output? Especially where it will be relied on by a customer or a colleague.
- What is never permitted? Named specifically, with the reasoning.
- How do I get something new approved? With a realistic turnaround, or people will not ask.
- What happens if I get it wrong? Including whether self-reporting a mistake is safe, which determines whether you ever hear about mistakes.
Write the data rules as a table people can check in ten seconds
'Do not input confidential information' is unusable, because nobody agrees on what that covers. A table mapping your actual data classifications to your actual approved tools, with examples of each, is what people will consult before pasting something. Everything else in the policy is read once at onboarding.
Where policies go wrong
| Failure | What happens | The fix |
|---|---|---|
| Written for the auditor | Nobody reads it; behaviour is unchanged | Write for employees; keep the audit mapping separate |
| Principles without rules | Everyone interprets it differently | Specific rules with named tools and examples |
| Blanket prohibition | Use moves to personal devices, unseen | Approved tools with clear data boundaries |
| No approval route | People proceed without asking | A route with a turnaround measured in days |
| Punitive on self-reporting | Mistakes are concealed | Safe self-reporting for good-faith errors |
| Never updated | Refers to tools nobody uses | A named owner and a review cadence |
The third row is the most consequential. A blanket ban does not stop AI use; it stops AI use you can see, and it moves your confidential data onto personal accounts where you have no visibility and no contract.
What we produce
The employee-facing policy
Short, specific and readable, with the data-to-tool table, the disclosure rules and the approval route. This is the document that changes behaviour; everything else supports it.
Role-specific guidance
Engineering, marketing, HR, legal, customer-facing and clinical teams have genuinely different questions and different risks. Short appendices per function work far better than one document attempting to serve everyone.
The approved tool list and its criteria
What is approved for what data, and how a new tool gets assessed. Maintained as a living list with an owner, because a static list is wrong within a quarter.
Disclosure standards
When AI assistance must be disclosed, to whom and how — for customer deliverables, published content, internal analysis, code and recruitment. Where the EU AI Act's transparency duties apply, they set a floor rather than the whole answer.
The approval route, with a service level
How someone proposes a new use, who decides, and how long it takes. Without a stated turnaround the route is theoretical, and people will reasonably conclude that proceeding is faster than asking.
The audit mapping, kept separate
How the policy maps to your governance framework, ISO 42001, the EU AI Act or customer questionnaires — in a separate document, so the employee-facing policy stays readable.
How the engagement runs
The policy is tested on real employee questions before it is published.
Current state
Existing policies, actual tool use including unsanctioned adoption, and the questions people are already asking.
Drafting
Employee-facing policy, data-to-tool table, disclosure standards and approval route drafted with legal, HR and security.
Testing
Real questions from real teams put to the draft; anything it cannot answer is fixed.
Role guidance and tool list
Function-specific appendices and the approved tool list with assessment criteria.
Rollout and handover
Communication, training and the review cadence, with a named owner.
What you receive
A policy that answers real questions, tested on the people who will have to follow it.
Employee-facing AI policy
Short and specific, with the data-to-tool table, disclosure rules and approval route.
Role-specific guidance
Short appendices for engineering, marketing, HR, legal and customer-facing teams.
Approved tool list
What is approved for which data, with criteria for assessing new tools and a named owner.
Disclosure standards
When AI assistance is disclosed, to whom and in what form.
Approval route
With a stated turnaround, so asking is faster than proceeding without asking.
Audit mapping
How the policy maps to your framework and external requirements, kept as a separate document.
Is this the right engagement?
Worth being direct. AI Policy and Acceptable-Use Documentation is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Employees are using AI tools and no clear rules exist.
- An existing policy is generic and nobody consults it.
- Confidential data has been pasted into a public tool, or you suspect it has.
- Different teams have reached different conclusions about what is allowed.
- A customer or auditor has asked for your acceptable-use position.
Choose something else if
- You need the governance operating model, not just documentation. See framework design.
- You want a document to satisfy an auditor with no intention of changing behaviour.
- A blanket ban has been decided and will not be revisited.
- No owner will maintain the policy or the tool list.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What should an AI acceptable-use policy contain?
Which tools are approved, what data may go into each, when AI assistance must be disclosed, what to verify before relying on output, what is never permitted, how to get a new use approved and how long that takes, and what happens when someone gets it wrong — including whether self-reporting is safe.
Should we ban AI tools outright?
It rarely works and usually makes things worse. A ban does not stop use; it moves use onto personal accounts and devices where you have no visibility, no contract and no audit trail. Approved tools with clear data boundaries give you the same risk reduction with the benefit of knowing what is happening.
How specific should the policy be?
Specific enough that an employee can answer their question without interpreting anything. Name the tools, map your actual data classifications to them in a table, and give worked examples. 'Do not input confidential information' is unusable because nobody agrees on what that covers.
Do employees have to disclose AI-assisted work?
That is your decision and it should be made explicitly rather than left ambiguous. Common positions require disclosure for customer deliverables and published content but not for internal drafting or research. Where the EU AI Act's transparency duties apply, they set a floor for customer-facing output rather than answering the whole question.
How often should this be updated?
At least twice a year, and whenever a significant new tool is adopted or a regulatory change lands. A policy naming tools nobody uses signals that the rules are not maintained, which undermines the parts that still matter. It needs a named owner and a review date.
Often paired with this
Most clients combine two or three engagements from the AI Governance, Security and Compliance pillar. These are the ones that most often run immediately before or after.
AI Governance Framework Design
Proportionate risk tiers, named accountability and decision rights — a framework people follow rather than route around.
Read more →Data Privacy for AI: GDPR, HIPAA and DPDP
Lawful basis, DPIAs, transfers, and the hard questions — deletion rights and retention inside trained models.
Read more →AI Inventory and Model Registry
A complete inventory including shadow and vendor AI, kept current by discovery rather than by annual survey.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.