EU AI Act

Oct

2026

The 10^25 FLOP threshold: what the AI Act never says

Article 51(2) of the EU AI Act (Regulation (EU) 2024/1689) presumes a general-purpose AI model has high-impact capabilities once the cumulative compute used to train it, measured in floating-point operations, exceeds 10^25. What the Act never spells out is how to actually count that number. Do earlier versions of a model contribute their compute to a later one’s tally? If a model is branched, is each branch’s compute counted separately or added together? A threshold this consequential, sitting with no counting methodology attached to it, is the whole story here.

What the threshold is and isn’t

Article 51(1) classifies a general-purpose AI model as presenting systemic risk if it meets either of two conditions: it has high-impact capabilities established through appropriate technical tools and methods, or the Commission has designated it as comparable, ex officio or following a qualified alert from the scientific panel, based on the criteria in Annex XIII. The 10^25 FLOP figure in Article 51(2) only speaks to the first route — it’s a rebuttable presumption that high-impact capabilities exist, not a definition of systemic risk itself, and not the only way a model ends up in scope. Article 51(3) lets the Commission adjust the threshold by delegated act to reflect the state of the art, including algorithmic improvements and more efficient hardware — so even the number itself isn’t fixed forever, only fixed until the Commission decides otherwise.

The contradiction at the centre

Recital 111 defines high-impact capabilities relative to the frontier: capabilities that match or exceed those recorded in the most advanced general-purpose AI models. That’s a moving target by design — as the frontier advances, the bar for “high-impact” moves with it. The 10^25 figure Article 51(2) actually operationalises this with is nothing of the sort: it’s fixed, absolute, and doesn’t move on its own between one delegated act and the next.

The practical consequence is exactly the one the Act’s own drafting implies but never resolves: a model that clears the relative, frontier-based bar this month may not clear it next month once competitors release something more capable, while the absolute FLOP number attached to that same model never changes at all. There’s a second problem sitting underneath this one — most frontier models are proprietary, so the actual comparator Recital 111’s test asks you to measure yourself against usually isn’t measurable at all. The relative definition and the absolute number were clearly meant to approximate each other. Nothing in the text guarantees they track.

The counting questions the text leaves open

Three practical questions decide whether a lot of real models sit above or below the line, and the Act answers only one of them.

Fine-tuning — this one has a real answer. Recital 111 states that the cumulative compute input used for training includes the total compute used for activities to improve the model’s capabilities prior to deployment, explicitly naming pre-training, synthetic data generation, and fine-tuning. So fine-tuning compute counts toward the cumulative total, at least for the fine-tuning that happens before a model’s initial deployment. What that doesn’t resolve is the harder version of the same question: whether fine-tuning or continued training applied after an earlier version was already placed on the market gets added to that version’s original tally, or starts a new count.

Prior iterations — genuinely unresolved. Nothing in the text says whether compute spent on earlier versions of a model contributes to a later version’s cumulative figure, which matters enormously for any provider that iterates on the same underlying architecture across releases rather than training each version from nothing.

Branches — also unresolved. If a single training run forks into multiple variants, nothing says whether each branch’s compute is counted independently or whether the branches’ compute is summed as one cumulative figure against the threshold.

Annex XIII gives the Commission its own set of proxies for the designation route — estimated training cost, time, or energy consumption, as alternatives to a direct FLOP count — but it’s unclear whether a provider doing its own self-assessment under Article 51(2) has to use the same criteria, and none of these proxies answer the iteration or branching questions regardless of which measure you use.

The other Annex XIII numbers

The FLOP threshold gets all the attention, but Annex XIII gives the Commission six other criteria to weigh when designating a model as comparable under Article 51(1)(b), and one of them is rarely quoted at all:

