GDPR

15
Sep
2026

Public bodies must refuse unregistered high-risk AI

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

The rule and what it forces into your process

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

What the public-authority deployer files itself

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

When your registration disappears from public view

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

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

Real-world testing is invisible by default

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

Two gaps to plan around

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

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

How to operationalise the check

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

Frequently asked questions

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

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

Does a framework agreement help?

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

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

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

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

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

Does this apply to a system already in service?

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

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

The AI Act reaches companies that never targeted the EU

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

The claim

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

How this differs from the GDPR, precisely

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

The worked example, in full

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

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

Why the usual mitigations fail

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

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

The second, quieter expansion

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

The counter-arguments

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

What this means if you sell outside the EU

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

The carve-outs that actually help

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

Posted by admin in Digital Operational Compliance & EU AI Act Knowledge Base
25
Jul
2026

When you don’t have to label your chatbot as AI

AI Act chatbot disclosure: when you don’t need a label

Article 50(1) of the EU AI Act (Regulation (EU) 2024/1689) requires providers to design AI systems that interact directly with people so those people are told they are dealing with an AI — “unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use.”

That phrase is not new drafting. It is the average consumer benchmark from EU consumer law, almost word for word, and it has been litigated at the Court of Justice since 1998. Which means the question “do we need a disclosure banner?” has an answer with thirty years of case law behind it — and it is not the answer the compliance-banner vendors are selling.

What Article 50(1) actually requires

Providers — not deployers — must ensure that AI systems intended to interact directly with natural persons are “designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system.” It is a design obligation, discharged at build time, and it sits with whoever puts the system on the market under their own name.

In practice the deployer inherits it. If you buy a chatbot and drop it on your checkout page, the provider owes the design duty, but you are the one whose customers see the result — and the exception turns on your circumstances and context of use, which the provider never saw. That gap is the reason contract terms on this matter more than most people assume.

The exposure is not theoretical: Article 99(4)(g) places breaches of Article 50 in the tier of up to €15,000,000, or 3% of total worldwide annual turnover for the preceding financial year if the offender is an undertaking, whichever is higher. Article 50 applies from 2 August 2026 and the Digital Omnibus did not defer it.

Systems in scope

White & Case’s EU AI Act Handbook reads the category as covering chatbots, voice assistants and robo-services — anything intended to interact directly with individuals. It explicitly does not include AI systems designed to interact exclusively with other AI systems or other non-human systems.

That exclusion is narrower than it sounds. An agent that calls your supplier’s API all day is out. An agent that calls your supplier’s switchboard and talks to a person is in, because the person on the other end is a natural person interacting directly with an AI system. The test is who is on the other end, not what your architecture diagram says.

The three exceptions, in order of usefulness

Article 50(1) can be switched off three ways. Only one of them is a live question for most businesses.

  • The “obvious” exception. No disclosure where it would be obvious to a reasonably well-informed, observant and circumspect person, taking into account the circumstances and the context of use. This is the one you will actually argue about.
  • Law enforcement. The obligation does not apply to AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties — unless the system is available for the public to report a criminal offence. White & Case gives the worked example: a chatbot on a law enforcement authority’s website. Public-facing crime-reporting bots get no exemption.
  • Out of scope entirely under Article 2. Chiefly individuals using AI systems in the course of a purely personal, non-professional activity. This is not an exception you can invoke as a business.

How far does “obvious” go?

The standard is contextual, not absolute — the Act says so, twice, with “taking into account the circumstances and the context of use.” So there is no such thing as a system that is obviously AI. There are only surfaces on which it is or isn’t obvious, and the same model can be on both sides of the line in the same company.

The reference person is where the argument gets decided, and the Act imported that person rather than inventing them. In Gut Springenheide (Case C-210/96), decided on 16 July 1998, the Court of Justice held that a national court assessing whether a description is misleading must take into account the presumed expectations of “an average consumer who is reasonably well-informed and reasonably observant and circumspect.” That formula became Recital 18 of the Unfair Commercial Practices Directive (2005/29/EC) and the default benchmark across EU consumer law. Article 50(1) reproduces it with one word dropped.

Three things follow, and none of them help a provider hoping for a bright line.

Nobody has defined it, deliberately. When the UCPD was negotiated, the definition of the average consumer was removed from the operative text — the European Parliament’s legislative record explains that a fixed definition was dropped precisely so the concept could keep evolving with the Court’s jurisprudence. The AI Act repeats the pattern: the formula appears in Article 50(1) and again in Recital 132, and is defined in neither. If you were waiting for the legislature to tell you what obvious means, it has told you it isn’t going to.

