EU AI Act Obligations for High-Risk LLM Applications

If an LLM just summarizes internal documents, it is not high-risk under the EU AI Act. The same model, wired into a hiring pipeline to screen candidates, is. That single contrast captures the Act's whole design: it regulates what a system is used to do, not which model runs underneath it, how it was trained, or where it's hosted. The legal test is the risk an AI system poses to health, safety, and fundamental rights, full stop.

This logic plays out across four tiers. Some uses are banned outright (unacceptable risk). Some trigger the full Annex III obligations (high-risk). Some require only that users be told they're talking to AI (limited-risk). And some carry no specific requirement at all (minimal-risk). A chatbot and a credit-scoring tool can run on the identical foundation model and land in entirely different tiers, because the tiers are assigned to the use, not the technology.

Two consequences follow, and both trip up enterprises that haven't internalized the logic. First, self-hosting changes nothing. An on-premise deployment of a high-risk use case carries the same obligations as a cloud API deployment of that same use case. Anyone pitching "on-premise means compliant" is selling a category error. Second, "we just use the vendor's model" doesn't get an enterprise off the hook either. The Act assigns obligations by role in the supply chain, not by who owns the weights, and that distinction is where the next section picks up.

Annex III and How to Read It Against an LLM Deployment

Annex III lists eight sectors where AI systems are presumed high-risk, and most enterprise LLM deployments that touch decisions about actual people will land in at least one of them. You can't just match job titles or product names against a checklist. Ask what determination the system's output enables or informs. Annex III is applying that test, and it's why two systems that look similar on the surface can land in different tiers.

Employment and worker management is the sector enterprise teams hit most often: recruitment and candidate screening, promotion decisions, performance monitoring, task allocation. It also covers AI assisting judges or administrative bodies, along with legal research tools that shape case outcomes.

One rule cuts across all eight categories and deserves its own attention: the profiling exception. Any AI system that processes personal data to evaluate a person's work performance, economic situation, health, behavior, preferences, or location is automatically high-risk, regardless of which Annex III sector it otherwise touches. That exception catches systems that don't look like obvious hiring or lending tools on first glance.

If an LLM application doesn't fit any Annex III sector and doesn't perform profiling, it is typically limited-risk: internal chatbots, content generation tools, retrieval-augmented systems built over internal documents. The obligation there is disclosure, telling users they're interacting with AI, not a conformity assessment.

Splitting Obligations Between Providers, Deployers, and Downstream Builders

Most enterprises calling commercial LLM APIs occupy the deployer or downstream provider role, not the provider role. But the line between these roles isn't fixed, and crossing it means taking on a much heavier compliance load.

A provider develops an AI system or GPAI model and places it on the EU market. A downstream provider sits between the two, building applications on top of GPAI models made by others. Its obligations are heavier than a pure deployer's but lighter than a from-scratch provider's.

The Act also reaches outside the EU's borders. A US company whose model is deployed by EU customers is in scope, and third-country providers must appoint an EU authorized representative in writing.

One objection enterprises raise often doesn't hold up: a vendor's terms of service claiming the vendor is the provider doesn't settle the question. Placing a fine-tuned system on the market under your brand makes you the provider no matter what the upstream agreement says.

The layered obligations that apply to any confirmed high-risk LLM application

Once an application is confirmed high-risk, the obligations stack across risk management, data governance, technical documentation, logging, human oversight, cybersecurity, incident reporting, and conformity assessment, and all of it needs to be in place before the system goes to market.

Risk management, under Article 9, means a documented system covering identification, analysis, mitigation, and monitoring that runs continuously through the AI's lifecycle. This isn't a one-time assessment done at launch. It connects directly to post-market monitoring from day one.

Data governance, under Article 10, requires documenting the origin, relevance, representativeness, and potential biases of training, validation, and testing datasets. Data lineage should function as a first-class asset here, with every dataset carrying metadata on source, legal basis, consent status, retention period, and transformations applied.

