Article 50 EU AI Act: An Operational Check for In-House Legal

Article 50 of the EU AI Act (Regulation (EU) 2024/1689) has applied across all EU member states since 2 August 2026. It requires organisations that build or use AI systems interacting with people, or generating content, to say so — and to mark certain outputs as artificially generated. In Germany, the national enforcement architecture followed shortly before: the KI-MIG (BGBl. 2026 I Nr. 223) entered into force on 29 July 2026, making the Bundesnetzagentur the central market surveillance authority as well as the contact and complaints point for the Regulation. BaFin and the Federal Ministry for Digital Affairs and State Modernisation (BMDS) both named the 2 August date explicitly in press releases dated 29 July 2026.

If you sit in an in-house legal function anywhere with an EU footprint, the legal analysis here is not the hard part. Article 50 is short, and its logic is transparency rather than prohibition. The hard part is inventory: knowing which AI systems are already running in your organisation, who owns each of them, and who answers when somebody asks. This article sets out what Article 50 requires, how provider and deployer duties diverge, and a six-step check that a small team can complete in a few weeks.

What is Article 50 of the EU AI Act?

Article 50 of Regulation (EU) 2024/1689 sets the AI labelling obligations at the centre of the EU AI Act’s transparency regime. It requires that people be told when they are interacting with an AI system, and that certain AI-generated content is marked as such, without banning or classifying anything as high risk. It has applied since 2 August 2026.

What Article 50 actually requires

Article 50 governs disclosure, not permissibility. It does not ban anything and it does not classify anything as high risk. It requires that people be able to tell what they are dealing with. Four situations matter in practice.

First, interaction. Providers of AI systems intended to interact directly with natural persons must ensure those persons are informed that they are interacting with an AI system — unless this is obvious to a reasonably well-informed and observant person in the circumstances. In practice this covers the dialogue assistant on your website, the automated first response in a service inbox, and anything that feels to the other side like a conversation.

Second, machine-readable marking of generated content. Providers of AI systems that generate synthetic audio, image, video or text content must mark the outputs in a machine-readable format so they are detectable as artificially generated or manipulated. This sits with the provider and is a technical duty, solved in the system rather than in the copy.

Third, disclosure for deep fakes and for published text. Deployers who use an AI system to generate or manipulate image, audio or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated. A comparable duty applies to AI-generated or AI-manipulated text published to inform the public on matters of public interest — unless the content has undergone human review and a natural or legal person holds editorial responsibility for it.

Fourth, emotion recognition and biometric categorisation. Deployers of these systems must inform the people exposed to them.

Two points carry more operational weight than they first appear to. The information must be given at the latest at the time of the first interaction or exposure, and it must be clear and distinguishable — a line that surfaces only in the fourth paragraph of a privacy notice does not meet that standard. And the Regulation contains exceptions, including for assistive functions that do not substantially alter the input data, for legally authorised law-enforcement purposes, and for artistic or satirical works. Whether an exception applies is a question of fact, and it is worth recording the answer rather than assuming it quietly.

Provider or deployer: what your duty depends on

The most common early misreading of Article 50 is that it concerns software vendors. The Regulation distinguishes between providers and deployers, and both roles routinely occur in the same organisation, sometimes on the same day.

A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its own authority. An organisation using a bought-in system is, to begin with, a deployer — but it can move into the provider role, for instance by offering the system under its own name or by substantially modifying it.

That allocation determines the kind of duty you carry. Machine-readable marking of generated content sits on the provider side. Disclosure to the specific affected individual typically sits on the deployer side, which is to say with you. From this follows a very concrete task for in-house legal: check what your vendors actually commit to. If a vendor does not mark outputs, you generally cannot retrofit that — your only real decision is whether to keep using the system for that purpose. The commitment therefore belongs in the contract and its service schedules, not in an audit note written a year later.

The operational check

The practical work does not start with a policy. It starts with a list, and in most organisations that list does not yet exist — not through negligence, but because the systems in question were rarely introduced as AI projects. They arrived as a new feature in software already in use, as a trial in marketing, as a small improvement in recruitment. Those legacy systems are the substance of the problem.

A sequence that works has six steps.

1. Take inventory. Ask function by function where an AI system today reaches a person outside the legal department: website, customer service, marketing, recruitment, sales, internal portals. Do not ask about “AI” — ask about behaviours: automated replies, suggested text, summaries, image or video editing, synthetic speech, scoring of free-text answers. Asking about “AI” reliably produces false negatives from colleagues who do not think of their tool that way.

2. Assign the role. For each system, record whether you are provider or deployer and why, together with the vendor, the contractual basis and the person who owns the use case in the business.

3. Test the trigger. For each system, establish which of the four situations applies: direct interaction, generation of synthetic content, deep fake or published text, emotion recognition or biometric categorisation. Frequently none applies — and that conclusion is worth recording too.

4. Draft and place the notice. Where a duty exists, decide on wording, timing and position. The notice must be visible before or at the first interaction, in the language of the service, and it must not disappear into general terms. A short, comprehensible sentence beats a legally exhaustive passage that nobody reads.

5. Preserve the evidence. Record who made which assessment, when, and on what basis. Article 50 does not impose the formal documentation regime that applies to high-risk systems. But in an exchange with a supervisory authority, a competitor or a claimant, the difference between “we looked at that” and a dated note with a name on it is considerable. ASD.Digital Solutions went through a comparable shift: turning legal assessments that varied by whoever handled them into structured, documented decision logic.

