Writing an AI usage policy: the clauses most drafts miss
Most organisations write their AI usage policy in a hurry. Someone discovers that a team has been pasting client files into a public chatbot for months, the question goes to the DPO or the head of information security, and a policy is expected by Friday.
What comes out of that week is usually one of two documents. The first is three lines long, says staff must use AI responsibly, and cannot be enforced against anything. The second is forty pages of borrowed boilerplate that nobody reads past the contents page. Neither changes what happens the next time someone has a contract to summarise and ten minutes to do it.
A usable AI usage policy sits between the two. It is short enough to be read, specific enough to be applied, and it regulates the right thing. Here are the clauses that first drafts leave out, and why each one matters more than it looks.
1. The AI features already inside software you license
Almost every policy scopes itself to AI tools, meaning the assistants people go and sign up for. That misses the larger surface.
Summarisation, drafting, transcription, and classification features are now built into products your organisation already pays for: the office suite, the helpdesk, the CRM, the meeting recorder, the code host. Nobody made a decision to adopt an AI tool. A vendor shipped a feature and it was on by default.
Scope the policy to the behaviour, not the product category. Any tool that sends text, files, images, audio, or code to a system that generates or analyses content is in scope, whether or not it is called an AI tool and whether or not anyone chose it.
2. Personal accounts on approved tools
Approving a tool and approving an account are different decisions, and policies routinely make only the first.
If a person uses their own login on an approved product, the work sits outside your contract, outside your negotiated retention and training terms, outside your ability to retrieve or delete anything, and outside any audit you might later need to run. The tool is on your approved list. The usage is not covered by anything on your approved list.
Say it explicitly: use the account the organisation provides.
3. A rule about data, not a list of tools
A list of banned tools is out of date the month you publish it. A rule about data is not.
The operative clause of a good policy is a table: which classification of data may go into which category of tool. Public, internal, confidential, restricted, mapped against public AI tools and approved ones. New product appears, staff can work out where it lands without a memo.
Reuse the classification scheme you already have rather than inventing a second one for AI. Two schemes means neither gets used.
The one-line version, the one people will actually remember: if the tool does not need to know who the person is in order to do the task, the person's identity does not belong in the prompt.
4. Client contracts that predate all of this
Where you hold data belonging to a client, your contract with them governs what you may do with it. That contract was almost certainly signed before anyone considered whether a chatbot counts as a subprocessor.
Before third-party data goes into any AI tool, someone has to confirm that the contract permits disclosure to subprocessors, that any notification or approval requirement has been met, and that the client has not issued a specific instruction about AI. Some clients have. Very few organisations have checked.
5. Who is accountable for the output
Policies spend all their attention on the input and almost none on what comes back.
The rule is that a person is accountable for every output used in the organisation's work, and the tool is not. In practice that means verifying every factual claim, figure, and citation against a source before the output goes to a client, a court, or a filing. Fabricated citations that look entirely plausible are a known and recurring failure, and they have already cost people professionally.
Add the harder line too: for decisions that materially affect a person, employment, credit, benefits, admission, discipline, or care, a qualified human makes the decision. AI output may inform it. In several jurisdictions that is not a preference, it is a requirement, and the requirements are moving quickly.
6. An incident clause people will actually use
Every AI policy has a reporting requirement. Most of them produce silence.
If reporting an incident reads like a confession, people work out that the safest option is to delete the conversation and say nothing. You then have a disclosure you never learn about, cannot assess, and cannot notify.
Two sentences fix it. Reporting in good faith will not result in disciplinary action. Concealing an incident may. Add the instruction not to delete the conversation before reporting, because the record is what the assessment needs.
7. Monitoring, stated honestly
If you monitor AI tool usage on managed devices, say so, under your existing monitoring policy. If you do not, say that instead.
This is one of the three points in an AI policy where local law genuinely changes the answer. Workplace monitoring rules and consultation requirements vary a great deal, and works council obligations in particular are not something to discover after the fact. The other two are automated decision-making and international transfers.
8. The clause that turns the rule into a control
The weakest control in any information security programme is asking a person to make a judgement call, correctly, every time, while busy.
A policy that stops at instruction has to be followed perfectly to work. Where you can, prefer a control that makes the prohibited version difficult rather than merely forbidden: strip the regulated content out of the text before it can leave, provide approved tools good enough that workarounds are not tempting, and make the approved path the fast one.
Then write down what you actually have. If the honest answer is that you have no technical control yet, write that, rather than describing an intention as though it were a control. A policy that overstates its own enforcement is worse than one that admits a gap, because the gap is what an auditor finds.
The mistake underneath all of this
The instinct after discovering unsanctioned AI use is to block it. It is a reasonable instinct and it rarely works. Blocking the domain moves the activity to a phone, and a phone is a device you cannot see. The organisations with the worst exposure are not the permissive ones. They are the ones that issued a ban, believed it, and stopped looking.
The alternative is not looser rules. It is a different control point. Instead of asking every person to judge, prompt by prompt, whether what they are about to paste is safe, you remove the regulated content from the text before it can leave. What reaches the provider carries no names, no identifiers, and no client details. The work still gets done, because the model does not need to know who the person is to summarise a case, redraft a clause, or explain a record. The exposure does not happen, because there was nothing regulated in the prompt to expose.
That is also what changes your position afterwards. A policy tells a regulator what you asked people to do. A control tells them what was possible.
A template you can start from
Rather than describe a policy, we published one. The AI usage policy template is a complete document covering all of the above: seventeen clauses, an approved tool register, the data classification table, a data protection section, an incident procedure, and a one-page card written to be circulated to staff on its own.
It is free, it has no form and no email capture, and it downloads as Word, PDF, or Markdown so it can go straight into your approval process under your own name. It is a template rather than legal advice, and the three clauses where local law decides the answer are marked as such.
Read the AI usage policy template
Free, ungated, and yours to adapt.
If the clause you cannot currently fill in is the one about controls, that is the gap Velum exists to close. It masks personal and sensitive data in prompts and files before they reach any AI tool, entirely on the user's own machine, with no network calls at runtime, and restores the real values in the reply so the answer is still usable. There is no server in the path, so adopting it does not add another provider to the subprocessor list you just finished reviewing.