TL;DR: AI governance for Salesforce is the program that decides which AI can run in your org, what data it can touch, who approved it, and how you prove all of that after the fact. It is broader than field permissions: you are governing agents, the models behind them, and the data those models see. Start by inventorying every AI feature already active, then put approval, data-access limits, and audit logging around each one. This piece covers the governance program: policy, roles, and accountability. For the technical controls themselves (masking, the Einstein Trust Layer, Shield), see Securing AI in Salesforce.
What does AI governance mean on Salesforce specifically?
Most governance advice was written for human users and static integrations. AI breaks the assumptions underneath it. An Agentforce agent can read records, update fields, send email, and call external APIs on its own, and it does so by inheriting the permission model of whatever user or service account it runs as. A prompt template can quietly ship customer PII to a model hosted outside your org. A well-meaning admin can turn on a new AI feature in a sandbox and promote it to production without anyone in security ever seeing it.
So AI governance on Salesforce covers three things that field-level permissions do not:
- The agents and features themselves. What AI is allowed to exist in the org, and who signed off.
- The models behind them. Which large language model processes your data, where it runs, and whether it retains anything.
- The data those models see at runtime. Not just which fields a user can open, but which fields get serialized into a prompt and sent out.
This is a different problem from the one covered in the Salesforce field-level governance gap. Field-level controls answer "can this user see this field." AI governance answers "can this agent, using this model, take this action on this data, and can we prove it later." You need both. If your field permissions are already loose, AI just moves that exposure faster and at larger scale, which is the core argument in the security debt hiding in your Salesforce org.
This article stays on the program side: policy, approval, ownership, and accountability. The controls that enforce those decisions inside the org are covered separately in Securing AI in Salesforce, so the two pieces pair rather than repeat each other.
Why does this matter now?
AI in Salesforce moved from suggestion to action, and regulators put real numbers on getting it wrong. Agentforce agents operate with topics, enumerated actions, and configurable guardrails, running inside your org under the same permission model as your human users (Salesforce Trailhead). An action is a concrete step: query a record, update a field, trigger a Flow, call an external API. Ungoverned, an agent that can act carries the same reach as a privileged user, without a person in the loop.
On the regulatory side, the EU AI Act now attaches administrative fines up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher, for prohibited AI practices; high-risk system violations reach up to EUR 15 million or 3% (Article 99, EU AI Act). That ceiling sits above GDPR's EUR 20 million or 4%, so AI governance is no longer a subset of privacy work. It is its own line item.
The timeline changed in mid-2026 and is now settled law, not a proposal. The Digital Omnibus on AI was adopted by Parliament on 16 June 2026, given final Council green light on 29 June 2026, and signed on 8 July 2026, entering into force on the third day after publication in the Official Journal (Council of the EU). It defers the high-risk obligations: stand-alone Annex III systems move to 2 December 2027, and AI embedded in regulated products under Annex I moves to 2 August 2028 (Gibson Dunn). What still applies around 2 August 2026 is the Article 50 transparency obligations for AI-generated content and the enforcement powers of the AI Office; generative-AI systems already on the market before 2 August 2026 have until 2 December 2026 to meet the Article 50(2) machine-readable marking requirement. If your Salesforce AI touches EU individuals, plan to the transparency date now and the high-risk dates as they arrive.
What does a practical AI governance framework look like?
A Salesforce AI governance framework has six components: policies, approval and guardrails, data-access controls, audit and monitoring, model choice and oversight, and roles and ownership. You do not need all six live on day one, but you need a named owner for each.
| Component | The question it answers | Where it lives in Salesforce |
|---|---|---|
| Policies | What AI is allowed, and for what use cases | Written policy, referenced in change management |
| Approval and guardrails | Who signed off, and what the AI cannot do | Agent topics/actions, permission sets, deployment gates |
| Data-access controls | Which fields and records the AI can see or send | Sharing, FLS, masking, prompt-template scoping |
| Audit and monitoring | What the AI actually did, provably | Event logs, agent traces, retention policy |
| Model choice and oversight | Which model runs, and where a human intervenes | Named Credentials, escalation rules |
| Roles and ownership | Who is accountable when it breaks | RACI, named owners per feature |
Policies
Write down which AI use cases are approved, which are prohibited, and what data classes are off limits to any model. Keep it short enough that an admin will actually read it before flipping a setting. Tie it to your data classification so "no financial account numbers in prompts" is an enforceable rule, not a suggestion.
Approval and guardrails
Every AI feature needs a gate before production. For Agentforce, guardrails are configured at the agent level: topics define what the agent may handle, actions define the concrete steps it can take, and hard boundaries define topics it must never engage and thresholds where it must escalate to a human instead of proceeding (Salesforce Trailhead). Treat "which actions can this agent take in production" as a security review, not an admin task. The governance job here is the sign-off record: who approved this agent, against which policy, on what date.
Data-access controls
This is where AI governance and field governance overlap, but the AI version is stricter. An agent inherits its running user's sharing and field-level security, so an over-permissioned service account is a data leak waiting to happen. Beyond permissions, the governance decision is what gets masked before it ever reaches a model, and who owns that rule. Native masking on the prompt path is one option; a dedicated masking layer that stays consistent across sandboxes and non-AI flows is another, and most AI incidents start with a copy of production data sitting somewhere it should not. The mechanics of each approach, and when to use which, are compared in Salesforce Shield vs data masking vs retention and the best Salesforce data masking tools. Your program's task is to assign an owner to the masking rule and confirm it covers every path, not just the native one.
Audit and monitoring
You cannot govern what you cannot see after the fact. Native Salesforce AI logs a fair amount on the prompt path, and Agentforce Observability adds session traces so you can reconstruct what an agent did turn by turn (Salesforce Developers). Two gaps are yours to close as a program, not a product: retention (how long you keep those logs, which is a compliance decision, not a storage default) and coverage of any AI that runs outside the native path. Decide the retention schedule, write it down, and make sure audit and PII records are disposed on that schedule rather than accumulating forever. Salesforce Shield vs data masking vs retention walks through the retention options.
Model choice and human oversight
Governance includes deciding which model sees your data, not just accepting the default. Native Agentforce routes through Salesforce's chosen models. If you need to pick the model yourself, or keep data out of a particular vendor's cloud, your options are in-org bring-your-own-model tooling that routes through Salesforce Named Credentials, or DIY Apex callouts you build and secure yourself. Either way, model choice, credential control, and per-model cost tracking become things you own rather than inherit. The tradeoffs between those paths are laid out in add ChatGPT and Claude to Salesforce and the best AI tools for Salesforce comparison. Human oversight is the other half: define, per feature, when the AI must hand off instead of act.
Roles and ownership
The failure mode here is diffusion. Security assumes the admin owns it, the admin assumes security signed off, and nobody owns the model contract. Assign a named owner per AI feature, plus one accountable person for the AI governance program overall. Without that, the other five components lose their owner and go unmaintained.
How is this different from Agentforce's built-in controls?
Salesforce ships real governance primitives, and you should use them. The distinction is that platform controls govern the AI Salesforce sells you, running on the path Salesforce designed. Your governance program has to cover everything, including AI that predates Agentforce, third-party prompt tools, and anything that calls an external model directly. Cost governance is part of this too: Agentforce Flex Credits run at $500 per 100,000 credits, with a standard action costing 20 credits, about $0.10 (Salesforce), so an ungoverned agent is also an uncapped bill. See Agentforce pricing explained and Agentforce alternatives for the full picture. For the enforcement controls that back these decisions up, see Securing AI in Salesforce.
How do I start without a six-month project?
One first step: inventory the AI already running in your org. Einstein features, Agentforce agents, prompt templates, installed packages that call external models. You cannot govern what you have not counted, and most orgs find more than they expected.
Then, in order:
- [ ] List every active AI feature and its running user or service account
- [ ] For each, record which model it uses and whether data leaves the org
- [ ] Confirm what is masked before any prompt is sent
- [ ] Turn on and retain audit logging for every AI path, native and third-party
- [ ] Put an approval gate in front of new agents reaching production
- [ ] Assign a named owner per feature and one program owner overall
Fix the highest-exposure item first. Usually that is an over-permissioned agent or an unmasked prompt sending real data to an external model.
