How to Write an AI Acceptable Use Policy for Employees

An AI acceptable use policy is a short document that tells employees which AI tools they may use, what information they may put into them, who must review the output, and when to stop and ask a person. A usable one fits on a few pages, uses plain language and names an owner. It works because it replaces vague caution with decisions people can apply in the middle of a task.

Key takeaways

• A good policy answers four questions: which tools, which data, who reviews, and when to escalate.
• Name approved tools in a list that one person maintains, and treat everything else as not yet approved rather than forbidden forever.
• Sort data into a few plain tiers and say what each tier may do, instead of writing a long list of banned examples.
• Match review effort to what the output will touch: internal drafts need less than anything customers, regulators or money will see.
• Publish the policy with a contact, a short training session and a review date, or it will be ignored.

What should an AI acceptable use policy actually do?

Most employees are already using AI, whether the company has said yes or not. They draft emails, summarize documents, translate, write spreadsheets formulas and prepare meeting notes. The policy does not exist to stop this. It exists to make the safe way the easy way, and to make the unsafe way obvious before someone is in the middle of a deadline.

That gives the policy three jobs. First, it sets boundaries that protect customers, employees and the company: confidential data, legal obligations, decisions that need a human. Second, it gives people permission, so that a careful employee does not have to guess whether a legitimate use is allowed. Third, it creates a path for questions, so that new tools and new situations reach a decision-maker instead of being solved privately.

Keep it separate from your wider governance work. A policy is the part employees read. The structures behind it, such as ownership, risk review and measurement, belong in a broader frame like the one in AI governance for mid-sized companies. If you want an outside reference for how to think about risk, the NIST AI Risk Management Framework is a sound, neutral starting point.

A practical test of length: if a new hire cannot read the policy over a coffee and explain it back, it is too long. Put the reasoning and the exceptions in a companion document and keep the policy itself to rules a person can follow.

Which tools are allowed, and who decides?

Start with a plain list of approved tools. For each one, record what it is approved for, which account type must be used, and who owns the relationship with the vendor. The account type matters more than people expect. A company-managed account with the right settings is a different thing from a personal account on the same product, even if the screen looks identical.

Then define three states for any tool:

• Approved: employees may use it for the stated purposes with the stated data tiers.
• Under review: a team may trial it with open or low-risk data only, with the owner informed.
• Not approved: not to be used for work, and not to receive company information in any form.

The policy should say who moves a tool between states. In a mid-sized firm this is usually a small group: someone from operations or IT, someone who understands legal and privacy duties, and a business lead. Give them a simple request path, because a slow approval process is the main reason people use personal accounts.

Do not forget what sits around the chat window. Browser extensions that read pages, meeting recorders, AI features switched on inside existing software and plugins that connect to email or calendars all count as tools. If a feature can read company data or act on it, it belongs on the list or in the review queue.

If your company runs AI agents rather than only chat tools, add a short clause that agents must operate under their own identity and accounts, not an employee's login. The reasoning is covered in why your company AI agent needs its own identity and accounts, and it makes both permissions and audit trails far easier to manage.

What data rules do employees need?

The data section carries most of the risk, so make it the clearest. Avoid long lists of forbidden examples. Use a small number of tiers that employees can apply by instinct.

• Public: material already published or intended for publication. Any approved tool may receive it.
• Internal: ordinary working information such as process notes, draft plans and non-sensitive correspondence. Approved tools on company accounts only.
• Restricted: personal data, health or financial records, credentials, contracts under confidentiality, unreleased financials, legal advice, and anything a customer shared in confidence. Allowed only in tools specifically approved for that tier, or not at all.

Say explicitly what happens in the gray zone: when in doubt, treat information as the higher tier and ask. Also state that removing a name does not always make data safe, since a few details together can still identify a person or a client.

Personal data deserves its own sentence. Depending on where you operate and whom you serve, laws such as Brazil's data protection law, overseen by the ANPD, or European rules may apply to how personal data is processed, including by AI vendors. The policy should not try to teach the law. It should say that personal data goes only into tools that legal or privacy review has cleared, and name the person who handles that review.

Cover outputs and storage too. Employees should know whether prompts and results are retained, who in the company can see them, and where they may be saved. If the company keeps long-term memory for agents, the rules about what belongs there are a separate topic, discussed in AI memory vs chat history.

What must people review before AI output is used?

The core principle is simple: the person who uses AI output owns it. If an employee sends it, files it or acts on it, the employee is responsible for its accuracy, tone and legality, exactly as if they had written it. The policy should say this in one sentence, without exceptions for the tool.

Then scale review to consequence. A decision guide helps:

• Private drafting or brainstorming: the author reads it and corrects it. No further review.
• Internal documents others will rely on: the author checks facts against the source, and a colleague reads anything that sets a process or commitment.
• Anything sent to a customer, partner or regulator: a named person checks facts, figures, names and promises before it leaves, and the AI use is not hidden from the reviewer.
• Anything involving money, contracts, hiring, health, safety or legal commitments: a person with authority makes the decision. AI may prepare material but may not decide.

The last tier is where many companies need to draw a firm line. AI can assemble a comparison of candidates, but it should not decide who is hired. It can draft a clause, but it should not sign off the contract. The principle behind these lines, and how to place them in automated workflows, is explored in where your AI agent should stop and ask.

