How to write an AI acceptable-use policy

An AI acceptable-use policy tells staff which AI tools they may use, what data may go into them, who approves a new tool, and what happens when something goes wrong. For a mid-market company it should be short enough that people read it and specific enough that managers can enforce it: eight to twelve pages, not a legal treatise.

The policy is the visible part of a governance program. The inventory and the review process behind it do the actual work.

Start with an inventory, not a template

You cannot write rules for tools you have not counted. Before drafting, list every AI tool and use case in the business, including the ones nobody approved.

• Ask department heads what they use and why.
• Check the SaaS admin console and expense reports for AI subscriptions.
• Review browser extensions and embedded AI features inside existing tools.
• Interview the people who build spreadsheets and automations, because they are usually the first adopters.

For each entry, record the tool, the use case, the owner, and the data it touches. That list is the input to every other decision.

Tier the use cases by data risk

A four-tier structure is enough for most mid-market companies.

1. Public or published data. Marketing copy, public research. Low risk, broad permissions.
2. Internal business data. Meeting notes, internal drafts. Allowed in approved tools with retention settings reviewed.
3. Regulated or customer data. Personal data, health data, financial records, contracts. Restricted to tools that passed a vendor review and a signed data agreement.
4. Production systems and credentials. Source code, infrastructure, admin access, customer systems. Default deny unless a review approved a specific use with logging.

Write one sentence of permission per tier. Staff should be able to find their situation in under a minute.

Say what is allowed and what is not

A prohibition list that is too long gets ignored. Keep it to behaviours that actually create risk:

• No customer, patient, or employee data in consumer AI tools.
• No credentials, API keys, or internal system details pasted into a chat window.
• No AI-generated legal, medical, or financial advice presented as a decision.
• No automated decision about a person without a human review step.
• No AI agent connected to a production system without a security review and an owner.

The allowed list matters just as much. Name the approved tools, the approved uses, and where staff can ask questions. A policy that only bans things pushes use underground.

Name the approval process

Someone has to own the decision. Put one person or role in charge of intake and make the process predictable:

1. A short request form: tool, use case, data involved, who benefits.
2. A vendor check: data handling, retention, security controls, contract terms.
3. A decision with a written reason, kept in one place.
4. A review date, because tools change their terms.

A request that returns a decision within a published turnaround keeps people inside the process. A black hole teaches them to skip it.

Cover the vendor side

The policy should require a review before purchase, not after. The questions that matter are about data, not features: whether the vendor trains on your data, how long it keeps it, which subprocessors touch it, what happens on deletion, who can access it, and what the breach notification terms say. AI vendors change these terms more often than traditional software vendors, so the review should record the date and the version reviewed.

Train, then give people a way to report mistakes

Training should cover the policy, the approved tools, and two or three real examples from the business. It should also make reporting safe. When someone pastes the wrong document into a tool, the company needs to hear about it quickly. A good-faith reporting path with a no-blame first response gets that information. A policy that punishes every mistake gets silence.

Review on a schedule and keep the evidence

Once a year is the minimum; a review after any major tool change or incident is better. Keep the evidence in one folder: the approved policy, the inventory, the approval decisions, the training records, the exception log, and the incidents and near misses. That file answers the questions a customer, an insurer, or a board will eventually ask.

The work maps cleanly to the NIST AI RMF functions of govern, map, measure, and manage, and it gives you a starting point for customer or EU AI Act questions without claiming a certification you do not have.

Common mistakes

• Writing a policy nobody can read. Legal language produces compliance theatre. Plain language produces behaviour.
• Banning everything. Staff use AI anyway, on personal accounts, where you cannot see it.
• No owner. Governance without an accountable person is a document, not a control.
• No inventory. You cannot tier data you have not found.
• Treating the policy as the finish line. The policy is one artifact; the review process is the control.

If you need the policy and the process built together, the AI Security & AI Governance service covers the inventory, the tiering, the policy, and the vendor review. Request a briefing if you want to scope it against your current tools.