EU AI Act Deepdive

Framework Deepdive

Summary

1. Overview

What the EU AI Act Is

Regulation (EU) 2024/1689, commonly called the EU AI Act, is the world's first comprehensive horizontal regulation of artificial intelligence. It entered into force on 1 August 2024 with phased application: prohibited practices (Article 5) and AI literacy obligations (Article 4) from 2 February 2025; general-purpose AI model obligations (Chapter V) from 2 August 2025; the bulk of high-risk obligations (Article 6 / Annex III) from 2 August 2026; and high-risk systems embedded in regulated products (Annex I) from 2 August 2027. The full consolidated text is published in the Official Journal at eur-lex.europa.eu.

Who It Applies To

The Act applies extraterritorially. It binds providers placing AI systems on the EU market, deployers using AI systems in the EU, importers and distributors, and any provider or deployer outside the EU whose system outputs are used in the Union. This is broader than GDPR in scope of obligation, narrower in scope of subject matter.

Risk Tiers

Prohibited AI practices (Article 5) — social scoring by public authorities, real-time remote biometric identification in public spaces (with narrow exceptions), exploitation of vulnerabilities, predictive policing based solely on profiling, untargeted facial-image scraping, emotion inference in workplaces and education.
High-risk AI systems (Article 6, Annex III) — eight defined areas including biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, administration of justice and democratic processes.
Limited-risk AI systems — transparency obligations (Article 50): inform users when interacting with AI, label deepfakes, disclose synthetic content.
Minimal-risk AI systems — no specific obligations beyond voluntary codes.
General-purpose AI (GPAI) models (Chapter V) — separate regime; additional obligations for GPAI with systemic risk (Article 51 thresholds, currently 10^25 cumulative training FLOPs).

Outcome

For most high-risk providers, the Act requires a conformity assessment (Article 43), CE marking, registration in the EU database, and post-market monitoring (Article 72). For deployers, obligations include fundamental rights impact assessment (Article 27) for certain Annex III systems, human oversight, monitoring, and incident reporting.

Security Consultants supports clients through the EU AI Act compliance service, frequently paired with our ISO 42001 AI management system implementation. For the practical case for stacking AI governance on top of an existing ISMS, see our deep-dive blog post How to integrate ISO 42001 with ISO 27001 without rebuilding your ISMS.

2. Scope & Applicability

Material Scope

An "AI system" under Article 3(1) is a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness, and that infers from inputs how to generate outputs (predictions, content, recommendations, decisions) that can influence physical or virtual environments. The European Commission published guidelines clarifying this definition in February 2025.

Annex III High-Risk Areas

Biometric categorization, emotion recognition (outside the prohibited contexts), remote biometric identification
Critical infrastructure (digital, road traffic, water, gas, heating, electricity)
Education and vocational training (admission, evaluation, monitoring)
Employment, workers management, access to self-employment (recruitment, performance, allocation of tasks, monitoring)
Access to essential private and public services (credit scoring, public benefits, emergency services dispatch, insurance pricing for life and health)
Law enforcement (within scope of Union competence)
Migration, asylum, border control
Administration of justice and democratic processes

Article 6(3) Derogation

A system that would otherwise fall in Annex III is not high-risk if it does not pose a significant risk of harm. The provider must document and justify this derogation. The European AI Office is expected to publish further guidance.

Provider vs Deployer

Provider — develops or has developed an AI system and places it on the market or puts it into service under its own name. Heaviest obligation set.
Deployer — uses an AI system under its authority, other than for personal non-professional activity. Obligations include human oversight, monitoring, fundamental rights impact assessment in defined cases, and incident reporting.
Importer, Distributor, Product Manufacturer, Authorized Representative — each have defined accountability under Articles 22–27.

GPAI Models

Models trained on broad datasets capable of general tasks are GPAI. From 2 August 2025, providers face documentation, copyright, and transparency obligations. Models exceeding the Article 51 systemic-risk threshold (currently 10^25 cumulative training FLOPs) face additional model evaluation, adversarial testing, incident reporting, and cybersecurity obligations under Article 55. The EU AI Office co-developed a Code of Practice for GPAI, finalized in mid-2025.

3. Core Principles

The Act builds on seven principles drawn from the High-Level Expert Group's Ethics Guidelines: human agency and oversight; technical robustness and safety; privacy and data governance; transparency; diversity, non-discrimination and fairness; societal and environmental wellbeing; accountability. These principles map to the operational obligations in Title III for high-risk systems.

Key operational principles for high-risk providers:

