Annex VIII

15
Sep
2026

Public bodies must refuse unregistered high-risk AI

Article 26(8) of the EU AI Act (Regulation (EU) 2024/1689) tells a public-authority deployer that when it establishes that the high-risk AI system it intends to use is not registered in the EU database, it does not use that system, and it notifies the provider or distributor. That’s a duty to refuse — triggered not by anything the deployer did wrong, but by someone else’s paperwork. It turns a database entry into a live precondition of go-live, and almost no procurement guidance treats it that way.

The rule and what it forces into your process

The answer first: a public authority or Union institution can’t lawfully put a high-risk system into service, or continue using one, once it has established the system isn’t registered. That has to become a checkpoint in the procurement and deployment process, not a compliance afterthought — a database lookup before go-live, and a clause in the contract that puts the burden of registration where the Act puts it.

What the public-authority deployer files itself

Registration in the EU database splits by who’s doing the filing. Providers file Annex VIII Sections A and B. But before putting an Annex III high-risk system into service or using it — with the same critical-infrastructure exception discussed below — deployers that are public authorities, institutions, bodies or agencies of the Union, or anyone acting on their behalf, have to do three distinct things: register themselves, select the system in the database, and register their use of it. That’s Annex VIII Section C, and it’s the deployer’s own filing, separate from anything the provider submitted, including a summary of the data protection impact assessment carried out under Article 35 GDPR where one was required.

When your registration disappears from public view

Not every entry is public. Annex III points 1, 6 and 7 — biometrics, law enforcement, and migration, asylum and border control management — go into a secured, non-public section of the database instead, and even there, only a specific, limited slice of the data makes it in: most of Annex VIII Section A (with three points excluded), five core points of Section B plus two more, the first three points of Section C, and four specified points of Annex IX. Access to that section is restricted to the Commission and the national authorities named for this purpose — and those authorities are typically the same ones that supervise data protection under the GDPR or the Law Enforcement Directive, not a separate, generic AI regulator. If you’re picturing a general market-surveillance body reading these files, picture your national data protection authority instead.

There’s a wrinkle worth knowing rather than glossing over: the same provision that names those data-protection authorities as the relevant overseers also covers Annex III point 8 — justice and democratic processes — but point 8 registrations themselves aren’t swept into the non-public section the way points 1, 6 and 7 are. Who regulates and where the entry lives aren’t drawn along quite the same lines, and it’s easy to conflate the two.

Real-world testing is invisible by default

A related blind spot: information submitted about testing high-risk systems under real-world conditions, outside a regulatory sandbox, is accessible only to market surveillance authorities and the Commission — not the public — unless the provider has specifically consented to make it public too. That default holds even for systems that would otherwise sit in the ordinary public section once fully registered; testing data gets the more cautious treatment until the provider opts in. And for providers of the same sensitive categories — points 1, 6 and 7 in their law-enforcement, migration, asylum and border-control uses — real-world testing registers straight into that same secure non-public section rather than the general restricted-testing one; for critical infrastructure, it registers nationally, matching how that category is treated everywhere else in the database.

Two gaps to plan around

Critical infrastructure — Annex III point 2 — never appears in the EU database at all. It registers at national level instead, and the Act doesn’t name a single EU-wide register to check; the mechanism is whatever the relevant Member State has set up, and that isn’t uniform. If your system touches critical infrastructure, “check the EU database” is the wrong instruction to give your team.

The second gap runs the other way. Article 26(8)’s mandatory check-and-refuse duty is written for public-authority and Union-institution deployers specifically. Other deployers may register voluntarily, and the recitals encourage it, but they aren’t bound by this particular provision the way a public authority is. Don’t assume a private-sector counterpart is running the same check you are — for them, absent other obligations, it’s optional.

How to operationalise the check

A workable version of this is short: identify which Annex III paragraph the system falls under, and therefore which part of the database it should appear in — public, non-public, or national. Look for the actual entry rather than accepting a supplier’s assurance that one exists. Record that the check was made and what it found, as part of the procurement file, not a side note. If the entry is missing, escalate before go-live rather than after. And notify the provider or distributor in writing, since Article 26(8) makes that notification part of the obligation, not a courtesy.

Frequently asked questions

What if the provider tells us registration isn’t required?

Verify it yourself rather than relying on that assurance. Article 26(8)’s duty sits with you as the deployer — if you use the system anyway on the strength of the provider’s claim and it turns out registration was required and missing, the exposure is yours, not theirs.

Does a framework agreement help?