The reference person is not a rational maximiser. The Court has kept moving. In Compass Banca (Case C-646/22) it accepted that the average consumer’s assessment can be affected by cognitive bias — the benchmark is a notional typical consumer, not a perfectly rational market actor. A provider arguing “anyone would have realised” is arguing against a standard that has been explicitly loosened away from that assumption.

The reference person shifts when your audience does. Recital 132 says that in applying the obligation, account must be taken of the characteristics of people belonging to vulnerable groups due to their age or disability, insofar as the AI system is intended to interact with those groups too. This mirrors the UCPD, which makes specific provision for vulnerable consumers. Build a homework helper for teenagers and the person deciding what’s obvious is a teenager.

Apply that to two real surfaces. A support widget on your own site, opened by a user who clicked a button labelled “Chat”, staffed by a bot called AI Assistant, answering instantly at 3am: a decent argument that disclosure adds nothing a reasonably observant person doesn’t already have. An outbound call to a customer’s mobile in a synthetic voice: not obvious, ever. The recipient did not choose the channel, has no context, has one second of audio to work from, and the entire history of the average consumer test runs through cases about people being misled in exactly that posture.

White & Case’s own advice is to treat the exemption with caution, on the reasoning that a court or regulator may read the level of information a reasonably well-informed user is deemed to have more narrowly than a provider would like. One more reason for caution is on the calendar. The Commission is obliged under Article 96(1)(d) to develop guidelines on the practical implementation of Article 50, and its published FAQ confirms those guidelines will address AI interaction specifically, that a public consultation on the draft has closed, and that the final version will be published before the obligations start to apply. The guidelines can narrow the exception. They cannot widen it beyond the text.

What the Code of Practice does not cover

Worth knowing before you go looking: the Code of Practice on Transparency of AI-Generated Content is no help on this question. Article 50(7) directs the AI Office to facilitate codes of practice on the detection and labelling of artificially generated content — that is Article 50(2) and (4). When the Commission issued its opinion on 8 July 2026, it concluded the Code adequately covers Articles 50(2), (4) and (5). Article 50(1) is not on that list. There is no code to sign that demonstrates your chatbot disclosure is adequate.

Form and timing you can’t negotiate away

If the exception doesn’t apply, Article 50(5) governs how you tell people, and it is short enough to quote in full: the information “shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure. The information shall conform to the applicable accessibility requirements.”

Four consequences:

  • Clear and distinguishable. Distinguishable from what surrounds it. A line in the terms of service is not distinguishable; a greyed-out footer under the input box is a bad bet.
  • At the latest at first interaction. White & Case reads this as akin to the point-in-time notice requirements under the GDPR — the notice attaches to the moment, not to a document you have somewhere. You cannot disclose on turn three.
  • Accessibility requirements. Recital 132 adds that the information must be provided in a format accessible to persons with disabilities. A purely visual badge on a voice product fails this on its face.
  • Vulnerable users. This one is Recital 132, not Article 50(5) — worth knowing, because summaries routinely present it as an operative requirement. It shapes how the obligation and the exception are applied rather than adding a fifth element to the form rules.

Why the obligations stack

Article 50(6) says paragraphs 1 to 4 “shall not affect the requirements and obligations set out in Chapter III, and shall be without prejudice to other transparency obligations laid down in Union or national law for deployers of AI systems.” Chapter III is the high-risk regime. So clearing Article 50(1) tells you nothing about Articles 13 and 26, and nothing about the GDPR notice you already owed.

The general-purpose AI overlap is real but comes from elsewhere — Article 50(2) applies to providers “of AI systems, including general-purpose AI systems”, and Chapter V imposes its own model-level duties. White & Case reads the whole set as applying cumulatively. A conversational assistant built on a general-purpose model, deployed in a high-risk context, can owe disclosure under 50(1), marking under 50(2), instructions for use under Article 13 and model documentation under Chapter V, all at once. They are not alternatives and satisfying one is not a defence to another.

Frequently asked questions

Does a bot name count as disclosure?

Calling it “AI Assistant” is evidence that the fact was obvious, not compliance with the disclosure duty. The two are different arguments: one says the exception applies so no notice was owed, the other says notice was given clearly and distinguishably at first interaction. If you are relying on the name, you are relying on the exception — write down why, in context, before a regulator asks.

Does the exception apply to voice?

Not to outbound voice, realistically. The recipient did not initiate the interaction, has no visual context and no prior expectation, and synthetic speech is now good enough that “reasonably observant” does not get you there. Inbound voice on a line the caller dialled knowing it is automated is a different and better argument.

Who is liable, the provider or the deployer?

