How to write an AI acceptable use policy for employees

Employees did not wait for a policy before they started using AI. Someone pasted a contract into ChatGPT to summarize it, asked Copilot to draft a client email, or ran a spreadsheet through Gemini looking for errors, often through a personal account nobody in IT approved or even knows about. A policy written after that happens is still worth writing. One written before the next tool shows up is worth more, because it gives people a clear yes instead of a guess.

Why do you need an AI acceptable use policy now?

Generative AI reached most employees through their own initiative, not through a company rollout, and that gap has a name. Microsoft and LinkedIn's 2024 Work Trend Index found that 78 percent of AI users bring their own AI tools to work, a pattern the report calls Bring Your Own AI, and warns that it puts company data at risk. When employees pick the tool, the company has no say in where a customer's details, a draft contract or an unreleased plan end up.

The risk is not AI itself. It is that nobody decided which tools are approved, what data may go into them, who checks the output before it is used, and who employees ask when a new tool shows up. Without that, IT finds out about a tool from a support ticket, HR finds out about an AI-drafted policy from an employee complaint, and legal finds out about a data question from a client. A short, specific policy replaces those surprises with a standing answer.

What should an AI acceptable use policy cover, section by section?

You can draft one interactively with the AI acceptable use policy builder, which turns answers to a short set of questions into a policy tailored to your tools, data and review habits. The sections below explain what each part of that draft is doing and why it belongs there.

A workable policy covers twelve areas. Each is a question an employee, or a lawyer, will eventually ask, and the policy should answer it before they do.

A few of these are worth a specific example.

Approved tools should name the plan, not just the vendor: "Employees may use the company's Microsoft 365 Copilot license. A personal ChatGPT or Gemini account may be used for public information only, never for company, customer or employee data." That sentence alone resolves most of the shadow AI problem, because it gives people a clear substitute rather than a blanket no.

What you may and may not enter should be concrete enough to picture: "Do not enter a customer's contact details, a draft financial result, source code, or a password into any AI tool that has not been approved for that purpose." Vague language such as "sensitive data" leaves employees guessing what counts.

Decisions about people should draw a bright line: "AI may help summarize a candidate's resume or draft interview questions. A named manager makes the hiring decision and records that they reviewed the AI's input first." This lets AI assist with the busywork around a decision without quietly becoming the decision.

Building AI into company systems should route through one door: "Only IT or an approved partner may connect an AI tool, agent or automation to company systems, email or files." An integration that uses one shared login can see everything that login can see, so the safer default is least privilege: give any AI connection only the access the task actually needs, never a standing administrator account.

Ownership and review should name a person, not a department: "The head of IT owns this policy, approves new AI tools, and reviews it every 6 months." A policy with no named owner tends to go stale the first time a new tool appears.

How do you choose between an open, balanced and strict policy?

The right stance follows from two things: how sensitive the data your people handle actually is, and how much review already happens before work goes out the door. There is no universal answer, and a policy copied from another company's website usually gets this wrong in one direction or the other.

A company that bans every tool outright when its data is mostly public ends up with the shadow AI problem it was trying to avoid, because employees will use AI on their own devices when the company version is not there. A company that allows any tool with sensitive client files ends up with a data problem it does not know it has yet. Match the stance to what is actually at risk, not to how the last headline about AI made someone feel.

Illustrative example: Consider a 120-person marketing agency that lands on a balanced stance. Employees may use the company's approved tools, plus a personal account for public research only. Anything reaching a client goes through review first, and the agency discloses when AI drafted a substantial part of a deliverable. AI may help summarize meeting notes and draft first passes, but it plays no role in hiring or performance decisions beyond that summarizing. The whole policy fits on two pages, and every employee signs an acknowledgment when they join.

How do consumer and business AI plans differ in data use and admin controls?

This is the question underneath most of the approved tools section, and the honest answer is that it depends on the plan, not the brand name. The same company's free tier and business tier can behave differently. Terms change, so treat the following as a snapshot of each vendor's own current documentation rather than a permanent fact, and check it again before you rely on it.

Three things fall out of this table. First, a personal account and a company-provided account from the same vendor are not the same product for this purpose, so "we use ChatGPT" or "we use Gemini" is not a specific enough answer to a data question. Second, every major vendor now defaults business and commercial plans away from training on your data, which is the strongest argument for the approved tools section pointing people toward the company-provided plan rather than leaving the choice to them. Third, admin controls, not the model itself, are usually where retention and visibility actually get decided, so whoever owns the policy should also own those admin settings, or know who does.

For the wider data question, including prompt injection, logging and access control, see data security and governance for AI in the enterprise. This guide covers the policy that tells people what to do; that one covers the systems that enforce it.

How do you roll out an AI acceptable use policy?

A policy nobody has seen is not a policy. Roll it out with three things: training before access, a signed acknowledgment, and one place it actually lives.

Training does not need to be long. A short session or module covering the policy, the approved tools and one or two examples of output that needs a closer look is usually enough, and it matters more for anyone whose role involves decisions about people or building AI into company systems. Have new hires complete it before they get access to a company AI tool, and have existing employees complete it once, on a set date, rather than whenever they get around to it.

An acknowledgment, even a simple one, matters more than it looks. It turns a document into something each employee has actually agreed to, and it gives HR a record if a problem comes up later.

Put the policy somewhere people already look, the employee handbook, the intranet, wherever onboarding paperwork lives, rather than a one-time email that scrolls out of view. Mention it again whenever the company adds or changes an approved tool, since that is the moment people are most likely to have a real question.

How do you enforce and review an AI acceptable use policy?

Enforcement works best as a named person and a known route, not a monitoring dashboard. This is the part of AI governance a policy cannot do on its own. Someone, often in IT, security or HR depending on the company, owns the policy, approves new tools and answers questions about edge cases. Reporting a wrong or concerning AI output should go to that person by name, and reporting a problem early, even one the employee caused, should not by itself be treated as a violation. Ignoring a known problem should be.

Review the policy on a fixed schedule, every 6 or 12 months is common, and sooner if the company adopts a materially different AI tool or a new contract or client requirement changes what is allowed. Organizations wanting a broader structure for this work often reference the NIST AI Risk Management Framework, which organizes AI risk work into four functions: Govern, Map, Measure and Manage. This policy is the governance layer that framework assumes already exists.

What mistakes do companies make with an AI use policy?

• Banning every tool outright. This does not stop AI use; it moves it to personal devices and accounts where the company has no visibility at all, which is the exact risk a policy is meant to reduce.
• Writing a policy nobody reads. Ten pages of legal language gets skimmed once and forgotten. Two pages in plain language gets followed.
• No named owner. Without one, nobody approves a new tool request, and employees either wait indefinitely or go around the policy.
• No route for requesting a new tool. Employees who find a genuinely useful tool need somewhere to ask, or the policy becomes a reason to hide the request rather than raise it.
• Treating the policy as finished. AI tools change faster than most policies do; a policy with no review date will quietly fall out of date.

How Kastling approaches AI acceptable use policies

An AI acceptable use policy is a starting point, not a finished control. It sets the rules; the systems around it, permissions, logging, approval steps, have to actually enforce them, which is where most of the technical work sits. As part of AI & Cloud Infrastructure, we help set the admin controls, data access and approval points a policy like this assumes are already in place, so the rule on paper matches what the systems actually allow.

We are not a law firm or an HR function, and this guide is not legal advice. Have legal counsel and HR review any policy before you adopt it, particularly the disclosure and decisions-about-people sections, since the right answer depends on your contracts, your state and your workforce.