What do enterprise buyers actually ask in AI security reviews?

The recurring set: what enters the model, what is retained, who can see it, what is logged, which providers and sub-processors are involved, how prompts and responses are protected, what controls exist beyond policy, and how reversible the decision is. Most reviews map back to those eight questions.

Is policy enough to protect AI workflows?

Policy is necessary and rarely sufficient on its own. People use the tools that make work faster, and AI is one of those tools. Enterprise reviewers increasingly expect technical controls behind the policy — masking, BYOK, retention rules, allow-listed models — not just a written acceptable-use page.

Where does Privian fit in an AI control stack?

Privian sits between the application and the model provider as a privacy-first LLM gateway. It reduces prompt-level sensitive-data exposure via masking and BYOK and does not retain raw prompt or response bodies. It is one layer — it is not governance tooling, prompt-injection defense, self-hosted inference, or a compliance certification.

Does Privian replace self-hosted models?

No. Privian is optimized for teams using managed model APIs while reducing what reaches the provider. If a workload genuinely requires self-hosted inference, Privian is not the layer that solves that requirement.

What enterprise buyers ask about AI data privacy

Q: What is a clean AI data path?

A data path where you can point at every hop between application and model and say what is sent, what is retained, who can see it, and how to change it. Definition-first explainer: /resources/articles/what-is-a-clean-ai-data-path.

AI made it into procurement. A year ago, "we use ChatGPT for some internal tasks" was a side conversation; today it is a security review. This article catalogs the questions reviewers actually ask, in the order they tend to come up, and points to how teams answer each one in practice.

It is descriptive, not prescriptive. Privian is mentioned where it is genuinely relevant; the goal is to help engineering and procurement teams answer the questions, not to position one tool as the answer to all of them.

Why enterprise AI reviews changed

Two things shifted at once. First, AI usage moved from experimentation to embedded product features and internal copilots — the prompts now contain real customer and employee data, not synthetic examples. Second, security and privacy teams caught up: AI is no longer a footnote in a SaaS review, it is a section of its own with its own questionnaire.

The result is that vague answers no longer pass. "We do not train on your data" is a provider claim, not an answer about your application. Reviewers want to see the path the data takes.

The questions enterprise buyers ask

These are the recurring ones, paraphrased from real review questionnaires:

What enters the model? Which fields from which systems end up inside the prompt at runtime?
What is retained, and for how long? By the application, by any gateway in front of the model, and by the provider.
Who can see prompt and response bodies? Internal staff, support, infrastructure providers, sub-processors.
Which providers and sub-processors are involved? Is the list documented and reviewable?
What controls exist on the prompt itself? Masking, redaction, allow-listed fields, or just policy.
How are provider credentials managed? Who owns the contract, who pays the bill, who can rotate the key.
How are model choices governed? Can the team restrict which models are reachable?
What does the audit trail look like? Structural metadata, not raw bodies.
Is the data flow reversible? If something changes — a new regulation, a leak at a provider — how quickly can it be cut over.
What does the vendor explicitly not solve? Reviewers trust honest scope more than maximal claims.

Clean data path, explained

A "clean" AI data path is one where every hop between the application and the model is described, and where the description matches the implementation. The definition-first version is here: What is a clean AI data path? The reference for Privian's own data path is at /data-path.

Retention

Reviewers want a specific answer per hop. For Privian, the short version: account, BYOK credential (AES-GCM at rest), hashed API keys, usage rollups and sanitized events are persisted; raw prompt bodies, rehydrated response bodies, the entity-mapping table and the decrypted provider key are not. The diagram and the longer explanation live on /data-path.

BYOK and provider boundaries

Bring-your-own-key means the provider relationship — contract, key, billing — stays inside the buying org. Privian decrypts the credential in memory for the duration of a single request and discards it. See BYOK for privacy-sensitive AI for what BYOK does and does not change.

Policies vs. technical controls

Acceptable-use policies are necessary. They are also routinely worked around by people trying to ship something on a deadline. Reviewers know this; the question they ask is what technical controls back the policy up. The longer take: Policies vs. technical controls for AI.

Managed vs. self-hosted models

This trade-off comes up in almost every review. Managed APIs win on iteration speed and operational simplicity; self-hosted wins when the workload genuinely cannot leave a controlled environment. Most enterprise stacks end up hybrid. Neutral comparison: Managed vs. self-hosted LLMs and Privian vs. self-hosted LLMs.

What a realistic AI control stack looks like

For most enterprise stacks: policy and training at the top; upstream data minimization in the application; a gateway in the middle that masks, routes and enforces retention; BYOK so the provider relationship stays inside the org; allow-listed models; structural observability. No single layer is sufficient.

Where Privian fits

Privian is the gateway layer in that stack. It reduces prompt-level sensitive-data exposure before prompts reach the provider, supports BYOK end-to-end, and persists structural metrics rather than raw bodies. It is provider-agnostic across the major managed model APIs.

What Privian does not solve

It is not an audit logging platform.
It is not a governance or DLP system of record.
It does not defend against prompt-injection attacks.
It does not provide self-hosted inference.
It does not grant compliance certifications, and using it does not by itself make a workflow compliant.

That list is deliberate. A vendor that claims to solve all of the above is one that reviewers will probe harder, not less.