Free, private tool
AI acceptable use policy generator
Create a private, editable AI acceptable use policy in minutes. No signup; answers stay in your browser. Download a tailored Word draft.
A ready-made policy template is useful when you need a reference document. This generator solves the next problem: turning your organisation's own decisions into a working draft. It asks about approved tools, uses, data, incidents, accountability and review, writes the clauses that follow, and keeps unresolved decisions visible instead of disguising them as finished policy.
Nothing leaves your browser: Your answers describe your organisation's risk appetite and what data it holds, so nothing is submitted to a server. The policy and Word file are created in your browser. Saving is off by default; if you choose Save on this device, the draft is saved in this browser and can be removed by switching it off. The page's connect-src 'none' Content Security Policy blocks fetch, XHR, WebSocket, EventSource and sendBeacon. Anything you download or copy afterwards is yours to protect.
3 steps
Organisation, boundaries and governance
Private
Nothing is sent to a server
Editable
Download Word or copy Markdown
Start from your sector
A preset supplies useful boundaries and examples. It deliberately leaves your tools, owners and reporting routes for you to decide.
Draft progress
0 of 15 required decisions
Organisation and scope
Name who the policy covers, who owns it and when it starts.
Live policy draft
10 sections · version 2026-09-19
15 decisions still to make
- The organisation is not named.
- No policy owner or exception decision-maker.
- The people covered by the policy are not defined.
- No overall position on AI use.
- No tool classes recorded.
- No specifically approved tools or account tiers.
- No approved use cases.
- No controlled data classes beyond the universal credentials rule.
- No rule for business and personal accounts.
- No route to approve a new tool or use case.
- No incident and concern reporting route.
- It is not established whether the organisation builds or configures AI.
- EU AI Act scope remains unresolved.
- No effective date.
- No review cadence.
Staff companionAllowed · Ask first · NeverA concise summary for people who need the rules rather than the governance detail.
Using AI safely at your organisation
Allowed
- Use only tools and accounts named on the approved-tools register.
- Use AI only for a use case the organisation has approved.
- Check facts, calculations, citations and code before relying on or sharing the output.
Ask first
- A new tool, connector or use case: request it through the published approval route.
- Any personal, confidential, privileged or security-sensitive information.
- Any use that could materially affect recruitment, performance, access to a service, safety or another person.
Never
- Paste credentials, keys or secrets into an AI tool.
- Treat AI output as evidence or as an independent second opinion.
- Use AI to impersonate someone, fabricate evidence, evade controls or create deceptive synthetic media.
- Hide a mistake or accidental disclosure.
Ask the policy owner to publish the incident-reporting route before this summary is issued.
1. Purpose, scope and status
This policy governs the use of artificial intelligence tools at [the organisation: not yet named]. It applies to [the people covered by this policy: not yet decided], whether or not they use a device [the organisation: not yet named] provides.
The policy owner should read this draft against the organisation's industry, contracts and regulatory obligations before approval.
[No effective date set. A policy without a start date cannot be versioned, communicated or reviewed reliably.]
It covers tools bought deliberately and AI features that arrive switched on inside software already licensed.
2. Our position
[No position selected. Decide whether AI use is broadly enabled, permitted by role, or restricted to approved use cases.]
3. Approved tools, accounts and use cases
[No tool classes recorded. Inventory what is already in use before setting the boundary.]
[No named tools or account tiers recorded. A category alone does not tell staff which product or tenant they may use.]
[No approved use cases recorded. Name ordinary permitted work so the policy is usable rather than purely prohibitive.]
[No account rule recorded. Decide whether work is restricted to organisation-managed business accounts.]
[No approval route recorded. A prohibition without a workable approval path produces quiet non-compliance.]
4. Data handling
Credentials, keys and secrets must never be entered into an AI tool. Use an authorised secrets-management process instead.
[No additional controlled data classes selected. Decide whether personal, confidential, privileged, financial, HR or proprietary material needs an explicit boundary.]
5. Prohibited uses and human accountability
AI must not make a final decision about recruitment, performance, credit, access to a service, safety or another material outcome affecting a person without competent human review and an accountable decision owner.
Do not use AI to impersonate a person, fabricate evidence or citations, evade security controls, create deceptive synthetic media, or infringe copyright, contractual or licensing obligations.
AI output is a draft, not a source. Verify facts, calculations, citations and code through the same review, testing and approval process that applies to human work.
Do not present AI output as independent corroboration of something you already believe. It is not a second opinion.
6. Transparency
Tell people when they are dealing with an AI system rather than a person. Mark synthetic images, audio and video as machine-generated where they could reasonably be mistaken for real.
[EU AI Act scope is unresolved. 'Not sure' is a decision to investigate, not evidence that the organisation is outside scope.]
7. Incidents, concerns and exceptions
[No incident route recorded. People need a named, safe way to report accidental disclosure, unsafe output and unapproved use.]
Exceptions are decided by [policy owner: not yet named]. Every exception must record its scope, owner, reason, safeguards and expiry date.
8. AI literacy and support
[the organisation: not yet named] will provide material appropriate to each affected group: what the tools are for, how they fail, what must not go into them, and how to check output in that person's work.
The EU AI Act frames AI literacy as a duty to support development rather than guarantee a result. That is a useful operating standard whether or not the organisation is in scope.
9. Building, configuring and integrating AI
[The organisation has not said whether it builds or configures AI. Resolve this because builders need inventory, testing, permissions and impact controls that ordinary users do not.]
10. Ownership, acknowledgement and review
This policy is owned by [policy owner: not yet named], who is responsible for keeping it current, maintaining the approved-tools record and deciding or routing exceptions.
The policy owner must decide whether acknowledgement is required and how communication will be evidenced.
[No review cadence set. An undated, unreviewed AI policy becomes unreliable quickly.]
Breach is handled through the organisation's normal disciplinary or contractual process, proportionate to intent, impact and whether the person reported the issue promptly.
Inventory before policy
The most common mistake in an AI policy is writing it before knowing what is already in use. Policy without an inventory governs a landscape nobody has mapped: it prohibits tools teams already depend on, which guarantees quiet non-compliance, and it misses the tools nobody thought to name. The governance conversation then turns adversarial at exactly the moment you need people to tell you what they are using.
Measure first. Network and SaaS telemetry will show which AI services are actually in use, and the answer is almost always broader than the one you would get by asking. Then write rules that legitimise the safe majority and name the boundaries clearly enough that the genuinely risky cases come to you voluntarily.
The three postures
This is the decision everything else follows from, and it cannot be delegated to the reader of the policy.
Enable broadly, with boundaries
Approved tools are available to everyone, with clear rules on what must never go in. Suits organisations where the work is largely non-sensitive and shadow use is already widespread.
Enable by role, with review
Access follows role and data exposure, and higher-risk uses need sign-off. The common landing place, and the one that survives an audit best.
Restrict to approved use cases only
Nothing is permitted until a named use case is assessed and approved. Appropriate for regulated work and for anyone handling special category data at scale.
A note on prohibition. A blanket ban rarely stops use. It stops disclosure, and the use continues on personal accounts and personal devices where you have no visibility at all. If you choose the restrictive posture, the route to get a use case approved has to actually work, or you have written a prohibition in name only.
What the policy can cover
- General assistants (chat, drafting, research)
- AI features inside software you already licence
- Coding assistants
- Meeting transcription and note-takers
- Agents that take actions on your behalf
- Image, audio or video generation
The second entry is the one organisations forget: AI features that arrive switched on inside software already licensed, which nobody chose and nobody assessed.
Boundaries worth naming
- Personal data about identifiable people
- Special category data (health, biometrics, beliefs)
- Client or customer confidential information
- Unpublished financial information
- Credentials, keys and secrets
- Proprietary source code
- Legally privileged material
- Employee records and HR case material
Naming none tells staff that the judgement is entirely theirs, which is the position a policy exists to avoid.
From draft to daily practice
Issue the policy, then make it usable
Approval is the midpoint. A policy changes behaviour only when staff can find the current rules, identify approved tools and report a mistake without searching through a long document.
- Route the draft through Legal, Privacy, HR, Security and the accountable business owner.
- Publish a named approved-tools register, including the permitted account or tenant for each product.
- Train each affected group on the tools, failure modes and data boundaries relevant to its work.
- Give staff the one-page Allowed, Ask first and Never summary, and retain evidence of communication.
- Record exceptions with an owner, safeguards and an expiry date instead of allowing permanent verbal waivers.
- Test the approval and incident routes, then schedule the review date and review sooner after material change.
Use the data
The question set, postures, data classes and tool classes are published as JSON under CC BY 4.0, currently version 2026-09-19. The policy prose is composed from your answers in your browser. If you need a reference before making those decisions, start with the practitioner-written template and return here when you are ready to tailor it.
What this is not
It is not legal advice, and it is not a finished policy. It is a working draft assembled from decisions you made, which is a good deal further along than a blank page but still needs reading by whoever owns risk in your organisation and approving through whatever process you use.
It also cannot make the decisions. That is deliberate: the parts of a policy that matter are the parts only you can answer, and a template that fills them in with something plausible is worse than no template at all, because it produces a document that reads as complete and commits you to nothing.
Common questions
›Is this a finished policy I can just issue?
No, and any tool telling you otherwise is selling something. It is a working draft built from your decisions, which is a great deal further along than a blank page or a generic template, but it needs reading by whoever owns risk in your organisation and approving through whatever process you use. Anything left in square brackets is a decision nobody has made yet and must be resolved first.
›Why does it leave square brackets in the text?
Because an unmade decision dressed as a finished sentence is how bad policies get approved. A template that says 'the organisation will take appropriate measures' reads as complete and commits you to nothing. If you have not decided which data must never be pasted into an AI tool, the policy should say that loudly enough that a reviewer notices.
›Does this satisfy the EU AI Act's AI literacy obligation?
It helps and it is not sufficient on its own. Article 4, as replaced by Regulation (EU) 2026/1744, requires providers and deployers to take measures supporting the development of AI literacy. A policy states the boundary; the literacy duty is about the support you provide alongside it. The generated policy covers both and points at what the training has to do, but the training itself still has to exist.
›What is the most common mistake in an AI policy?
Writing it before knowing what is already in use. Policy without an inventory governs a landscape nobody has mapped: it prohibits tools teams already depend on, guaranteeing quiet non-compliance, and misses the tools nobody thought to name. Measure first with network and SaaS telemetry, then write rules that legitimise the safe majority and name the boundaries.
›Should the policy prohibit AI use outright?
Rarely, and it usually backfires. A blanket prohibition does not stop use; it stops disclosure, so the use continues on personal accounts and personal devices where you have no visibility at all. A restrictive posture is appropriate for regulated work and for special category data at scale, but it needs a working route to get a use case approved or it becomes a prohibition in name only.
›Does the file carry any branding or tracking?
The Word document carries a provenance block naming the tool and standards behind the draft so a reviewer can trace it. It contains no tracking. The file is written in your browser, and the page's connect-src 'none' policy blocks fetch, XHR, WebSocket, EventSource and sendBeacon.
When you need more than a tool
AI Consultancy
Strategy-first AI advisory: which AI systems and agents your business actually needs, and how to adopt them safely under NIST AI RMF, the EU AI Act, and the UK's principles-based approach.
Book a consultation
