Skip to content

The rules, in plain words

EU AI Act

Artificial Intelligence Act · Regulation (EU) 2024/1689 · EU

AI systems are sorted by how much harm they could do, and the riskier ones carry real obligations - documentation, human oversight, logging and data governance.

Who it applies to. Providers and deployers of AI systems used in the EU, including organisations outside the EU whose systems are used there. General-purpose AI model providers have their own separate regime.

In plain words

The Act works by risk tier rather than by technology. A few uses are prohibited outright. A defined set of high-risk uses carries substantial obligations. Most everyday systems fall below that and carry light transparency duties instead. The first practical question is always which tier you are in.

For high-risk systems the demands are recognisable to anyone who has built regulated software: know and document what the system does, govern the data it learns from and runs on, keep logs that let you reconstruct a decision, and make sure a human can meaningfully intervene.

The obligations phase in over several years rather than arriving at once, which has led a lot of organisations to treat it as a future problem. That is a mistake for one specific reason: nearly all of it is decided at design time. A system built to produce its own evidence satisfies most of this incidentally. One that was not has to be partly rebuilt.

Timing

When it applies.

2 February 2025
Prohibitions on certain AI practices took effect, along with AI literacy duties.
2 August 2025
Obligations for general-purpose AI models began to apply.
2 August 2026
The high-risk regime applies: risk management, data governance, logging, human oversight, conformity assessment and registration.
2 August 2027
General-purpose AI models placed on the market before August 2025 must be brought into compliance.

What it means for your architecture

The part that is decided at design time.

  • Logging has to be designed for reconstruction, not just for debugging - you may need to explain a specific past output.
  • Data provenance and access control for training and grounding data become evidence, not hygiene.
  • Human oversight has to be a real control point in the system, not a person nominally in the loop.
  • Technical documentation is far cheaper when the build produces it than when someone assembles it afterwards from memory.

Read the real thing

This is an engineering explainer, not legal advice. How the rules apply to your organisation is a question for your counsel and your compliance function. What your architecture can evidence against them is the question Northkeep answers.