Not on its own. A framework or procurement agreement doesn’t substitute for checking the specific system instance you’re actually deploying — registration status attaches to the system, not to the contract you’re buying it under.

Who’s the deployer when a contractor operates the system on our behalf?

You still are, in substance. Article 49(3)’s registration duty extends explicitly to persons acting on behalf of a public authority or Union institution, which is built precisely to stop the relationship from being restructured away through a contractor.

What if the system is in the non-public section?

If it’s your own registration as the deployer, you have access to it. If you’re trying to verify a third-party provider’s registration in that same section before deploying their system, that’s a harder practical problem — access is restricted to the Commission and the specific national data-protection authorities named for this purpose, not to public authorities generally. Build that verification into your contract with the provider directly, rather than assuming you can look it up yourself.

Does this apply to a system already in service?

The Act’s general grandfathering protects systems already on the market from new obligations absent a significant change, and that logic would plausibly extend here too — but I haven’t found a source addressing the registration-check duty for legacy systems specifically, so treat this as a reasonable inference rather than a settled answer, and confirm it against current guidance before relying on it.

Posted by admin in Public Authority & Certified Provider Integrations Knowledge Base
07
Sep
2026

You still register the AI system you decided isn’t high-risk

Under Article 6(4) of the EU AI Act (Regulation (EU) 2024/1689), a provider who concludes under Article 6(3) that its Annex III system is not, in fact, high-risk still has to register that system in the EU database — with a short summary of the grounds on which it reached that conclusion. That entry sits in the public section. The Commission’s Digital Omnibus proposal of 19 November 2025 tried to delete this obligation outright. Both the Council, in its negotiating mandate of 13 March 2026, and the European Parliament’s IMCO and LIBE committees, in a joint report adopted five days later on a 101-9-8 vote, independently rejected the deletion. The final text reinstates registration, with streamlined content requirements. If your compliance plan was drafted off the November proposal, it’s currently wrong.

The rule in one paragraph

Exemption doesn’t mean invisibility. Concluding that your Annex III system clears the Article 6(3) bar doesn’t end your paperwork — it starts a different kind. You keep the internal assessment that got you to that conclusion, you file a summary of it in the EU database, and that summary sits where the public can read it.

The three database categories

The EU database sorts entries into three categories, and who files depends on which one applies:

  • Category 1 — genuinely high-risk systems under Article 6(2) and Annex III. Filed under Annex VIII Section A. The provider files.
  • Category 2 — systems a provider has assessed as not-high-risk under Article 6(3). Filed under Annex VIII Section B. The provider files.
  • Category 3 — high-risk systems used by public authority deployers. Filed under Annex VIII Section C, including a summary of the data protection impact assessment carried out under Article 35 GDPR. The deployer files, not the provider.

Category 2 is the one that catches people off guard, precisely because “not high-risk” sounds like an off-ramp from the database entirely. It isn’t.

What your competitors get to read

Category 2 entries go into the public section of the database, the same section genuinely high-risk registrations sit in. The public section is free to access, navigable, and machine-readable. That’s not a side effect — it’s the design.

The practical consequence is straightforward and easy to underestimate: the legal argument you’re relying on to stay out of the high-risk regime is a document a competitor, a journalist, or an NGO can read, and can challenge. If your reasoning under Article 6(3) is thin, it’s thin in public.

The Article 80 backstop

Article 80 gives market surveillance authorities a specific procedure for exactly this situation, and it’s worth reading in full rather than taking on faith. Where an authority has sufficient reason to believe a system a provider classified as not-high-risk is actually high-risk, it tests that classification against the Article 6(3) conditions and the Commission’s guidelines. If the test confirms the system is high-risk, the authority orders the provider to bring it into compliance within a deadline the authority sets. Miss that deadline, and fines follow under Article 99 — that’s the backstop the brief refers to, and it’s a real, specific consequence, not a vague risk of reputational harm.

There’s a second, sharper consequence sitting one paragraph later. If the authority’s review finds the provider classified the system as not-high-risk specifically to circumvent the Chapter III Section 2 requirements — not a good-faith misjudgment, but an evasive one — that draws its own, separately finable violation under Article 99.

And Article 80 names its own evidence source. In exercising their oversight, market surveillance authorities may carry out checks that take into account, in particular, information stored in the EU database. That’s not a general observation about transparency — it’s the Act telling authorities where to look first. Your Category 2 summary isn’t a filing that disappears into an archive; it’s a named input into exactly the kind of review Article 80 describes.

What the Omnibus changed

