EU AI Act Annex III: Which High-Risk Obligations Must Deployers Meet by August 2026?

Most teams treat "August 2026" as the moment every high-risk AI obligation switches on. It is not that clean.

The AI Act applies from 2 August 2026 as its general date. But the Act also carves out specific timelines, and it splits obligations between two very different roles: the provider who builds and places the system on the market, and the deployer who uses it under their own authority.

The brief that landed on most compliance desks reads "deployer obligations by August 2026." Read the source text and a sharper picture emerges. Several of the duties people file under "deployer" — the risk management system, data governance, the logging design — are written as provider obligations. Deployers inherit a narrower, but still demanding, set.

If you are scoping your own AI estate, getting that split right is the difference between building controls you actually owe and building controls someone else owes you.

This piece walks the Annex III classification, the real phasing, and the obligation areas — risk management, data governance, human oversight, and logging — with the provider/deployer line drawn honestly at each step.

What makes an AI system Annex III high-risk (and what falls outside the list)?

The AI Act has two routes into the high-risk category, and they are governed by different paragraphs of Article 6.

The first route (Article 6(1)) covers AI that is a safety component of a product — or is itself a product — covered by existing Union harmonisation legislation listed in Annex I, where that product already requires third-party conformity assessment.

The second route (Article 6(2)) is the one most organisations care about: AI systems whose use case is listed in Annex III are high-risk on that basis alone.

Annex III enumerates a set of use-case areas — including biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, and administration of justice and democratic processes. Read the current Annex III text and the Commission's guidance directly before you finalise scope; the corpus this article is grounded in cites the cross-references to specific Annex III points (point 1(a) biometric identification, point 2, and points 5(b) and (c)) but I will not invent the full enumerated wording.

Here is the nuance that catches teams out: being in an Annex III area does not automatically make a system high-risk.

Article 6(3) provides a derogation. A system listed in Annex III is not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing decision outcomes.

That derogation applies in four situations:

→ the system performs a narrow procedural task → it improves the result of a previously completed human activity → it detects decision-making patterns or deviations and is not meant to replace or influence a prior human assessment without proper review → it performs a preparatory task to an assessment relevant to an Annex III use case

There is a hard backstop. Under Article 6(3), a system that performs profiling of natural persons is always high-risk, regardless of the derogation.

And the derogation is not self-certifying without a paper trail. Article 6(4) requires a provider who concludes its Annex III system is not high-risk to document that assessment before placing the system on the market, register under Article 49(2), and produce the documentation on request from national competent authorities.

So the boundary is not binary. It is a documented judgement, and Article 6(5) commits the Commission to issue guidelines and a list of practical high-risk and not-high-risk examples no later than 2 February 2026. If you are scoping a borderline system, that guidance is the reference point.

How do you scope your own systems against the eight Annex III use-case categories?

Scoping is an inventory problem before it is a legal one.

You cannot apply Article 6 to a system you have not catalogued. The first move is a complete register of AI systems in use, mapped to intended purpose — because high-risk classification turns on intended purpose, not on the underlying model's general capability.

For each system, walk this sequence:

→ Identify the Annex III area the intended purpose falls into (if any). → If none applies, the system is not Annex III high-risk under Article 6(2). Document why. → If an area applies, test the Article 6(3) derogation: narrow procedural task, improvement of completed human work, deviation detection without replacing human judgement, or preparatory task. → Check the profiling backstop. If the system profiles natural persons, it is high-risk and the derogation does not rescue it. → Where the derogation is claimed, capture the documented assessment Article 6(4) requires.

A practical note for groups and financial entities: the same model can be high-risk in one deployment and out of scope in another, because intended purpose differs. Scope at the deployment level, not the vendor level.

