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.
Also worth knowing
The other rules in play.
-
DORA
Financial firms must prove they can keep running when their technology fails - including when the failure is at a supplier like AWS.
-
NIS2
Medium and large organisations across 18 sectors must manage cybersecurity risk properly, report significant incidents fast, and hold their management personally accountable for it.
-
US CLOUD Act
US authorities can compel a US-based provider to hand over data it controls, even when that data is stored on servers in Europe.