The sequence is worth having straight, because it moved more than once. The Commission’s Digital Omnibus package, published 19 November 2025, proposed deleting the Article 6(4) registration obligation for self-assessed not-high-risk systems entirely. The Council’s negotiating mandate of 13 March 2026 rejected that specific deletion while broadly aligning with the Commission elsewhere, reinstating a simplified registration obligation. Five days later, on 18 March 2026, the Parliament’s IMCO and LIBE committees adopted a joint report doing the same, by a 101-9-8 vote. A provisional political agreement reached on 7 May 2026 confirmed the reinstatement, with streamlined Annex VIII Section B content — fewer data points required in the filing, without removing the filing itself. Parliament adopted the final text on 16 June 2026, and the Council gave its final green light on 29 June 2026.

What’s actually different in the streamlined Section B, line by line, isn’t something I can confirm precisely — commentary consistently describes it as a reduced set of required data points rather than a restructured form, but I haven’t seen the specific before-and-after list. What isn’t in question is the outcome: the obligation survived a deletion attempt from its own drafter, unanimously rejected by both co-legislators before trilogue even started.

One more date worth anchoring this to: Annex III high-risk obligations, under the same reform, now apply from 2 December 2027 rather than the original 2 August 2026. The registration duty for Category 2 systems tracks that same timeline.

The one Annex III category that escapes the EU database

There’s a genuine exception, and it’s narrow. High-risk AI systems falling under Annex III point 2 — critical infrastructure — register at national level instead of in the EU database. The Act doesn’t name a single EU-wide national register to check; the obligation is simply pushed down to whichever Member State mechanism applies, and that mechanism isn’t uniform across the Union. If your system is critical-infrastructure-adjacent, “check the EU database” isn’t the right instruction to give your compliance team.

Frequently asked questions

Do I register before or after placing the system on the market?

Before. Registration is structured as a precondition tied to placing the system on the market or putting it into service, not a filing you make afterward to tidy up the paperwork. Treat the Article 6(3) assessment and the database entry as part of your go-live checklist, not a follow-up task.

What if my system triggers the profiling override?

Then Article 6(3) isn’t available to you at all. Any Annex III system also used to profile natural persons is high-risk regardless of how narrow, preparatory, or human-reviewed its role looks otherwise — there’s no exemption to claim. You’re in Category 1, filing under Annex VIII Section A, not Category 2.

Can I redact the grounds I file?

Not for a standard Category 2 entry — the summary of your grounds is what goes in the public section, and that’s the point of the filing. Restricted, non-public treatment is reserved for specific categories named in the Act, chiefly biometrics, law enforcement, migration and border control, and similar sensitive uses. A conventional HR, credit, or education system claiming the Article 6(3) exemption doesn’t get that treatment.

Who registers if we’re the importer, not the original developer?

Ordinarily, the original provider — including one established outside the EU, acting through its EU authorised representative. You become the provider yourself, with the provider’s registration duty, only if you put your own name or trademark on the system, make a substantial modification to it, or modify a non-high-risk system’s intended purpose in a way that makes it high-risk. A straightforward import without any of that doesn’t shift the filing obligation onto you.

Does this apply to a system already on the market?

This is genuinely less settled than the rest of this piece. The Act’s general grandfathering rule protects high-risk systems already on the market from the new obligations unless they undergo significant changes, and the same logic would plausibly extend to a system you’d assessed, before the relevant date, as not needing Article 6(3) registration at all. But I haven’t found a source that addresses this specific edge case directly, so treat it as a reasonable inference rather than a confirmed answer, and check it against the Commission’s guidance before relying on it.

Posted by admin in Digital Operational Compliance & EU AI Act Knowledge Base
08
Aug
2026

Targeted job ads are high-risk AI under Annex III

Annex III point 4(a) of the EU AI Act (Regulation (EU) 2024/1689) covers AI intended to be used for recruiting or selecting natural persons, “in particular for placing targeted job advertisements, analysing and filtering applications, and evaluating candidates.” Targeted job advertising is named first, ahead of application filtering and candidate evaluation, in the operative text itself. Most HR compliance programmes classify the applicant tracking system and the interview-scoring tool without ever looking at the ad-targeting stack behind a recruitment campaign — because that stack usually sits with marketing, not HR, and nobody told marketing this Annex applies to them too.

What Annex III point 4 actually lists

Point 4(a) covers recruiting or selecting natural persons, with three named examples: placing targeted job advertisements, analysing and filtering applications, and evaluating candidates. Point 4(b) covers a separate category — decisions affecting the terms of a work-related relationship, promotion or termination of a work-related contract, allocating tasks based on an individual’s behaviour or personal traits, and monitoring or evaluating the performance and behaviour of people already in that relationship.