This is also where the provider/deployer question first bites. If you procure a high-risk system, the provider should already have classified it and, where relevant, carried out conformity assessment. Your scoping exercise validates their classification against your actual use — it does not replace it. A platform that maps Annex III categories to source-grounded controls (the approach behind aegis-grc.com's AI Act tooling) turns this from a spreadsheet exercise into a repeatable, evidenced one.

Which deployer obligations actually trigger in August 2026 versus earlier phases?

This is where precision matters most, and where the "August 2026 deadline" shorthand misleads.

Article 113 sets the phasing. The Regulation applies from 2 August 2026 as the general date. But the same article carves out earlier and later milestones:

→ Chapters I and II apply from 2 February 2025 — that includes the prohibited practices in Article 5 and the AI literacy duty in Article 4, which binds both providers and deployers. → A further set of provisions — including Chapter V (general-purpose AI models), parts of governance, penalties, and Article 78 — apply from 2 August 2025, with the exception of Article 101. → Article 6(1) and its corresponding obligations apply from 2 August 2027.

Read that last point carefully. The Annex I product-safety route (Article 6(1)) and its obligations are explicitly deferred to August 2027.

The Annex III high-risk obligations — the Article 6(2) route — fall under the general 2 August 2026 application date. So for Annex III systems, August 2026 is the operative milestone. For Annex I product-integrated systems, it is August 2027.

If your high-risk exposure is Annex III, plan to August 2026. If it is the product-safety route, you have a year longer. Do not collapse the two.

Within that August 2026 set, the genuinely deployer-facing obligations live in Article 26:

→ use the system in accordance with the provider's instructions for use (Article 26(1)) → assign human oversight to natural persons with the necessary competence, training and authority (Article 26(2)) → where the deployer controls input data, ensure it is relevant and sufficiently representative (Article 26(4)) → monitor operation and report risks and serious incidents to the provider and market surveillance authority, suspending use where warranted (Article 26(5)) → keep automatically generated logs for an appropriate period of at least six months (Article 26(6)) → inform workers and their representatives before workplace deployment (Article 26(7)) → for public authorities, comply with registration obligations under Article 49 (Article 26(8)) → use provider information to support a data protection impact assessment where one is required (Article 26(9)) → inform affected natural persons where the system makes or assists decisions about them (Article 26(11))

A separate duty sits in Article 27: a fundamental rights impact assessment. It applies before deployment of an Article 6(2) high-risk system — with the exception of systems in the area listed in point 2 of Annex III — for deployers that are public bodies or private entities providing public services, and for deployers of systems referred to in points 5(b) and (c) of Annex III. It is not a universal deployer duty; it is scoped to those categories.

Mapping these triggers against your organisational profile is the work that turns a deadline into a plan.

What does a compliant risk management system look like under Article 9?

Here is the honest correction the brief invited. The Article 9 risk management system is a provider obligation.

Article 9 requires that a risk management system be established, implemented, documented and maintained for high-risk AI systems. Article 9(9) makes the actor explicit — "providers shall give consideration" to adverse impact on persons under 18 and other vulnerable groups when implementing it. The system is the provider's.

That said, knowing what good looks like matters to deployers too, because you are relying on it and you should assess it during procurement.

Under Article 9(2), the risk management system is a continuous, iterative process across the entire lifecycle, with regular systematic review. It must:

→ identify and analyse known and reasonably foreseeable risks to health, safety and fundamental rights in intended use → estimate and evaluate risks arising in intended use and under reasonably foreseeable misuse → evaluate other risks from post-market monitoring data gathered under Article 72 → adopt appropriate, targeted risk management measures

Article 9(5) sets the bar for those measures: residual risk for each hazard, and overall, must be judged acceptable. Risks should be eliminated or reduced by design as far as technically feasible, then mitigated with controls, then addressed through information and, where appropriate, training to deployers.

Testing is not optional. Article 9(6) to (8) require testing to identify the most appropriate measures, against prior-defined metrics and probabilistic thresholds, performed throughout development and in any event before the system is placed on the market or put into service.

For deployers, the practical takeaway: you do not build the Article 9 system, but you should demand evidence of it. The provider's risk management documentation, test metrics, and the instructions for use under Article 13 are what let you discharge your own Article 26 duties — particularly the human oversight assignment and the input-data obligation.

How strict are the data governance and bias-monitoring duties under Article 10?

Same correction, same reason. Article 10 is primarily a provider obligation, and the source text confirms it — Article 10(5) refers to "the providers of such systems" when setting conditions for processing special categories of personal data.

Article 10 applies to high-risk systems trained on data, and requires training, validation and testing data sets to meet quality criteria. The data governance practices under Article 10(2) must address, among other things:

→ design choices and the origin of data, including the original collection purpose for personal data → data preparation: annotation, labelling, cleaning, updating, enrichment, aggregation → assumptions about what the data is supposed to measure → an assessment of availability, quantity and suitability → examination for possible biases likely to affect health and safety, harm fundamental rights, or lead to prohibited discrimination → appropriate measures to detect, prevent and mitigate those biases → identification of data gaps and how they are addressed

Article 10(3) sets the substantive standard: data sets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete for the intended purpose, with appropriate statistical properties for the persons the system will be used on.

There is a narrow bias-correction allowance in Article 10(5): providers may exceptionally process special categories of personal data strictly for bias detection and correction, subject to a stack of conditions — that no other data (including synthetic or anonymised) would work, technical re-use limits, state-of-the-art security and pseudonymisation, no onward transmission, deletion once bias is corrected or retention ends, and documented justification in the records of processing.

Where does the deployer fit? Article 26(4): to the extent you control input data, you must ensure it is relevant and sufficiently representative for the intended purpose. That is your slice of the data-quality duty. The training-data governance belongs to the provider; the operational input data you feed the system is yours.

What counts as meaningful human oversight under Article 14?

Human oversight is a shared duty, and the split is instructive.

Article 14 places the design obligation on the provider: high-risk systems must be built so they can be effectively overseen by natural persons during use, including through appropriate human-machine interface tools. Article 14(3) requires oversight measures either built into the system by the provider, or identified by the provider as appropriate for the deployer to implement — or both.

Article 14(4) sets out what those overseers must be enabled to do. As appropriate and proportionate, they must be able to:

→ understand the system's relevant capacities and limitations and monitor its operation, including detecting anomalies and unexpected performance → stay aware of automation bias — the tendency to over-rely on system output, especially where the system informs human decisions → correctly interpret the output, using available interpretation tools → decide not to use the system, or to disregard, override or reverse its output → intervene or interrupt the system through a stop function that brings it to a safe state

The deployer's piece is Article 26(2): assign human oversight to natural persons who have the necessary competence, training and authority, plus the necessary support. The provider builds the affordances; the deployer staffs and empowers the oversight.

One obligation deserves separate attention because of who carries it and how strict it is.

For high-risk systems referred to in point 1(a) of Annex III — biometric identification — Article 14(5) requires that no action or decision be taken on the basis of the identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority. The Act carves out a narrow exception for law enforcement, migration, border control and asylum where Union or national law considers the requirement disproportionate.

That two-person rule is a control, not a principle. If you deploy biometric identification in scope of point 1(a), build the four-eyes verification into the workflow and evidence it.

How long must you keep automatic logs, and what must they capture?

Logging is split across design and retention, and the deployer owns the retention end.

Article 12 puts the design duty on the system: high-risk AI must technically allow automatic recording of events (logs) over its lifetime. Article 12(2) ties logging to traceability — recording events relevant to identifying Article 79(1) risks or substantial modifications, facilitating post-market monitoring under Article 72, and monitoring operation under Article 26(5).

For biometric systems in point 1(a) of Annex III, Article 12(3) sets a minimum content standard. Logs must record, at a minimum:

→ the period of each use (start and end date and time) → the reference database against which input data was checked → the input data for which the search produced a match → the identification of the natural persons involved in verifying the results, as referred to in Article 14(5)

Retention is where provider and deployer duties run in parallel. Article 19 requires providers to keep automatically generated logs under their control for a period appropriate to the intended purpose, of at least six months, unless other Union or national law (in particular data protection law) provides otherwise.

Article 26(6) mirrors this for deployers: keep the logs automatically generated by the system, to the extent they are under your control, for at least six months, subject to the same data-protection caveat.

So the headline number is "at least six months" — a floor, not a ceiling. Appropriate-to-purpose may demand longer, and personal-data rules may pull in either direction.

A carve-out matters for regulated finance. Article 19(2) and Article 26(6) both provide that financial institutions subject to internal governance requirements under Union financial services law maintain these logs as part of the documentation kept under that financial services law. Article 26(5) gives a parallel deemed-compliance route for the monitoring obligation. If you are a financial entity, you are not building a second logging regime — you are folding AI logs into your existing one. That is a meaningful reduction in net new control surface, and worth confirming against your DORA and sectoral record-keeping setup.

How do you build an audit-ready evidence trail across all four obligation areas?

Compliance is what you can prove, not what you intend.

The four obligation areas in this article each generate distinct evidence, and a defensible file ties each piece back to the source article and the specific system.

For classification, keep the Annex III scoping decision per system, the Article 6(3) derogation analysis where claimed, and the Article 6(4) documented assessment for systems judged not high-risk.

For risk management and data governance, retain the provider's Article 9 documentation, test metrics and thresholds, and the Article 10 data governance records — obtained at procurement. Where you control input data, evidence your Article 26(4) representativeness checks.

For human oversight, record the named overseers, their competence and authority (Article 26(2)), the oversight measures implemented from the instructions for use, and — for point 1(a) biometric systems — the two-person verification logs Article 14(5) demands.

For logging, retain the logs themselves for the appropriate period of at least six months (Article 26(6)), plus the policy that sets retention against intended purpose and data-protection constraints.

Add the cross-cutting items: the fundamental rights impact assessment where Article 27 applies, the affected-person notifications under Article 26(11), worker information under Article 26(7), and the AI literacy measures under Article 4 that have applied since February 2025.

The hard part is not collecting any one of these. It is keeping them current as systems change, traced to the article that demands them, and reproducible for an auditor who will ask "show me." That is precisely the failure mode of a folder-and-spreadsheet approach — evidence drifts out of date and nobody can map it back to an obligation.

An audit-ready evidence model that anchors each control to its source article and surfaces gaps before an assessor does is the difference between a roadmap and a fire drill.

See how aegis-grc.com maps Annex III obligations to source-grounded controls — answer once, assess everything.

FAQ: Annex III scoping, deadlines, and deployer-versus-provider duties

Is every AI system used in an Annex III area automatically high-risk?

No. Article 6(3) provides a derogation where the system does not pose a significant risk to health, safety or fundamental rights — for narrow procedural tasks, improving completed human work, detecting deviations without replacing human judgement, or preparatory tasks. But a system that performs profiling of natural persons is always high-risk, and a provider claiming the derogation must document that assessment under Article 6(4).

Do all high-risk obligations start on 2 August 2026?

The Regulation applies generally from 2 August 2026, which is the operative date for Annex III (Article 6(2)) high-risk systems. But Article 113 defers Article 6(1) — the Annex I product-safety route — and its corresponding obligations to 2 August 2027. Earlier milestones apply too: prohibited practices and AI literacy from 2 February 2025, and general-purpose AI and governance provisions from 2 August 2025.

Are Article 9 risk management and Article 10 data governance deployer duties?

Primarily no. The source text frames both as provider obligations — Article 9(9) and Article 10(5) name providers as the actor. Deployers carry the obligations in Article 26: using the system per instructions, assigning competent human oversight, ensuring input data they control is representative (Article 26(4)), monitoring, log retention, and notifications. Deployers should still obtain and assess the provider's Article 9 and Article 10 documentation to discharge their own duties.

How long must deployers keep AI system logs?

At least six months, to the extent the logs are under the deployer's control, for a period appropriate to the intended purpose (Article 26(6)) — unless other Union or national law, particularly data-protection law, provides otherwise. Financial institutions may maintain these logs as part of the documentation kept under Union financial services law, rather than building a separate regime.