Add one reminder employees rarely hear: AI output can be fluent and wrong. Require checking of numbers, citations, names, dates and any claim about a rule or a product. If a tool cites a source, open it. If a tool summarizes a document, spot-check the summary against the original for the points that matter.

Finally, address documents that arrive from outside. Emails, PDFs and web pages can contain instructions aimed at the AI reading them. Employees do not need technical detail, but they should know not to let an assistant act on instructions found inside a document without checking. The risks are explained in prompt injection in business documents, and the OWASP Top 10 for LLM Applications is a reliable reference for the wider set of risks.

When should an employee escalate, and to whom?

A policy that only says "use good judgment" fails exactly when judgment is hard. Give people specific triggers and a specific place to send them.

Good triggers to include:

• Restricted data has been pasted into a tool that is not approved for it.
• An AI output was sent externally and then found to be wrong, or contains something that should not have been shared.
• A tool behaves unexpectedly, such as taking an action no one requested or revealing information from another context.
• A customer, journalist or regulator asks how the company uses AI.
• Someone wants to use a new tool, connect AI to company systems, or automate a task that touches customers.

For each trigger, name one contact or mailbox, say what to include (the tool, what was shared, when), and promise that reporting a mistake promptly will be treated as the right behavior. This last promise is not softness. Companies learn about incidents early only if people are not afraid of the consequences of reporting them.

When escalation reaches a decision-maker, the quality of the handoff matters. The reviewer should receive the situation, the options and the recommended action, not a pile of chat logs. The same discipline applies to agents and people alike, as described in human escalation for AI agents.

An illustrative scenario and a one-page checklist

Illustrative scenario: a sales coordinator needs a quick summary of a long customer contract before a call. She has a personal account with a chatbot and is tempted to paste the text in. Under a clear policy, the contract is restricted data, the personal account is not an approved tool, and the approved company tool is cleared only for internal-tier information. She checks the tool list, sees that contract review is routed to a named contact, and sends the document there with a request for a summary. Nothing leaves the company, and the next time she knows the route. A policy with no tiers or contacts would have left her alone with a deadline.

Use this checklist to assemble your own one-page policy:

• Purpose: one paragraph saying the policy enables safe use and applies to all employees, contractors and any AI feature inside work tools.
• Approved tools: a list with purpose, account type and owner, plus the three states.
• Data tiers: public, internal, restricted, with what each may do.
• Personal data: a single rule and a named reviewer.
• Ownership of output: the person who uses it is responsible for it.
• Review levels: matched to consequence, with the human-only decisions listed.
• Disclosure: when to tell customers, colleagues or regulators that AI was involved.
• Escalation: triggers, contact and the no-blame promise for prompt reporting.
• Owner and review date: one named person and a scheduled revision.

Write it in the second person and the present tense. Short sentences, concrete verbs. Put the reasoning in a separate note so that the rules stay visible.

How do you roll it out and keep it current?

Publishing the document is the smallest part of the work. Policies fail through neglect, not malice. Plan these steps:

• Agree the draft with legal or privacy review, IT and at least two people who do the actual work, since they will find the ambiguity.
• Hold a short briefing where you walk through realistic examples from each team, including at least one the policy forbids.
• Make the approved tool list and the escalation contact easy to find, not buried in a policy library.
• Set a review date and a trigger for earlier review, such as a new tool category, an incident or a change in the law.
• Check practice, not just paperwork: ask teams what they actually use and why, and treat gaps as input to the tool list.

Training carries more weight than most owners expect. People follow rules they understand and can apply. A brief session on what AI does well, where it fails and what the data tiers mean pays off more than a longer document. The content is outlined in AI training for employees.

Expect the policy to change. Tools update, vendors alter their terms and features appear inside software you already use. Treat the tool list as a living register and the policy text as stable principles, so that you update the first often and the second rarely.

How does Be Human handle this in practice?

Be Human designs, implements and operates AI infrastructure for companies, and an acceptable use policy is part of the operating context, not an add-on. In a first engagement, we define one useful role for an agent, the memory and tools it needs, the approval boundaries and an observable success criterion. The data tiers and review levels in your policy become the permissions and approval points that the agent actually works within. Under managed operations, permission review, monitoring and recurring evaluations keep the policy and the real behavior aligned, with a human owner on your side deciding where the boundaries sit.

Frequently asked questions

How long should an AI acceptable use policy be? Short enough that employees read it, usually a few pages at most. Put the rules in the policy and the reasoning, examples and technical detail in a companion note. If people cannot recall the data tiers without opening the document, simplify.

Should we ban AI tools until we have a policy? A blanket ban often pushes use onto personal accounts, where you have no visibility. A better approach is to approve a small set of tools quickly, set clear data rules and make the request path for new tools easy. Reserve outright bans for specific data types and specific tools you have reason to distrust.

Who should own the policy? One named person should own it, typically in operations, IT or risk, with input from legal or privacy review and business leads. Ownership means keeping the tool list current, handling questions and scheduling revisions. Shared ownership without a name tends to mean no ownership.

Does the policy also cover AI agents that act on their own? It should include a clause for them, because an agent can read data and take actions, not only produce text. The clause should require a separate identity, limited permissions, defined approval points and logs a person can review. The rest of the policy, such as data tiers and escalation, applies to agents as it does to employees.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.