Where an AI quoting system gets its prices — and whether your data is safe
A machinery dealer's real questions about AI quoting are concrete: can it invent a price, and does our data train someone else's model? Both answers are architectural, and both are checkable.
Two questions come up in every dealer conversation about AI quoting, and both are usually treated as questions about the model. Can it invent a price? Does our data train someone else's AI? They are not model questions. They are architecture questions, and the reassuring part is that architecture is checkable in a way "trust us, the model is accurate" is not.
We build these systems, and the honest way to answer both questions is to show where the price comes from and where the data goes. Neither answer requires the buyer to understand machine learning. Each requires the vendor to be precise about the parts of the system a probabilistic model is allowed to touch, and the parts it is not.
The price comes from a catalog, not a model
Start with the path a price actually takes. A manufacturer's list arrives as a PDF or a spreadsheet. That file is read — with AI assistance — into a structured catalog, reviewed by a person, and published as a version. When a salesperson builds a quote, the application queries that catalog for the price. The model is not in that path. It did its work upstream, during ingestion, and a human accepted the result before it became a number anyone could quote.
This is why a correctly built system has no route to invent a price. There is no live call to a model asking "what does this cost?" The price is a lookup against approved data, the same way a well-built store checkout does not ask a language model to guess the total. Prices for machinery change every three to six months, not every second, so there is nothing to gain from generating them live and a great deal to lose.
It is worth being precise about the word grounding, because vendors use it loosely. Grounding a model in your current documents — retrieval-augmented generation — genuinely improves factual accuracy, and it is the right first move over fine-tuning for information that changes (Microsoft, 2024). But grounding reduces error; it does not eliminate it. A peer-reviewed corpus of 18,000 annotated retrieval-augmented responses exists precisely to measure the hallucinations that remain (Niu et al., 2024). So we do not use runtime retrieval as the price source. We use AI to turn a manufacturer's document into candidate catalog data, review it, and publish a deterministic version. Grounding stops being a live document search and becomes a controlled data-maintenance step — which is the version of it a dealer can actually trust with a customer-facing number.
Where AI is allowed to help
None of this means the quoting screen has no AI in it. It means the AI runs where a mistake is caught before it ships, not where it becomes a commitment. There are two lanes, and the whole design is knowing which is which.
| AI may run here | AI must never run here | |
|---|---|---|
| Reading a manufacturer PDF into catalog data | Yes — proposes, a person reviews | — |
| Summarizing an inbound request | Yes — a draft for a human | — |
| Suggesting an alternative machine | Yes — a suggestion, not a decision | — |
| The unit price, discount, or tax | — | Deterministic catalog + rules only |
| Compatibility validation | — | Deterministic rules only |
| The number on the offer sent to a customer | — | Approved catalog version only |
The rule is simple to state and it is the same rule from the pillar of this cluster: a model may propose data for a human to accept, but it must never be the system of record or the final calculator for price, discount, tax, or compatibility. Define the failure behavior explicitly, too. If the data is missing or stale, the app stops and escalates. It does not improvise a number to be helpful.
The privacy question, answered by architecture
Now the second question, and it deserves a straight answer because the fear behind it is real. In our experience the Polish reflex is that all company data is private and must never leave the building, and that reflex is not wrong — it is just imprecise. Dealer price books and quotes are commercially sensitive; they are usually not personal data in the way a health record is. That distinction matters, because the honest privacy story is not "your data never moves." It is "here is exactly what moves, where, and what happens to it."
The load-bearing distinction is between grounding and training. Grounding means your data is retrieved and put in front of a model at the moment of a request; it stays your data. Training means your data is absorbed into a model's weights. Feeding a fine-tuned model your quotes carries a documented memorization risk — research has shown fine-tuned models can leak fragments of what they were trained on (Zeng et al., 2023). We do not train models on client data. In 2026 we do not need to: off-the-shelf models are good enough that the choice is a matrix of budget, in-house competence to run something more advanced, and data sensitivity — not a training project.
And the "someone else's AI trains on our data" fear has a concrete, contractual answer at the provider level. Business API data from the major providers is not used to train their models by default, and enterprise arrangements go further with zero data retention.
| Provider control | What it means | Reference |
|---|---|---|
| Not used for training (default) | API inputs/outputs are not added to the provider's training data | OpenAI, Anthropic, Azure OpenAI |
| Retention window | Short abuse-monitoring retention (e.g. ~30 days), removable under ZDR | OpenAI |
| Zero data retention | Nothing stored after the response, on approved enterprise plans | Anthropic |
| No provider access, in-region processing | Prompts not shared with the model provider; regional hosting | Azure OpenAI |
Two honest cautions belong next to that table. "Not used for training" is not the same as "zero retention" — they are different controls, and a careful vendor names which ones apply. And GDPR scope depends on what the data contains: a price book alone is unlikely to be personal data, but customer names, contacts, and quote histories can pull the system into scope, which the European Data Protection Board treats as a case-by-case assessment (EDPB, 2024). For the genuinely sensitive fraction of data — in our experience roughly a tenth of it — the technique is to anonymize before it is sent and re-associate after, so the sensitive fields never leave the dealer's environment in the clear.
What to verify before you sign
If you are evaluating a vendor, four checks separate an architecture from a slogan. Ask where a quoted price is computed — the answer should be a catalog version, not a model call. Ask what the model is allowed to decide — the answer should stop short of price, discount, tax, and compatibility. Ask whether client data trains any model — the answer should be no, with the provider's no-training and retention terms named. And ask what happens to the sensitive fields — the answer should be anonymization or on-prem handling, not a promise.
Custom AI is not a synonym for expensive AI; it is a synonym for AI that fits the operational reality of the dealer's business — and that reality is a customer-facing price that has to be right and data the owner is right to protect. Trust in an AI quoting system is a property of where the price is computed and where the data goes, not of how clever the model is. Get the architecture right and the model can be boring, which is exactly what you want it to be. Whether the team will then actually use the thing is a different question, and the next one in this cluster.