EU AI Act LLM Guide: High-Risk Classification, Documentation Requirements & 2026 Deadlines

The EU AI Act entered into force in August 2024. Penalties for violations can reach €35 million or 7% of global annual revenue.

If your company builds, deploys, or uses LLM-based applications in the EU market, you have compliance obligations. The specifics depend on three factors: what role you play in the AI value chain, what risk tier your application falls into, and whether you use general-purpose AI models.

This guide covers the technical compliance requirements for LLM applications. Not the legal theory. The practical work engineering and product teams need to do before August 2026.

Timeline: What's Already Enforceable

The Act phases in over three years. Some obligations are already live:

Date	What Applies
February 2, 2025	Prohibited AI practices banned. AI literacy requirements for staff.
August 2, 2025	GPAI model provider obligations (transparency, copyright, documentation).
August 2, 2026	Full enforcement for high-risk AI systems. Conformity assessments required.
August 2, 2027	Legacy GPAI models placed on market before August 2025 must comply.

Finland became the first EU member state with active enforcement powers in January 2026. Other countries are following. The regulatory apparatus is operational.

Your Role Determines Your Obligations

The Act assigns different duties to different actors in the AI supply chain. For LLM applications, four roles matter:

Provider: You develop the AI system or have it developed under your direction, then place it on the EU market under your name or trademark. If you fine-tune a model substantially and deploy it commercially, you may become the provider of the resulting system.

Deployer: You use an AI system under your own authority for professional purposes. Most companies using commercial LLM APIs fall here. You deploy, you don't develop.

GPAI Model Provider: You create general-purpose AI models (like foundation models) and make them available to others. Think OpenAI, Anthropic, Mistral, Meta for open-weight models.

Downstream Provider: You build AI systems on top of GPAI models created by others. If you build a product using Claude or GPT-4 via API, you're a downstream provider.

Most companies reading this will be deployers or downstream providers. You use LLMs, you don't train them from scratch. Your obligations are lighter, but they exist.

Risk Classification for LLM Use Cases

The Act defines four risk tiers: unacceptable (banned), high, limited, and minimal. LLM applications can fall into any category depending on how they're used.

Unacceptable Risk: Prohibited Since February 2025

These AI applications are banned outright:

• Subliminal manipulation that distorts behavior and causes harm
• Exploitation of vulnerabilities (age, disability, economic situation) to distort behavior
• Social scoring by governments
• Emotion recognition in workplaces and educational settings (with narrow exceptions)
• Real-time biometric identification in public spaces for law enforcement (with narrow exceptions)
• Predictive policing based solely on profiling

An LLM-powered system that manipulates users into harmful decisions through deceptive techniques would violate the prohibition. Same for chatbots designed to exploit vulnerable users.

High-Risk: Compliance Required by August 2026

Annex III lists use cases that trigger high-risk classification. For LLM applications, the relevant categories include:

Employment and Worker Management

• AI systems for recruitment and candidate screening
• Systems making decisions on promotion, termination, task allocation
• Performance monitoring and evaluation tools

If your LLM application screens resumes, ranks candidates, or evaluates employee performance, it's likely high-risk.

Access to Essential Services

• Credit scoring and loan eligibility assessment
• Insurance risk assessment and pricing
• Healthcare triage and resource allocation

An LLM that helps decide who gets a loan, what insurance premium someone pays, or who gets prioritized for medical care triggers high-risk requirements.

Education

• Student assessment and examination systems
• Admission decision support
• Learning analytics that affect educational outcomes

LLM-powered grading systems or admission screening tools fall here.

Administration of Justice

• AI assisting judges or administrative bodies
• Legal research tools that influence case outcomes

LLM applications used by courts or administrative bodies for decision support are high-risk.

Critical Infrastructure

• AI managing energy, water, transport, or digital infrastructure
• Safety components in these sectors

LLM agents controlling critical systems trigger high-risk classification.

Limited Risk: Transparency Required

This is where most commercial LLM applications land. Chatbots, content generation tools, AI assistants, and RAG systems typically fall into limited risk.

