When the EU agreed to delay the AI Act’s high-risk obligations, the law firms called it relief almost to a word. Their alerts landed within days, all variations on the same competent summary: deadlines extended, here’s the new timeline, contact us with questions. The framing was near-unanimous, and in one specific way it was wrong. I’d spent the previous months turning those obligations into a blueprint for Annex III compliance: a catalogue of 79 controls, each mapped to a specific article and worked through against a CV-screening use case, with the hardest controls written out in code. From where I sit, the delay isn’t relief. It removes the pressure to act without removing any of the work. Here’s why, starting with what the law actually is.
The EU AI Act, formally Regulation (EU) 2024/1689, is the first broad, cross-sector law for artificial intelligence anywhere in the world. It entered into force in August 2024 and phases in through 2030. It doesn’t regulate AI by sector or by the technology underneath. It regulates by risk, sorting every system into one of four tiers:
- Unacceptable risk. Banned outright: social scoring, subliminal manipulation, untargeted facial scraping. (Art. 5.)
- High risk. Allowed but heavily regulated: the systems that decide who gets a job, a loan, a university place, or bail. Almost all of the real obligations live here, in Articles 8–15. It’s the tier this article is about.
- Limited risk. Transparency duties only: you have to be told when you’re talking to a bot or looking at a deepfake. (Art. 50.)
- Minimal risk. The overwhelming majority of AI, left unregulated.
On top of all of it sits a separate regime for general-purpose AI models, the foundation models that everything else now gets built on. The Act also applies to two roles: providers, who build systems, and deployers, who use them. The line between the two is thinner than most companies assume, and I’ll come back to it.
On 19 November 2025 the Commission proposed a Digital Omnibus, a package of changes that amends several digital-era laws at once, the AI Act among them. On 7 May 2026 the Council and Parliament reached political agreement on the AI part. The main effect: full enforcement of the high-risk rules (Annex III: employment, credit scoring, education, biometrics, law enforcement) is pushed back from 2 August 2026 to 2 December 2027, a sixteen-month delay. The Annex I systems built into regulated products move from August 2027 to August 2028.
The gap between the law and the controls
The AI Act is written in obligations, not controls. Article 14 says a high-risk system must be “designed and developed in such a way … that [it] can be effectively overseen by natural persons during the period in which the AI system is in use.” That’s a requirement, not a specification. It doesn’t tell you what to build, what to log, what to test, or how to show an auditor you did any of it. Every article in the high-risk chapter reads like this: a statement of intent that no engineer can build from directly.
Between the obligation and a working system that meets it sits a translation job, and that translation is the real work. A control is something you can run, log, and fail a test against. If you can’t, you don’t have a control. You have an intention. Turning those intentions into working controls is exactly where the law firms stop and the architects start. The alerts can tell you the deadline moved. They can’t tell you that what the deadline covers is many months of engineering work.
That gap is what this article is about: what actually changed in May, why high-risk compliance is a build and not a deadline you sprint toward, and, for most of what follows, what two of those 79 controls look like once you stop reading the law and start building it.
What actually changed
The facts first, because the argument depends on them.
The Omnibus is now law. The Council and Parliament reached political agreement on 7 May 2026, the Parliament approved the text on 16 June, and the Council gave it final approval on 29 June. It was adopted as Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal on 24 July, and entered into force on 27 July, the third day after publication.
(Update, 28 July 2026: this section originally said the Omnibus was “adopted but not yet in force” and warned against planning around a date not yet in the Official Journal. That caveat expired when the regulation entered into force on 27 July. The deferrals below are now binding law rather than political agreement, which removes the planning risk but changes none of the argument: the work still has to happen, and the clock still runs to December 2027.)
What the agreement moves:
- Standalone high-risk (Annex III): 2 Aug 2026 → 2 Dec 2027. The full weight of Articles 8–15: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity.
- High-risk in regulated products (Annex I): 2 Aug 2027 → 2 Aug 2028. Medical devices, machinery, vehicles.
What the agreement doesn’t touch is the part the “relief” story leaves out:
| Obligation | Status | Max penalty (Art. 99/101) |
|---|---|---|
| Prohibited practices (Art. 5) | In force since 2 Feb 2025 | €35M / 7% turnover |
| GPAI model obligations (Art. 53, 55) | In force since 2 Aug 2025 | €15M / 3% turnover |
| Transparency / disclosure (Art. 50) | 2 Aug 2026 — did not move | €15M / 3% turnover |
| Standalone high-risk (Art. 8–15) | Deferred to 2 Dec 2027 | €15M / 3% turnover |
Two things matter here. First, only the Art. 5 prohibited practices sit at the headline €35M / 7% tier. The high-risk, transparency and GPAI obligations are the €15M / 3% tier (GPAI under its own Art. 101 regime). If you’ve seen “7%” quoted against high-risk systems, that’s wrong. Second, the transparency obligations (chatbot disclosure, deepfake labelling, emotion-recognition notification) still land on 2 August 2026. For systems already on the market, the content-marking duties (provider machine-readable marking under Art. 50(2), deployer labelling under Art. 50(4)) carry a short grace period to 2 December 2026. None of that was deferred.
The same package even tightened the rules in one place: it added a new ban on AI built to generate non-consensual sexual imagery and child sexual abuse material (CSAM), with compliance due by 2 December 2026. The Omnibus delayed high-risk enforcement and banned a new category of system at the same time.
And as of 2 June 2026 the Commission has appointed the Scientific Panel of 60 independent experts, alongside a 174-member Advisory Forum, to advise the AI Office and support enforcement, focused at first on general-purpose models.
I keep the full, up-to-date picture on a tracker with verified dates, what’s in force and what’s still pending.
Sources: Regulation 2024/1689 Art. 5, 19, 26, 50, 53, 55, 99, 101; Council and Parliament agreement on the Digital Omnibus, 7 May 2026; Parliament endorsement, 16 June 2026; Council final adoption, 29 June 2026.
First question: are you even high-risk?
Before any controls, there’s a step most coverage skips: working out whether you’re even in scope. A deployer should run it first.
Being listed in Annex III doesn’t automatically make a system high-risk. Article 6(3) carves out systems that only do a narrow procedural task, improve work a human already finished, or spot patterns without replacing or influencing a human decision. If you genuinely qualify, you document the assessment, register the system, and you’re out from under the Article 8–15 weight.
The catch, and the reason CV-screening is my reference case: profiling of natural persons is always high-risk, and a system that ranks or filters candidates directly affects who gets hired. So it doesn’t clear the Article 6(3) gate.
The second question is who you are. Most companies buying a hiring tool think of themselves as deployers, with the lighter Article 26/27 duties (assign human oversight, run a fundamental-rights impact assessment, keep logs, monitor). But Article 25 says the moment you put your name on a system, change it substantially, or change what it’s for, you become a provider and take on the full Article 8–15 build. A lot of “we just bought this” companies are providers and don’t know it.
Decide this first. It decides whether the rest of this article is your problem or your vendor’s.
Frameworks: EU AI Act Art. 6(3), Art. 25, Art. 26–27; NIST AI RMF MAP 1; ISO/IEC 42001 §6.1.
Why the delay is a build, not a deadline
The mistake to avoid: read “December 2027” as “later” and move the budget elsewhere.
The problem is that Annex III compliance isn’t a task you finish in a quarter. It’s a system with a dependency graph, and the slowest parts of it aren’t technical, they’re organisational:
FOUNDATION (start now: long lead, organisational)
├─ Art. 10 Data governance + bias study
├─ Art. 9 Risk management system
└─ Art. 14 Human oversight workflow
│ produces the records that…
▼
EVIDENCE (must run continuously, cannot be retrofitted)
├─ Art. 12 Logging ──► Art. 20 / 72 Post-market monitoring
│
▼
PROOF (only ever as good as everything above it)
├─ Art. 11 Technical documentation (Annex IV)
└─ Art. 43 Conformity assessment → registrationYou can’t make up for a late start by doing things in parallel, because each layer feeds the next. Technical documentation (Art. 11) comes after every other domain. You can’t document a risk-management process you haven’t built. Conformity assessment (Art. 43) comes after the documentation. Logging (Art. 12) and post-market monitoring (Art. 20, 72) run continuously, and you can’t go back and create a year of monitoring logs in November 2027. If the logs don’t exist by the time you go live, the evidence isn’t there, and no amount of budget buys back the months you missed.
Be realistic about the timeline. A data-bias study is a study, not a sprint. A human-oversight workflow means redesigning how people actually do the job. Setting up logging and monitoring before you go live takes months. For a single high-risk system you haven’t started, the realistic timeline is counted in months or even more than a year, and that’s per system, assuming the will to do it already exists. Count backwards from 2 December 2027 and the real start date is now.
Frameworks: EU AI Act Art. 9–15, 20, 72; NIST AI RMF GOVERN 1, MANAGE 2; ISO/IEC 42001 §8.
Control in depth #1: Human oversight (Art. 14)
This is the control that most clearly shows the gap between reading the Act and building it, so it’s the one to walk through.
Article 14 is usually summarised as “human in the loop.” That summary is where compliance programmes go to die, because it sounds like a checkbox and isn’t one. The blueprint breaks it into five controls. The one that does the real work is AISEC-HO-003 (Override and Intervention): the overseer must be able to decide not to use the output, to override it, or to reverse it. It’s paired with AISEC-HO-004 (Automation Bias): the design has to actively prevent reviewers from approving decisions without reading them.
The design decision that makes it real: in the reference design, the model can rank a candidate but it can’t issue a decision. Issuing sits behind a fixed check the model has no control over.
# Art. 14 — a screening decision cannot leave the system until a
# competent human has engaged with it. This is a deterministic gate,
# not an instruction in a prompt. The model ranks; it does not decide.
def finalize_screening_decision(candidate_id, model_output, review):
# AISEC-HO-003: a human override/intervention must exist and be recorded.
if review is None or review.reviewer_id is None:
raise OversightRequired(
"No human review on record — decision cannot be issued"
)
# AISEC-HO-004: the reviewer must have actually acted, not waved it through.
if review.action not in ("confirm", "override", "reject"):
raise OversightRequired("Unrecognised review action")
# An override must carry a real replacement decision.
if review.action == "override" and review.overridden_output is None:
raise OversightRequired("Override recorded with no replacement decision")
decision = (review.overridden_output
if review.action == "override"
else model_output)
log_event(EventType.DECISION_ISSUED, {
"candidate_id": candidate_id,
"model_version": model_output.model_version,
"reviewer_id": review.reviewer_id, # AISEC-LG-004
"review_action": review.action,
})
return decisionThere is no model call in that gate. No “the system prompt tells the model to ask for confirmation.” It’s pure control flow: is there a recorded reviewer, did they take a real action, yes or no. If you’ve read my agent-security work, this should look familiar. It’s the same principle as a tool authorizer. The model, which only ever gives you a guess, can’t be the thing that enforces the rule. The thing that enforces it has to be a fixed check that runs after the model.
What “done” looks like: every decision you issue carries a named overseer and an action they could have overridden, and a test proves that a decision with no recorded human review simply can’t be produced, not just that it’s discouraged.
Frameworks: EU AI Act Art. 14(4); NIST AI RMF GOVERN 1.4, MANAGE 2.4; ISO/IEC 42001 A.9; GDPR Art. 22.
Control in depth #2: Logging (Art. 12)
Logging is the control everyone agrees with and nobody schedules early, which is exactly why it’s dangerous. Article 12 requires automatic logging of risk-relevant events over the system’s lifetime, but it sets no retention period of its own. The six-month floor is a separate obligation: Article 19 for providers, Article 26(6) for deployers. The blueprint’s AISEC-LG-002 through LG-005 make the logging concrete, and LG-005 carries that six-month deployer floor.
The reason this can’t wait: you’re required to have the records for the whole operating life of the system. A logging setup you add a month before the audit gives you a month of logs. The control is the history itself, and history only builds up in real time.
A single decision should log something like this:
{
"event": "decision_issued",
"use_period": { "start": "2027-11-30T09:14:02Z",
"end": "2027-11-30T09:14:08Z" }, // AISEC-LG-002
"system_version": "cv-screen-2.3.1",
"model_version": "ranker-2026-09@sha256:1f3c…",
"reference_db": "candidates-2027Q4", // AISEC-LG-003
"input_ref": "application:4471f2", // AISEC-LG-003
"reviewer_id": "hr-overseer:emp-2087", // AISEC-LG-004
"review_action": "override",
"retained_until": "2028-05-30T00:00:00Z" // AISEC-LG-005
}Every field maps to a clause in the Act. The reviewer_id is the same value the Article 14 gate recorded. That’s the dependency graph made real: the oversight control produces the evidence the logging control has to keep and the monitoring control later reads. Build them out of order and they don’t connect.
Frameworks: EU AI Act Art. 12(2)–(3), Art. 19, Art. 26(6); NIST AI RMF MEASURE 2.3; ISO/IEC 42001 A.10; GDPR Art. 30; DORA Art. 6.
The other 77 controls
Two controls aren’t a compliance programme. I showed them in detail to make the scale clear: if one control is a fixed gate plus a test plus a logged record, then the full Article 8–15 surface is large. When I worked it out, it came to 79 controls across fifteen domains:
| Domain | Controls | Core articles |
|---|---|---|
| Risk Management | 6 | Art. 6, 9 |
| Data Governance | 6 | Art. 10 |
| Technical Documentation | 5 | Art. 11, Annex IV |
| Logging | 5 | Art. 12, 19 |
| Transparency | 5 | Art. 13, 50 |
| Human Oversight | 5 | Art. 14, 26 |
| Accuracy | 2 | Art. 15 |
| Robustness | 3 | Art. 15 |
| Cybersecurity | 6 | Art. 15(5) |
| Post-Market Monitoring | 4 | Art. 20, 72, 73 |
| Conformity Assessment | 5 | Art. 17, 43, 47–49 |
| Deployer Obligations | 5 | Art. 26, 27 |
| GPAI Systems | 5 | Art. 53, 55 |
| Prohibited Practices | 8 | Art. 5 |
| Governance & Oversight | 9 | Art. 4, 21, 25 |
The value is in the mappings. Each control is also cross-referenced to NIST AI RMF, ISO/IEC 42001, OWASP, MITRE ATLAS, GDPR and DORA. Interesting fact: if you already run an ISO 42001 management system or a DORA programme, you’ve already paid for a good part of Annex III. The overlap is real but uneven, and it’s worth being honest about where. Incident reporting, logging, and risk-management process carry over well. The AI-specific work (the bias gate, the explainability tooling, the fundamental-rights monitoring) mostly doesn’t. So the AI Act work isn’t 79 controls from scratch, but it isn’t 79 controls minus everything you already have either. Map each control against what you already run before you set the budget, because that’s where the real number is.
One correction to a common assumption, because it changes the plan: for most Annex III systems, conformity assessment is internal control (Annex VI), a self-assessment, not third-party assessment by a notified body. Notified-body involvement is the exception, largely for certain biometric systems (Annex VII). That sounds like good news but isn’t: self-assessment means you carry the burden of proving conformity, with no outside body to share it. The harmonised standards (CEN-CENELEC) that would give you a presumption of conformity are still being finalised, and that delay is a real planning risk, because until they arrive you’re judging yourself against the articles directly.
A plan you can actually fund
Here’s the dependency graph turned into something a budget committee can fund, in three phases:
Phase 1: start now (the slow work you can’t compress). List which systems are Annex III, GPAI, or transparency-only, and decide provider or deployer for each (Art. 25). Turn on Article 12 logging in any system you plan to deploy, because the history starts building today or never. Start the data-governance and bias study (Art. 10). If you’re in the biometric category that needs a notified body, get in the queue now.
Phase 2: the workflow redesign. Build the human-oversight gate and the explainability tooling that lets an overseer actually understand and override a decision (Art. 14), plus the post-market monitoring that reads the logs from Phase 1 (Art. 20, 72). This phase touches the people doing the job, which is why it’s slow, and why it follows the foundation instead of waiting on it.
Phase 3: the proof. Technical documentation (Art. 11, Annex IV) and the conformity assessment (Art. 43). This is the one part the delay actually lets you do properly instead of in a panic, as long as Phases 1 and 2 produced the evidence it documents. Documentation is the one place the extra sixteen months is a real gift. Logging is not.
What can’t move: anything continuous (logging, monitoring) and anything organisational (the bias study, the oversight workflow). What the delay actually buys you: time to do the documentation and assessment without cutting corners. Spend that gift there, not on the foundation.
The cost of getting it wrong is not the fine
CISOs don’t lie awake over the €15M / 3% headline. They lie awake over everything that comes with it. If a high-risk system is found non-compliant, the regulator can order it off the EU market, and a stop-use order on a hiring system is a major operational event, not a line item. There’s forced model retraining and revalidation. There’s the indemnity you owe the enterprise customers you sold it to. And for a CV-screening model specifically, there are the discrimination lawsuits that follow: a biased model is both a GDPR Article 22 problem and an employment-law problem, and those run alongside anything the AI Act regulator does. The fine is the most predictable, and probably the smallest, of the consequences.
What this is, and what it isn’t
The blueprint is a reference and a teaching tool. It is not legal advice, and it is not a substitute for formal conformity assessment or for an adviser’s reading of your specific situation. The control catalogue is my own reading of the high-risk requirements. A notified body or your own legal counsel may scope yours differently. What the repo gives you is the thing the regulatory alerts don’t: a concrete answer to what you actually have to build, with each control mapped back to the article it satisfies.
Treat it as a starting point to argue with, not a certificate to point at.
What I learned building it
Four things, in order of how much they changed how I think about the Act:
1. A control is code, a test, and a record, or it’s nothing. Saying “human in the loop” is easy. Decomposing it into the fundamentals is the hard part: the gate, the test that proves it, the record it leaves.
2. The dependency graph is the whole game. A late start can’t be rescued with money because the controls feed each other in order. Logging feeds monitoring, everything feeds documentation, and documentation feeds assessment. You build the foundation, then the floors.
3. The frameworks converge, and that’s a gift. I expected overlap between the AI Act, NIST AI RMF, ISO 42001, GDPR and DORA. I didn’t expect it to be this clean. Most companies have already paid for part of Annex III under another name. Finding that overlap is the single most useful thing a security architect can do before the budget conversation.
4. The delay is the most expensive thing to misread. Not because the date is close, but because “later” is the word that kills programmes with long lead times. The teams who treat 2 December 2027 as breathing room are the ones who’ll discover, in mid-2027, that the one thing they can’t buy back is the year of logs they never started.
The regulation didn’t get easier. The hardest part of it moved just far enough away to be ignored. Don’t.
Resources
- The live enforcement timeline: manzambi.com/tracker
- The 79-control blueprint: eu-ai-act-blueprint
- Regulation (EU) 2024/1689 — the AI Act
- NIST AI Risk Management Framework 1.0
- ISO/IEC 42001:2023 — AI Management Systems
- Companion piece on deterministic gates in agent security: Secure-By-Design-Agentic
Joseph Manzambi is a Cloud and AI Security Architect based in Málaga. He writes periodically on AI security and making EU AI Act compliance practical. manzambi.com/writing.