OpenAI outlines Private Intelligence with a fall inference preview

OpenAI’s September 29 DevDay announcement introduced Private Intelligence and put a Private Inference preview on the calendar for this fall. The announcement also highlighted Zero Data Retention with Private Safety Processing, which has a more detailed operating guide.

For businesses evaluating the package, the important distinctions are where records are stored, who can decrypt them and which processing stages are protected. A privacy label by itself does not answer all three questions.

Safety records remain in customer storage

The Private Safety Processing guide describes a system that encrypts selected prompts and responses for automated safety review and writes them into storage controlled by the customer. OpenAI keeps operational metadata and a reference to the stored record rather than its own content copy.

Customers can connect AWS S3, Azure Blob Storage or Google Cloud Storage. They must retain encrypted records for at least 30 days and maintain the required storage permissions and key access. The review runtime is designed to decrypt content without human access and release limited safety signals.

That means the storage obligation continues even when OpenAI does not retain the content itself. A business adopting the service needs someone responsible for the storage lifecycle, access configuration and response to safety notices.

The whitepaper draws a narrower security boundary

The linked technical whitepaper was published on September 22, before DevDay. It explains that standard Private Safety Processing protects the safety review runtime from human access, while its inference path does not provide an inference wide guarantee of zero operator access.

The paper describes Private Inference as an additional protection for eligible workloads. It explicitly says that the protection does not automatically extend to the initial API request or every OpenAI system. Its scope also excludes Amazon Bedrock and other outside distribution arrangements.

Another stated limitation concerns repeated reviews. The paper says the system does not currently cap the total information disclosed across repeated reviews of the same content, and identifies cumulative disclosure protections as future work.

These boundaries matter when a procurement team turns a product description into requirements. A claim about one protected safety component should remain attached to that component, rather than becoming a blanket claim about every stage of an application.

Access and key management require planning

The operating guide says organizations already approved for Zero Data Retention can configure Private Safety Processing in the API console. The setting applies to an entire project. Requests that should use ordinary eligible Zero Data Retention instead need a separate project.

OpenAI’s Enterprise Key Management overview explains the use of customer managed keys in external cloud services. Its technical FAQ distinguishes rotation from revocation and warns against testing revocation in production because existing information can become inaccessible.

Security controls therefore need an operational plan as well as an approval. The organization should establish who owns the key service, who responds if storage validation fails and how a proposed configuration change will be tested safely.

What buyers should verify next

Our earlier coverage of OpenAI’s Daybreak rollout examined access to specialized security models. Private Intelligence adds a separate set of questions about the handling of customer information.

For now, buyers can examine the documented safety processing controls and their own implementation requirements. They should treat the fall Private Inference preview as a forthcoming milestone, then verify its actual scope, eligibility and availability when that preview arrives.

Private Safety Processing documentation artwork from OpenAI.