Data residency is not compliance
Hosting your org in an EU region through Hyperforce is a sensible step, and it does simplify some cross-border transfer questions. It does not, on its own, make Agentforce GDPR-compliant. Residency governs where data sits at rest. It says nothing about your lawful basis for processing, the rights of the people in your records, how long you keep the data, or where an integration, a sandbox refresh, or a third-party tool quietly sends a copy of it.
Start with lawful basis and data-subject rights
Before an agent touches personal data, you need a lawful basis for what it does with that data, and a way to honour data-subject rights when they are exercised. If a customer asks for their data to be deleted or exported, an agent that has summarised, cached, or learned from that data has to be part of that answer. Design the deletion and access paths before go-live, not after the first request lands.
Every AI feature needs its own assessment
GDPR treats automated decision-making and profiling as higher-risk, so each Agentforce or Einstein capability you switch on deserves its own review rather than one account-level sign-off. For each feature, be explicit about what data enters the prompt, whether it is used for training, what the agent decides versus merely recommends, and whether a human stays in the loop. A data protection impact assessment is the right home for those answers.
The EU AI Act adds obligations on top
GDPR is not the only regime in play. The EU AI Act layers on transparency, human-oversight, and documentation duties that scale with how the agent is used. An agent that makes or heavily influences decisions about people carries more obligation than one that drafts a summary for an employee to review and send. Knowing which category each use falls into is part of the design, not a box ticked at the end.
Follow where the data actually goes
Most compliance gaps are not in Salesforce itself; they are at the edges. A sandbox refresh copies production personal data into a less-controlled environment. An integration ships records to a system in another region. Debug logs and a third-party tool each keep their own copy. Before go-live we map every one of those flows, because as with a cross-region migration, the data movement you do not track is the one that bites.
The pre-go-live checklist
Before an EMEA Agentforce agent goes live, we clear a short, concrete list: a signed data processing agreement and a documented lawful basis; EU data residency configured; a per-feature data-protection assessment; a human in the loop wherever a decision affects a person; retention and deletion honoured across caches and summaries; and every integration and sandbox flow accounted for. The agent should also only ever see the data it needs, and its outputs should be reviewed, which is what our AI Enablement and AI-native delivery approach is built around.
Governance is the enabler, not the brake
It is tempting to treat all of this as friction that slows the AI project down. In the EU it is the opposite: governance is what makes the agent usable at all. Clean data, per-feature assessments, human oversight, and a reviewed output are what let you deploy with confidence instead of hoping nobody asks. The teams that get Agentforce into production in Europe are the ones that treated compliance as part of the build, alongside validating the agent before go-live.
A note on legal advice
This is practical guidance for scoping and building compliant Agentforce projects, not legal advice. Your obligations depend on your data, your jurisdiction, and how you use the agent. Confirm the specifics with your data protection officer or legal counsel before you go live.
Key takeaways
- EU data residency helps but does not equal GDPR compliance on its own.
- Establish lawful basis and deletion or access paths, and assess each AI feature individually.
- The EU AI Act adds transparency and oversight duties on top of GDPR.
- Map every integration, sandbox, and backup flow, and keep a human in the loop where decisions affect people.