EU AI Act Compliance for LLM Features: A 2026 Checklist

Most teams we talk to in Germany and the Netherlands have stopped asking whether the EU AI Act applies to them. The question now is narrower: which parts apply to the specific feature they are about to ship, and what has to exist in the codebase before it goes live. That is an engineering question as much as a legal one, because most of the obligations end up as logs, UI copy, review queues and documents generated from the system itself.

This post walks through the regulation the way we approach it on client projects. It assumes you are building on top of a general-purpose model from a provider such as OpenAI, Anthropic, Google or Mistral, rather than training a foundation model yourself. That is the situation for the vast majority of product teams.

Provider or deployer: decide your role first

The Act assigns duties by role. A provider develops an AI system (or has one developed) and places it on the market under its own name. A deployer uses an AI system under its authority in a professional context. If you build a support chatbot into your SaaS product and sell that product, you are generally the provider of that AI system, even though the underlying model came from someone else. Your enterprise customer who switches it on for their staff is a deployer.

This matters because the heavier obligations for high-risk systems sit with providers. It also matters for contracts. If you substantially modify a third-party system, or put your name on it, you can inherit provider duties. We have seen procurement teams in DACH start asking vendors to state their role in writing, so it is worth settling internally before the first security questionnaire arrives.

The Act also reaches outside the EU. A US or UK company whose system is used in the EU, or whose output is used there, is in scope. UK teams selling into the EU should treat it the same way they treated GDPR.

The four risk tiers, mapped to real features

The Act sorts AI uses into tiers, and the tier is set by the use case, not the model. The same LLM can power a harmless FAQ bot and a CV-screening tool that falls squarely into high-risk.

There is a filter worth knowing about. An Annex III system is not considered high-risk if it performs a narrow procedural task, improves the result of a previously completed human activity, or does preparatory work for an assessment, provided it does not profile people. A tool that reformats a recruiter's notes is very different from one that scores candidates. If you rely on this exception, the Act expects you to document the reasoning before you place the system on the market.

Timeline: what applies now and what is moving

The Act entered into force on 1 August 2024 and applies in stages. The prohibitions and the AI literacy duty have applied since 2 February 2025. Obligations for providers of general-purpose AI models, plus the governance and penalty framework, followed on 2 August 2025. The bulk of the remaining rules, including Annex III high-risk obligations and the Article 50 transparency duties, were scheduled for 2 August 2026, with high-risk systems embedded in regulated products (Annex I) following in August 2027.

In late 2025 the European Commission proposed a digital omnibus package that would push some high-risk dates back and tie them to the availability of harmonized standards and support tools. At the time of writing that proposal is still moving through the legislative process, and the final dates may differ from both the original text and the proposal. Check the current status before you plan a release around any specific date. Our practical advice is to treat the transparency obligations as live and to build high-risk controls into the architecture now, because retrofitting audit logging into a system that is already in production costs far more than adding it at design time.

If you only consume a GPAI model through an API, the August 2025 GPAI rules mostly bind your model provider, not you. What you should do is collect the documentation they are now required to give downstream providers (capabilities, limitations, intended uses) and file it with your own technical documentation.

Transparency for chatbots and generated content

Article 50 is the part that touches the most product teams, because it covers ordinary chatbots and content generation. The engineering translation is fairly direct:

• Chat and voice interfaces must make it clear that the user is interacting with an AI system, unless that is obvious from context. A small label in the chat header plus a line in the first message is the pattern we use most often. Do not rely on a link buried in the terms of service.
• Providers of systems that generate synthetic audio, image, video or text must mark the output in a machine-readable format so it can be detected as AI-generated, where technically feasible. For images and video, look at C2PA content credentials and watermarking from your model provider. For text the state of the art is weaker, so document what you do and why.
• Deployers who publish deepfakes, or AI-generated text intended to inform the public on matters of public interest, must disclose that the content was artificially generated, with an exception for text that has gone through human editorial review.
• The disclosure has to be given at the latest at the first interaction and must meet accessibility requirements, so check contrast and screen reader output on the label.

For voice agents on phone lines, the cheapest compliant approach is a spoken disclosure in the greeting. It adds about two seconds to the call and removes a whole class of complaints.

Logging, oversight and documentation