the number of parameters in the model;
the quality or size of the training dataset, for example measured in tokens;
the amount of compute used to train it, measured in FLOPs, or expressed through a combination of other variables such as estimated cost, time, or energy consumption;
the model’s input and output modalities — text-to-text, text-to-image, multimodal — along with advanced thresholds for high-impact capabilities specific to each modality, and the particular type of input or output involved, such as biological sequences;
benchmarks and capability evaluations, including the number of tasks the model performs without additional training, its adaptability to learn new distinct tasks, its degree of autonomy and scalability, and the tools it can access;
whether it has a large impact on the internal market because of its reach — which is presumed once the model has been made available to at least 10,000 registered business users established in the EU;
the number of registered end-users.

What you do when you cross it

If a model meets the Article 51(1)(a) condition, the provider notifies the Commission without delay, and in any event within two weeks of the condition being met or of it becoming known that it will be met. The notification has to include the information needed to demonstrate the condition is satisfied. Providers aren’t limited to reporting the fact, either — in that same notification, a provider can put forward sufficiently substantiated arguments that, despite meeting the threshold, the model exceptionally doesn’t present systemic risks because of its specific characteristics, and therefore shouldn’t be classified as a systemic-risk model. If the Commission decides those arguments aren’t sufficiently substantiated, it rejects them, and the model is treated as a systemic-risk model regardless.

The appeal loop

The self-notification route comes with a built-in argument mechanism. The Commission’s own ex officio designation route, under Article 51(1)(b), doesn’t have an equivalent express provision letting a provider make its case before the decision is made — which pushes toward providers over-notifying rather than risk being designated without having had the chance to argue first.

Once a model has been designated this way, though, there is a path back. A provider can submit a reasoned request for reassessment, and the Commission will consider whether the model, measured against the Annex XIII criteria, is still properly considered a systemic-risk model. That request has to rest on objective, detailed, and new reasons that came to light after the designation decision — not a restatement of the original case — and the earliest a provider can make it is six months after the designation. If the Commission reassesses and decides to maintain the designation anyway, the provider has to wait another six months before trying again. There’s no cap on how many times this can repeat, only the six-month cooldown between each attempt.

Frequently asked questions

Is 10^25 a hard line?

No, in either direction. Above it, a provider can still argue its way out under Article 51(2) and 52(2)-(3) if it can substantiate that the model’s specific characteristics mean it doesn’t actually present systemic risk. Below it, the Commission can still designate a model under Article 51(1)(b) if it finds comparable capabilities or impact using the Annex XIII criteria. The number sets a presumption, not a verdict.

Who publishes the list of systemic-risk models?

The Commission does. Article 52(6) requires it to publish and keep an up-to-date list of general-purpose AI models with systemic risk, though that duty is itself qualified by the need to respect intellectual property rights and protect confidential business information and trade secrets under EU and national law.

Does the Omnibus change Articles 51-55?

No. This is one of the more consistently confirmed points across current commentary: the Digital Omnibus reform is squarely focused on the Annex III and Annex I high-risk timeline, registration, and related provisions. The general-purpose AI rules in Articles 51 through 55 have applied since 2 August 2025 and remain untouched by the reform.

What if we don’t know our own FLOP count?

The Act doesn’t offer a substitute self-certification route for this situation — the cost, time, and energy proxies in Annex XIII exist for the Commission’s own comparable-capabilities designation under Article 51(1)(b), not explicitly as an alternative counting method a provider can rely on for its own Article 51(2) self-assessment. A provider without confident compute accounting is sitting in exactly the gap this article describes, without a clearly signposted way out of it.

Can we be designated without ever notifying?

Yes. Article 52(1) states plainly that if the Commission becomes aware of a general-purpose AI model presenting systemic risks that it hasn’t been notified about, it can decide to designate that model as one anyway. Notification is the expected route in; it isn’t the only route the Commission can use to get there.

Sep

2026

Significant change vs substantial modification: same thing?