The main requirement: users must know they're interacting with AI. For chatbots, this means clear disclosure that responses come from an automated system, not a human. For AI-generated content, the output should be identifiable as machine-generated.

Deepfakes and synthetic media require explicit labeling.

Minimal Risk: No Specific Requirements

Spam filters, basic recommendation systems, and AI features that don't affect rights or decisions fall here. No compliance obligations beyond general consumer protection law.

The Profiling Exception

One critical rule: any AI system that performs profiling of individuals is automatically considered high-risk, regardless of which Annex III category it falls into.

If your LLM application processes personal data to evaluate aspects of someone's life (work performance, economic situation, health, behavior, preferences, location), it triggers high-risk classification.

GPAI Model Obligations

The Act creates a separate regulatory track for general-purpose AI models. As of August 2025, GPAI model providers must comply with specific obligations.

Who Qualifies as a GPAI Model?

The Commission defines a GPAI model as one trained with more than 10²³ FLOPs that can generate language, text-to-image, or text-to-video outputs. This threshold captures most commercial LLMs.

Models below this threshold may still qualify if they demonstrate "significant generality" and can "competently perform a wide range of distinct tasks."

Provider Obligations

All GPAI model providers must:

Technical Documentation: Maintain detailed documentation covering model architecture, training procedures, evaluation results, capabilities, and limitations. Submit to the AI Office and national authorities upon request.

Downstream Provider Support: Provide information enabling downstream developers to understand capabilities, limitations, and integrate the model while meeting their own compliance obligations.

Copyright Compliance: Establish policies respecting EU copyright law, including text-and-data mining opt-outs under the Copyright Directive.

Training Data Summary: Publish a summary of training content using the Commission's template. This includes data types, sources, and preprocessing methods.

Systemic Risk Models

Models trained with more than 10²⁵ FLOPs are presumed to carry systemic risk. These face additional requirements:

• Model evaluations and adversarial testing
• Systemic risk assessment and mitigation
• Serious incident reporting
• Cybersecurity protections

The 10²⁵ FLOP threshold currently captures only the largest frontier models (GPT-4 class and above). Providers must notify the Commission within two weeks of reaching or anticipating this threshold.

Open-Source Exemptions

Free and open-license models are exempt from technical documentation and downstream provider support obligations. They must still comply with copyright requirements and publish training data summaries.

The exemption does not apply if the open-source model poses systemic risk.

What This Means for LLM Users

If you're using commercial LLM APIs (OpenAI, Anthropic, Google, Mistral), the GPAI provider obligations fall on those companies, not you. OpenAI, Anthropic, and Google have all signed the GPAI Code of Practice.

But you inherit responsibilities as a downstream provider. You need the information these providers supply to meet your own compliance obligations. If they don't provide adequate documentation, your compliance becomes harder.

High-Risk System Requirements

If your LLM application qualifies as high-risk, you face comprehensive compliance mandates before August 2026.

Risk Management System

Implement a continuous risk management process throughout the AI system lifecycle. This includes:

• Identifying and analyzing known and foreseeable risks
• Estimating and evaluating risks from intended use and reasonably foreseeable misuse
• Adopting risk management measures
• Testing to ensure measures work

For LLM applications, this means documenting prompt injection risks, hallucination rates, bias patterns, and mitigation strategies.

Data Governance

Training, validation, and testing datasets must be:

• Relevant to the intended purpose
• Sufficiently representative
• As free from errors as possible
• Complete according to intended purpose

For fine-tuned LLMs, you need documentation of your training data sources, quality controls, and preprocessing steps.

Technical Documentation

Create and maintain documentation demonstrating compliance. The content varies by system type but generally includes:

• General system description and intended purpose
• Design specifications
• Description of system elements and development process
• Monitoring, functioning, and control descriptions
• Risk management documentation
• Changes made during lifecycle
• Performance metrics and testing results

Record-Keeping

High-risk systems must automatically log events relevant to:

• Identifying risks at national level
• Substantial modifications during lifecycle
• Conformity assessment validation