Risk management is an iterative, lifecycle process (Article 9)
Data governance must address relevance, representativeness, errors, and bias (Article 10)
Technical documentation must be maintained current (Article 11, Annex IV)
Logging is built-in by design (Article 12)
Transparency to deployers includes intended purpose, performance characteristics, and human oversight measures (Article 13)
Human oversight is designed in (Article 14)
Accuracy, robustness, and cybersecurity are validated and maintained (Article 15)

4. Control Breakdown

Article 9 — Risk Management System

Purpose: Identify, estimate, evaluate, and mitigate risks to health, safety, and fundamental rights across the AI lifecycle.
Minimum Expectations: Documented methodology; pre- and post-mitigation residual risk; testing including against reasonably foreseeable misuse; continuous update through post-market monitoring.
Evidence: Risk register, mitigation log, residual risk acceptance, periodic review records.

Article 10 — Data and Data Governance

Purpose: Ensure training, validation, and testing datasets are fit for purpose.
Minimum Expectations: Data provenance documentation, relevance and representativeness analysis, bias detection and mitigation, data quality controls, processing of special categories under Article 10(5) where strictly necessary.
Evidence: Data sheets, statistical bias reports, data preparation records.
Common Gaps: No formal record of dataset sourcing or annotation provenance; bias testing limited to a single demographic axis.

Article 11 — Technical Documentation

Purpose: Demonstrate compliance for conformity assessment.
Minimum Expectations: Documentation per Annex IV covering system description, design specifications, development methodology, training data, validation, deployment, post-market monitoring, change control.
Evidence: Technical file, version-controlled documentation, traceability matrix.

Article 12 — Record-keeping (Logging)

Purpose: Enable post-market monitoring and incident investigation.
Minimum Expectations: Automatic logging across the operational lifetime; minimum content for remote biometric ID systems specified in Article 12(2); retention period appropriate to intended purpose and at least six months for the deployer.
Evidence: Log inventory, retention policy, sample log exports.

Article 13 — Transparency to Deployers

Purpose: Equip deployers to use the system appropriately.
Minimum Expectations: Instructions for use covering intended purpose, accuracy and performance metrics, known limitations, human oversight measures, computational resources, expected lifetime, maintenance.
Evidence: Published instructions for use, model card, performance summary.

Article 14 — Human Oversight

Purpose: Ensure a natural person can monitor and intervene.
Minimum Expectations: Oversight measures designed in by the provider; documented in instructions for use; deployer implements them in operation.
Evidence: Oversight procedure, training records for operators, override logs.

Article 15 — Accuracy, Robustness, Cybersecurity

Purpose: Maintain operational reliability and security.
Minimum Expectations: Accuracy levels declared in instructions; resilience to errors, faults, inconsistencies, adversarial attacks (data poisoning, model evasion, prompt injection for generative systems), and confidentiality attacks; documented in technical documentation.
Evidence: Test reports, adversarial robustness assessments, vulnerability management records, penetration testing of AI inference pipelines. See our penetration testing service.

Articles 16–21 — Provider Obligations

Quality management system, technical documentation maintenance, registration in the EU database (Article 49), conformity assessment, EU declaration of conformity (Article 47), CE marking (Article 48), authorized representative if not established in the EU.

Articles 26–27 — Deployer Obligations

Operate per instructions, assign competent human oversight, monitor operation, log retention, inform provider of incidents and risks, conduct a Fundamental Rights Impact Assessment (Article 27) for certain Annex III public services and credit scoring contexts.

Article 43 — Conformity Assessment

For most Annex III systems, internal control by the provider (Annex VI). For biometric identification systems and Annex I product-embedded systems, third-party assessment by a Notified Body. Output: EU declaration of conformity and CE marking.

Articles 72–73 — Post-Market Monitoring and Incident Reporting

Providers maintain a post-market monitoring plan, collect operational data, document corrective actions. Serious incidents (Article 3(49)) and widespread infringements must be reported to the market surveillance authority within defined timelines (immediately for fatal incidents; not later than 15 days otherwise; shorter for incidents linked to fundamental rights infringement under Article 73(3)).

5. Minimum Requirements (Non-Negotiable)

Mandatory Documents

Annex IV technical documentation
Risk management documentation (Article 9)
Data governance and data sheets (Article 10)
Instructions for use (Article 13)
EU declaration of conformity (Article 47)
Quality management system documentation (Article 17)
Post-market monitoring plan (Article 72)
Incident reporting register
Fundamental Rights Impact Assessment template for deployers in defined contexts (Article 27)
For GPAI providers: model documentation per Annex XI; for systemic-risk GPAI: model evaluation reports, adversarial testing, cybersecurity assessment

Mandatory Processes

