EU AI Act Compliance in Practice

"Regulation does not stop innovation. It tells innovation where the guardrails are."

A Resolute Guard, Regulation-Respecting AI Agent

1. Risk Classification for LLM Applications

The EU AI Act defines four risk tiers. Understanding where your LLM application falls determines your legal obligations. The classification is based on the application, not the underlying model. The same GPT-4 model powering a creative writing assistant (minimal risk) and a medical triage system (high risk) triggers entirely different compliance requirements.

Figure 32.9.1: EU AI Act risk classification tiers and their corresponding compliance obligations. The same underlying model can trigger different risk levels depending on the application context. Classification is based on the application, not the model.

1.1 Prohibited Practices

Certain AI uses are banned outright. For LLM applications, the most relevant prohibitions include: social scoring systems that evaluate people based on social behavior or personality characteristics, real-time remote biometric identification in public spaces (with narrow law enforcement exceptions), and AI systems that manipulate human behavior through subliminal techniques to cause harm. An LLM chatbot designed to psychologically manipulate users into purchases they would not otherwise make could fall under this category.

1.2 High-Risk Systems

LLM applications become high-risk when deployed in specific domains enumerated in Annex III of the Act: employment (AI-powered hiring, performance evaluation), education (automated grading, admissions decisions), essential services (credit scoring, insurance underwriting), law enforcement, migration management, and administration of justice. If your LLM application makes or materially influences decisions in these domains, it is classified as high-risk and must comply with the full set of requirements described in Section 2 below.

1.3 Limited Risk: Transparency Obligations

Most customer-facing LLM chatbots fall into the "limited risk" category. The primary obligation is transparency: users must be informed that they are interacting with an AI system. Additionally, AI-generated content must be labeled as such when it could be mistaken for human-created content. This affects synthetic text, deepfake detection, and AI-generated images or audio.

1.4 Minimal Risk

Internal tools, spam filters, AI-assisted code completion, and other applications that do not directly affect individuals' rights fall into the minimal-risk category. No specific obligations apply beyond general product safety law. Most internal enterprise LLM applications fall here.

# Risk classification helper for LLM applications
from dataclasses import dataclass
from enum import Enum

class RiskTier(Enum):
 PROHIBITED = "prohibited"
 HIGH_RISK = "high_risk"
 LIMITED_RISK = "limited_risk"
 MINIMAL_RISK = "minimal_risk"

# Annex III domains that trigger high-risk classification
HIGH_RISK_DOMAINS = {
 "employment": [
 "recruitment", "hiring", "performance_evaluation",
 "task_allocation", "termination"
 ],
 "education": [
 "admissions", "grading", "learning_assessment",
 "student_monitoring"
 ],
 "essential_services": [
 "credit_scoring", "insurance_underwriting",
 "emergency_dispatch", "utility_access"
 ],
 "law_enforcement": [
 "crime_prediction", "evidence_evaluation",
 "profiling", "polygraph_replacement"
 ],
 "migration": [
 "visa_processing", "asylum_assessment",
 "border_control", "document_verification"
 ],
 "justice": [
 "sentencing_support", "legal_research_for_judges",
 "dispute_resolution"
 ],
}

@dataclass
class LLMApplication:
 name: str
 description: str
 domain: str
 sub_domain: str
 affects_individuals_rights: bool
 user_facing: bool
 makes_automated_decisions: bool

def classify_risk(app: LLMApplication) -> RiskTier:
 """
 Classify an LLM application under the EU AI Act.
 This is a simplified heuristic; consult legal counsel
 for binding classification.
 """
 # Check for prohibited uses
 prohibited_indicators = [
 "social_scoring",
 "subliminal_manipulation",
 "real_time_biometric_identification",
 ]
 if app.sub_domain in prohibited_indicators:
 return RiskTier.PROHIBITED

 # Check for high-risk domains (Annex III)
 for domain, sub_domains in HIGH_RISK_DOMAINS.items():
 if app.domain == domain and app.sub_domain in sub_domains:
 if app.makes_automated_decisions:
 return RiskTier.HIGH_RISK

 # User-facing AI requires transparency
 if app.user_facing:
 return RiskTier.LIMITED_RISK

 return RiskTier.MINIMAL_RISK

