An EU AI Act compliance checklist for a company that ships AI features is mostly engineering work, not legal drafting. Classify every use case. Rule out the prohibited practices. Build the Article 50 transparency duties into the product, because they have applied since 2 August 2026. Support AI literacy among staff. Log inputs, outputs and versions, give a named person a real override, and write the documentation while you build. Get the right terms from your model provider. Then check which use cases are high risk, since those carry a much heavier set of duties from 2 December 2027.
Dates follow the Act as amended by the Digital Omnibus on AI, in force since 27 July 2026. If your notes say high-risk duties start in August 2026, they are out of date. We are engineers, not lawyers. This is the list we work through on client systems, and counsel should confirm any borderline call.
The checklist at a glance
One row per obligation, with what it means in code and process.
| Obligation | Applies when | From | What to build |
|---|---|---|---|
| Classify each use case | Every AI feature you build or deploy | Now. It decides every other row | A register: purpose, who is affected, risk class, your role, reasoning, sign-off |
| Prohibited practices (Art. 5) | Every use case | 2 February 2025. Two new bans from 2 December 2026 | A written check per use case. Abuse filters for image or video generation |
| AI literacy (Art. 4) | You provide or deploy any AI system | 2 February 2025, softened by the Omnibus | Role-based training for staff, with a record |
| Disclose AI interaction (Art. 50(1)) | The system talks directly to people | 2 August 2026 | A notice in the interface at first interaction, not in the terms |
| Mark generated content (Art. 50(2)) | You provide a system that generates audio, images, video or text | 2 August 2026. 2 December 2026 for systems already on the market | Machine-readable marking: metadata or watermarks |
| Other labels (Art. 50(3) and (4)) | You deploy emotion recognition or deepfakes, or publish unreviewed AI text on public interest matters | 2 August 2026 | A visible label or notice to the people exposed |
| Logging and version pinning | Legal duty for high risk. Evidence for everything else | Now as evidence. 2 December 2027 as a duty for Annex III | Logs of input, output, model and prompt version, human action |
| Human oversight (Art. 14) | Legal duty for high risk. Good practice elsewhere | 2 December 2027 for Annex III | A named owner, an override in the product, a record of its use |
| Technical documentation | Annex IV for high risk. A short record for everything else | 2 December 2027 (Annex III), 2 August 2028 (Annex I) | Purpose, architecture, data, evals, known limits, failure behavior |
| Terms with your model provider | You build on a third-party general-purpose model | Provider duties since 2 August 2025 | Downstream documentation, EU processing, version pinning, change notice |
| High-risk regime | Annex III use case, or safety component of an Annex I product | 2 December 2027 (Annex III), 2 August 2028 (Annex I) | Risk management, data governance, quality management, conformity assessment |
Classify every use case, not every model
The Act regulates what a system is used for. It does not care which model you picked or where it runs. The same model is minimal risk behind your document search, limited risk behind your support widget and high risk behind a CV screening step. Classifying the model tells you nothing. Classifying the use case tells you almost everything.
Keep a register with one row per AI feature. Record the intended purpose, who uses it, who is affected by its output, and whether that output feeds a decision about a specific person. Note the Annex III area if one applies. Note your role too. If you built the feature into your product, you are the provider of that AI system, even when the model belongs to someone else.
Article 6(3) gives a way out for some Annex III uses. A system escapes if it only does a narrow procedural task, improves work a human already finished, spots patterns without replacing human review, or prepares an assessment. The hard exception is profiling. A system that profiles people in an Annex III area is always high risk. If you rely on 6(3), document that assessment before the system ships.
In the projects we see, most features land in minimal or limited risk. Internal copilots, document search and support assistants rarely come close to Annex III. The mistakes go both ways. Some teams treat a harmless knowledge bot as high risk and stall for months. Others add a candidate fit score to an HR tool and never notice the class changed.
Rule out the prohibited practices
Article 5 has applied since 2 February 2025, and its fines are the heaviest in the Act: up to €35 million or 7% of worldwide annual turnover. Most B2B software is nowhere near it. Check anyway, in writing, per use case. It takes ten minutes and closes the question.
Two items catch ordinary companies. The first is inferring emotions at work or in education, banned unless it serves medical or safety reasons. A tool that reads stress from employees' voices on sales calls is inside it. The Commission's guidelines limit the ban to biometric data, so sentiment scoring on typed text is outside it. The second is design that exploits a vulnerability, such as age or financial distress, to push someone into a harmful decision.
The Omnibus adds two bans from 2 December 2026: systems that generate non-consensual intimate imagery of identifiable people, and systems that generate child sexual abuse material. If your product generates images or video from user prompts, you need input and output filters, abuse reporting and a takedown path before that date.
Article 50 transparency is already in force
The Omnibus postponed the high-risk rules. It did not postpone transparency. Article 50 has applied since 2 August 2026, so if you ship a chatbot, a voice agent or a content generator in the EU, this part is live now.
- Tell people they are interacting with an AI system, at the latest at the first interaction. The exception for the obvious case is narrow. A widget with a human name and a stock photo is not obvious.
- Put the disclosure in the interface: the chat header, the first message, the first sentence of a voice call. A clause in the terms of service does not do it.
- If an agent emails or messages customers on its own, treat that as direct interaction and disclose it in the message.
- Mark generated audio, images, video and text in a machine-readable way. Systems already on the market before 2 August 2026 have until 2 December 2026. Purely assistive editing is exempt.
- Label deepfakes. Label AI-written text published to inform the public on matters of public interest, unless a human reviewed it and someone holds editorial responsibility.
Images and audio have workable options, such as C2PA content credentials and audio watermarks. Plain text is the hard case, with no mature, tamper-resistant watermark. Mark what you can, such as provenance fields in API responses, and write down what you did and why.
AI literacy, logging, oversight and documentation
Article 4 has applied since 2 February 2025. After the Omnibus, providers and deployers must support AI literacy among their staff rather than guarantee a specific level. In practice: a short session per role, written guidance on what the system cannot do, and a record of who took part. No certification program needed.
Logging is a legal duty only for high-risk systems. Providers must build automatic logging in, and deployers must keep the logs for at least six months. We log on every system anyway. Logs are the only evidence that the disclosure appeared, that a human reviewed the output, and what the system said on a given day.
What we log: timestamp, a pseudonymized user or session id, the input, the ids of retrieved documents, the output, model id and version, prompt version, tool calls, and what the human did next. Logs contain personal data, so GDPR applies to them. Mask what you do not need, set a retention period and write down why you chose it. Pin model versions as well. An alias that silently moves to a new model makes last March impossible to explain.
Human oversight under Article 14 is also a high-risk duty, and good practice anywhere the output affects people. It needs three things: a named person, an override that exists in the product, and the authority to use it. Auditors ask whether the override was ever used. If nobody overruled the system in a year, either it is perfect or nobody is looking.
Documentation follows the same logic. Annex IV applies to high-risk systems, but every feature deserves a two page record: purpose, users, risk class and reasoning, model and provider, data sources, eval results with dates, known limitations and failure behavior. An eval suite running in CI with retained results is the best evidence you can have. It is also how you ship working software, so here compliance and engineering are the same work.
Get the right terms from your model provider
Providers of general-purpose AI models have carried their own obligations since 2 August 2025. Article 53 requires them to keep technical documentation and to give downstream providers enough information to understand the model's capabilities and limits. If you build on their API, the downstream provider is you. Ask for that information, and put the rest in the contract.
- The downstream documentation: capabilities, limitations, intended uses and the acceptable use policy.
- EU processing: a data processing agreement, a sub-processor list and a region you can pin.
- No training on your inputs and outputs, in writing.
- Version pinning, and a deprecation notice long enough to rerun your evals before a forced migration.
- Notice when the model behind an alias changes.
- Whether they have signed the General-Purpose AI Code of Practice.
None of this moves your obligations onto the vendor. It gives you what you need to meet them.
What changes if a use case is high risk
Annex III covers biometrics, critical infrastructure, education, employment, access to essential services such as credit and insurance, law enforcement, migration and justice. High-risk duties for these apply from 2 December 2027. Safety components of products under Annex I harmonization law, such as medical devices and machinery, follow on 2 August 2028. As provider, you take on most of the work:
- A risk management system for the life of the product (Article 9).
- Data governance for training, validation and test data (Article 10).
- Annex IV documentation and instructions for deployers (Articles 11 and 13).
- Logging, human oversight, accuracy and cybersecurity designed in (Articles 12 to 15).
- Quality management, conformity assessment, CE marking, EU database registration, post-market monitoring and incident reporting.
As deployer, you use the system according to its instructions and assign competent people to oversee it. You keep its logs for at least six months, inform workers' representatives before using it at work, and tell people when a decision about them involved it. Credit and life or health insurance deployers also owe a fundamental rights impact assessment.
For most Annex III areas the conformity assessment is internal control, with no notified body. Biometrics can require one. SMEs and small mid-caps get simplified documentation, proportionate quality management and sandbox priority. The duties themselves remain.
Two traps matter for engineering. A high-risk system already on the market before 2 August 2026 is caught only if its design changes significantly afterwards. Swapping the model or adding tools may count, so treat those as decisions with legal weight. And if you take a general-purpose system and point it at an Annex III purpose, Article 25 makes you its provider. Retrofitting all of this costs several times what building it in does.
What to do this quarter
- 01Ship the Article 50 disclosures if you have not. They are already late.
- 02Classify every AI feature in production in a register, with the reasoning.
- 03Add logging and version pinning to anything live. You cannot reconstruct last quarter later.
- 04If you generate images or video, get abuse filters in place before 2 December 2026.
- 05Check your model provider contracts against the list above.
- 06For anything high risk, start the risk file and the technical documentation now. December 2027 is one or two build cycles away.
Most teams can do the first five themselves in a few weeks. If you want a second pair of eyes, our AI readiness assessment includes a written EU AI Act position per use case. A five day review covers a single existing AI feature. Either way you keep the document, and we can build what it recommends.