Designing for the EU AI Act, not just compliant to it

Most conversations about the EU AI Act happen in legal and compliance functions, framed around risk classification, documentation requirements and timelines. That framing is correct, but incomplete. A significant share of what the Act requires, particularly around transparency, traceability and risk management for high-risk systems, depends on capabilities that live in the infrastructure layer: logging, access control, data lineage, and the ability to reconstruct how a model reached a given output.

Treating these as compliance add-ons, implemented after a system is already in production, tends to produce two outcomes. The first is a scramble to retrofit logging and audit trails into systems that were never designed to produce them, which is expensive and rarely complete. The second is a parallel set of governance tooling bolted alongside the AI stack rather than integrated into it, creating gaps between what the infrastructure actually does and what the documentation claims it does.

The alternative is to treat governance requirements as infrastructure design inputs from the outset, in the same way that security requirements have become a standard part of network design rather than an afterthought. In practice, this means a small number of architectural decisions made early rather than late.

Data lineage needs to be a property of the pipeline, not a report generated after the fact. That means storage and processing architectures that retain provenance metadata as data moves between training, fine-tuning and inference stages, rather than systems where lineage has to be reconstructed from logs after the question is asked.

Access control needs to operate at the level the Act actually cares about: who can deploy, modify or retrain a model, not just who can log into a server. For organisations running multi-tenant environments, this also means the isolation between tenants needs to be auditable, not just functional.

Monitoring and logging need to capture model behaviour, not just infrastructure health. Knowing that a GPU cluster was at 80 percent utilisation tells you nothing about whether a high-risk system behaved as documented during that window. The two need to be correlated, which means the logging architecture has to be designed with both audiences, operations and compliance, in mind from the start.

None of this is exotic. It is closer to how mature organisations already approach data protection: privacy by design rather than privacy by retrofit. The organisations that will find the EU AI Act manageable are the ones that recognise it as an infrastructure design question now, while systems are still being specified, rather than a documentation exercise to be handled once everything is already live.