How to write an AI usage policy for your company. Seven steps

An AI usage policy is an internal document that tells employees which AI tools they may use, on what data, under whose oversight, and what to do when something goes wrong. The AI Act does not require such a document by name, but it requires measures that, without one, end up scattered across departments and individuals.

Below are seven steps, control questions for each and a list of the things that usually break a policy at the drafting stage.

When does an AI usage policy make sense?

The legal position is current as of 25 August 2026. This piece is written for a deployer - a company that uses off-the-shelf tools under its own responsibility.

Article 4 has required measures supporting the development of AI literacy since 2 February 2025. After the amendment introduced by Regulation 2026/1744, the provision no longer requires guaranteeing a specific level for any individual, but you still have to show that measures were taken and that they were reasonably chosen. A policy is one of those measures and, at the same time, the document that organises them. On top of that comes Article 50, applicable from 2 August 2026, and the prohibitions in Article 5.

Step 1: Scope - who and what does this policy cover?

The most common mistake happens in the first sentence. A policy addressed to employees leaves out contractors, freelancers and agencies working with company data. Article 4, however, speaks of staff and other persons dealing with the operation and use of AI systems on the organisation's behalf.

Control questions: Does the scope cover people outside an employment contract? Does it cover the board, not only staff carrying out the work? Does it cover tools used on personal accounts for work tasks? Has anyone checked how the scope interacts with subcontractor agreements?

A narrowly written scope looks cautious, but in practice it leaves out the people most likely to be working with someone else's data.

Step 2: Tools - what may be used, and what may not?

A ban with no alternative loses to a deadline. An employee with something due on Friday will open whatever tool is on their personal phone. An approved list works better than a banned list, provided every routine task has at least one entry on it.

Control questions: Does the list cover real tasks, not just the convenient ones? Does it state which plan and which account each tool must be used on? Does it describe how to request a new tool? Is the list somewhere people can reach without asking for a link?

This list should come straight from the AI system register. Without a register, the policy will describe tools the company does not use and miss the ones it actually does.

Step 3: Data - where does the line sit on what may be pasted in?

This is the hardest step and the one where policies most often turn useless. The line “do not paste in personal data” does not work, because half the people reading it will not recognise personal data in the document in front of them. What works is naming document types: contracts, payroll, contact databases, medical records, material covered by an NDA.

Control questions: Is the line drawn by document type rather than legal category? Is there a sentence on what to do when in doubt and who to ask? Does it cover data that reaches the tool indirectly, for example through a browser plugin? Does the rule differ between the paid company plan and a free one?

A line drawn in the language of the statute is formally correct and operationally dead.

Step 4: Verification - who is responsible for checking the output?

A model phrases a sentence in exactly the same tone whether it is right or making things up. The policy therefore has to say plainly that responsibility for content rests with the person who sends it, not the tool that generated it. It is worth distinguishing internal material from anything going to a client or into publication.

Control questions: Is it named, by person or by role, who checks content going outward? Is there a rule for numbers, dates and quotes a model can invent? Does it describe what to do with material that cannot be verified? Does the rule cover code and spreadsheets, not only text?

Without this step, the policy tells people what not to paste in and stays silent on what is safe to send out.

Step 5: Approval - which decisions need someone's sign-off?

Not everything needs approval, and a policy that fails to say so becomes something people route around within a week. Approval is worth requiring for three things: a new tool, a new data category in a tool already in use, and publishing AI-generated content externally, because that is where the Article 50 disclosure duties kick in.

Control questions: Is it clear who approves and how quickly they respond? Is there a path for when that person is out? Is the approval recorded anywhere? Does the list of things needing sign-off fit in a handful of points?

A long approval list does not buy more control, it just moves the work into channels nobody sees.

Step 6: Incidents - what to do once something has already happened?

This section is three sentences long and saves more than everything else combined. Who to notify, how fast, and what not to do. The last point matters most: never delete the conversation with the model, because it is the only record of what left the company.

Control questions: Does the document name a specific person and channel to notify? Does it say plainly that reporting does not end in a penalty for the person who reports? Is there a sentence on preserving the record? Has anyone checked how this path connects to the personal-data breach procedure?

A policy silent on what happens afterwards turns every incident into silence. Whether a personal-data breach has occurred is for whoever handles that to decide.

Step 7: Review - how does the policy keep up with change?

Write a review date into the document and the triggers that bring it forward: a new tool in the register, a change in a vendor's terms, a change in the law. Article 4 changed wording in July 2026, so this is not a hypothetical.

After this step you have a document you can show: a scope that reaches contractors, an approved-tools list that matches the register, a data line written in plain language, named responsibility for verification, a short approval list, an incident path, and a date and owner for the next review.

Frequently asked questions

How long should an AI usage policy be?

As long as people will actually read. One to three pages works, thirty does not. Keep exceptions and reasoning in an appendix.

Is a policy enough to meet the Article 4 obligation?

Not on its own. Article 4 speaks of measures supporting the development of AI literacy, and a document nobody has been walked through is not literacy delivered.

Do we need a separate AI policy for every department?

Usually not. One policy plus short department-specific rules where the risk genuinely differs, for example in marketing and HR, is enough.

By hand or with a tool?

You will write the first draft of the policy yourself, in a text editor, and that is how it should start - it has to speak about your company. The work begins afterwards: acknowledgements, tracking who received which version, and linking the document to the register and to training. The AI TrustCERT platform keeps the policy alongside acknowledgements and a record of the measures taken, included in the price of the training licence. It supports the process and organises the evidence, it does not replace a legal assessment. Open it for seven days without a card and see how it looks with your own rules.

Summary

An AI usage policy is not an explicit AI Act requirement, but it organises what the regulation does require. The scope has to reach contractors and the board, because Article 4 covers people acting on the organisation's behalf, not only payroll staff. An approved-tools list beats a banned one, provided it covers real tasks and is taken straight from the AI system register. Draw the data line by document type, not legal category, or nobody recognises it in practice. A named person owns responsibility for content leaving the company. Keep the approval list short, or the work moves to channels nobody sees. Fit incidents into three sentences, banning deletion of the conversation, and finish with a review date.

This material is for information purposes. It is not legal advice or a guarantee of compliance with the AI Act. For a specific organisation, consult a lawyer.

✦ This article was written with the help of artificial intelligence and reviewed before publication by the author, who takes editorial responsibility for it.