Keeping Salesforce AI Compliant: The Privacy Gaps the Einstein Trust Layer Leaves Open

TL;DR: AI in Salesforce (Agentforce, Einstein, and third-party AI apps) creates privacy exposure that your existing masking and DSAR processes were not built for: real customer PII flowing into prompts and model calls, AI-generated records that regulators can demand you erase, and cross-border inference you may not be logging. The Einstein Trust Layer handles part of this, but not the whole surface. Closing the gap means controlling what data reaches a model, proving consent and retention on AI outputs, and putting AI-generated records inside the same masking, retention, and privacy-rights workflows you already run on the rest of your org.

Cloud Compliance builds native Salesforce controls for masking, consent, retention, and privacy-rights automation that extend past the Trust Layer to the AI-generated records and third-party AI apps it does not reach. This guide maps the new risks and where those controls apply.

What actually changes about privacy when you turn on AI in Salesforce?

Before AI, a Contact record sat in your org and moved through predictable paths: reports, integrations, backups. You knew where personal data lived and who touched it.

AI adds three new behaviors that break that model:

1. Data leaves for inference. A prompt built from a Case, an Opportunity, and a Contact gets assembled and sent to a model for a response. Even when the model provider retains nothing, that assembly is a new processing activity involving personal data.
2. AI writes new personal data back. A summarized case, a drafted email, a predicted churn score, a next-best-action note. These are new records containing (or derived from) personal data, and they are subject to the same erasure and retention rules as the source.
3. The data flow is often invisible to your existing controls. Your masking rules were written for sandboxes and integrations. Your DSAR process searches Contacts, Leads, and Cases. Neither automatically covers a prompt log or an AI-generated summary field unless you extend them.

That is the gap. Not new regulations, the same GDPR, CCPA/CPRA, and HIPAA obligations, applied to data paths that did not exist a year ago.

Does the Einstein Trust Layer make Agentforce and Einstein compliant on its own?

It covers a meaningful slice, and you should turn it on. But "Trust Layer is enabled" is not the same as "compliant."

What the Trust Layer does well:

• Data masking before the prompt leaves Salesforce. It combines pattern rules (for fixed formats like emails, phone numbers, credit cards, and SSNs) with machine-learning entity detection trained to catch unstructured entities such as names of people and companies, then replaces them with placeholders, so the external provider sees a tokenized prompt. (Salesforce Trailhead)
• Zero data retention with model providers. Salesforce's contracts with providers like OpenAI forbid retention and training on your prompts, and data is deleted after the response returns. (Trailhead)
• An audit trail of prompts, responses, grounding sources, and filter decisions, written to the Einstein audit log in Data Cloud. (Salesforce)

Where it stops, and where you carry the risk:

• Detection is not exhaustive. Masking combines pattern rules with ML entity detection, but it can miss industry-specific identifiers (member IDs, case numbers, policy numbers) that follow no standard pattern, and PII buried deep in long free-text such as call transcripts or custom description fields. Coverage also depends on how you configure it. You have to set up field-based masking and custom patterns; the defaults do not cover those industry identifiers. (eesel AI)
• Third-party AI apps. The Trust Layer protects Salesforce's own generative features. An AppExchange AI tool or a custom integration calling an external model through Apex does not automatically inherit it.
• The output side. The Trust Layer governs the prompt going out. It does not manage the retention, consent status, or erasability of the records AI writes back into your org.

So the Trust Layer is a strong front door. It is not the whole building.

What happens to AI-generated records when someone files a DSAR or erasure request?

This is the risk most teams miss. Under GDPR Article 17, a person can require you to erase their personal data, and Article 12(3) sets the clock: you must respond without undue delay and in any event within one month of the request, extendable by two further months where the request is complex or numerous, provided you tell the person of the extension and the reasons within the first month. (GDPR Article 12, GDPR Article 17) That erasure obligation covers the personal data you hold about the person, which includes data derived from them, not just the original record.

