EU AI Act compliance playbook for product teams

Overview

The EU AI Act is a risk-based product safety regulation. It entered into force on 1 August 2024. Prohibitions take effect from February 2025, and general-purpose AI (GPAI) rules from August 2025. These dates appear in the European Commission’s overview and the Official Journal publication.

The Act allocates obligations by role (provider, deployer, importer, distributor). It empowers the EU AI Office for oversight. It also requires CE marking for high-risk AI to demonstrate conformity.

This playbook is for product, legal, data, quality, and security leaders accountable for implementation. It covers scope tests, risk classification, conformity routes and CE marking, Annex IV documentation, procurement essentials, and budgeting benchmarks. Each step includes references to authoritative sources for verification.

Who the EU AI Act applies to and extraterritorial scope

The Act applies to anyone placing AI systems or GPAI models on the EU market or putting them into service. It includes non-EU organizations when outputs are used in the EU. Territorial scope is extraterritorial: if your AI affects people in the EU, obligations can apply regardless of establishment, per the Commission’s summary.

Roles determine duties. A “provider” (often the developer or brand owner) is primarily responsible for conformity. “Deployers” (users) hold governance and transparency duties. “Importers” and “distributors” must verify documentation and labeling. Non-EU providers may appoint an authorised representative in the EU to manage regulatory correspondence and vigilance.

For example, a US speech-to-text vendor serving EU hospitals is a provider under the Act. It must comply even without an EU office. Map your roles per channel and appoint an EU representative where applicable.

Enforcement is coordinated by national market surveillance authorities and the AI Office for GPAI. Administrative fines can reach up to €35 million or 7% of global annual turnover for prohibited practices. Lower ceilings apply for SMEs and startups, and €15 million or 3% for other non-compliance, as defined in Regulation (EU) 2024/1689. Build your accountability map early. Assign provider/deployer/importer responsibilities and track which entity owns CE marking.

How to classify your system: unacceptable, high-risk, transparency obligations, or minimal risk

Classification follows four risk tiers set in the Act. Unacceptable risk systems are banned. High-risk systems require CE marking and comprehensive controls. Some systems carry transparency duties. The remainder are minimal risk with voluntary measures.

Make a first-pass scope test by use case, sector, and functionality. Then validate your result against the Act’s annexes.

Use this quick classification sequence:

• Unacceptable risk: practices banned outright (e.g., certain social scoring, manipulative techniques that materially distort behavior, some real-time biometric identification in public spaces outside narrow exceptions).
• High-risk: AI used as a safety component of regulated products (e.g., MDR/IVDR medical devices, Machinery) or in listed use cases (e.g., biometric identification, critical infrastructure safety, education and exams, employment and worker management, essential services access, law enforcement, migration/asylum, and administration of justice).
• Transparency obligations: systems that interact with humans, generate or manipulate image/audio/video (“deepfakes”), or involve emotion recognition or biometric categorization require notices/labelling and content provenance steps.
• Minimal risk: systems outside these categories, still encouraged to follow voluntary codes and good practices.

Borderlines matter. An AI that scores candidates for shortlisting in recruitment is typically high-risk. A chatbot that merely schedules interviews likely falls under transparency duties. Document your classification logic and link it to Annexes II and III for auditability. Pass it through regulatory counsel review before finalizing obligations and build plans.

Sector-specific edge cases and classification pitfalls

In health, a diagnostic triage model embedded in a radiology workflow is commonly a safety component of a medical device. This pulls you into high-risk obligations via MDR. A wellbeing chatbot offering general health tips without diagnosis may trigger transparency duties if it interacts with users. This is especially true where it might be mistaken for human advice.

In finance, fraud detection that gates access to essential services (e.g., payment or credit) can be high-risk due to potential denial of service. A back-office anomaly detector used solely for analyst triage may remain minimal risk.

In HR, automated ranking or scoring of candidates or workers is high-risk. Pure scheduling assistants are typically non-high-risk but may still require user disclosure.

In education, proctoring and automated grading used for significant assessments are high-risk. A study guide generator is more likely to carry transparency duties if it could be mistaken for a human tutor.

