Article 50 Transparency Goes Live: Building Chatbot and AI-Interaction Disclosure That Holds Up

From 2 August 2026 the AI Act requires that people be told when they are dealing with a machine. The duty is small; the ways to implement it badly are many.

Article 50 is the part of the AI Act that most firms underestimated, because it sounds trivial. Put a line of text in front of the user saying they are talking to an AI. How hard can that be. Hard enough that the ones treating it as a copy change, rather than a control, will end up with disclosure that appears on some surfaces and not others, cannot be evidenced after the fact, and quietly disappears the moment the front end is redesigned. This is a reading for the technology function that has to make the disclosure real, consistent and provable across every AI touchpoint the organisation runs.

What actually comes due on 2 August 2026

The AI Act entered into force on 1 August 2024, and its transparency obligations under Article 50 apply from 2 August 2026. That date matters more than it looks, because the Digital Omnibus that pushed the hardest high-risk deadlines out to 2027 and 2028 deliberately left Article 50 alone. Transparency is not a high-risk obligation sitting inside the risk pyramid; it is a separate layer that applies regardless of how a system is classified. So the delay everyone read about does not touch this one. If you were counting on slippage, there is none to count on.

Article 50 is not a single rule but four, and they do not fall on the same party. Article 50(1) puts the design duty on the provider of an AI system intended to interact directly with people: the system must be built so that the person is informed they are interacting with an AI, in a clear and distinguishable manner, at the latest at the time of the first interaction. Article 50(2) requires providers of generative systems to mark synthetic output in a machine-readable format. Article 50(3) and 50(4) shift to the deployer: those running emotion-recognition or biometric-categorisation systems must inform the people exposed to them, and those deploying systems that produce deepfakes must disclose that the content is artificially generated or manipulated. The Commission has since published Article 50 guidelines that sharpen how these apply in practice.

The provider-or-deployer trap

The first mistake is assuming the chatbot disclosure is somebody else’s problem because you bought the model rather than built it. Article 50(1) names the provider, and a firm that takes a foundation model, wraps it, gives it a persona and puts it on its own website has in most readings become a provider of that assistant. Even where it has not, the deployer is the one whose customers meet the system, and the one a supervisor will approach first. The honest position is that the practical duty to make the disclosure appear lands on whoever controls the interaction surface, and that is almost always you.

There is an exemption, and it is narrower than people want it to be. Disclosure is not required where it is obvious, from the perspective of a natural person who is reasonably well-informed, observant and circumspect, that they are dealing with an AI. A chatbot in a widget branded as a virtual assistant may feel obvious to the team that built it. To a customer who has just been transferred from a human agent, it is not. The guidelines warn against leaning on this exemption, and the safe engineering assumption is that you disclose unless you have a documented reason not to.

Build it at the interaction layer, not as a banner

The tempting implementation is a banner or an opening message hard-coded into each front end. It fails for the same reason UX copy always drifts: there is more than one surface. A live-chat widget, a WhatsApp number, an in-app assistant, a voice line and an email autoresponder are five code paths, five teams and five chances for the disclosure to be present in four of them. Bolt the notice onto each and you are maintaining the same control in five places, which means you are maintaining it in none.

The durable approach is to treat disclosure as a reusable control that every conversational entry point calls, the same way you would treat authentication or consent. One module owns the disclosure text, decides whether it has already been shown this session, emits it before the first model turn, and records that it did. This is the same principle as putting human oversight in the interface rather than the policy: a duty that lives in a control the system enforces survives redesigns and staff turnover in a way that a duty living in a style guide does not.

Voice agents are the case that breaks naive implementations. There is no screen to put a banner on, the first interaction is auditory, and the disclosure has to be spoken before the caller starts talking to the system in earnest. That means the disclosure belongs in the call-flow orchestration, played as the opening turn, not buried in a terms-of-service line nobody hears. The interaction-layer design handles voice and text with one control precisely because it is anchored to the session, not the screen.

Logging that the disclosure happened

Meeting the duty is half the work. Being able to show you met it is the other half, and it is the half firms forget until a complaint arrives. If a customer alleges they were never told they were speaking to a machine, “our system always shows it” is an assertion. A per-session record that the disclosure was surfaced, on which surface and when, is evidence. This is the same discipline as automatic logging under Article 12 and the same reflex behind building the disclosure muscle before the regulation demands it: the control and its audit trail are one design, not two.

A minimal middleware makes the point. It surfaces the notice once per session, tags it with the surface it appeared on, and appends a hash-chained record so that a deleted or altered entry is detectable later.

// ai-disclosure.middleware.ts
// Express middleware: surfaces the Article 50(1) notice once per
// session and writes a tamper-evident record that it happened.
import type { Request, Response, NextFunction } from 'express';
import { createHash } from 'node:crypto';
import { appendFile } from 'node:fs/promises';

const DISCLOSURE =
  'You are chatting with an automated assistant, not a person.';

// Append-only log. Each line is chained to the previous hash, so a
// removed or edited record can be detected after the fact.
let previousHash = 'genesis';

async function recordDisclosure(sessionId: string, surface: string) {
  const entry = {
    ts: new Date().toISOString(),
    session: sessionId,
    surface,                 // e.g. 'web-chat', 'voice-ivr', 'whatsapp'
    control: 'ai-act-art-50-1',
    text: DISCLOSURE,
    prev: previousHash,
  };
  const line = JSON.stringify(entry);
  const hash = createHash('sha256')
    .update(previousHash + line)
    .digest('hex');
  previousHash = hash;
  await appendFile('disclosure-audit.log', line + '\t' + hash + '\n');
}

export async function aiDisclosure(
  req: Request,
  res: Response,
  next: NextFunction,
) {
  const session = req.session as { disclosed?: boolean; id: string };
  if (!session.disclosed) {
    // Emit before the first model turn, never after it.
    res.locals.systemNotice = DISCLOSURE;
    await recordDisclosure(session.id, req.header('x-surface') ?? 'web-chat');
    session.disclosed = true;
  }
  next();
}

It is deliberately small. The value is not the code; it is that disclosure and its proof are produced by one control that every surface routes through, rather than reconstructed from front-end screenshots after someone complains.

Do not confuse this with the synthetic-content duty

Article 50(1) is about telling a person they are talking to an AI. Article 50(2) and 50(4) are about marking and disclosing the output of generative systems, which is a different control on a different timetable and needs different plumbing. If your assistant also generates images, audio or synthetic media, the machine-readable marking obligation applies on top, and that is closer to the watermarking problem than to the interaction notice. Solving one does not solve the other, and a project that ships a chatbot banner while leaving generated content unmarked has met one duty and missed a second.

Map every AI touchpoint you run, decide for each whether it interacts with people, generates synthetic content, or does both, and route each through a control that discloses and logs. Do that once, centrally, and Article 50 becomes a property of the platform. Leave it to each team to remember, and you will find out which one forgot the day a regulator or a complainant asks you to prove otherwise.