AI Use Policy Template: A Compact Starting Point for EU AI Act Compliance
A fill-in AI use policy template covering Article 5 prohibitions, shadow-AI control, Article 14 oversight, Article 50 disclosure, and Article 4 literacy.
An AI policy is not a statutory deliverable under the EU AI Act — the Regulation does not hand you a template to sign and file. What it does is impose obligations that, taken together, only make sense if someone has written down the rules: who may use which tools, what is banned outright, who signs off on new systems, and who is responsible when something goes wrong. This template gives you the twelve sections that cover that ground. A competent legal reviewer should adapt it to your jurisdiction before it goes live.
For a full compliance programme — the 12-section, obligation-mapped version covering high-risk documentation, technical files, and the complete provider/deployer obligation stacks — see the detailed AI compliance policy template. For the software and workflow that keeps a live policy current, see the AI policy management guide. This page is the leaner artefact: a fill-in template an SME can adopt in an afternoon and refine over time.
The Template
1. Purpose and Scope
Purpose. This policy governs how [Organisation Name] develops, procures, deploys, and uses artificial intelligence systems. It exists to ensure compliance with Regulation (EU) 2024/1689 (the EU AI Act), to fulfil the AI literacy obligation under Article 4, to support the quality management system where Article 17 applies, and to protect staff, customers, and third parties from AI-related harms.
Scope. This policy applies to all employees, contractors, and third parties acting on behalf of [Organisation Name] who develop, procure, integrate, or use any AI system in a professional capacity. It covers AI systems provided by third parties and any systems developed internally.
AI system defined. For the purposes of this policy, "AI system" has the meaning in Article 3(1) of the EU AI Act: a machine-based system designed to operate with varying levels of autonomy that, for explicit or implicit objectives, infers from inputs how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.
2. Who This Policy Covers
This policy binds everyone who uses, builds, procures, or manages AI systems under [Organisation Name]'s authority. That includes:
- All employees and secondees
- Contractors, consultants, and freelancers working on [Organisation Name] projects
- Third-party partners with access to [Organisation Name] systems or data where AI is involved
Individuals who become aware of AI use that is not covered by this policy must escalate to the AI Governance Owner (Section 12) rather than proceed independently.
3. Approved and Prohibited Uses
Approved uses. Only AI systems listed on the Approved Systems Register (maintained by [Role/Function]) may be used for professional purposes. Use of any AI tool not on the register — often called shadow AI — is not permitted until a formal review and approval has been completed. Teams who identify a new tool they wish to use should submit an intake request to the AI Governance Owner before deployment.
Prohibited uses — Article 5. The following practices are prohibited within [Organisation Name] and have been banned under EU AI Act Article 5 since 2 February 2025. Breach of any prohibition is a disciplinary matter and, for the organisation, carries a maximum penalty of €35,000,000 or 7% of total worldwide annual turnover (whichever is higher) under Article 99.
- AI techniques that manipulate behaviour through subliminal means or exploit the vulnerabilities of specific groups (Article 5(1)(a)–(b))
- Biometric categorisation systems that infer sensitive characteristics (race, political opinions, religious beliefs, sexual orientation) for purposes that are not permitted under applicable law (Article 5(1)(g))
- Social scoring of individuals by public authorities (Article 5(1)(c))
- Predictive policing based solely on profiling without objective factual grounds (Article 5(1)(d))
- Untargeted scraping of facial images from the internet or CCTV for facial recognition databases (Article 5(1)(e))
- Emotion recognition in the workplace or in educational settings (Article 5(1)(f)) — safety-related exceptions apply only where the law explicitly permits them
- Real-time remote biometric identification in publicly accessible spaces for law enforcement except in the narrow legally authorised circumstances (Article 5(1)(h))
If there is any doubt as to whether a planned use might fall within these categories, the AI Governance Owner must be consulted before proceeding.
4. Intake and Approval for New AI Tools (Shadow-AI Control)
Before any new AI system is used for professional purposes, a brief intake form must be completed and reviewed. The intake captures: system name and vendor, intended use, data categories it will process, and whether the use could place the system in an Annex III category (see Section 5).
The AI Governance Owner reviews the intake within [X] working days and returns one of three outcomes: approved (added to the Approved Systems Register), approved pending conditions (e.g. data restrictions, training requirements), or rejected with written reasons.
This process applies to trial use and pilots, not only production deployments. An employee downloading a new AI productivity tool for an unmonitored pilot is not exempt.
5. Risk Classification — Article 6 and Annex III Trigger
Any AI system that may fall within the eight Annex III categories must be escalated for a formal classification assessment before use. The Annex III categories are:
- Biometrics
- Critical infrastructure safety components
- Education and vocational training
- Employment, worker management, and access to self-employment
- Access to essential private and public services (including creditworthiness and life/health insurance pricing)
- Law enforcement
- Migration, asylum, and border control
- Administration of justice and democratic processes
If a system falls within one of these areas, Article 6 determines whether it is high-risk. The Article 6(3) filter may exclude systems that perform only narrow procedural tasks or that do not pose a significant risk of harm to health, safety, or fundamental rights — but that assessment must be documented, not assumed.
High-risk classification triggers the full obligation stack under Articles 9–15, 26, and 43 (and, for providers, Articles 16–17). Classification outcomes are recorded in the AI system's compliance file.
6. Data and GDPR Handling
AI systems that process personal data must have a lawful basis under the GDPR and a corresponding entry in the Record of Processing Activities (RoPA). The AI use does not create a separate legal basis — it must fit within an existing one (consent, contract, legitimate interest, legal obligation, etc.).
Data minimisation applies: do not input more personal data than the system needs for its specified purpose. Sensitive categories of data (Article 9 GDPR: health, biometrics, political opinions, etc.) require explicit authorisation from the Data Protection Officer before use in any AI system.
Where an AI system triggers the need for a Data Protection Impact Assessment (DPIA) under GDPR Article 35, that assessment must be completed before deployment. High-risk AI systems that also process personal data and are used by public bodies or certain deployers (Annex III 5(b)/5(c)) may also require a Fundamental Rights Impact Assessment under EU AI Act Article 27 — the FRIA can build on an existing DPIA (Article 27(4)).
7. Human Oversight — Article 14
Every high-risk AI system used by [Organisation Name] must have a named human oversight role. That person must:
- Have sufficient understanding of the system's capabilities and limitations
- Be able to monitor outputs and identify anomalies, bias, or unexpected results
- Hold authority to override, suspend, or stop the system's output from influencing any decision
- Document significant interventions
Automated decisions that produce legal or similarly significant effects on individuals require human review before the decision is communicated, unless the system has been specifically approved for automated processing under both the EU AI Act and GDPR Article 22. Any waiver of human review must be documented and approved by the AI Governance Owner.
8. Transparency and Disclosure — Article 50
Article 50 applies from 2 August 2026. From that date, [Organisation Name] must disclose to individuals when they are:
- Interacting with an AI system rather than a human (chatbots, virtual assistants) — Article 50(1)
- Subject to emotion recognition or biometric categorisation — Article 50(3)
- Receiving content that has been generated or substantially manipulated by AI (deepfakes, synthetic audio/video) — Article 50(4)
Internal AI-generated content used only within the organisation does not trigger disclosure obligations, but the distinction should be documented. Disclosure must be given at the latest at the first interaction and must be presented in a clear and accessible way (Article 50(5)).
9. AI Literacy — Article 4
Article 4 has applied since 2 February 2025. It requires providers and deployers to take measures to ensure sufficient AI literacy among their staff and, where relevant, deployers. No specific certification is mandated, but the obligation must be demonstrable.
[Organisation Name] meets this obligation through:
- Baseline AI literacy training for all staff using AI in a professional capacity (completion recorded)
- Role-specific training for staff in AI oversight roles, AI procurement, and compliance functions
- Annual refresher, triggered earlier if material regulatory changes occur
- Onboarding training for new starters before they are granted access to AI systems
Training records are maintained by [HR/Compliance function] and are available for audit.
10. Logging and Incident Escalation
Logging. High-risk AI systems must maintain records of their operation sufficient to identify inputs and outputs for accountability purposes. Deployer logs must be retained for at least 6 months (Article 26). Technical documentation for high-risk systems has a 10-year retention requirement (Article 18).
Incidents. An AI incident is any event in which an AI system produces an output — or fails to produce an expected output — that causes or risks causing harm to individuals, the organisation, or third parties. All staff are required to report suspected AI incidents to the AI Governance Owner immediately.
The AI Governance Owner assesses whether the incident is a "serious incident" under Article 3(49) of the EU AI Act. For providers, serious incidents must be reported to the relevant market surveillance authority within the timelines in Article 73 (15 days in most cases; 2 days for critical infrastructure or widespread infringement; 10 days where a death has occurred). Deployers must notify the provider and, where required, the relevant authority under Article 26.
11. Review Cadence
This policy is reviewed annually as a minimum. A triggered review is required where:
- A material regulatory change occurs (new guidance from the AI Office, Digital Omnibus amendments, or equivalent)
- The organisation's AI system portfolio changes significantly (new high-risk system, new Annex III use)
- A serious incident has occurred and a root-cause review warrants policy updates
- A market surveillance authority issues guidance relevant to the organisation's AI use
The AI Governance Owner owns the review; approval rests with [Senior Management/Board].
12. Roles
| Role | Responsibility |
|---|---|
| AI Governance Owner | Overall accountability for this policy and the Approved Systems Register; escalation point; incident triage; classification sign-off |
| Data Protection Officer | GDPR/AI Act intersection; DPIA and FRIA sign-off; RoPA maintenance |
| Business Unit AI Contacts | Day-to-day intake submissions, shadow-AI identification, and oversight arrangement maintenance within their function |
| All Staff | Compliance with this policy; escalation of incidents and potential prohibited uses; completion of required training |
Honest Framing: What a Policy Is and Is Not
A policy is good governance. It supports the Article 17 QMS (for providers), satisfies the Article 4 literacy obligation for all, and provides an audit-ready record of intent and controls. It is not a statutory deliverable in its own right — the Act does not require you to produce a document titled "AI Policy." But it is the practical backbone for almost everything the Act does require.
For deployers using third-party AI tools (the situation most companies are in), a policy is particularly valuable because deployer obligations under Article 26 — oversight, incident monitoring, log retention, instruction-following — only become enforceable internally once they are written down and communicated.
For providers of high-risk systems, a policy is the governance layer without which the Article 17 QMS has no organisational authority. It should be formally approved at senior management level and reviewed in step with the system's lifecycle.
How Confir Helps
A policy is only as good as the system inventory and classification decisions that underpin it. Two things must be right before any of the sections above carry real weight: you need to know which AI systems are in scope, and you need to know what each one's risk tier is.
Confir's rule-based intake runs structured checklists that identify every AI system your organisation builds or deploys, derives each system's risk tier under Articles 5 and 6 with Annex III logic, and records the outputs in an immutable audit log — giving the Approved Systems Register and the classification records that Sections 4 and 5 of this policy require. The same intake feeds the Article 27 FRIA and the Article 11/Annex IV technical documentation for high-risk systems.
[Start your free assessment at confir.eu →]
Frequently Asked Questions
Is an AI policy legally required under the EU AI Act? Not as a named document. But Article 4 (AI literacy), Article 17 (QMS for high-risk providers), and Article 26 (deployer governance) collectively demand governance that a policy delivers. Treating it as optional and not producing one creates a gap that is difficult to defend to an auditor or market surveillance authority.
What is the difference between this template and the detailed 12-section policy at /ai-compliance/policy-template?
The detailed version is a full obligation-mapped programme document covering the complete high-risk stack — technical documentation requirements, the conformity assessment procedure, provider obligations under Article 16, and the QMS structure under Article 17. This template is the compact governance artefact: the rules document you give to your organisation, not the compliance programme you hand to a notified body.
Can one policy cover both providers and deployers if we do both? Yes, but the policy should state explicitly which sections apply to which role. Provider and deployer obligations are distinct (Articles 16 and 26 respectively), and some organisations straddle both roles depending on the system. Article 25 explains the circumstances in which a deployer becomes a provider — substantial modification, rebadging under your own name, or repurposing a system beyond its intended use.
When does Article 4 (AI literacy) apply? Since 2 February 2025 — it is already live. It applies to all providers and deployers, regardless of whether your AI systems are high-risk. No specific format or certification is required, but you need to be able to demonstrate that relevant staff have sufficient understanding of AI to fulfil their roles responsibly.
What are the penalties for an Article 5 prohibited-use violation? €35,000,000 or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher (Article 99(3)). For SMEs and start-ups, the fine is capped at the lower of the percentage or the fixed amount (Article 99(6)). This is the highest penalty tier in the Act — and the prohibitions have been live since 2 February 2025.
How often should we update the Approved Systems Register? Whenever a new AI tool is approved for use, whenever a system is decommissioned, and at minimum as part of the annual policy review. In practice, the register needs a lightweight real-time process — quarterly snapshots miss the shadow AI that accumulates between reviews.
Related guides
- AI policy management software
- open source model exemptions
- responsible AI governance framework
- EU AI Act explained
- Article 17 quality management
- SaaS startup compliance guide
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 →