AI training · Internal rules
The internal AI use policy
One or two pages an employee actually reads: which tools are approved, what data may go into them, when the output must be checked, and who is accountable. This page sets out what belongs in that document and what keeps it from going stale within six months.
Definition
What is an AI use policy?
An AI use policy is an internal company document stating which AI tools are approved, what data may be put into them, when the output must be checked before it is relied on, and who inside the company is accountable for those rules. The market also calls the same document AI guidelines, an AI acceptable use policy, or employee AI rules. The content does not change with the name: it is the one place where a member of staff finds, in half a minute, the answer to “can I upload this”.
What separates it from a general information security procedure is specificity. A security procedure talks about principles. An AI policy talks about actions at the keyboard: which account to use, what to strip out of a text before uploading it, what to do with a result that looks right. So it is written in plain language and kept short. A long document protects the company formally and changes no behaviour, and behaviour is the risk. One or two pages is the right length. This policy is part of the AI training for companies programme, because rules written without the team do not survive contact with the work. The Lithuanian edition is at DI naudojimo politika įmonėje.
Context
Shadow AI: use without rules is already happening
The question inside a company is almost never whether to start using AI. The question is whether it is happening under agreed rules or without them.
All four figures come from the same study: IBM’s annual Cost of a Data Breach Report, which analysed 600 breached organisations in 17 industries around the world. What people actually put into these tools when nobody has decided is covered in shadow AI: what employees paste.
Contents of the document
What an AI use policy has to cover
Eight sections. Together they fit on two pages, provided each one is written in sentences rather than paragraphs.
Scope and who it applies to
Who the document binds: employees, managers, interns, contractors and freelancers working in the company’s name. Alongside that, which activity it covers, because the rules for marketing copy and the rules for handling customer data cannot be the same rules.
The list of approved tools
Actual product names, not the phrase “trusted tools”. Against each one: which account type is used (personal or company), which class of data it is approved for, and who can add a new tool to the list. Without this section the rest of the policy stays theoretical.
Data classes and their boundaries
Data is sorted into a few unmistakable groups, and each group is told where it may be processed. An employee needs the answer in five seconds, so there have to be few classes and they have to be recognisable at a glance, without a legal assessment.
Prohibitions, written concretely
A short list of things nobody does, with any tool. Being specific matters more than being complete: the line “do not upload a customer contract with prices in it” works better than a general clause about protecting confidential information.
Checking and labelling
When AI-assisted output must be checked, who checks it and how that is visible. Alongside it, whether and where material has to be marked as AI-assisted: in internal documents, in client material, in public communication.
Accountability and who decides
Who owns the policy, who rules on unclear cases and who is told about an incident. One name with a job title, not a department. Alongside it, the statement that accountability for the output stays with the person who signs or sends the document.
Incident procedure
What to do once somebody has already put the wrong thing into the wrong tool. The important part is not the punishment but the report-without-consequences rule: if reporting a mistake is frightening, nobody reports one, and the company finds out from a customer or a supervisory authority.
Review date and version
A specific next review date and a version number. Market conditions here change in months, so a document with no review date becomes wrong inside a year, and the staff notice before the management does.
Data classes
Which data with which tool
The heart of the policy is one table. It answers a question staff ask several times a day, so the answer has to fit in a single cell. Below is the structure we adapt to your operations and your client contracts.
| Class of data | Public personal account | Company account under contract | Internal system |
|---|---|---|---|
| Public information: already published text, marketing material, public prices | Allowed | Allowed | Allowed |
| Internal non-confidential material: agendas, internal memos, training material | Not recommended | Allowed | Allowed |
| Customer personal data: names, contacts, contract numbers, correspondence | Prohibited | Only under a data processing agreement and a written process | Allowed under the GDPR procedure |
| Commercial information: contracts, pricing, supplier terms, margins | Prohibited | Only anonymised, or by a separate management decision | Allowed |
| Special category data: health, judicial, biometric | Prohibited | Prohibited without a separate legal assessment | Only under a separately written procedure |
| Access data: passwords, keys, configurations | Prohibited | Prohibited | Prohibited |
The three columns are three different legal and technical regimes, not three different vendors. A public personal account is the one an employee creates for themselves with their own email. A company account under contract means terms have been signed with the provider defining how data is processed. An internal system is one running inside an environment the company or its partner controls. Where those lines fall in your case depends on your contracts, so the actual list is drawn up together. Which product tiers differ on training defaults, retention and location, tier by tier, is on a separately sourced page: does your AI vendor train on your data. How we handle data on our own side is on the security page.
Prohibitions
What never goes into a public chatbot
This list is written out separately in the policy, and deliberately kept short. The longer it gets, the smaller the chance an employee recalls it in the second when the decision is made.
- Credentials, passwords, access tokens and API keys. This is the one line that holds absolutely, for every tool, with no exceptions.
- Customers’ personal data where there is no contractual basis for passing it to that provider. A name together with a contract number is already personal data.
- Health, judicial, financial and other special-category information, unless the process has been separately written down and assessed.
- Unsigned contracts, pricing tables, supplier terms and internal margin calculations.
- Third-party material covered by a non-disclosure agreement. The undertaking holds when the material is processed by a program rather than by a person.
- Source code containing internal secrets, configurations or integration data, unless a separately approved environment exists for it.
The rule teams remember best
If you would not email the same text to a stranger, you do not put it into a public tool either. That single line covers a larger share of real situations than a three-page classification, which is why it is worth writing into the policy alongside the table rather than instead of it. A second line covers doubt: if you are not sure, you ask the named owner rather than deciding alone.
Checking
The duty to check before relying on the output
After the data boundary, the second most important part of the policy is the check. It answers what an employee must do before sending an AI-drafted text to a customer, before putting it into a report, and before taking a decision based on it.
Tie the level of checking to the cost of an error rather than to the type of document. An internal summary needs only its author to read it. A proposal going to a customer needs the numbers and the deadlines checked by somebody who knows them from the primary source. Decisions with legal or financial consequences need a second person and an explicit signature. Three levels is enough, and four is already unmemorable.
Separately, the policy names what is checked every time regardless of level: numbers, dates, names, references to legislation, quotations, and any citation of a source. Those are exactly the places where confident-sounding text is most often wrong, and exactly the places a reader assumes have been checked. Where an AI agent is already running, the checking procedure gains one more line: what share of the agent’s conversations is reviewed, and who does it.
Why checking is a human duty
DigComp 3.0, the fifth edition of the European Digital Competence Framework published by the European Commission’s Joint Research Centre in 2025, puts it plainly in competence statement CS1.2.10: “Recognise that AI systems may produce output which is inaccurate, even if it may seem plausible, and that the human using the AI system is responsible for checking the quality and validity of information and content generated.” That wording goes into a policy almost verbatim, because it assigns responsibility, forbids nothing, and demands no technical knowledge. The Commission’s AI literacy Q&A points at the same framework, noting that recital 8 of the Digital Omnibus on AI provides that when complying with the Article 4 obligation, the Commission and the Member States could take into account the European competence frameworks.
Ownership
Who owns the policy and how it stays current
A policy with no owner goes stale within a quarter. That is not a figure of speech: the approved tool list, the account types and their features change over months, and a document nobody updates becomes not merely useless but misleading, because staff rely on it to make the wrong decision.
The owner is named with a name and a job title. In a small company that is usually the managing director or the head of administration; in a larger one, somebody from HR, legal or IT, depending on where decisions about tools are actually taken. What matters is not the department but that there is a person who can be sent a question and will answer the same day. When the owner is “a department”, questions go unanswered and staff decide for themselves.
Five signs the policy has gone stale
- The policy names tools nobody in the company uses any more, and does not name the ones people actually use.
- There is nothing about AI agents, even though part of the work is already being done automatically.
- The rules are written for text only, while the team is already using voice, image and document-processing tools.
- The named owner has left the company, or their role has changed.
- More than a year has passed since the last review, and the document carries no review date at all.
The practical rhythm is a quarterly review of the tool list and an annual review of the whole document, plus an out-of-cycle review when a new tool arrives or an incident happens. The review date goes into the document where every reader can see it. How this decision is taken at management level, and how it connects to investment priorities, is on AI training for executives. If the company is still working out which processes to change at all, the right first step is scoping rather than a policy, and how we work sets out that sequence.
Regulation
What the EU AI Act actually says about this
Internal AI policies are often sold on the claim that the EU AI Act requires one. There is no requirement in the Act to hold such a document, so we do not say that, and we would not recommend using that argument in your own internal communication either. A rule people believe was imposed from outside is followed differently from a rule the company chose.
What the Act does contain is Article 4, which obliges providers and deployers of AI systems to take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. Since 27 July 2026, when Regulation (EU) 2026/1744 entered into force, the same Article states expressly that this obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual (EUR-Lex, Regulation (EU) 2026/1744). Separately, the European Commission’s AI literacy Q&A answers the governance question outright: no specific governance structure is mandated to comply with Article 4 of the AI Act. There is therefore no provision anybody can point to that requires an AI policy document, and if a supplier claims otherwise it is fair to ask which article they mean.
Two things follow, and they need keeping apart. Article 4 is a binding obligation and has applied since 2 February 2025; what the July 2026 amendment changed is its content, not its existence. At the same time Article 4 is not listed in Article 99(4), the paragraph that sets administrative fines of up to EUR 15 000 000 or 3 percent of total worldwide annual turnover, so it carries no EU-level fine ceiling. That is not a licence to ignore it. Article 99(1) obliges Member States to lay down rules on penalties and other enforcement measures for infringements of the Regulation, and Regulation (EU) 2026/1744 widened that paragraph rather than narrowing it: administrative fines were added to the national measures it lists, and “infringements” became “any infringement”. So the consequences of Article 4 run through national law, and the EUR 15 million story attached to it by training vendors was never in the text.
The practical conclusion for a business: have the policy, but not because of the AI Act. The real reasons are different and older than the Act itself, namely obligations under the GDPR when handling personal data, confidentiality undertakings to clients and suppliers, and the plain accountability question of who signs a document a program drafted. What the July 2026 amendment changed, clause by clause, is set out separately in EU AI Act Article 4 and the AI literacy rule. This is general information, not legal advice.
What the European Commission said directly
The Commission’s document states that “There is no one size fit all when it comes to AI literacy and no strict requirements or mandatory trainings are imposed,” and that “There is no need for a certificate. Organisations can keep an internal record of trainings and/or other guiding initiatives.” Asked whether an organisation shall set up an AI governance board, it answers: “No, no specific governance structure is mandated to comply with article 4 of the AI Act.” A supplier asserting that the Regulation demands a particular course, a particular certificate or precisely their policy template is relying on something the document does not say.
Sequence
How we draft the policy with your team
We write the policy during the training rather than before it. The reason is simple: rules written in an office describe imaginary work, while rules written on the same day the team tried the tools on its own documents describe the real thing. The second reason matters more: when staff propose a boundary themselves, they treat it as theirs.
We write down what is already in use
The first step is an inventory rather than a prohibition. We ask which tools the team already uses, on which accounts, and for what work. That conversation happens without consequences, because otherwise the answers are incomplete and the policy ends up describing work that is not being done.
We sort data into a few classes
Together with the team we pick four or five classes of data that an employee can recognise without a lawyer. The class names come from your everyday vocabulary rather than from legislation, because the table has to be usable in seconds.
We assign tools to classes
For each class we state where it may be processed: a public personal account, a company account under contract, or only an internal system. Where the answer depends on a client contract, that is written down explicitly rather than left implied.
We set the checking levels
We agree what is always checked, what needs a second person, and where a signature is required. Levels are tied to the cost of an error, so the team does not have to memorise a list of document types.
We name the owner and the review date
A specific name with a job title, the incident reporting route, and the next review date go into the document. Without those three lines the policy works until the first unclear case.
We test it against real cases
The last part of the session is a test: we take five real cases from your work and see whether the policy gives an unambiguous answer. Wherever two employees answer differently, the wording is fixed on the spot.
The result is a document that can go out to the team the same week, and an agreement about when it is next reviewed. In sectors where the rules are tighter, sector annexes are attached: the questions that matter to accounting teams are on AI for accounting firms, and the ones that matter to legal teams on AI for law firms. Scope and price are agreed per engagement.
FAQ
Frequently asked questions.
Founder & CEO, AInora
Building AI digital administrators that replace front-desk overhead for service businesses across Europe. Previously built voice AI systems for dental clinics, hotels, and restaurants.
View all articlesRules the team actually reads.
An hour on a call to look at which tools are already in use in your company, which data classes are relevant, and what has to be written down first. No obligation.