The EU AI Act and your Agentforce deployment

If you built a compliance plan around 2 August 2026, today is a strange day to be reading the news. That date was the cliff — the day the EU AI Act’s obligations for standalone high-risk systems were supposed to bite, the one cited in every readiness deck and, for what it’s worth, in a few of our own posts written before the ground shifted. And then, in June, the Council gave final approval to the Digital Omnibus, and the cliff moved. Standalone high-risk obligations under Annex III — the category that catches recruitment, credit scoring, insurance underwriting, and access to essential services — now apply from 2 December 2027, not today.

Here’s the trap in that reprieve: a lot of teams will read “delayed” and down tools. That’s the wrong read twice over. First, because the transparency obligations were explicitly carved out of the delay — Article 50 still applies from 2 August 2026, which means the disclosure rules governing your customer-facing agent are live as you read this. Second, because eighteen months is what a high-risk conformity programme actually takes, and the good news buried in the platform is that Salesforce already generates most of the evidence you’ll need — if you turn it on and know where it lands.

This post is the current map. What moved and what didn’t, then the obligations that matter for a Salesforce AI deployment, translated article by article into what you configure in your org, what the platform gives you, and — the part vendors gloss — what stays unavoidably your job. It is not legal advice; it’s an implementer’s guide to where the controls live.

The timeline, corrected

The Act phases in over years, and the Omnibus rewrote the middle of that schedule without touching the ends. As it stands now:

Date	What applies
2 Feb 2025	Prohibited practices (Article 5) and AI-literacy duty (Article 4) — already live
2 Aug 2025	General-purpose AI (GPAI) model obligations — already live
2 Aug 2026	Article 50 transparency obligations — disclosure that a user is interacting with AI, and marking of AI-generated content
2 Dec 2026	Article 50(2) transparency for systems already on the market before Aug 2026 (legacy carve-out)
2 Dec 2027	Standalone high-risk systems (Annex III) — the deadline moved here from 2 Aug 2026
2 Aug 2028	High-risk systems embedded in regulated products (Annex I)

Two things about this table drive everything below. The bolded rows are the ones that concern a typical Agentforce build: an agent that talks to people is squarely inside Article 50 now, and an agent that makes or materially informs a decision about hiring, lending, or essential services is a high-risk system you have until December 2027 to get right. The Omnibus takes legal effect on publication in the Official Journal, expected around the same window, but the substance isn’t in dispute across the major analyses: high-risk deferred, transparency held.

Everything else is a classification exercise, and it’s the exercise most teams skip.

Step zero: is your agent even high-risk?

Before you spend a euro on conformity, answer the only question that sets your obligations: what does the agent decide, and for whom? The Act is risk-tiered, and most Agentforce deployments are not high-risk at all.

A service agent that answers order questions, checks entitlements, and books appointments is minimal-to-limited risk. Its only AI-Act obligation is the Article 50 disclosure — tell the human they’re talking to a machine.
A recruiting agent that ranks or screens candidates is high-risk under Annex III, point 4 — the moment it evaluates rather than merely sources and schedules. We walk the exact line in AI agents for recruiting, and it’s the cleanest example of how one design choice flips the risk tier.
An HR agent that touches promotion, allocation, or termination decisions is high-risk on the same basis; the Agentforce HR service post draws the boundary between the safe employee-support use and the regulated employment-decision use.
A collections or credit agent that assesses creditworthiness is high-risk under the financial-services category — though, as we note in AI agents for contract lifecycle management, the headline categories are narrower than the panic suggests, and a private-sector tool that never makes a listed decision usually isn’t caught.

The pattern across all of them is the rule we keep returning to for enterprise agents generally: the value is in acting, but the regulatory risk is in deciding, and the two can be architected apart. An agent that sources, drafts, retrieves, and schedules all day while a human makes every listed decision often stays out of the high-risk tier entirely — and that architecture, not a compliance binder, is your cheapest path to compliance. Draw the line deliberately and you may discover you’re building a limited-risk system with one disclosure obligation, not a high-risk one with nine.

