EU AI Act Article 50: What Voice Agents Must Disclose

What Article 50 actually says

Article 50 is the transparency article of the AI Act, and it is not one rule but a set of related ones aimed at situations where a person could be misled about what they are dealing with. Only some of it touches a voice agent, so it is worth separating the paragraphs rather than treating the article as a single obligation.

Read together, 50(1) and 50(5) produce a requirement that is unusually concrete for a piece of AI regulation. There must be a disclosure, it must be clear and distinguishable, and it must land no later than the first interaction. On a phone call the first interaction is the moment the line opens. There is no later.

What the omnibus delayed, and what it did not

This is where most summaries get it wrong, so it is worth being precise. The EU's digital omnibus process did postpone a number of AI Act deadlines, and the headlines around it left many teams with the impression that August 2026 had moved. For the disclosure duty, it has not.

The provisional agreement between the Council and the Parliament reached on 7 May 2026 pushed the machine-readable marking obligation in Article 50(2) to 2 December 2026 for systems that were already on the market before 2 August 2026. Several high-risk obligations elsewhere in the regulation moved as well. The obligation to tell a person they are talking to an AI system was not among them.

The Commission has also published guidelines on the transparency obligations for providers and deployers, which clarify the provider and deployer notions and work through practical examples. If you are building the compliance story for a client, that document is the reference to have open, because it is the interpretation the supervisory authorities will start from.

Provider or deployer: whose duty is it

Article 50 splits its duties. Paragraphs 1 and 2 sit with the provider; paragraphs 3 and 4 sit with the deployer. For a voice agent the duty you care about, 50(1), is a provider duty, which immediately raises the question of who the provider is in a chain that runs from an orchestration platform, through an integrator, to the company whose phone number is being called.

The regulation answers this by role rather than by contract. Broadly, a provider is the party that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is a party using an AI system under its own authority. The consequence that surprises people is that putting your own name on a system, or substantially modifying one, can make you its provider even if someone else wrote the software.

For most of the setups we see, that means the company whose brand answers the phone is very likely carrying the 50(1) duty, not the platform underneath it. We are not your counsel and this is not a legal opinion. The classification depends on facts we cannot see from here, and it is worth twenty minutes with a lawyer rather than an assumption. What we can tell you is which side of the line the engineering work falls on, and it falls on yours.

What 'clear and distinguishable' means on a phone line

A web product satisfies this with a label next to a chat window. A phone call has no screen, no persistent surface, and no second chance. That has three practical consequences that are easy to get wrong.

1. 01

   The disclosure has to be in the audio, not in the paperwork

   A line in your privacy policy is not a disclosure made at the first interaction. The caller has to hear it. For an inbound line that means the greeting; for an outbound call it means the opening sentence, before you ask the person anything.
2. 02

   It cannot depend on the model deciding to say it

   If the disclosure lives only in a system prompt as an instruction to mention being an AI, you have made a legal requirement probabilistic. Models drift, paraphrase, and occasionally skip. The opening line should be delivered as a fixed first message, not generated per call.
3. 03

   It has to survive a barge-in

   Callers talk over greetings constantly. If your agent stops the greeting the instant the caller starts speaking, the disclosure may never finish. Put it in the first clause of the first sentence, so an interruption two seconds in still leaves it delivered.

That third point is the one teams discover late, usually from a recording. "Good afternoon, thank you for calling Van Dijk Installations, my name is Lieke and I am an AI assistant" is a compliant sentence that gets cut off after five words most of the time. Front-load it instead.

Wording that satisfies a lawyer and survives a caller

There is a real tension here. Legal wants an unambiguous statement; the business wants a call that does not feel like a disclaimer. In practice the phrasings that work say the machine part plainly and immediately, then move on quickly. "Digital assistant" and "automated assistant" both do the job in ordinary language, and naming the agent afterwards keeps it human enough to talk to.

Good afternoon, you're speaking with the digital
assistant for Van Dijk Installations. How can I help?

or, warmer:

Van Dijk Installations, this is Lieke, the digital
receptionist. What can I do for you?

What to avoid is anything that hedges the machine part into invisibility. "You are speaking with Lieke from Van Dijk Installations" is not a disclosure. Neither is "this call may be handled automatically", which describes a possibility rather than stating a fact. And do not bury it after a menu, a name request, or a data- protection notice; 50(5) says at the latest at the first interaction, and a caller who has already answered two questions has interacted.

"Unless it is obvious" is not a plan

Article 50(1) exempts you where it is obvious to a reasonably well-informed, observant and circumspect person that they are dealing with an AI system. It is tempting to lean on this: surely everyone can tell? Two things make that a weak position for a phone agent specifically.

The first is that the standard is not your average caller, it is a legal construct applied after the fact, and the better your voice stack gets the harder the exemption is to argue. A native-audio model with natural turn-taking is precisely a system where it is not obvious. Improving the product erodes the defence.

The second is that the exemption is an argument you make later, whereas a first message is a change you ship once. The cost asymmetry is enormous. Four seconds of audio at the top of a call is cheap; reconstructing a year of calls to argue obviousness in front of a supervisory authority is not.

Treat the exemption as a fallback you never intend to use, and put the sentence in the greeting.

Proving it happened on every call

Here is the part that turns a copy decision into a platform question. A rule you cannot evidence is a rule you cannot demonstrate you followed. If a caller complains in October about a call in August, the useful answer is not "our greeting includes a disclosure". It is the record of that specific call showing the disclosure was delivered before the caller's first turn.

Below is the shape of record that answers that question. It is an illustration of what to aim for rather than a screenshot of any one dashboard, because the useful part is not the formatting, it is which facts survive.

call  4c1d9e77-3a2f-4b10-9c8e-11e2a6d0f5aa
──────────────────────────────────────────────────
00.00  answered            inbound +316*******8
00.00  first_message       played, verbatim
       "Goedendag, u spreekt met de digitale
        assistent van Van Dijk Installatie."
00.04  disclosure          delivered · pre-model · audio
00.05  stt                 session opened
00.09  caller speech       detected
──────────────────────────────────────────────────
evidence  disclosure delivered before first
          caller turn · retained with the call record

Three properties make that record worth having. It has to be per call rather than a configuration snapshot, because configuration changes and calls do not. It has to be ordered, so that "before the first caller turn" is a fact and not an inference. And it has to outlive the audio, because in a setup where recording is switched off for privacy reasons the log may be the only evidence that survives.

That last combination is the awkward one, and it is where owning the orchestration layer stops being an abstract advantage. Privacy pressure pushes you to retain less; transparency obligations push you to prove more. The resolution is to retain the minimum structured fact (a disclosure was delivered, at this position, on this call) rather than the maximum raw material. Whether you can do that at all depends on whether the layer that plays your first message will tell you what it did.