Direct identifiers
Names, emails, phone numbers and postal addresses typed into free-text fields or pulled from records for context.
Solution
Protect customer data before it reaches OpenAI
OpenAI data privacy for AI SaaS applications.
Detect and mask customer identifiers in the prompt, forward only masked text to the OpenAI API using your own credentials, and restore the original values in the response — without changing how your application code reads.
How can an AI application protect customer data before sending prompts to OpenAI?
Place a privacy layer between the application and the OpenAI API. The layer detects sensitive values in the outbound prompt, replaces them with deterministic placeholders, forwards only the masked text to OpenAI under your own credentials, and restores the protected values in the response. The provider receives the structure of the request without the identifiers.
Summary
The short version
What is the problem?
Production prompts carry customer identifiers — names, emails, account and ticket references — that the model does not need in order to perform the task, and that leave your boundary on every request.
How is it solved?
Detect and mask those values at a gateway before the OpenAI call, then rehydrate the response in memory so the application still sees real data.
When should this approach be used?
When customer or employee data reaches an LLM provider, when an enterprise buyer asks what leaves your systems, or when you want one control point instead of per-feature filtering.
What are the limitations?
Masking is best-effort over a supported entity set, does not certify compliance, does not prevent prompt injection, and cannot govern what OpenAI does with what it still receives.
Problem
The data-exposure problem
The exposure rarely comes from a deliberate decision to send personal data to a model provider. It comes from ordinary product work: a summarization feature is pointed at a support thread, a copilot is given the current record for context, a retrieval step pulls a document that happens to contain an address. Each request is reasonable in isolation. In aggregate, a third party now receives a continuous stream of your customers' identifiers.
The practical consequence usually shows up commercially before it shows up as an incident: an enterprise prospect asks what data your AI features send to which providers, and the honest answer is "whatever the user typed". That answer is what stalls the deal — see enterprise-ready AI for what buyers expect instead.
The question a security reviewer asks is not "is OpenAI secure?" — it is "what does your application send them, and how do you know?"
Exposure surface
What data may appear in prompts
Account and transaction references
Customer ids, ticket numbers, invoice and payment references that map back to a person inside your systems.
Financial and national ids
Card numbers, IBANs and national identifiers pasted into support and onboarding conversations.
Technical identifiers
IP addresses, device ids and session identifiers included in diagnostic context.
Developer secrets
API keys, tokens, connection strings and env values pasted into debugging prompts in internal tools.
Retrieved document content
RAG chunks that carry identifiers from the source document even when the user's question contains none.
Common misconception
Why provider settings alone may not solve application-level privacy
Provider-side controls are worth configuring, and for some organisations they are a necessary part of the answer. They are a different control from data minimization, and they answer a different question.
Framework
What each control can and cannot govern
- 01
Provider settings govern the provider
They describe what the provider does with data it has already received. They cannot reduce what your application chose to send.
- 02
Scope is per provider and per surface
Settings, defaults and contractual terms differ between providers and between product surfaces, and have to be re-verified whenever either changes.
- 03
Intermediate hops are out of scope
Logs, traces, analytics, error reporting and prompt-debugging tools sit between your application and the provider and are governed by neither.
- 04
Verification is contractual, not observable
You are relying on a stated policy. Masking before egress produces evidence you can demonstrate from your own side of the boundary.
- 05
Minimization survives provider changes
If you later add or switch providers, controls applied before the call still apply. Provider-specific settings do not transfer.
The two are complementary: configure the provider correctly, and also reduce what has to be trusted to that configuration.
Provenance
About OpenAI-specific claims
Control 1
Detecting sensitive data before transmission
Minimization starts with detection: you cannot mask what you have not identified. Privian scans the assembled prompt — every message in the request, not just the latest user turn — for the supported entity set on each request, with no cross-request state.
- Personal identifiers: names, emails, phone numbers, IP addresses
- Financial and national ids: card numbers, IBANs, US SSN, Canadian SIN
- Developer secrets: JWTs, provider API keys, GitHub tokens, AWS keys
- Env-style assignments and prefixed secret tokens
The current catalog and its known gaps are listed on the PII masking page. Detection is best-effort and should be evaluated against your own data before you rely on it.
Control 2
PII masking before the OpenAI call
Each detected value is replaced with a deterministic, type-aware placeholder for the duration of the request — PERSON_1, EMAIL_2, CREDIT_CARD_1. The prompt keeps its shape, so the model can still follow who did what, but the identifying value never crosses the boundary.
Application sends to Privian
Draft a reply to Michael Olsen
(michael@example.com) about
invoice INV-4821.Privian sends to OpenAI
Draft a reply to PERSON_1
(EMAIL_1) about
invoice INV-4821.Control 3
Prompt privacy as a request-path property
Prompt privacy means the controls live in the request path rather than in each feature that happens to call OpenAI. A new AI feature added six months from now inherits the same treatment as the first one, because the control is attached to the egress point and not to the code that produced the prompt. The concept is described in more depth under prompt privacy.
Control 4
A controlled, documented data path
Because every OpenAI call goes through one place, the data path is describable hop by hop: what enters, what is transformed, what is forwarded, what is stored. That description is what a security reviewer actually asks for, and it is published per-hop on the data path page.
Control 5
Rehydration on the way back
If masking were one-way, every consuming feature would have to be rewritten to handle placeholders. Instead the mapping is held in memory for the life of the request, applied in reverse to the OpenAI response, and then discarded. Your application receives the reply with real names and addresses; the provider never saw them. Unknown placeholders in a response pass through untouched. See rehydration for the mechanics.
Control 6
Retention considerations
Retention has to be answered at each hop, not once. Three of them are usually in scope for an AI feature built on OpenAI:
Your application
Prompt logs, traces and analytics are often the largest retained copy of sensitive prompt content, and they are entirely under your control.
The privacy layer
Privian does not persist raw prompts or responses. Only structural counters are retained for billing and observability.
The model provider
Governed by the provider's own terms and your configuration — check OpenAI's current documentation rather than a summary.
Commercial impact
What this changes in an enterprise security review
Reviewers rarely ask whether you use OpenAI. They ask what you send, who holds the credentials, what is retained and how you would prove it. Masking before egress changes the answers from intentions to architecture:
Framework
Answers a reviewer can verify
- 01
What leaves our systems?
Masked prompts containing placeholders for the supported entity set, rather than raw customer records.
- 02
Who holds the provider credentials?
You do — BYOK, encrypted at rest, decrypted in-process at request time.
- 03
What does the vendor retain?
No raw prompts or responses; structural counters only.
- 04
How is this enforced?
At one egress point that every AI feature passes through, rather than per feature.
- 05
What is out of scope?
Compliance certification, prompt-injection defence, and anything the detector does not support.
The document set buyers usually request is collected in the enterprise trust package.
Architecture
Implementation architecture
- 1
Application — Your code calls the OpenAI Chat Completions shape as usual, with the base URL pointed at Privian and a Privian gateway key.
- 2
Privian privacy layer — The assembled prompt is scanned, supported entities are replaced with deterministic placeholders, and the request-scoped mapping is held in memory.
- 3
OpenAI — The masked request is forwarded to OpenAI using your own encrypted credentials; usage bills against your account.
- 4
Privian rehydration — Placeholders in the response are replaced with the original values from the in-memory mapping, which is then discarded.
- 5
Application — Your code receives an ordinary OpenAI-shaped response containing real values — no placeholder handling required downstream.
In practice the integration change is the base URL and the key:
from openai import OpenAI
client = OpenAI(
base_url="https://api.privian.io/v1",
api_key=os.environ["PRIVIAN_GATEWAY_API_KEY"],
)
resp = client.chat.completions.create(
model="openai/gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
)Full request and response shapes are in the API reference; the model catalog is on supported models.
Fit
When this pattern is useful — and when it isn't
Useful when
- Customer or employee data reaches OpenAI through product features
- Enterprise buyers are asking what your AI features transmit
- Several features call OpenAI and you want one control point
- You may add or switch providers and don't want to redo privacy work
- Internal tools risk pasted keys and tokens reaching the provider
Less useful when
- The task genuinely requires the literal identifying value
- Your prompts contain no personal or sensitive data at all
- You need native streaming, tool calling or multimodal input today
- Your requirement is prompt-injection defence rather than data minimization
- You need a certification rather than a technical control
Scope
What this does NOT solve
FAQ
Frequently asked questions
- How can an AI application protect customer data before sending prompts to OpenAI?
- Put a privacy layer between the application and the OpenAI API. The layer detects sensitive values in the outbound prompt, replaces them with deterministic placeholders, forwards only the masked text to OpenAI, and restores the original values in the response. The application keeps working with real data; the provider receives less of it.
- Is it safe to send customer data to the OpenAI API?
- That is a question about your legal basis, your agreement with OpenAI, your configuration and the sensitivity of the data — not something a vendor can answer generically. What you can control architecturally is how much identifying data needs to leave your boundary at all. Sending structure instead of identifiers reduces the exposure regardless of how the provider question is answered.
- Does OpenAI retain API data?
- Retention behaviour depends on the product surface, your account configuration and your contract, and it changes over time. Check OpenAI's current API data-usage and retention documentation rather than any third-party summary, including this one. Privian's position is that a privacy layer should reduce what is sent in the first place, so the answer matters less.
- Do provider-side privacy settings remove the need for application-level controls?
- No. Provider settings govern what the provider does with what it receives. They cannot govern what your application decides to send, they do not apply to intermediate hops such as logging and analytics, and they generally have to be re-verified per provider. Application-level minimization is complementary, not redundant.
- What customer data typically appears in OpenAI prompts?
- Names, email addresses, phone numbers, IP addresses, account and ticket identifiers, payment references, and — in developer-facing tools — API keys, tokens and connection strings pasted in for debugging. Most of it arrives incidentally inside free text rather than through a field explicitly labelled as personal data.
- Does masking break the OpenAI response quality?
- Placeholders are deterministic within a request, so the same value maps to the same token throughout the prompt and the model can still reason about relationships. It does affect tasks that genuinely depend on the literal value, such as validating a specific email address format.
- How does this work with the OpenAI SDK?
- Privian is OpenAI Chat Completions-compatible for non-streaming requests. Point the OpenAI SDK's base URL at https://api.privian.io/v1, use a Privian gateway key, and address models as openai/<model>. Streaming, tool calling, JSON mode, multimodal input and the Responses API are not supported in the current beta.
- Who holds the OpenAI credentials?
- You do. Privian uses BYOK: your OpenAI key is stored AES-GCM encrypted at rest and decrypted in-process at request time, and token usage bills against your own OpenAI account.
- Does Privian store the prompts sent to OpenAI?
- No. Raw prompts and responses are not persisted. Only structural counters are retained for billing and observability.
Enterprise review
Built for enterprise review
Trust assets procurement and security teams routinely request.
Plans & pricing
Pricing for OpenAI-bound prompt privacy
BYOK, zero retention and masking before the provider call. Beta plans may change as the product matures.