If you have been told the EU AI Act was delayed, you were told something true about a different part of the law.
The Digital Omnibus on AI was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It moved the compliance deadline for stand-alone high-risk systems under Annex III from 2 August 2026 to 2 December 2027, and for AI embedded in regulated products under Annex I from 2 August 2027 to 2 August 2028. Those are real deferrals with fixed dates, and the coverage they generated has been enormous.
Article 50 was not in that package. The transparency obligations took effect on 2 August 2026, exactly as originally scheduled. They are in force now. Breaching them sits in the AI Act's middle penalty tier under Article 99: up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher.
For a Salesforce estate, that is not an abstract exposure. Article 50 governs what your customers are told when an agent answers them. If you have deployed Agentforce against any audience that includes EU residents, the obligation attached on 2 August, and it is almost certainly not satisfied by anything you configured by default.
Did the Omnibus delay Article 50?
No. Three sets of obligations were left untouched by the Digital Omnibus, and it is worth being precise about which, because the "AI Act is delayed" summary has obscured all three.
- Prohibited practices under Article 5 have applied since 2 February 2025. The Omnibus added a new prohibition covering non-consensual intimate imagery and CSAM, with a transitional period to 2 December 2026.
- General-purpose AI model obligations under Articles 51 to 56 have applied since 2 August 2025.
- Article 50 transparency applied from 2 August 2026, unchanged.
The only Article 50 concession is narrow: systems already placed on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2). That is a grace period on one paragraph, not on the article.
The practical consequence is that a governance programme built around "we have until December 2027" has a live gap in it right now. If you built your roadmap from our AI governance programme guide, this is the piece that moved to the front of the queue.
Which Salesforce surfaces are in scope?
Article 50(1) covers AI systems "intended to interact directly with natural persons." Article 50(2) covers systems generating synthetic audio, image, video or text. Article 50(4) covers deployers publishing AI-generated text to inform the public on matters of public interest, and deepfake content.
Mapped onto a typical enterprise Salesforce estate, that reaches further than most teams assume:
- Agentforce Service Agents on any customer-facing channel — web chat, in-app messaging, WhatsApp, SMS, voice.
- Agentforce Sales agents and SDR-style agents that engage prospects directly, including outbound sequences where a human never touches the message.
- Experience Cloud portals with an embedded agent serving partners, patients, members or customers.
- AI-drafted content published under your brand on matters of public interest, which can pull certain marketing and communications output into Article 50(4).
- Voice deployments, where disclosure has to be audible and cannot be delegated to a screen element.
Internal-only copilots that assist employees are a different question. Article 50(1) has a carve-out where the AI nature is "obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect." An employee using a clearly labelled assistant inside a console usually meets that bar. A customer arriving at a chat window branded with a human-sounding name usually does not.
The carve-out is narrower than it sounds. It turns on what a reasonable person would infer, not on what your internal documentation says. Naming an agent something person-like and giving it a human avatar cuts directly against it.
Why the Einstein Trust Layer does not cover you
This is where most Salesforce teams have a false sense of coverage, and it is the single most important point in this article.
The Einstein Trust Layer is a genuinely strong control set. It handles dynamic grounding, PII masking, zero data retention with the model provider, toxicity detection, and audit trail capture. If your concern is what happens to customer data on its way to and from the model, the Trust Layer is doing serious work on your behalf.
Article 50 is not about what happens to the data. It is about what the human on the other end is told.
The Trust Layer governs the pipeline. Article 50 governs the greeting. No amount of masking, grounding or audit logging causes a disclosure to appear in front of a customer. That disclosure is a deliberate conversation-design decision that someone has to make and configure, and nothing in the platform makes it for you.
The same confusion appears with Agentforce's EU Cloud Code of Conduct adherence and its GDPR posture. Both are real, both are useful in a procurement conversation, and neither discharges an Article 50 obligation. They answer questions about data processing. Article 50 asks a question about user notification.
If your compliance evidence for Article 50 currently consists of a Trust Layer architecture diagram, you do not have evidence for Article 50.
Are you the provider or the deployer?
Article 50 splits its duties. Paragraphs 1 and 2 bind providers. Paragraphs 3 and 4 bind deployers. Most Salesforce customers assume they are deployers of Salesforce's system and that the design obligation therefore sits upstream.
That assumption is worth testing, for two reasons.
First, Article 50(5) applies the timing and clarity requirements to the information referred to in paragraphs 1 through 4 collectively: whoever is responsible, the disclosure has to reach the person "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure." A provider-side design capability that you leave switched off does not produce a compliant outcome.
Second, the provider and deployer line can move. Under Article 25, a deployer who puts an AI system on the market under its own name or trademark, or who substantially modifies it, can take on provider obligations. An enterprise that builds a custom-branded agent on the platform, gives it its own persona, and puts it in front of its own customers should not assume it has stayed on the deployer side of that line.
This is a question for your counsel, not for a configuration guide. But it should be an explicit, documented determination rather than an assumption, and the answer changes who owns the design obligation in paragraph 1.
What a compliant disclosure actually looks like
The Commission's transparency guidance and the text of Article 50(5) converge on four properties. A disclosure has to be:
- Timely. Present at or before the first interaction. A notice that appears after the customer has already asked a question is late.
- Clear and distinguishable. Legible as its own statement, not folded into a marketing greeting.
- Perceivable without special tools. Visible or audible in the interaction itself. Not in a terms-of-service link, not in a privacy policy, not implied by a small robot icon.
- Accessible. Subject to applicable accessibility requirements, which means screen-reader exposure and adequate contrast, and an audible equivalent on voice channels.
Two failure modes are common enough to name. Branding is not disclosure: an agent called "Ava" with a friendly avatar communicates the opposite of what the article requires. And a link is not disclosure: burying it one click away fails the standard that information be perceivable without any specific technical tools.
The wording itself can be short. Something on the order of "You're chatting with an AI assistant. You can ask for a human at any time." satisfies the substance in one line. The engineering problem is not the sentence. It is making sure the sentence is present on every channel, in every language, on every agent, including the ones nobody remembers deploying.
What to configure
The work divides into five tasks. None is individually difficult; the difficulty is coverage.
Inventory every customer-facing agent. Include pilots, agents on Experience Cloud sites, agents attached to inactive-but-published messaging channels, and anything a partner deployed in a sandbox that got promoted. The compliance question is per touchpoint, not per project.
Set the disclosure in the opening turn of each agent. In Agentforce this belongs in the agent's welcome or greeting configuration and, for messaging channels, in the channel's opening message, so that it renders before the customer's first input rather than as a response to it. Configure it as a static element of the conversation opening, not as an instruction in the agent's topic or system prompt. A generative instruction is probabilistic, and a legal disclosure requirement is not.
Localise it. The disclosure must be understandable to the person receiving it. If you serve EU customers, that means every language your channels support, not just English.
Preserve it across handoff. When an agent escalates to a human, the customer should be able to tell that the counterpart changed. The inverse case matters more: if a conversation starts with a human and an agent takes over, disclosure attaches at that transition.
Handle voice separately. A visual disclosure does not exist on a voice channel. The statement has to be spoken in the opening, and it has to survive call transfers.
Because the disclosure is a fixed string rather than model output, it is straightforward to verify. Treat it as a release gate: any new agent or channel ships with the disclosure configured, and the check belongs in the same deployment checklist that already governs your other org changes.
Article 50(2) and the December deadline
Article 50(2) requires providers of systems generating synthetic audio, image, video or text to mark outputs in a machine-readable format, detectable as artificially generated. This is a different obligation from the conversational disclosure, aimed at downstream detectability rather than the person in the conversation.
Systems placed on the market before 2 August 2026 have until 2 December 2026 to comply. That is your remaining runway, and it is short.
For most Salesforce estates the marking capability is a provider-side question that belongs in your vendor conversations. The deployer-side work is knowing where AI-generated content leaves your org and enters public circulation — AI-drafted knowledge articles, generated marketing assets, synthetic imagery in campaigns — and being able to say which of those are marked. If you are also generating content through the platform under your own brand, revisit the provider question above, because paragraph 2 binds providers.
How to evidence this
Article 50 compliance is demonstrable in a way that a lot of AI governance is not. The disclosure is either present at first interaction or it is not.
Build the evidence package now, while the configuration is fresh:
- A register of every customer-facing agent and channel, with its disclosure text and the languages it renders in.
- Screenshots or transcript samples showing the disclosure at first interaction on each channel type, including voice recordings.
- The documented provider-versus-deployer determination, with the reasoning and the date it was made.
- The release-checklist entry that prevents the next agent from shipping without one.
- For Article 50(2), an inventory of AI-generated content published externally and its marking status, with the December 2026 date tracked.
This register is also reusable. It is close to what you need for the Annex III readiness work that now lands in December 2027, and it overlaps with the data-subject-request tooling covered in automating DSAR and right-to-erasure across Salesforce.
The wider pattern
The Omnibus deferral was reported as a reprieve, and for high-risk classification work it genuinely is. But the parts of the AI Act that touch the largest number of ordinary deployments — prohibited practices, GPAI obligations, and transparency — were all already in force before the deferral was agreed, and none of them moved.
The teams exposed here are not the ones running biometric identification or credit scoring. They are the ones who deployed a customer service agent, read that the AI Act was delayed, and reasonably concluded that nothing was due. The obligation that applies to them is the one nobody wrote a countdown article about, and it is satisfied by a configuration change that takes an afternoon.
If you do one thing this week, inventory your customer-facing agents and check what the first message says. For a broader view of the control set around those agents, see our guide to securing AI in Salesforce, and the practitioner session on privacy, ethics and AI with Punit Bhatia and Tom Kemp.
*This article is editorial analysis, not legal advice. Provider and deployer determinations under the AI Act are fact-specific and should be made with qualified counsel.*