Article 111(2) of the EU AI Act (Regulation (EU) 2024/1689) grandfathers high-risk systems already on the market unless they undergo “significant changes” in design after the general application date. Article 3(23), in a completely separate part of the Regulation, defines “substantial modification.” Recital 177 says the two are equivalent in substance. White & Case’s own Handbook commentary on this point is unusually blunt for a law-firm guide: “It is not entirely clear why two separate terms are used.” Whether your legacy AI estate stays outside the Act’s high-risk rules turns on a distinction its own drafters apparently didn’t mean to create.

What the grandfathering actually gives you

Article 111(2) applies the Regulation to operators of legacy high-risk systems — those placed on the market or put into service before the general application date — only if those systems undergo significant changes in their design from that date onward. Read that structure carefully: it isn’t a grace period that eventually expires on its own. It’s an indefinite exemption, conditional on one thing only — that you don’t significantly change the system. Stand still, and the exemption holds indefinitely. Change it, and you’re pulled into the full regime from that point.

The three exceptions to the free pass

Three categories don’t get to rely on standing still.

Public authority deployers. Regardless of whether a system undergoes any change at all, providers and deployers of high-risk AI systems intended for use by public authorities have to comply with the Regulation’s requirements no later than six years after entry into force — 2 August 2030.
Annex X large-scale IT systems. AI components of the large-scale IT systems established under the legal acts listed in Annex X have their own fixed deadline: 31 December 2030, for systems placed on the market before the relevant cutoff.
The Article 5 prohibitions. These were never grandfathered in the first place. Both of Article 111’s grandfathering provisions open with “without prejudice to the application of Article 5” — the prohibited-practices regime has applied since 2 February 2025, full stop, regardless of when any given system was placed on the market.

The GPAI cliff edge

Article 111(3) draws its own hard line, and it’s worth seeing exactly how sharp it is. A general-purpose AI model placed on the market before 2 August 2025 gets until 2 August 2027 to come into compliance. A model placed on the market on or after 2 August 2025 faces enforcement immediately, from the moment it’s placed on the market. White & Case’s own framing of this makes the stakes concrete: a model placed on the EU market on 1 August 2025 faces no enforcement risk for two years; the same model placed one day later, on 2 August 2025, faces immediate risk. Providers of GPAI models were, in the Handbook’s words, incentivised to place those models on the EU market before that specific deadline. One day either side of a date is worth two years.

Does the Omnibus reset the clock?

Article 111(2)’s grandfather clause attaches to “the general date of application” — and the Digital Omnibus reform moved that date, deferring Annex III high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028. That’s not a cosmetic shift. If the cutoff itself moves, the population of systems that count as “legacy” moves with it: a system placed on the market in, say, October 2027 — which would have squarely missed the old 2 August 2026 cutoff and faced the full regime immediately — can now fall on the grandfathered side of a later line, provided it isn’t significantly changed afterward.

The honest caveat, consistent with everything else tied to this reform: the new dates bind only once the amending regulation is published in the Official Journal and enters into force. Until then, the original 2 August 2026 cutoff remains the legally operative one. The GPAI timeline in Article 111(3) is a separate matter entirely — nothing in the Omnibus reform touched the 2 August 2025 / 2 August 2027 dates, since that deferral was built specifically around the Annex I and Annex III high-risk regime, not the general-purpose AI rules.

So what is a significant change?

Since Recital 177 treats the two concepts as equivalent, the operative test is the one Article 3(23) actually writes down: a change that was not foreseen or planned in the initial conformity assessment, and that either affects the system’s compliance with the Chapter III, Section 2 requirements, or modifies the intended purpose the system was assessed for. That’s the same test this piece’s companion article on Article 43(4) walks through in detail for systems that keep learning after deployment — the pre-determined change envelope you document there is, in substance, the same boundary that decides whether a legacy system has quietly lost its grandfathering here.

Frequently asked questions

Does a UI change count as a significant change?

