Annex III

Sep

2026

Who actually owes a fundamental rights impact assessment

Article 27 of the EU AI Act (Regulation (EU) 2024/1689) catches only two categories of deployer: bodies governed by public law, or private entities providing public services, and deployers of the Annex III point 5(b) creditworthiness and point 5(c) life and health insurance systems. A private employer running an Annex III recruitment tool owes no fundamental rights impact assessment at all. Critical infrastructure — Annex III point 2 — is carved out of Article 27 by name, in the operative text itself. Most compliance content treats the FRIA as a blanket high-risk deployer duty. It isn’t one.

The date matters as much as the scope, and it moved. The FRIA obligation tracks the Annex III application date, which the Digital Omnibus deferred from 2 August 2026 to 2 December 2027 — and that deferral almost didn’t include the FRIA. During trilogue, the Parliament’s IMCO and LIBE committees specifically pushed to carve Article 27 out of the general delay and keep it on the original 2026 date, on the reasoning that a fundamental-rights safeguard deserved different treatment from the rest of the high-risk package. That carve-out didn’t survive the final agreement: the FRIA moved with everything else, to 2 December 2027, once the Parliament adopted the deal on 16 June 2026. As with the rest of the Omnibus, that date only binds once the amending regulation is published in the Official Journal — until then, 2 August 2026 is still the legally operative date.

Do you owe a FRIA?

Four questions settle it:

Are you a body governed by public law, or a private entity providing public services?
Are you deploying an Annex III 5(b) creditworthiness system, or a 5(c) life and health insurance risk-assessment or pricing system? (This limb catches you regardless of whether you’re a public or private organisation — a bank running credit scoring owes a FRIA through this route alone, without needing to argue over whether banking counts as a public service.)
Is the system critical infrastructure under Annex III point 2? If so, you’re excluded from Article 27 by name, full stop.
Is this your first use of the system? The obligation attaches at first use, not every use afterward.

What goes in it

Article 27(1) specifies six elements, and they’re worth naming precisely rather than paraphrasing loosely:

A description of the deployer’s own processes in which the system will be used, in line with its intended purpose.
The period and frequency over which each high-risk system will be used.
The categories of natural persons and groups likely to be affected by the specific context of use.
The specific risks of harm likely to affect those categories, taking into account the information the provider supplied under Article 13.
A description of the human oversight measures implemented, in line with the instructions for use.
The measures to take if those risks materialise, including internal governance arrangements and complaints mechanisms.

The filing nobody mentions

Once the assessment is done, the deployer notifies the market surveillance authority of the results and submits the completed template as part of that notification. That’s what turns Article 27 from an internal document into a reporting obligation, and it’s the part most summaries skip entirely.

There is one specific, named exemption from the notification duty: the Article 46(1) case, where a market surveillance authority has authorised a system in exceptional circumstances of public security, life and health, environmental protection, or protection of key infrastructure. Outside that specific case, notification is owed.

The template itself is still missing. Article 27(5) requires the AI Office to develop a questionnaire template — potentially through an automated tool, not just a form — to help deployers comply, but as of this writing that template hasn’t been published, and there’s no fixed deadline forcing its release. Its absence doesn’t suspend the obligation. In the meantime, the ECNL and the Danish Institute for Human Rights published a practitioner guide to fundamental rights impact assessments in December 2025 that’s worth building against while the official template is still pending.

How to not do it twice

The obligation applies to first use only. For similar later cases, a deployer can rely on a fundamental rights impact assessment it already carried out, or on one the provider carried out for similar cases — you’re not starting from a blank page every time you deploy a comparable system.

There’s a second overlap most summaries also skip: if any obligation under Article 27 is already satisfied by a data protection impact assessment carried out under Article 35 GDPR, or under Article 27 of the Law Enforcement Directive, the fundamental rights impact assessment becomes a supplement to that existing DPIA rather than a separate document duplicating it. Build the FRIA as an addition to the DPIA you likely already have, not a second filing cabinet.

The reuse right isn’t unconditional, though. If, during use, any of the six elements changes or stops being current — the affected population shifts, the frequency of use changes, a new risk emerges — the deployer has to update the assessment. Retraining a model, or a material change in how it’s actually used, is exactly the kind of event that should trigger this update duty; there’s no fixed retraining cadence that automatically resets the clock, but a change substantial enough to touch any of the six elements is substantial enough to require revisiting them.

The GDPR Article 22 trap next door

