Skip to content
Hassaan Mallick Book a call
Guide 01 Working document · Published in full

AI usage policy template: the confidentiality line.

The one-page policy I hand a group before any technique. Published in full so you can copy it, argue with it, and adapt it for the person who has to sign it off.

By Hassaan Mallick Published How this site's documents are made

The short answer: an AI usage policy for employees has to answer five questions on one page. Which tools and accounts are approved. What may go into them. What never does. Which outputs a person must check before they leave the building. And who decides the grey cases. If it runs longer than a page, people will not read it, and the quiet use carries on.

Most organisations do not have an AI policy problem. They have an ambiguity problem. People are not sure what they are allowed to paste into a chatbot, so they either stop using it in front of colleagues or keep using it and stop mentioning it. The second is worse. Quiet use is where mistakes stay hidden and good workflows never get shared.

That is why this document comes before any prompting technique in a workshop. Not because compliance is interesting, but because the boundary is what lets people practise in the open. It was drafted inside a regulated practice, where one missed document is real liability, and it has held up in rooms where the work is far less regulated because the logic is the same: the line that matters is not what AI can and cannot do. It is where a wrong answer or a leak costs a minute, and where it costs a client, a person or a case. Draw the policy there.

Everything in a highlighted box is a placeholder for your organisation. The rest is written to be adopted as it stands and edited only where your own rules are stricter.

The policy · one page

Using AI tools at [Organisation]: the confidentiality line

Owner: [name and role] · Grey-case decisions: [name] · Next review: [date]

1. Who this covers

Everyone who does work for [Organisation], on any device, using any tool that generates, summarises, translates or transforms text, images, code or data. It applies to personal accounts exactly as it applies to company ones, because the information does not know which account it went into.

2. Approved tools and accounts

Use only the tools and account types on the approved list kept by [owner]: [list the tools, the account type for each, and what each is approved for]. A company account whose data-handling terms we have read is approved. A free personal account is not, because its terms may allow the provider to keep or train on what you enter. If a tool you want is not on the list, ask. The answer may well be yes; the point is that someone has read the terms first.

3. What may go in

Before you enter anything, put it in one of three groups.

  • GreenInformation that is already public, or that contains no identifiable person, client, customer or counterparty. Published material, general drafting, your own notes with the names and identifiers removed. Use any approved tool.
  • AmberInternal information that is not sensitive on its own: working drafts, internal process documents, meeting notes without personal details. Use only an approved company account, and strip names, account numbers and anything that identifies a person where the task does not need them.
  • RedNever, in any tool, unless the tool is approved for exactly this and the purpose is lawful: personal data about clients, customers, employees or the public; anything received under confidentiality, non-disclosure or legal privilege; passwords, keys and credentials; financial or commercial information not yet public; anything you would need permission to email to someone outside the organisation.

The test when you are unsure: ask what a wrong answer or a leak would cost. If it would cost a minute, go ahead. If it would cost a client, a person or a case, stop and ask before you enter it. While you wait for an answer, the default is not to enter it.

4. A person checks it before it leaves

Nothing generated or edited by an AI tool goes to a client, customer, regulator, court, the public or anyone outside the organisation until a named person has checked it for wrong claims, missing points, private information and tone. The person who sends it is responsible for it, not the tool. Match the check to the consequence: an internal first draft needs a read-through; an external commitment needs the full check.

5. Grey cases

[Name] decides grey cases and answers within one working day. Each decision is written down in [one shared place] so the same question is not asked twice and the policy learns from the cases it did not anticipate.

6. Keep the evidence when a claim matters

When an AI-assisted output supports a decision, a piece of advice or a claim that someone may later question, keep the prompt, the source documents you gave the tool and the output together in the relevant file. Where a client, contract or professional rule requires you to disclose AI use, disclose it.

7. Mistakes

If something red went into a tool, or something wrong went out, tell [owner] as soon as you notice. Reporting it is the right action and will be treated that way. The response is to fix the boundary or the check that let it through, not to find someone to blame.

8. Review

This policy is reviewed by [owner] on [date], and sooner whenever an approved tool changes its terms, a new tool is approved or a grey case shows the line is in the wrong place.

How to adapt it without losing the point

  • Make the approved list real. Name the actual tools and the actual account type your people will use, with their real limits and approval status. A policy that says "approved tools" and never names them is the ambiguity problem in a new outfit.
  • Choose a grey-case owner who will answer. Not the most senior person; the one who will reply within a working day. A grey-case owner who takes a week is a red line in disguise, and people will route around it.
  • Test it on last week's work. Take three real tasks from the past week and sort their inputs into green, amber and red before you circulate anything. If the three of you disagree, the wording needs work, and better to find that now.
  • Put it in front of people before technique. Hand it out at the start of any AI training, not at the end. People practise openly once they know where the line is.
  • Keep it to a page. If your legal, privacy or security teams need more, add an annex they own. The page everyone reads stays a page.

What this is not

This is operational guidance drawn from training practice and from building AI systems in a regulated setting. It is not legal, privacy or security advice, and it does not know your regulator, your contracts or your data-protection obligations. Check it against those before you adopt it, and let the stricter rule win wherever the two disagree.

Where it fits in the training

Boundaries come before technique in every session I run. Section 4 of the planning guide explains why, and the team workshop starts with this page before anyone opens a tool. The other two working documents, a prompt library that survives and a short set of questions for finding out whether training actually worked, are described on the resources page and available on request.

This template reflects the method I use and the positions set out in the methodology. It contains no client material and describes no specific engagement. If you spot an error or a case it handles badly, the editorial standards page explains how corrections are made.

Want the line drawn for your team's actual work?

Thirty minutes, no deck. Tell me who is in the room and what they handle, and I will tell you whether a workshop is the right way to get the policy used rather than filed.