Usually not, unless it touches how the system actually meets the Chapter III Section 2 requirements — a change to how oversight information or output explanations are presented to a human reviewer could cross that line, where a purely cosmetic interface refresh wouldn’t. The test is whether compliance or intended purpose is affected, not how visible the change is to an end user.

Does deploying into a new customer segment count?

Likely yes, if the new segment amounts to a different intended purpose than what the system was originally assessed for. This is close to the paradigm case the “modifies the intended purpose” limb of Article 3(23) is written for — the same system, doing a materially different job for a materially different population, is exactly the scenario grandfathering isn’t meant to protect.

Does a routine security patch count?

Generally not, if it’s the kind of maintenance foreseeable at the time of the initial assessment and doesn’t itself change how the system meets the substantive requirements or what it’s for. A patch significant enough to materially alter the system’s behaviour or outputs is a different matter, and the size of the change matters more than its label as “just a patch.”

What if we never carried out a conformity assessment in the first place?

This is a harder problem than a grandfathering question, and this piece won’t pretend otherwise. Article 3(23)’s test explicitly measures a change against what was foreseen or planned in the initial conformity assessment — without one, there’s no documented baseline to test a change against at all. A system in that position has a more fundamental compliance gap than whether a later change was “significant”; that gap is worth resolving before the grandfathering question becomes the relevant one.

Can we deliberately freeze a system’s design to stay exempt?

Yes, and White & Case’s own commentary treats this as a real, foreseeable incentive rather than a loophole — not changing a legacy system’s design keeps it inside Article 111(2)’s exemption indefinitely, subject to the three exceptions above. Freezing the system’s design doesn’t freeze every other obligation that might apply regardless of risk tier, though — Article 4 AI literacy, for instance, isn’t tied to this grandfathering at all and applies whether or not the underlying system changes.

Sep

2026

Retraining a high-risk model without a new assessment

Article 43(4) of the EU AI Act (Regulation (EU) 2024/1689) provides that, for high-risk systems that keep learning after being placed on the market or put into service, changes to the system and its performance that were pre-determined by the provider at the time of the initial conformity assessment — and that form part of the technical documentation required under Annex IV, point 2(f) — do not count as a substantial modification. No new conformity assessment follows. The entire cost of staying compliant while you keep retraining rests on documentation you write once, at the start, and almost nothing written for MLOps teams says so plainly.

The rule and the timing that makes or breaks it

Read the timing again, because it’s the whole mechanism: the changes have to be pre-determined at the time of the initial conformity assessment. Not documented eventually. Not written up after a retraining cycle already happened and worked out fine. If it isn’t in the technical file the assessment was actually based on, it doesn’t get the exemption — it’s just an undocumented change, and undocumented changes are exactly what Article 3(23) is built to catch.

What “pre-determined” has to look like in a technical file

Annex IV, point 2(f) — the specific provision Article 43(4) cross-references — requires, where applicable, a detailed description of pre-determined changes to the AI system and its performance, together with all relevant information about the technical solutions put in place to ensure the system’s continued compliance with the Chapter III, Section 2 requirements as those changes happen. That’s two things, not one: a description of what can change, and an explanation of how you’ve engineered continued compliance despite it changing.

Two companion provisions in the same Annex turn this from a paperwork exercise into something that has to actually be tested. Point 2(g) requires dated, signed test logs and reports specifically covering the pre-determined changes described in point (f) — you don’t just describe the envelope, you have to show testing that happened inside it. And point 6, separately, requires an ongoing description of the relevant changes the provider actually makes over the system’s lifetime — a running log distinct from the upfront envelope, recording what happened against what was planned.

In practice, the envelope worth drafting into that technical file covers: the retraining cadence itself; the bounds of the data sources involved, not just their identity; the performance ranges you expect, tied to the specific metrics you’re measuring against; drift thresholds that would trigger a stop; rollback conditions if a retrained version underperforms; and, most importantly, a clear statement of the point at which a change would leave this envelope and stop being “pre-determined” at all. Tie each of these back to your Article 11 technical documentation as a whole and your Article 17 quality management system — the envelope isn’t a standalone document, it’s a component of both.