A related but separate question sits beside all of this. Deployers using these systems without meaningful human review of individual decisions still have to separately consider whether the GDPR’s Article 22 restriction on solely automated decision-making applies. That’s a different instrument, with a different test, frequently triggered by the same use case — passing your Article 27 analysis doesn’t answer the Article 22 question, and the two shouldn’t be run as if one substitutes for the other.

Frequently asked questions

Is a bank a “public service” deployer?

You don’t need to resolve that argument for credit scoring specifically — Annex III 5(b) already catches a bank running creditworthiness assessment directly, regardless of whether banking counts as a public service in your Member State. The public-service question only matters for deployers who aren’t independently caught by the 5(b) or 5(c) limb.

Does a private hospital count?

This is a genuine grey area rather than a settled answer. Private hospitals aren’t covered by the credit or insurance limb, so the question turns entirely on whether they count as providing a public service — and that can depend on how a given Member State’s healthcare system blends public and private provision, including whether the hospital operates under a public health insurance scheme. Don’t assume either answer without checking the national position.

What if the provider gives us their own FRIA?

Article 27(2) explicitly allows this — you can rely on an impact assessment the provider already carried out for similar cases instead of starting your own from scratch. Confirm it actually covers your specific context of use, since the six elements are context-dependent by design, and update it if your deployment differs from what the provider assessed.

Do we redo it when the model is retrained?

There’s no fixed rule tying a FRIA refresh to every retraining cycle, but Article 27(2) requires an update whenever any of the six elements changes or becomes outdated during use. A retraining that changes who’s affected, what risks arise, or how the system behaves in practice is exactly the kind of change that obligation is aimed at — treat significant retraining as a trigger to check the assessment, not as an automatic all-clear.

What’s the penalty for not filing?

Violations of the high-risk operator obligations, including Article 27, sit in the tier of fines up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99 — with the lower of the two figures applying to SMEs and start-ups instead of the higher one.

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.

Aug

2026

Most high-risk AI never sees a notified body

Article 43(2) of the EU AI Act (Regulation (EU) 2024/1689) sends providers of Annex III points 2 to 8 — critical infrastructure, education, employment, essential services, law enforcement, migration, justice and democratic processes — down the internal-control route in Annex VI. No notified body reviews the system, no third party signs off on it. Only biometrics, Annex III point 1, ever has a notified-body option, and product AI embedded under Annex I legislation follows its own sectoral procedure instead. “The AI Act means certification” is the wrong mental model for the large majority of high-risk providers, and treating it as true is costing some of them time and money they don’t need to spend.

Which route are you on?

Three answers cover every high-risk AI system:

Annex VI internal control — for every Annex III category except biometrics: critical infrastructure, education, employment, essential private and public services, law enforcement, migration and border control, the administration of justice, and democratic processes. No notified body is involved at all.
A choice between Annex VI and Annex VII — for Annex III point 1, biometrics, but only where the provider has applied harmonised standards or common specifications to demonstrate compliance. Where that condition isn’t met, the choice disappears; that case gets its own section below.
The sectoral procedure — for high-risk AI covered by Annex I product legislation, such as the Medical Devices Regulation. The provider follows whatever conformity assessment that sectoral law already requires, with the AI Act’s Chapter III Section 2 requirements folded into the same assessment rather than run as a second, parallel process. Specific Annex VII provisions on quality management and change control still apply within that sectoral assessment, and a notified body already designated under the sectoral law can assess the AI-specific requirements too — provided its competence to do so has itself been separately confirmed.

The Digital Omnibus reform added a practical fix here: where a single system could plausibly fall under two different conformity regimes at once — an emotion-recognition function built into a medical device is the example regulators point to — the provider follows the sectoral procedure rather than attempting to satisfy two separate assessment programmes. Notified bodies already designated under sectoral product law have until 2 February 2028 to apply for a corresponding AI Act designation if they want to assess the AI-specific requirements themselves.

What Annex VI actually asks of you

Internal control isn’t an honour system. The provider has to verify that its quality management system complies with Article 17 — covering regulatory compliance, technical specifications, data management, risk management, monitoring and reporting — and examine its own technical documentation to confirm the system meets the Chapter III Section 2 requirements for high-risk AI.

Once that’s done, Article 47 requires a written declaration of conformity: machine-readable, signed, containing the information set out in Annex V, and translated into the language required by each Member State where the system is placed on the market or put into service. The provider keeps it, and the underlying technical documentation, available to national authorities. CE marking follows under Article 48 — visible on the system or its documentation, affixed before the system is placed on the market, and required regardless of which conformity route was used. What differs is what sits behind the mark: for Annex VI self-assessment, there’s no notified body number to attach because no notified body was involved.

The one case where the choice disappears: biometrics without applied standards

Article 43(1) makes the Annex VI/Annex VII choice conditional, not automatic, even for biometrics. It’s only available where the provider has applied harmonised standards under Article 40, or common specifications under Article 41. If those standards haven’t been fully applied, aren’t available at all, or are themselves restricted in scope, Annex VII — the notified body route — becomes mandatory. Given how much of the AI Act’s harmonised-standards work is still in progress, that’s a live trap rather than a theoretical one, and it deserves its own treatment.

The other case where the choice disappears: law enforcement and EU institutions

Separately from the standards question, Article 43(1) removes the provider’s choice of notified body entirely where a high-risk system is intended to be put into service by law enforcement, immigration or asylum authorities, or by an EU institution, body, office or agency. In those cases, the market surveillance authority named in Article 74(8) or (9) acts as the notified body. There’s no shopping for a preferred assessor; the assessor is fixed by who the deployer is.

Two free presumptions people miss

Article 42 hands providers two presumptions of conformity that a lot of compliance programmes never claim, simply because nobody goes looking for them.

First: a high-risk system trained and tested on data reflecting the specific geographical, behavioural, contextual and functional setting it’s intended to be used in is presumed to comply with the data governance requirements in Article 10(4). You still have to be able to show that fit — provenance, the population the data represents, the gap (if any) between training conditions and deployment conditions — but where you can show it, you don’t have to separately argue Article 10(4) compliance from scratch.

Second: a system already certified, or holding a statement of conformity, under a cybersecurity scheme adopted under the EU Cybersecurity Act (Regulation (EU) 2019/881) is presumed to meet Article 15’s cybersecurity requirements — to the extent the certificate actually covers them. Both halves of that qualifier matter: the scheme’s reference has to be published in the Official Journal for the presumption to attach at all, and the presumption only reaches the specific requirements the certificate scope actually addresses, not Article 15 wholesale. A certificate covering resilience to adversarial attacks doesn’t hand you a presumption on data poisoning if poisoning wasn’t in scope of the assessment.

Frequently asked questions

Does self-assessment mean no audit, ever?

No — it means no third-party notified-body audit before you place the system on the market. Annex VI still requires a genuine internal verification against Article 17, not a box-ticking exercise, and market surveillance authorities keep their ordinary ex-post inspection and enforcement powers regardless of which conformity route a provider used. Self-assessment shifts who checks first, not whether anyone ever checks.

Who signs the declaration of conformity?

The provider, or its authorised representative, under the provider’s sole responsibility. Article 47 doesn’t contemplate a notified body’s signature for Annex VI systems, because none was involved in producing it.

Do we still CE mark if we self-assessed?

Yes. CE marking under Article 48 applies to every high-risk AI system regardless of conformity route. The difference shows up in what accompanies the mark: a notified body identification number appears alongside it only where Annex VII applied.

What’s the four-year certificate rule, and does it apply to us?

Only if a notified body was involved. Article 44 caps certificates issued under Annex VII at four years for Annex III systems (five years for Annex I systems), renewable on reassessment. A pure Annex VI self-assessment never produces a notified-body certificate in the first place, so there’s no four-year clock running — what you keep instead is your technical documentation and declaration of conformity, available to authorities on request rather than expiring on a schedule.

What actually changes on 2 December 2027?

That’s when the Annex III high-risk obligations apply, following the Digital Omnibus deferral from the original 2 August 2026 date. For providers on the Annex VI route, that’s the date by which the Article 17 quality management verification and the Article 47 declaration of conformity need to actually be in place — not a date that changes which route you’re on. Don’t confuse it with the separate 2 February 2028 deadline for sectoral notified bodies to seek an AI Act designation; the two dates come from the same reform but govern different things.

Aug

2026

Police can deploy high-risk AI before it’s authorised

Article 46(2) of the EU AI Act (Regulation (EU) 2024/1689) lets law enforcement or civil protection authorities put a specific high-risk AI system into service without prior authorisation, in a duly justified situation of urgency, for exceptional reasons of public security or a specific, substantial and imminent threat to the life or physical safety of natural persons — on condition that authorisation is then requested during or after use, without undue delay. If that authorisation is refused, use of the system stops with immediate effect, and all results and outputs of that use are immediately deleted. A statutory evidence-destruction clause sitting inside what is, on paper, a product-safety regulation — and almost nothing has been written about what it actually does.

Two different derogations, often confused

Article 46 contains two distinct mechanisms, and conflating them gets the sequencing wrong.

Article 46(1) is the general derogation. Any market surveillance authority — not limited to law enforcement — may authorise placing a specific high-risk system on the market or putting it into service, for exceptional reasons of public security, protection of life and health, environmental protection, or protection of essential industrial and infrastructure assets. The authorisation lasts for a limited period while the necessary conformity assessment is carried out, and that assessment has to be completed as quickly as possible. Authority acts first here too, but conditionally — it has to conclude compliance before authorising anything.

Article 46(2) is narrower and more dramatic. Only law enforcement authorities or civil protection authorities can use it, and only in genuine urgency — the deployment happens with no authorisation at all, and the paperwork follows during or after the fact. This is the deploy-now, ask-later route, and it’s the one carrying the discard consequence.

One scope point worth having on hand: neither derogation touches high-risk AI embedded in products covered by Annex I Section A legislation. Those systems use only whatever conformity-assessment derogations their own sectoral legislation provides — Article 46 doesn’t reach them at all.

The discard rule

If the Article 46(1) authorisation is refused after a paragraph 2 deployment, two things happen simultaneously: use stops immediately, and every result and output the system produced during that use is immediately deleted. Both are unconditional — there’s no grace period, no partial retention for review.

What the Act doesn’t say is where that leaves anything built on top of those outputs. If an officer already acted on a system’s flagged match, or an output already made its way into a case file, the text gives no answer for what happens to the decision or the file once the outputs behind it are gone. That’s a genuine, open gap rather than something this piece can resolve — and it’s worth knowing it’s open before you assume the Act has an answer.

The 15-day clock

The paragraph 1 authorisation is only granted if the market surveillance authority concludes the system actually complies with the Chapter III Section 2 requirements. Once granted — whether under paragraph 1 directly or via the paragraph 2 route — the authority notifies the Commission and other Member States, though that notification duty doesn’t extend to sensitive operational data tied to law enforcement activities specifically.

From there, a silent-consent structure runs on calendar days, not business days. If no Member State or the Commission raises an objection within 15 calendar days of receiving that notification, the authorisation is deemed justified — no further action needed. If a Member State does object to another Member State’s authorisation, or the Commission itself considers the authorisation contrary to EU law or the underlying compliance conclusion unfounded, the Commission consults with the Member State concerned without delay, and the operators involved are consulted and given a chance to present their views before the Commission decides. If the Commission ultimately finds the authorisation unjustified, the market surveillance authority that granted it has to withdraw it.

Who assesses police AI in the normal case

Outside of Article 46’s emergency mechanics, high-risk AI intended for use by law enforcement, immigration or asylum authorities, or EU institutions, doesn’t go through a notified body of the provider’s choosing at all — the market surveillance authority itself carries out the assessment. And when these systems are registered, the entry sits in the EU database’s secure, non-public section rather than the ordinary public one. Emergency deployment isn’t a shortcut around an otherwise-open marketplace of assessors; it’s a shortcut inside a system that was already centralised and restricted.

What this means if you sell to police forces

The commercial consequence is straightforward and worth putting in writing before it happens, not after. Your customer can lawfully deploy your system under genuine urgency, use it, and then be told — days or weeks later — to stop immediately and delete everything it produced. If your contract assumes deployment implies an ongoing, stable engagement, it doesn’t account for this. Build the discard scenario into your terms: what data reverts to you, what your customer owes you notice of, and what happens to your own copies of anything derived from that use.

Frequently asked questions

Does Article 46 override the Article 5 prohibitions?

No. Article 46 is a derogation from the conformity assessment procedure for high-risk systems — it has nothing to do with the absolute prohibitions in Article 5, which ban certain practices outright regardless of risk classification or urgency. A practice that’s prohibited under Article 5 doesn’t become available under emergency conditions; Article 46 only ever touches something that would otherwise be lawful but for the timing of its paperwork.

Who decides what counts as urgent?

The law enforcement or civil protection authority makes that call itself in the moment it deploys under paragraph 2 — that’s the point of the mechanism. The market surveillance authority’s role comes after, when it decides whether to grant the paragraph 1 authorisation the deployment is retroactively seeking.

Is there an appeal if authorisation is refused?

The text gives operators a consultation right specifically within the paragraph 5 process — where the Commission is reviewing a granted authorisation that another Member State or the Commission has challenged, operators are consulted and get to present their views before the Commission decides. It’s less clear there’s an equivalent route for challenging an initial refusal itself; nothing in the article spells one out.

Does the discard rule reach models trained on the deleted outputs?

The text doesn’t address this, and it would be overreaching to assume an answer either way. If a derived model or downstream system incorporated something built from the discarded outputs before deletion happened, the Article doesn’t say what that means for the derived material — treat it as unresolved rather than settled.

Does this apply to migration or asylum authorities?

Not under paragraph 2 specifically — that provision names only law enforcement authorities and civil protection authorities. Migration and asylum authorities aren’t included in the deploy-first mechanism, even though they’re treated alongside law enforcement for other purposes elsewhere in the Act, such as who conducts the conformity assessment in the ordinary case.

Aug

2026

Your AML and fraud AI probably isn’t high-risk

Annex III point 5(b) of the EU AI Act (Regulation (EU) 2024/1689) makes creditworthiness assessment and credit scoring high-risk, “with the exception of AI systems used to detect financial fraud.” Recital 58 goes further still: AI systems that Union law provides for to detect fraud in the offering of financial services, and for prudential purposes to calculate the capital requirements of credit institutions and insurance undertakings, aren’t considered high-risk under the Regulation at all. And Recital 42 keeps a specific category of entity-level risk analytics — assessing the likelihood of financial fraud by undertakings based on suspicious transactions — outside the Article 5(1)(d) prohibition on profiling-based crime prediction entirely. Three separate carve-outs, each with its own precise wording, and most AML-focused content hasn’t caught up with any of them.

The three carve-outs, stated plainly

If your system detects financial fraud rather than scoring a natural person’s creditworthiness, and it doesn’t profile individuals to do it, there’s a good chance none of the high-risk machinery in this Regulation reaches it. Each of the three routes there has its own source and its own precise limits, worth taking one at a time.

The Annex III 5(b) exception

This one sits in the operative Annex itself, not a recital — the fraud carve-out is written directly into the same provision that otherwise makes credit scoring and creditworthiness assessment high-risk, rather than added as separate interpretive commentary. That placement matters: an Annex carve-out has the same legal weight as the rule it modifies, not the softer interpretive status of recital text.

Recital 58

Recital 58 adds two more categories, both carrying a real limiting condition. Fraud-detection systems are excluded only where Union law itself provides for that detection function — this isn’t a blanket exemption for any anti-fraud tool a firm builds on its own initiative, but specifically for systems built to satisfy a fraud-detection obligation that Union law already imposes, such as under the anti-money-laundering framework or payment services rules. Separately, and rarely mentioned in AML-focused guidance at all, systems used for prudential purposes to calculate the capital requirements of credit institutions and insurance undertakings are excluded too.

Recital 42

Article 5(1)(d) prohibits assessing or predicting the risk that a natural person will commit a criminal offence, based solely on profiling that person or assessing their personality traits and characteristics. Recital 42 clarifies what that prohibition doesn’t reach: risk analyses that aren’t based on profiling natural persons or their personality traits at all. The recital gives two concrete examples — AI systems using risk analysis to assess the likelihood of financial fraud by undertakings based on suspicious transactions, and risk analysis tools predicting the likelihood of drug or illegal-goods finds by customs authorities based on known smuggling routes. Entity-level and pattern-level analysis sits outside the prohibition by design; the ban is aimed squarely at profiling people.

Where every carve-out collapses

Two triggers end all three exceptions at once, and they’re worth holding in mind as a single test rather than three separate ones.

The first is the moment a system’s output actually scores a natural person’s creditworthiness. The Annex III 5(b) exception protects fraud detection specifically — it was never an exemption for creditworthiness scoring, so a tool that starts life detecting fraud but feeds into an actual credit decision about an individual has walked into the very category the carve-out exists to carve around.

The second is profiling itself. Article 6(3) is explicit and leaves no room to argue around it: any Annex III system also used to profile natural persons is always high-risk, with no exemption available regardless of what else the system does. An alert-triage model that ranks individual customers by their behavioural traits is not the same artefact as one that scores the suspiciousness of an entity’s transactions, even if both get called “fraud detection” internally. The label doesn’t decide the outcome; what the model actually measures does.

Why the vendor material is behind

Hawk’s 2024 whitepaper on the AI Act put it carefully, and honestly, for the moment it was written: whether AI in AML and fraud prevention would count as high-risk “still needs to be determined,” with “initial indications” suggesting it might not be, and official interpretive guidelines expected to settle the question. That hedging was reasonable at the time. It just isn’t accurate anymore — the final text answered this directly, in the Annex itself, and never needed separate guidelines to do it. Content written in that earlier window of genuine uncertainty is still circulating as though the uncertainty never resolved.

What you still owe even when you’re out

Falling outside Annex III doesn’t mean falling outside the Act entirely. Article 4 AI literacy applies to all AI regardless of risk tier, with no carve-out for fraud-detection systems. Article 50 transparency duties apply if the system interacts directly with people — a customer-facing fraud alert, for instance. And the Article 5 prohibitions never depended on risk classification in the first place; a system that did profile individuals to predict criminal behaviour would face Article 5(1)(d) regardless of anything Annex III says about fraud detection.

Frequently asked questions

Is sanctions screening high-risk?

Generally not, on the same logic Recital 42 sets out for fraud analytics — screening names and entities against watchlists doesn’t itself assess a natural person’s creditworthiness or predict individual criminal behaviour through personality profiling. That reading holds only as long as the screening stays at the entity or transaction level; layering in behavioural profiling of individuals changes the analysis.

Is our alert-triage model in scope?

Test it against the same two triggers. A model scoring transaction or entity-level suspicious-activity patterns sits inside the carve-outs described here. A model that ranks or scores individual customers based on their profiled behaviour or personality traits doesn’t, regardless of how the function is labelled internally.

What about AML models that also feed credit decisions?

Once that model’s output feeds an actual creditworthiness or credit-scoring decision about a natural person, you’re inside Annex III 5(b)’s core high-risk category rather than its fraud-detection exception. The exception protects fraud detection; it doesn’t follow the model downstream into a different use.

Does the Omnibus change Annex III 5(b)?

Not as far as the current record shows. The Digital Omnibus reform’s substantive changes concentrate on Annex III and Annex I timing, the registration duty, and the safety-component definition — nothing in what’s been reported touches the individual category carve-outs within Annex III itself.

Who decides — us or our national supervisor?

You make the initial classification call, the same self-assessment pattern that runs throughout Article 6. Your national financial supervisor — the authority Recital 158 designates as the market surveillance authority for regulated financial institutions — retains the ordinary power to review that classification afterward and require correction if it disagrees.

Aug

2026

Banks: your AI Act regulator is already your supervisor

Recital 158 of the EU AI Act (Regulation (EU) 2024/1689) designates the authorities that already supervise credit institutions, insurers, and credit intermediaries — under the Capital Requirements Regulation, the Capital Requirements Directive, Solvency II, the Consumer Credit Directive, the Mortgage Credit Directive, and the Insurance Distribution Directive — as the market surveillance authorities for AI systems offered or used by regulated financial institutions, unless a Member State designates someone else instead. And Articles 17(4), 18(3), 19(2), and 26(5)-(6) let those same institutions discharge several AI Act quality-management, documentation, and logging duties by pointing to the internal governance rules they already follow under financial services law. A lot of banks are budgeting for a new AI regulator that, for them, mostly doesn’t exist.

Who your regulator actually is

The default answer is your existing financial supervisor — the authority already responsible for supervising you under CRR, CRD, Solvency II, the Consumer Credit Directive, the Mortgage Credit Directive, or the Insurance Distribution Directive, depending on which regime you sit under. That’s the designated market surveillance authority for the AI systems you offer or use.

The wrinkle is that Member States can designate a different authority for this specific task instead, so the answer is genuinely national rather than uniform across the EU. Check the actual designation in each market you operate in — don’t assume your home supervisor’s role carries over unchanged into every jurisdiction you’re active in.

The ECB pipe

For credit institutions supervised under CRD and participating in the Single Supervisory Mechanism, Recital 158 adds a specific reporting line: when their national supervisor is acting as the AI Act market surveillance authority, it has to report to the European Central Bank, without delay, any information from its market surveillance activities that could potentially be relevant to the ECB’s own prudential supervision tasks. Spell out what that means in practice: an AI Act finding about your systems doesn’t stay inside an “AI compliance” silo. By design, it can land on your prudential supervisor’s desk quickly, through the same channel that already carries your other supervisory information.

The four substitutions, article by article

Four separate provisions let a regulated financial institution meet AI Act obligations through governance it already has, rather than building a parallel structure from nothing.

Article 17(4) deems the quality management system obligation fulfilled by complying with the internal governance rules already required under financial services law — but only for most of Article 17(1). The provision carves out three specific elements by name: the risk management system under Article 9, the post-market monitoring system under Article 72, and the serious-incident reporting procedures under Article 73. Those three still have to be addressed directly under the AI Act, regardless of how mature your existing banking governance is. It’s a partial substitution, not a blanket one, and it’s deliberately calibrated to leave the elements closest to actual AI safety oversight outside the shortcut.

Article 18(3) lets technical documentation retention be discharged as part of the documentation you already retain under financial services law. Article 19(2) does the same for the automatically generated logs your high-risk systems produce. Articles 26(5)-(6) extend the same logic to deployers specifically — the ongoing monitoring obligation and the log-retention duty are both deemed fulfilled by complying with existing internal governance rules under financial services law.

What substitution does not cover

Beyond the Article 9/72/73 carve-out inside Article 17(4) itself, the substitution mechanism doesn’t touch several other obligations at all. The substantive Chapter III Section 2 requirements — Articles 9 through 15 — still have to actually be met; the substitution changes how you evidence quality management, not what a high-risk system has to do. Article 27’s fundamental rights impact assessment, owed by deployers of the Annex III 5(b) and 5(c) categories specifically, is a separate duty with no financial-services equivalent standing in for it. Article 49 registration is still owed. Article 50 transparency, where it applies, is still owed. None of these get a banking-sector shortcut.

What this forces on your operating model

The practical consequence is that AI Act compliance and financial regulatory compliance can’t be run as two separate programmes that happen to share a subject. The same authority reads both, and for SSM banks, findings can flow onward to the ECB. A parallel AI governance stack that doesn’t talk to your existing prudential and conduct compliance function is exactly the failure mode this structure is built to expose — inconsistency between the two becomes visible to the one regulator positioned to see both at once, immediately, rather than eventually.

What is high-risk for a bank at all

Briefly, since this is covered in full in a companion piece on AML and fraud detection: Annex III 5(b) makes creditworthiness assessment and credit scoring of natural persons high-risk, and 5(c) does the same for life and health insurance risk assessment and pricing — with financial fraud detection specifically carved out of 5(b), and further exceptions for fraud detection and prudential capital calculation set out in Recital 58. The detail of where those carve-outs hold and where they collapse is worth reading on its own rather than repeating here.

Frequently asked questions

Do we need a separate AI management system?

Not necessarily a wholly separate one for the quality-management obligation specifically — Article 17(4) lets your existing governance framework serve that function, minus the three carved-out elements. Risk management under Article 9, post-market monitoring under Article 72, and serious-incident reporting under Article 73 need direct attention regardless of how developed your banking governance already is.

Does BaFin or the AI Office supervise us?

Your national financial supervisor by default — BaFin, for a German institution — under the Recital 158 designation, not a separate AI Office function created from scratch. That only changes if your Member State has specifically designated a different authority for this role.

Do our DORA controls count toward this?

DORA isn’t one of the instruments Recital 158 names, and I haven’t found anything establishing that Digital Operational Resilience Act controls substitute for AI Act obligations the way CRD or Solvency II governance does. Treat this as a genuine open question rather than an assumed yes — the overlap may be substantive, but it isn’t a stated legal substitution route.

What about our model risk management framework?

Same answer. A model risk management framework may cover much of the same ground as Article 9’s risk management system in substance, but it isn’t one of the six instruments Recital 158 names as a basis for substitution. Don’t assume it discharges an AI Act obligation without checking whether your supervisor treats it that way.

Does the Omnibus change who supervises us?

Not as far as the current record shows. The Digital Omnibus reform’s substantive changes concentrate on Annex III and Annex I timing, the registration duty, and the safety-component definition — nothing reported so far touches the Recital 158 supervisory-authority designation itself.

Aug

2026

Telling staff about AI at work: the Article 26(7) duty

Article 26(7) of the EU AI Act (Regulation (EU) 2024/1689) requires employer-deployers of high-risk AI systems to inform workers’ representatives and the affected workers that they will be subject to the system, before it’s put into service or used at the workplace. That information is provided, where applicable, in accordance with the rules, procedures and practice on informing workers and their representatives laid down in Union and national law. One short clause routes the AI Act straight into works council law — and the procedure, the timing, and the leverage workers actually have are all determined nationally from there, not by the Act itself.

What the duty actually is

Read literally, the Act’s own text requires informing, not consulting. But that duty is expressly channelled through whatever national information rules and practice already exist — and in several Member States, those rules go further and require actual consultation before a workplace change like this. This distinction decides your real timeline: if you’re only reading Article 26(7) itself, you might plan for a notice sent shortly before go-live; if your national regime channels this into an existing consultation obligation, you’re planning for a process with its own lead time, and possibly its own points where workers’ representatives can push back before you’re clear to proceed.

Who has to be told

Both workers’ representatives and the affected workers themselves — not one or the other. “Affected workers” is a broader category than “users of the system.” A worker who is monitored, evaluated, or has decisions made about them by a high-risk system is affected by it whether or not they ever personally interact with its interface. Scoping this notice to the people who log into the tool, rather than everyone the tool is actually applied to, undercounts who the Act means to protect.

When

Before the system is put into service or used. For a phased rollout, that points toward informing each new population as it’s actually brought into the system’s scope, rather than a single blanket notice issued at the start that tries to cover populations not yet affected. A pilot counts — running a smaller-scale version of the system is still putting it into service or using it, and doesn’t get treated as exempt just because it’s temporary or limited. A vendor upgrade that changes what the system actually does to workers — new monitoring capability, a different basis for evaluation — is a fresh trigger in its own right; the original notice covered the original system, not whatever it becomes afterward.

The Article 2(11) fragmentation problem

Article 2(11) states plainly that the Regulation doesn’t prevent the Union or Member States from maintaining or introducing legislative or administrative provisions more favourable to workers regarding the protection of their rights in relation to employers’ use of AI systems, or from encouraging or allowing more favourable collective agreements. The AI Act sets the floor; national law and collective bargaining set the ceiling, and the ceiling varies. A rollout across the EU doesn’t have one answer to “what do we owe workers here” — it potentially has as many answers as there are Member States involved, and collective agreements can raise the bar further still in any one of them. Rather than attempting to summarise 27 different national positions here, the honest move is to point at the national implementation trackers directly and check the specific markets a rollout actually touches.

What else the employer-deployer owes

Article 26(7) doesn’t sit alone. The same Article requires using the system in accordance with its instructions for use, and assigning human oversight specifically to natural persons who have the necessary competence, training and authority, and who receive the necessary support to exercise it — not oversight assigned on paper to someone without the standing or resources to actually do it. Where the deployer controls the input data, that data has to be relevant and sufficiently representative for the system’s intended purpose. And deployers monitor the system’s operation against its instructions for use, retaining the automatically generated logs, to the extent under their control, for a period appropriate to the system’s purpose and at least six months, unless other Union or national law requires longer.

Separate from all of this, Article 4 AI literacy applies regardless of risk tier — it isn’t limited to high-risk deployments — and it explicitly reaches staff and other persons operating or using AI systems on the deployer’s behalf, not employees alone. A contractor or an external service provider running your systems for you falls inside this duty too.

A practical sequence

Inventory what AI systems are actually deployed at the workplace and where. Classify which are high-risk. Identify the affected population properly, beyond just the direct users. Map the specific national information and consultation route for each country involved, since this isn’t one process repeated identically everywhere. Brief workers’ representatives through that route. Document the date this happened, since it’s the fact you’ll need to point to later. Only then go live.

Frequently asked questions

Is a works council agreement required before we can proceed?

Not under the AI Act’s own text, which only requires informing. Whether a formal agreement, or consultation with a real chance to object, is required depends entirely on whether your national information and consultation regime already demands that for a change like this — in jurisdictions with strong co-determination rights, it very well might be.

Does this apply to a tool we already use?

The duty attaches to putting the system into service or using it — a tool already in continuous use presumably triggered it at that original point. A material change to what the tool does, or who it’s applied to, is a fresh trigger in its own right, even for a system that’s been running for years.

What if the system isn’t high-risk?

Article 26(7) specifically is a high-risk deployer obligation, so it doesn’t apply on its own terms to a non-high-risk system. Article 4 AI literacy still applies regardless of risk tier, and separate national employment or data protection law may independently require informing workers about workplace monitoring tools whether or not the AI Act’s own high-risk trigger is met.

Can workers object once informed?

The Act’s own text gives an information right, not an explicit objection right. Whether workers or their representatives have real leverage to push back depends on the national regime Article 26(7) channels this through — some Member States’ consultation frameworks give workers’ representatives genuine influence over the outcome; others may limit the right to notice itself.

What’s the penalty for skipping it?

Article 26 obligations, including this one, sit in the same fine tier as the rest of the Act’s high-risk operator duties: up to €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher, with the lower of the two figures applying to SMEs and start-ups instead.

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.