If any feature lands in a high-risk category, three obligations will dominate the engineering work. Even for limited-risk features, building lighter versions of them is good practice, and enterprise buyers increasingly ask for them anyway.

Logging (Article 12) requires automatic recording of events over the system's lifetime, enough to identify situations that may create risk and to support post-market monitoring. In practice we log a request ID, timestamp, model and model version, prompt template version, retrieved document IDs, the output, any tool calls, confidence or guardrail scores, and the identity of the human who acted on the result. Store prompts and outputs separately from user identifiers so you can apply different retention rules. Deployers of high-risk systems must keep the logs they control for at least six months, unless other law says otherwise.

Human oversight (Article 14) means a person must be able to understand the system's output well enough to interpret it, decide not to use it, override it, or stop the system. A review queue where a recruiter has to click through every AI-ranked candidate is not oversight if the interface only shows a score. Show the evidence behind the output, make rejection as easy as acceptance, and watch for automation bias in your metrics. If reviewers accept 99.5% of suggestions in under three seconds, the oversight exists on paper only.

Technical documentation (Article 11 and Annex IV) covers the system's purpose, architecture, data, testing, performance metrics, known limitations and the risk management process. Generate as much of it as you can from the repository: evaluation reports from CI, model and prompt versions from config, data lineage from the pipeline. A Word document written once before launch will be out of date within a sprint.

Where the AI Act meets GDPR (DSGVO)

The AI Act does not replace GDPR. Both apply in parallel, and German data protection authorities have been clear that they will keep enforcing the DSGVO against AI systems. A few overlaps come up on almost every project.

• Legal basis: the AI Act does not give you one for processing personal data. You still need a GDPR basis for prompts containing personal data, for logs, and for any fine-tuning data.
• Data minimization versus logging: Article 12 wants detailed logs, GDPR wants you to hold as little as possible. Pseudonymize user identifiers in logs and set explicit retention periods per field.
• Automated decisions: GDPR Article 22 already restricts decisions based solely on automated processing that significantly affect people. A high-risk AI system with real human oversight helps on both fronts.
• International transfers: if your model provider processes data outside the EU, you need a transfer mechanism. Many providers now offer EU data residency, and some German buyers will insist on it.
• DPIA: a high-risk AI system processing personal data will almost certainly need a data protection impact assessment. The AI Act documentation can feed into it.

A pre-release checklist for LLM features

1. Write down the intended purpose of the feature in one paragraph. Classification depends on it.
2. Classify the use case against Article 5 and Annex III, and record the reasoning, including any reliance on the Article 6(3) exception.
3. Confirm your role (provider or deployer) and reflect it in customer contracts.
4. Add AI disclosure to every chat, voice and generated-content surface, and test it with a screen reader.
5. Implement structured, versioned logging with separate retention rules for content and identity.
6. Design the human review step so reviewers see evidence, can reject easily, and their decisions are logged.
7. Run evaluations in CI and keep the reports. They become your accuracy and reliability evidence.
8. Collect your GPAI provider's downstream documentation and data processing terms.
9. Run AI literacy training for the staff who build, sell and operate the feature, and keep a record.
10. Assign an owner to track the omnibus changes and implementing guidance from the AI Office.

None of this is exotic engineering. Most of it is the observability and review tooling a careful team would build for an LLM feature anyway. The regulation mainly forces you to write it down and keep it current.

Questions we get asked

Does the EU AI Act apply to companies outside the EU?

Yes. It applies to providers placing AI systems on the EU market and to providers and deployers outside the EU whose system output is used in the EU. US, UK and Australian companies selling into Europe are generally in scope.

Is a customer support chatbot a high-risk AI system?

Usually not. A standard support chatbot falls under the transparency obligations, so users must be told they are talking to an AI. It becomes high-risk only if it is used for an Annex III purpose, such as deciding access to essential services.

When do high-risk obligations apply?

The original text set 2 August 2026 for most Annex III systems and August 2027 for AI in regulated products. The proposed digital omnibus may delay some of these dates, so check the current legislative status before planning around them.

What are the penalties for non-compliance?

Fines reach up to 35 million euros or 7% of global annual turnover for prohibited practices, up to 15 million euros or 3% for most other breaches, and up to 7.5 million euros or 1% for supplying incorrect information to authorities.