This is engineering guidance, not legal advice. But most of the EU AI Act turns into work for the people who build and run the system, so it helps to read it that way.
Four risk tiers, two that change your week
The Act sorts AI by risk. Unacceptable-risk uses are banned outright: social scoring, manipulative systems, untargeted facial-recognition scraping, most real-time biometric identification in public. High-risk systems carry heavy obligations and cover things like hiring, credit, education, and critical infrastructure. Limited-risk systems mainly owe transparency, telling people they are talking to AI and labelling synthetic media. Minimal-risk is everything else, with no new duties.
Find your tier first. Most product features land in limited-risk or high-risk depending on what the output decides. A support chatbot is limited-risk. The same model scoring loan applications is high-risk, and the difference is the decision, not the technology.
The timeline you have to track
The Act entered into force in August 2024 and phases in:
- February 2025: the prohibited practices apply, plus an AI-literacy duty for staff
- August 2025: rules for general-purpose AI models, governance, and penalties
- August 2026: obligations for the high-risk systems listed in Annex III
- August 2027: high-risk systems embedded in regulated products
Plan from the date that hits your tier, not from the headline. A team shipping a high-risk feature has a deadline of August 2026 and should already be collecting evidence.
Where the AI Act meets GDPR
If your AI touches personal data, both laws apply at once, and they ask related questions. GDPR wants a lawful basis for the data you train and run on, data minimisation, and purpose limitation. The AI Act adds its own assessments on top. Where GDPR asks for a Data Protection Impact Assessment, the Act asks high-risk deployers for a Fundamental Rights Impact Assessment. They overlap, so write them together.
The part teams miss is automated decisions. GDPR gives people rights when a decision with legal or similar effect is made without a human. If your agent approves, rejects, or ranks people, you owe a human review path and an explanation. We map that flow on every engagement that processes personal data: what enters the prompt, what enters training, what lands in logs, and what comes back out of retrieval.
Transparency is a technical requirement
Limited-risk obligations read like product work. Users have to know when they are interacting with an AI system. Synthetic image, audio, and video has to be marked as artificially generated in a machine-readable way. That is provenance metadata and labelling in the pipeline, not a sentence in the footer.
High-risk is mostly logging, oversight, and records
Strip the legal language from the high-risk obligations and you get engineering tasks: automatic event logging across the system's lifetime, human oversight built into the workflow, documented data governance, and Article 15's demand for accuracy, resilience, and cybersecurity. That last one is testable, which is where we come in.
What we check
On a defensibility review we look for the controls the Act now assumes exist. A data-flow map of every place personal data meets the model. Prompt-injection resistance, because the Act names cybersecurity for high-risk systems and injection is the way most agents get turned. Access controls on the logs, since those logs now mirror every sensitive value the system has seen. Retention and deletion that account for a model remembering data it was trained on. And a human-review path on any decision that affects a person.
A defensible order of operations
If an EU launch is on the roadmap, this order front-loads the parts that take longest:
- Classify each AI feature into its risk tier. Write down why.
- Map personal-data flows through prompts, training, retrieval, and logs.
- Add AI-interaction notice and machine-readable labelling for generated media.
- Wire automatic logging and a human-oversight step into high-risk decisions.
- Run the DPIA and the Fundamental Rights Impact Assessment together.
- Test the security controls the Act mandates, and keep the evidence.
The Act reads like a legal document, but nine of its ten hard requirements are things an engineer builds, logs, or tests. Treat it as a backlog, not a memo.
Compliance here is not a certificate you buy at the end. It is a set of controls you can show working, which is the same bar a security audit sets. Build them in once and both reviews get easier.