What is definitely outside the envelope

Article 3(23) defines a substantial modification as a change to an AI system, after it’s placed on the market or put into service, that the provider did not foresee or plan in the initial conformity assessment, and that either affects the system’s compliance with the Chapter III, Section 2 requirements, or changes the intended purpose the system was assessed for. Two disjunctive triggers, either one sufficient, sitting on top of the same threshold question: was this foreseen at the time of the initial assessment or wasn’t it.

A retraining run using the data sources, cadence and performance bounds you described in your point 2(f) envelope, producing a model that still does the same job to the same standard, sits inside the exemption — that’s precisely what Article 43(4) exists to cover. A retraining run that pulls in a materially different data source you never documented, or that shifts the system toward a new use case, sits outside it on both available grounds: it wasn’t foreseen, and it plausibly touches compliance or purpose. The difference isn’t how big the change feels. It’s whether you wrote it down before you were assessed.

Where the envelope has to be re-declared

Once a change actually crosses into substantial modification, the practical consequence is that a new conformity assessment applies — the system is, in effect, being placed on the market again in its modified form. That loops back to registration: the EU database registration duty attaches to placing a system on the market or putting it into service in the first place, so a substantially modified system re-triggers that same duty rather than quietly inheriting the original entry. Treat a substantial modification as resetting the compliance clock, not just the model weights.

The neighbouring clocks

A few retention and monitoring duties sit right next to this one, and they’re worth having straight rather than confusing with each other. Article 12 requires high-risk systems to automatically log events across their lifecycle, and one of the three purposes that logging capability is explicitly built for is identifying situations where a substantial modification occurs — the log isn’t just an audit trail, it’s part of how you’re meant to notice you’ve left your own envelope. Article 19 then sets how long those logs have to be kept: a period appropriate to the system’s intended purpose, and at least six months, unless other Union or national law — particularly data protection law — requires longer. Separately, Article 18 requires the provider to keep the technical documentation, the quality management system documentation, any documentation of changes approved by a notified body, notified-body decisions, and the declaration of conformity available to national authorities for ten years after the system was placed on the market or put into service.

Frequently asked questions

Does a fine-tune count as a substantial modification?

It depends entirely on whether it falls inside your documented envelope. A fine-tune using the data sources and staying within the performance bounds you described in your point 2(f) file isn’t a substantial modification — that’s the exemption working as intended. A fine-tune that pulls in undocumented data or pushes performance outside the ranges you committed to isn’t covered, regardless of how routine it felt to run.

Does swapping the base model count?

Almost certainly, yes. Swapping the underlying model is rarely something a provider pre-determined as a continued-learning change in the original technical file — it’s closer to a different system than a retrained version of the same one, and it’s hard to argue it doesn’t touch Chapter III Section 2 compliance or the assessed intended purpose. Treat a base-model swap as a substantial modification by default, and build the case for an exception only if your original documentation genuinely anticipated it.

Does a new training run on the same pipeline count?

Only if it stays inside what you documented. The same pipeline producing a run that matches the data-source bounds and performance ranges already on file is exactly what the exemption is for. The same pipeline producing a run against new data, or aimed at different performance characteristics than what you described, has left the envelope even though nothing about the infrastructure changed.

Who decides — us or the notified body?

For Annex VI self-assessed systems, the provider makes this call itself, as part of its ongoing Article 17 quality management obligations — there’s no notified body in the loop to consult. Where a notified body is involved under Annex VII, changes it has specifically approved get their own retention requirement under Article 18, which suggests an ongoing role in confirming certain categories of change — but the initial pre-determination is still the provider’s own documentation choice, made before that body ever assessed anything.

Does the December 2027 date change any of this?