When in doubt, analyze the impact on rights and safety. Check whether the system is decisive for access to services or a safety component of a regulated product. Record the rationale in your technical file.

GPAI models: obligations, code of practice, and oversight

GPAI providers must meet transparency, documentation, and model-level governance obligations. Additional duties apply when models pose systemic risks. Oversight sits with the Commission’s EU AI Office, supported by an AI Board and scientific panels.

Core expectations for GPAI providers include:

• Prepare and publish a sufficiently detailed training data summary and technical documentation to enable downstream compliance, including usage policies and model capabilities/limitations.
• Implement policies to respect EU copyright and enable opt-outs consistent with the EU’s text and data mining exceptions.
• Provide interfaces and information enabling deployers of high-risk applications to satisfy Annex IV technical documentation and human oversight.
• For “systemic risk” models (very capable GPAI meeting thresholds set by the AI Office), implement risk management, cybersecurity, red-teaming, incident reporting, and compute/resource reporting; participate in Codes of Practice until harmonized standards are available.

Use the Codes of Practice shared by the Commission and AI Office as interim guidance. Transition to harmonized standards when cited in the Official Journal. Document GPAI controls with references to recognized AI standards (e.g., ISO/IEC JTC 1/SC 42). Maintain a changelog aligned with model releases.

Timelines, compliance windows, and transition planning

Obligations are staged to allow implementation. The Act entered into force on 1 August 2024. Prohibitions apply from February 2025. GPAI rules apply from August 2025. Most high-risk obligations, CE marking, and market surveillance follow longer transition windows defined in the text and Commission guidance.

Expect further guidance and standards through 2025–2026 as the AI Office and Member States stand up sandboxes and designate notified bodies. Plan remediation by mapping obligations to product release trains.

Freeze requirements and design decisions 6–9 months before high-risk launches. This allows for pre-release testing, data governance improvements, and Annex IV drafting. For GPAI, align public model cards and training data summaries with the August 2025 date. Backfill red-teaming evidence. Monitor national regulatory sandboxes and the Commission’s AI Pact to pilot controls early with supervisory feedback.

Conformity assessment in practice: choosing routes, CE marking, and post-market monitoring

Conformity assessment demonstrates EU AI Act compliance and enables CE marking for high-risk AI. Depending on use case and harmonized standards availability, you may self-assess or require a third-party notified body (NB). You must also maintain post-market monitoring with incident reporting for the lifecycle.

Choose your route by answering three questions.

Is your AI a safety component of a regulated product (e.g., under MDR/IVDR or Machinery) that already mandates third-party assessment? If yes, you will generally go through an NB with AI scope.

Are applicable, cited harmonized standards or common specifications fully applied? If yes, provider self-assessment under internal control may be possible for certain standalone high-risk AI, subject to legal conditions.

Does your system include novel or high-uncertainty risks (e.g., biometric identification, critical infrastructure, or no standards coverage)? If yes, expect third-party assessment.

After passing the assessment, affix CE marking, register where required, and maintain vigilance plans. Plan for periodic audits and change-controlled model updates.

Post-market monitoring is mandatory. Establish key risk indicators, human oversight effectiveness checks, drift monitoring, and an incident reporting process to competent authorities. When in doubt, consult the EU NANDO database of notified bodies for designations and scopes. Align your quality management system with the risk management and documentation cadence anticipated by Annex IV.

Notified bodies landscape and readiness

Notified bodies will be designated by Member States and listed in NANDO with explicit AI Act scopes. Many will build on existing product safety designations (e.g., MDR/IVDR, Machinery). Early in the regime, expect limited capacity and lead times measured in months. Bottlenecks are likely in biometrics, medical, and critical infrastructure, where specialist competence is needed.

Select an NB with domain experience, AI competence, and availability that matches your release plan. Ask about audit scope (documentation-only versus witnessing of tests), model update policies, and experience with ML lifecycle controls. Given likely bottlenecks, initiate scoping discussions 6–12 months before your target CE marking to avoid late-stage delays.

Annex IV technical documentation and data governance requirements

