TL;DR: A Salesforce AI roadmap should run in five phases over 6 to 12 months: assess and prioritize use cases, decide build vs buy per use case, set security and governance gates before anything launches, measure ROI on a small pilot, then scale what works. The mistake most teams make is skipping straight to a platform decision. Sequence the work instead, and let each phase gate the next.
This is a neutral practitioner guide. It names specific products only as examples of a category, not endorsements. Verify every price and date against the vendor before you commit budget.
Key takeaways
- Run the roadmap in five sequenced phases, not one big platform purchase. Each phase produces a decision the next one needs.
- Decide build vs buy per use case, not once for the whole program.
- Set governance gates before you pick a pilot, because the gate criteria often change the sourcing decision.
- Prove one use case against a pre-recorded baseline before scaling anything.
- Two 2026 regulatory dates shape the timeline: the EU AI Act's GPAI and transparency enforcement (August 2, 2026) and India's DPDP full-compliance deadline (May 14, 2027).
What does a Salesforce AI roadmap actually look like?
Five phases, run in order. Each one produces a decision the next phase depends on.
| Phase | Timeline | Goal | Output |
|---|---|---|---|
| 1. Assess and prioritize | Weeks 1 to 4 | Rank candidate use cases by value and feasibility | A shortlist of 3 to 5 use cases |
| 2. Build vs buy | Weeks 4 to 8 | Decide per use case whether to build, buy, or configure | A sourcing decision for each shortlisted case |
| 3. Governance gates | Weeks 6 to 10 | Set the security and compliance bar every deployment must clear | A written gate checklist and an owner |
| 4. Pilot and measure ROI | Weeks 8 to 16 | Prove one use case with real numbers | A go or no-go decision backed by data |
| 5. Scale | Months 4 to 12 | Roll the winner to more users and add the next use case | A repeatable deployment pattern |
The phases overlap on purpose. Governance work starts while you are still deciding build vs buy, because the gate criteria often change the sourcing decision. A model that cannot mask personal data before it leaves the org is not a candidate, no matter how good the demo looked.
How do you assess and prioritize use cases?
Score each candidate on two axes: business value and feasibility. Value is revenue, cost, or risk reduction you can name a number for. Feasibility is how ready your data is, how clear the workflow is, and how tolerant the process is of a wrong answer.
High-value, high-feasibility cases go first. Case summarization, email drafting, call note capture, and record field population tend to land here because the data already lives in Salesforce and a human reviews the output. Autonomous multi-step agents that take action without review are high value but lower feasibility. They belong later in the roadmap, after you have a governance track record.
A short prioritization checklist:
- Can you state the value in a number (hours saved, cases deflected, cycle time cut)?
- Does the data the use case needs already exist in Salesforce and is it clean?
- Does a human review the output, or does the AI act on its own?
- What is the cost of a wrong answer, and who absorbs it?
- Is there a clear owner who will use this daily?
Cut anything that fails the value test. A feature nobody adopts is a cost, not a win.
Build vs buy: how do you decide per use case?
Decide case by case, not once for the whole program. Building gives you control and no per-seat license, but you own the prompt engineering, the model routing, the security layer, and the maintenance for the life of the tool. Buying moves the maintenance burden to a vendor and gets you to production sooner, at the cost of a subscription and some flexibility.
A rough rule: build when the use case is core to how you differentiate and you have engineering capacity to maintain it. Buy when the use case is common (summarization, drafting, data entry assistance) and a managed package already does it well.
Two platform facts change this math in 2026:
- Salesforce Agentforce is the first-party option. It runs on consumption pricing and provisions Data 360 (formerly Data Cloud), which it is designed to run on. Non-trivial deployments end up committing to Data 360 as a data platform, though a free Salesforce Foundations tier lets Enterprise Edition customers prototype first. See the Agentforce pricing breakdown for the full cost model. (Salesforce Agentforce pricing)
- Native managed packages run inside the org without that data-platform dependency. These are Salesforce-native tools (for example GPTfy and others on AgentExchange) that let you bring your own model, such as OpenAI, Claude, or Gemini, through Named Credentials. Pricing and data flow differ from the first-party path, so the trade-off is worth evaluating per use case. See running AI in Salesforce without Data Cloud and Agentforce alternatives.
Note where each option puts your data. First-party agents keep processing in the Salesforce platform. Bring-your-own-model tools send data to an external provider, which makes the masking and governance gate in the next phase essential.
What governance gates should you set before launch?
Set the gates before you pick a use case to pilot, and make sure no deployment ships without clearing them. This is the phase teams skip, and it is the one that ends up in a breach report or a regulator letter. For the security architecture behind these gates, see securing AI in Salesforce.
A governance gate checklist:
| Gate | Question to answer | Why it matters |
|---|---|---|
| Data masking | Is personal and regulated data masked before it reaches any external model? | An unmasked prompt to a third-party model can be an unlawful transfer |
| Access control | Does the AI respect existing field-level security, sharing rules, and profiles? | AI that ignores sharing can surface records a user should never see |
| Prompt and output logging | Are prompts and responses retained and auditable? | You cannot investigate an incident you did not log |
| Data retention | How long are AI-related records kept, and is that defensible? | Over-retention is its own compliance exposure |
| Consent and rights | Can you honor a deletion or access request that touches AI-processed data? | DSAR and RTBF obligations do not stop at the AI boundary |
| Regulatory mapping | Which regimes (GDPR, CCPA/CPRA, HIPAA, EU AI Act, India DPDP) apply to this data? | The gate criteria are set by the strictest law you touch |
Salesforce Shield covers platform-level encryption and event monitoring, but it does not mask data field by field before it leaves the org for an external model, and it does not automate rights requests. Dedicated privacy products fill that gap. Vendors in this category include Own, Prodly, and Cloud Compliance, whose data masking can act as the governance gate on data leaving the org and whose privacy-rights automation handles DSAR and RTBF requests across major privacy regimes. For the tooling comparison, see Shield vs data masking vs retention, the best Salesforce data masking tools, and DSAR and RTBF automation.
Two regulatory dates should shape the timeline of any 2026 roadmap:
- The EU AI Act's transparency duties (chatbot disclosure, AI-content labeling) and its general-purpose AI (GPAI) model enforcement become applicable on August 2, 2026, with fines up to 15 million euros or 3 percent of global annual turnover for GPAI and transparency breaches. The higher 35 million euro or 7 percent cap applies only to prohibited practices under Article 5, not to these provisions. Under the Digital Omnibus signed on 8 July 2026, high-risk obligations for Annex III systems are deferred to December 2, 2027, and AI embedded in regulated products under Annex I moves to August 2, 2028, but the GPAI enforcement date holds. (Council of the EU)
- India's DPDP Rules were notified on November 14, 2025, with full compliance required by May 14, 2027 under a phased rollout, and penalties reaching 250 crore rupees (roughly 30 million US dollars) per violation. If you process data of people in India, the extraterritorial scope applies wherever your org lives. See India DPDP and Salesforce. (DPDP Rules 2025 overview)
Most orgs already carry hidden exposure here before any AI is added. If you have not audited field-level access recently, read the field-level governance gap and security debt hiding in your Salesforce org first. AI amplifies whatever access problems you already have.
How do you measure ROI on the pilot?
Pick one use case from the shortlist, run it with a small group, and measure against a baseline you captured before launch. Without a baseline the numbers mean nothing.
Track three things:
- Adoption. What percentage of the target group uses the feature weekly? Low adoption kills the ROI case regardless of quality.
- The value metric you named in Phase 1. Hours saved per rep, cases deflected, cycle time cut. Compare to baseline.
- Total cost. Add license or credit spend, model usage billed by the provider, and the internal time spent on governance and maintenance. Consumption pricing can drift, so watch the model bill weekly during the pilot.
Set the go or no-go threshold before the pilot starts so the decision is not argued after the fact. A pilot that clears the threshold moves to scale. One that misses it either gets an adoption fix or gets dropped in favor of the next use case on the shortlist.
How do you scale without losing control?
Scaling is repetition, not reinvention. Once one use case clears the governance gate and proves ROI, you have a deployment pattern: the masking config, the access rules, the logging setup, and the review workflow. Reuse it for the next use case rather than rebuilding from scratch.
Add use cases one at a time and run each through the same five phases. Keep the governance gate owner in place permanently, since someone has to hold the bar as the program grows. Re-run the regulatory mapping when you enter a new market or the model provider changes, because the gate criteria move with the law and the data flow. And watch consumption costs at scale: a per-conversation or per-credit model that was cheap in a pilot behaves differently across a few hundred users, so set a billing alert and review it monthly.