What applies today: Article 50 transparency

Since it’s the obligation that’s actually live, start here. Article 50 requires that people interacting with an AI system are told so, unless it’s obvious from context, and that AI-generated content is marked as such. For a customer-facing agent this is concrete and cheap: the agent must disclose that it’s an AI at the start of the interaction.

You don’t need a new product feature for this — you need the agent’s opening behaviour to state it, plainly, in every channel it runs. In practice that’s a standing instruction and a first-turn disclosure that survives every conversation path:

Agent opening (every channel, every session):
"Hi — you're chatting with an AI assistant from [Company]. I can help with
orders, returns, and account questions, and I'll connect you to a person
whenever you'd like. How can I help?"

Three things make that disclosure real rather than decorative. It fires on the first turn, before any substantive exchange. It’s present on every surface the agent runs — web, WhatsApp and SMS, voice — because the obligation follows the interaction, not the channel. And it’s paired with a genuine, always-available handoff to a human, because “talk to a person” is the reasonable expectation the disclosure sets. If your agent whispers the disclosure once in a pre-chat window nobody reads and then behaves like a human for the rest of the conversation, you’ve met the letter and missed the point — and regulators reading Article 50 are reading for the point.

For agents that generate content shown to the public, the marking obligation also lands here, and the platform’s provenance signals matter; for the conversational service-agent majority, the interaction disclosure is the whole of it.

What you have until December 2027 to build: the high-risk obligations

If your classification came back high-risk, the delay is breathing room, not a reprieve — the requirements are substantial and the platform only carries some of the weight. Here’s the honest division of labour, obligation by obligation, for a high-risk agent built on Salesforce.

Obligation (Article)	What it requires	Where Salesforce helps	What stays your job
Risk management (Art 9)	A continuous, documented risk process across the lifecycle	Sandboxing, testing, and adversarial evaluation tooling	Owning the risk register; deciding residual-risk acceptance
Data governance (Art 10)	Training/validation/test and grounding data that’s relevant, representative, and error-checked	Data 360 governance, tagging, and masking; identity resolution	Proving your grounding data is representative and bias-checked
Technical documentation (Art 11)	A file describing the system, its purpose, and its design	Config is metadata — exportable, source-controllable	Writing and maintaining the actual documentation
Record-keeping (Art 12)	Automatic logging of events over the system’s lifetime	Einstein Trust Layer audit trail, Shield Event Monitoring, Field Audit Trail	Enabling it, and setting retention to match the law
Transparency to deployers (Art 13)	Instructions clear enough for the deployer to use the system correctly	Product docs; the Trust Layer’s grounding-source records	Your own internal use instructions and limits
Human oversight (Art 14)	Meaningful oversight by a competent person able to intervene	Human-in-the-loop approval gates; escalation paths	Designing the gate on consequential actions; training the overseer
Accuracy & robustness (Art 15)	Appropriate accuracy, resilience, and cybersecurity	Trust Layer prompt defence; platform security; health checks	Measuring accuracy against a defined bar; monitoring drift

Two rows in that table are where the platform genuinely does the heavy lifting, and they’re worth dwelling on because most teams don’t know the evidence is already being generated.

Record-keeping (Article 12) is the one the Einstein Trust Layer all but hands you. Every prompt that passes through the Trust Layer is logged with the user, timestamp, prompt-template version, the full prompt and response text, the grounding sources it retrieved, and the masking and filter decisions it made along the way. That’s not a nice-to-have — it’s close to a purpose-built Article 12 audit log, describing exactly what the system did and on what basis. The catch is that it isn’t on by default at full fidelity: you enable the Einstein audit and feedback setup so those events flow into Data 360, and for extended retention you lean on Shield’s Event Monitoring and Field Audit Trail. The Act expects logs kept over the system’s lifetime, and deployers to retain them for at least six months; your retention configuration has to be set against that bar, not left at the platform default.

