AI governance for Salesforce is a short set of written decisions made before any agent goes live: who owns each agent, which jobs it may and may not do, what data it can reach, when a person must approve its work, how it is tested before release, how it is watched afterward, and what records you keep. Salesforce's Einstein Trust Layer handles protections such as masking and zero data retention, but it cannot make those business decisions for you.
Why policy comes before the build
An agent acts with whatever permissions and instructions it has, at a volume no individual employee reaches. A loose rule that caused an occasional mistake when a person applied it can cause hundreds when an agent does. Teams that build first and write policy later usually discover the gaps in production: an agent that answered a pricing question it should have routed, or one that could read records its users were never meant to see.
Governance does not need a committee or a long document. For most mid-market organizations, a two-page policy plus a one-page charter per agent covers it. What matters is that each decision has a named owner and is written down where the build team can check against it.
The seven policies to agree
| Policy | Question it answers | Typical owner |
|---|---|---|
| Ownership | Who is accountable for this agent’s behavior and who maintains it? | Business owner plus a technical owner |
| Allowed use cases | Which requests may it handle, which must it refuse or hand off? | Business owner, reviewed by legal or compliance |
| Data access | Which objects, fields and external sources may it read or change? | Salesforce admin with security |
| Human review | Which outputs need approval before a customer or record sees them? | Business owner |
| Testing and evaluation | What must pass before release and before each change? | Technical owner with business testers |
| Monitoring | Which signals are watched, how often, and what triggers action? | Operations lead |
| Audit and records | What is logged, where, for how long, and who can see it? | Compliance or IT |
Write a charter for each agent that answers every row in plain language. If a row cannot be answered yet, the agent is not ready for production.
Ownership and allowed use cases
Every agent needs a business owner who decides what it should do and signs off on changes, and a technical owner who controls its configuration, instructions and actions. Keep both names on the charter and update them when people change roles; an agent whose owner has left the company is one nobody will pull back when it misbehaves.
Define scope as two explicit lists. The allowed list names the requests the agent handles, such as order status, appointment changes or drafting replies to product questions. The excluded list is just as important: pricing exceptions, refunds above a threshold, legal or medical questions, complaints, anything involving a minor, or whatever your industry treats as sensitive. For each exclusion, say what happens instead, usually a handoff to a named queue with the conversation attached.
Data access and human review
Treat an agent like a new employee with a very fast reading speed. Give it its own permissions rather than borrowing an administrator's, limit them to the objects and fields its use case needs, and check sharing so it cannot surface records the person it serves should not see. Decide separately which external data, if any, it may draw on through Data 360 or integrations, and which fields must never appear in a prompt.
Human review is a dial, not a switch. Set it per action, based on what a wrong answer would cost:
- Read-only answers to internal staff: no approval, but sampled review each week.
- Drafts for customers, such as email replies or case responses: a person edits and sends.
- Record updates with low impact, such as tagging or routing: automatic, with an undo path and a daily exception report.
- Anything touching money, contracts, eligibility or regulated advice: a person approves before the action runs.
- Every case the agent is unsure about, or the customer asks for a person: immediate handoff.
Loosen the dial only on evidence. When sampled reviews show a steady record of correct work over an agreed period, the business owner can move an action one step toward autonomy and note the change in the charter.
Testing, monitoring and audit
Testing starts before the agent exists. Collect real requests from your case, chat or email history, including awkward phrasing and requests the agent should refuse, and write the expected outcome for each. Salesforce's Agentforce Testing Center runs batches of these test utterances against expected results, can generate test cases, supports multi-turn conversations, and can be scripted through Salesforce CLI for teams that deploy through a pipeline. Rerun the full set whenever instructions, actions, knowledge or the underlying model change.
Once live, someone has to look. Agentforce Observability gives session-level tracing of agent conversations, health monitoring against the measures you choose and reporting on credits consumed per agent. Decide in advance which signals trigger action, such as a rising handoff rate, a drop in resolution or a cluster of negative feedback, and who can pause the agent.
For audit, Salesforce stores Einstein generative AI audit and feedback data in Data 360: the prompt, the unfiltered response, toxicity scores and user feedback. Agree how long you keep it, who may query it and how it feeds your existing compliance reviews. Record configuration changes too, since knowing what the agent said matters less if you cannot tell which instructions it was following at the time.
Put governance into practice
Start with one low-risk agent and run the whole policy set on it, from charter to monitoring, before a second agent is approved. Treat changes to instructions, actions and knowledge like any other release: tested in a sandbox, approved by the business owner and deployed through your normal process. A proof of concept is a good place to rehearse this. For a telecom-infrastructure contractor, we delivered a Document AI and Agentforce proof of concept with hands-on knowledge transfer so the internal team could extend it independently, and that handover is the moment an internal owner must take over governance. Review each charter quarterly, retire agents nobody uses, and tell customers or employees when they are dealing with AI where your policies or regulations require it.