Regulators have signalled that AI processing of personal data sits inside these rules. In its Opinion 28/2024, adopted 17 December 2024, the EDPB confirmed that developing and deploying an AI model on personal data is processing under the GDPR, and that where a model is not genuinely anonymous, data-protection obligations (including data-subject rights) continue to apply. (EDPB Opinion 28/2024) National authorities have reached the same starting point from different angles: the Italian Garante's December 2024 decision against OpenAI turned on there being no adequate legal basis and inadequate transparency for training-data processing (that fine was later annulled by the Court of Rome in March 2026 on jurisdictional grounds, not on the merits) (Garante), while the Hamburg DPA's July 2024 discussion paper argues that although an LLM's weights do not themselves "store" retrievable personal data, the deployer still has to honour information, correction, and deletion requests for the chatbot's inputs and outputs. (Hamburg DPA discussion paper (PDF)) The through-line: the inputs you send to a model and the outputs it writes back about an identifiable person are in scope for erasure. For how this plays out in a Salesforce DSAR workflow, see Enterprise Dreamin's DSAR/RTBF automation walkthrough.

In practical Salesforce terms, when a person exercises their right to erasure, you now have to find and delete:

• The source Contact, Lead, Case, and related records (the part your current process handles).
• AI-generated summaries, drafted communications, and predictive fields derived from that person.
• Prompt and response logs that contain their unmasked data.

If your DSAR workflow only sweeps standard objects, you are leaving AI-generated personal data behind, which is exactly the kind of incomplete erasure regulators cite. This is why AI makes a manual, object-by-object erasure process untenable. It needs to run natively against the whole object model, including the custom objects and fields where AI writes. That is what Privacy Rights Automation is built to do: track each request against its regulation-specific deadline, handle cascading deletion across the object graph, and produce an audit-ready completion record.

How do you keep PII out of prompts and models in the first place?

The cleanest control is to never send the sensitive data you do not need. Two layers matter:

Layer 1: mask before inference. For sandboxes and lower environments where AI features get built and tested, real PII should never be present at all. Sandbox Data Masking replaces production values with realistic but fake data before developers or AI tooling touch the environment. For production prompts, use the Trust Layer's field-based masking and extend it with custom patterns for your unstructured and industry-specific fields.

Layer 2: know where personal data lives. You cannot mask or govern fields you have not classified. Personal Data Discovery scans the org to find where personal data actually sits, including the custom and free-text fields that default masking misses. That inventory is what tells you which fields must be masked before they reach a prompt.

For teams that want to narrow where PII can escape during inference, architecture matters too. GPTfy runs inside your Salesforce org and connects to your chosen model (OpenAI, Claude, Gemini, and others) through Salesforce Named Credentials, with no Data Cloud requirement. Its security layer masks PII, PHI, and financial data before the callout, so per its documentation only PII-masked data reaches the AI provider while raw data stays in your infrastructure. (GPTfy) Keeping the orchestration native narrows the number of places PII can escape, though you still owe the same masking, consent, and retention discipline on top. See AI for Salesforce without Data Cloud for how that architecture compares.

Does the person whose data feeds the AI actually consent to that use?

Consent granularity is where AI trips CCPA and GDPR. A contact may have consented to marketing but not to having their case history summarized by a third-party model, or to cross-border processing when the model call routes outside their region.

Two practical requirements:

• Track consent at a level that maps to AI use. A single "opted in" flag is not enough when the lawful basis for an AI summary differs from the basis for an email campaign. Consent Management captures consent across channels into one auditable record per contact, which is the record you check before feeding data into a model. See the consent implementation guide for the CCPA/GDPR mechanics.
• Watch cross-border model calls. If your model provider processes in a different region than your data subject, that is an international transfer with its own basis and disclosure requirements. Log which model handled which prompt so you can answer "where did this data go" during an audit.

How does the EU AI Act change the stakes?

The AI Act adds a compliance regime on top of GDPR, with its own penalties, and enforcement is live now.

• Prohibited AI practices have been enforceable since 2 February 2025, and general-purpose AI model rules since 2 August 2025. (artificialintelligenceact.eu)
• Penalties for prohibited practices reach up to €35 million or 7% of global annual turnover, whichever is higher. High-risk system breaches can hit €15 million or 3%. (artificialintelligenceact.eu)
• One important nuance: under the Digital Omnibus package signed on 8 July 2026, the deadline for high-risk Annex III systems is deferred from 2 August 2026 to 2 December 2027, and AI embedded in regulated products under Annex I moves to 2 August 2028. (Council of the EU) So the high-risk clock has more runway than early guidance suggested, but the prohibited-practice and transparency obligations are already in force.

The takeaway for a Salesforce AI deployment: you need to document what your AI does, what data it uses, and what controls sit under it. That documentation is far easier to produce when masking, consent, and audit are systematized rather than reconstructed after the fact. Cloud Compliance covers the EU AI Act alongside GDPR, CCPA/CPRA, HIPAA, and others.

