Guide · AI policy

A company AI policy: what goes in it, and a ready template.

An AI policy is two pages of house rules that tell employees what they may do with AI, what they may not, and who is responsible. This guide covers why every company needs one, what goes in it, how you know it is being followed, and how to roll it out in an hour. A ready template is at the end.

Updated 10 September 2026 · Reading time about 10 minutes · Jump to the template

What an AI policy is, and what it is not

It is a short, everyday document. Two or three pages that an employee reads once and returns to when unsure. It answers practical questions: which tools may I use, what may I enter into them, what must I check myself, what do we tell customers, and whom do I ask.

It is not a 40-page framework, a security standard or a legal contract. A document nobody reads governs nothing. A good policy is short enough to fit into onboarding and concrete enough to settle a single situation.

Why it is needed now

The absence of a policy does not mean there is no AI use. It means nobody knows how it is used. Five reasons management should take seriously:

• Customer data ends up in consumer tools. When an employee pastes a customer's email into a personal ChatGPT account to summarise it, the content may be used to develop models unless the user has turned that off in the settings. Business versions such as ChatGPT Business, Microsoft 365 Copilot and Gemini for Google Workspace do not use the company's content to train models. The difference is the licence, not the tool.
• Data protection and customer contracts. Processing personal data in an AI service needs a legal basis and, where the provider acts as a processor, an appropriate data processing agreement. Many customer contracts contain a confidentiality clause that makes no exception for "I only summarised it".
• The EU AI Act. Article 4, as amended in July 2026, requires providers and deployers of AI systems to take measures to support the development of their staff's AI literacy. A policy and the short training that goes with it can be part of those measures and help document them.
• Confident-sounding errors. A language model writes convincingly even when it is wrong. Without an agreed checking practice, the error goes to the customer in the company's name.
• Unclear responsibility. Who is responsible for a proposal drafted by AI, and in whose name does it go out? The policy answers in one word: the sender.

The ten sections a good policy has

Below is the skeleton. Each section has two parts: what the company has to decide, and the most common mistake. The template at the end follows the same order.

Rolling it out in an hour

1. Fill in the template (30 minutes). Decide the approved tools, the traffic lights and the owner. Do not polish the wording, polish the decisions.
2. Get management sign-off (10 minutes). The policy is a management position, not an IT instruction.
3. Hold a 20-minute session for staff. Walk through the traffic lights, three everyday examples, and what the company can and cannot see. Take questions. Record attendance.
4. Ask for acknowledgement. An email reply or an entry in the HR system is enough.
5. Make the tool settings match the policy. Business licences on, sign-in with company accounts, data visibility limited. This is where paper becomes practice, and it is usually the part where help is needed.
6. Put the review in the calendar six months ahead.

The most common mistakes

• Banning everything. Use does not stop, it moves to personal devices and out of sight. A ban is the worst possible policy.
• Writing too much. If the document does not fit on two pages, it is not read.
• Not naming tools. "Approved tools" without a list is an empty phrase.
• Policy without settings. A rule the tool's settings do not support is forgotten on the first busy day.
• No training, no updates. Then the document exists but does not shape daily work.

How do you know it is being followed?

Not everything can be seen, and not everything should be. The aim is not to watch employees but to make the approved tools the easiest option, to catch the significant security risks, and to make sure the tools' settings support the agreed rules. What a company can see depends on its tools, licences and device management. And in Finland any technical visibility into what employees do is regulated: it is introduced openly and discussed with staff, never quietly. Visibility comes in layers:

• Use of the approved tools. The Copilot usage reports in the Microsoft 365 admin centre and the workspace analytics in ChatGPT Business show how many people use the tools and how much. Microsoft's reports hide user names by default, and that is a good default. Low adoption in one team is the first hint that something else is in use.
• Apps connected to company accounts. Both Microsoft Entra and Google Workspace list the apps someone has granted access to a company account or its data, and new connections can be limited to admin approval. These controls are basic settings in both environments, and the exact features depend on the licence or edition. They show only apps connected through sign-in, not websites anyone visits.
• Which AI services work computers talk to. Here the right tool depends on the licence. Defender for Business, included in Microsoft 365 Business Premium, protects the network traffic of work computers and can block and report website use. Wider visibility into which cloud services are used and by whom needs additional capabilities such as Defender for Cloud Apps, a separate add-on to Business Premium. Without Microsoft device management, a DNS or web filter with an agent on work computers can provide basic visibility into and control over access to certain services. All of these are technical monitoring, see the box below.
• What has been entered into the approved tools. Less is visible here than many assume. The Microsoft 365 audit log records metadata about Copilot interactions: the user, the time, the app used and the files referenced, not the content of prompts and responses. Access to the content requires separate Purview or eDiscovery features and is not part of normal usage reporting. In ChatGPT Business the admin cannot read workspace members' conversations; organisation-level conversation logs are Enterprise and Edu features. So "what has been entered" is secured through settings, for example by restricting who can see personal data and confidential files, so that Copilot cannot surface what a user should not see anyway.
• Blocking the paste. Microsoft Purview endpoint data loss prevention can detect customer data being pasted into consumer services, and Purview's AI reports show in aggregate whether sensitive data is entered into Copilot. Both need an E5-level licence or an equivalent add-on, so for most SMEs they are a later step, not the starting point.

What cannot be seen: a personal phone on mobile data. The company's network, DNS or device monitoring does not see what is done on an unmanaged personal phone on mobile data, and claiming otherwise would be dishonest. That is why the policy, the training and an easy approved path decide the outcome, and why reporting an incident is welcome and not punished.

The goal is not to monitor people. It is to make the approved path the easiest, to see the big leaks in time and to keep the settings in line with the policy. The visibility and blocking settings belong to configuring the tools, and checking them monthly is part of the reporting.

This guide and template are practical guidance, not legal advice. Check questions about the processing of personal data, the introduction of technical monitoring and customer contracts with a data protection officer or a lawyer where needed. Tool capabilities and licences were checked against the vendors' documentation on 10 September 2026, and they change.