The EU AI Act's high-risk obligations land in August — a builder's readiness checklist

On 2 August 2026, the EU AI Act's obligations for high-risk AI systems become applicable. The prohibited-practice and AI-literacy provisions have been in force since February 2025, and the general-purpose-model rules since August 2025 — but August 2026 is when the heavy operational machinery starts to apply to the systems most businesses actually run: risk management, technical documentation, human oversight, logging, conformity assessment.

Two things before anything else. First, this is not legal advice — we're an engineering firm, and this post is an engineer's translation of regulatory text into software requirements. For scoping decisions with real consequences, involve counsel. Second, this is deliberately non-alarmist. Most AI systems are not high-risk under the Act, and a lot of the vendor noise around the deadline is selling fear. The useful work is narrower and more concrete than the noise suggests.

Step zero: does the Act reach you at all?

If you're a UK company, don't stop reading. The Act has explicit extraterritorial scope. It applies, among other cases, to:

• providers who place AI systems on the EU market or put them into

service there, regardless of where the provider is established;

• deployers of AI systems located in the EU; and
• providers and deployers located outside the EU where the output

produced by the system is used in the EU.

That last clause is the one that catches UK firms by surprise. You don't need an EU entity or an EU customer contract. If your AI-assisted screening tool scores candidates for a client's Dublin office, or your model's outputs are consumed by users in the EU, you can be in scope. The first honest task of any readiness exercise is establishing, system by system, whether and how the Act reaches you — not assuming it doesn't because your registered office is in London.

Which hat are you wearing?

The Act assigns obligations by role, not by company. The two roles that matter for most SMEs:

• A provider develops an AI system (or has it developed) and places

it on the market or into service under its own name or trademark. Providers carry the heavy end: risk management, data governance, technical documentation, logging capability, human-oversight design, accuracy and robustness requirements, quality management, conformity assessment, registration.

• A deployer uses an AI system under its own authority in a

professional context. Deployer obligations are lighter but real: use the system per the provider's instructions, assign competent human oversight, ensure input data is relevant, monitor operation, retain the automatically generated logs you control (at least six months), and inform affected workers where relevant.

Two traps worth engineering attention. The same company is routinely both — provider of the model it built, deployer of the SaaS AI it buys. And a deployer can become a provider by putting its own name on a system, substantially modifying one, or repurposing a system into a high-risk use. If your team fine-tunes a vendor model and ships it to customers under your brand, you may have quietly picked up provider obligations. That determination belongs in your architecture review, not in a post-incident scramble.

Classification: where does each system actually sit?

The Act is tiered. Prohibited practices (social scoring, certain biometric and manipulation use cases) are already banned. At the other end, minimal-risk systems — most of what a typical business runs — carry no new hard obligations beyond honesty about what they are. Limited-risk systems (chatbots, synthetic media) carry transparency duties: people must be able to tell they're interacting with AI.

The tier that August is about is high-risk. Leaving aside AI embedded in regulated products, the list that matters for most companies is Annex III: biometrics, critical infrastructure, education and vocational training, employment and worker management (CV screening, promotion and termination decisions), access to essential services (credit scoring, insurance pricing), law enforcement, migration, and administration of justice. The pattern: AI making or materially shaping consequential decisions about people's lives.

Classification sounds like a legal exercise; in practice it's an inventory exercise, and inventory is an engineering problem. You cannot classify what you haven't listed, and in every organisation we've looked at, the list is longer than anyone expected once you include vendor features (the AI quietly embedded in your HR suite and CRM) and shadow AI (the tools individual teams adopted without approval). Many companies discover exactly one workflow — often CV screening or credit decisioning — that quietly crossed into Annex III territory while everything else stays minimal-risk. That one workflow is where the work is.

The obligations, translated into software

Here's the part that matters for builders: nearly every high-risk obligation has a natural software implementation, and implementing it as software is both cheaper and more defensible than maintaining it as documents. What the control objectives look like in practice:

• AI system inventory. A live register — not a spreadsheet that was

accurate in January — of every AI system in use or in development: purpose, owner, role (provider/deployer), risk tier, data touched, review date. This is the foundation everything else keys off, and it's a CRUD app plus an intake process, not a moonshot.

• Technical documentation and model cards. The Act requires

documentation sufficient to assess compliance: intended purpose, architecture, training-data provenance, performance metrics, known limitations, foreseeable misuse. A model card per production model, version-controlled next to the code and regenerated as part of the release pipeline, keeps this true by construction. A Word document on a shared drive drifts within a quarter.

• Record-keeping and logging. High-risk systems must be capable of

automatically recording events over their lifetime, and deployers must retain the logs they control. As software: structured decision logs capturing inputs, model version, output, confidence and the human involvement on each consequential decision — append-only, and replayable, so "why did the system decide X on 14 March?" is a query rather than an archaeology project.

• Human oversight. The Act requires that natural persons can

effectively oversee the system — understand its outputs, decide not to use them, intervene or interrupt. Engineered, that means confidence-threshold escalation into review queues, explicit override paths that are themselves logged, and a kill switch that degrades to a rule-based fallback instead of an outage.

• Accuracy, robustness and post-market monitoring. Declared

performance metrics, an evaluation harness that gates model and prompt changes on regression tests, drift monitoring in production, and an incident process — serious incidents in high-risk systems carry reporting duties with short clocks, which you can only meet if detection is automated.

None of this is exotic. It's the same discipline mature engineering teams already apply to payments or PII, pointed at model behaviour.

A 90-day-shaped checklist

• Build the inventory, including vendor and shadow AI. Assign owners.
• Classify each system: role (provider/deployer/both) and risk tier.

Document the reasoning even where the answer is "minimal risk".

• For anything plausibly Annex III: gap-assess against the high-risk

obligations that apply to your role, and sequence remediation by exposure, not by ease.

• Stand up decision logging and model cards for the systems that need

them first — they're prerequisites for almost everything else.

• Design human oversight into the workflow (queues, thresholds,

overrides, kill switch) rather than bolting a review step on top.

• Write the incident playbook before you need it.

A candid note on the timetable: there has been sustained lobbying in Brussels to soften or stagger parts of it, and interpretive guidance and harmonised standards are still maturing. We'd treat that as noise for planning purposes. The obligations as enacted apply from 2 August 2026, the controls above are worth having on pure engineering-quality grounds regardless of enforcement posture, and retrofitting logging and oversight under deadline pressure is the most expensive way to get them.

If you want a structured version of this exercise — inventory, per- system classification, gap analysis and a prioritised remediation roadmap in two weeks, with the controls implemented as working software rather than shelf-ware — that's exactly what our AI governance & EU AI Act readiness service does. And to repeat the disclaimer once more, because it matters: this post is engineering guidance, not legal advice.