The EU AI Act Lands on Your Codebase, Not Just Your Legal Team

July 2026

The EU AI Act describes engineering work. Risk management, logging, human oversight, resilience against attackers: these are build requirements written in legal language, and the people most exposed are the ones who think it belongs to the legal team. The main wave applies from 2 August 2026, and whether the obligations land on you or on the vendor you buy from turns on a question most teams haven't asked.

What the EU AI Act Has Already Triggered

The Act does not land in one piece. The banned practices and the AI literacy duty have applied since 2 February 2025, and the rules for general-purpose AI models since 2 August 2025. The bulk of the regime, including the high-risk obligations, applies from 2 August 2026 under current law.

High-risk is the tier that matters most here, and it is defined by what a system is for. The Act's Annex III names the use cases: credit scoring, CV screening and hiring, biometric identification, exam marking, access to essential services, and safety components in critical infrastructure. If your system does one of those jobs, the heavy obligations apply.

There is a moving part worth knowing about. The Digital Omnibus, a package that defers the main high-risk deadlines to 2 December 2027, cleared its final European Parliament vote on 16 June 2026, with Council adoption and Official Journal publication expected before August. That deferral is very likely to land, but nothing binds until publication, so 2 August 2026 stays the legal date: treat the later date as your planning baseline, the earlier as the law, and the prohibitions as already enforceable.

The fines are tiered, and the tier that matters for most builders is not the headline one. Breaching the high-risk obligations sits at up to 15 million euro or 3% of worldwide annual turnover under Article 99(4), while the 35 million euro or 7% figure quoted everywhere is Article 99(3), reserved for the prohibited practices in Article 5. Most engineering teams will never touch the top tier and will touch the middle one constantly.

Why High-Risk Obligations Hit the People Who Build

Read Article 15 and the disguise slips. High-risk systems must achieve an appropriate level of accuracy, robustness, and cybersecurity, and they must be resilient against attempts to alter their outputs by exploiting vulnerabilities. The EU's own guidance names the attack classes it has in mind: data poisoning, model poisoning, adversarial examples, confidentiality breaches. Prompt injection is already documented against live systems. This is a threat model, not a compliance checkbox.

The same pattern runs through the surrounding articles. Article 9 wants a risk management system. Article 10 wants data governance. Article 12 wants logging. Article 14 wants meaningful human oversight. None of these is satisfied by a policy document, because each one describes something a system either does or does not do at runtime.

Take the loan applicant rejected in seconds with no human in the loop and no reason given. That example is one of the "how to explain this to your tech team" walkthroughs in The Easy Peasy Guide to the EU AI Act, an advance copy of which Ahmed shared with me, and it lands because it is exactly what Article 14 and the right to explanation in Article 86 are written to prevent. That translation move, from legal text to something a tech team can act on, is the book's best feature: it is a companion to the official text rather than a security manual, but for getting a build team to grasp what the Act asks of them, it suits this audience well.

Two Excuses the EU AI Act Has Already Closed

Two reassurances do a lot of work in engineering conversations about the Act, and the scope provisions write out both.

The first is "we just use open-source models." Article 2(12) exempts AI released under free and open-source licences, then withdraws the exemption the moment the system is high-risk or falls under the prohibited practices or the transparency rules. Open weights buy you nothing once the use case is regulated.

The second is "we're not in the EU." Article 2(1)(c) extends the Act to providers and deployers outside the Union wherever the output is used inside it, so your servers, your incorporation, and your team's location stop mattering the moment a person in the EU is on the receiving end of what your model produces. The Act's scope provisions write out both excuses in the text itself: open-source loses its exemption once a system is high-risk, and being outside the EU is no defence once the output is used inside it.

What Engineering Teams Should Change Before August 2026

The first decision is not legal. It is working out which role you are playing, because the obligations and the penalty tier both turn on it. The shadow AI already running inside most organisations counts here too: an ungoverned tool a team adopted on its own is still a deployment, and someone is still the deployer.

Build a retrieval pipeline or an agent on top of someone else's foundation model and you are most likely a deployer. Fine-tune or substantially modify that model and you can be reclassified as a provider, which carries the heavier set of obligations. Ahmed's guide runs a "how to explain this to your tech team" section against each article, which makes the role distinctions usable rather than abstract; it is on pre-order now, out 3 August 2026, the Easy Peasy Guide to the EU AI Act

Is Your Cybersecurity Tool High-Risk Under the EU AI Act?

What a system is for decides its tier, regardless of where it runs. An EDR dropped into a hospital or a grid operator does not become a critical-infrastructure safety component just by being there: the Act treats a tool used purely for cybersecurity as outside that category.

That clears one way of being high-risk, not all of them. The same product could still count as high-risk for another reason on the list, say if it also screens job applicants or scores credit, so the carve-out is narrower than it looks. The vendor is on the hook for what its own tool does, the operator for whatever high-risk AI the operator runs, and neither inherits the other's tier for sharing a building.

That split is about to reshape procurement, and the carve-out is legal relief, not commercial relief. Once the high-risk obligations apply, Article 13 forces the disclosure: the provider must hand deployers a plain account of the system's capabilities, its limits, and the human oversight it expects. The carved-out cybersecurity vendor escapes that duty but not the buyer, so every vendor should be ready for the same questions: what in your product uses AI, what can it decide on its own, and how far does its autonomy reach.

So work it out before August. List the AI systems you build or run, classify each one against the high-risk criteria, and write down your role for each, then put an acceptable use policy for AI around what your teams are allowed to adopt. The classification is an engineering judgement about what the system does and who it affects, which puts the first move on your side of the house rather than legal's.

The legal team cannot tell you what you have built. You have to tell them.

There is an upside in that, though. The Act wants logging, human oversight, and enforcement on the systems it covers, and the agent control plane the whole industry is racing to build in 2026 is exactly the surface that delivers them: audited enforcement, every action logged and reversible, a named human accountable for each agent. Build that layer well and the compliance obligation and the control you would want anyway are the same architecture, with the evidence the Act asks for falling out as a by-product.

Sources and further reading

The official text of the Act, including every article referenced here, is Regulation (EU) 2024/1689, the EU Artificial Intelligence Act on EUR-Lex. The dates come from Article 113, the penalty tiers from Article 99, the scope carve-outs from Article 2, the high-risk requirements from Articles 9 to 15, and the deployer disclosure duty from Article 13. High-risk classification is set by Annex III read with Article 6; Recital 55 guides that reading by treating tools used "solely for cybersecurity purposes" as outside the critical-infrastructure safety-component category, though recitals interpret the operative text rather than bind in their own right.

The attack classes named under Article 15 are set out in the EU AI Act Service Desk guidance on cybersecurity of high-risk AI systems. The deferral of the high-risk deadlines is the Digital Omnibus package, approved by the European Parliament on 16 June 2026 and awaiting Council adoption and Official Journal publication at the time of writing.

For a plain-language walkthrough aimed at non-lawyers, Jamal Ahmed's The Easy Peasy Guide to the EU AI Act is out 3 August 2026. Ahmed shared an advance copy; the recommendation is independent and carries no affiliate arrangement.