Regulation · AI Act

EU AI Act
for engineering teams.

The AI Act version that matters to AI product, model, and platform teams is the one that shows which role the organization plays, which AI category is in play, where the operational burden lands, and what evidence the system needs to emit once it is live.

CELEX 32024R1689·68 defined terms·Graph-backed + editorial
At a glance

The graph gives the structure. The page gives the operating read.

For engineers, the AI Act is not an abstract “AI policy.” It puts concrete duties on how you build, ship, run, and change an AI system: technical documentation, logging, human oversight, incident reporting. The same duties reach the general-purpose models underneath it.

Product and platform teams do not need a recital-by-recital commentary. They need the operating read: which systems are in scope, which terms flip your role, which model and deployment choices trigger stricter controls, and what evidence you show when a regulator, customer, or procurement team asks how the system is governed.

CELEX
32024R1689
Stable regulation identifier
Published
2024-07-12
OJ publication date
Applies From
2026-08-02
General application date
Definitions
68 terms
Graph-backed definition set
Regulatory Briefing·June 2026

The AI Act deadline just moved 16 months. Three obligations didn’t.

High-risk slips to December 2027 — but Article 50 transparency, synthetic-content marking, and two new Article 5 prohibitions still hit in 2026, plus operational deadlines no timeline shows. What still applies, mapped to your role.

Read the briefing→
// ai_act_high_risk.deadlineDELAYED
2 Aug 2026→2 Dec 2027
+16 months
on stand-alone high-risk (Annex III) — but transparency, watermarking, and two new prohibitions still hit in 2026.
By role

Every obligation is addressed to a specific actor.

A provider does not carry a deployer's duties. An importer does not carry a notified body's. The Actor Hub breaks the Act out role by role — provider, deployer, importer, distributor, and seven more — so each team reads only what it owes, generated from the same graph as this overview.

Browse the AI Act Actor Hubarrow_forward
Scope

This is a value-chain law, not only a model-builder law.

The Act splits its duties across the value chain. A provider does not carry a deployer’s load; an importer does not carry a distributor’s. So the first question is not whether you use AI. It is which role you play, and whether the system is prohibited, high-risk, transparency-triggering, or a general-purpose model.

General-purpose model providers
Foundation-model and model-platform teams need to care about documentation, transparency, copyright policy, downstream support, and systemic-risk duties where capability thresholds are crossed.
Application and product teams
Product teams embedding AI into user-facing workflows need to understand whether they are simply deployers, whether they have become downstream providers, and whether the use case triggers transparency or high-risk treatment.
Platform, ML, and MLOps owners
Logging, traceability, model release controls, human oversight hooks, incident response, and post-market monitoring become compliance-bearing surfaces rather than internal-only engineering concerns.
Public-sector and regulated-service deployers
Teams using AI in employment, education, essential services, law enforcement, critical infrastructure, or public services can hit the most operationally demanding parts of the Act quickly.
Implementation

These are the obligation clusters that change how AI teams ship.

Risk-based classification
The Act routes obligations based on category: prohibited practices, high-risk systems, transparency-triggering systems, and general-purpose AI models do not share the same burden.
Provider and deployer duties
Articles 16 and 26 split the implementation load across the value chain. Teams need clarity on who owns instructions, monitoring, corrective action, and operational controls.
Data, documentation, and logging
High-risk systems must support data governance, technical documentation, record-keeping, and information flows that let deployers and authorities reconstruct what the system did and how it was governed.
Human oversight and transparency
Teams need to design for user disclosures, operator understanding, and meaningful oversight rather than treating AI behaviour as a black-box downstream problem.
Post-market monitoring and serious incidents
Operational ownership continues after release. Providers and deployers need ways to monitor performance, detect serious incidents, and route corrective action back into the delivery workflow.
General-purpose AI model governance
For GPAI, the Act adds obligations around documentation, downstream cooperation, copyright policy, and, for systemic-risk models, additional testing, reporting, and cybersecurity expectations.
System Surfaces

The Act lands in release, monitoring, and handoff workflows.

Model and system inventory
Teams need a living inventory of which AI models and systems exist, what role the organisation plays for each one, and where each system enters production, procurement, or customer-facing workflows.
Release, modification, and purpose control
Substantial modification, intended purpose, and foreseeable misuse are release-governance issues. They affect whether a team is still operating within the assessed posture or has crossed into a new compliance state.
Logging, observability, and incident handling
If high-risk or GPAI obligations attach, logs, oversight events, model changes, and incident evidence need to be durable enough to support both internal review and external scrutiny.
Value-chain and downstream handoff
Providers, deployers, importers, distributors, and downstream providers need clearly bounded obligations, documentation flows, and escalation paths rather than implicit assumptions.
What teams miss

The failure mode is usually role confusion or lifecycle drift.

Treating “we use AI” as the only question
The harder questions are what role the organisation plays, whether the system is high-risk or transparency-triggering, and whether later modifications change that answer.
Assuming model procurement removes obligations
Buying or integrating a third-party model does not remove governance duties. Downstream providers and deployers still inherit serious operational work under the Act.
Leaving documentation to the end
Technical documentation, instructions for use, logging, and post-market evidence are not post-launch paperwork. They shape what the system has to emit and preserve while it runs.
Reducing AI governance to ethics statements
The AI Act turns governance into release, monitoring, incident, transparency, and control problems. Policy language without operational hooks will not be enough.
Related

Use the hub as the router into deeper AI governance work.

Keep Reading

Use the hub to route into the value chain.

Start with the glossary to align vocabulary, then move into the reports and MCP surfaces that show how RuleMesh frames AI governance operationally.

Browse obligations by actor rolearrow_forwardOpen the AI Act glossary