Skip to content
Nullgen AI Blocker

BlogEnterprise

How to write a generative AI acceptable use policy that employees actually follow

Most companies have one of two AI policies: a ban nobody enforces, or a document nobody reads. Here is how to write one people can apply in the moment — three tool tiers, four data classes, one decision rule — and how to back it with controls without slowing work down.

The Nullgen team

13 min read

Colleagues around a conference table listening to a presenter in a bright office.
Photo by Christina @ wocintechchat.com on Unsplash

Ask ten companies for their generative AI policy and you will get three answers: a ban nobody enforces, a twelve-page document nobody has read, or a shrug. All three produce the same behavior. People use the tools anyway, on whatever account is closest, with whatever data happens to be in front of them.

This guide is for the people who have to fix that — CISOs, IT directors, compliance and legal leads, and the HR partners who end up owning the document. It covers why most AI policies fail, four principles that make one work, a tiering model for tools and data that fits on a single page, a template you can adapt this week, and how to back the policy with controls so it is more than a paragraph in the handbook.

Why most AI policies fail

Start with the uncomfortable numbers. In the 2026 Cost of a Data Breach study from IBM and the Ponemon Institute, 68% of breached organizations had no AI governance in place to manage AI or detect unsanctioned use — worse than the year before. Among those that did have governance, the most common control was requiring IT approval before AI is deployed, and even that fell from 45% to 38%. Only 19% said their governance and security teams coordinate at all. Shadow AI showed up in 43% of the breaches studied.

  • 68%

    of breached organizations had no AI governance in place

    IBM, 2026

  • 43%

    of breaches involved shadow AI

    IBM, 2026

  • 39.7%

    of workplace AI interactions involve sensitive data

    Cyberhaven, 2026

The policies that do exist tend to fail in one of two ways. The first is the ban. It reads well in a board deck and lasts until the first deadline, after which usage moves to personal accounts and personal phones. Microsoft and LinkedIn’s 2024 Work Trend Index found that 78% of people who use AI at work bring their own tools, and Cyberhaven puts roughly a third of workplace AI use on personal accounts already. The second is the wall of text: a long, careful document that answers every question except the one an employee has at nine in the evening with a customer file open, which is “can I paste this?”

A man working alone at a laptop in an office.
The policy has to work here: one person, one deadline, one text box, and no time to look anything up.Photo by Priscilla Du Preez on Unsplash

Neither failure is a writing problem. It is a design problem: the policy was written for the auditor who might read it once, not for the person who has to follow it two hundred times a week.

Four principles before you write a word

Everything that follows rests on four decisions. Make them explicitly, and the document almost writes itself.

  • Write for the moment of use. The reader is not in a training session. They have a task, a deadline, and a chatbot open. Every rule has to be applicable right there, from memory.

  • Regulate data, not tools. The tool list changes weekly; your data classes do not. A policy built on data classes survives the next model launch without a rewrite. The tool list is an appendix you update, not the policy itself.

  • Make the approved path faster than the workaround. If the sanctioned assistant takes three days of tickets to reach and the personal account takes ten seconds, you have already lost. Speed is a security control.

  • Pair every rule with a control, or cut the rule. A rule you cannot enforce teaches people that the whole document is optional. Fewer rules, each backed by something real, beats a comprehensive list nobody believes.

If your compliance team wants a formal backbone, NIST’s AI Risk Management Framework supplies the govern, map, measure, and manage structure. The one-page policy described here is the employee-facing layer that sits on top of it — the part people actually read.

Three tool tiers

Sort every generative AI tool — including the AI features inside software you already license — into one of three tiers. Publish the list where people actually look, and let the data rules in the next section do the rest.

What qualifies

Approved
An enterprise agreement is in place: your data is not used for training, retention terms are written down, and access is through company single sign-on.
Limited
A reputable tool with no enterprise agreement, or an AI feature inside a licensed product that nobody has reviewed yet.
Blocked
Personal accounts of any tool, and anything without published data terms.

Data allowed

Approved
Public, Internal, and Confidential. Regulated data only where the contract and your privacy team explicitly permit it.
Limited
Public data only. Nothing that identifies a customer, an employee, or an unreleased plan.
Blocked
None. People may use it for personal purposes on personal devices — not with company data.

Typical examples

