A team discovers that an engineer has been feeding production database queries to a large language model to help debug them. That is confidential information. Another team member gets called away and leaves a half-written memo containing strategic information on the table while using an AI writing assistant — the text is still in the model’s context window. A third person uses an AI image generator with the company logo, which the tool now has rights to use for marketing.
None of these are elaborate security breaches. They are normal people doing normal work with tools that have invisible footprints. In a small organisation, written policy often feels like overhead. It becomes essential when someone has to explain to a lawyer why confidential information ended up outside the organisation.
This article outlines a policy that is practical for a team of five to fifty people.
The goal
The goal is not to ban useful tools. It is to make the implications explicit and require one conscious decision rather than relying on people to guess what is safe.
The policy should fit on two pages. If it is longer, people will not read it. If it is so short it provides no guidance, it is performative rather than functional.
The three categories
Separate tools into categories based on data sensitivity.
Green: Tools you are happy having people use freely with any input. These might include brainstorming assistants, programming help, or writing assistance where you are feeding in drafts of external-facing content and nothing confidential. Tools that meet this bar usually have clear data handling policies, enterprise support, and no clause about using your input for training their models.
Yellow: Tools that are useful but need guardrails. Most current AI tools fit here. They are fine if you are careful, but require discipline. Translation: people can use them, but they need to know what not to feed them.
Red: Tools that should not be used with company data. Image generation is often here — the tool may claim rights to generated images and could use your logo. Certain cloud AI services might be here because of data residency requirements or uncertain policies about input use.
A policy that lists green tools by name and explains what makes them safe is more useful than a policy that lists everything by category. Link to the official terms of service.
The rules that matter
No confidential data in public systems. Customer names, financial information, product plans, code, unfinished strategy, personal information about employees. If it is something you would not want a competitor or journalist to know, it should not go into a system that is not under your control.
This is broad enough to be defensible and specific enough to provide real guidance. Some judgement applies — the customer’s industry and broad use case is usually fine, the customer’s actual contract terms usually is not.
Verify sensitive outputs before using them. If an AI has generated something you are going to publish, claim credit for, or act on, someone needs to have checked it. This is cheaper than recovering from hallucinated facts in public.
Check terms of service before giving input. Some tools state that they will use your inputs to train their models. Others state they will not. Some say it depends on your plan. Teams should know which is which. A one-sentence rule — “ask before using any new tool” — is a common pattern.
Anonymise and aggregate before feeding to external systems. If you need to use an external tool with data that contains personal information, remove names and identifiable details first. The functionality usually remains and the risk drops dramatically.
Do not generate images with company assets unless you own the result. This is simpler than it sounds. Use tools where you own what you generate. If the terms are unclear, ask the vendor. If they will not clarify, do not use the tool with company assets.
What to avoid
Bans without explanation. “AI tools are not permitted” produces shadow use. Explaining why — “because we don’t want confidential data in public systems” — lets people make conscious decisions.
Policies that make work harder. If the policy requires three approval steps to use a helpful tool, people skip the policy and use the tool anyway. The goal is to make the safe path the easy path.
Lists that need constant updating. “Here are the 47 approved tools” becomes outdated every quarter. Better: “Here is what makes a tool safe, evaluate new ones against these criteria.”
Policies that assume everyone knows what constitutes confidential information. They do not. Give examples. Customer names: probably fine. Customer contract terms: confidential. Product timeline: confidential. Salary information: definitely confidential.
Distributing and updating
Print it or send it as a PDF, not as a wiki page that lives in obscurity. Every new team member gets it. Every person doing a security review sees it. Make it part of onboarding.
Update it annually and whenever something changes substantially (new tool, new regulation, actual incident). But do not change it constantly. People should be able to trust that they know the rules.
What to do if someone breaks it
The point of a written policy is that the conversation becomes about the rule, not about the person. “You should have known better” becomes “we have a rule about this, let me show you.”
If someone violates it, explain the risk, update their practice, and drop it. If someone repeatedly violates it despite knowing the policy, you have a different problem — that person is not able to follow guidelines.
The policy is not enough
A written policy covers the case where someone is not thinking. It does not stop someone who deliberately wants to cause harm or extract data. It also does not stop accidental disclosure — the person who accidentally commits confidential information to a shared git repository.
But it does establish which decisions are conscious and which are habitual. Most violations are habitual. Making them conscious — “I am putting customer names into this system, is that allowed?” — is often enough to prevent them.
Template language
Here is starter language you can adapt:
We use AI tools to enhance productivity. These tools are safe to use with public information, work in progress, and business information of low sensitivity. They are not safe for confidential data including customer personal information, contract terms, source code, or unfinished strategy. Before using a new tool, check its data handling policy and data residency. If you cannot verify that your data will not be used for training the model, do not use it with company information.
You can be more specific based on your actual tools and risks, but this covers the essentials.