The objection every AI buyer has and most vendors answer vaguely. This page answers it plainly, including the parts that are limitations rather than features.
When a request goes to a hosted model, the provider receives the instructions, the retrieved passages and the user's question. That is unavoidable with hosted inference. What is avoidable is sending more than the task needs, so retrieval is scoped tightly and fields that are not required for the answer are stripped before the call.
The major providers offer commercial terms under which submitted data is not used for training and is retained only briefly for abuse monitoring, or not at all under zero retention agreements. We build against those terms and can tell you per provider what applies. This is a materially different arrangement from the consumer products of the same name.
If residency, contractual constraints or the sensitivity of the material means nothing may leave your infrastructure, we can serve open models inside your own environment. It costs more and the quality ceiling is lower, so we recommend it when it is required rather than by default.
Redaction and tokenisation happen at the boundary, as content enters the index, rather than being bolted on at the prompt. Doing it at ingestion means personal data never propagates into embeddings, caches and logs, which is where retrofitted redaction usually fails.
Traces contain prompts, retrieved passages and outputs, which means they contain whatever your users typed. They get the same retention policy, access control and residency treatment as the primary index, because a log store is where sensitive data quietly accumulates.
During a build we work in your environment where we can. Where we cannot, we take the smallest sample that lets us build and evaluate, agreed in writing, and delete it at handover. We would rather ask for another extract later than hold a full copy of your data indefinitely.
Identity is resolved before the search runs, so a user's query only ever touches documents they are entitled to. The model cannot leak what it never received, which is a stronger guarantee than filtering results after the fact.
Permission aware retrievalWhere a system serves multiple customers, tenancy is a hard boundary in the index and in every query path, not a filter someone can forget to apply.
Multi tenancyAny system that reads untrusted content will eventually read an instruction aimed at it. Untrusted content is fenced from instructions, tool use is allowlisted, and injection cases sit in the regression suite.
Injection defenceRetrieved context, tools called, prompt version and model version recorded per interaction, so when someone disputes what the system said it can be reconstructed rather than guessed at.
AuditabilityCredentials in a managed secret store, scoped per integration, with the narrowest permissions the workflow needs. An agent that only reads order status does not hold a key that can issue refunds.
Access controlEverything is documented well enough that you could take the system in house or move it to another supplier. Lock in by obscurity is a business model we would rather not have.
PortabilityNot under the terms we build against. The enterprise API agreements from the major providers exclude submitted data from training. If a specific provider or tier does not, we will not route your data through it without telling you first.
We would rather answer your security review early and honestly than discover a blocker three weeks into a build.