Lifecycle risk management with iterative review
Pre-deployment testing including adversarial robustness
Post-market monitoring with structured data collection
Serious incident reporting to the market surveillance authority
Conformity assessment before placing on the market or putting into service
AI literacy program for staff (Article 4)
Human oversight operating procedures

Technical Controls

Logging built into the system (Article 12)
Cybersecurity controls including adversarial robustness
Data quality and bias controls
Access control and audit logging for system operations
Monitoring of accuracy drift in production

6. Technical Implementation Guidance

Mapping to ISO 42001

The AI Management System defined in ISO/IEC 42001:2023 provides the governance backbone for AI Act compliance. Article 17 (quality management) maps to Clauses 5–10 of ISO 42001. Article 9 (risk management) maps to Clauses 6.1 and 8.2 of ISO 42001 plus the Annex A controls in A.5 (policies), A.6 (organization), and A.8 (AI lifecycle). The two are not interchangeable, but an ISO 42001-aligned program meets most of the documentation expectations of the AI Act. See our ISO 42001 service.

Privacy Overlap

AI systems processing personal data remain fully bound by GDPR. Article 10(5) of the AI Act permits processing of special-category data for bias correction under strict conditions. A DPIA under GDPR Article 35 should be performed where applicable and aligned with the FRIA where the deployer triggers Article 27. See our GDPR service and ISO 27701 service.

Data Governance

Maintain dataset provenance, including supplier or scraping records
Document annotation methodology and inter-annotator agreement metrics
Run bias diagnostics across protected and intersectional categories
Test on representative populations including edge cases relevant to the intended purpose

Adversarial Robustness

Threat-model the inference pipeline: data poisoning, evasion attacks, model extraction, membership inference, prompt injection for generative models
Apply input sanitization, output filtering, and rate limiting
For GPAI with systemic risk, document red-team evaluations against the Code of Practice methodology

Human Oversight

Implement override and stop functions
Train operators in the system's limitations and confidence indicators
Log oversight interventions for audit

Cybersecurity

Integrate the AI system into the existing ISMS (ISO 27001 or SOC 2 controls)
Threat-model model serving infrastructure and protect model weights and training data
Continuous monitoring of inference for anomalous patterns

7. Policy & Procedure Requirements

AI Policy (linking provider/deployer roles to governance)
Risk Management Procedure (Article 9)
Data Governance Standard (Article 10)
Technical Documentation Standard (Annex IV)
Logging and Monitoring Standard (Article 12)
Instructions for Use Template (Article 13)
Human Oversight Procedure (Article 14)
Cybersecurity for AI Standard (Article 15)
Post-Market Monitoring Plan (Article 72)
Serious Incident Reporting Procedure (Article 73)
AI Literacy Program (Article 4)
Fundamental Rights Impact Assessment Template (Article 27)
Quality Management System Procedure (Article 17)

For combined ISO 42001 + AI Act + ISO 27001 deployments, most documents serve all three. See our ISO 42001 service.

8. Audit Evidence & Verification

Audit and supervisory inspection by national market surveillance authorities can examine any documentation referenced above. Notified bodies inspect technical documentation, the QMS, and conformity assessment evidence where applicable.

Typical Evidence Categories

Risk management records: register, treatment, residual risk acceptance
Data governance records: data sheets, bias reports, dataset versioning
Technical documentation: Annex IV file, traceability matrix
Testing records: validation, robustness, adversarial, accuracy
Logging exports demonstrating compliance with Article 12
Incident register and serious-incident reports
Post-market monitoring data and trend analyses
FRIAs (deployers), DPIAs (where applicable)
QMS records including audits and management review

Common Remediation Items

Annex IV documentation not maintained current after model updates
Risk management treated as a one-off pre-launch exercise
Bias diagnostics absent or limited to one dimension
Cybersecurity assessment treats AI as a black box without adversarial robustness testing
FRIA and DPIA performed in isolation rather than coordinated

9. Implementation Timeline Considerations

Application Dates

2 February 2025: prohibited practices (Article 5) and AI literacy (Article 4) applicable
2 August 2025: GPAI obligations (Chapter V), governance, market surveillance framework operational
2 August 2026: full application to most high-risk systems (Annex III)
2 August 2027: high-risk systems embedded in Annex I products; grandfathered GPAI providers complete obligations

Typical Provider Program Duration

Annex III high-risk, mature ML practice: 6–9 months from gap analysis to conformity assessment readiness
Annex III high-risk, ad-hoc ML practice: 12–18 months including QMS implementation and Annex IV documentation backfill
GPAI systemic risk model: continuous — obligations are operational once the threshold is crossed

