EU AI Act: Regulatory Context, Timeline, and Compliance Architecture

The EU AI Act addresses a fundamental challenge that distinguishes AI systems from conventional software: temporal instability. A traditional application behaves tomorrow the way it behaves today unless someone deliberately changes it. An AI system is designed to improve through learning, and that learning introduces continuous change that conventional governance was never built to handle. Models are retrained on new data, feature distributions shift as the population served evolves, and fine-tuning adjusts behaviour in ways that may be subtle and difficult to document after the fact. The system that passed validation six months ago may no longer be the system running in production.

This temporal instability is what makes AI compliance fundamentally different from compliance for traditional software. A static application can be assessed once and maintained through periodic review. An AI system demands continuous evidence that it still behaves within documented boundaries, that its data inputs remain representative, that its performance across demographic subgroups has not degraded, and that its risk profile has not shifted. The documentation challenge is not to describe the system as it was built, but to maintain a living, traceable record of what the system is now and how it arrived there.

The AI Act (Regulation (EU) 2024/1689) is the first major regulatory framework to address this challenge at scale. It tells organisations what they must document but is largely silent on how. Articles 8 through 15 set out substantive requirements for high-risk systems. Annex IV specifies documentation contents. The gap between a regulatory requirement and an engineering workflow that satisfies it is where most compliance programmes stall, producing documentation that reads well on paper yet cannot withstand scrutiny because no traceable evidence supports its claims.

This gap is precisely where the Practitioners Implementation Guide operates. It translates every material obligation in the AI Act into concrete engineering practices, governance processes, and organisational structures. It addresses not only what each aisdp module must contain, but how to generate that content as a natural byproduct of the development lifecycle, how to verify it through internal conformity assessment, and how to maintain it through years of post-market operation until the system eventually reaches end-of-life. The AI Act imposes a documentation obligation that is fundamentally different from anything organisations have encountered before: one that must evolve continuously alongside the system it describes.

Article 8 serves as the umbrella provision binding all high-risk obligations together. It requires that high-risk AI systems comply with all Chapter 2 requirements as an integrated whole, taking into account the system's intended purpose and the generally acknowledged state of the art. Compliance with any individual article cannot be assessed in isolation. The conformity assessment must evaluate the system against the full set of requirements, and the AISDP's twelve-module structure reflects this integrative mandate. Each module addresses a specific requirement, but the modules are cross-referenced and interdependent.

The AI Act entered into force on 1 August 2024 with obligations phased across a staggered timeline. Understanding which provisions are already enforceable and which are pending is essential for planning aisdp preparation.

Already in force (February 2025). Prohibited practices under Article 5 took effect on 2 February 2025, banning subliminal manipulation, exploitation of vulnerable groups, social scoring, untargeted facial recognition scraping, emotion recognition in workplaces and educational institutions, criminal risk profiling, and real-time remote biometric identification in public spaces. Organisations operating systems that fall within any of these categories face immediate enforcement risk. The AISDP process cannot remediate a prohibited system; the only compliant action is cessation. AI literacy requirements under Article 4 also became enforceable on this date, requiring providers and deployers to ensure staff involved in AI operation have sufficient AI literacy. This obligation applies across all risk tiers and predates the high-risk framework.

Codes of practice for GPAI (since August 2024). Providers of gpai models were invited to participate in the Code of Practice drafting process under Article 56. The AI Office Code of Practice was finalised in early 2025 and provides a compliance pathway for GPAI providers. Organisations integrating GPAI models into high-risk systems should monitor the Code of Practice's evolution, as it establishes the expectations that national competent authorities will apply when assessing GPAI provider compliance.

The AI System Documentation Package is the operational expression of the Article 11 obligation. Providers of high-risk AI systems must draw up technical documentation in accordance with Annex IV before the system is placed on the market or put into service. A competent authority examiner who has never seen the system should be able to understand its design, behaviour, risk profile, and compliance posture from the AISDP alone. That is the self-standing test, and meeting it requires sustained effort across every compliance domain.

The AISDP is the document a national competent authority will open first. It is the file a notified body will scrutinise for technical rigour. It is the reference that internal governance, legal counsel, and engineering teams will consult throughout the system's operational life. A deficient AISDP exposes the organisation to fines reaching EUR 15 million or 3% of global annual turnover, enforcement action, and reputational harm that may exceed any financial penalty. A well-constructed AISDP forces the organisation to know its own AI systems with a depth and precision that many have never attempted.

A full AISDP comprises twelve modules, each addressing a specific compliance dimension:

The AISDP sits within an ecosystem of six compliance artefacts that together form the complete evidentiary chain from risk classification through to market placement and ongoing monitoring.