Approved
Your licensed copilot; the enterprise tier of a chatbot with a signed data-processing agreement.
Limited
A free-tier writing assistant used to rephrase a blog post that is already public.
Blocked
A personal ChatGPT or Gemini account in a work browser; a browser sidebar nobody has vetted.

How it is enforced

Approved
Single sign-on, the contract, and an allow rule on managed browsers.
Limited
The data rules, reinforced in training.
Blocked
Prompt blocking on managed browsers, with an access request path for legitimate exceptions.
Tier by contract and account, not by brand. The same product can sit in two tiers depending on who is paying for it.

Notice what the tiers do not mention: brand names. A consumer chatbot and its enterprise edition are the same product with different contracts, and the contract is what protects your data. Tiering by agreement also means the list stays short — most tools fall into Blocked by default until someone reads their terms, which is exactly the incentive you want.

Four data classes everyone can remember

Most organizations already have a classification scheme. If yours has more than four levels, collapse it for this policy. The point is recall under pressure, not precision.

  • Public

    Anything already on your website or in a press release. Free to use in any tier.

  • Internal

    Day-to-day work that is not secret but is not published either: meeting notes, drafts, process documents. Approved tools only, unless it has been stripped of names and specifics.

  • Confidential

    Source code, customer lists, contracts, financials, unreleased plans. Approved tools only, and no exceptions without a named approver.

  • Regulated

    Personal data, health or payment information, and anything a customer agreement restricts. Only where your privacy or legal team has explicitly cleared the tool — and by default, nowhere.

Give each class one concrete example from your own business — the actual name of the CRM export, the actual repository — and people will map new situations onto it without asking. Abstract categories are forgotten; the example is what sticks.

The one-page policy: a template you can adapt

Here is the structure we recommend, in the order employees will read it. Each section is a paragraph or a short list, and the whole thing should fit on one screen. The wording in each step is a starting point rather than legal advice — have your counsel review the final text.

  1. 1

    Purpose and scope

    Two sentences: why the policy exists (protecting customer trust, company data, and your own work) and who it covers (all staff and contractors, every device used for work, every generative AI tool — including features inside software you already license).

  2. 2

    The approved tool list

    Link to a living page, owned by IT, that lists Approved and Limited tools with the account to use for each. Put the request path for a new tool on the same page. Do not bury the list inside the policy document; it will be out of date within a month.

  3. 3

    The data rules

    The four classes with one example each, then the one-line rule. This is the section people will actually remember, so keep it plain: “If the tool is not Approved, the data must be Public.”

  4. 4

    Required practices

    Verify outputs before they reach a customer or a decision. Never paste credentials, keys, or tokens into any AI tool, Approved or not. Disclose AI use where a customer, regulator, or contract expects it. Three or four lines, no more.

  5. 5

    Exceptions

    Name who can approve a temporary exception, how to ask, and how long an approval lasts. A policy without a fast path to yes is a policy with a slow path to workarounds.

  6. 6

    Enforcement and consequences

    State plainly that managed browsers block AI prompts outside the Approved list, that exceptions are recorded, and what happens after a breach of the policy. People follow rules they can see being enforced.

  7. 7

    Ownership and review

    One named owner, a quarterly review of the policy, and a monthly refresh of the tool list. Put the date and version at the top so nobody wonders whether it is current.

The policy is the decisions. The tool list, the request form, and the training deck are attachments — keep them out of the document people are supposed to remember.

Make it enforceable

The fourth principle is the hard one. Most of the policy can be enforced by contract and identity: Approved tools sit behind single sign-on and an enterprise agreement, so the data protections live in the paperwork. The Blocked tier is where policies usually give up, because the obvious control — a URL blocklist — does not work. New assistants launch every week, AI now lives inside domains you cannot block, and a blocked office browser simply moves the paste to a personal phone. We covered that gap in detail in What is shadow AI?

Nullgen enforces the Blocked tier where the risk actually is: the prompt field. It recognizes AI prompt boxes on any website — including tools that launched this week — and stops typing and pasting into them on managed browsers, while the rest of the page keeps working. Approved tools are allowed by policy for the people who need them. Everyone else sees a clear block and a way to ask.

The Blocked tier, enforced in the field: the page stays usable, and the paste never leaves the device.
The exceptions section as a product: the request reaches a named approver with the site and the duration — never the prompt.

