Writing an AI Usage Policy for Your Staff
By CodexierPublished 7 min read
Your staff already use AI tools. The only question is whether they do it inside rules you have written or inside rules they have guessed. A policy is not there to stop them; it is there to make the safe path the easy path. This guide gives you a one-page structure, the handful of rules that matter for GDPR and client confidentiality in Sweden, and a way to keep the document alive after the first month.
Why a one-page policy beats a long one
Long policies fail for a mechanical reason: the person about to paste a customer email into a chatbot will not open a twelve-page PDF first. They will act on what they remember. So the policy has to be short enough to remember, and specific enough that remembering it changes what they do. A generic sentence like use AI responsibly changes nothing. A rule like never paste a personal number into any AI tool is remembered because it is a picture, not a principle.
Approved tools and accounts
The first section names the tools staff may use and, just as important, which account to use them through. The difference between a private ChatGPT account and a company workspace is not cosmetic: business tiers typically let you switch off training on your data, give you an admin view of who uses what, and come with a data processing agreement you can actually sign. A private account gives you none of that, and IMY will not be interested in the excuse that it was convenient.
| Tool category | Approved through | Allowed for | Not allowed for |
|---|---|---|---|
| General chat assistant | Company workspace, business tier | Drafting, summarising public material, code help | Anything containing customer or employee data |
| Meeting transcription | Company account, EU data region if offered | Internal meetings with participants informed | Client calls without consent from the client |
| Coding assistants | Company licence | Code the company owns | Client code without their written approval |
| Browser extensions and unknown apps | Not approved | Nothing | Everything, until IT has reviewed them |
What data never goes into AI
This is the section that carries the legal weight, so it has to be concrete. Personal data is the obvious category, but for a Swedish company the practical list is longer than most people expect, and it includes things that do not look sensitive on the screen.
- Personal numbers, names combined with health, union, religion or financial details, and anything from HR files.
- Customer lists, price lists, margins and contract terms: confidential to you and often to your client under an NDA.
- Client material you hold under a data processing agreement. If you are a processor, the client decides which sub-processors you may use, and an AI vendor is one.
- Login details, API keys and internal documents marked confidential.
- Anything from a client in a regulated sector, such as healthcare, finance or law, unless that client has approved the tool in writing.
Give staff a way to still get the help they want: describe the case in general terms, replace names with roles, and strip the numbers. Most drafting and summarising tasks work just as well on anonymised text, which is why a policy with an allowed path is followed and a policy that only forbids is worked around.
Checking output before it leaves the company
Language models produce confident text, including confident text that is wrong. The policy should state that AI output is a draft until a person has checked it, and it should say what checked means for the common cases in your business.
Customer-facing text
Read every sentence. Verify any fact, price, date or legal claim against the source. The sender is responsible for the content, not the tool.
Numbers and calculations
Recompute in a spreadsheet. Models are unreliable with arithmetic, VAT rates and currency conversion, and the error usually looks plausible.
Code and configuration
Review as if a junior colleague wrote it: run the tests, check licences on any snippet that looks copied, and never paste generated code into production without reading it.
Anything about a real person
Do not let a model summarise, assess or rank a person without a human owning the conclusion. The AI Act treats some of these uses as high risk, and the reputational cost is immediate.
Review and training rhythm
A policy dated last year is a signal that nobody is looking. Put a review date on page one, assign an owner, and treat the first quarterly review as the moment to add the tools people have actually started using. Training does not need to be a course: a thirty-minute walkthrough with three real examples from your own work does more than a slide deck, and repeating it for new hires is a checklist item, not a project.
- Quarter one: publish the page, walk every team through it, collect the tools people already use.
- Quarter two: add or remove tools, sign the data processing agreements for the approved ones, and update the forbidden-data list with real incidents.
- Every quarter after that: a fifteen-minute review, plus a note in the onboarding checklist.
- Whenever a client asks: be able to send the policy the same day. It is increasingly part of supplier due diligence.
When you do not need help with this: if you are a five-person company with no client data and no regulated customers, write the page yourself using the structure above, and you are done. Where a review pays for itself is when you process data on behalf of clients, when several tools are already in use with nobody sure which accounts they run on, or when you are about to build AI into a product or process. That is the situation our AI integration audit is designed for: it maps the tools in use, the data that flows through them and the agreements missing, and hands you the policy as one of the outputs. Details are on the pricing page, or book a short call to talk it through first.
Frequently asked questions
Can we simply ban AI tools instead of writing a policy?
You can write the ban, but you cannot enforce it on personal phones and private accounts, so a ban tends to move usage out of sight rather than stop it. A policy with approved tools and an allowed path is followed more often, which is what actually reduces the risk.
Do we need a data processing agreement with the AI vendor?
If any personal data goes into the tool, yes, and the vendor's business tier is usually where one is offered. If your policy forbids personal data entirely and that is actually followed, the need is smaller, but most companies find the line is crossed within weeks, so signing the agreement is the safer default.
Does the EU AI Act change what a small company must do?
For most small companies using off-the-shelf chat and drafting tools, the main obligation is AI literacy: staff who use the tools should understand what they can and cannot do. Your policy plus a short training session is a reasonable way to meet that. Building AI into decisions about people, such as recruitment, brings much heavier requirements.
Should the policy cover AI features inside tools we already use?
Yes, briefly. Copilot in Microsoft 365, AI summaries in your CRM or helpdesk, and transcription in your meeting tool all process the same data. Name them in the approved list, check where the vendor processes the data, and apply the same forbidden-data rule.
Not sure which tools your team is already using?
Fifteen minutes to walk through what is in use, which data flows through it and what a one-page policy would need to say. We will tell you plainly if you can do it yourself.
Book a free 15-minute call