The EU AI Act Is Not a Compliance Problem. It's an Engineering Problem.
The Act's high-risk provisions come into full effect on August 2, 2026. The penalties for non-compliance reach up to €35 million or 7% of global annual turnover — whichever is higher. And the requirements that matter most aren't in legal documents. They're in your logging infrastructure, your data pipelines, your model documentation, and the way your system handles human oversight. Engineers built the thing. Engineers need to understand what the regulation actually asks of it.
The four-tier structure in plain terms
The Act classifies AI systems by risk, and the classification determines everything.
Prohibited systems have been banned since February 2025: real-time biometric surveillance in public spaces, social scoring by governments, AI that exploits psychological vulnerabilities, predictive policing based purely on profiling. If you're building any of these, stop — that conversation is over.
High-risk systems are where most of the engineering work lands. This includes AI used in hiring decisions, credit scoring, educational assessment, medical devices, and critical infrastructure. These systems require technical documentation, mandatory logging of inputs and outputs, human oversight mechanisms, and conformity assessments before deployment. The August 2026 deadline applies here for most Annex III use cases.
General-purpose AI (GPAI) models — foundation models like GPT-4, Claude, Gemini — have their own obligations, enforceable since August 2025. If you're fine-tuning a foundation model substantially enough that you've become a "provider" rather than a "deployer," your compliance obligations increase significantly. The line between the two is genuinely blurry, and the EU AI Office's guidance acknowledges it.
Minimal-risk systems — recommendation engines, spam filters, most internal productivity tools — face no new Act-specific obligations. This covers the vast majority of AI in production today.
What this actually means for your production system
The technical requirements for high-risk systems are specific. Article 12 mandates automatic logging of events sufficient to trace a system's decisions after the fact — inputs, outputs, decision points, all attributable to authorised identities. A system that can't produce a coherent audit trail doesn't meet the standard, regardless of how well-documented the model itself is.
Dataset versioning and model lineage tracking are expected. Risk management documentation needs to span the full lifecycle — design, development, deployment, post-market monitoring — not a static policy document filed once and forgotten. Human oversight isn't satisfied by putting a button in the UI. It means designing the system so a human can meaningfully intervene in decisions that affect people, not just theoretically approve them.
The harder truth: harmonised technical standards that were supposed to clarify implementation detail missed their April 2025 deadline and are now targeting end of 2026. Organisations can't wait for them. The Act applies whether standards are published or not, and regulators have explicitly rejected enforcement delays. You document your reasoning, work from the Act's text and the Commission's guidance, and build toward demonstrable compliance rather than waiting for perfect instruction.
The one thing most teams are missing
Over half of organisations heading into 2026 lack a complete inventory of AI systems currently in production. Before any of the technical compliance work is meaningful, that inventory needs to exist. You can't classify risk, assign ownership, or build documentation for systems you don't know you're running.
Compliance built into the development workflow from day one is manageable. Retrofitted onto a production system under deadline pressure, it isn't.