This page is narrower than the organisation-wide AI policy. It owns day-to-day user behaviour at the point of AI use.
| Action or situation | Allowed | Approval required or prohibited | Reason | Escalation route |
|---|---|---|---|---|
| Using an approved tool for a routine task | Yes | No | Within approved scope | None |
| Using an approved tool for a new task type | Not yet | Approval required | A new purpose can change the risk | Use-case owner |
| Entering personal data into a tool | Only within an approved use, tool and information class | Approval or specialist review if outside approved conditions | Data-protection and privacy | Privacy lead |
| Entering confidential business information | Only within an approved use, tool and information class | Approval or specialist review if outside approved conditions | Confidentiality and IP | Data owner |
| Using an unapproved tool | No | Prohibited | Unassessed risk | Security lead |
| Sharing AI output externally | Only within defined rules | Approval may be required | Confidentiality, accuracy and IP | Communications lead |
| Using AI in a regulated or high-impact decision | Not by default | Specialist assessment and approval required | Potential effect on people and legal duties | Legal or compliance lead |
| Continuing work after a suspected data breach involving an AI tool | No | Stop and escalate immediately | Incident response | Incident lead |
This table is illustrative. Your organisation must define its own categories based on local law, contract, risk appetite and tool capabilities.
What is an AI acceptable use policy?
An acceptable use policy is the operational rule set for AI use. It sits below the organisation-wide AI policy and the governance framework. It answers the question: "What can I do, what do I need to ask about, and what must I never do?"
The NIST AI RMF Core supports documented requirements, defined roles and third-party risk work. An acceptable-use policy is one way to document the user-facing requirements that flow from those governance decisions.
The policy should be clear, specific and actionable. It should not require users to make complex risk judgments; it should tell them what to do and when to ask.
How acceptable use differs from an organisation-wide AI policy
| Aspect | Organisation-wide AI policy | Acceptable use policy |
|---|---|---|
| Audience | All staff, governance leaders, approvers | Employees, contractors, authorised users |
| Focus | Strategic rules, decision rights, requirements | Day-to-day behaviour, point-of-use rules |
| Detail level | High-level requirements | Specific actions, tools, data categories |
| Change frequency | Changes when the governing model changes | Changes when tools or operating rules change |
| Enforcement | Governance review, audit | User acknowledgement, monitoring, escalation |
The acceptable-use policy should reference the AI policy and provide the specific guidance that makes the policy actionable at the point of use.
Decisions to make before adopting the template
Before adapting the template, your organisation should decide:
- Which tools are approved, restricted or prohibited.
- What data categories may enter each tool.
- What level of human review is required for different use types.
- What disclosure or attribution rules apply.
- What incident response steps apply to users.
- What training and acknowledgement are required.
- What exceptions process applies.
- What enforcement approach is proportionate.
These decisions are organisation-specific and must reflect local law, contract, risk appetite and tool capabilities.
Make the approved-tool decision specific enough to use. A vendor name on its own is rarely enough: record the service or feature, account type, approved purpose, permitted information classes and any required settings. A new AI feature inside familiar software may still change the data flow or purpose, so it should not inherit approval automatically.
Write each rule so that a person can act without guessing. Name who may perform the action, in which approved tool, with what information, what review is required and where the user must stop. Then name one real role or team that can answer the question. “Use AI responsibly” is a principle; “do not upload Restricted documents, and ask the data owner if classification is unclear” is an operational rule.
Copy-and-adapt AI acceptable use policy template
The following template is an editorial synthesis requiring local adaptation. It is not an official legal or regulatory template.
Scope and authorised users
This policy applies to all [employees, contractors, and authorised users] who use AI tools on behalf of [Organisation Name]. It covers all AI tools, whether provided by the organisation or accessed through personal accounts used for work.
Approved tools and accounts
The following tools are approved for use: [list or reference approved tools register].
Users must use only approved tools and approved accounts. Personal accounts may not be used for work tasks unless explicitly approved.
To assess an AI provider before adding it to the approved list, see the AI vendor risk assessment checklist.
Permitted uses
The following uses are permitted without additional approval:
- [List routine uses, e.g., drafting an internal outline from public information or summarising a public document]
- [List other permitted uses]
Permitted use still depends on the named tool, account, information class and review requirement. Approval for one routine task should not be read as permission for a new purpose or a more sensitive input.
Uses requiring approval
The following uses require prior approval from [defined authority]:
- [List uses that need approval, e.g., new task types, uses involving personal data above a certain classification, uses in regulated contexts]
- [List other approval-required uses]
The request must record [purpose, tool, information, intended output, affected people and owner]. Do not start the new use until the required decision and any preconditions have been recorded.
To assess a proposed use before approval, see the AI risk assessment template.
Prohibited uses
The following uses are prohibited:
- [List prohibited uses, e.g., using AI for regulated decisions without specialist review, entering restricted data into unapproved tools, using AI to generate content that misrepresents the organisation]
- [List other prohibited uses]
Keep this list short enough to remember. Put conditional activities in the approval-required category instead of labelling them prohibited and then relying on informal exceptions.
Data, documents and confidential information
- Only data classified as [classification level] or below may enter [specific tools].
- Personal data must be minimised: include only what is necessary for the task.
- Confidential and restricted information must not be entered into [specific tools] without prior approval.
- Documents entering an AI workflow must be classified and authorised before use.
- If you are unsure whether data may be entered, stop and ask [data owner or privacy lead].
To identify sensitive data before AI use, see the sensitive data classification guide.
Human review and output verification
- AI output must be reviewed before it is used in [decisions, communications, publications, etc.].
- Reviewers must be able to check the output against [source material, defined criteria or a responsible expert], rather than simply confirming that it looks plausible.
- Users must follow the organisation's attribution and disclosure rules when presenting AI-assisted work.
- Users must flag uncertain, incomplete or potentially harmful output for further review.
- The level of review depends on the risk tier: [define levels].
Human review is a control only when the reviewer has enough time, authority and information to challenge the output. Define what they check, what evidence they retain and what happens when they disagree.
Transparency and attribution
- Where required by law, contract or organisational policy, AI use must be disclosed to [affected parties, customers, etc.].
- AI-generated content must be attributed as such where required.
- Users must not conceal that AI was used in a task where disclosure is required.
Intellectual property and third parties
- Users must complete [the organisation's required provenance and IP review] before publishing or reusing AI output externally.
- Users must not enter third-party confidential information into AI tools without permission.
- The organisation's IP ownership rules apply to AI output: [reference IP policy].
Security incidents and escalation
- If you suspect a data breach, harmful output, or system failure related to AI use, report it to [incident lead] immediately.
- Follow the incident procedure; do not investigate, contain or remediate beyond your defined authority.
- Escalation path: [define levels and contacts].
- Post-incident, the user may be asked to provide details of the task, tool and data involved.
Records, training, exceptions and review
- Users must complete AI acceptable-use training within [timeframe] of starting or changing role.
- Users must acknowledge this policy [at onboarding and at each update].
- Exceptions may be requested from [authority] with documented justification.
- This policy is reviewed [at a locally defined interval] and after any material change in AI use, tool, or regulation.
Applying the rules to documents and uploaded content
When a document is uploaded to an AI tool, the following rules apply:
- The document must be classified before upload.
- The document must be authorised for the intended use.
- Only the minimum necessary content should be included.
- The tool must be approved for the document's classification level.
- Output containing document content must be handled according to the data classification policy.
These decisions come first. A document check can then add evidence about the exact file entering the approved workflow; it cannot decide whether the upload is authorised.
.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version for supported prompt-injection signals, hidden and instruction-like content, sensitive-information patterns, and links or active document surfaces. It will route the version to Approved, Needs review or Quarantine, with Approved versions kept in a private Library for reuse. The result does not authorise the upload, enforce this policy or establish universal safety; change the file and it becomes a new version to check.
To understand what the document checkpoint reports, see the what it scans page.
Training, acknowledgement and proportionate enforcement
Training should cover:
- What the policy requires and why.
- How to identify approved tools and permitted uses.
- How to handle data and documents.
- When to stop and escalate.
- How to report incidents.
Acknowledgement should be recorded and retained. Enforcement must follow the organisation's locally reviewed employment, contractual and security processes. Define who investigates, which evidence they consider, how a person can explain the circumstances and who decides the response. Do not turn the template into an automatic disciplinary scale.
The UK Government AI Playbook supports named ownership, lifecycle assessment, assurance, testing, escalation and change control. It was published in February 2025 for government organisations; private organisations may adapt its patterns.
Testing whether the policy works in practice
A policy is only effective if it is followed. Testing should include:
- Spot checks: are users following the rules?
- Incident review: are incidents being reported and resolved?
- User feedback: are the rules clear and actionable?
- Tool changes: do new tools or updates require policy updates?
- Audit: does the evidence show the policy is operating?
Keep the evidence layers separate. A published policy shows that a rule exists. Training and acknowledgements show that it was communicated. Access records, sampled work and incident handling can show whether selected controls operated. Only monitoring and review can tell you what outcomes occurred. One layer should not be used as proof of the next.
A small test is often more revealing than another policy clause. Give a sample of authorised users three harmless scenarios: a clearly permitted task, a task that needs approval and a prohibited upload. Check whether they choose the correct route, whether the route is easy to find and whether the named owner responds. Record the result, fix ambiguity and test again. This is an editorial example, not a prescribed audit method or pass mark.
The ICO's AI governance and accountability audit toolkit supports action tracking, reassessment on change, risk-register integration and risk-based audit. These are audit expectations focused on data protection; not every item is a freestanding statutory duty.
Frequently asked questions
What is an AI acceptable use policy?
It is the operational rule set for how people may and may not use approved AI tools. It tells users what is allowed, what needs approval, what is prohibited, what information may enter a tool, and when to stop or escalate.
What should it prohibit?
The prohibited uses depend on your organisation's risk appetite, legal obligations and tool capabilities. Common prohibitions include: using unapproved tools, entering restricted data into unapproved tools, using AI for regulated decisions without specialist review, and concealing AI use where disclosure is required.
Can employees put confidential information into AI?
It depends on the authorised purpose, information classification, provider terms, applicable law and contract, and the organisation's approved-tool rules. The policy should define what may and may not be entered, and what approval is required. When in doubt, the user should stop and ask.
Should staff disclose AI use?
Where required by law, contract or organisational policy, yes. The policy should define when disclosure is required and to whom.
Is an acceptable use policy enough to govern AI?
No. An acceptable-use policy is one component of AI governance. It sits within the wider governance framework and the organisation-wide AI policy. It addresses user behaviour but does not cover governance design, risk assessment, provider diligence, or monitoring.
To place these rules inside the wider AI policy, see the AI policy template for organisations.
