Guidance · The AI Act and the internal rule
Six areas an internal rule should cover, each with a sample clause and the reason it belongs there. Not a template to adopt, but a basis for writing your own.
Let us start with what usually causes the confusion: the Artificial Intelligence Act, Regulation (EU) 2024/1689, nowhere imposes an obligation to have an internal directive on the use of AI. Anyone telling you otherwise is pointing at Article 4 — and that article reads differently from the way it is quoted.
Article 4 was replaced in full by Regulation (EU) 2026/1744, the digital omnibus on artificial intelligence, and its wording was softened. Originally, providers and deployers took measures to ensure, to their best extent, a sufficient level of AI literacy. Under the new Article 4(1) they take measures to promote the improvement of AI literacy, and the text expressly adds that this obligation does not require providers or deployers to guarantee any specific level of literacy for any individual. The new wording has been effective since 27 July 2026.
The personal scope has not changed, though. The obligation falls on providers and on deployers, in relation both to their staff and to all other persons dealing with the operation and use of AI systems on their behalf. What has to be taken into account is the technical knowledge, experience, education and training of those persons, the context in which the systems are used, and the persons or groups of persons on whom the systems are to be used. Contractors and suppliers acting on your behalf have therefore not dropped out of scope.
A practical conclusion follows from that. A rule for using AI is not compliance with Article 4 in itself, because Article 4 speaks of measures to promote the improvement of AI literacy, not of a document. At the same time it is the cheapest way to organise such measures and to evidence them — and above all it deals with things Article 4 says nothing about: what may be sent out of the company, who approves a new tool, and what to do when a feature nobody ordered turns up in a marketing tool.
The penalty side of it is elsewhere than expected too. Article 4 is not listed among the provisions in Article 99(4), where the ceiling is EUR 15 000 000 or 3 % of total worldwide annual turnover. The AI Act therefore sets no specific administrative fine for a breach of Article 4; what applies is the general duty of the Member States under Article 99(1) to lay down effective, proportionate and dissuasive penalties — a paragraph the omnibus rewrote so that it now expressly contemplates warnings and non-monetary measures alongside fines. The prohibitions in Article 5, which the rule helps you not to cross, carry the highest rate — up to EUR 35 000 000 or 7 % of turnover under Article 99(3).
Set the scope of the rule before you start writing. A company that only uses AI in finished tools needs a different document from one that fine-tunes a model on its own data or builds it into a product — the latter can end up in the provider role under Article 25(1), with its obligations multiplying. This page is written for the first case.
The most common mistake is a rule written in general terms: approved AI tools may be used. That decides nothing. An employee opens any tool at all and, without a list, has no way of finding out whether it is approved, so answers the question themselves — and answers yes.
The list of approved tools is therefore the one part of the rule that should not sit in the text of the directive. It belongs in an annex or a table that can be changed without an approval round over the whole document — otherwise the list goes stale within a month and the rule stops applying as a whole, because people notice it does not match reality.
For every entry on the list you need to know four things, and all four for a different reason. Who owns the tool inside the company, because otherwise there is nobody to put questions to the supplier. Which variant was purchased, because the free and the business variant of the same tool differ in what they do with your input. What purpose it is approved for, because extending the purpose is precisely the moment when use turns into something else. And whether any transparency obligation attaches to it, because that cannot be retrofitted.
Word it so that it also covers tools that are not on the list. A closed list without an express prohibition of everything else is a rule that prohibits nothing — and that is exactly where most corporate AI directives fall apart.
Three things to notice in the sample: it prohibits trial mode as well (the most common gap), it ties the permission to the variant and the purpose rather than to the name of the tool, and it separates the annex from the text so that it can be updated. Write your own wording — yours will read differently already because you have different roles and a different way of approving documents.
This is the area most companies start writing the rule for, and at the same time the one where they most often miss. The typical attempt looks like this: sensitive data must not be entered into AI tools. In practice, though, the word sensitive means something different to everyone, and on the strength of such a sentence nobody dares say whether they may paste in the minutes of a meeting.
What separates a usable rule from an unusable one is that it refers to a classification you already have in the company, not to a feeling. If you have confidentiality levels for documents, you say which levels may go where. If you do not have them, you list specific kinds of content — and a short specific list beats a long abstract one.
The other half of it is that a prohibition has to come with an alternative. A rule that only says no manufactures circumvention: the person has a task, the tool is at hand, and the only thing the rule achieves is that nobody will know about it. So a prohibition needs a sentence on what to do instead — anonymise, use another tool from the approved list, or ask the owner.
One novelty deserves particular care, because it invites the opposite reading. The omnibus inserted a new Article 4a into the AI Act which, under strict cumulative conditions, allows special categories of personal data to be processed for the purpose of detecting and correcting bias, and extended it to deployers as well. The conditions are hard: the processing cannot be effectively carried out with other data, including synthetic or anonymised data; technical limits on re-use apply, together with state-of-the-art security measures including pseudonymisation, strict controls and documentation of access, a prohibition on transmission to other parties, deletion once the bias has been corrected or at the end of the retention period, whichever comes first, and a justification in the records of processing activities. And above all: the text itself says that this paragraph does not create an obligation to carry out bias detection and correction. Article 4a therefore does not belong in an ordinary corporate rule as a permission, at most as an express exception for one specific, pre-assessed case.
This area usually calls for a technical measure as well, not just text. A rule resting solely on discipline holds for the first month. A picture of which tools are really used in the company and what data leave through them can be obtained from outputs you already have — from the proxy, from DNS or from the SaaS application inventory.
Without a described route for approving a new tool, the rule has two possible outcomes and both are bad. Either everything is approved and the approver becomes the bottleneck, at which point people start going around them, or nothing is approved and the list from area 1 stops matching reality.
A sensible route is short, has one decision-maker and a fixed set of questions. Five questions are enough and four of them come straight from the regulation. First: does the intended use fall under any of the prohibitions in Article 5? Second: does the use give rise to a transparency obligation under Article 50, meaning someone will have to be informed? Third: is this a high-risk system under Article 6? Fourth: does the use make us a provider under Article 25? And fifth, outside the regulation but the most important one in practice: what data will flow into the tool and what does the supplier do with them.
The fourth question deserves elaboration, because it is the least known and hurts the most. Under Article 25(1) a deployer becomes the provider of a high-risk AI system in three cases, and the omnibus did not change them: where it puts its own name or trademark on a high-risk system already placed on the market; where it makes a substantial modification to a high-risk system already placed on the market in such a way that it remains high-risk; and where it modifies the intended purpose of an AI system, including a general-purpose AI system, that was not classified as high-risk in such a way that it becomes high-risk under Article 6. The consequence is single and fundamental — the provider obligations under Article 16 apply to you.
That is exactly why the approval question has to target the intended purpose, not the name of the product. The same general-purpose tool is an aid for rephrasing text in one case and, once connected to HR data and to decisions about candidates, something else entirely.
Do not complicate this process with a ten-field form. The goal is not a perfect record but a request that can be filed in five minutes — because the only competition the approval route has is the option of asking nobody and simply starting to use the tool.
If AI in companies were used only where IT deployed it, this area would be pointless. Reality is different: most of it is used in tools bought by marketing, HR or sales, and often they are not AI tools at all — they are ordinary applications into which the supplier added a feature in an update and switched it on by default.
That has two consequences for the rule. First, the rule must not be addressed only to technical people and must not be written in language only they understand. Second, it has to allow for a new feature appearing without any purchase at all, which means outside the processes by which the company normally controls what gets in.
Two categories deserve particular attention, because the legal consequence is harshest there and least expected. The first is tools that evaluate people in the workplace. Article 5(1)(f) prohibits the placing on the market, the putting into service for this specific purpose, or the use of AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except where the AI system is intended to be put in place or into the market for medical or safety reasons. The omnibus did not touch this point at all — it has applied since 2 February 2025 in its original wording. A tool that estimates the mood of the speaker on client calls or in interviews is therefore in scope regardless of the fact that nobody knowingly bought it as an AI system.
The second category is tools generating content for the outside world. They may give rise to a transparency obligation under Article 50, which applies from 2 August 2026 and was not postponed. A marketing department that switches on image generation can thus create an obligation for the company that it learns about only from someone outside it.
The sentence saying the feature is not used until a decision is taken is in the sample on purpose — without it the rule describes an ideal state and does not say what a person is to do on Monday morning when the tool offers them a new feature. It also holds that such a prohibition can only be enforced where the feature can in fact be switched off; otherwise you create a rule that breaks itself.
The last substantive area is also the most misunderstood. After the amendment of Article 4, what is evidenced are the measures, not the level of knowledge attained. The new wording says expressly that the obligation does not require providers or deployers to guarantee a specific level of AI literacy for any individual. Does that mean nothing has to be evidenced? No — it means that what is evidenced is something other than what companies are used to from other training obligations.
What you want to show is that you adopted the measures, that they match the roles and the environment in which AI is used, and that they are repeated. Those are exactly the three things Article 4(1) targets when it requires account to be taken of the technical knowledge, experience, education and training of the persons concerned, of the context of use and of the persons or groups of persons on whom the systems are to be used. A company where five people use AI to rephrase texts and a company where AI pre-screens CVs are supposed to have demonstrably different measures.
The material that will carry the evidence arises by itself in the ordinary running of the rule, as long as a few things get written down. Creating a separate register for it is unnecessary and usually ends in a spreadsheet nobody updates. What matters is that the records read as a process, not as a one-off exercise before an inspection.
A note on wording: do not put sentences such as the company complies with the requirements of the AI Act into the rule. Such a claim cannot be evidenced, because compliance is assessed for a specific system and a specific role, not for the company as a whole. Write down what you do — that you can defend.
Nobody today knows exactly how supervisory authorities will assess compliance with Article 4, and any material claiming otherwise is making it up. Guidance does exist, though, and it is written into the regulation itself: under the new Article 4(2) the Commission is to publish practical examples of compliance on the single information platform under Article 62(3)(b), and under paragraph 3 the European Artificial Intelligence Board is to adopt a recommendation with common objectives. Once they appear, they are the first documents your measures will be compared against.
Knowing what to leave out of the rule matters as much as the content. Nobody reads an overloaded document, and its only effect is that the company settles into the conviction that AI rules are incomprehensible.
The first category to strike out is restating the regulation. Copying definitions and lists from the AI Act into an internal rule creates two risks at once: the document becomes unreadable, and it stops matching the law with every amendment. A link to EUR-Lex serves this purpose better than any careful transcription.
The second category is prohibitions with no addressee. The sentence that Article 5 must not be breached is true, but it tells nobody what to do or not do. The prohibitions in Article 5 belong in the rule translated into situations that can arise at your company — typically into the approval question for new tools and into the description of what is not used in the workplace.
The third category is provisions that do not apply to you as a deployer. The provider obligations under Article 16, conformity assessment, technical documentation and registration are a world you enter only when one of the circumstances in Article 25(1) occurs. What belongs in the rule is one sentence flagging that boundary, not a chapter describing it.
And the fourth, quietest category: promises you cannot keep. A sentence saying that all use of AI is monitored is untrue without a corresponding technical measure, and the moment somebody finds that out, the whole document loses credibility.
A useful test of the finished text: give the rule to someone who uses AI in the company every day and has neither legal nor technical training, and ask them about three specific situations from their work. If they cannot find the answer in the rule within a minute, the document is too long or written for a different reader from the one it is meant for.
2026 showed why this section cannot be missing. Regulation (EU) 2026/1744 replaced Article 4 in full, moved the dates of application in Article 113, added two new prohibitions to Article 5 and amended Article 25. A company that wrote its rule in 2025 and has not returned to it since now has sentences in it that do not match the wording in force.
The opposite of excessive activity holds as well: rewriting the rule at every change in the law is as bad as never rewriting it. A document that changes four times a year goes unread, because reading it does not pay. The solution is to separate the stable part from the variable one — principles and roles belong in the text of the rule, tools, data and dates in the annexes.
There is one owner and it is named by role. Shared ownership means in practice that nobody owns the rule and the review is put off until somebody from outside asks about the document.
A note on the postponements that often gets lost in summaries: the postponement under point (c) of the third subparagraph of the new Article 113 concerns Chapter III Sections 1, 2 and 3, with the exception of Article 6(5). It does not concern Chapter IV, meaning the transparency obligations under Article 50, nor Chapter III Section 5. Anyone who wrote into their rule that the AI obligations are postponed to 2027 has a sentence there that does not hold.
This is not a requirement of the regulation. It is the order that works for us — it follows from the fact that every step needs the result of the previous one. The most common mistake is to start by writing the text; the document then describes an idea of how AI is used in the company, not the reality.
The statements about obligations and deadlines on this page are based on the following sources, as of 9 August 2026. This material does not replace the text of the law — what is binding is what appears in the Official Journal.
You are adopting AI and dealing with data
An initial consultation on which AI tools run in the company, what data leave through them and what follows from that under Articles 4, 5 and 50. The output is a list of the areas your rule has to cover and the order in which to address them. Tell us what you are adopting.