"Can the AI see our pricing?" — the first question CIOs now ask vendors
It sounds like a security question. It is really four questions at once, and vendors answer the easy one unless you separate them.
The short answer
When a CIO asks whether an AI tool can see company pricing, they are asking four separate things: whether it can retrieve the data, whether that data leaves your tenant, whether it is retained or used for training, and which users the tool will reveal it to. Vendors answer the first and buyers hear all four.
Why it matters for sales leaders
- Pricing is the data industrial firms guard hardest and the data reps most need answered live.
- A vendor saying 'we don't train on your data' has answered one of four questions.
- Access inheritance decides whether a junior rep can reach margin data through the assistant.
Somewhere in the second vendor meeting, the CIO asks it: can the AI see our pricing?
The vendor answers confidently, usually with some version of “your data stays yours and we don’t train on it,” and the room moves on. Both sides leave believing the question was settled. It was not, because the question was four questions wearing one sentence.
The four questions inside the one
Can it retrieve pricing at all? A surprising number of sales-AI deployments cannot. If the tool has not been connected to the price list and the ERP, it cannot answer the question reps ask most — price at this quantity, for this customer’s tier. This is the question the vendor is usually answering, and it is the least sensitive of the four.
Does the data leave our tenant? Retrieval is not the same as transmission. If the tool sends retrieved pricing to a third-party model endpoint for reasoning, that data has crossed a boundary — possibly a regional one, which matters for Indian enterprises under the DPDP Act and European ones under the GDPR. Ask specifically where inference happens and which sub-processors are involved.
Is it retained? Prompts and outputs are frequently logged for debugging, abuse monitoring or quality evaluation, on a retention schedule that has nothing to do with training. “We don’t train on your data” and “your pricing appears in logs retained for ninety days” are both true simultaneously, and only one of them usually gets said.
Which of our own people will it show it to? The one that gets missed, and often the largest practical risk.
The access inheritance problem
Most integrations use one of two identity models, and the difference decides your internal exposure.
Acting as the user. The tool queries the underlying system with the signed-in person’s own credentials. If that rep cannot open the margin sheet directly, the assistant cannot retrieve it for them. Permissions you already maintain continue to work.
Acting as a service account. The tool holds its own broad credentials and queries on everyone’s behalf. Now the assistant becomes a route around your access model: a junior rep who cannot open cost data may be able to ask a question whose answer contains it.
The second pattern is common, because it is far simpler to build and it makes indexing straightforward. It is rarely volunteered in a sales conversation. Ask which model applies, get it in writing, and if it is the service account, ask what filtering is applied and how it is tested.
What good answers sound like
A vendor with a defensible position will be specific without being prompted: it acts as the signed-in user; inference runs in a named region; prompts and outputs are retained for a stated number of days for a stated purpose; the sub-processor list is published and changes come with notice; the zero-training commitment is in the master agreement, not the FAQ.
A vendor whose answer is a reassurance rather than a mechanism has not thought about it, or would rather you did not.
The mistake in the other direction
The safe-looking response is to keep pricing out of the AI entirely. It is also how organizations end up with expensive licenses nobody uses.
Price, stock and lead time are precisely the questions that make an assistant worth opening for a sales rep. Exclude them and you are left with a tool that drafts emails — which is real, but it is not the business case anyone approved. The workable answer is scoped read access with the user’s own permissions honored and every retrieval logged.
That is a harder configuration to build and a much easier one to defend.
Was this useful?
Questions leaders are asking
What should we ask a sales-AI vendor about pricing data? +
Split the question. Can it retrieve pricing, and from where? Does that data leave our tenant or cross a region boundary? Is it retained, logged, or used for training, and for how long? And does the tool respect each user's own permissions, or does it act through a service account with wider access?
Does 'we don't train on your data' cover everything? +
No. It addresses training only. Data can still be transmitted to a third-party model provider, retained in logs for a period, cached for performance, or exposed to users whose own permissions would not allow it. Each of those needs its own answer, ideally in the contract rather than in a sales call.
Can an AI assistant leak pricing to the wrong internal user? +
Yes, and this is the most commonly missed risk. If the integration reads through a service account with broad rights rather than acting as the signed-in user, anyone who can ask the assistant a question can potentially reach data their own role would deny them. Ask which identity model applies.
Is it safer to keep pricing out of the AI entirely? +
It is safer and much less useful. Price at quantity is one of the questions reps most need answered live, and excluding it is a large part of why general assistants go unused in sales teams. The workable position is scoped read access with permissions honored, not exclusion.
Sources
- Microsoft Learn — Microsoft 365 Copilot data, privacy and security learn.microsoft.com
- Microsoft Learn — Graph connectors and access control learn.microsoft.com
- NIST — AI Risk Management Framework nist.gov