EU AI Act checklist for companies that use AI
Updated 9 November 2026. Free to copy and use. Article text from EUR-Lex and the AI Act Service Desk.
A company that uses AI systems under its own authority is a deployer under the EU AI Act (Article 3(4)). This checklist lists what the Act asks of deployers, the article each duty comes from and the evidence that shows the work is done: AI literacy since 2 February 2025, transparency from 2 August 2026, and the Article 26 and 27 duties for high-risk uses from 2 December 2027.
Download it as a Markdown file or as a CSV with empty owner, status and evidence columns, and work through it with your legal and security teams.
14 October 2026: the first harmonised standard under the AI Act, EN 18286 (quality management for providers of high-risk AI systems), was cited in the Official Journal. What it means for deployers.
Download the checklist (.md)Spreadsheet (.csv)
The CSV opens in Excel, Google Sheets or Numbers, with columns for owner, status and evidence link.
The checklist
Start with section 1, which applies to every company. Section 2 applies only to AI systems that are high-risk under Article 6 and Annex III. Section 3 depends on what you publish, and section 4 on which models you build on.
1. Every company that uses AI
Applies whatever the tool: chat assistants, AI features in other software, coding agents and models called through an API.
| No. | What to do | Article | How to evidence it |
|---|---|---|---|
| 1 | AI literacy. Take measures to support the AI literacy of staff and of others who operate or use AI systems on your behalf, matched to their knowledge, experience and training and the context of use. | ArticleArt. 4 (since 2 Feb 2025, as amended by Reg. 2026/1744) | How to evidence itTraining records per role (date, attendees, content), the AI usage policy staff have acknowledged, and guidance on risks such as hallucination. No certificate is required. |
| 2 | Inventory. List every AI system and use case: what it does, who owns it, who uses it, which models and providers serve it and what data goes in. | ArticleBasis for Art. 4, 6, 26 and 50 | How to evidence itAn AI register with owner, purpose, users, models, providers, data categories, whether output is published, and the date of the last review. A per-app or per-key export of the models and providers in use. |
| 3 | Risk classification. Check each use case against the eight Annex III areas: biometrics, critical infrastructure, education, employment and worker management, essential private and public services (including creditworthiness and life and health insurance pricing), law enforcement, migration and border control, and justice and democratic processes. Drafting, translating, summarising and coding assistance are not Annex III areas. Such a use becomes high-risk when the AI serves a listed purpose, for example filtering job applications. | ArticleArt. 6(2), 6(3), Annex III | How to evidence itA classification note per use case naming the Annex III point checked and the reasoning, any Article 6(3) derogation relied on, sign-off by legal, and a re-check whenever the purpose changes. Profiling of natural persons in an Annex III area is always high-risk. |
| 4 | Role check. Confirm you are still a deployer. You take on provider obligations if you put your name or trademark on a high-risk system, substantially modify one, or change the purpose of an AI system so that it becomes high-risk. | ArticleArt. 25(1) | How to evidence itA note in the register per system: own brand or not, modifications made, intended purpose compared with the provider's. |
2. Only if you deploy a high-risk AI system
Annex III uses, from 2 December 2027 (Article 113 as amended by the Digital Omnibus on AI).
| No. | What to do | Article | How to evidence it |
|---|---|---|---|
| 5 | Use per instructions. Take technical and organisational measures to use the system in accordance with the provider's instructions for use. | ArticleArt. 26(1) | How to evidence itThe instructions for use on file with their version, and an internal procedure that maps each instruction to a control. |
| 6 | Human oversight. Assign oversight to people with the necessary competence, training and authority, and give them the support they need. | ArticleArt. 26(2) | How to evidence itNamed overseers per system, their training records, their authority to stop or override the system, and the escalation path. |
| 7 | Input data. Where you control the input data, make sure it is relevant and sufficiently representative for the intended purpose. | ArticleArt. 26(4) | How to evidence itA description of the input data sources and a dated review of relevance and representativeness. |
| 8 | Monitoring. Monitor the system on the basis of the instructions for use. If it may present a risk, inform the provider or distributor and the market surveillance authority and suspend use. Report serious incidents. | ArticleArt. 26(5) | How to evidence itA monitoring log, an incident procedure with the provider's and authority's contacts, and records of any notification or suspension. |
| 9 | Log keeping. Keep the logs the high-risk system automatically generates, to the extent they are under your control, for a period appropriate to its intended purpose and of at least six months, unless Union or national law, in particular data protection law, provides otherwise. | ArticleArt. 26(6) | How to evidence itThe retention setting and storage location of the system's logs, the deletion schedule, and a sample export showing six months or more. |
| 10 | Inform workers. Before putting a high-risk system into service or using it at the workplace, employers inform workers' representatives and the affected workers. | ArticleArt. 26(7) | How to evidence itThe dated notice to staff and the minutes or letter to the works council or other workers' representatives. |
| 11 | Inform affected people. When an Annex III system makes or assists decisions about natural persons, tell them they are subject to its use. | ArticleArt. 26(11) | How to evidence itThe notice text and where and when it is shown to the people concerned. |
| 12 | Fundamental rights impact assessment (FRIA), where required: bodies governed by public law, private entities providing public services, and deployers of creditworthiness or life and health insurance pricing systems (Annex III 5(b) and (c)) assess the impact before first use and notify the market surveillance authority of the results. Critical infrastructure (Annex III point 2) is excepted. | ArticleArt. 27, Art. 26(9) | How to evidence itThe completed FRIA (processes, period and frequency of use, affected groups, risks, oversight, measures and complaint mechanisms), the notification sent, and cross-references to your GDPR Article 35 DPIA. |
3. Transparency
Article 50 applies from 2 August 2026.
| No. | What to do | Article | How to evidence it |
|---|---|---|---|
| 13 | Provider marking. Providers of AI systems that generate synthetic audio, image, video or text must mark the output in a machine-readable format as artificially generated or manipulated. This is the provider's duty. For systems placed on the market before 2 August 2026 it applies from 2 December 2026. | ArticleArt. 50(2), Art. 111(4) | How to evidence itFor each generative tool in the register, the provider's statement or documentation on how its output is marked, with the date you checked it. |
| 14 | Deep fakes and public-interest text. Disclose that deep fake image, audio or video content has been artificially generated or manipulated. Disclose AI-generated or manipulated text published to inform the public on matters of public interest, unless it has had human review or editorial control and a person holds editorial responsibility. | ArticleArt. 50(4) | How to evidence itA labelling rule in the publishing workflow, examples of labelled content, and the name of the person holding editorial responsibility for reviewed text. |
| 15 | Emotion recognition and biometric categorisation. Inform the people exposed to such a system. | ArticleArt. 50(3) | How to evidence itThe notice text and where it is shown, or a note in the register that no such system is used. |
4. Documents to request from model providers
General-purpose AI model obligations sit with the providers and have applied since 2 August 2025.
| No. | What to do | Article | How to evidence it |
|---|---|---|---|
| 16 | GPAI documentation. If you build a general-purpose AI model into your own AI system, request the information and documentation its provider must make available to downstream providers, plus the public summary of training content and the copyright policy. Open-source models are exempt from the documentation duty unless they carry systemic risk. | ArticleArt. 53(1)(b), (c), (d), Annex XII | How to evidence itA folder per model with the provider documentation, training content summary link, copyright policy, data processing terms and the date retrieved, linked from the register. |
How a gateway helps with the evidence
Several rows above need the same thing: a current record of which models and providers each application uses, and a history of who changed the rules. When every AI request goes through one gateway, that record builds itself.
Standard Compute puts Claude, GPT, Gemini and open models behind one company account, with a key for every person and every app. Every admin change is recorded with before and after values, and you can export a record of every request showing the model, the provider that served it and the region rule in force, kept for 12 months. Request records hold metadata only (model, provider, tokens, cost and status), never your prompts or outputs.
| Checklist row | What Standard Compute records or enforces |
|---|---|
| 2. Inventory | A key per person and per app, the models each key may use, and the model and serving provider of every request. |
| 3 and 4. Classification and role | Model allow-lists per key, so a use case runs only on the models you approved for it. |
| 9. Log keeping | A request log with model, provider and region rule for every call, kept for 12 months and exportable. |
| 1 and 16. Policy and provider choice | Provider allow-lists for the company, a team or a key. New providers are never added without an admin's approval, and fallbacks can never route around your list. |
| Policy history | An admin audit log with before and after values for every change to people, keys and rules. |
| Data protection work | A Europe rule: every request, including retries and fallbacks, is served only by approved European inference endpoints. Zero data retention: requests go only to endpoints that commit to keeping no copy of your data. |
These are gateway records of model and provider use. The logs Article 26(6) refers to are the ones a high-risk system generates itself. Your legal team decides what the Act requires of your company. This checklist is not legal advice.
Questions
- Is using ChatGPT, Claude or a coding agent for office work high-risk under the EU AI Act?
- High-risk systems are those in Article 6(1) and the use cases listed in Annex III, such as recruitment, worker management, creditworthiness, education and access to essential services. Drafting, translating, summarising and coding assistance are not on that list. The same tool becomes high-risk when it is used for a listed purpose, for example to filter job applications or evaluate employees.
- How long must a deployer keep AI logs?
- For high-risk systems, Article 26(6) asks deployers to keep the logs the system automatically generates, to the extent they are under their control, for a period appropriate to its intended purpose and of at least six months, unless Union or national law, in particular data protection law, provides otherwise.
- Who has to do a fundamental rights impact assessment?
- Under Article 27, bodies governed by public law, private entities providing public services, and deployers of Annex III systems for creditworthiness or life and health insurance risk and pricing. They do it before first use and notify the market surveillance authority of the results. It can cross-reference the GDPR data protection impact assessment.
- When do the Article 50 transparency rules apply?
- From 2 August 2026. Deployers disclose deep fakes and AI-generated text published on matters of public interest (Article 50(4)). Providers mark synthetic output in a machine-readable format (Article 50(2)), and for systems placed on the market before 2 August 2026, Article 111(4) gives them until 2 December 2026.
- What does an AI gateway add to this checklist?
- One record of which models and providers every application uses, and one place to enforce the approved list. Standard Compute exports a request log with model, provider and region rule, kept for 12 months, logs every admin change with before and after values, and enforces model and provider allow-lists.
Sources
- Regulation (EU) 2024/1689, the AI Act, EUR-Lex
- Regulation (EU) 2026/1744, the Digital Omnibus on AI, EUR-Lex
- AI Act Service Desk, consolidated text: Article 4, Article 6, Article 25, Article 26, Article 27, Article 50, Article 53, Article 111, Article 113, Annex III
Related
Run every AI request through one company account, and keep the inventory and the records in one place.