Not the substance. Article 43(4) is part of the Chapter III framework that, for Annex III systems, now applies from 2 December 2027 rather than 2 August 2026 following the Digital Omnibus reform. The rule itself is unchanged — only the date it starts binding on stand-alone Annex III systems moved, alongside every other obligation in that same package.

Sep

2026

Biometric AI: no standards means a mandatory notified body

Article 43(1) of the EU AI Act (Regulation (EU) 2024/1689) gives providers of biometric AI systems — Annex III point 1 — a choice between the lighter Annex VI internal-control route and the notified-body route under Annex VII, but only where harmonised standards or common specifications have actually been applied. None have been cited in the Official Journal yet. The choice the Act promises doesn’t exist in practice right now, and the fallback it leaves you with — a notified body — is itself in short supply.

The mechanism, in three steps

This is the whole article, so it’s worth stating plainly before anything else. The choice between Annex VI and Annex VII is conditional on applied harmonised standards or common specifications. That condition is currently unmet. Therefore Annex VII — third-party assessment by a notified body — is mandatory, not optional, for biometric AI providers today.

Why there are no standards, and where they actually stand

The Commission’s original deadline for CEN-CENELEC to deliver harmonised standards was 30 April 2025. It was missed, and the Commission formally pushed it to 31 August 2025 — which also came and went without publication. By late 2025, CEN-CENELEC’s own Joint Technical Committee 21 had moved into what multiple accounts describe as crisis mode: an “exceptionality” measure that would let a small drafting group finalise the most delayed drafts and skip the normal Formal Vote stage where a public Enquiry produced a positive result. Senior figures within JTC 21 pushed back on the measure even as its chair defended it as necessary to avoid signalling weakness at a politically sensitive moment.

As things actually stand: prEN 18228, covering the risk management system required by Article 9, is still in Public Enquiry, with that stage due to close at the end of July 2026 — essentially now. prEN 18286, the quality management system standard supporting Article 17, has moved further: its Enquiry closed in early 2026 and it’s currently out for Formal Vote by national standards bodies, apparently without the Formal-Vote skip that was floated for other drafts. prEN 18284, covering the data and dataset governance requirements of Article 10, is progressing alongside them. None of the three has been cited in the Official Journal, which is the only event that actually triggers a presumption of conformity — a draft standard, however advanced, confers nothing on its own.

One more standard is worth naming precisely, because a common but imprecise claim conflates it with the others: a dedicated standard for the conformity assessment process itself is still described by JTC 21’s own work programme as “in active drafting,” meaningfully behind risk management, quality management and data governance in maturity. And even once finished, a procedural standard governing how an assessment is conducted wouldn’t itself carry a presumption of conformity the way the substantive standards do — presumption of conformity attaches to meeting the essential requirements in Articles 9, 10, 15 and 17, not to the assessment methodology used to check them.

The Article 41 fallback, and why it doesn’t rescue you

The Act does have a backstop for exactly this gap: common specifications adopted by Commission implementing act under Article 41, usable where harmonised standards don’t exist or don’t fully cover the requirements. But it’s built as an exceptional, temporary measure that sunsets once the equivalent harmonised standard arrives, not a parallel permanent track. A provider that doesn’t comply with an applicable common specification has to justify why, and Member States retain the right to challenge a common specification they think doesn’t adequately meet the underlying requirements. It fills a gap; it doesn’t make the underlying uncertainty disappear.

Can you even get a notified body?

Member States had until 2 August 2025 to designate both a market surveillance authority and a notifying authority — the office responsible for authorising and overseeing notified bodies in the first place. As of the most recent tracking, nine Member States have designated both; twelve have partial arrangements or pending proposals; six have designated neither. The models vary widely — Cyprus centralised the role in a single Commissioner acting as notifying authority, market surveillance authority and single point of contact together, while Finland spread it across existing sectoral regulators including its Energy Authority, Transport and Communications Agency, and Medicines Agency.

