AI Use Policy Template for EU AI Act Compliance
EU AI Act AI use policy template: 12 sections covering Art 5 prohibitions, Art 6 risk classification, Art 14 oversight, and Art 73 incident timelines.
Every organisation using AI tools needs a written AI use policy before regulators come knocking — and most don't have one. Not because the law explicitly demands a document with that title, but because the obligations in Regulation (EU) 2024/1689 (the EU AI Act) only work if your people know what they can deploy, what they must not touch, and who is accountable when something goes wrong.
This page gives you a structured, copy-adaptable policy outline. It is not a statutory deliverable by itself. Think of it as the governance instrument that supports your Article 17 quality management system (QMS) and demonstrates Article 4 AI literacy across your organisation. A good internal policy ties those obligations together in one place staff can actually use.
Before you draft, one distinction matters: this page covers the internal AI use policy — the document your employees follow. The separate process of managing, updating, and enforcing that policy over time is covered in our AI policy management guide.
What a compliant AI use policy must accomplish
An AI use policy has two jobs. First, it keeps your organisation within the Act's rules — particularly the Article 5 prohibitions (in force since 2 February 2025) and the data-handling and oversight obligations that apply when you deploy high-risk systems. Second, it creates a paper trail: evidence that your organisation exercises meaningful governance over AI, which supports both the Article 17 QMS (for providers) and the Article 26 deployer obligations.
The policy is not the conformity assessment, the risk management system, or the technical documentation. Those are separate artefacts required under Articles 9, 11, and 43. The policy tells your people how to behave; the technical file tells the regulator how the system works.
Policy template: section-by-section outline
The 12 sections below map directly to the Act's obligations. Use this as a drafting skeleton — adapt the language, scope, and examples to your organisation.
1. Purpose and scope
State that this policy governs the use, procurement, development, and deployment of AI systems within the organisation. Name the legal basis — Regulation (EU) 2024/1689 — and confirm it applies to all employees, contractors, and third parties acting on the organisation's behalf. Don't limit scope to "high-risk AI": the Article 5 prohibitions apply to all AI systems, and Article 4 literacy obligations apply organisation-wide.
2. Definitions
Define "AI system" (Article 3(1)) and the four risk tiers: unacceptable risk (prohibited, Article 5), high risk (Article 6 + Annex III), limited risk (Article 50 disclosure obligations), and minimal risk (no mandatory obligations). Define the organisation's role(s): provider (Article 16), deployer (Article 26), importer (Article 23), distributor (Article 24). Roles can shift under Article 25 if the organisation substantially modifies a system or repurposes it. Most companies are deployers of third-party tools; a company shipping AI features under its own name is a provider.
3. Roles and responsibilities
Assign named accountability. At minimum: an AI/Compliance Lead who owns the policy and the Article 17 QMS; a DPO (if appointed) covering GDPR/AI Act overlap and DPIA/FRIA triggers; System Owners accountable for each system in the inventory (Article 9 risk management for providers, Article 26 monitoring for deployers); IT/Procurement screening new tools before any licence; and all staff completing Article 4 AI literacy training and reporting anomalies. Without named owners, the policy is not enforceable.
4. Approved and prohibited AI uses
This is the most operationally critical section of any internal policy.
4a. Approved uses
Maintain a live list of AI tools and systems that have passed the intake process in Section 6. For each tool, specify: the approved use case, the risk tier, the relevant deployer or provider obligations, and any use restrictions (e.g., "may not be used for performance appraisal without a human reviewer in the loop").
4b. Prohibited uses — Article 5 categories (in force since 2 February 2025)
The Act bans eight categories of AI outright. Your policy must make these explicit and non-negotiable:
- Social scoring — AI that evaluates or classifies natural persons based on social behaviour or personal characteristics in ways that lead to detrimental treatment unrelated to the context in which the data was generated (Article 5(1)(c)).
- Subliminal or manipulative techniques — AI that exploits subconscious vulnerabilities or psychological weaknesses to distort behaviour, causing harm (Article 5(1)(a) and (b)).
- Real-time remote biometric identification in public — using live facial recognition or similar biometrics in publicly accessible spaces for law enforcement purposes, outside the narrow exceptions (Article 5(1)(h)).
- Untargeted facial scraping — building or expanding facial recognition databases by scraping faces from the internet or CCTV (Article 5(1)(e)).
- Sensitive biometric categorisation — inferring race, political opinion, trade union membership, religious belief, or sexual orientation from biometric data (Article 5(1)(g)).
- Emotion recognition in workplaces and educational settings — any AI that infers employees' or students' emotional states (Article 5(1)(f)).
- Predicting offending solely from profiling — AI that assesses a person's risk of committing a crime based solely on profiling, without grounding in objective, verifiable facts (Article 5(1)(d)).
- Cognitive behavioural manipulation of vulnerable persons — AI that exploits age, disability, or social vulnerability to bypass rational decision-making (Article 5(1)(b)).
Breach of Article 5 carries the Act's highest penalty: up to €35,000,000 or 7% of total worldwide annual turnover, whichever is higher (Article 99(3)); for SMEs/start-ups, capped at the lower figure (Article 99(6)). The policy must state clearly: any employee who discovers a tool may engage in a prohibited practice escalates immediately, and deployment does not continue pending investigation.
5. Risk classification trigger — Article 6 and Annex III
Explain how the organisation determines whether a new or existing AI system is high-risk. The classification test has two steps:
Step 1 — Annex I product safety component (Article 6(1)): Is the system a safety component of a product that itself requires third-party conformity assessment under EU product law (e.g., machinery directive, medical devices regulation)? If yes: high-risk, with the 2 August 2028 deadline.
Step 2 — Annex III stand-alone system (Article 6(2)): Does the system fall into one of the eight Annex III categories — biometrics; critical infrastructure; education; employment and worker management; access to essential services (including creditworthiness scoring, health/life insurance risk and pricing); law enforcement; migration and border control; administration of justice? If yes: provisionally high-risk.
Article 6(3) filter: A system in an Annex III area is not high-risk if it poses no significant risk of harm to health, safety, or fundamental rights — for example, if it performs a narrow procedural task, improves a previously completed human activity, detects decision patterns without influencing human assessment, or does only preparatory work. Any system that profiles natural persons is always high-risk, regardless of the filter. Providers claiming the exemption must document their assessment and register the system.
The deadline for stand-alone high-risk Annex III systems: 2 December 2027 (under the Digital Omnibus political agreement of May 2026, which deferred the original 2 August 2026 date). That is not a reason to delay governance work. Documentation alone takes months.
6. Approval and intake process for new AI tools — shadow-AI control
No AI tool may be deployed professionally without completing this intake process. Shadow AI — tools adopted without approval — creates direct legal exposure: under Article 26, deployers bear monitoring and incident-reporting obligations regardless of whether the deployment was sanctioned.
The intake covers six steps: (1) system registration in the AI inventory (name, vendor, use case, data types); (2) risk classification under Article 6/Annex III; (3) vendor due diligence for high-risk systems — verify Article 43 conformity assessment, Article 47 Declaration of Conformity, and Article 49 EU database registration; (4) GDPR check — confirm whether a DPIA (GDPR Article 35) is required; (5) human oversight assessment under Article 14; (6) approval sign-off by the Compliance Lead. Match review depth to the risk tier.
7. Data handling and GDPR
The AI Act and GDPR are separate frameworks; compliance with one does not satisfy the other. Address four intersections: (1) personal data in AI inputs — confirm the vendor is a data processor under a valid DPA; (2) DPIA trigger — high-risk systems processing personal data typically satisfy the GDPR Article 35 threshold; run the DPIA before deployment; (3) solely automated decisions — GDPR Article 22 may apply; establish a human review route; (4) FRIA vs DPIA — the Article 27 Fundamental Rights Impact Assessment is distinct from a DPIA and applies to public bodies and to deployers of creditworthiness (Annex III point 5(b)) or life/health insurance systems (point 5(c)); Article 27(4) allows the FRIA to build on an existing DPIA.
8. Human oversight — Article 14
For every high-risk AI system, Article 14 requires measures enabling humans to understand outputs, assess reliability, intervene or suspend the system, and identify at-risk persons or groups. For each high-risk system in the inventory, name the person responsible and document the decision point for overriding the system's output. "Human in the loop" is not a control without a named human, a defined decision point, and a recorded override procedure.
9. Transparency and disclosure — Article 50
Article 50 imposes transparency obligations on AI systems interacting directly with natural persons, applying from 2 August 2026. Four categories:
- Chatbots and conversational AI — users must be informed that they are interacting with an AI system, unless it is obvious from context (Article 50(1)).
- Emotion-recognition systems — persons subject to emotion recognition must be informed (Article 50(2)). Note: this disclosure requirement applies only to lawful emotion-recognition uses outside workplaces and educational settings — workplace and educational use is entirely prohibited under Article 5(1)(f).
- Deepfakes and synthetic media — AI-generated or manipulated images, audio, or video must be labelled as such (Article 50(3)).
- AI-generated text on matters of public interest — text generated by AI for public information on elections, public health, and similar topics must be labelled (Article 50(4)).
Specify which customer-facing or public-facing systems trigger these obligations, and how disclosures are delivered and logged.
10. AI literacy and training — Article 4
Article 4 requires providers and deployers to ensure staff have sufficient AI literacy for their role — in force since 2 February 2025. Calibrate training by function: general staff need awareness of Article 5 prohibitions and the policy's reporting procedures; System Owners and compliance staff need the classification framework (Articles 5, 6, Annex III) and incident timelines (Article 73); developers need the provider obligation stack (Articles 9–15, 16–17). Specify training frequency, how completion is logged, and how training stays current as the portfolio changes.
11. Logging and incident reporting — Article 73
Three obligations converge here.
Deployer logs (Article 26): Retain logs of high-risk system operation for at least six months. Specify where logs are stored, who has access, and the retention schedule.
Provider logs (Article 12): Providers must ensure high-risk systems automatically generate operation logs throughout their lifetime. Technical documentation retention runs ten years (Article 18).
Serious incident reporting (Article 73): Providers report serious incidents to the market-surveillance authority of the member state where the incident occurred. Timelines: 15 days from awareness (Article 73(2)); 2 days for widespread or irreversible critical-infrastructure disruption (Article 73(3)); 10 days where a person has died (Article 73(4)). An incomplete initial report is permitted and must be completed as information arrives (Article 73(5)). Deployers monitor and report to the provider under Article 26; the provider escalates to authorities. The policy must name who triages incidents and how the Article 73 notification is drafted.
12. Review cadence
Three triggers: (1) annual — check whether the policy reflects the current AI portfolio and regulatory updates; (2) triggered — adoption of a new high-risk system, a serious incident under Article 73, a change in law, or a substantial modification (Article 3(23)) that converts a deployer role into a provider role; (3) post-incident — review relevant sections within 30 days of resolution. Record policy version, review date, and approver on the document and in the AI inventory log.
What this policy does — and does not — do
An AI use policy is not a statutory deliverable by name. The Act does not require you to submit a document with this title. What it does is support real obligations: it evidences the Article 17 QMS; it operationalises Article 4 AI literacy in one place staff can use; it makes Article 26 deployer monitoring workable; and it controls shadow AI — the most common source of unintentional non-compliance.
The conformity assessment (Article 43), risk management system (Article 9), and technical documentation (Article 11) are separate system-level artefacts the policy points to but does not replace.
How Confir helps
When your AI inventory grows past a handful of tools, manually cross-referencing the policy against the register becomes the constraint. Confir supplies the two artefacts the policy depends on: the AI inventory (every system registered, classified by Articles 5 and 6, role derived from plain-English intake) and the structured assessment (Article 9 risk management system, Article 26 deployer checks, Article 27 FRIA — all driven by deterministic, rule-based logic that is reproducible and audit-defensible). From €600 per year, no consultants required.
Frequently Asked Questions
Does the EU AI Act require organisations to have a written AI use policy?
Not by that name. The Act does not mandate a document with this title. But Article 4 (AI literacy, in force since 2 February 2025) requires staff to have sufficient AI knowledge for their roles, and Article 17 requires providers to document QMS processes. A written internal policy is the most direct way to demonstrate both. Regulators investigating an incident will ask what governance was in place.
What is shadow AI and why does the Act make it risky?
Shadow AI is any tool staff use professionally without a formal approval process — a free chatbot, a browser plug-in, a productivity add-on. Under Article 26, deployers bear monitoring obligations for every high-risk AI system they use, regardless of whether the deployment was internally sanctioned. A shadow tool that turns out to be high-risk means the organisation is already non-compliant.
How does the AI use policy interact with our GDPR documentation?
Cross-reference your GDPR processing register in the policy. High-risk AI systems processing personal data typically require a GDPR DPIA (GDPR Article 35) before deployment. Public bodies and deployers of creditworthiness (Annex III point 5(b)) or life/health insurance systems (point 5(c)) must also run an Article 27 FRIA; Article 27(4) allows the FRIA to build on an existing DPIA.
When do the high-risk AI obligations actually apply?
Under the Digital Omnibus agreed in May 2026, the original 2 August 2026 high-risk deadline was deferred. Stand-alone Annex III systems: 2 December 2027. High-risk AI in regulated products (Annex I): 2 August 2028. Article 5 prohibitions have applied since 2 February 2025; Article 50 limited-risk transparency applies from 2 August 2026. Neither was deferred.
What are the penalties for getting this wrong?
Three tiers under Article 99. Article 5 violations: €35M or 7% (Art 99(3)). Provider/deployer obligation breaches: €15M or 3% (Art 99(4)). Incorrect information to authorities: €7.5M or 1% (Art 99(5)). SMEs and start-ups are capped at the lower of the percentage or the fixed amount (Art 99(6)).
Do minimal-risk AI tools need to be in the policy at all?
Yes. Article 4 AI literacy applies to all tools, not only high-risk ones. Risk tier depends on use, not name: a chatbot is minimal-risk for drafting and limited-risk when customer-facing under Article 50 — but becomes high-risk if used to inform creditworthiness decisions (Annex III point 5(b)). The intake process prevents that classification drift.
Does an internal AI policy satisfy the Article 17 QMS requirement for providers?
No — but it is a meaningful component. Article 17 requires a QMS covering design, testing, monitoring, conformity assessment, incident response, and documentation control. The policy provides the governance layer. The QMS also requires system-level artefacts — the Article 9 risk management record, Article 11 technical documentation, Article 12 logging — that the policy points to but cannot substitute for.
Related guides
- AI policy management tools
- CISO governance oversight guide
- open-source model exemptions
- responsible AI governance framework
- Article 26 deployer requirements
- Article 26 compliance details
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →