EU AI Act

11
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.

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
05
Sep
2026

Should you sign the AI transparency Code of Practice?

The Code of Practice on Transparency of AI-Generated Content was published on 10 June 2026. The European Commission’s Opinion of 8 July 2026 concluded it adequately covers Articles 50(2), (4) and (5) of the EU AI Act, and the AI Board adopted its own adequacy assessment the following day. And yet the Code’s own text, in the Objectives section of both its parts, states that adherence does not amount to conclusive proof of compliance. Signing is also severable — the provider-facing and deployer-facing halves can be signed independently, by different kinds of organisation, for different reasons. This is a real commercial decision with asymmetric costs on each side, not a box-ticking formality.

What the Code is and isn’t

The Code is voluntary. It doesn’t replace the Act, and it doesn’t replace the Commission’s separate guidelines on implementing Article 50 — a draft of those guidelines was published on 8 May 2026, a targeted consultation closed on 3 June 2026, and the final version is expected before 2 August 2026. The Code and the Guidelines do different jobs: the Guidelines interpret what the law requires; the Code offers one accepted way to meet it. It imposes no obligation beyond what the Act already imposes on providers and deployers within its scope.

Within the Code itself, every commitment is graded. Measures marked “will” are what a signatory commits to as binding; measures marked “encouraged” are recommended but not required; measures marked “may” are left entirely optional. That grading matters more than it looks — it’s the difference between something you’re accountable for and something you can quietly skip.

What signing buys you

The Commission’s own framing is direct: signatories get an EU-wide recognised way to demonstrate compliance, regardless of where they’re established or which national market surveillance authority has jurisdiction over them, and future enforcement effort will focus on monitoring adherence to the Code rather than re-litigating compliance from scratch. That’s a real reduction in administrative burden and a real increase in predictability.

Weigh that against the other half of the sentence. The Code does not guarantee compliance, and — as commentary on the equivalent regime for general-purpose AI models under Article 56 has already established for that adjacent Code — alternative routes to compliance may exist alongside it. Signing narrows your risk. It doesn’t eliminate the need to actually do the thing the Code describes.

The two sections, and why you might sign only one

Section 1 covers providers under Article 50(2). Because no single marking technique is currently considered reliable enough on its own, the Code generally expects a multi-layered approach: digitally-signed, tamper-evident metadata recording that content is AI-generated or manipulated, combined with imperceptible watermarking embedded in the content itself. Fingerprinting or logging sits alongside these as an optional third layer. Providers also commit to offering a detection mechanism — typically free of charge, though the Code allows smaller signatories to charge where detection carries substantial operational cost — while forensic detection of content that’s been stripped of its marking stays optional, on the Code’s own acknowledgment that the technology isn’t mature enough yet to meet the Act’s reliability bar. A staged interoperability requirement follows, with a working solution for watermark detection due by 2 February 2027.

Section 2 covers deployers under Article 50(4) and (5): labelling deepfakes, and labelling AI-generated or manipulated text published to inform the public on matters of public interest that hasn’t been through human review. Notably, the Code doesn’t leave the visual form of that label to the deployer’s judgment — it obliges use of the Commission’s own EU AI icon, or an equivalent, wherever visual disclosure is possible, with an audible disclaimer as the fallback where it isn’t.

The split explains why an organisation might reasonably sign only one half. A model or system provider with no deployment role of its own has nothing to gain from Section 2’s labelling commitments. A retail business running marketing campaigns through a third-party generative tool is a deployer with no marking infrastructure to build — Section 1 isn’t its problem, Section 2 is. Only a company that both builds and ships generative features to end users has a reason to sign both.

The alternative route, and its price

Nothing about the Code forecloses building your own approach instead. The Code’s own drafting on this point directs signatories testing marking and detection solutions to weigh them against current state-of-the-art benchmarks and testing methods generally, expressly including any that the AI Office develops or recognises together with the AI Board — phrasing that concedes those AI Office-recognised benchmarks are still a work in progress rather than a finished reference you can simply cite.

That’s the real price of the alternative route. Until the AI Office publishes its own benchmarks, an organisation going it alone is testing against internal benchmarks and general industry practice, and carrying the burden of proving that’s good enough — optionally strengthened with independent red-teaming or a run through an Article 57 regulatory sandbox. A signatory can point to the Code. A non-signatory has to build and defend an equivalent case from scratch, to a market surveillance authority that hasn’t pre-approved the yardstick.

Who else is signing

The Code is open well beyond the organisations Article 50 actually binds. Technology providers of marking and detection solutions — companies with no generative AI system of their own — can sign Section 1 to demonstrate their tools meet the Code’s technical bar. That matters commercially: a generative AI provider choosing a third-party watermarking vendor has a direct reason to prefer one that has already signed, since the Code lets a signatory rely on a third party’s solution only where that third party has itself adhered to the Code and demonstrated compliance with it.

A subtler case is generative AI model providers, as distinct from the system providers Article 50 actually addresses — the Act’s transparency duties are pinned to systems, not to the underlying models that power them. The Code’s first draft tried to impose hard obligations on model providers directly; the final version backed away from that and merely encourages them to implement marking and detection at the model level, so that system providers built on top of their models can comply more easily downstream. It’s a voluntary, upstream courtesy, not a binding duty — and the softening between drafts is itself a signal of how contested that question was.

The decision

Three questions do most of the work. Do you ship generative output — audio, image, video or text — into the EU market at all, as a provider or a deployer? If not, none of this applies yet. If you do, can you evidence your marking or detection performance independently, against a benchmark a regulator would accept, without the Code’s cover? If that’s expensive or uncertain, signing is the cheaper insurance. And do you sell to enterprise customers who are starting to ask suppliers whether they’re Code signatories as part of their own due diligence? If procurement teams are already asking, being on the list answers the question before it’s asked.

Frequently asked questions

Is the signatory list public?

Not yet, as of this writing. The deadline to be included in the first published list is 22 July 2026 at 18:00 CEST, and the Commission has said that list will be published before the Article 50 obligations take effect on 2 August 2026.

Can we join later?

Yes. Signing remains open after 22 July 2026 — organisations that miss that date simply submit the signature form afterward and aren’t on the first published list, without losing the ability to sign at all.

Does signing bind our downstream customers?

No. Each organisation in a generative AI supply chain has its own role and its own Article 50 obligations. Signing signals your own adherence and, where relevant, supports customers building on top of you — the Code specifically encourages provider-level tooling that helps deployers meet their own duties — but it doesn’t extend your signature to bind anyone downstream.

Does the Code cover Article 50(1)?

No. The Code addresses Articles 50(2), (4) and (5) — marking, deepfake and public-interest text labelling, and the form those disclosures take. Article 50(1), the general AI-interaction disclosure duty, and Article 50(3), the emotion-recognition and biometric-categorisation notice, sit outside the Code entirely and are addressed only by the Commission’s separate Article 50 guidelines.

What happens if you sign and then fail to implement?

The Code frames signing as signalling intent to adhere to its commitments, not as a one-time filing that stands in for the work. An organisation that signs but doesn’t actually implement the marking, labelling or detection measures it committed to isn’t shielded by having signed — it has simply made a compliance claim that doesn’t match its practice, which is a weaker position than never having claimed Code adherence in the first place.

Posted by admin in What happened with...
01
Sep
2026

AI Act deepfake labelling: artistic and editorial carve-outs

Article 50(4) of the EU AI Act (Regulation (EU) 2024/1689) requires deployers to disclose when image, audio or video content is a deepfake, and when text has been artificially generated or manipulated for publication on matters of public interest. Two carve-outs sit inside that duty — a lighter disclosure for content that is “evidently” artistic, creative, satirical or fictional, and no disclosure at all for text that passed through genuine editorial control. Both sound generous on a first read. Neither is as wide as it looks, and the European Commission’s draft guidelines, published 8 May 2026, spend more time narrowing them than most summaries let on.

Which content counts as a deepfake under Article 50(4)?

The duty sits with the deployer, not the provider — whoever publishes or puts the content in front of people, not whoever generated it. It applies to AI-generated or manipulated image, audio or video content that constitutes a deepfake under Article 3(60): content resembling existing persons, objects, places, entities or events that would falsely appear to a person to be authentic or truthful.

The Commission’s draft guidelines read that definition wider than most people assume. Three clarifications matter:

  • Intent is irrelevant. Whether the content falsely appears authentic doesn’t depend on whether the deployer meant to deceive anyone. An absence of fraudulent intent doesn’t defeat the labelling duty.
  • “Existing” is read broadly. A realistic synthetic depiction of a fictitious but natural-looking person can still be a deepfake, even where no identifiable real person is implicated — it’s enough that the subject resembles someone or something that could exist, or could once have existed.
  • Not every edit counts. Routine adjustments — lighting, colour correction, noise reduction, sound cleanup — normally don’t turn content into a deepfake, because they don’t meaningfully affect how truthful it appears. More substantial changes that alter meaning or context, such as edits to a photograph used in journalism, can. The guidelines treat this as a case-by-case judgment rather than a bright line.

The artistic, creative, satirical and fictional carve-out

Where a deepfake forms part of a work or programme that is artistic, creative, satirical, fictional or similar in nature, Article 50(4) is satisfied by a lighter disclosure: making known that the content exists in generated or manipulated form, in a way that doesn’t hamper the display or enjoyment of the work — a credit rather than an overlay stamped across the frame.

The word doing the real work in that sentence is one most summaries drop. The original text requires the work to be evidently artistic, creative, satirical or fictional — not arguably, not defensibly, but obviously so. That’s not loose paraphrasing: it’s the actual qualifier in the operative text, and the Commission’s draft guidelines lean on it directly, treating it as a threshold the content has to clear plainly rather than a label a deployer can assert after the fact.

That threshold has teeth, and the clearest illustration is political satire — the case that looks safest on paper. A deepfake of a real politician, shared on social media to mock a decision they made, looks like a textbook fit for the satirical carve-out. Commentary on the draft guidelines gives exactly this example and reaches the opposite conclusion: the exception doesn’t apply, because the same content also touches public discourse on a matter of public interest. Satire and public-interest commentary aren’t mutually exclusive categories under Article 50(4) — they can describe the same clip, and where they do, the more consequential reading controls, not the more convenient one.

The Code of Practice on Transparency of AI-Generated Content addresses this carve-out too, in the section covering deployer labelling of deepfakes and public-interest text. It’s a voluntary compliance tool, not a substitute for reading the exception correctly — signing it demonstrates a method, it doesn’t relax the “evidently” test underneath.

The text carve-out and its two cumulative conditions

Article 50(4)’s second limb catches AI-generated or manipulated text published to inform the public on matters of public interest. It doesn’t catch text that isn’t public-interest text in the first place — an AI-drafted product description or an internal memo was never in scope, carve-out or not.

For the text that is in scope, disclosure drops away entirely, but only where two conditions are both met: the content has undergone a process of human review or editorial control, and a natural or legal person holds editorial responsibility for publishing it. Both, not either. A generative system that drafts news summaries with nobody reviewing them, and nobody named as accountable for what goes out, gets neither condition and has to label every piece.

“Editorial control” is doing more work here than a quick skim suggests. The guidelines and the underlying text point toward an actual review process tied to an identifiable person or role who could be held to account for the publication — not a general policy that content is “monitored,” and not a single glance before hitting publish. A newsroom with a named editor who reviews AI-assisted copy before it runs has a real claim to both conditions. A platform that auto-publishes AI summaries with a disclaimer buried in the terms of service has neither.

Why “obvious” means something narrower here than in Article 50(1)

Article 50(1)’s chatbot-disclosure exception and Article 50(4)’s deepfake exception both turn on how a reasonable person would perceive the content — but they’re not the same reasonable person, and the draft guidelines are explicit about the gap.

Article 50(1) asks whether it would be obvious to a reasonably well-informed, observant and circumspect member of the system’s target audience that they’re dealing with AI. Article 50(4)’s deepfake assessment asks something broader: it has to account for the actual, potentially more varied audience the content is likely to reach, including foreseeable exposure to children, older people, or audiences with less digital or AI literacy than the primary audience the deployer had in mind. A deployer who tests disclosure against their core audience’s media literacy and stops there has answered the wrong question if the content is likely to circulate further than that audience — which most social content is.

The EU icon and the taxonomy nobody has finished building

The Code of Practice’s Section 2 covers Article 50(4) and 50(5) labelling specifically, distinct from the Section 1 marking obligations under Article 50(2). Alongside it, the Commission has floated a standardised visual label for AI-generated content — an “AI” mark, localised as “KI” in German or “IA” in French — together with a taxonomy that would distinguish “fully AI-generated” content from “AI-assisted” content and attach different disclosure requirements to each. Neither the icon nor the taxonomy is settled law; both are proposals moving alongside the Code rather than requirements written into Article 50 itself. Whether to sign the Code at all is a separate decision with its own trade-offs, worth working through on its own terms.

What’s left over

The law enforcement exception applies here as it does throughout Article 50: use authorised by law to detect, prevent, investigate or prosecute criminal offences falls outside the disclosure duty. Open-source licensing doesn’t help elsewhere — Article 2(12) exempts free and open-source AI systems from large parts of the Act, but the exemption specifically carves out Article 50, so a deepfake or text-generation system released under an open licence is fully subject to the labelling duties described here. And none of this shifted in the Digital Omnibus reshuffle: Article 50(4) applies from 2 August 2026 regardless of what happened to the high-risk timeline.

Frequently asked questions

Does a satirical deepfake of a real politician escape labelling?

Not reliably. If the content also bears on public discourse about that person’s decisions or conduct, it’s simultaneously public-interest content, and the guidelines’ worked example treats that overlap as defeating the satire carve-out rather than being resolved in the deployer’s favour. Political content aimed at a real, identifiable person is the case to assume you can’t rely on the exception, not the case to assume you can.

Does someone glancing at AI output before publishing count as editorial control?

That’s a thin claim to either condition. The stronger reading requires an actual review process and a person who holds editorial responsibility for the publication — not evidence that a human technically looked at the text. If you can’t name who is accountable for what goes out, you likely don’t meet the second condition regardless of the first.

Does an AI-written product description count as a matter of public interest?

No. The text limb of Article 50(4) only reaches content published to inform the public on matters of public interest — news, safety information, and similar categories. Commercial copy was never in scope, so the editorial-control carve-out is irrelevant to it; there was never a disclosure duty to carve out of.

Do you need both a visible label and machine-readable metadata?

Generally yes, and they’re not substitutes. Article 50(2) machine-readable marking is a provider duty attached to the output itself; Article 50(4) labelling is a deployer duty attached to how the content is published or presented to people. A provider marking its model’s output doesn’t relieve the deployer of disclosing a deepfake to its actual audience.

Who has the labelling duty — the agency that made the content or the client that published it?

Article 50(4) attaches to the deployer — whoever puts the content in front of the public — not necessarily whoever operated the generative tool. An agency producing a deepfake on a client’s behalf isn’t automatically who Article 50(4) is speaking to if the client is the one publishing it; that allocation is worth fixing in the contract rather than assuming.

Posted by admin in Data, Identity & Compliance UX Knowledge Base
26
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.

Posted by admin in Public Authority & Certified Provider Integrations Knowledge Base
22
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.

Posted by admin in Public Authority & Certified Provider Integrations Knowledge Base
18
Aug
2026

“Safety component” after the Omnibus: a narrower test

The Digital Omnibus narrows the definition that decides whether AI embedded in a regulated product counts as high-risk under the EU AI Act (Regulation (EU) 2024/1689). AI used solely for user assistance, performance optimisation, service efficiency or automation, or convenience or quality control no longer makes a component a “safety component” — and doesn’t trigger high-risk classification by virtue of sitting inside a regulated product — unless its failure or malfunction would actually endanger health or safety. Separately, the Machinery Regulation moved out of Annex I Section A into Section B entirely, so AI-enabled machinery now complies with sectoral safety rules instead of both regimes at once. Every guide written before May 2026 is describing a test that no longer applies.

The old test and why it swept too wide

Article 6(1) classifies an AI system as high-risk when two conditions are both met: it’s intended for use as a safety component of a product, or is itself a product, covered by the Annex I Union harmonisation legislation; and that product requires third-party conformity assessment under that legislation before it can be placed on the market. Whether an AI function counts as a “safety component” in the first place decides whether this whole test even applies.

The original definition of safety component covers a component that fulfils a safety function for a product or AI system, or whose failure or malfunction endangers the health and safety of persons or property. That second limb is where the trouble sits. Read expansively, almost any function embedded in a regulated product can be argued into it — an optimisation model inside a lift or a boiler doesn’t itself perform a safety function, but a sufficiently loose reading of “failure… endangers health and safety” could sweep it in anyway, on the theory that anything going wrong inside safety-regulated machinery carries some attenuated safety implication.

What the new test asks

The narrowed definition collapses this to one question: could the component’s failure or malfunction actually endanger health or safety? If the answer is no, and the function is assistance, optimisation, efficiency, automation, convenience, or quality control, it isn’t a safety component — regardless of what product it happens to sit inside.

Two examples on either side of the line. A predictive-maintenance model that flags when industrial machinery needs servicing is squarely an optimisation function: if it fails, the direct consequence is a missed maintenance window, not an immediate safety event, so it’s a strong candidate for falling outside the safety-component definition under the new test. A torque-limiting or collision-avoidance function built into the same machinery is a different case entirely — its failure directly creates a safety risk, which is exactly what the carve-out was never meant to exempt. The label attached to a function matters far less than what actually happens when it fails.