Designating the authority is not the same as having an operational notified body. Even where a notifying authority exists and is functioning, it still has to run a specific conformity assessment body through the full designation process before that body can actually assess AI systems — a separate, further step. When you check a candidate notified body, check three things specifically: its identification number and notifying Member State in the NANDO database, the precise scope of activities it’s been notified for, and — critically — whether that scope actually covers AI Act conformity assessment, rather than only the other Union product legislation the same organisation may be notified under.

What the queue costs

The designation mechanics themselves take real time. A notified conformity assessment body can only start operating once the Commission and other Member States have raised no objection — within two weeks of notification if it’s based on an accreditation certificate, or two months if based on other documentary evidence instead. Once operating, a notified body needs appropriate liability insurance for its assessment activities, unless national law already covers that liability or the Member State itself takes direct responsibility. And if it subcontracts specific tasks, it needs the provider’s consent first, keeps full responsibility regardless, and has to retain the subcontractor qualification records for five years after the subcontracting arrangement ends. None of this is unique to AI — it’s the same structural pattern that has made notified-body capacity a persistent bottleneck under the Medical Devices Regulation for years, and there’s no reason to expect AI Act capacity to scale faster.

What to do with the extra time

Annex III obligations now apply from 2 December 2027 rather than 2 August 2026, under the Digital Omnibus reform. It’s worth being precise about what that extra time actually is. Reporting on the Commission’s original proposal describes it as deferring the high-risk obligations until measures to support compliance — harmonised standards, common specifications, Commission guidelines — were actually available, which would have tied the deadline to real-world readiness. The final agreement between the co-legislators didn’t keep that conditional structure; it settled on fixed calendar dates instead. That matters: if the standards and notified-body capacity gaps described above are still open in December 2027, the obligations apply anyway, calendar first.

What the time is genuinely useful for: inventory and classification work that doesn’t depend on any of this being resolved, and — if you’re a biometric provider — starting a conversation with a notified body now rather than waiting, given how constrained current capacity already is. What it isn’t for is assuming the standards gap will have quietly closed itself by the time the date arrives.

Frequently asked questions

Can we use a notified body established outside the EU?

No. A notified body has to be constituted under the law of a Member State and hold legal personality there — an organisation established outside the EU or EEA can’t itself hold that status, whatever other credentials it carries elsewhere.

Can we use a body that’s already an MDR notified body?

Only if that same body has separately gone through designation for AI Act conformity assessment specifically. Being notified under the Medical Devices Regulation doesn’t automatically extend to AI Act scope — check the NANDO entry for that specific activity listing rather than assuming an existing sectoral relationship carries over.

How long is an Annex VII certificate valid?

Up to four years for Annex III systems, renewable for further periods of the same length following reassessment. Annex I product systems get a slightly longer five-year ceiling instead.

What happens if a standard is finally published while our assessment is already under way?

The Act doesn’t spell out a specific transition mechanic for this exact situation, and treating it as settled would overstate what’s actually written down. In practice, this is a question to put directly to your notified body, since it’s the one applying whatever technical baseline is current at each stage of the assessment.

Does the Digital Omnibus fix the notified-body supply problem?

No — it buys time for the supply problem to resolve on its own, on a fixed calendar rather than one conditioned on the standards and capacity gaps actually closing. That’s a meaningfully different thing from fixing it, and it means providers still carry the risk that December 2027 arrives with the same shortage this article describes.

Sep

2026

Public bodies must refuse unregistered high-risk AI

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

The rule and what it forces into your process

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

What the public-authority deployer files itself

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

When your registration disappears from public view

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

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

Real-world testing is invisible by default

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

Two gaps to plan around

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

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

How to operationalise the check

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

Frequently asked questions

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

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

Does a framework agreement help?

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

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

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

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

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

Does this apply to a system already in service?

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

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.

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.

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.

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.