Technical documentation, under Article 11 and Annex IV, covers system design, intended purpose, capabilities, limitations, and performance metrics, and it needs to be detailed enough that regulators, and in some sectors customers, can understand the AI's role in a workflow and how it's controlled. For API-accessed models, the documentation has to describe a moving target, since the vendor can update the model underneath the application without notice.

Cybersecurity, under Article 15, needs particular attention if your team is used to thinking about security in conventional software terms. The Act requires technical robustness against adversarial attacks by unauthorized third parties, and it names specific threats: data poisoning, adversarial examples, confidentiality attacks, model evasion. These map directly onto LLM-specific attack surfaces like prompt injection, and it's the obligation teams coming from a traditional application-security background tend to underestimate, because the threat model is unfamiliar even when the compliance language sounds routine.

Incident reporting, under Article 73, requires a monitoring system in place from the first day of deployment. Serious incidents affecting life or safety must be reported within 24 hours. Other serious incidents get a 15-day window.

Conformity assessment and database registration, under Articles 43 and 49, work differently depending on what the application is. Self-assessment covers most Annex III systems. Either way, the system has to be registered in the EU AI public database before it goes to market, with CE marking and an EU declaration of conformity attached.

Finally, the Fundamental Rights Impact Assessment, under Article 27, is mandatory for high-risk deployers that are public bodies, private bodies providing public services, or organizations conducting creditworthiness or life and health insurance risk assessments. Treat an existing data protection impact assessment as the base layer and extend it into the FRIA, keeping privacy risk and broader fundamental rights risk in one integrated register.

GPAI model obligations that apply regardless of high-risk classification

Separate from everything above, general-purpose AI model providers carry their own set of obligations, enforceable since August 2025, regardless of whether any downstream application built on the model is high-risk. The GPAI Code of Practice is the main mechanism for showing conformity, and whether a provider has signed it changes what's required of them.

They have to publish a summary of training data content with the AI Office's template, and they must comply with EU copyright law, including text-and-data-mining opt-out mechanisms.

The Commission's GPAI guidelines use 10²³ FLOP of training compute as the indicative threshold for coverage.

As of mid-2026, Anthropic, Google, Microsoft, OpenAI, IBM, Mistral AI, Cohere, and Amazon have signed the full Code, alongside roughly a dozen other companies including Aleph Alpha, ServiceNow, and Black Forest Labs. xAI signed only the Safety and Security chapter and has to demonstrate Transparency and Copyright compliance through other means. Meta declined to sign and has to demonstrate every applicable obligation by alternative means.

For enterprises building on top of these models, this matters directly. The obligations above sit with the model maker, not with the enterprise calling the API, but the enterprise's own documentation and risk assessment depend on what the upstream provider actually furnishes. Which chapters of the Code a given foundation model provider has signed tells you how much of your own technical file you can fill in from the vendor's documentation and how much you'll have to build yourself.

The enforcement timeline and the Digital Omnibus changes

Several dates matter here, and they don't all point to the same deadline. The grace period for Article 50(2)'s machine-readable marking requirement runs out 2 December 2026.

The headline change is the Annex III deadline. High-risk AI built into regulated products under Annex I still has its own date: 2 August 2028.

The delay reflects an absence of finalized technical standards for conformity assessment, not a softening of what's expected. Compliance programs built against the original August 2026 deadline remain valid and worth continuing exactly as planned.

Enforcement infrastructure isn't waiting around for 2027 either.

The fines attached to all of this scale with company size. For large multinationals, the percentage of global turnover is the figure that bites.

Where Enterprise Compliance Programs Stand

Most compliance programs aren't behind because of budget. Classification is the prerequisite every other obligation depends on, so skipping it doesn't save time, it just moves the problem downstream.