Typical Deployer Program Duration

3–6 months for a defined Annex III deployment including FRIA, operator training, and oversight procedure

10. Ongoing BAU Requirements

Post-market monitoring data collection and review
Serious incident reporting within statutory timelines
Annex IV documentation maintained current with model and data changes
Annual AI risk assessment refresh
Periodic adversarial robustness re-testing on production models
AI literacy training updated and refreshed annually
Conformity assessment refreshed on substantial modification (Article 43(4))
For GPAI systemic-risk providers: continuous model evaluation and incident reporting

11. Maturity Levels

Minimum Compliance

Inventory of in-scope AI systems and provider/deployer roles documented
Annex IV technical documentation maintained
Risk management procedure in place
Instructions for use published
Incident reporting channel established

Intermediate

Integrated AI management system aligned to ISO 42001
Automated data governance: provenance tracking, data quality monitoring
Adversarial robustness testing in CI/CD for model updates
FRIA integrated with DPIA where personal data is involved

Advanced

Continuous post-market monitoring with statistical drift detection
Combined ISO 27001 + ISO 27701 + ISO 42001 + AI Act evidence collection
Real-time bias and fairness monitoring with alerting
Mature GPAI code-of-practice alignment and external red-team participation

12. FAQs

When does the AI Act start to bite?

It already does. Prohibited practices have been in force since 2 February 2025. GPAI provider obligations applied from 2 August 2025. Most high-risk obligations apply from 2 August 2026, and Annex I product-embedded high-risk from 2 August 2027.

Are we a provider or a deployer?

Provider obligations attach to whoever places the system on the market or puts it into service under their own name. If you take a third-party model, substantially modify it, or rebrand it, you may become a provider. If you use a system under your authority for professional purposes, you are a deployer. A single organization can be both for different systems.

What counts as a high-risk AI system?

Annex III systems in the eight defined areas, and systems embedded in Annex I-regulated products. A system in an Annex III area is not high-risk if it does not pose a significant risk of harm under Article 6(3), but this derogation must be documented.

Do we need a Notified Body?

For most Annex III systems, no — the provider performs an internal control under Annex VI. Notified Body assessment is required for biometric identification systems and for high-risk AI embedded in Annex I products, following the relevant sectoral conformity assessment routes.

What is a Fundamental Rights Impact Assessment?

The FRIA is a deployer obligation under Article 27, mandatory for public bodies and private operators in defined Annex III contexts (notably essential public services and credit scoring). It assesses risks to fundamental rights, impacted persons, monitoring measures, and complaint mechanisms.

How does the AI Act relate to ISO 42001?

ISO 42001 is the international management system standard for AI; the AI Act is binding EU regulation. ISO 42001 certification does not equal AI Act compliance, but an ISO 42001-aligned program delivers most of the documentation and governance that the AI Act requires of providers.

How does the AI Act relate to GDPR?

GDPR continues to apply to any AI system processing personal data. Article 10(5) of the AI Act permits processing of special-category data for bias correction under strict conditions. DPIA and FRIA should be coordinated.

What about general-purpose AI models?

From 2 August 2025, GPAI providers face documentation, copyright, and transparency obligations under Chapter V. Models exceeding the Article 51 threshold (currently 10^25 cumulative training FLOPs) face additional model evaluation, adversarial testing, incident reporting, and cybersecurity obligations.

What are the penalties?

Up to €35 million or 7 percent of worldwide annual turnover for prohibited-practice violations; up to €15 million or 3 percent for most other infringements; up to €7.5 million or 1 percent for supplying incorrect information.

What about generative AI deployed inside our business?

If you use a third-party generative model (such as a foundation model API) for internal productivity, you are a deployer. Limited-risk transparency obligations under Article 50 apply (label synthetic content, inform users they are interacting with AI). High-risk obligations apply only if the deployment falls into Annex III.

How does this relate to the AI Liability Directive?

The proposed AI Liability Directive is separate civil liability legislation. The AI Act is product regulation. The two together create a fuller liability framework. The Liability Directive remains in negotiation as of 2026.

13. Summary

The EU AI Act establishes a tiered, risk-based regulatory regime for artificial intelligence with extraterritorial reach. Compliance is built on lifecycle risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, and post-market monitoring. For most providers, the practical path is to build an ISO 42001-aligned AI management system, integrate it with the existing ISMS, and use that combined evidence base to support conformity assessment under Article 43.

To scope an engagement, book a call from the EU AI Act compliance service page, or talk to us about combining the AI Act with ISO 42001, GDPR, or ISO 27701 for a single integrated AI governance program.

Share this post