Reading the EU AI Act as an engineer, not a lawyer
Most summaries tell you what the risk categories are. Fewer tell you what they change about the system you are about to build. These are the parts that alter architecture.
This is an engineering perspective on building systems that can pass review, not legal advice. Obligations depend on your role, sector and use case — take the specifics to counsel.
The useful thing about the AI Act, from a build perspective, is that it asks for things that are difficult to retrofit and cheap to design in. Which means the cost of ignoring it is not a fine in three years. It is a rebuild in six months.
Four requirements change how we architect systems. None of them are about model choice.
1. Classification determines the whole shape of the project
The Act treats AI systems differently depending on what they are used for, and the difference between categories is not incremental. A support agent answering product questions and an agent screening job candidates are similar systems technically and entirely different projects in regulatory terms.
Recruitment, credit, education access, essential services and several other uses fall into the high-risk category, which brings obligations around documentation, oversight, data governance and record-keeping. Get the classification wrong at the start and you either over-engineer a low-risk system or under-engineer a high-risk one. The second is the expensive mistake.
Our own voice interview product sits in that high-risk category, which is why it works the way it does: disclosure to the candidate at the start of the call, no automated rejection, transcript and scoring retained together so a judgment can be reviewed. Those are not features we added for compliance. They are the reason the system is shaped as it is.
Classification is the first architectural decision, not a compliance step at the end.
2. Human oversight has to be real, not nominal
“A human reviews the output” is easy to claim and easy to design badly. A reviewer who sees a decision with no context, no confidence signal and no practical ability to disagree is a rubber stamp, and a regulator reading the system will see that.
Meaningful oversight has concrete requirements. The reviewer needs the evidence the system used, not just its conclusion. They need to know how confident the system was. They need the authority and the time to overrule it. And the interface has to make disagreeing as easy as agreeing — if rejecting a suggestion takes four clicks and accepting takes one, you have designed the outcome.
On document extraction work this is why we show the reviewer the source image beside the extracted value. A check takes seconds, which means it actually happens. Oversight that is expensive gets skipped, whatever the policy says.
3. You will need records you are not currently keeping
High-risk systems carry logging and traceability obligations. In practice this means being able to reconstruct, after the fact, what the system was shown and what it produced.
This is the single most common gap we find in existing deployments. Teams log usage metrics — request counts, latency, cost — because that is what operational monitoring needs. They do not log content, because storing it felt like a privacy risk rather than a compliance requirement.
Both concerns are legitimate and they resolve into a design question rather than a trade-off: what is retained, where it sits, for how long, and who can read it. A private deployment makes this easier, because the logs are already in an environment the organisation controls and can set retention on. Where inference happens on a third-party API, you can log only what the provider exposes.
Input content, retrieved context, model output, confidence, whether a human reviewed it, and what they decided. Retention and access controlled deliberately rather than by default.
A specific decision, traced end to end. Not a dashboard — one case, with the evidence behind it. If you cannot produce that, the documentation does not help.
4. Transparency obligations reach into the interaction design
People are entitled to know when they are interacting with an AI system. That sounds like a copy change and is often a product decision.
On a voice call, disclosure has to happen at the start, in a way the caller registers, without turning the first fifteen seconds into a legal notice that makes them hang up. Getting that wording right took us several iterations on our own product. On a chat interface it is easier, but the same question applies to the handoff: when a human takes over, does the user know?
The overlap with GDPR is where projects actually get stuck
The AI Act does not replace data protection obligations, it sits alongside them. Most of the hard questions in practice come from the intersection: lawful basis for the processing, minimisation when a model performs better with more context, residency when inference happens elsewhere, and the right to an explanation of a decision that affected someone.
A system designed for AI Act traceability tends to answer the GDPR questions too, because both are asking for the same underlying capability: know what happened, be able to show it, and keep the data where you said you would.
Which is the practical conclusion. Regulation is not a tax applied to finished systems. It is a set of constraints that, taken seriously at the design stage, produce systems that are easier to operate, easier to debug and easier to defend.
Risk classification, oversight design, logging and residency are decided with your security and legal teams before the build, not retrofitted before go-live.
How we deploy privately →