# Example classifications
apps = [
 LLMApplication(
 "ResumeScreener", "Filters job applications",
 "employment", "recruitment",
 affects_individuals_rights=True, user_facing=False,
 makes_automated_decisions=True,
 ),
 LLMApplication(
 "CustomerBot", "Answers product questions",
 "retail", "customer_support",
 affects_individuals_rights=False, user_facing=True,
 makes_automated_decisions=False,
 ),
 LLMApplication(
 "CodeAssistant", "Suggests code completions",
 "engineering", "development_tools",
 affects_individuals_rights=False, user_facing=True,
 makes_automated_decisions=False,
 ),
]

for app in apps:
 tier = classify_risk(app)
 print(f"{app.name}: {tier.value}")

Code 32.9.1: Simplified risk classification for LLM applications. Production classification requires legal analysis of the specific deployment context; this code illustrates the decision logic, not a legally binding tool.

2. High-Risk System Requirements

If your LLM application is classified as high-risk, the EU AI Act imposes six categories of requirements. Each translates into specific engineering tasks:

2.1 Risk Management System (Article 9)

You must establish and maintain a risk management system throughout the AI system's lifecycle. This includes identifying foreseeable risks (the red teaming from Section 32.8 directly supports this), estimating their likelihood and severity, adopting risk mitigation measures, and documenting residual risks with their acceptable thresholds. The risk management system must be a living document, updated when the model is retrained, when new deployment contexts are added, or when new vulnerabilities are discovered.

2.2 Data Governance (Article 10)

