EU AI Act obligations for LLM applications

Most enterprise LLM applications are not high-risk AI systems under the EU AI Act. An internal assistant, a support copilot or a RAG search tool over your own documents is, in the Act's own scheme, usually a transparency-risk system: you must tell people they are talking to a machine and label synthetic content, and that is close to the whole of it. The heavy obligations — conformity assessment, technical documentation, registration, post-market monitoring — attach to a defined list of use cases, and to the provider of a general-purpose model rather than to the company deploying one.

Getting that classification right first is worth more than any control you could buy, because the wrong answer is expensive in both directions: a team that wrongly believes it is high-risk spends a year on a conformity file it did not need, and a team that wrongly believes it is not misses a deadline that carries administrative fines.

Source and currency. Every date below is taken from the European Commission's own regulatory-framework page for the AI Act, which was last updated 3 August 2026. We checked it on 12 August 2026. The authoritative text is Regulation (EU) 2024/1689 on EUR-Lex. Re-check both before relying on this page after 12 November 2026.

The dates changed in 2026. Most published timelines are wrong.

This is the single most important thing on this page. A great many articles, vendor pages and internal compliance decks still show 2 August 2026 and 2 August 2027 as the high-risk deadlines. Those were the dates in the Regulation as originally adopted. They were moved.

The amending package is the Commission's AI Omnibus, part of the Digital Package on Simplification. The Commission's own page records it as adopted on 19 November 2025, reaching political agreement on 7 May 2026, and entering into force on 27 July 2026. It moved the high-risk application dates back by over a year in each case.

If your programme plan still cites 2 August 2026 or 2 August 2027 as the high-risk deadline, it predates the amendment and needs revisiting.

The timeline as it stands

Which tier are you in?

The Act sorts systems into four bands. In order of severity:

Unacceptable risk — prohibited. Social scoring, certain biometric categorisation, manipulative techniques that cause significant harm, and the other practices listed in Article 5. These have been banned since 2 February

1. If your use case is here, no control changes the answer.

High risk. Two routes in. Either the system is used in one of the areas listed in Annex III — biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, or the administration of justice — or it is a safety component of a product already regulated under the EU legislation in Annex I, such as machinery, lifts or toys. High-risk systems carry the full obligation set: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, and conformity assessment before placing on the market.

Transparency risk. Systems that interact with people or generate content. The Act's requirement is disclosure: when people use a system such as a chatbot, they must be made aware they are interacting with a machine; providers must ensure AI-generated content is identifiable as such; and deepfakes must be clearly and visibly labelled. This is the band most enterprise LLM deployments land in, and it is the band whose obligations are cheapest to satisfy and most often quietly skipped.

Minimal or no risk. No obligations under the Act.

Note that the tier is a property of the use case, not of the model. The same frontier model is minimal-risk behind an internal code-search tool and high-risk behind a CV-screening step. Classify per application, and re-classify when the application's job changes — which, for an agentic system whose tool set grows sprint by sprint, is more often than a yearly review will catch.

Provider or deployer? The distinction that decides your bill

The Act places different duties on the provider who develops and places a system on the market and the deployer who uses it under its own authority. Most companies building on someone else's model are deployers of a system and downstream users of a GPAI model — not providers of a GPAI model.

That matters because the obligations on GPAI model providers that started on 2 August 2025 — technical documentation, a copyright policy, a public summary of training content, and, for models presenting systemic risk, model evaluation and risk mitigation — are duties of the organisation that trained and released the model. Building a product on top of that model does not inherit them.

There is a trap in the other direction, though. A deployer can become a provider: putting your own name or trade mark on a high-risk system, making a substantial modification to one, or changing its intended purpose so that it becomes high-risk moves the provider obligations onto you. Fine-tuning a model and shipping it as your own product is the version of this that catches AI teams.

What a security layer can and cannot do for this

Be direct about the limit, because vendors in this category routinely are not. No product makes an organisation compliant with the EU AI Act. The obligations are organisational: a risk management system, a quality management system, technical documentation, a conformity assessment, human oversight arrangements, and registration in an EU database. Those are governance artefacts, produced by people, signed by an accountable person.

What a runtime control layer genuinely contributes is evidence, and evidence is the part teams find they cannot reconstruct after the fact:

• Logging and record-keeping. Article 12 requires high-risk systems to log events automatically over their lifetime, and Article 19 requires providers to keep those logs. An inline control that records every model call, the policy decision applied and the context that produced it is the mechanism that makes those records exist.
• Human oversight. Article 14 requires that high-risk systems be designed so a person can intervene. A confirmation step in front of irreversible or outbound actions is a technical implementation of exactly that requirement.
• Accuracy, robustness and cybersecurity. Article 15 asks for resilience against attempts to alter a system's use or performance by exploiting its vulnerabilities. Prompt injection is the canonical example in an LLM system, and the controls that address it are described in our prompt injection explainer.
• Transparency. Machine-readable records of which models and providers were actually called — derived from traffic rather than from a spreadsheet — are what turns a system inventory into something an auditor can test.

What it does not do: classify your systems, write your technical documentation, run your conformity assessment, or make you a provider's problem rather than your own.

Where SecureAI Guard fits

SecureAI Guard is an enterprise security layer for LLM and generative-AI applications: it sits inline between an application and the models it calls, inspecting prompts and completions in both directions to enforce policy server-side. Because it is on the request path, it is also the only place in a typical architecture where the evidence described above can be captured completely and consistently.

That produces technical evidence for a subset of the obligations above. It is help with the file, not a certificate. Our own certification and audit position — what we hold, what we do not, and when — is stated with dates on the trust page, including where the honest answer today is "not yet".

Primary sources

• Regulation (EU) 2024/1689 — the AI Act, on EUR-Lex
• European Commission — regulatory framework for AI (the source of the dates above; last updated 3 August 2026, checked 12 August 2026)
• European AI Office

Related

• NIST AI Risk Management Framework — the governance framework most often used to implement what the Act requires
• ISO/IEC 42001 — the certifiable management system that carries the evidence
• GDPR and LLM data handling — the other EU instrument that applies to the same traffic
• The OWASP LLM Top 10, entry by entry