The Classification Decision Record precedes the AISDP. It documents the system's classification within the AI Act's risk tiers and provides the rationale for that determination. The CDR addresses the four-tier risk classification under Article 6, the Annex III category determination, and the Article 6(3) exception assessment where applicable. AISDP Module 1 references the CDR as the authoritative source for risk classification. Without a current CDR, the AISDP lacks its foundational premise, and the entire compliance case is undermined.

The Evidence Pack substantiates every claim in the AISDP. Every material assertion, whether a performance metric, a fairness evaluation result, a security test finding, or a governance approval, must trace to a specific artefact in the evidence pack. The evidence register catalogues these artefacts and maps them to the AISDP modules they support. This traceability is what transforms the AISDP from a prose document into a defensible compliance record. Without it, the AISDP contains claims; with it, the AISDP contains evidence.

The Master Compliance Questionnaire provides systematic verification. It walks through every applicable AI Act requirement, prompting the assessor to confirm compliance and reference supporting evidence. The AISDP provides the substantive answers; the MCQ provides the structure that ensures nothing is missed. The MCQ is particularly valuable during internal review cycles, where it functions as a completeness check before the formal .

The AI Act creates overlapping obligations with four major EU legislative instruments that organisations must address in a unified compliance approach. Failure to recognise these overlaps leads to duplicated effort, inconsistent documentation, and gaps where no framework is clearly assigned responsibility.

GDPR (Regulation (EU) 2016/679) governs the processing of personal data used to train, validate, test, and operate AI systems. The AISDP's data governance module must demonstrate GDPR compliance alongside AI Act compliance. This encompasses lawful basis for training data processing under Article 6 GDPR, data subject rights in the context of AI-generated decisions, coordination between the Data Protection Impact Assessment (DPIA) required by GDPR Article 35 and the Fundamental Rights Impact Assessment (FRIA) required by AI Act Article 27, and data retention policies that satisfy both frameworks. Where a system processes special category data under Article 10(5) of the AI Act, the GDPR Article 9 conditions must also be documented. Data governance addresses GDPR alignment in detail, including the specific challenges of demonstrating lawful basis for historical training data and the GDPR status of stored embeddings in RAG architectures.

NIS2 Directive (Directive (EU) 2022/2555) imposes cybersecurity risk management requirements on essential and important entities. Organisations subject to NIS2 must integrate AI system cybersecurity controls with their broader NIS2 risk management measures. The overlap is particularly significant for incident reporting: NIS2 requires notification within 24 hours, while the AI Act's Article 73 serious incident reporting operates on a different timeline. Organisations subject to both must establish coordinated incident response procedures that satisfy both frameworks without conflict. Multi-regime incident reporting coordination is essential to avoid contradictory obligations.

The Practitioners Implementation Guide examines twenty-one interconnected domains across the full lifecycle of a high-risk AI system. Each domain addresses a distinct dimension of AISDP preparation; together they cover everything from initial risk classification through to archival of the final documentation package.

Foundation domains. Risk assessment establishes the four-tier classification, the FRIA, and the iterative risk management lifecycle. It covers five risk identification methods: FMEA, stakeholder consultation, regulatory gap analysis, adversarial red-teaming, and horizon scanning. Risk scoring and calibration, residual risk acceptability thresholds, and the particular challenges of assessing systems built on GPAI models are addressed, including the Article 25(3) information request framework. Model selection addresses compliance consequences of model choice, including origin risk, the fine-tuning provider boundary under Article 25, copyright and intellectual property exposure, geopolitical considerations, and provider data collection practices.

Engineering domains. Data governance covers Article 10 requirements including dataset documentation, completeness assessment, fairness and bias evaluation at both pre-training and post-training stages, data lineage, special category data under Article 10(5), and GDPR alignment. It extends to embedding model governance and knowledge base management for RAG architectures. System architecture structures documentation around an eight-layer reference model covering data ingestion, feature engineering, model inference, post-processing, explainability, human oversight interface, logging and audit, and monitoring. underpins traceability across the AISDP, including the composite version concept that captures every artefact type deployed at a given point in time. describe automation that produces compliance evidence as a development byproduct. extends CI/CD with five compliance gates: classification and scope, risk and fundamental rights, fairness and bias, documentation currency, and deployment authorisation. addresses Article 15 resilience alongside NIS2, CRA, and DORA obligations, including the OWASP LLM Top 10 and thirteen AI-specific threat categories.

The AI Act assigns obligations based on role, with each actor in the AI value chain bearing distinct responsibilities. Understanding which role applies to an organisation is the first step in determining the scope of its compliance obligations.

