Annex III

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.

Aug

2026

The AI Act reaches companies that never targeted the EU

Recital 22 of the EU AI Act (Regulation (EU) 2024/1689) frames the Act’s reach beyond the EEA around output “intended to be used” there. Article 2(1)(c), the operative provision that actually does the work, drops the word “intended” entirely: it applies to providers and deployers established outside the EEA “where the output produced by the system is used in the [EEA].” White & Case’s own Handbook calls the two “inconsistent,” and works through what that inconsistency actually does to a business that never meant to come near EU law. The argument worth making explicitly, rather than leaving implicit: the operative text creates a jurisdictional trigger with no off-switch built in, and the recital that would have installed one has no binding force of its own.

The claim

Read literally, Article 2(1)(c)’s territorial trigger is an event downstream of the operator’s own control — a later, independent decision by someone else about where to use an AI system’s output — rather than a choice the operator itself makes. That is a genuinely unusual jurisdictional design for EU law, and it is not what Recital 22 says the rule is supposed to be.

How this differs from the GDPR, precisely

Article 3 GDPR turns on offering goods or services to, or monitoring, individuals in the EEA — both are tests shaped around the entity’s own intent or conduct. You come within the GDPR’s territorial scope by doing something aimed at the EEA. Article 2(1)(c) isn’t built the same way: nothing in its text asks what the provider or deployer meant to do. This is worth stating carefully rather than overstating — it’s a difference in what triggers the rule, not necessarily a difference in how ambitious EU lawmakers were being. The GDPR and the AI Act both clearly intend broad reach; only one of them ties that reach to the regulated party’s own choices.

The worked example, in full

White & Case’s Handbook walks through exactly this scenario. An advertising agency based in Japan uses third-party AI systems in its ordinary workflow to generate branding concepts for clients. A customer based in Argentina commissions branding for one of its products; the agency delivers it, using AI to generate some elements; the client is happy and pays. A year passes. The Argentine client then opens a new office in Spain, and uses that branding there.

Under a literal reading of Article 2(1)(c), the Japanese agency is the deployer of the AI system it used to produce the branding; the branding itself is the “output”; the client has now used that output in the EEA. The agency — based solely in Japan, with no intention of ever doing business in Europe — falls within scope, a year after the work was finished, because of a decision it had no part in and no visibility into. White & Case’s own conclusion is blunt: there does not appear to be any way for the agency to avoid this outcome. A contractual clause prohibiting the client from using the branding in the EEA wouldn’t help, because Article 2(1)(c) doesn’t appear to take intent into account at all — and a restriction aimed at intent has nothing to grip onto in a test that doesn’t ask about intent.

Why the usual mitigations fail

This is worth arguing through rather than just asserting, because the reason both standard defences fail is structural, not incidental. A contractual prohibition on EEA use is a tool for shaping intent — it tells a counterparty what they’re not supposed to do, and creates a remedy if they do it anyway. Article 2(1)(c) doesn’t test intent, so a tool built to manage intent has nothing to act on; the client’s actual use in Spain triggers the provision regardless of what the contract said the client was and wasn’t allowed to do with the deliverable.

Geo-blocking your own service has the same structural mismatch, from a different angle. It controls who can reach your system directly. It does nothing about a customer who received an output outside any geo-blocked environment and later, independently, carries that output somewhere you can’t see and never contracted around. The output has already left your hands by the time the triggering event happens.

The second, quieter expansion

Article 2(1)(g) adds a separate line: the Act applies to affected persons located in the EEA. Under the GDPR, failing every Article 3 test ends the analysis — even if some of the people affected by a business’s processing happen to be in the EEA, that alone doesn’t pull an otherwise out-of-scope business in. Article 2(1)(g)’s wording is genuinely unclear, and White & Case reads it as possibly meaning something different: that an affected person located in the EEA might be able to exercise rights under the Act against a business that passes none of the other territorial tests at all. This is worth flagging precisely as unresolved rather than pushed toward an answer — the source itself doesn’t resolve it, and neither should this piece.

The counter-arguments

None of this is airtight, and the case against reading Article 2(1)(c) this literally deserves its full weight rather than a token mention before moving on. Recitals exist to guide interpretation, and a court taking a purposive approach could plausibly read the “intended to be used” language from Recital 22 back into Article 2(1)(c), resolving the inconsistency in the operator’s favour rather than the literal reading’s. Practically, enforcing the AI Act against a Japanese advertising agency with no EEA presence, no EEA assets, and no EEA representative is a real exercise in fiction — scope on paper and an enforceable judgment are different things, and the gap between them matters. And even where scope does attach, the actual obligation set for a business whose system is genuinely minimal-risk is thin: Article 4 AI literacy, and Article 50 transparency only if the system interacts directly with people. None of the high-risk apparatus this territory usually brings to mind switches on just because Article 2(1)(c)’s trigger fired.

What this means if you sell outside the EU

The honest conclusion sits between the alarming reading and the dismissive one. The exposure is real — the literal text supports it, and the most detailed commentary available concludes there’s no clean way to engineer around it. But for most businesses whose output ends up in the EEA through someone else’s later, unplanned decision, the resulting obligation set is genuinely small. The practical question worth asking isn’t “could we ever technically fall in scope” — for almost any business whose output could travel, the honest answer is probably yes, eventually. It’s which of your systems could ever be high-risk if that trigger fires, since that’s where the actual stakes of this whole analysis live.

The carve-outs that actually help

A handful of exclusions do real work here, separate from the territorial question itself. Article 2(3) excludes AI systems used exclusively for military, defence, or national security purposes. Article 2(6) excludes AI systems and models designed and used solely for scientific research and development. Article 2(8) excludes research, testing, and development of AI systems before they’re placed on the market or put into service — though this exclusion does not extend to testing under real-world conditions, which is treated differently. And Article 2(12) excludes AI systems released under free and open-source licences, except where they are high-risk systems, prohibited systems, or systems subject to the Article 50 transparency obligations. None of these touch the territorial trigger itself, but each one can take a given system out of the analysis before the question of where its output ends up ever needs asking.