Annex IV is the technical file. It is a comprehensive, auditable record of how the system meets high-risk AI requirements. It must be complete before CE marking and maintained over the lifecycle.

Treat it as a single source of truth covering design intent, data, testing, risk controls, and human oversight.

Use this Annex IV checklist as your baseline:

• System overview: purpose, intended use, risk classification, deployment context, versions, release notes, and links to design documents.
• Data governance: dataset lineage, collection methods, representativeness metrics (e.g., demographic coverage by region/age/sex where relevant), data quality KPIs (missingness, label noise), provenance/consent handling, and retention/deletion controls.
• Training and tuning: architectures, training regimes, hyperparameters, evaluation splits, and reproducibility evidence; cite model cards and training data summaries for GPAI-derived components.
• Performance and bias testing: task-specific metrics (e.g., AUROC, F1, WER), subgroup disparity analyses (e.g., difference in false positive rates ≤ X%), robustness (stress/noise/shift tests), and uncertainty calibration results with thresholds.
• Risk management: identified hazards, misuse and adversarial scenarios, mitigations, residual risk rationale, and traceability to requirements; link to threat modeling, red-team results, and corrective actions.
• Human oversight: roles, escalation criteria, override controls, fallback procedures, and operator training materials; define “effective control” with latency and workload assumptions validated in pilot tests.
• Cybersecurity and logging: supply chain SBOM for AI components, model integrity checks, runtime logging (input/output/events), and secure update mechanisms.
• Post-market monitoring and CAPA: monitoring plan, incident taxonomy and thresholds, reporting workflow, and corrective/preventive action records.

Anchor each section to harmonized standards as they are cited. In the interim, map controls to recognized frameworks from ISO/IEC JTC 1/SC 42. Include evidence artifacts (plots, summaries, SOPs). Make the file easy to navigate for auditors and engineers.

Human oversight, testing, and model transparency, including content provenance and deepfake disclosures

Human oversight must be effective. Operators should understand system status, intervene, and override with adequate time and context. Pre-release testing should verify accuracy and safety under stress, fairness across relevant subgroups, and resilience to misuse. Deployers must be trained and informed about limitations and intended use.

For content-generating systems, transparency and provenance are key. Deepfakes and materially manipulated content must be clearly disclosed to affected persons. Providers should implement technical measures to support labelling at scale.

Consider adopting the C2PA standard to embed tamper-evident provenance in images, audio, and video. Add UI indicators for end-users. Build your testing plan to include human-in-the-loop latency tests, red-team scripts for harmful outputs, and logging reviews. Verify that oversight mechanisms are actually used in practice.

Open-source and research exemptions: what is covered and what is not

The Act includes targeted exemptions to avoid chilling effects on open research and open-source components. Obligations reattach when systems are placed on the market or put into service for regulated uses. Publishing a model under an open-source license can be exempt from certain provider duties. Integrating that model into a high-risk application for EU users brings you into scope as the provider of the final system.

Two practical limits matter. First, transparency duties (e.g., deepfake notices) and certain GPAI obligations may still apply irrespective of licensing if the functionality reaches users. Second, downstream integrators inherit obligations when they control the final intended purpose, data, and deployment context. If you redistribute or fine-tune an open-source GPAI and market it for high-risk use (e.g., employment screening), prepare a full Annex IV. Run a conformity assessment and affix CE marking.

Interplay with sectoral regimes: GDPR/Data Act, MDR/IVDR, Machinery Regulation, NIS2, and DORA

The AI Act complements—rather than replaces—sectoral frameworks. For medical AI, MDR/IVDR continue to govern clinical safety and performance. The AI Act layers AI-specific risk management, data governance, and human oversight on top.

If your AI is a safety component in machinery, align with the Machinery Regulation and the AI Act simultaneously. This will often occur via a single conformity assessment covering both scopes.

GDPR continues to govern personal data, including lawful bases, DPIAs, and data subject rights. The Data Act adds data access and fairness provisions in B2B/B2C contexts. Operational resilience duties under NIS2 and DORA (financial services) remain and dovetail with AI Act cybersecurity and logging.