Why the ad stack is the blind spot

Follow where ownership actually sits inside a typical organisation. The applicant tracking system has an HR owner, and by now usually has an AI Act classification attached to it. The audience-targeting model deciding who sees a given job advertisement — built into or bolted onto a recruitment marketing campaign — has a marketing owner, and in most organisations no classification has ever been attempted. Both sit inside the same legal category. Annex III point 4(a) doesn’t distinguish between the system that decides who to interview and the system that decides who gets shown the ad in the first place; it names the second one first.

Can you exempt out under Article 6(3)?

Article 6(3) lets a provider treat an Annex III system as not high-risk where it poses no significant risk of harm and meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns or deviations from them without replacing or influencing a previously completed human assessment without proper human review; or it performs a preparatory task for an assessment relevant to an Annex III use case.

Test an ad-targeting model against these honestly rather than reaching for whichever sounds closest. Deciding which individuals see a job advertisement, based on inferred interests, behaviour, or demographic proxies, is not a narrow procedural task — it’s a substantive targeting decision, arguably the central function of the model. It’s a weak fit for “improving a previously completed human activity” unless a human already decided the exact audience and the model only optimises delivery mechanics within that fixed audience. It doesn’t detect patterns or deviations from prior decisions in the way the third ground contemplates. And it’s a stretch to call the core targeting decision merely “preparatory” to some later assessment, when the targeting decision is often the entire point of the system.

The override that ends the argument

Even where one of the four grounds might plausibly fit, Article 6(3) closes with an override that applies notwithstanding all of them: an Annex III system is always considered high-risk if it carries out profiling of natural persons. No exemption survives that. An audience model built on individual behavioural traits — inferred interests, browsing history, demographic signals used to decide who sees what — is profiling by any ordinary reading of the term. That ends the Article 6(3) argument regardless of how well the model might otherwise have fit one of the four narrow grounds.

The price of claiming the exemption anyway

If you conclude your ad-targeting model genuinely clears Article 6(3) despite this, the exemption doesn’t make the system invisible. You keep the underlying assessment, and you register the system in the EU database with a summary of the grounds you relied on — and that summary sits in the database’s public section, readable by anyone, including a competitor or an advocacy group. The mechanics of that registration duty, and what happens if a market surveillance authority later disagrees with your classification, are covered in full in a companion piece on Article 6(3) registration and Article 80 enforcement rather than repeated here.

When this bites

Annex III obligations now apply from 2 December 2027, following the Digital Omnibus deferral, once the amending regulation is actually published in the Official Journal. Recruitment and employment systems sit in the Annex III categories that go through internal-control self-assessment rather than a notified body, so unlike biometric AI, there’s no third-party capacity bottleneck standing between now and that date. The sixteen-odd months between now and then are for inventory and classification work specifically — finding every system that touches recruitment, including the ones marketing owns — and that work doesn’t depend on any external standard or authority being ready first. Nothing about the extended timeline changes what needs to be found; it only changes how much time there is to find it.

Frequently asked questions

Does using LinkedIn’s ad targeting make us a deployer?

Likely yes. The platform is ordinarily the provider of the underlying targeting system, and the business running a recruitment campaign through it is the deployer — deployer obligations attach to you regardless of who built the model underneath the campaign tool you’re using.

What if the vendor says their tool isn’t high-risk?

Verify it yourself rather than relying on that assurance. The classification decision, and the consequences if a market surveillance authority later disagrees with it, attach to whoever is actually making the call — a vendor’s own marketing claim about its product’s risk tier doesn’t relieve you of that.

Are we the provider or the deployer?

Ordinarily the deployer, using a system someone else built. You become a provider yourself only if you put your own name or branding on the system, substantially modify it, or change a non-high-risk system’s intended purpose in a way that makes it high-risk — the same test that applies to importers and rebranders elsewhere in the Act.

Does a job board’s own matching algorithm count?

To the extent a job board’s algorithm recruits, selects, or filters candidates on an employer’s behalf, that function sits inside Annex III 4(a) in its own right — with the job board as a plausible provider of that specific functionality and the posting employer as its deployer.

Does an internal mobility tool count?

That sits closer to Annex III 4(b) than 4(a) — assessing existing employees for promotion or transfer eligibility is a decision affecting the terms of an employment relationship, not external recruitment. The same profiling override applies equally regardless of which limb of point 4 the tool falls under.

Posted by admin in Workforce, Labour & HR Compliance Reporting