Checklist: the AI compliance controls that Trust Layer does not cover

The short version

Turn on the Einstein Trust Layer, then extend past it. The Trust Layer protects Salesforce's own generative calls at the prompt boundary, but its detection is not exhaustive across free text and industry identifiers, it does not cover third-party AI apps, and it does not manage the retention, consent, or erasability of the records AI writes back. Those are the controls that keep you compliant when a regulator asks where a person's data went and whether you deleted all of it.

For the broader architecture and threat model, see Securing AI in Salesforce (2026) and the field-level governance gap. To put native masking, consent, retention, and privacy-rights controls under your AI, start with Cloud Compliance.

FAQ

Does the Einstein Trust Layer mask all PII automatically?

No. It combines pattern rules with machine-learning entity detection to mask standard PII (names, emails, phone numbers, SSNs, credit cards, addresses) before the prompt leaves Salesforce, but industry-specific identifiers and PII buried in long free-text can still be missed, and coverage depends on how you configure field-based masking and custom patterns. (eesel AI)

Do I have to delete AI-generated records when someone files a right-to-erasure request?

Generally yes. The EDPB's Opinion 28/2024 (17 December 2024) confirms that processing personal data to develop and deploy AI models falls under the GDPR, and that a model which is not genuinely anonymous stays subject to data-subject rights. (EDPB Opinion 28/2024) National authorities agree that a deployer must honour deletion requests for a chatbot's inputs and outputs about an identifiable person (Hamburg DPA discussion paper (PDF)), so summaries, drafts, predictive fields, and prompt logs derived from a person need to be found and deleted along with the source record under Articles 17 and 12(3). (GDPR Article 17, GDPR Article 12)

What does Agentforce cost, and does the pricing model affect compliance scope?

Agentforce offers a per-conversation model at $2 per conversation and a Flex Credits model at $500 per 100,000 credits (a standard action is 20 credits, roughly $0.10); the two consumption models cannot run in the same org at the same time. For employee access, there is also a base Agentforce User License from $5 per user per month (which requires an active Flex Credits subscription), with add-ons at $125–$150 per user per month, while Agentforce 1 Editions start at $550 per user per month. (Salesforce, ekfrazo) The pricing model does not change your privacy obligations; each conversation or action still processes personal data you must govern.

How large are the fines if AI mishandles personal data?

GDPR fines reach up to €20 million or 4% of global turnover. (Improvado) The EU AI Act adds up to €35 million or 7% of turnover for prohibited practices. (artificialintelligenceact.eu) In 2026, CCPA penalties run about $2,663 per unintentional and $7,988 per intentional violation, applied per record. (Clym)

Do third-party AI apps get the Einstein Trust Layer's protection?

No. The Trust Layer covers Salesforce's own generative features. Third-party AppExchange AI tools and custom Apex integrations calling external models need their own masking, logging, and governance, which is why org-wide native controls matter more than any single feature toggle.

Sources

• https://www.salesforce.com/agentforce/pricing/
• https://ekfrazo.com/resources/blogs/salesforce-agentforce-pricing-2026/
• https://trailhead.salesforce.com/content/learn/modules/llm-data-masking-in-the-einstein-trust-layer/explore-llm-data-masking
• https://trailhead.salesforce.com/content/learn/modules/the-einstein-trust-layer/meet-the-einstein-trust-layer
• https://help.salesforce.com/s/articleView?id=ai.generative_ai_trust_arch.htm&type=5
• https://www.eesel.ai/blog/salesforce-einstein-trust-layer
• https://gdpr-info.eu/art-12-gdpr/
• https://gdpr-info.eu/art-17-gdpr/
• https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en
• https://www.garanteprivacy.it/
• https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/240715_Discussion_Paper_Hamburg_DPA_KI_Models.pdf
• https://enterprisedreamin.org/articles/salesforce-dsar-rtbf-automation-2026/
• https://enterprisedreamin.org/articles/ai-for-salesforce-without-data-cloud-2026/
• https://enterprisedreamin.org/articles/securing-ai-in-salesforce-2026/
• https://enterprisedreamin.org/articles/salesforce-field-level-governance-gap/
• https://gptfy.ai/features/bring-your-own-model-in-salesforce
• https://artificialintelligenceact.eu/article/99/
• https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
• https://improvado.io/blog/gdpr-fines
• https://www.clym.io/blog/ccpa-penalties-and-fines-what-businesses-need-to-know
• https://cloudcompliance.app/