Core Scope: Timelines and Role Definitions
The AI Act, Regulation (EU) 2024/1689, sets risk-based rules that fall differently on AI developers and deployers depending on the specific use of the system. This index functions as a navigation hub: each entry states a technical obligation in a single line, identifies the legally liable party, and routes directly to the operational guide covering its implementation.
Statutory Deadlines and Entity Qualification
The regulation establishes distinct enforcement milestones across different risk tiers, with amended application timelines established under Regulation (EU) 2026/1744. Determining whether an engineering team acts as a provider or a deployer governs which downstream operational controls must be implemented.
| Regulatory Duty | Obligated Role | Statutory Timeline | Technical Implementation Guide |
|---|---|---|---|
| General AI Act enforcement across standard application tiers | All commercial entities | 2 August 2026 | See compliance timeline |
| Provider vs. deployer qualification test for API-based model consumption | Engineering leads and software architects | 2 August 2026 | AI Act: Provider vs. Deployer Role Test (publishing 24-25 September) |
| Substantial modification threshold triggering reclassification to provider status | Downstream engineering teams modifying upstream models | 2 August 2026 | AI Act: Provider vs. Deployer Role Test (publishing 24-25 September) |
Downstream teams consuming hosted model endpoints operate as deployers by default, provided they do not alter model weights or place the system under their own trademark.
High-Risk Classification and Prohibitions
The framework bans certain AI practices outright under Article 5, including social scoring, untargeted scraping of facial images, emotion inference in workplaces and education institutions, and biometric categorisation that deduces protected characteristics, alongside strict controls for systems classified as high-risk under Annex III. Engineering teams must determine whether their workload touches banned categories before evaluating technical requirements.
Classification Gates and Prohibited Categories
Prohibitions on manipulative systems and workplace emotion recognition took effect in February 2025, while high-risk classifications dictate mandatory quality management systems and pre-deployment conformity checks.
| Regulatory Duty | Obligated Role | Statutory Basis | Technical Implementation Guide |
|---|---|---|---|
| Verification that system architecture contains no prohibited practices | Providers and deployers | Article 5 (Enforced Feb 2025) | See prohibited practices checklist |
| Annex III high-risk classification audit for critical infrastructure, HR, and essential services | System architects and product teams | Article 6 & Annex III | AI Act: Annex III High-Risk Decision Tree (publishing 24-25 September) |
| High-risk safety component verification for regulated physical products | Hardware and embedded ML teams | Annex I harmonised legislation | AI Act: Annex III High-Risk Decision Tree (publishing 24-25 September) |
Systems falling outside Annex III categories generally avoid conformity assessment requirements, remaining subject only to horizontal transparency mandates.
General Purpose AI and Compute Thresholds
General Purpose AI (GPAI) models operate under dedicated rules for providers on technical documentation, copyright policy and a public training-content summary, with additional obligations where a model is classified as posing systemic risk. Upstream model developers carry the primary compliance burden, but teams executing large-scale fine-tuning runs risk inheriting provider status.
Foundation Models and Fine-Tuning Limits
Statutory duties scale based on whether a model presents systemic risk, measured by cumulative floating-point operations (FLOPs) utilized during training runs.
| Regulatory Duty | Obligated Role | Trigger Threshold | Technical Implementation Guide |
|---|---|---|---|
| GPAI technical documentation, training data summaries, and copyright compliance | Upstream model providers | All GPAI foundation models | See foundation model obligations |
| Systemic risk notification and mandatory adversarial testing protocols | Model developers | Training compute exceeding 10^25 FLOPs | See foundation model obligations |
| Fine-tuning compute audit to prevent involuntary reclassification as a GPAI provider | Teams fine-tuning open-weight models | Substantial retraining runs | AI Act: Fine-Tuning Compute Thresholds (published 22 September) |
Standard parameter-efficient fine-tuning (PEFT) and low-rank adaptation (LoRA) workflows remain well below systemic thresholds, preserving downstream deployer classification.
Article 50: Output Marking and Transparency
Article 50 enforces horizontal transparency mandates across generative AI systems, irrespective of their risk tier. Developers operating chatbots, synthetic media pipelines, or automated publication tools must implement programmatic disclosures and machine-readable provenance markers.
Synthetic Content Marking and User Disclosure
Mandates apply from 2 August 2026, requiring both visual user notifications and embedded provenance metadata across synthetic text, image, audio, and video streams.
| Regulatory Duty | Obligated Role | Technical Mechanism | Technical Implementation Guide |
|---|---|---|---|
| Direct interaction disclosure informing end-users they are communicating with an AI system | Providers of conversational interfaces | UI disclaimers at first interaction | AI Act: Article 50 Output Marking and Watermarking (publishing 24-25 September) |
| Machine-readable marking and provenance encoding on synthetic audio, image, and video outputs | Providers of generative AI systems | C2PA metadata and SynthID watermarking | AI Act: Article 50 Output Marking and Watermarking (publishing 24-25 September) |
| Labelling synthetic text published on matters of public interest | Deployers publishing generated text | Editorial review flags or visual labels | AI Act: Article 50 Output Marking and Watermarking (publishing 24-25 September) |
| Disclosure to individuals exposed to emotion recognition or biometric categorisation | Deployers of biometric systems | Prior notice to affected individuals | AI Act: Article 50 Output Marking and Watermarking (publishing 24-25 September) |
Assistive editing systems that do not substantially alter underlying semantics remain exempt from machine-readable watermarking obligations.
Annex IV Documentation and DPIAs
High-risk AI systems must carry technical documentation drawn up before the system is placed on the market, giving national authorities the information needed to assess compliance, alongside a risk management system maintained across the lifecycle. Teams deploying models against personal data must simultaneously execute statutory Data Protection Impact Assessments.
Technical Files and Privacy Assessments
Engineering teams must assemble verifiable documentation covering model architecture, data lineage, algorithmic assumptions, and validation metrics.
| Regulatory Duty | Obligated Role and Application Date | Statutory Reference | Technical Implementation Guide |
|---|---|---|---|
| Assembly of Annex IV technical documentation files and system architecture records | Provider; Annex III systems apply from 2 December 2027, Annex I product-embedded systems from 2 August 2028 | Article 11 & Annex IV | AI Act: Annex IV Technical Documentation Guide (published 21 September) |
| Lifecycle risk management system implementation and residual risk monitoring | Provider; Annex III systems apply from 2 December 2027, Annex I product-embedded systems from 2 August 2028 | Article 9 | AI Act: Annex IV Technical Documentation Guide (published 21 September) |
| Data Protection Impact Assessment (DPIA) for high-risk and LLM-driven inference pipelines | Deployer as controller; GDPR duty in application since 25 May 2018 | GDPR Article 35 / AI Act alignment | AI Act: Data Protection Impact Assessment for LLMs (published 21 September) |
Annex IV records must be maintained and held available for national market surveillance authorities for ten years after placing the system on the market.
Article 26: Logging and Conformity Audits
Deployers of high-risk AI systems must keep the logs the system automatically generates where those logs are under their control, assign human oversight to competent persons, and monitor the system in operation. Logging architectures must guarantee data integrity while satisfying statutory retention windows.
Operational Traceability and Audit Integrity
Article 26 mandates minimum retention periods for operational logs generated by high-risk systems under the deployer's direct technical control.
| Regulatory Duty | Obligated Role and Application Date | Retention Period | Technical Implementation Guide |
|---|---|---|---|
| Automated logging of high-risk AI system execution events and inference metadata | Deployer; Annex III systems apply from 2 December 2027 | Article 26(5) minimum retention window | AI Act: Deployer Logging and Retention Window (published 14 September) |
| Implementation of tamper-evident audit trails and cryptographic hash chains for event logs | Deployer; Annex III systems apply from 2 December 2027 | Active lifecycle duration | AI Act: Tamper-Evident Audit Trails and Hash Chains (publishing 24-25 September) |
| Conformity assessment execution and CE marking registration in the EU database | Provider; Annex III systems apply from 2 December 2027, Annex I product-embedded systems from 2 August 2028 | Pre-deployment milestone | AI Act: Conformity Assessment Guide (published 18 September) |
Inference logging pipelines must record prompt identifiers, execution timestamps, and model version strings without logging sensitive payload data unnecessarily.
Infrastructure Duties and GDPR Overlap
Deploying compliant AI workloads requires isolating infrastructure responsibilities between the cloud provider and the application layer. Infrastructure controls must reconcile EU AI Act governance with existing GDPR mandates GDPR overlap guide.
Compute Sovereignty and Platform Handoff
Technical teams must distinguish between legal data protection claims and physical hosting architectures when provisioning compute nodes.
| Governance Area | Infrastructure Responsibility | Compliance Intersection | Technical Implementation Guide |
|---|---|---|---|
| Data residency and processing location of each model you call | Infrastructure provider and deployer | GDPR Chapter V transfers, not an AI Act duty | See infrastructure requirements guide |
| Dual-framework compliance mapping for data lineage and training sets | Engineering and legal leads | GDPR Article 6 & AI Act Article 10 | See GDPR overlap guide |
| Retention of prompts and outputs at the inference layer | Inference platform, confirmed in writing in your DPA | GDPR storage limitation (Art. 5(1)(e)) | Ask your provider for its retention terms in the DPA |
Lyceum states zero data retention for Serverless Inference, meaning prompts and outputs are processed in volatile GPU memory rather than stored, a self-asserted position rather than an audited one. It holds no EU AI Act conformity statement or certification; engineering teams remain responsible for their own application-level compliance and should request the Data Processing Agreement, plus the processing region of every model they call, in writing.