Internal AI Use Policy: A Template in Eight Clauses

An internal AI use policy is a short document — two or three pages, not twenty — that answers the four questions your team is already asking every day: which tools may I use, what information may I paste into them, who reviews what they produce, and what happens if I get it wrong. If your company has not written one, that does not mean there is no policy. It means everyone has quietly decided their own.

This article gives you the full template as clauses you can copy and adapt, plus the part that is usually missing: how to roll it out so it does not end up as a PDF nobody has read. And there is a reason to do it now beyond common sense: EU rules already require companies deploying AI systems to ensure an adequate level of AI literacy among their staff, and that obligation has applied since 2 February 2025 (verified August 2026).

What should an AI use policy contain?

Eight sections, and not one more. Long policies do not get read, and a policy nobody reads protects nothing. Its only real job is to let the person hesitating at eight in the evening know what to do without asking anyone.

1. Scope: who it applies to (staff, interns, freelancers, suppliers) and to which uses.
2. Approved tools and how to request a new one.
3. Data classification: what may be pasted into an AI tool and what never may.
4. Human review: which outputs require validation before leaving the company.
5. Transparency: when AI involvement must be disclosed, internally and externally.
6. Confidentiality and IP for what goes in and what comes out.
7. Mandatory training and who receives it.
8. Breaches: what happens when someone ignores the policy, and how to report a mistake without fear.

Template: the policy in eight clauses

What follows is real base text written for a small or mid-sized company. Adapt it to your context, review it with your employment counsel before publishing, and date the version.

1. Scope. This policy applies to everyone working for [COMPANY] — employees, interns, external collaborators and suppliers with access to our systems — and to any use of artificial intelligence tools in the course of their work, whether the tool was contracted by the company or not.

2. Approved tools. Only tools on the approved tool list, published at [LOCATION] and reviewed quarterly, may be used with company information. To propose a new tool, open a request to [OWNER] stating the purpose, the type of data involved and the provider. Using personal or free-tier accounts with company information is not permitted, because on most free plans the provider may use submitted content to train its models.

3. What information may be entered. Information is classified in three levels: public, internal and restricted. Public information may be used with any approved tool. Internal information may only be used with approved tools covered by a business contract. Restricted information is not entered into any AI tool without express authorisation from [OWNER]. The classification table forms part of this policy.

4. Human review. Any AI output that goes to a client, a supplier, a public authority or external publication must be reviewed by a responsible person before it is sent. Responsibility for the content always sits with whoever signs it, never with the tool. In matters with legal, financial or health implications, the review is performed by a qualified professional.

5. Transparency. Internally, documents produced with AI assistance are flagged as such where that is relevant to the recipient. Externally, when a customer interacts with an automated assistant they will be told they are speaking with an AI system and will always be offered access to a person.

6. Confidentiality and intellectual property. Personal data of clients, employees or candidates is not entered without a legal basis and without the tool being covered by an appropriate data processing agreement. Code, documentation or material subject to third-party confidentiality agreements is not entered. Before publishing or commercialising AI-generated material, it is checked that it does not reproduce someone else's work.

7. Training. Everyone with access to AI tools receives initial training before access is granted and an annual refresher, with content adapted to their role. Training covers tool capabilities and limits, error risks, and this policy. Attendance is recorded.

8. Breaches and error reporting. Breaches of this policy are handled under the applicable disciplinary framework, proportionately: an oversight is not the same as a deliberate data leak. Reporting your own AI-related mistake in good faith will not be sanctioned; concealing it will. Incidents are reported to [OWNER] within 24 hours.

What data can be pasted into an AI tool, and what cannot?

This is the most consulted table in the whole policy, so it should fit on one screen and leave no room for interpretation.

Two clarifications that resolve most real-world doubts. First: poor anonymisation does not turn restricted data into internal data — if the text still allows the person to be identified from context, it stays restricted. Second: credentials and API keys are never pasted, into any tool, under any circumstances, not even "just to debug this quickly".

What exactly does the EU AI Act require?

For a company that uses AI rather than develops it, the most direct obligation already in force is literacy: Article 4 of the EU AI Act requires providers and deployers to ensure a sufficient level of AI literacy among their staff, and it has applied since 2 February 2025. The simplification package known as the Digital Omnibus on AI — Regulation (EU) 2026/1744, in force since 27 July 2026 — deferred the high-risk obligations for Annex III systems to December 2027 and Annex I to August 2028, but it did not defer the literacy obligation, which stays on its original timeline. Verified August 2026; this calendar has already changed once, so reconfirm before making decisions on it.

The practical reading is convenient: the training in clause 7 of the template is not a goodwill extra, it is the most direct way to comply. And the transparency in clause 5 anticipates user disclosure obligations. If you are also deploying agents that act on your systems rather than assistants that write text, a use policy is not enough on its own — you need the permission and traceability layer we describe in AI agent governance and permissions.

A restrictive policy, or one people actually use?

This is the underlying decision, and it is cultural rather than editorial. A policy that only prohibits achieves precisely the opposite of its intent: people keep using AI because it solves their day, they just stop mentioning it. That is shadow AI, and it is considerably worse than uncontrolled use, because it happens in personal accounts, with no business contract and no visibility at all.

A policy that works does three things at once: it prohibits little and clearly, it offers an approved alternative for nearly everything people need, and it does not punish honest error reporting. If a salesperson needs to summarise calls and your policy gives them no tool for it, they will use their own. The approved tools section is not bureaucracy — it is the mechanism by which the policy enforces itself.

We run our own businesses this way, and the most useful lesson has been this: the approved tool list has to be genuinely reviewed every quarter, because an outdated list pushes people outside the policy faster than any prohibition.

How to roll it out so it does not become a forgotten PDF

1. Inventory what is already in use. Ask without sanction and with explicit amnesty. The real list is always surprising.
2. Approve tools for the three or four most frequent uses before publishing anything. Publishing prohibitions without alternatives kills the policy on day one.
3. Write the short version using the template above, dated, with a named owner.
4. Train before you enforce. One hands-on session per area, using examples from their real work, beats a generic course. We develop it in AI training for employees and its ROI.
5. Review quarterly: the tool list and the reported incidents, then adjust.

If the question underneath all of this is where your data is actually processed, the comparison is in on-premise versus cloud AI and privacy, and if you want the wider organisational frame, it sits inside the AI-first operating model.

Frequently asked questions

Is an AI use policy legally required?

EU rules do not mandate a document called "AI use policy", but since February 2025 they do require ensuring AI literacy among staff, and GDPR requires controlling which personal data is processed and where. A written policy is the most efficient way to evidence both, and in practice it is the first thing an auditor or a large enterprise client will ask you for.

How long should it be?

Two or three pages for the policy itself, plus a data classification table and an approved tool list kept separately, because those change far faster than the text. If your policy runs to fifteen pages, what you have written is a manual — and you will still need a two-page policy for anyone to read it.

Does it apply to suppliers and freelancers?

Yes, and it should be explicit in the scope clause as well as reflected in contracts. The risk of an external collaborator pasting your documentation into a free tool is exactly the same as an employee doing it, except you have less direct control over them.

What do we do if AI is already being used without control?

Amnesty and channelling, not discipline. Open a short declaration window with no consequences, log everything that surfaces, quickly approve tools that cover the legitimate uses, and close the rest by offering an alternative. Pursuing existing usage without providing a substitute only teaches people to hide it better.

How often should it be reviewed?

The tool list quarterly. The policy text annually, or whenever something material changes: a new agent deployment, a regulatory change or an incident. Put a visible version date in the header — an undated policy is rightly treated as a doubtful one.