Human oversight (Article 14) is the one that has to be designed, and it’s the same discipline we argue for on every consequential agent: the approval gate built before you need it. Article 14 doesn’t want a human rubber-stamping at machine speed; it wants a competent person with real authority to override or halt the system. In Salesforce terms that’s the agent proposing the high-stakes action — the hiring rejection, the credit decline, the benefit denial — and a trained human approving it through an explicit gate, with that decision logged. “The model was confident” is not oversight, and it is not a defence.

The rows where Salesforce doesn’t save you are the ones worth staffing now. Data governance (Article 10) asks you to show your grounding and training data is representative and free of the errors that produce discriminatory outcomes — the platform enforces access and masking beautifully, but it can’t prove your data represents your applicant population; that’s your analysis to run and document. And technical documentation (Article 11) is unavoidably prose someone has to write and keep current. The delay to December 2027 exists precisely because these are not weekend tasks.

The reframe: the delay is a gift you’ll waste by treating it as one

It’s easy to read the Omnibus as the EU blinking, and to file high-risk compliance under “later.” Resist that, for a reason that has nothing to do with fear of enforcement: the work the Act asks for is the work that makes an agent good. A documented risk process, representative and access-governed grounding data, a real human-oversight gate on consequential actions, and an immutable log of what the agent did and why — strip the legal framing off that list and it’s just the definition of an agent you’d trust in production. We make the same argument, without the regulation, in governing an agent fleet before it governs you: the controls that keep you compliant are the controls that keep you correct.

So run the sequence the timeline now permits. Classify honestly — most agents aren’t high-risk, and the architecture that keeps them out (act freely, decide never) is the same one that makes them safe. Ship the Article 50 disclosure today, on every channel, because that obligation is live and it’s an afternoon’s work. Then treat the eighteen months to December 2027 as the runway it is: turn on the Trust Layer audit trail and set its retention to the law’s bar, design the human-oversight gate into your high-risk agents from the first sprint rather than bolting it on, and start the data-governance and documentation work that no vendor can do for you. The teams that do this won’t be scrambling in November 2027 — they’ll be operating agents that happened to be compliant all along, because compliant and trustworthy turned out to be the same build. That build is exactly what our Data & AI Strategy engagement is for: telling you which tier you’re actually in, and sequencing the work so the deadline is a formality, not a fire drill.

Understanding the basics

Did the EU AI Act high-risk deadline really move to 2027?

Yes. In June 2026 the Council gave final approval to the Digital Omnibus, which postpones the obligations for standalone high-risk AI systems under Annex III — including recruitment, creditworthiness, and access to essential services — from 2 August 2026 to 2 December 2027, and high-risk systems embedded in regulated products (Annex I) to 2 August 2028. The change takes legal effect on publication in the Official Journal. Crucially, the delay does not touch the Article 50 transparency obligations, the Article 5 prohibitions, the AI-literacy duty, or the GPAI rules — those remain on their existing dates.

What EU AI Act obligation applies to my Agentforce agent right now?

For most customer-facing agents, the live obligation is Article 50 transparency, which applies from 2 August 2026: you must disclose that the person is interacting with an AI system, unless it’s obvious from context, and mark AI-generated content where relevant. In practice that means a clear first-turn disclosure on every channel the agent runs, paired with an available handoff to a human. If your agent makes or materially informs a decision about employment, credit, or access to essential services, it’s likely high-risk and carries the fuller set of obligations — but you now have until 2 December 2027 to meet those.

Does the Einstein Trust Layer make Agentforce EU AI Act compliant?

No single feature makes you compliant, but the Einstein Trust Layer does most of the heavy lifting for the record-keeping obligation (Article 12): it logs each prompt with the user, timestamp, template version, full prompt and response, grounding sources, and masking and filter decisions, which is close to a purpose-built audit trail. You still have to enable the audit and feedback setup so those events are retained (with Shield for extended retention), design the Article 14 human-oversight gate yourself, prove your data governance under Article 10, and write the Article 11 technical documentation. The platform generates much of the evidence; assembling it into a conformity programme is your job.

Trying to work out which risk tier your agent actually falls into before you over- or under-build? Talk to us — classifying the use case and mapping the obligations onto your org is a very normal first engagement.