Providers are organisations that develop or place AI systems on the market under their own name or trademark. They bear the heaviest burden: conformity assessment, AISDP preparation, CE marking, Declaration of Conformity, EU database registration, quality management system establishment, and post-market monitoring. The provider is responsible for the entire technical documentation chain and for maintaining it for ten years after market placement. Where an organisation fine-tunes a GPAI model for a high-risk use case, it becomes a provider under Article 25(1)(b), triggering the full set of provider obligations regardless of whether it developed the underlying model.

deployers are organisations that use AI systems within the EU under their authority. Their obligations are lighter but still consequential: conducting fundamental rights impact assessments under Article 27, ensuring human oversight by competent persons under Article 14, monitoring system performance in accordance with the provider's guidance, reporting serious incidents to both the provider and market surveillance authorities, and maintaining logs for at least six months under Article 26(6). Public authority deployers face an additional obligation to register in the EU database under Article 49(3). addresses these obligations comprehensively, including the complete deployer compliance record structure covering eight modules.

The AI Act establishes a three-tier penalty structure that became enforceable from August 2025 for prohibited practices and applies fully from August 2026 for high-risk non-compliance. The penalty framework is designed to be proportionate yet deterrent, with maximum fines that rival those under GDPR.

Tier 1: Prohibited practices. Fines of up to EUR 35 million or 7% of global annual turnover, whichever is higher, for systems violating Article 5 prohibitions. This is the highest penalty tier in the AI Act and exceeds GDPR's maximum of EUR 20 million or 4% of turnover. The prohibited categories include subliminal manipulation, exploitation of vulnerable groups, social scoring by public authorities, untargeted facial recognition scraping, emotion recognition in workplaces and educational institutions, criminal risk profiling based solely on profiling, and real-time remote biometric identification in publicly accessible spaces. These penalties have been enforceable since August 2025.

Tier 2: High-risk non-compliance. Fines of up to EUR 15 million or 3% of global annual turnover for failure to comply with the requirements of Articles 6 through 51. This covers deficient conformity assessments, missing or inadequate Declarations of Conformity, incomplete AISPDs, failure to establish a quality management system under Article 17, and failure to implement post-market monitoring under Article 72. For deployers, the same maximum applies to failures in human oversight, FRIA completion, incident reporting, and cooperation with competent authorities.

Fines of up to EUR 7.5 million or 1% of global annual turnover for providing incorrect, incomplete, or misleading information to competent authorities or notified bodies. This tier catches organisations that misrepresent their compliance status, provide incomplete documentation during inspections, or fail to maintain accurate records. It applies to both providers and deployers.

Organisations should begin AISDP preparation immediately if they have not already started. The 20 to 28 week preparation timeline for a medium-complexity system means organisations need to be well under way by early 2026 to meet the August deadline. Brownfield compliance for systems already in production is typically more complex than greenfield preparation, as it requires retrospective documentation of decisions that were made without compliance in mind.

Prerequisites. A discovery exercise identifying all AI systems in the portfolio should be complete, with a Classification Decision Record for each system documenting its position within the AI Act's risk tiers. An evidence pack structure should be established, providing the organisational infrastructure for collecting, storing, and cataloguing the artefacts that substantiate AISDP claims. Governance roles should be assigned, including at minimum an AI Governance Lead, an AI System Assessor, and a Technical SME. Smaller organisations may combine roles, but the responsibilities must be explicitly allocated. A Quality Management System meeting Article 17 requirements should be in place at a foundational level, covering policies, procedures, responsibilities, and document control. The Technical SME and AI System Assessor must have direct access to the system's source code, training infrastructure, model artefacts, data stores, deployment configuration, and monitoring outputs.

Reading guide by role. The guide serves multiple audiences with distinct needs. AI Governance Leads should prioritise risk assessment, conformity assessment, and regulatory landscape sections, with particular attention to residual risk acceptability thresholds, non-conformity management, and Declaration of Conformity liability. Technical SMEs should focus on model selection, data governance, architecture, version control, and CI/CD, particularly the governance pipeline's five compliance gates and the composite version concept. Legal and Regulatory Advisors should focus on regulatory context, FRIA methodology, conformity assessment, penalty framework, and end-of-life regulatory basis. Conformity Assessment Coordinators should prioritise the Annex VI walkthrough, non-conformity register management, multi-system coordination, and registration workflow. DPO Liaisons should focus on GDPR alignment, special category data, and DPIA/FRIA coordination. Executive Leadership needs the strategic overview, penalty exposure, and cost model.