Article 50 for AI providers: the disclosure your customer can switch off
Your support assistant opens every chat with:
“You are talking to an AI assistant.”
QA signs off.
You ship.
Then a customer embeds the widget under its own brand and removes the label through a configuration setting.
You tested the default environment. Your customer’s users see something else.
This is not only a design problem. It is a question of regulatory scope, product governance and responsibility across the AI value chain.
Under Article 50 of the EU AI Act, providers and deployers have distinct transparency obligations. The fact that your default configuration is compliant does not necessarily mean that every customer-facing deployment is.
And if your product lets a customer remove a required disclosure without warning, logging or technical safeguards, you have created a compliance risk by design.
Your role depends on the system and the use
You do not have one permanent role under the AI Act. Your role depends on what you do with a particular system.
If you place an AI system on the market or put it into service under your own name or trademark, you may be the provider-even if another company developed the underlying technology.
Examples include:
An AI assistant sold under your own brand.
A customer-service agent embedded in your product.
A white-label chatbot that your company configures and supplies.
An AI system substantially modified and offered as part of your own service.
If you use an AI system in your own activities, you may instead be a deployer.
Examples include:
Using an AI assistant to communicate with your customers.
Publishing AI-generated marketing content.
Deploying an AI recruitment or sales tool internally.
Using an AI system to generate public-facing information.
The same organisation can be a provider for one system and a deployer for another. In some arrangements, several organisations may have different roles in the same value chain.
A white-label deployment therefore requires more than a provider/deployer label in a contract. You need to map:
Who developed the system.
Who places it on the market or puts it into service.
Whose name or trademark appears to users.
Who controls the configuration.
Who uses the system and for what purpose.
Who is responsible for the final publication or interaction.
If you substantially modify an AI system, or place it on the market or put it into service under your own name or trademark, provider obligations may apply to the resulting system. The precise qualification depends on the facts and on the applicable value-chain rules.
The AI Act can also apply to providers and deployers established outside the EU where the conditions in Article 2 are met, including situations in which the output of an AI system is used in the Union.
Article 50 contains separate obligations
Article 50 contains several transparency obligations. They are not interchangeable.
Broadly:
Article 50(1) concerns direct interaction between people and AI systems.
Article 50(2) concerns the marking and detectability of certain AI-generated or manipulated content.
Article 50(3) concerns the information obligations of deployers using emotion-recognition or biometric categorisation systems.
Article 50(4) concerns deepfakes and certain AI-generated or manipulated text published to inform the public.
Article 50(5) sets requirements concerning the clarity and timing of certain disclosures.
A provider’s marking of an output does not automatically discharge the customer’s deployer obligations. Equally, a customer’s public-facing label does not remove the provider’s obligation to build appropriate technical measures into the system.
One obligation never automatically discharges another.
Article 50(1): tell people they are talking to AI
Article 50(1) requires providers to design AI systems so that people are informed that they are interacting with an AI system.
The obligation applies where the system is intended to interact directly with natural persons. In practice, this may include:
Customer-support chatbots.
Voicebots and AI call agents.
AI sales assistants.
Conversational avatars.
AI companions.
Agents that communicate directly with customers, prospects, employees or candidates.
Before deciding that Article 50(1) applies, assess the feature itself:
Is it an AI system rather than a fixed rule or static message?
Is it intended to interact directly with a person?
Is there a genuine exchange rather than a one-way notification?
Could a person reasonably believe that they are interacting with a human?
Who is the foreseeable audience?
Are vulnerable people likely to use or encounter the system?
In practice, it is often useful to identify both the AI nature of the interaction and the organisation operating or sponsoring the assistant. The second point is not the same as the specific disclosure required by Article 50(1), but it may matter under consumer-protection, GDPR, contractual or sector-specific rules.
What may be outside the scope?
The obligation may not apply in the same way to:
Rule-based forms.
Fixed out-of-office messages.
Static website notices.
Machine-to-machine workflows.
Tools that draft a response while a human remains the communicator.
The last example requires care. If a human genuinely reviews and adopts the response, the user may still be interacting with the human rather than directly with the AI system. If the system communicates automatically in the background, that analysis may change.
Document the reasoning feature by feature. Do not rely on the product name or the fact that a human can intervene.
The “obvious” exception
Article 50(1) does not require a separate disclosure where it is obvious from the circumstances and the context of use that the person is interacting with AI.
This exception should be assessed carefully. A robot icon, an “AI-powered” product name or a stylised interface will not automatically make the AI nature obvious.
A human-sounding voicebot, realistic avatar or natural conversational agent is more likely to create confusion. The foreseeable audience and the context also matter.
An AI coding assistant used by professional developers may be a plausible case for the exception. A consumer-facing support assistant designed to sound human is a much weaker case.
When in doubt, an explicit disclosure is usually cheaper than a legal and reputational dispute.
How to present the disclosure
The disclosure should be clear, distinguishable and provided no later than the first interaction or exposure, taking the relevant accessibility requirements into account.
Examples include:
Web chat: a visible statement inside the chat interface.
Voice interaction: a spoken statement at the beginning, before the caller shares information.
Conversational avatar: a clear statement before or at the start of the interaction.
Embedded widget: a disclosure that remains visible under the customer’s branding.
Automated email interaction: a clear line in the message where the recipient may reasonably believe that the response came from a human.
Terms and conditions, privacy policies, help centres, footers and “AI-powered” branding can provide additional context. They should not be treated as substitutes for a clear, timely disclosure in the interaction itself.
Human escalation is good design in sensitive workflows. It is not, by itself, a substitute for the Article 50(1) disclosure.
The white-label problem
A white-label product creates a simple but easily missed question:
Can the customer remove or hide the disclosure?
If the answer is yes, ask a second question:
What happens when they do?
A provider should not validate only the default environment. It should test the actual configurations that customers can deploy.
This includes:
Customer branding.
Different languages.
Mobile layouts.
Accessibility settings.
Dark and light modes.
Voice and text channels.
Embedded widgets.
API-based implementations.
Human handover.
Custom system prompts.
Customer-controlled templates.
Export and publication workflows.
Where a disclosure is required, consider making its core elements technically mandatory. Depending on the product, this may involve:
Locking the disclosure in the user interface.
Preventing removal through ordinary configuration.
Showing a warning before a customer disables it.
Recording the configuration change.
Requiring an explicit customer acknowledgement.
Restricting the option to deployments where a documented exception may apply.
Testing the final customer-facing configuration before launch.
The exact control will depend on the system and the contractual allocation of responsibilities. But “the customer switched it off” should not be the end of the analysis.
In a white-label deployment, responsibility should be mapped across the full value chain. The model provider, application provider, integrator and client may have different roles. Responsibility should not be assigned only by reference to who owns the API key or pays the invoice.
Article 50(2): marking and detection
Article 50(2) concerns providers of AI systems that generate synthetic audio, image, video or text content.
The system must be designed so that outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, as far as technically feasible.
These are related but distinct requirements:
People need an understandable disclosure.
Machines need a signal that can be detected and interpreted.
A visible “AI-generated” label informs people. It is not necessarily machine-readable.
A provenance manifest or invisible watermark may help software detect the content. It does not, by itself, tell a viewer what they are seeing.
You therefore need two different test cases:
Can people understand the relevant disclosure?
Can appropriate technical systems detect and interpret the machine-readable signal?
The law sets a functional requirement rather than mandating one specific technology. The appropriate solution depends on:
The type of content.
The file format.
The system architecture.
The intended distribution channels.
The technical feasibility.
The cost of implementation.
The state of the art.
The likelihood of export, compression or transformation.
Test the solution across the real content journey:
Generation.
Editing.
Export.
Resize.
Compression.
Cropping.
Upload to third-party platforms.
Download.
Republishing.
Conversion between file formats.
The standard is not “the mark can never disappear”. It is whether the provider has implemented appropriate and technically feasible measures, tested their limitations and documented the results.
4 engineering questions
Ask your engineers:
Effective: Can relevant people and tools identify the content as AI-generated or manipulated?
Reliable: Does the mechanism work consistently, with acceptable false-positive and false-negative rates?
Robust: Does it survive ordinary transformations such as export, resizing, compression or social-media upload?
Interoperable: Can relevant third parties detect and interpret the signal using commonly accepted technical approaches, standards or interfaces?
Where a mark is likely to be lost during ordinary use, document the limitation and consider additional controls, such as user warnings or publication prompts.
Where C2PA fits
C2PA Content Credentials can provide signed provenance information and a tamper-evident relationship between the credentials and the file.
They do not, by themselves, prove:
That the content is true.
That the people depicted consented.
That the content has a complete history.
That the signer acted responsibly.
That the file is safe or legally usable.
A file without credentials is not proof of human origin. Trust also depends on the identity and reliability of the signer.
The AI Act does not mandate C2PA specifically. Depending on the content type and technical environment, compliance may involve provenance metadata, watermarking or other machine-readable signals.
The Code of Practice promotes a layered approach to marking and detection, adapted to the content type and technical constraints. Adhering to the Code may help demonstrate an appropriate approach, but it is not a substitute for assessing the actual system and its outputs. Nor does adherence provide conclusive evidence that every deployment complies with the Act.
Text is not a simple exemption
Article 50(2) contains an exception for certain standard assistive editing functions that do not substantially alter the input data or its semantics.
Routine spelling or grammar correction may therefore be a strong candidate for this exception.
But do not turn that principle into an automatic list of exempt categories.
Translations, summaries and rewrites require a contextual assessment. A translation can alter meaning, tone or emphasis. A summary can substantially transform the original information. A rewrite can change the message while preserving its broad subject.
A safer working rule is:
If the system substantially changes the input data or its meaning, do not assume that the assistive-editing exception applies.
Record the scope decision and the reasoning behind it.
The handover: your customer still has duties
Marking an output does not discharge your customer’s deployer obligations.
Your product may generate, mark or preserve content. The customer may then publish it, embed it in a campaign or present it to the public.
The customer needs to assess what happens at that stage.
Deepfakes
For AI-generated or manipulated image, audio or video content that constitutes a deepfake, the deployer must disclose that the content has been artificially generated or manipulated.
The disclosure should be accessible to the people exposed to the content. Machine-readable provenance alone should not be treated as a substitute for the public-facing disclosure required for a deepfake.
Practical safeguards may include:
Visible labels on images and videos.
Spoken or clearly audible disclosures for audio.
Persistent labels where content is likely to be reposted.
Publication prompts in the content-management workflow.
Warnings when provenance information is removed.
Templates that preserve the disclosure across common formats.
Text published in the public interest
Article 50(4) also covers AI-generated or manipulated text published to inform the public about matters of public interest, subject to the applicable exception.
Human review alone does not automatically remove the obligation. The exception requires genuine human review or editorial control and a natural or legal person holding editorial responsibility for the publication.
A “reviewed by a human” checkbox is therefore not enough by itself.
Your product cannot answer this question for every customer. It can, however, make the compliant path easier through:
Publication prompts.
Disclosure templates.
Export warnings.
Editorial sign-off fields.
Preserved provenance.
Records showing who reviewed the content.
Documentation stating which party is responsible for the final publication.
Timeline
Article 50 applies from 2 August 2026.
Providers and deployers should therefore treat the interaction-disclosure and deployer-labelling obligations as applicable from that date, subject to the specific exceptions in Article 50.
A transitional period until 2 December 2026 applies to the Article 50(2) marking obligation for certain generative AI systems already placed on the market or put into service before 2 August 2026.
This is not a general grace period for all Article 50 obligations or for systems introduced after 2 August 2026.
The Act does not create a general obligation to retroactively label all content generated before the relevant obligation applied. Retention, provenance and sector-specific requirements may nevertheless create separate issues.
What good looks like
A practical Article 50 readiness review should produce more than a general policy statement.
It should include:
A feature inventory with written reasoning for each scope decision.
A clear mapping of provider, deployer and other value-chain roles.
Mandatory disclosure elements protected against ordinary configuration changes.
Tests in the real customer-facing configurations.
Tests across languages, devices and channels.
A marking and detection architecture tested across the real export journey.
Documentation of technical limitations and known failure points.
A process for deepfake and public-interest text disclosures.
Contractual language allocating operational responsibilities.
Records showing who approved the final configuration.
A change-management process for new models, prompts and features.
Customer documentation explaining what they may and may not disable.
A useful test is simple:
If your customer changes the brand, channel, language or configuration, does the required transparency survive?
If not, the system is not ready for every deployment your product permits.
Conclusion
Article 50 compliance is not only a question of adding “AI assistant” to a product page.
It is a product-design, configuration-management and value-chain responsibility issue.
If you provide AI-driven services, test the experience that people will actually see-not only the environment that your QA team approved.
If you use white-label deployments, define which disclosures are mandatory, prevent accidental removal where appropriate, and document what remains the customer’s responsibility.
A readiness review can help identify the boundary between provider and deployer duties, test disclosure and marking controls, and reduce avoidable exposure before launch.
It does not certify compliance or replace legal advice. It gives your team a documented, practical basis for making better decisions.
