AI Acceptable-Use Policy: A Practical Template for Employees and Managers

Write a policy employees can apply

“Use AI responsibly” is an aspiration, not an operational instruction. An employee deciding whether to paste a support ticket into a chatbot needs a concrete answer about the tool, information and purpose.

A useful policy identifies approved uses and gives people a route for uncertain cases. It should allow appropriate experimentation without making every employee invent a privacy or security assessment. NIST's generative AI profile discusses acceptable-use governance and risks such as unreliable outputs and sensitive-information exposure.¹ The original draft below translates those concerns into workplace decisions; it is not a NIST policy or approved legal document.

Separate tool approval from use approval

An enterprise subscription does not approve every task, connected data source or plugin. A drafting tool approved for public marketing copy may remain unsuitable for customer complaints, confidential contracts or consequential employment decisions.

Maintain a small approved-use register: tool and account configuration, permitted task, allowed data, output reviewer, restrictions, owner and review triggers. When the supplier adds a connector or changes retention terms, review that change before expanding access.

Use clear internal categories. For example: public material; ordinary internal information; confidential business information; personal information; and credentials or highly restricted records. These categories are a proposed management aid, not a substitute for your existing classification rules or applicable law.

Original AI acceptable-use policy draft

Replace bracketed fields and have the responsible reviewers approve the final wording.

1. Purpose and coverage

“This policy governs use of AI tools for [organization] work by [covered staff and contractors]. It includes AI features embedded in existing applications and use through personal accounts for work purposes. The policy owner is [name/role]. Questions go to [monitored internal route].”

Identify which activities are governed elsewhere, such as secure software development or regulated decision processes. A policy that silently excludes embedded AI misses an important part of actual use.

2. Approved tools and tasks

“Use only tools and configurations listed in [approved register] for the tasks listed there. Approval of one task does not authorize new data categories, connectors, external actions or decision uses. Request a review before changing the approved purpose.”

Give staff a visible way to check the current register. Do not publish secret credentials or private vendor assessments in it.

3. Information that may be shared

“Share only the minimum information needed for the approved task. Do not enter passwords, access tokens or recovery codes. Do not enter restricted, customer, employee or confidential information unless the approved-use record specifically permits that category and processing. Removing a name alone does not establish anonymity.”

Add examples from the business: public brochure paragraphs may be allowed; a spreadsheet of customer disputes may require a separate review. A blanket claim that prompts always train a model is inaccurate; supplier behavior varies and must be verified for the specific service and settings.

4. Human review and accountability

“The person using an output remains responsible for its approved business use. Review factual claims, calculations, citations, confidential content and suitability before sharing or acting. Do not present unverified output as a verified fact or professional conclusion.”

For material decisions, define an accountable reviewer with the expertise and authority to reject the output. A required click on an approval button is not meaningful review by itself.

5. Uses requiring separate review

“Do not use AI to make or recommend consequential decisions about individuals, provide regulated advice, commit money, alter access, or execute external actions unless the use case has received the required approval under [relevant process].”

Tailor the list. HR, legal, clinical, credit and safety-related activities may have particular requirements. Seek appropriate expertise rather than copying another company's permission rules.

6. Incidents and mistakes

“Report accidental sharing, unexpected access, unsafe outputs or unauthorized tool use through [incident route]. Do not conceal the issue or attempt destructive cleanup. Preserve the facts needed for review and stop the affected use when instructed.”

Define an accessible reporting channel and a deputy. Employees should be able to report a mistake without needing to know whether a legal breach occurred.

7. Exceptions, training and review

“Exceptions require [named approval role], documented purpose, scope, safeguards and expiry. Managers confirm staff understand the applicable uses. The policy is reviewed after material tool, data, legal or operational changes and on [chosen cadence].”

An exception should not authorize activity prohibited by law or contract. Document how access is withdrawn when the exception ends.

Worked example: a support-summary assistant

Fictional scenario: A manager wants staff to use AI to draft summaries of customer support tickets. The initial tool approval covers public knowledge-base articles only.

The employee checks the register and sees that real tickets are outside the approved data category. The manager submits a use review describing ticket data, attachments, users, output destinations and intended retention. A privacy reviewer distinguishes supplier processing from the company's own purpose and evaluates the relevant legal basis if personal data is involved. ICO guidance supports examining purposes and lawful basis before processing, while noting that its UK guidance is under review after legislative change.²

Until approval, the team tests with clearly fictional tickets. The test includes an ambiguous cancellation request and a fabricated order number to see whether reviewers catch a mistaken summary. The final approved use, if granted, specifies the configuration and the human check before any response leaves the team.

This sequence is more useful than an employee acknowledgement that simply says “I understand AI risk.” It connects the policy to a real decision and observable safeguards.

Test the draft with a short decision exercise

Ask staff to classify five examples before adopting the policy:

If reasonable employees give incompatible answers, revise the policy or register. The exercise is a usability check, not proof of legal compliance.

Keep governance proportional and visible

NIST AI RMF 1.0 is voluntary guidance for organizing AI risk management, and NIST reports that a revision is in progress.³ A small team can begin with a register, clear approvals and targeted tests rather than copying an enterprise committee structure. More consequential uses need deeper review and stronger evidence.

Track training completion separately from effective use. Review a small sample of actual approved workflows, while respecting employee privacy and internal policy. Identify unsupported tools and confusing boundaries without collecting unnecessary prompt content.

Questions about adoption

Can employees use their personal AI accounts?

Your policy must answer this explicitly. If personal accounts lack the approved configuration and terms, do not assume they qualify because the same vendor offers a business service.

Should the policy ban all AI?

That is a business decision. A useful policy states permitted and restricted uses clearly, with a working review route. An unenforced blanket ban can leave leaders unaware of actual use.

Can RiskSensai approve the policy for us?

No automated draft establishes approval. Use your accountable reviewers and applicable expertise. The readiness assessment can support a broader planning conversation; it does not authorize employee AI use or verify legal compliance.

Sources and references

1. NIST. AI 600-1: Generative Artificial Intelligence Profile (2024-07-26). Voluntary companion profile; supports discussion of privacy, unreliable outputs and acceptable-use governance. ↩

2. UK Information Commissioner’s Office. How do we ensure lawfulness in AI? (2024-10-28). UK guidance currently under review after the Data (Use and Access) Act; used for limited lawful-purpose planning, not an EU/US legal conclusion. ↩

3. NIST. Artificial Intelligence Risk Management Framework 1.0 (2023-01-26). Voluntary framework; NIST reports a revision is in progress as checked October 2026. ↩