EU AI Act: From Regulation to Technical Evidence
Practical perspectives on AI governance, risk, security, evaluation and technical evidence for organizations preparing for the EU AI Act.
What is the EU AI Act?
The EU AI Act, formally Regulation (EU) 2024/1689, is the European Union's risk-based legal framework for artificial intelligence. It entered into force on 1 August 2024, and rather than regulating "AI" as one thing, it sorts AI systems and models into risk tiers and attaches different obligations to each one.
It is a horizontal EU legal framework that establishes risk-based rules for artificial intelligence. The Act applies in several situations, including to certain providers and deployers in the EU and to certain third-country providers whose AI system's output is used in the Union, subject to the specific conditions set out in the Regulation rather than as a blanket rule covering every organization connected to AI in any way. The obligations are being phased in over several years rather than all at once, and that phasing has itself been adjusted since the Act was first adopted, which is part of why this page carries a review date rather than treating any single summary as permanent.
Who does the EU AI Act apply to?
Applicability is not uniform, and one of the more common mistakes I see is an organization assuming the Act either fully applies to them or doesn't apply at all. In practice, it depends on several factors working together.
Role in the AI value chain. A provider develops an AI system or model and places it on the market or puts it into service. A deployer uses an AI system under its own authority. The two carry different obligations, and an organization can be both for different systems.
Intended purpose and risk classification. The same underlying model can sit in different risk tiers depending on what it's used for. A general-purpose language model used for internal drafting carries a very different obligation set than the same model wrapped into a CV-screening tool.
Whether the system is a general-purpose AI model. GPAI models carry their own obligation track, addressed separately below, layered on top of whatever role and risk classification otherwise applies.
None of this is a substitute for a case-by-case legal assessment of a specific system. It's the frame an engineering or architecture team needs before that assessment can even be scoped properly.
What are the EU AI Act risk categories?
The Act takes a risk-based approach rather than regulating every AI system the same way. Four broad categories are commonly used to explain that approach in practical terms; they are an explanatory framework for orientation, not a universal legal self-classification test, and the boundaries below should not be treated as a substitute for a case-specific legal assessment.
Unacceptable risk
A defined list of prohibited practices, including social scoring, exploiting vulnerabilities to manipulate behavior, and certain biometric and predictive-profiling uses. These have been banned since 2 February 2025. A further prohibition, covering AI systems that generate or manipulate non-consensual intimate imagery or child sexual abuse material, was added by the 2026 Digital Omnibus and applies from 2 December 2026, not before.
High-risk
Systems used in sensitive domains (Annex III) or embedded in already-regulated products (Annex I). Subject to the Act's most detailed obligations: risk management, data governance, documentation, logging, human oversight, and robustness requirements.
Limited risk (transparency)
Systems such as chatbots and AI content generators carry transparency obligations under Article 50: disclosing that content is AI-generated or that a user is interacting with an AI system, including labeling deepfakes. Article 50 applies from 2 August 2026, but for AI systems already placed on the market before that date, providers have until 2 December 2026 to comply with the Article 50(2) marking and detection obligation specifically; content generated before 2 August 2026 does not need to be labeled retroactively.
Minimal or no risk
Many AI systems fall into the minimal- or no-risk category and carry no specific obligations under the Act, though voluntary codes of conduct are encouraged.
What is a high-risk AI system?
High-risk status attaches in two ways. Annex III lists specific use-case domains: critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including credit scoring and insurance), law enforcement, migration and border control, the administration of justice and democratic processes, and certain biometric identification and categorization uses. Annex I covers AI used as a safety component in products already regulated under existing EU product-safety law, such as machinery, medical devices and toys. Falling within one of these domains is not, by itself, a complete classification test: whether a specific system is actually high-risk depends on the applicable legal criteria for that domain, not on the sector alone, and not every AI system used in healthcare, employment, education, finance or public services is automatically high-risk.
Providers of high-risk systems carry the heaviest obligation set: a risk management system maintained across the system's lifecycle, data governance over training, validation and testing data, technical documentation, automatic logging capabilities, clear instructions enabling human oversight, and demonstrated accuracy, robustness and cybersecurity. Deployers of high-risk systems carry a narrower set, centered on using the system according to its instructions, ensuring human oversight in practice, and monitoring its operation, with additional obligations such as a fundamental-rights impact assessment for certain deployers (including public bodies and specific financial-services uses).
What are GPAI obligations?
The Act defines a general-purpose AI (GPAI) model in Article 3; the exact scope of that legal definition should be checked against the Regulation's own text or official Commission guidance, not against this summary. In practical terms, and purely as an explanatory description rather than a restatement of that legal text, this generally covers models with broad capabilities that can perform a wide range of tasks and be integrated into downstream AI systems. GPAI models have a distinct set of obligations for their providers under the Act, and additional requirements may apply depending on how a GPAI model is incorporated into or used within a downstream AI system, so a GPAI provider's obligations and a downstream system's obligations are not automatically the same thing.
Every GPAI provider is expected to maintain technical documentation, make certain information available to providers who integrate the model downstream, and publish a sufficiently detailed summary of the content used for training, to support copyright-related obligations.
A GPAI model is presumed under Article 51 to carry systemic risk when the cumulative compute used for its training exceeds a defined threshold (expressed in floating-point operations), and the Commission can also designate a model as carrying systemic risk on other grounds. Providers of such models face additional obligations: model evaluation including adversarial testing, assessing and mitigating systemic risk, tracking and reporting serious incidents, and ensuring an adequate level of cybersecurity protection. The European AI Office, established within the European Commission, holds primary supervisory authority over GPAI models and maintains a voluntary Code of Practice for GPAI providers covering transparency, copyright and safety and security; it is a voluntary tool intended to help providers demonstrate compliance, not itself a determination that a given provider is compliant.
Timeline: what applies when
The Act's obligations are phased in, and the phasing has already been adjusted once since adoption. As of this page's last review date, the application schedule is:
1 August 2024
Regulation (EU) 2024/1689 enters into force.
2 February 2025
Prohibited-practice rules and AI-literacy obligations become applicable.
2 August 2025
Governance rules, GPAI model obligations, and the Article 99 penalty regime become applicable.
2 August 2026
General application date for most remaining provisions, including Article 50 transparency obligations, subject to the specific transitional and application rules that apply to particular provisions and systems; see the 2 December 2026 entry below for the specific transition affecting systems already on the market.
2 December 2026
The additional prohibition on AI systems that generate or manipulate non-consensual intimate imagery or child sexual abuse material, introduced by the 2026 Digital Omnibus, becomes applicable. For AI systems already placed on the market before 2 August 2026, this is also the compliance deadline for the Article 50(2) marking and detection obligation specifically, a separate transition from the general 2 August 2026 Article 50 application date.
2 December 2027
High-risk obligations for Annex III systems apply. Originally set for August 2026, this date was pushed back by the 2026 Digital Omnibus amendment.
2 August 2028
High-risk obligations apply to AI embedded in Annex I regulated products.
In 2026, the European Commission's "Digital Omnibus on AI" (in force since 27 July 2026) amended the Act to extend the high-risk compliance timeline and simplify certain administrative obligations, while leaving the Act's core risk-based structure and safeguards in place. Treat any AI Act timeline, including this one, as subject to further guidance and possible amendment, and verify current dates against the European Commission's own page before treating a specific date as final for a specific system.
What happens if an organization doesn't comply?
Article 99 sets three penalty tiers, applicable since 2 August 2025: up to €35 million or 7% of total worldwide annual turnover for violating prohibited practices; up to €15 million or 3% for non-compliance with high-risk obligations or Article 50 transparency duties; and up to €7.5 million or 1% for supplying incorrect, incomplete or misleading information to authorities. For large organizations, the higher of the two figures applies; these are statutory maximums, not automatic or fixed amounts, and the actual fine in a given case depends on the specific facts and the enforcing authority's assessment. Article 99 itself provides more favorable treatment for SMEs, including start-ups, using the lower of the two figures instead, and the 2026 Digital Omnibus extended comparable treatment to small mid-cap companies for the two lower penalty tiers.
Why the EU AI Act matters to technology leaders
Set aside the penalty figures for a moment, because they're not actually the most useful reason to pay attention to this regulation.
The Act is, in effect, codifying a set of engineering and governance practices that production-grade AI needed anyway: a documented risk assessment, traceable data lineage, logging sufficient to reconstruct what a system did and why, human oversight that's actually exercisable rather than nominal, and monitoring that catches drift before a customer or a regulator does. Organizations that already run AI systems this way have a head start that has nothing to do with legal strategy. Organizations that don't are discovering, often at the worst time, that "we'll document it later" doesn't hold up once a system is handling decisions that affect real people.
This doesn't mean every company or every AI system carries the same obligations, and it's worth resisting both extremes here: treating the Act as irrelevant because "we're not in a regulated industry," and treating it as an existential threat that demands a crash compliance program regardless of what the organization actually does with AI. The right response is proportionate to the system's actual role and risk classification, which is exactly why the applicability question above comes before anything else.
AI compliance is more than a checklist
This is where most compliance conversations go wrong. A policy document that nobody can trace to an actual running control isn't evidence of anything, and a control that's never been tested isn't meaningfully different from no control at all.
Policy
What the organization says it does. A statement of intent, not yet a mechanism.
Control
What mechanism has actually been implemented to carry that policy out, in code, configuration or process.
Test
Whether the control, and the system's actual behavior, can be evaluated and shown to hold under realistic conditions.
Evidence
What can actually be produced to demonstrate the result: logs, test output, evaluation reports, audit trails.
Governance
How that evidence is maintained, reviewed on a cadence, and acted on when it reveals a gap.
That chain is also, not coincidentally, the architecture conversation I have with engineering teams regardless of regulation: production-grade AI requires measurable behavior, security controls, observability and governance evidence, not only a policy document sitting in a shared drive. I won't claim to know exactly what a given regulator will accept as sufficient evidence in every case, because that determination sits with the regulator and the specific facts. What I can say is that an organization with no measurable behavior and no evidence trail has nothing to offer that conversation when it comes.
What is AI assurance? Technical evaluation for AI systems
AI assurance is the technical practice of evaluating what an AI system actually does, as distinct from what a policy says it should do. It's the engineering layer that produces the evidence the governance chain above depends on, and it's worth being explicit that technical evaluation is not itself a legal compliance determination. It's an input to one.
Mechanistic interpretability as an evidence source
Mechanistic interpretability is an active research field that tries to understand what's happening inside a model, not just what it outputs, using techniques such as activation analysis, feature attribution, activation patching, sparse autoencoders, and causal interventions to identify candidate circuits that appear to drive a given behavior.
It's worth stating plainly what this does and doesn't currently offer. These methods can surface measurable internal representations and build evidence for a hypothesis about what's influencing a model's output. They do not currently provide exact knowledge of a model's "thoughts," a complete reconstruction of its reasoning, a guaranteed causal explanation, or identification of a single neuron definitively responsible for an outcome. The field's own terminology reflects this: findings are described as attribution, candidate causal influence, and evidence supporting a hypothesis, not as proof.
Framed accurately, interpretability is one possible technical evidence source among several, useful alongside behavioral evaluation and monitoring, not a stand-in for them and not a compliance mechanism on its own.
Building an EU AI Act Compliance & Evidence Engine
This is a real engineering and research project I'm building, not a shipped commercial product. There's no public demo, customer base or benchmark result to point to yet, and I won't describe it as more mature than that.
The core idea: connect AI evaluation, technical evidence and risk assessment to regulatory control mapping, so that an organization's actual, tested system behavior, not just a policy document, is what gets mapped against the EU AI Act's requirements.
At a high level, the pipeline looks like this:
Planned capabilities include model registration, automated behavioral and security testing, interpretability-based risk indicators, evidence collection, mapping tested behavior to specific EU AI Act controls, an audit trail, reporting, and configurable governance frameworks so the same evidence pipeline can map to more than one regulatory or internal standard over time.
One thing this engine will not do, by design: determine legal compliance on an organization's behalf. Its output is a technical assessment and an evidence map, the raw material a compliance or legal function needs, not a substitute for that function's judgment.
What this means for AI leaders
Business risk and accountability
What AI risks is the organization actually taking on. Can responsible AI governance be demonstrated, not just claimed. Can AI systems scale without the risk scaling uncontrolled alongside them.
Operationalizing governance
How governance gets turned into something engineering teams actually run, not a document they read once. What technical controls are needed, and how systems get evaluated continuously rather than at a single sign-off.
A new attack surface
Whether AI introduces new attack surfaces, prompt injection, data leakage, tool abuse, that existing security programs weren't built to test. How evidence of that testing gets maintained and kept current.
Where the operational work lands
What operational and compliance work AI adoption actually creates, and where it lands organizationally. How measurable controls, established early, reduce the odds of an expensive surprise later.
Who this is for
This content is written primarily for the organizations and roles actively building, deploying or governing AI systems with EU exposure:
Not every organization in these categories is legally obligated under every provision of the Act. Which obligations actually apply depends on the specific factors covered above.
FAQ
What is the EU AI Act?
The EU AI Act, formally Regulation (EU) 2024/1689, is the European Union's risk-based legal framework for AI systems. It entered into force on 1 August 2024 and lays down rules on prohibited AI practices, obligations for high-risk AI systems, transparency requirements, and rules for general-purpose AI models, applied in phases through 2028.
Who does the EU AI Act apply to?
The Act applies in several situations, including to certain providers and deployers in the EU and to certain third-country providers whose AI system's output is used in the Union, subject to the specific conditions set out in the Regulation. The specific obligations that apply depend on an organization's role (provider or deployer), the system's intended purpose, and its risk classification, so not every organization or system carries the same obligations.
What are the EU AI Act risk categories?
The Act takes a risk-based approach. Four broad categories are commonly used as an explanatory framework, not a universal legal self-classification test: unacceptable risk (prohibited practices), high-risk (subject to detailed obligations), limited risk (transparency obligations such as disclosing AI-generated content), and minimal or no risk (no specific obligations under the Act).
What is a high-risk AI system?
A high-risk AI system is one used in a sensitive domain listed in Annex III (such as employment, education, essential services, law enforcement, migration, or the administration of justice) or embedded as a safety component in a product already regulated under EU product-safety law (Annex I). Providers of high-risk systems face obligations including risk management, data governance, technical documentation, logging, human oversight, and accuracy, robustness and cybersecurity requirements.
What are GPAI obligations?
Providers of general-purpose AI (GPAI) models must maintain technical documentation, provide information to downstream providers, and publish a summary of training content for copyright purposes. GPAI models presumed to carry systemic risk, including those trained using cumulative compute above the threshold set in Article 51, face additional obligations: model evaluation and adversarial testing, systemic risk assessment and mitigation, incident reporting, and cybersecurity protection.
What is AI assurance?
AI assurance is the practice of technically evaluating an AI system's behavior, security and reliability, through methods such as evaluation, red teaming, bias and safety testing, and monitoring, to produce evidence about how the system actually behaves. It is a technical discipline that can support legal compliance, but it is not itself a legal or regulatory determination.
What evidence should AI teams maintain?
Technical documentation of the system's design and data; records of evaluation, testing and red-teaming results; monitoring and audit logs of production behavior; human-oversight records for high-risk use cases; and a clear mapping from each control to the specific behavior or requirement it addresses, maintained on an ongoing basis rather than produced once.
How can engineering teams prepare for the EU AI Act?
By first classifying their role (provider or deployer) and the system's risk category, then building the technical controls that generate evidence for that classification: documentation, evaluation and testing pipelines, monitoring and logging, and human-oversight mechanisms, reviewed and updated as the system and the guidance evolve.
What is the difference between AI compliance and AI governance?
Compliance is meeting a specific external requirement, such as a provision of the EU AI Act. Governance is the ongoing organizational structure, including policies, controls, testing, evidence and accountability, that produces compliance as an outcome and keeps it current as systems, usage and regulation change.
Related reading
This connects directly to AI Security, Agentic AI Security and Production AI, and to the economics and architecture questions covered in The Economics of Autonomous AI and The Agent Card Problem.
Sources & further reading
Regulation (EU) 2024/1689 (Artificial Intelligence Act), official text, EUR-Lex.
AI Act regulatory framework, European Commission, Digital Strategy.
European AI Office, European Commission.
AI Omnibus enters into force, European Commission, July 2026.
This content provides technical and educational guidance and does not constitute legal advice, regulatory certification or a guarantee of compliance. It does not establish the author as an EU-certified assessor, a lawyer, or an official EU body or partner. Applicability of the EU AI Act to a specific organization or system should be assessed with qualified legal counsel.
Building AI for the European market?
Let's discuss the architecture, security, governance and evidence requirements behind production-grade AI, in the context of where your systems actually sit under the EU AI Act.