6. Set the review point. Decide who maintains the list and when it is revisited — at minimum on every new application, every change of vendor, and every substantial change of function in an existing system.

Step six is where this kind of work usually fails, not step one. An inventory taken once is out of date within two quarters if maintaining it depends on one person’s calendar. Where disclosure and its documentation sit as a fixed step inside the process that runs anyway (a node that has to be completed before anything moves on), the practice survives a change of staff. With e!, that kind of process, including the recurring check itself run on a schedule, can be built and amended by the legal experts themselves, without writing code.

Who supervises this, and what non-compliance costs

In Germany, the contact point is the Bundesnetzagentur. Under the KI-MIG, in force since 29 July 2026, it acts as the market surveillance authority for the AI Act and as the central contact and complaints point. Sectoral supervision sits alongside it: BaFin oversees AI systems directly connected to regulated financial activity. AI in personnel management stays expressly with the Bundesnetzagentur — an allocation that matters immediately to any legal function with a recruitment system in scope.

The Regulation’s own penalty framework is in Article 99. Breaches of the transparency obligations in Article 50 carry administrative fines of up to EUR 15 million or up to 3 % of total worldwide annual turnover for the preceding financial year, whichever is higher; for SMEs, whichever is lower applies. How German supervisory practice will develop is still open in autumn 2026, and the oversight regime is only weeks old.

Realistically, the fine is not the first risk most organisations face. It is more likely that the question arrives from outside: from a customer, a rejected applicant, a competitor, or a consumer body. An organisation that can say within a day which systems are running, who owns them, and why a notice was or was not given keeps the matter under control. One that starts its inventory at that point is already negotiating under pressure.

Frequently Asked Questions

Since when has Article 50 applied?

The transparency obligations in Article 50 of Regulation (EU) 2024/1689 have applied since 2 August 2026, under the Act’s staged application timetable. Both BaFin and the BMDS named that date explicitly in press releases of 29 July 2026. The Regulation itself entered into force in 2024, but its obligations bite in stages. For in-house legal the practical consequence is that systems introduced before 2 August 2026 are not grandfathered: legacy systems fall within the transparency duties as soon as they meet one of the situations the Article describes.

Do we have to label every piece of AI-generated text?

No. Article 50 does not require blanket labelling of every text produced with AI assistance. Internal drafts, file notes, research summaries and litigation preparation are not caught by the disclosure duty for published text. The duty attaches to publication intended to inform the public on matters of public interest, and it falls away even there where the content has undergone human review and an identifiable person or organisation holds editorial responsibility. For a typical in-house legal function, the more relevant trigger is therefore not your own writing but the customer dialogue and the recruitment journey.

What is the difference between marking and disclosure?

Marking under Article 50 is a technical duty on the provider side: generated outputs must be detectable as artificially generated or manipulated in a machine-readable format, for instance through embedded identifiers or watermarks. Disclosure is a communicative duty that typically falls on the deployer: the affected human being has to understand that they are speaking to an AI system or looking at artificially generated content. The two can concern the same facts and must still be assessed separately. A system may mark its outputs correctly while the notice to the user is missing, and the reverse happens just as often.

Who handles a complaint in Germany?

The Bundesnetzagentur is the central contact and complaints point. Under the KI-MIG, in force since 29 July 2026, it is the market surveillance authority for the AI Act in Germany. BaFin supervises AI systems directly connected to regulated financial activity. AI in personnel management remains with the Bundesnetzagentur. In practice it is worth settling internally, in advance, who receives correspondence from a supervisory authority, who answers on the substance, and who knows the system inventory, since in many organisations those are three different roles.

Is a line in the privacy notice enough?

As a rule, no. The Regulation requires the information to be given at the latest at the first interaction or exposure, clearly and distinguishably. A sentence that appears only in a linked document the person does not open before the conversation begins does not meet that requirement. The notice belongs where the interaction starts, in the language of the service, and in wording that works without legal training. The privacy notice remains relevant alongside it, but it does not substitute for the notice.

We only use AI internally. Does Article 50 concern us at all?

Possibly not, but the assessment is still worth doing, for two reasons. First, the boundary between internal and external use is blurrier in practice than in planning: an internal system whose outputs flow into customer correspondence, job adverts or formal decisions reaches outwards. Second, the inventory Article 50 forces is the foundation for the Regulation’s later stages, particularly for classifying high-risk systems. Building the list now is not work spent on Article 50 alone.

Sources

• Regulation (EU) 2024/1689 (EU AI Act), Articles 50 and 99; transparency obligations applicable from 2 August 2026
• BaFin, press release of 29 July 2026 on the AI Regulation (staged timetable): https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Pressemitteilung/2026/pm_2026_07_29_ki_verordnung.html
• BMDS, press release 47/2026 of 29 July 2026, “Neues KI-Gesetz tritt in Kraft”: https://bmds.bund.de/aktuelles/pressemitteilungen/detail/neues-ki-gesetz-tritt-in-kraft
• Bundesnetzagentur, press release of 29 July 2026: https://www.bundesnetzagentur.de/1112336
• KI-Marktüberwachungs- und Innovationsförderungsgesetz (KI-MIG) of 22 July 2026, BGBl. 2026 I Nr. 223, in force since 29 July 2026: https://www.gesetze-im-internet.de/ki-mig/BJNR0DF0B0026.html

This article gives a general overview as at 10 September 2026 and does not replace advice on an individual case.