Build a harmonized control set mapping AI Act Articles and Annex IV to GDPR DPIAs, DORA ICT controls, and sectoral testing standards. Keep legal references anchored to Regulation (EU) 2024/1689 for traceability.

Roles and responsibilities for non-EU providers, importers, distributors, and authorised representatives

Accountability follows the economic operator chain. Providers (often developers or branded owners) own risk management, Annex IV, conformity assessment, CE marking, and post-market monitoring. Deployers must use systems as intended, ensure human oversight and logging, and perform context-specific impact assessments when required.

Importers ensure that non-EU products meet EU requirements before market entry and that documentation and CE marking are correct. Distributors must not place non-compliant systems on the market and should stop distribution and inform authorities if risks emerge.

Non-EU providers typically appoint an authorised representative in the EU to field authorities’ requests and hold technical documentation. Clarify these duties in contracts. Specify who maintains Annex IV, who handles incidents, and who pays for surveillance audits. Mirror these in supplier quality agreements.

Public procurement and buyer obligations: model clauses, due diligence, and supplier attestations

Public buyers and large private buyers should bake AI Act requirements into procurement to avoid downstream non-conformities. Treat vendors of high-risk AI as critical suppliers subject to documentation, testing, and audit rights. Align RFPs with risk classification and transparency obligations.

Add these clauses and checks to your procurement pack:

• Vendor attestation of AI Act classification (unacceptable/high-risk/transparency/minimal) and role (provider/deployer), with a warrant that classification will be updated if intended use changes.
• Annex IV access rights: the vendor maintains and grants access to the technical file (or a redacted audit package) and supplies CE marking evidence before go-live.
• Testing and human oversight: the vendor agrees to pre-release testing in your environment, provides human oversight procedures, and supports post-market monitoring, including incident reporting.
• GPAI provenance: for models generating content, the vendor supports content provenance (e.g., C2PA) and deepfake disclosures, with configuration guidance for your users.
• Change control: the vendor notifies material updates, retraining, or fine-tuning that could affect risk profile and re-assesses conformity when needed.

During due diligence, request sample outputs and bias/robustness metrics. Verify notified body involvement where required. Check the vendor’s scope via the NANDO database. Maintain a vendor scorecard tied to your internal risk taxonomy and update it with each release.

Budgeting and staffing for compliance: benchmarks by risk class and company size

Budget scales with risk, novelty, and sector. High-risk systems typically require six-figure investments in year one to stand up risk management, testing infrastructure, documentation, and audits. GPAI providers add red-teaming and provenance pipelines.

SMEs can reduce costs via standards reuse, automation, and sandboxes. They also benefit from simplified fines ceilings compared to large undertakings under the AI Act.

Expect cost drivers in these categories: standards adoption. Data curation and documentation. Testing for fairness, robustness, and red-teaming. Notified body fees where applicable. CE marking and registration. Post-market monitoring and incident response. Procurement and legal work for role allocation.

A pragmatic staffing pattern for a mid-sized high-risk program includes an AI compliance lead, ML safety/reliability engineer, data governance lead, QA/test engineer, security engineer, and legal/regulatory counsel. Add SMEs from product and UX. ROI improves when you reuse controls across products, adopt harmonized standards early, and automate documentation and test reporting so Annex IV stays “always current.”

National implementation tracker and authoritative sources

Keep your plan anchored to primary sources and evolving guidance. Track EU-level updates, standards work, and notified body designations. Monitor your national competent authority for sandbox and enforcement notices.

Start with these authoritative links:

• Legal text: Regulation (EU) 2024/1689
• Commission overview and timelines: European Commission AI Act overview
• Oversight and guidance: EU AI Office
• Voluntary early alignment: AI Pact
• Notified bodies designations: EU NANDO database of notified bodies
• Standards landscape: ISO/IEC JTC 1/SC 42
• Interoperable principles: OECD AI Principles

With these sources and the steps in this playbook, your team can classify systems accurately, select the right conformity route, and produce Annex IV documentation that stands up to scrutiny. You can align procurement to vendor duties and operationalize EU AI Act compliance on time.