OpenAI Private Intelligence Bundles Privacy Controls

OpenAI introduced Private Intelligence on October 30, 2026, bringing enterprise privacy controls and a new inference preview under one business offering. The package covers eligible Zero Data Retention workflows, automated safety processing without personnel access to underlying content, configurable agent boundaries and confidential-computing protections for inference.

The availability distinction matters: Zero Data Retention is offered for eligible workflows, while Private Inference is explicitly labeled an API preview. OpenAI directs interested organizations toward an interest form and sales discussions, rather than publishing a universal access tier or general price.

OpenAI’s announcement says the company is developing these protections with some of its largest customers for sensitive business work:

The useful way to assess this launch is to separate three concerns: what happens to data after a request, how it is protected during processing, and what an agent is allowed to do. Private Intelligence brings those concerns together, but its individual controls address different risks.

What Private Intelligence Includes Today

OpenAI’s Private Intelligence product page organizes the offering around four commitments: restricted access to business content, customer ownership of inputs and outputs, customer control over agent actions, and security measures including encryption, access controls and threat detection.

Those commitments sit alongside features with different availability and configuration requirements:

OpenAI’s Privacy by Product page places the protections across ChatGPT, Codex and the API, with controls designed for each product. It also directs organizations to discuss their requirements with the company.

That makes Private Intelligence best understood as an umbrella for product-specific protections. A business should not assume that a setting available for one API workflow automatically applies to its ChatGPT workspace or a connected agent.

My view is that this distinction deserves more attention than the new branding. Procurement teams need a map of which controls cover their actual application, not simply confirmation that their vendor offers a privacy portfolio.

Zero Data Retention Still Includes Safety Processing

OpenAI’s Private Intelligence interest form explains the relationship between Zero Data Retention and Private Safety Processing. It says the combination enables automated safety reviews:

“without giving OpenAI personnel access to the underlying content.”

Safety processing therefore remains part of the described workflow. The change concerns how that review happens and the access available to personnel.

That is a consequential detail for organizations handling sensitive records. A business may want safety safeguards to remain active while placing tighter restrictions on who can inspect the content submitted to a model. OpenAI presents Private Safety Processing as a way to support both requirements.

The public description is narrower than a complete technical specification. It does not explain the safety system’s architecture, enumerate every eligible workflow or provide an exhaustive account of how each category of operational data is handled.

For a buyer, the next step is to establish the exact scope in writing:

• Which product, model and workflow qualify for Zero Data Retention?
• Which content and operational data are covered by the retention arrangement?
• How is Private Safety Processing applied to that deployment?
• Which contractual commitments govern personnel access?

These are implementation questions raised by the published description, not evidence of a defect. They matter because the word “eligible” makes the deployment boundary part of the protection.

Private Inference Targets Protection During Processing

OpenAI describes Private Inference as combining confidential computing with strict, verifiable controls. Its diagram places that protection between the incoming prompt and outgoing response, inside the OpenAI environment, and labels it API Preview.

The distinction from Zero Data Retention is about the stage being protected. Retention controls concern what is kept. Confidential computing is aimed at protecting workloads while computation is taking place, when a model must process information to generate an answer.

That also differs from encryption in transit, which protects information as it moves between systems. OpenAI’s diagram lists encrypted transport separately from Private Inference, indicating that these are complementary protections.

For regulated buyers, the practical appeal is clear: reducing storage alone leaves questions about access during execution. Private Inference is OpenAI’s proposed additional layer for that part of the request lifecycle.

The overview pages, however, do not provide enough detail to assess the full technical guarantee. They do not specify the hardware architecture, a customer verification procedure or a complete supported-model list. The preview label also leaves access and future availability unsettled. This article analyzes OpenAI’s published descriptions, not independent validation of the implementation.

I would treat “verifiable” as a procurement requirement to investigate. Buyers should ask what evidence they can inspect, what component that evidence covers and what happens when the configuration changes. A useful assurance must connect the promised protection to the system actually processing the request.

The product diagram also places Private Inference within OpenAI’s environment. It should not be read as an announcement of an on-premises model or a customer-hosted deployment.

Agent Boundaries Address What AI Can Do

OpenAI’s product page identifies four boundaries customers can set before agents act:

• Data access: which information the agent can reach.
• Available tools: which connected capabilities it can use.
• Permitted actions: which operations it may perform.
• Required approvals: when it must obtain authorization.

These controls address a different failure mode from retention or protected inference. An agent could process a request privately and still cause trouble if it has excessive permission to change records, publish information or invoke another service.

Consider a hypothetical finance workflow. An organization might let an agent read approved invoices and prepare payment instructions, while requiring a person to authorize the payment itself. That example illustrates how the four boundaries can divide access from action; it is not a claim that OpenAI has shipped that exact workflow.

OpenAI’s product-specific page says enterprise customers can choose app connections, control supported actions and set automation permissions. It also describes identity and access features, including single sign-on, automated provisioning and role-based controls for Enterprise capabilities.

I would evaluate these permissions alongside the privacy settings from the start. Sensitive information can leave an intended boundary through an authorized tool call, even when the model’s own processing protections work as described. Organizations should therefore check the permissions and data handling of connected systems separately.

What Regulated Buyers Should Verify

OpenAI’s product page references SOC 2 Type 2 audits, ISO certifications, HIPAA support through Business Associate Agreements for eligible services, and FedRAMP support for designated government offerings.

The scope qualifiers are important. HIPAA support is tied to eligible services and a BAA. FedRAMP support is tied to designated government offerings. Neither statement makes every Private Intelligence configuration suitable for every regulated workload.

A healthcare organization, for example, needs to confirm that the particular service processing its information falls within its agreement. A government buyer needs to identify the designated offering that carries the relevant support. The umbrella product name cannot answer those questions by itself.

A practical evaluation should keep four records separate:

1. Service scope: the exact product, model, endpoint and connected systems in use.
2. Retention and access terms: the applicable ZDR eligibility and personnel-access commitments.
3. Runtime protections: whether Private Inference is available and what verification evidence accompanies it.
4. Action permissions: what agents can read, change or send, including approval requirements.

OpenAI has not published general pricing or universal eligibility on the pages examined here. Its interest form and sales prompts indicate a sales-led evaluation path. Buyers should also distinguish what can be contracted for deployment now from what remains dependent on the Private Inference preview.

The strongest practical implication of this launch is that privacy requires several separate decisions. Zero Data Retention, confidential-computing inference and agent permissions can complement one another, but none answers all the questions addressed by the others.