Article 50(1) puts the design duty on the provider. But the exception depends on the circumstances and context of use, which the deployer controls — so a provider who ships without disclosure on the assumption that deployment will be obvious has made a bet on someone else’s product decisions. Allocate it in the contract: who decides whether the exception is relied on, and who evidences it.

What about an AI agent that calls a customer?

In scope of Article 50(1), and the exception almost certainly does not apply. See outbound voice above. This is the single clearest case in the whole provision.

Does this apply to internal-only tools?

Yes, if the tool interacts directly with natural persons — the Act does not distinguish between customers and employees here. The Article 2 carve-out covers individuals using AI in a purely personal, non-professional activity, which is the opposite of an internal work tool. Whether disclosure is obvious to a trained employee using a named internal assistant is a much easier argument than the customer-facing case, but it is still the argument you have to make.

Posted by admin in Data, Identity & Compliance UX Knowledge Base
09
Jul
2026

What Is SaaS Data Governance EU?

Definition

SaaS data governance EU is the set of policies, controls, workflows, and technical measures used to manage data in SaaS products operating in or serving the European Union. It covers how data is collected, classified, stored, accessed, shared, protected, retained, deleted, transferred, and documented under EU legal and operational requirements.

For product, compliance, and SaaS teams, SaaS data governance EU is not only a privacy function. It is a product operating model for data quality, accountability, access control, audit readiness, customer trust, and regulatory resilience.

Why SaaS Data Governance EU Matters

SaaS data governance EU matters because EU data rules affect product design, customer procurement, security architecture, vendor management, and go-to-market claims. Teams need to know what data they process, where it is stored, who can access it, which subprocessors are involved, what retention rules apply, and how customers can exercise their rights or meet their own obligations.

The core legal baseline is the GDPR, which has applied since 25 May 2018 and governs personal data processing in the EU. Newer EU data frameworks also matter. The Data Governance Act has applied since September 2023 and focuses on trusted data sharing mechanisms, while the Data Act has applied since 12 September 2025 and creates rules for access to and use of data in connected products and related services, as well as cloud and data processing services.

Core Areas of SaaS Data Governance EU

Data inventory and classification

Teams should maintain a clear inventory of data types, data sources, processing purposes, storage locations, owners, retention periods, and sensitivity levels. This is the foundation for privacy, security, analytics, reporting, and customer due diligence.

Access control and accountability

SaaS products need role-based access control, least-privilege permissions, admin oversight, audit logs, approval workflows, and regular access reviews. Governance should define who can access customer data, under what conditions, and how access is recorded.

Data residency and transfers

EU customers often ask where data is hosted, whether data leaves the EU or EEA, which subprocessors are used, and what safeguards apply to international transfers. Product and infrastructure decisions should support clear answers, not ad hoc explanations.

Retention and deletion

Data governance must define how long different data types are kept, when they are deleted, how deletion is triggered, and whether backups, logs, analytics stores, or third-party tools follow the same lifecycle rules.

Data sharing and interoperability

Modern EU data regulation increasingly focuses on controlled data access, portability, switching, and interoperability. SaaS teams should design export, API, access, and offboarding workflows with governance in mind, not as afterthoughts.

Common Implementation Questions

What should SaaS teams do first?

Start with a data map. Identify all personal, customer, operational, product, analytics, support, billing, and telemetry data. Then map processing purposes, systems, locations, subprocessors, access rights, retention periods, and customer-facing documentation.

Is this only a compliance task?

No. Compliance defines obligations, but product and engineering teams implement the actual controls. Data governance depends on architecture, permissions, logging, UX, APIs, integrations, admin tools, deletion workflows, and customer documentation.

What evidence do customers usually request?

Customers may ask for data processing agreements, subprocessor lists, security certifications, data flow diagrams, retention policies, access control policies, audit logs, transfer safeguards, incident response procedures, backup policies, and deletion processes.

What is the biggest implementation risk?

The biggest risk is fragmented data ownership. If product, engineering, analytics, support, and sales tools all store customer data without a shared governance model, the company may struggle to answer basic questions about access, retention, deletion, and transfers.

Can a vendor claim EU data compliance?

Use caution. “Fully compliant” is risky unless the vendor defines the scope, data types, jurisdictions, legal roles, controls, subprocessors, and date of assessment. Stronger wording explains what the system supports: data inventory, access control, audit trails, retention workflows, deletion workflows, transfer documentation, and customer governance evidence.

Related Standards and Frameworks

SaaS data governance EU often overlaps with GDPR, Data Governance Act, Data Act, ISO/IEC 27001, ISO/IEC 27701, SOC 2, NIST Cybersecurity Framework, cloud security controls, privacy management systems, and internal data governance policies.

These frameworks do not replace legal analysis, but they help structure controls, evidence, ownership, monitoring, and audit readiness.

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