Key takeaways
- The AI Act — Regulation (EU) 2024/1689 — entered into force on 1 August 2024 and applies in stages.
- What applies depends on the category: prohibited practices, high-risk systems, transparency duties and general-purpose AI models each have their own rules.
- For high-risk systems the requirements are largely engineering: risk management, data governance, technical documentation, automatic logging, human oversight, and accuracy and robustness.
- An inventory of where AI is used, and in what role, comes first. You cannot classify what you have not listed.
- Parts of the high-risk timetable have been the subject of proposed changes, so check the dates in force before fixing a plan to one.
A regulation that arrives in stages
The AI Act entered into force on 1 August 2024. The bans on prohibited practices, and the duty to build AI literacy among staff, applied from 2 February 2025. Obligations for providers of general-purpose AI models followed on 2 August 2025. The regulation’s original timetable put most remaining provisions — including the bulk of the high-risk obligations — at 2 August 2026, with high-risk AI built into products already covered by EU product legislation following in August 2027.
The EU has since proposed moving some high-risk deadlines back while the harmonised standards are finished. Whatever the final dates, the engineering work below takes longer than most plans allow, so treat the timetable as the latest the work can finish rather than a target to aim at.
Categories, and what applies to each
| Category | Examples | What applies |
|---|---|---|
| Prohibited practices | Social scoring, untargeted scraping of facial images, emotion recognition at work or in education | Banned outright |
| High-risk systems | Uses listed in the Act, such as creditworthiness assessment, recruitment and access to essential services, and safety components of regulated products | Risk management, data governance, documentation, logging, human oversight, conformity assessment |
| Transparency duties | Chatbots, and AI-generated or manipulated content | Tell people they are dealing with AI; mark synthetic content |
| General-purpose AI models | Models offered for a wide range of uses | Documentation and a copyright policy for providers; more for models with systemic risk |
| Everything else | Spam filters, code assistants, most internal tooling | No new obligations beyond AI literacy; voluntary codes |
What the high-risk requirements look like in code
Articles 9 to 15 set out what a high-risk system must have. Read as an engineer, each one is a feature or a pipeline step:
- Risk management (Article 9): a documented process across the system’s life — identify risks, estimate them, mitigate them, and test that the mitigations work.
- Data and data governance (Article 10): training, validation and test data that is relevant, representative and examined for bias, with its provenance recorded.
- Technical documentation (Article 11): what the system does, how it was built and how it was tested, kept current as it changes.
- Record-keeping (Article 12): automatic logging of events over the system’s lifetime, enough to trace how an output came about.
- Transparency to deployers (Article 13): instructions for use that explain what the system can do, and where it fails.
- Human oversight (Article 14): designed-in ways for a person to understand an output, intervene, and override it.
- Accuracy, robustness and cybersecurity (Article 15): declared levels of accuracy, and resilience to errors and attacks.
None of these is a document written at the end. Logging has to be designed into the inference path. Oversight has to be a screen and a workflow, with the approver recorded. Data governance has to be a step in the pipeline that fails the build when it is skipped.
Provider or deployer?
The Act separates the provider, who develops a system and places it on the market under their own name, from the deployer, who uses it. Many enterprises are both: they deploy a vendor’s model inside a system they build and brand themselves. Putting your name on a high-risk system, modifying it substantially, or changing its intended purpose so that it becomes high-risk can make you its provider, with the provider’s obligations.
Start with an inventory
List every use of AI
Including features inside bought software, and the assistants staff use on their own.
Classify each one
Against the Act’s categories, with the reasoning recorded so it can be reviewed.
Build the controls in
For anything high-risk or close to it, design logging, oversight and documentation into the build rather than after it.
Name an owner
One person per system who can say what it does, on what data, with what controls.