Harmonized technical standards meant to guide compliance arrived late, so enterprises have had to interpret the Act's requirements without the standards its own conformity assessment process assumes will exist. Organizations starting late don't just face a shorter runway, they face a compressed version of the same multi-step dependency chain, and no amount of extra budget shortens a dependency chain that has to run in order.

The vendor relationship adds another layer of difficulty. If the GPAI provider hasn't furnished that documentation, an enterprise using a third-party LLM can't fully document that system's training data provenance, model architecture, or upstream data governance. GPAI Code signatory status matters to downstream builders because it's a proxy for how much of that documentation burden the model maker has already carried.

The sharpest version of this problem is visible in unvetted vendor AI, models, plugins, agents, and connectors brought into an enterprise environment without any assessment. That's the blind spot traditional security and governance frameworks were never built to catch, and it's exactly where Article 15's adversarial robustness requirements and the Act's incident reporting obligations become impossible to meet, because you can't secure or report on an asset the compliance function doesn't know exists.

The Act's answer to this is built into its own structure: the risk management system has to run throughout the model's operational life, not conclude once the system is deployed. Building that kind of continuous monitoring capability, one that can surface new vendor AI assets and emerging risks before they become compliance gaps, is what the Act's own language is asking enterprises to build.

A practical compliance sequence for enterprises with LLMs in or approaching high-risk territory

You can't work through the eight steps below as a checklist in parallel. They're a dependency chain, and the first two steps gate everything that comes after.

Step 1 is inventory. Map every LLM application in production or development against the Annex III sectors, one by one, and include AI tools you brought in through vendors. Apply the profiling check as a cross-cutting screen across the whole inventory, then document the results as a formal classification register. Nothing downstream works without this step done first.

Step 2 is role determination. For each application that comes out high-risk, you need to establish whether the organization acts as provider, downstream provider, or deployer. Flag any fine-tuned or rebranded deployment that may have crossed into provider territory, and confirm EU authorized representative arrangements are in place for any non-EU-established entity in the chain.

Step 3 is logging infrastructure, which can start now, independent of classification results. A gateway-with-audit-log pattern satisfies the record-keeping requirements of both the AI Act and GDPR at once. On-premise deployments already have log format, retention, and completeness under direct enterprise control. For API-accessed models, you need to check the vendor's log export capabilities and retention windows against the six-month minimum.

Step 4 builds the technical file per high-risk application: model versions pinned and documented (with a weights hash for self-hosted models), system prompts, intended purpose, performance metrics, risk controls. This becomes the backbone everything else in the technical documentation and conformity assessment process builds on.

Step 5 integrates data governance with the FRIA and DPIA. Treat the GDPR DPIA as the base layer, then extend it into the Fundamental Rights Impact Assessment wherever the Act requires one, keeping both sets of risks in a single integrated register.

Step 6 implements human oversight mechanisms and AI literacy training. AI literacy requirements have been enforceable since February 2025, so this step is already overdue for organizations that haven't started. Oversight mechanisms need competent personnel identified per high-risk application, with training documented.

Step 7 stands up continuous monitoring and incident response. The risk management system has to operate across the AI's entire lifecycle, and the incident reporting timelines, 24 hours for life or safety incidents, 72 hours for other serious incidents, 15 days for malfunctions, require monitoring infrastructure that can detect and escalate problems in near real time. Vendor AI assets sitting outside the traditional security perimeter, plugins, agents, API connectors, have to be inside the scope of this monitoring, not treated as someone else's problem.

Step 8 completes conformity assessment and registers the system in the EU AI database: self-assessment for most Annex III systems, third-party assessment for biometric identification and certain critical infrastructure applications, CE marking affixed and the EU declaration of conformity drawn up before the system goes to market.

One detail belongs in the technical file for every high-risk application built on a third-party foundation model: which chapters of the GPAI Code of Practice that model's provider has signed. That status can change over time as providers update their compliance posture, and tracking it is part of the same continuous risk management obligation that runs through every other step in this sequence.