Nullgen Pro Enterprise maps onto the policy sections directly:

  • Zero-touch force-install through Intune, Jamf, Google Workspace, or Group Policy, pinned so users cannot remove it — the enforcement clause, delivered through the tools you already run.

  • Allow and deny policies per site for selected users, synced to enrolled browsers in real time — the Approved list, made operational.

  • Access requests routed to named approvers, with temporary or permanent grants — the exceptions section, with a record of every decision.

  • One dashboard of users, devices, requests, and policies — the evidence your quarterly review needs.

One detail matters for privacy teams, works councils, and plain trust: detection runs on the device, and prompt text is never collected. Nullgen enforces the policy without reading what people type, which is a much easier conversation to have with employees than monitoring.

Rolling it out without a revolt

A good policy launched badly becomes the wall of text you were trying to avoid. Four moves keep it credible.

  • Lead with the why. Share the numbers above and one concrete story from your own industry. People accept limits they understand and route around limits that feel arbitrary.

  • Train briefly, then repeat. Fifteen minutes on the tiers, the data classes, and the one-line rule beats an hour-long compliance module. Repeat the one-line rule in onboarding, in the tool list, and on the block screen itself.

  • Pilot with the team that complains loudest. Usually engineering or sales. If the approved path works for them, it works for everyone, and you gain advocates instead of workarounds.

  • Watch the exceptions, not the blocks. Access requests are your best signal. A flood of requests for one tool means the Approved list is missing something; approve it properly and the requests stop.

A man presenting at a whiteboard to colleagues seated in a meeting room.
Fifteen minutes on the tiers, the classes, and the one-line rule is the whole training.Photo by Vitaly Gariev on Unsplash

If you operate in the European Union, note that the EU AI Act has required organizations that use AI systems to ensure a sufficient level of AI literacy among their staff since February 2025. Short, practical training on the policy is the natural place to address that — your counsel can tell you what else applies.

Then keep the policy alive. A document dated eighteen months ago that still names a tool nobody uses tells every reader it can be ignored.

Key takeaways

  • Most AI policies fail by design: they are written for auditors, not for the moment someone is about to paste.

  • Regulate data, not tools. Three tool tiers and four data classes fit on one page and survive the next model launch.

  • One sentence carries the policy: if the tool is not Approved, the data must be Public.

  • Every rule needs a control. Contracts and single sign-on cover the Approved tier; prompt blocking on managed browsers covers the rest, with a fast path to exceptions.

  • Launch with the why, train briefly, pilot with the skeptics, and read the access requests to learn what the policy is missing.

Frequently asked questions

  • Should we just ban generative AI outright?

    Bans move usage to personal devices and personal accounts, where you have no visibility and no contract. A better structure is to approve a small set of tools under enterprise terms, block the prompt everywhere else on managed browsers, and keep the exceptions process fast. People stop working around a policy when the approved path is quicker than the workaround.

  • Do developers need their own rules for AI coding assistants?

    The same framework covers them. Source code is Confidential, so a coding assistant is either Approved — under an agreement that excludes your code from training — or it is Blocked. The one addition worth making is a line about secrets: credentials and keys in code never go into any assistant, Approved or not.

  • How do we handle AI features inside software we already license, like Copilot or Gemini?

    Tier them like any other tool, based on the contract that covers them. If the feature inherits your existing enterprise agreement, it is Approved. If it was switched on with no review, it is Limited until someone reads the terms. Managed-browser policies can allow the approved product while still blocking personal accounts of the same assistant.

  • How long should the policy be?

    One screen. The tool list, the request form, and the training material live on linked pages that IT can update without a policy revision. The policy itself is the decisions: scope, tiers, data classes, required practices, exceptions, enforcement, and ownership.

  • Does enforcing the policy mean monitoring what employees type?

    Not with Nullgen. Detection runs in the browser, on the device, and prompt text is never sent to Nullgen or to your administrators. Approvers see the site that was requested and for how long — not what anyone was about to type.

Sources

  1. IBM and Ponemon Institute, Cost of a Data Breach Report 2026
  2. Microsoft and LinkedIn, 2024 Work Trend Index: AI at Work Is Here. Now Comes the Hard Part
  3. Cyberhaven Labs, 2026 AI Adoption & Risk Report
  4. National Institute of Standards and Technology, AI Risk Management Framework
  5. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 4: AI literacy

Enforce the policy where the paste happens

Install the free extension on your own laptop to see the block. Nullgen Pro Enterprise force-installs through the MDM you already run, allows the tools you have approved, and routes every exception to a named approver.