EU AI Act compliance is now a concrete obligation for any organization deploying AI systems that touch European users. The regulation entered into force in August 2024, and its requirements phase in through 2027. Organizations that treat it as a distant concern will find themselves scrambling as enforcement ramps up.
This guide covers what the EU AI Act requires, what counts as an AI system in the first place, how the risk classification system works, what your organization must do at each tier, what changes for MLOps teams, and how to build a compliance program that aligns with broader AI governance frameworks like ISO 42001 and the NIST AI Risk Management Framework.
What Is the EU AI Act
The EU AI Act is the world's first comprehensive legal framework for artificial intelligence. It regulates AI systems based on the risk they pose to health, safety, and fundamental rights. Unlike sector-specific rules, it applies horizontally across all industries and use cases. Like GDPR before it, it sets requirements that reach well beyond Europe's borders.
The regulation follows a risk-based approach. Higher-risk systems face stricter requirements, and minimal-risk systems face almost none, so obligations vary significantly depending on what your AI systems do and how they are used.
The Act applies to providers of AI systems (organizations that develop or place AI on the market), deployers (organizations that use AI systems), and importers and distributors who bring AI systems into the EU market. It applies regardless of where the organization is headquartered. If your AI system affects people in the EU, the Act applies to you.
What Counts as an AI System Under the EU AI Act
Every compliance conversation eventually reaches the same sticking point: "Does this count as an AI system?"
Article 3(1) defines an AI system as "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."
That definition is intentionally broad. It captures everything from deep learning models generating medical diagnoses to statistical scoring systems ranking loan applicants. It aligns with the OECD's updated AI definition, which also emphasizes inference and autonomy. The Act does exclude "systems based on the rules defined solely by natural persons to automatically execute operations," but that exclusion only helps at the clear extremes.
Where the boundaries blur
These are ordinary enterprise software scenarios:
- A rule-based claims engine uses hardcoded if-then logic to approve or deny claims under a dollar threshold. No machine learning, no training data, no adaptiveness. Most legal analysts place it outside the definition. It gets murkier when those thresholds were derived from a statistical analysis of historical claims, or when an analyst used a machine learning model to find the optimal cutoffs and then hardcoded them. The system is deterministic, but its parameters were inferred from data.
- An HR recommendation algorithm surfaces candidates using weighted scoring criteria the HR team set by hand. It still infers a ranking from its input and generates recommendations that influence hiring. The HR team would say it has no autonomy. A regulator might disagree.
- A robotic process automation tool extracts invoice data on scripted workflows. Then the vendor adds an "intelligent extraction" feature that uses machine-learning OCR for non-standard formats, and the customer switches it on without much deliberation. One module is now an AI system under the Act.
Fully deterministic systems like lookup tables clearly fall outside. Foundation models and autonomous agents clearly fall inside. The hard cases sit in the middle: a logistic regression credit model on five variables, a basic NLP sentiment classifier, a time-series demand forecast with seasonal adjustment. Each infers an output from input data, and the Act does not cleanly resolve where they land. The European Commission has published guidance and FAQs, and the AI Office will keep issuing interpretive guidance, but guidance always lags deployment.
Why classification errors cost money in both directions
Obligations attach based on classification. Overclassify, and you impose documentation burdens, audit costs, and deployment delays that serve no regulatory purpose. Underclassify a system that qualifies, and you face enforcement. Most organizations overclassify out of caution, and the practical result is that compliance teams drown in paperwork for minimal-risk tools while genuinely high-risk systems get the same generic treatment.
A functional test for classification
Instead of asking "Is this AI?", assess each system against specific questions that map to the definition's elements:
- Does the system infer outputs from input data, or execute purely deterministic logic?
- Does it adapt through retraining, online learning, or parameter updates?
- Do its outputs influence decisions that affect individuals' rights, safety, or access to services?
- How much human oversight sits in the decision pipeline?
- How transparent is its reasoning to the people affected by its outputs?
The answers produce a risk profile that sets the appropriate level of governance, documentation, and monitoring. Document the reasoning behind each classification, including the borderline cases and the factors that tipped them. Then revisit it: a tool that was purely rule-based six months ago may now include machine learning components because a vendor shipped an update.
Key Dates and Enforcement Timeline
The EU AI Act follows a staggered implementation schedule.
August 2024: The regulation entered into force.
February 2025: Prohibitions on unacceptable-risk AI systems took effect.
August 2025: Requirements for general-purpose AI (GPAI) models apply. Obligations for national competent authorities begin. Voluntary codes of practice become relevant benchmarks.
August 2026: The bulk of the regulation takes effect, including requirements for high-risk AI systems listed in Annex III. This is the most significant compliance deadline for most enterprises.
August 2027: Requirements for high-risk AI systems embedded in products regulated under existing EU product safety legislation (Annex I) take full effect.
Building an AI compliance framework takes time, and regulators expect evidence of good-faith effort. Confirm current dates with counsel, since implementation timelines can be amended.
The Risk Classification System
Once a system qualifies as an AI system, it falls into one of four risk tiers.
Unacceptable Risk: Banned Outright
Certain AI practices are prohibited entirely:
- Social scoring systems used by public authorities to evaluate individuals based on social behavior or personality characteristics
- Subliminal manipulation techniques that exploit vulnerabilities or cause significant harm
- Real-time remote biometric identification in public spaces for law enforcement (with narrow exceptions)
- Emotion recognition in workplaces and educational institutions
- Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases
- Biometric categorization that infers sensitive attributes like race, political opinions, or sexual orientation
Systems in these categories must be discontinued. There is no compliance pathway, and these prohibitions are already in effect.
High Risk: Strict Requirements
A system is high risk if it falls within the use cases defined in Annex III:
- Biometric identification and categorization of natural persons
- Management and operation of critical infrastructure (energy, transport, water, digital)
- Education and vocational training (admissions, assessment, monitoring)
- Employment and workforce management (recruitment, screening, performance evaluation, task allocation)
- Access to essential services (credit scoring, life and health insurance risk assessment and pricing, emergency services)
- Law enforcement (risk assessment, polygraph, evidence evaluation)
- Migration and border control (risk assessment, document verification)
- Administration of justice (legal research, application of law)
High-risk systems also include AI embedded in products already covered by EU product safety legislation, such as medical devices, machinery, vehicles, and aviation systems. For insurance, Annex III, point 5(c) specifically lists AI systems used for risk assessment and pricing in relation to natural persons in life and health insurance. General P&C underwriting and claims are not automatically high-risk under that provision; assess each system against the applicable use case and the Act's classification rules.
Limited Risk: Transparency Obligations
AI systems that interact with humans, generate synthetic content, or perform emotion recognition or biometric categorization must tell users they are interacting with AI. AI-generated content, including deepfakes, must be labeled. Chatbots, AI-generated text, synthetic media, and voice assistants all fall here. The obligations are lighter but mandatory.
Minimal Risk: Voluntary Codes
Spam filters, AI-enabled video games, and inventory management systems face no specific obligations. Organizations may voluntarily adopt codes of conduct.
Compliance Requirements for High-Risk Systems
Risk Management System
Organizations must maintain a risk management system that operates throughout the AI system's lifecycle. It requires continuous identification, analysis, estimation, and evaluation of risks, plus appropriate mitigation. It must consider risks to health, safety, and fundamental rights, account for intended use and reasonably foreseeable misuse, and communicate residual risks to deployers. See our overview of AI risk management.
Data Governance
Training, validation, and testing datasets must be relevant, representative, and as free from errors as practicable. Organizations must examine datasets for biases, particularly those that could lead to discrimination against protected groups. Protected attributes vary by domain and the right fairness metrics depend on context, so bias evaluation needs its own process before a model advances to production.
Technical Documentation
Before a high-risk system is placed on the market, documentation must demonstrate conformity and give authorities what they need to assess it: a general description of the system, design specifications, development methodology, data governance practices, risk management measures, testing and validation results, and performance metrics.
Record Keeping and Logging
High-risk systems must automatically record events while operating, with traceability appropriate to the system's purpose. In practice, that means logging predictions (or at minimum a representative sample) with enough context for later analysis. When a regulator asks why a specific decision was made three months ago, you must be able to reconstruct what inputs the model received, what state it was in, and what it produced. Retention periods, level of detail, and access rules should follow the system's risk level and applicable legal obligations. An AI audit trail serves auditing, incident response, and continuous improvement at once.
Transparency and User Information
High-risk systems must be designed so users can understand and appropriately interpret how outputs are produced. Deployers must provide clear information about capabilities, limitations, intended purpose, and the level of human oversight required.
ML models make this hard because they are trained automatically on data and can absorb complex nonlinear interactions humans cannot otherwise discern. Meeting the requirement means building explainability into development from the start, serving four audiences: technical teams who need feature attributions to debug, business stakeholders who need behavior tied to business concepts, regulators who need verifiable documentation, and end users who need simple explanations. A loan applicant denied credit should understand what factors mattered and what might change the outcome.
Human Oversight
High-risk systems must allow human operators to understand capabilities and limitations, correctly interpret outputs, decide not to use the system or override it, and intervene or interrupt operation. Oversight must be proportionate to the risks posed and the system's level of autonomy.
Accuracy, Robustness, and Cybersecurity
High-risk systems must achieve appropriate accuracy, robustness, and cybersecurity throughout their lifecycle, and resist errors, faults, and manipulation by unauthorized third parties. When declared accuracy levels are not met, the system must indicate this so action can be taken.
That makes continuous model monitoring a practical requirement. Models degrade when production data diverges from training data. A recruiting model trained when employment was high may stop performing once unemployment rises sharply and the candidate pool changes. Drift can be gradual or sudden, and it can hit overall performance or specific subgroups. The Act does not prescribe an implementation, but monitoring should compare behavior against baselines, detect input distribution shifts, track performance over time, and alert when thresholds are crossed.
What the EU AI Act Means for MLOps Teams
The requirements above land hardest on the teams that build and run models. For MLOps teams, three areas change.
Development. Explainability and bias evaluation become part of the workflow: choosing inherently more interpretable models where possible, using explanation methods suited to the model type, and validating that explanations are accurate. Documentation of data sources, preprocessing, architectures considered, and testing performed must be maintained for the model's full lifecycle.
Deployment infrastructure. Monitoring belongs inside the pipeline that models deploy into. Logging must capture inputs, outputs, and enough metadata to reconstruct context, calibrated to risk level. Alerting must cover operational issues (latency, errors) and behavioral ones (drift, fairness degradation).
Governance integration. Model validation needs clear criteria and documented outcomes, deployment approvals need to be traceable, and incident response needs documented procedures. This is far easier when governance exists before the MLOps build than when it is retrofitted.
These capabilities pay for themselves operationally too. Explainability helps debug models, monitoring catches issues before customers do, and documentation makes collaboration easier.
How the EU AI Act Intersects with Other Frameworks
ISO 42001
ISO 42001 is the international standard for AI management systems. Organizations certified under it will find significant overlap with EU AI Act requirements, particularly around risk management, documentation, and continuous improvement. Certification does not guarantee EU AI Act compliance, but its management system discipline, policy documentation, and audit mechanisms directly support many obligations.
NIST AI Risk Management Framework
The NIST AI RMF is a voluntary framework whose four core functions (Govern, Map, Measure, and Manage) align well with the Act's risk-based approach. Its trustworthiness characteristics (validity, reliability, safety, security, accountability, transparency, explainability, privacy, and fairness) map onto the Act's high-risk requirements.
Building a Unified AI Compliance Framework
Rather than running each standard as a separate initiative, build one AI governance framework that satisfies several at once. Map EU AI Act obligations against ISO 42001 requirements and NIST AI RMF practices, identify overlaps and gaps, and build once. US carriers can fold the NAIC model bulletin and state AI regulations into the same map.
Practical Compliance Checklist
Inventory and Classification
- Catalog every system that involves automated inference, prediction, recommendation, or decision-making, without pre-filtering. Include rule-based systems with data-derived parameters, vendor tools, and internal tools that never went through procurement (see how to detect shadow AI)
- Apply the functional classification test and document the reasoning, including borderline cases
- Classify each AI system according to the risk tiers
- Identify which systems interact with EU users or are placed on the EU market
- Discontinue any systems that fall under prohibited practices
Vendors
- Request technical documentation on how third-party tools generate outputs; many have AI components not surfaced in marketing or the UI
- Remember the Act places obligations on deployers as well as providers
Risk Management
- Establish a risk management system for each high-risk AI system
- Conduct risk assessments covering health, safety, and fundamental rights
- Document residual risks and communicate them to deployers
- Implement mitigation measures and monitor their effectiveness
Data Governance
- Audit training, validation, and testing datasets for quality and representativeness
- Document data sources, preprocessing steps, and known limitations
- Assess and mitigate bias risks in datasets
- Establish ongoing data quality monitoring
Technical Documentation and Records
- Prepare technical documentation for all high-risk systems before market placement
- Implement automatic logging capabilities
- Set record retention policies aligned with regulatory requirements
- Ensure documentation is sufficient for authorities to assess compliance
Human Oversight and Transparency
- Design human oversight mechanisms proportionate to system risk
- Provide clear user information about capabilities, limitations, and intended use
- Implement mechanisms for operators to override or interrupt AI outputs
- Label AI-generated content and disclose AI interactions where required
Conformity Assessment
- Determine whether self-assessment or third-party conformity assessment is required
- Prepare for conformity assessment before the relevant deadline
- Obtain CE marking for high-risk systems where applicable
- Register high-risk systems in the EU database
Organizational Readiness
- Designate internal responsibility for AI Act compliance, with a named owner for each system
- Set review cycles and reclassification triggers (new vendor features, retraining, configuration changes)
- Train relevant staff on regulatory requirements and internal procedures
- Establish incident reporting mechanisms for serious incidents or malfunctions
- Start with the systems most likely to be high risk, then expand coverage incrementally
Penalties for Non-Compliance
- Prohibited AI practices: Fines up to 35 million EUR or 7% of global annual turnover, whichever is higher
- Non-compliance with high-risk requirements: Fines up to 15 million EUR or 3% of global annual turnover
- Supplying incorrect information to authorities: Fines up to 7.5 million EUR or 1% of global annual turnover
For SMEs and startups, fines are capped at the lower of the two thresholds. Non-compliance can also mean systems withdrawn from the EU market, reputational damage, and lost customer trust.
The European AI Office oversees enforcement for general-purpose AI models, while national competent authorities handle enforcement within each member state. Expect scrutiny to increase as enforcement infrastructure matures.
Operationalizing EU AI Act Compliance
Meeting EU AI Act requirements takes more than policy documents. It takes operational capabilities for classifying, evaluating, monitoring, and documenting AI systems on an ongoing basis. That means a live inventory of AI systems with structured classification criteria, behavioral evaluation that measures accuracy, robustness, fairness, and transparency (the same dimensions the Act requires for high-risk systems), monitoring that flags drift and triggers reclassification when a system's capabilities change, and documentation that maps evidence to the EU AI Act, ISO 42001, and the NIST AI RMF at the same time.
None of this replaces legal judgment about whether a particular system qualifies. It gives that judgment structured evidence, and it ensures each system gets governance proportional to its actual risk. Definitional certainty was never a prerequisite for responsible governance, and the organizations that build these processes now will be ready wherever the regulatory lines settle.
For a broader view of the obligations, see our guide to AI compliance. If you want to see how continuous governance, audit-ready logging, and multi-framework mapping work in practice, see how Swept approaches AI governance.