How to write an AI acceptable-use policy.
Every regulated company already has an acceptable-use policy. It covers the laptop, the network, the office, the data, and the words employees are allowed to put online. Most of those policies were written before generative AI was a workflow rather than a curiosity, and they treat AI, when they touch it at all, as a special case of "internet use".
That gap is where the trouble starts. The AI acceptable-use policy is the document that says, in plain language, what an employee is allowed to do with AI, what they are not, what counts as a borderline case, who decides, and what happens when a rule is broken. If it does not exist, every AI conversation in the company is a private negotiation.
Why the AI AUP needs to stand alone
The temptation, especially in a company that already has half a dozen policies, is to add a section to the general AUP and move on. Three problems show up almost immediately.
First, the data classes are different. The general AUP treats company data as one or two categories: confidential and public. AI workflows move documents through retrieval systems, embedding stores, vendor APIs, and prompt windows, each of which is a separate data path with separate rules. The general AUP cannot speak to those paths without becoming unreadable.
Second, the decision rights are different. The general AUP does not need to say who is allowed to draft a regulatory response. The AI AUP does, because AI-assisted drafting raises a specific question (who is accountable for the words?) that has to be answered before the draft is sent.
Third, the vendor relationships are different. A general AUP does not list which vendors are approved for which workflows. The AI AUP has to, because the wrong vendor on the wrong workflow is the cleanest way to leak data out of a regulated environment.
The AI AUP stands alone. It references the general AUP where the rules overlap, and the general AUP references back. They are linked, not nested.
The seven sections every AI AUP needs
01. Scope
A short paragraph that says who the policy applies to, what it applies to, and what it does not apply to. Employees, contractors, and agency workers. AI tools used in the course of work, regardless of whether the tool is on the approved list. Not personal use of AI tools on personal devices outside work hours.
The "not" half is as important as the "applies to" half. Without it, the policy starts to look like it reaches into personal life, and the social contract weakens.
02. Allowed uses, with examples
A list of allowed uses, each with a one-sentence example. The examples are concrete to the level of the tool and the task. "Using Veetso Brain in internal mode to find the most recent revision of the AML procedure" is an allowed use. "Researching" is not, because no one ever decides whether a specific task counts as researching.
The list does not need to be exhaustive. It needs to cover the cases that come up frequently, and the cases at the edges that need a clear answer. Three or four examples per allowed category is enough.
03. Forbidden uses, with examples
A list of forbidden uses, each with a one-sentence example. The categories that earn their place: feeding regulated customer data into an unapproved external model; using AI output as the final word on a regulated decision without a named human reviewer; pasting confidential documents into consumer-grade chat tools.
The forbidden list is where people read most carefully. It is also where the policy writer is most tempted to over-write. Resist the temptation. Five or six forbidden categories with one example each is more useful than twelve with no examples.
04. Borderline cases and the escalation route
The third list is the one most AUPs skip. Almost every case that matters is borderline. The policy should name a few common borderline patterns and the route to resolve them: a single point of contact for AI-use questions, an expected response time, and the question the requester should be prepared to answer.
Naming the borderline route is what makes the policy livable. Without it, employees either avoid the borderline (which kills useful work) or push through it (which kills the policy).
05. Data-handling rules
A short section that maps data classes to AI surfaces. Public data: any approved surface. Internal data: internal Brain mode or named approved vendors with a no-training contract. Customer data: only the surfaces specifically approved for the use case, with the use-case identifier from the register. Regulated data: only the surfaces named on the use-case register entry, never anywhere else.
This section is short by design. The detail belongs in the use-case register, which the policy references rather than duplicates.
06. Sign-off and acknowledgement
Every employee signs the policy on joining and re-signs it after every revision. The signature is recorded with a date. The signature record is auditable.
This sounds bureaucratic. The bureaucratic version is what makes the policy enforceable. Without a signature, "the employee did not know" is a complete defence. With one, it is not.
07. Violation handling
A description of what happens when a rule is broken. Categories of violation (minor, material, severe), the process for each, the role responsible for the decision, and the appeal route. The categories are not exhaustive; they are a frame. The frame is what keeps two similar violations from being handled in two very different ways depending on who happens to investigate.
How to keep it from rotting
Policies rot because they are written once and reviewed under pressure. We review the AI AUP every six months on a fixed date (1 March and 1 September), with the AI Steering Committee. The reviewer prepares a diff against the previous version, the committee approves the diff, and the policy is re-issued with the change log attached.
Re-issuing on a fixed cadence does two useful things. It makes the policy a known artefact rather than a forgotten one. And it gives the diff a place to live, which means a new employee can see how the policy has changed over time rather than being handed only the latest version. Both effects compound.
FAQ
Questions readers ask
What is an AI acceptable-use policy?
An AI acceptable-use policy (AI AUP) is the document that defines what employees are allowed and not allowed to do with AI tools in the course of work. It covers scope, allowed and forbidden uses with concrete examples, borderline cases and the escalation route, data-handling rules per data class, sign-off and acknowledgement, and violation handling.
Does an AI AUP replace the general acceptable-use policy?
No. They stand alongside each other. The general AUP covers the laptop, the network, the office, and general data handling. The AI AUP covers AI tools specifically, because AI workflows raise data-path, decision-right, and vendor questions that the general AUP cannot speak to without becoming unreadable. Each policy references the other rather than nesting inside it.
How specific should the allowed and forbidden lists be?
Specific to the level of the tool and the task, with a one-sentence example for each entry. 'Drafting an internal policy memo in Veetso Brain external mode' is specific. 'Using AI for drafting' is not. People apply policy to cases they recognise. Three to four examples per allowed category and five to six forbidden categories with one example each is the right depth.
How often should the AI AUP be reviewed?
Every six months on a fixed date, with the AI Steering Committee. The reviewer prepares a diff against the previous version, the committee approves, and the policy is re-issued with the change log attached. Fixed dates beat annual reviews because models, vendors, and use cases move faster than a year, and the change-log discipline makes the policy a living artefact.
What happens when an AI AUP rule is broken?
The policy categorises violations as minor, material, or severe, and names the role responsible for the decision in each category plus the appeal route. The frame keeps two similar violations from being handled inconsistently depending on who investigates. Each handling decision is logged in the incident log with a follow-up item if a control change is required.
Further reading
- Part of the Responsible AI in banking series.
- The AI steering committee: charter, membership, cadence · the body that owns the AUP.
- The AI use-case register pattern · the register that the AUP's data-handling section references.
- Vendor due diligence for AI models · how vendors are admitted to the approved list the AUP relies on.