For LLM applications, this means maintaining audit logs of inputs, outputs, and system behavior.

Human Oversight

Design the system to allow effective human oversight. This includes:

• Enabling human operators to understand system capabilities and limitations
• Allowing humans to correctly interpret outputs
• Providing ability to decide not to use the system
• Enabling intervention or stopping of the system

For LLM applications processing sensitive decisions, this typically means keeping humans in the loop for final determinations.

Accuracy, Robustness, and Cybersecurity

Systems must achieve appropriate levels of:

• Accuracy for intended purpose
• Robustness against errors and inconsistencies
• Cybersecurity protection against unauthorized access

For LLMs, document your evaluation methodology, performance benchmarks, and security controls.

Conformity Assessment

Before placing a high-risk system on the market, complete a conformity assessment. For most Annex III systems, this is a self-assessment based on internal controls. Some categories require third-party assessment.

After passing assessment, affix CE marking and register the system in the EU database.

Deployer Obligations

If you deploy (use) high-risk AI systems developed by others, your obligations include:

• Using the system according to provider instructions
• Ensuring human oversight by competent personnel
• Monitoring system operation for risks
• Keeping logs generated by the system
• Informing the provider of serious incidents
• Conducting fundamental rights impact assessments (for public bodies and certain private deployers)
• Maintaining appropriate AI literacy among staff operating the system

The AI literacy requirement has been enforceable since February 2025. Your team operating AI systems needs training appropriate to their role.

The Data Sovereignty Question

The Act doesn't explicitly mandate data residency, but several provisions create strong incentives for controlling where your AI processing happens.

Documentation Requirements: You need to demonstrate what data trained your model, how it was processed, and what safeguards protect it. This is easier when you control the infrastructure.

Audit Trails: High-risk systems need logging and record-keeping. Cloud APIs don't always provide the granularity regulators may want to see.

Incident Response: If something goes wrong, you need to investigate. That requires access to system internals that cloud providers may not expose.

Copyright Compliance: Demonstrating your model doesn't infringe copyright requires knowing what's in your training data. Third-party models with opaque training sets create liability uncertainty.

For organizations in regulated industries (healthcare, finance, critical infrastructure), these pressures push toward greater infrastructure control. Self-hosted deployment provides full visibility into data flows, complete audit trails, and demonstrable compliance with data residency requirements.

The PremAI platform offers self-hosted inference with sub-100ms latency and zero data retention. For organizations where EU data can't leave EU infrastructure, this architecture eliminates the compliance ambiguity of routing through US-based cloud APIs.

Swiss jurisdiction adds another layer. The Federal Act on Data Protection (FADP) provides data protection comparable to GDPR, and Switzerland's adequacy status with the EU simplifies cross-border data flows within compliant infrastructure.

Technical Documentation Template

Here's what your technical documentation should cover for an LLM application:

General Description

1. System name and version
2. Provider/developer identification
3. Intended purpose and use cases
4. User types (who operates it, who is affected by it)
5. Deployment context (cloud, on-premise, hybrid)
6. Geographic scope of deployment

Model Information

1. Base model identification (name, version, provider)
2. Model architecture overview
3. Training data description (if fine-tuned)
4. Fine-tuning methodology (if applicable)
5. Capabilities and limitations
6. Known failure modes

Risk Management

1. Identified risks (accuracy, bias, security, misuse)
2. Risk assessment methodology
3. Mitigation measures implemented
4. Residual risk documentation
5. Testing results validating mitigations

Data Governance

1. Input data types and sources
2. Data quality controls
3. Bias assessment methodology
4. Training data documentation (for fine-tuned models)
5. Data retention and deletion policies

Performance and Evaluation

1. Accuracy metrics for intended use cases
2. Evaluation dataset description
3. Benchmark results
4. Failure rate documentation
5. Robustness testing results

Human Oversight

1. Human-in-the-loop processes
2. Override mechanisms
3. Operator training requirements
4. Escalation procedures

Logging and Monitoring

