Essay
The EU AI Act, read as architecture
A working engineer's view of the EU AI Act — not as a compliance burden, but as a set of architectural constraints that, taken seriously, produce better AI products.
Most enterprise conversations I sit in about the EU AI Act sound the same. Legal explains the obligations. The risk function nods. Engineering quietly calculates how much velocity this will cost. By the end of the meeting, the Act has been framed as a tax on AI work.
This framing is wrong, and it produces worse products.
The Act is best read as a specification — one that the regulator has handed you for free. It tells you what your AI system needs to be able to explain about itself, what records it needs to keep, what oversight it needs to support, and what failure modes you need to have thought about. If you build your platform around those requirements from the start, you end up with an AI system that is easier to debug, easier to improve, and easier to defend. That is not the system anyone builds by accident.
This essay walks through five architectural choices the Act effectively makes for you, and what they look like when you turn them into platform features.
1. Risk classification at design time
The Act asks: what is the risk class of this system? In practice, that question is best answered when the system is being designed, not when it is being shipped. A platform team can encode this by requiring a risk classification field on every AI workload at the moment it enters the platform. The classification then drives downstream behavior — what logging is required, what evaluation thresholds apply, what human oversight is wired in.
This is the same logical move that mature security platforms made with data classification. A platform with class-aware AI workloads is a platform you can reason about.
2. Logging and traceability as a first-class concern
For higher-risk systems, the Act requires logs that let you reconstruct what the system did and why. Most enterprise AI platforms in 2026 still treat this as something the application team owns. That is a mistake. Tracing — full request, prompt, retrieval context, model output, post-processing — belongs in the platform. If every team has to build their own, you will have ten implementations and zero of them will be admissible in a regulatory conversation.
The good news: this is the same infrastructure you need to debug LLM applications in production anyway. Compliance and engineering converge here.
3. Human oversight, designed in
Article 14 of the Act, on human oversight, is the part most often handled with a sentence in a policy document. That is not oversight. Oversight is a set of product decisions: which actions can the system take autonomously, which require a human in the loop, what does the human see, how do they correct or override. These decisions belong in the spec, not in the appendix.
A platform that takes this seriously offers oversight primitives — approval queues, override capture, justification logging — that product teams compose. Teams that build oversight from scratch each time will get it wrong, and the gap will not show up until a real incident.
4. Evaluation as infrastructure
The Act requires that high-risk systems be tested and validated. In practice, this means the company needs evaluation infrastructure: golden datasets, regression suites, drift monitoring, a way to compare model versions against each other. Without this, the compliance story is fiction.
The companies I have seen ship serious AI all have evaluation owned by a real function, not by individual teams. The Act gives executives the air cover to fund that function.
5. Documentation that is generated, not written
The Act requires technical documentation. The trap is to write it by hand, which means it is out of date the moment it is delivered. A platform team that takes the Act seriously generates documentation from the system itself — model cards, eval reports, data provenance, risk classifications — and treats the human-written portion as a thin narrative layer over generated facts.
This is the same posture mature software companies have toward API documentation. The Act pushes the same discipline into the AI layer.
The strategic move
Companies that fight the Act will spend the next two years in defensive posture and ship fewer AI products. Companies that treat the Act as architecture will build platforms that produce better products, are easier to operate, and have a story to tell regulators that does not require last-minute heroics.
This is, structurally, the same move the best companies made with GDPR. The ones who treated it as a compliance project absorbed cost and shipped worse products. The ones who treated it as an architectural constraint built systems that handled data better, full stop. The Act is the same kind of opportunity.
If you are an executive or platform leader in a Nordic or EU enterprise wrestling with how to operationalize the Act, the advisory page explains how I work. A short note on LinkedIn is the fastest way to start.