Annex I Section A vs Section B

This distinction decides how much of the Act applies at all. Section A covers New Legislative Framework legislation — medical devices, toys, personal protective equipment, gas appliances, and, until this reform, machinery. Section B covers other Union harmonisation legislation, including aviation security, agricultural and forestry vehicles, motor vehicle type-approval, marine equipment, and rail interoperability. For systems in Section B, only Article 6(1) itself, Articles 102 to 109, and Article 112 apply — essentially none of the Act’s substantive high-risk apparatus, the conformity assessment procedures, or the registration duties reach them at all.

The Omnibus moved only the Machinery Regulation from Section A to Section B. That’s a narrower outcome than what was actually on the table during trilogue: the deadlock that briefly collapsed negotiations centred on a Parliament proposal to exclude far more broadly — medical devices, toys, connected cars, and industrial machinery all together. The final compromise pulled back to Machinery alone. It isn’t a deregulation of industrial AI, either — the Commission is empowered to adopt delegated acts under the Machinery Regulation itself, not the AI Act, adding AI-specific health and safety requirements for systems that would otherwise have been high-risk. Oversight doesn’t disappear; it moves into the sectoral regime.

The other overlap relief, and its condition

Products that stayed in Section A — medical devices and toys among them — get a different, conditional form of relief instead of a full carve-out. Where the sectoral legislation already contains AI-specific requirements equivalent to or higher than the AI Act’s own, the Commission may, by implementing act, limit how far Articles 9 to 15 and 17 to 25 actually apply to those systems. That’s a genuinely different legal instrument from the Machinery-specific delegated acts, and it comes with its own timing: implementing acts addressing this general sectoral overlap are expected by 2 August 2027, while the Machinery-specific delegated acts are expected by 2 August 2028, tied to when Annex I obligations actually start binding. Both dates are worth putting on a calendar. Neither is a rule you can rely on today — nothing is actually limited until the Commission acts.

When any of this binds

Annex I high-risk obligations now apply from 2 August 2028 rather than 2 August 2027, under the same Digital Omnibus reform that deferred Annex III obligations to 2 December 2027. As with every date in this reform, it binds only once the amending regulation is published in the Official Journal and enters into force — as of this writing, formal adoption and publication were still pending, with the original 2 August 2026/2027 calendar remaining the legally operative one until that happens.

Frequently asked questions

Is a predictive maintenance model a safety component?

Generally not, under the narrowed test — unless the specific machine’s failure mode makes a missed service interval itself a direct safety event rather than an efficiency loss. That’s genuinely fact-specific: the same category of model can land on either side depending on what actually happens when the maintenance flag is missed.

Does the Medical Devices Regulation change?

Not in the same way. Medical devices remain in Annex I Section A — they didn’t get the Machinery-style move to Section B. What they get instead is the conditional relief described above: if the Commission determines, by implementing act, that the sectoral legislation already imposes equivalent AI-specific requirements, application of the relevant AI Act articles can be limited. Until that happens, the full parallel regime still applies.

What about toys and lifts?

Both stay in Section A, on the same footing as medical devices — eligible for the conditional implementing-act relief if the Commission acts, but not moved to Section B the way Machinery was. Lifts in particular sit under their own directive, separate from the Machinery Regulation, and nothing in this reform touched that separately.

Does “quality control” cover visual inspection?

Often, but not automatically. A visual-inspection model that flags defective units for human review before they’re used is a strong fit for the quality-control carve-out — its failure means a defect goes unflagged, not an immediate safety event. But if that inspection is the only safeguard standing between a genuinely dangerous defective unit and its use, the “failure would endanger health or safety” test can still catch it. The function’s name doesn’t decide the answer; the actual consequence of it failing does.

Who decides — us or the notified body?

The provider makes the initial classification call, consistent with how Article 6 works generally — nobody else does it for you upfront. Where third-party conformity assessment still applies, a notified body’s scope determination matters downstream, but a market surveillance authority retains the ordinary power to review a provider’s classification later and require correction if it disagrees, the same oversight mechanism that applies to Article 6(3) classification calls elsewhere in the Act.

Posted by admin in RegTech Glossary & Standards
14
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.

Posted by admin in Financial, AML & Regulatory Reporting Knowledge Base
12
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.

Posted by admin in Financial, AML & Regulatory Reporting Knowledge Base
10
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.

Posted by admin in Workforce, Labour & HR Compliance Reporting