By: Jonathan Anspaugh, CTO, Revecast
A Salesforce AI governance playbook ahead of Dreamforce 2026.
Two weeks before Dreamforce, Salesforce and Anthropic announced Claudeforce: Claude built into Salesforce, Salesforce data and workflows exposed directly inside Claude, and Claude set as the default model in Slack. It’s a significant announcement, and it’s going to be everywhere at Dreamforce.
It’s also going to create a lot of confusion.
Because within about a week, every Salesforce customer with an AI initiative is going to be asked some version of the same question by their CFO or CIO: “We’re already getting Claude with Salesforce. Why are we paying for anything else?”
That’s a fair question. So let’s answer it and then let’s talk about the much bigger problem that neither Claudeforce nor any point tool is going to solve for you.
The Shadow AI Problem You Already Have
Here’s what you already suspect. While your governance committee has been deliberating on an AI policy, your team has already adopted AI. Not the sanctioned kind.
A January 2026 BlackFog survey of 2,000 workers at companies with 500+ employees found that 49% had adopted AI tools without employer approval, and 51% had connected AI tools to work systems without IT approval. Among those using unsanctioned tools, 58% were on free versions. A third had pasted enterprise research or datasets into them. Roughly a quarter had entered employee data — salaries & performance records — or company financials.
And it isn’t a junior-staff problem. 69% of C-suite executives in that survey said the practice was acceptable.
Now read the terms of service of most consumer AI products. Free and consumer tiers frequently reserve the right to use your inputs — prompts, uploaded files, data payloads and the surrounding metadata — to improve and train their models. Enterprise agreements are usually a different story, with training exclusions and retention controls. But shadow AI, by definition, isn’t running on your enterprise agreement. It’s running on a personal login, on a free tier, on someone’s laptop, under whatever terms that vendor publishes this quarter.
That’s the exposure. Not a hypothetical breach, but a contractual, already-executed transfer of your client’s data into a third party’s training pipeline, performed by an employee acting in good faith and trying to hit a deadline.
For a consultancy, a systems integrator (SI), or an independent software vendor (ISV), it’s worse than a policy violation. It’s a client-contract problem. Most master services agreements have confidentiality and subprocessor clauses that shadow AI quietly violates. You can’t remediate it after the fact, either. As one summary of that research put it: you cannot get the information back.
The governance question is not, “Should we allow AI?” It’s, “Do we have any idea what our people are already doing with it?” If the answer is no, you don’t have an AI strategy. You have an AI liability with a productivity story attached.
What Claudeforce Actually Does for Salesforce AI Governance
Let’s be accurate about this, because sloppy competitive positioning ages badly and Dreamforce attendees will have read the press release.
Claudeforce, as announced, has three parts:
- Salesforce in Claude: a plugin exposing Salesforce data and workflows inside Claude, shipping with 37 prebuilt sales skills. Available to pilot customers now, open beta expected September 2026, with service, marketing, and commerce skills following later in the year.
- Claude in Salesforce: Claude powering Agentforce’s Atlas Reasoning Engine, available via Amazon Bedrock inside the Salesforce Trust Boundary.
- Claude in Slack: Claude as the default model across the Slack workspace.
The mechanism is Model Context Protocol servers. When a seller asks for something, Claude consults the relevant skill, then executes against the Salesforce MCP server. Critically, permissions are inherited: if the user can’t see the record, the MCP server can’t either. Administrators authenticate centrally rather than every user standing up their own connection.
This is a real advance, and it addresses a real version of the shadow AI problem for operational users. A seller who was going to paste an opportunity summary into a free chatbot now has a sanctioned path that runs inside existing permissions. That’s a genuine win.
Here’s the part that matters for scoping: Claudeforce does not build, configure, or deploy anything. In Salesforce’s own framing, there’s “nothing new to stand up, nothing to re-audit, nothing to configure account by account.” That feature is exactly why adoption friction is low. But it also defines the boundary precisely. Claudeforce exposes your existing Salesforce data and actions to Claude for operational processes. It does not touch the delivery lifecycle: requirements, design, configuration, metadata, code, testing, deployment, release governance.
Which means for the people that actually build and change your org — admins, developers, architects, delivery partners — Claudeforce closes exactly none of the exposure described in the section above.
That’s not a criticism of Claudeforce. It’s a description of a different layer.
How Orchestrate Fits into Salesforce AI Governance
Revecast Orchestrate is not a competitor to Claudeforce. Claudeforce governs how your business users consume Salesforce data through AI. Orchestrate governs how your delivery team builds, changes, and ships Salesforce with AI.
You will very plausibly want both. Here’s what puts Orchestrate in a different category:
1. Built for Teams, Not Individual Developers
Most AI development tooling is fundamentally single-player. It runs on one machine, in one Integrated Development Environment (IDE), against one person’s context, and it produces artifacts nobody else can see. That model works for a solo developer. It does not work for a delivery organization where an architect sets direction, three admins configure in parallel, a developer builds, and a lead has to sign off on all of it.
Orchestrate is designed around the team as the unit of work: shared context, shared standards, shared artifacts. The delivery method is enforced by the platform, not by whoever happened to write the prompt that morning.
2. Cloud-Based, so the Work Is Auditable and Visible
Local AI tooling produces local evidence, which is to say none. If AI helped configure a validation rule, nobody can tell you six months later what was asked, what was generated, what was accepted, or by whom.
Because Orchestrate runs in the cloud, every prompt, generation, approval, and artifact is recorded across the team. That gives you two things you cannot get from a local tool. First, an audit trail an auditor or a client will accept. Second, transparency across users. That means a delivery lead can actually see how AI is being used across the engagement rather than inferring it from output quality.
3. Governance and Compliance in Every Layer
Governance isn’t a checkbox on the settings page. It’s role-based access to what AI can see and do, defined data boundaries, human-in-the-loop approval gates at the points that carry risk, retention and residency you can put in writing, and enforcement of your delivery standards at the moment work is produced rather than at review time.
The practical test: can you give a client’s compliance officer a straight answer to, “What data did AI touch on our project, under what terms, and who approved the output?” With shadow AI, the answer is no. With a local tool, the answer is no. That question is the whole reason this layer needs to exist.
4. AI ROI Reporting: Productivity Gains
This is the one most vendors skip, and it’s the one your CFO is going to ask about first.
McKinsey’s research on enterprise AI keeps landing on the same finding: organizations struggle to translate pilots into measurable bottom-line impact. Removing deployment friction isn’t the same as producing value, and “our team feels faster” is not a business case.
Orchestrate reports on AI-augmented delivery as a measurable line: where AI was applied, what it produced, what got accepted versus reworked, and what that meant for delivery effort and cycle time. That turns your AI investment from an act of faith into a number you can defend in a renewal conversation. If you’re a services firm, that’s evidence you can put in front of a client to justify your rate.
Salesforce AI Governance Questions Worth Asking at Dreamforce
Dreamforce is going to be extremely loud about AI. A short filter:
- Does this govern consumption, or does it govern creation? Exposing your data to AI safely and building your org with AI safely are different problems requiring different controls. Most tools do one. Be clear which one you’re buying.
- Where does the evidence live? If the audit trail is on someone’s laptop, there is no audit trail.
- What does it prove? If a tool can’t tell you what it changed about your delivery economics, you will be defending it from budget pressure every quarter for the rest of its life.
Claudeforce is a good solution to the first question for operational users, and it’s going to make a lot of sales teams better. But it leaves the build layer exactly where it was. For most organizations, that’s where the real compliance exposure lives, because that’s where the people with the deepest access to your data and your client’s data are already using AI, quietly, on tools nobody approved.
That’s the gap Revecast Orchestrate was built to close.
Come find us at Dreamforce, September 15–17 in San Francisco.