Training, validation, and testing datasets must be subject to appropriate data governance practices. For LLM applications, this means documenting the data sources used during fine-tuning (the pretraining data is typically the GPAI provider's responsibility), the preprocessing steps applied, any data augmentation or synthetic data generation (covered in Chapter 13), and the measures taken to detect and mitigate bias in the training data.

2.3 Technical Documentation (Article 11)

You must produce technical documentation before placing the system on the market. This documentation must include a general description of the AI system, its intended purpose, the design specifications, the development process, the monitoring and control mechanisms, the accuracy and robustness metrics, and the cybersecurity measures in place.

# Template for EU AI Act technical documentation
from dataclasses import dataclass, field
from datetime import date

@dataclass
class TechnicalDocumentation:
 """
 EU AI Act Article 11 technical documentation template.
 Annex IV specifies required contents.
 """
 # Section 1: General description
 system_name: str = ""
 version: str = ""
 intended_purpose: str = ""
 intended_users: list[str] = field(default_factory=list)
 geographic_scope: list[str] = field(default_factory=list)
 risk_classification: str = ""
 date_prepared: date = field(default_factory=date.today)

 # Section 2: Development process
 design_specifications: str = ""
 model_architecture: str = ""
 base_model_provider: str = ""
 fine_tuning_methodology: str = ""
 training_data_description: str = ""
 training_data_sources: list[str] = field(default_factory=list)
 preprocessing_steps: list[str] = field(default_factory=list)
 bias_mitigation_measures: list[str] = field(default_factory=list)

 # Section 3: Monitoring and testing
 evaluation_metrics: dict[str, float] = field(default_factory=dict)
 test_datasets_description: str = ""
 red_team_results_summary: str = ""
 known_limitations: list[str] = field(default_factory=list)
 residual_risks: list[str] = field(default_factory=list)

 # Section 4: Cybersecurity
 security_measures: list[str] = field(default_factory=list)
 guardrails_description: str = ""
 input_validation: str = ""
 output_filtering: str = ""

 # Section 5: Human oversight
 human_oversight_measures: str = ""
 override_mechanisms: str = ""
 escalation_procedures: str = ""

 def completeness_check(self) -> dict[str, bool]:
 """Check which required sections are filled in."""
 checks = {
 "system_name": bool(self.system_name),
 "intended_purpose": bool(self.intended_purpose),
 "risk_classification": bool(self.risk_classification),
 "model_architecture": bool(self.model_architecture),
 "training_data": bool(self.training_data_description),
 "evaluation_metrics": bool(self.evaluation_metrics),
 "known_limitations": bool(self.known_limitations),
 "security_measures": bool(self.security_measures),
 "human_oversight": bool(self.human_oversight_measures),
 }
 return checks

 def compliance_score(self) -> float:
 """Percentage of required fields completed."""
 checks = self.completeness_check()
 return sum(checks.values()) / len(checks)

# Example usage
doc = TechnicalDocumentation(
 system_name="MedAssist Pro",
 version="2.1.0",
 intended_purpose=(
 "Assist healthcare providers in triaging patient "
 "symptoms by suggesting possible conditions and "
 "recommended next steps. Does NOT provide diagnoses."
 ),
 risk_classification="high_risk",
 model_architecture="Fine-tuned Llama 3.1 70B with "
 "medical domain adapter (LoRA rank 32)",
 training_data_description="Fine-tuned on 50K curated "
 "medical consultation transcripts",
 evaluation_metrics={
 "triage_accuracy": 0.94,
 "harmful_advice_rate": 0.001,
 "refusal_rate_on_out_of_scope": 0.97,
 },
 known_limitations=[
 "Limited accuracy for rare conditions (<0.1% prevalence)",
 "May produce less accurate triage for pediatric patients",
 "Non-English language support is experimental",
 ],
 security_measures=[
 "Input sanitization against prompt injection",
 "Output guardrails for medication dosage claims",
 "Rate limiting per user session",
 ],
 human_oversight_measures=(
 "All triage suggestions are reviewed by a licensed "
 "healthcare provider before being acted upon. System "
 "displays confidence scores and flags low-confidence "
 "suggestions for mandatory human review."
 ),
)

print(f"Documentation completeness: {doc.compliance_score():.0%}")
for field_name, complete in doc.completeness_check().items():
 status = "PASS" if complete else "MISSING"
 print(f" [{status}] {field_name}")

Code 32.9.2: Technical documentation template aligned with EU AI Act Article 11 and Annex IV requirements. Automated completeness checking helps ensure no required section is overlooked before submission.

2.4 Record-Keeping and Logging (Article 12)

High-risk systems must automatically log events relevant to their operation. For LLM applications, this means logging all inputs and outputs (or representative samples for high-volume systems), the model version and configuration used, any guardrail interventions (inputs blocked, outputs filtered), latency and resource consumption metrics, and any errors or anomalies. The observability infrastructure described in Section 29.5 provides the technical foundation for meeting this requirement.

2.5 Transparency and User Information (Article 13)

High-risk systems must be designed to be sufficiently transparent to enable users to interpret the system's output and use it appropriately. For LLM applications, this means providing clear documentation of the system's capabilities and limitations, displaying confidence indicators where appropriate, and explaining how the system's output should (and should not) be used.

2.6 Human Oversight (Article 14)

High-risk AI systems must be designed to allow effective human oversight. This includes the ability for a human operator to understand the system's capabilities and limitations, correctly interpret the outputs, decide when to override or disregard the system, and intervene or interrupt the system's operation. For agentic LLM systems (covered in Chapter 22), this means implementing kill switches, confirmation gates for consequential actions, and audit trails for all autonomous decisions.

3. General-Purpose AI Model (GPAI) Obligations

The EU AI Act introduces specific rules for providers of general-purpose AI models, meaning the foundation model providers (OpenAI, Anthropic, Meta, Google, Mistral, etc.) rather than the downstream deployers. If you are fine-tuning and deploying a model, you are a "deployer" and your obligations are those described above. The GPAI provider has separate obligations:

All GPAI providers must: maintain technical documentation about the model, provide information and documentation to downstream deployers, establish a policy to comply with EU copyright law, and publish a sufficiently detailed summary of the training data content.

GPAI models with systemic risk (those trained with more than 10²⁵ FLOPs of compute, or designated by the Commission) face additional obligations: conduct model evaluations including adversarial testing, assess and mitigate systemic risks, ensure cybersecurity protections, and report serious incidents to the AI Office.

Figure 32.9.2: GPAI model obligations under the EU AI Act. All general-purpose AI model providers must meet base obligations (documentation, copyright compliance). Models exceeding the systemic risk threshold face additional requirements including adversarial testing and incident reporting.

4. Comparing Regulatory Frameworks

The EU AI Act does not exist in isolation. Organizations deploying LLM applications globally must navigate multiple regulatory frameworks simultaneously. The three most relevant are:

Table 32.9.1: Comparison of major AI governance frameworks. Organizations serving the EU market must comply with the AI Act; NIST and ISO compliance is voluntary but can support AI Act conformity assessment.

5. Implementation Timeline and Practical Milestones

The EU AI Act uses a phased enforcement timeline. Understanding the deadlines is essential for planning your compliance roadmap:

February 2025: Prohibitions on banned AI practices take effect. If your application falls under prohibited uses, you must discontinue it.

August 2025: GPAI model obligations take effect. Foundation model providers must comply with transparency, documentation, and copyright requirements. Systemic risk models face additional obligations.

August 2026: High-risk system requirements take effect for most categories. Deployers of high-risk LLM applications in Annex III domains must have their conformity assessment, technical documentation, risk management, and human oversight measures in place.

August 2027: Requirements for high-risk AI systems that are safety components of products (medical devices, vehicles, etc.) take effect.

6. Automated Compliance Checking

Manual compliance audits are expensive and error-prone. Automated compliance checking tools can continuously verify that your LLM application meets regulatory requirements. The following framework integrates compliance checks into your existing CI/CD pipeline (building on the security testing integration from Section 32.8):

# Automated EU AI Act compliance checker
from dataclasses import dataclass
from enum import Enum
from pathlib import Path
import json

class ComplianceStatus(Enum):
 COMPLIANT = "compliant"
 NON_COMPLIANT = "non_compliant"
 NEEDS_REVIEW = "needs_review"

@dataclass
class ComplianceCheck:
 article: str
 requirement: str
 status: ComplianceStatus
 evidence: str
 remediation: str = ""

def check_transparency_obligations(app_config: dict) -> ComplianceCheck:
 """Article 13: Check that AI disclosure is present."""
 has_disclosure = app_config.get("ai_disclosure_enabled", False)
 disclosure_text = app_config.get("ai_disclosure_text", "")

 if has_disclosure and len(disclosure_text) > 20:
 return ComplianceCheck(
 article="Article 13",
 requirement="Users informed of AI interaction",
 status=ComplianceStatus.COMPLIANT,
 evidence=f"Disclosure text: '{disclosure_text[:80]}...'",
 )
 return ComplianceCheck(
 article="Article 13",
 requirement="Users informed of AI interaction",
 status=ComplianceStatus.NON_COMPLIANT,
 evidence="AI disclosure not configured or text too short",
 remediation="Add ai_disclosure_enabled=true and meaningful "
 "disclosure text to application config",
 )

def check_logging_requirements(
 log_config: dict,
) -> ComplianceCheck:
 """Article 12: Verify automatic logging is configured."""
 required_fields = [
 "input_logging", "output_logging",
 "model_version_logging", "guardrail_event_logging",
 ]
 missing = [f for f in required_fields if not log_config.get(f)]

 if not missing:
 return ComplianceCheck(
 article="Article 12",
 requirement="Automatic event logging",
 status=ComplianceStatus.COMPLIANT,
 evidence=f"All {len(required_fields)} required log "
 f"streams configured",
 )
 return ComplianceCheck(
 article="Article 12",
 requirement="Automatic event logging",
 status=ComplianceStatus.NON_COMPLIANT,
 evidence=f"Missing log streams: {', '.join(missing)}",
 remediation=f"Enable logging for: {', '.join(missing)}",
 )

def check_human_oversight(app_config: dict) -> ComplianceCheck:
 """Article 14: Verify human oversight mechanisms."""
 has_kill_switch = app_config.get("kill_switch_enabled", False)
 has_escalation = app_config.get("escalation_path", "")
 has_override = app_config.get("human_override_enabled", False)

 mechanisms = sum([has_kill_switch, bool(has_escalation), has_override])
 if mechanisms >= 2:
 return ComplianceCheck(
 article="Article 14",
 requirement="Human oversight mechanisms",
 status=ComplianceStatus.COMPLIANT,
 evidence=f"{mechanisms}/3 oversight mechanisms active",
 )
 return ComplianceCheck(
 article="Article 14",
 requirement="Human oversight mechanisms",
 status=ComplianceStatus.NON_COMPLIANT,
 evidence=f"Only {mechanisms}/3 oversight mechanisms active",
 remediation="Enable kill_switch, escalation_path, and "
 "human_override in application config",
 )

def run_compliance_suite(
 app_config: dict,
 log_config: dict,
) -> list[ComplianceCheck]:
 """Run all compliance checks and return results."""
 checks = [
 check_transparency_obligations(app_config),
 check_logging_requirements(log_config),
 check_human_oversight(app_config),
 ]

 # Print report
 for check in checks:
 icon = {
 ComplianceStatus.COMPLIANT: "PASS",
 ComplianceStatus.NON_COMPLIANT: "FAIL",
 ComplianceStatus.NEEDS_REVIEW: "REVIEW",
 }[check.status]
 print(f"[{icon}] {check.article}: {check.requirement}")
 print(f" Evidence: {check.evidence}")
 if check.remediation:
 print(f" Fix: {check.remediation}")
 print()

 return checks

Code 32.9.3: Automated compliance checking framework. Each check maps to a specific EU AI Act article, provides evidence for auditors, and generates remediation guidance when non-compliant.

7. Conformity Assessment Procedures

High-risk AI systems must undergo conformity assessment before being placed on the EU market. For most LLM applications (those not embedded in regulated products like medical devices), this is a self-assessment performed by the provider or deployer. The assessment verifies that all requirements from Articles 9-15 are met and produces a Declaration of Conformity that must be kept for 10 years.

The conformity assessment draws together everything covered in this section and the previous one: risk management documentation (Article 9), data governance records (Article 10), technical documentation (Article 11, Code 32.9.2), logging configuration (Article 12), transparency measures (Article 13), human oversight mechanisms (Article 14), and accuracy/robustness testing results (Article 15, supported by the red teaming from Section 32.8).

For AI systems that are safety components of products already subject to EU conformity assessment (medical devices under MDR, machinery under the Machinery Regulation), the AI Act requirements are integrated into the existing conformity assessment process. A third-party notified body conducts the assessment, which is more rigorous and expensive than self-assessment.

8. Practical Compliance Checklists

The following checklists summarize the key compliance tasks by role:

For deployers of high-risk LLM applications:

• Classify your application's risk tier based on its domain and decision-making role
• Obtain GPAI provider's technical documentation and training data summary
• Implement input/output logging with sufficient retention (minimum period to be set by national authorities)
• Implement human oversight mechanisms (escalation paths, override capabilities, kill switch)
• Conduct or commission red team evaluation covering the attack categories from Section 32.8
• Produce technical documentation per Article 11 / Annex IV
• Implement AI disclosure for end users (transparency obligation)
• Establish ongoing monitoring and periodic re-evaluation schedule
• Complete conformity assessment and produce Declaration of Conformity
• Register the system in the EU AI database (when registration opens)

For GPAI model providers:

• Produce and maintain model technical documentation
• Provide documentation to downstream deployers upon request
• Publish training data content summary
• Establish copyright compliance policy
• For systemic risk models: conduct and publish model evaluations, implement adversarial testing, report serious incidents

9. Governance and Compliance-as-Code

The EU AI Act does not exist in isolation. Organizations deploying LLMs must navigate a growing landscape of AI governance frameworks. Three frameworks deserve particular attention because they provide structured, auditable processes that complement the EU AI Act's requirements.

7.1 NIST AI Risk Management Framework (AI RMF 1.0)

Published in January 2023 as NIST AI 100-1, the AI RMF organizes AI risk management into four core functions, each containing categories and subcategories of activities:

1. Govern: Establish policies, roles, and accountability structures for AI risk management. Define risk tolerances, assign ownership of AI systems, and ensure organizational culture supports responsible AI practices.
2. Map: Identify and document the context in which the AI system operates. Catalog intended uses, known limitations, stakeholder impacts, and interdependencies with other systems.
3. Measure: Assess and analyze AI risks using quantitative and qualitative methods. Run bias evaluations, red team exercises, and performance benchmarks. Track risks over time with metrics and thresholds.
4. Manage: Prioritize and act on identified risks. Implement mitigations, allocate resources, establish incident response plans, and continuously monitor deployed systems.

The Generative AI Profile (NIST AI 600-1, published 2024) extends the base framework with specific guidance for LLMs, including risks around hallucination, prompt injection, data provenance, and environmental impact. Organizations that implement the AI RMF find it significantly easier to satisfy EU AI Act requirements because both frameworks share common principles of documentation, testing, and ongoing monitoring.

7.2 ISO 42001 and NIST SSDF for ML Systems

ISO/IEC 42001:2023 (AI Management System) provides a certifiable management system standard for organizations developing or deploying AI. It follows the ISO management system structure (Plan-Do-Check-Act) and requires formal risk assessment, objective setting, competency management, and internal auditing. For LLM teams, ISO 42001 certification signals to customers and regulators that your organization has systematic AI governance in place.

NIST SSDF (Secure Software Development Framework, SP 800-218) applies to ML systems as much as traditional software. Key adaptations for LLM projects include: maintaining provenance records for training data (not just source code), securing model artifact storage with integrity checks, running adversarial testing as part of the release process, and documenting known model limitations alongside traditional software vulnerabilities.

7.3 Regulatory Mapping

The table below maps common regulatory requirements to the technical controls that satisfy them and the evidence artifacts that demonstrate compliance during an audit.

7.4 Compliance-as-Code in Practice

Compliance-as-code treats regulatory obligations as automated checks that run in your CI/CD pipeline, producing machine-readable evidence on every build. Instead of a compliance team manually reviewing a spreadsheet before release, the pipeline enforces policies and generates audit artifacts automatically.

# Example: Compliance-as-code checks in a CI/CD pipeline
# This runs as a GitHub Actions step or similar CI job

from dataclasses import dataclass

@dataclass
class ComplianceCheck:
 name: str
 framework: str # "EU_AI_ACT", "NIST_AI_RMF", "ISO_42001"
 requirement_id: str # e.g., "Art.9", "MAP-1.1", "8.3"
 passed: bool
 evidence_path: str # Path to the generated artifact

def run_compliance_gate(model_version: str) -> list[ComplianceCheck]:
 """Run all compliance checks and return results."""
 checks = []

 # Check 1: Model card exists and is current
 checks.append(ComplianceCheck(
 name="Model card generated",
 framework="EU_AI_ACT", requirement_id="Art.11",
 passed=model_card_exists(model_version),
 evidence_path=f"artifacts/{model_version}/model_card.json",
 ))

 # Check 2: Bias evaluation completed with passing thresholds
 bias_results = load_bias_results(model_version)
 checks.append(ComplianceCheck(
 name="Bias evaluation within thresholds",
 framework="NIST_AI_RMF", requirement_id="MEASURE-2.6",
 passed=all(r["disparity"] < 0.1 for r in bias_results),
 evidence_path=f"artifacts/{model_version}/bias_report.json",
 ))

 # Check 3: Red team evaluation completed
 checks.append(ComplianceCheck(
 name="Red team evaluation completed",
 framework="EU_AI_ACT", requirement_id="Art.9",
 passed=red_team_report_exists(model_version),
 evidence_path=f"artifacts/{model_version}/red_team.json",
 ))

 # Check 4: Artifact signatures verified
 checks.append(ComplianceCheck(
 name="Model artifact signatures valid",
 framework="NIST_SSDF", requirement_id="PW.6",
 passed=verify_signatures(model_version),
 evidence_path=f"artifacts/{model_version}/signatures.json",
 ))

 return checks

def enforce_gate(checks: list[ComplianceCheck]) -> bool:
 """Block deployment if any required check fails."""
 failed = [c for c in checks if not c.passed]
 if failed:
 for c in failed:
 print(f"FAILED: [{c.framework} {c.requirement_id}] {c.name}")
 return False
 print(f"All {len(checks)} compliance checks passed.")
 return True