1. Log data captured
2. Log retention periods
3. Monitoring dashboards and alerts
4. Incident response procedures

For enterprise deployments, maintaining this documentation is simpler when you control the model lifecycle. Fine-tuning on your own data means you know exactly what trained the model. Self-hosted inference means you control the logging.

Compliance Checklist for August 2026

Start now. Conformity assessment alone takes 6-12 months for complex systems.

Immediate (Now - Q2 2026)

AI Inventory: Catalog every AI system in use. Document intended purpose, user types, and deployment context.

Role Classification: For each system, determine whether you're provider, deployer, or downstream provider.

Risk Classification: Map each system to risk categories. Document the assessment, especially for borderline cases.

Prohibited Use Check: Verify no system violates Article 5 prohibitions. Discontinue any that do.

AI Literacy: Train staff operating AI systems. Document the training program.

Mid-Term (Q2 - Q3 2026)

Technical Documentation: Create documentation for high-risk systems following the template structure.

Risk Management: Implement formal risk management processes. Document identified risks and mitigations.

Data Governance: Audit training data for fine-tuned models. Implement quality controls.

Human Oversight: Define and implement oversight processes. Train operators.

Logging: Ensure high-risk systems generate required audit logs.

Pre-Deadline (Q3 - August 2026)

Conformity Assessment: Complete self-assessment or third-party assessment as required.

CE Marking: Prepare marking for high-risk systems passing assessment.

EU Database Registration: Register high-risk systems.

Quality Management System: Establish QMS processes for ongoing compliance.

Post-Market Monitoring Plan: Define monitoring and incident response procedures.

Common Questions

Do chatbots require high-risk compliance?

Usually no. Standard customer service chatbots fall into limited risk, requiring only transparency (users know they're talking to AI). But if the chatbot makes decisions affecting employment, credit, healthcare access, or education outcomes, it triggers high-risk classification.

What if I use multiple LLM providers?

Each provider relationship should be documented. Understand what technical documentation each provider supplies. Ensure you can demonstrate compliance for the combined system, not just individual components.

Does the Act apply to internal tools?

Yes, if they affect employees or are used for professional purposes. HR tools using LLMs for performance evaluation are high-risk regardless of whether they're internal-only.

What about RAG systems?

RAG (retrieval-augmented generation) systems typically fall into limited risk unless the use case triggers high-risk categories. Document your retrieval sources and how they affect outputs. If RAG-enhanced responses drive decisions in high-risk domains, the full requirements apply.

Can I wait for the potential Digital Omnibus delay?

Don't count on it. The Commission proposed potential delays of up to 16 months for high-risk systems IF standards are unavailable, with backstop dates ensuring enforcement regardless. Prudent planning treats August 2026 as the binding deadline.

How do I prove copyright compliance for models I didn't train?

You rely on your GPAI provider's documentation. OpenAI, Anthropic, and other providers who signed the Code of Practice commit to copyright compliance policies. Document your due diligence in selecting providers with adequate compliance measures.

Implementation Resources

The Commission provides several resources:

• GPAI Code of Practice: Voluntary framework for demonstrating compliance. Three chapters cover transparency, copyright, and safety/security.
• Guidelines on GPAI Providers: Clarifies when models qualify as GPAI and which obligations apply.
• Training Data Summary Template: Required format for publishing training content summaries.
• AI Act Service Desk: Commission resource for compliance questions.

National authorities are also establishing guidance. The German Federal Network Agency's AI Service Desk provides SME-focused support.

Beyond Compliance

Meeting minimum requirements protects you from penalties. But the organizations treating AI governance as strategic rather than defensive will have advantages.

Strong model evaluation practices improve product quality alongside compliance. Comprehensive documentation accelerates debugging and iteration. Human oversight processes catch errors before they reach users.

The Act's requirements push toward practices that well-run AI teams should implement anyway. Use the compliance deadline as forcing function for building proper infrastructure.

For teams starting their compliance work, the foundation is understanding your AI inventory, classifying your risk levels, and identifying gaps between current state and requirements. Start there. The deadline is closer than it appears.