A safety processing announcement changes the diligence conversation
OpenAI’s September 22 update says it is rolling out Private Safety Processing to API customers in phases. The company describes a system intended to identify patterns across related interactions while remaining compatible with Zero Data Retention, using automated processing and limited safety signals rather than exposing underlying prompts to its personnel. The provider’s published exceptions and account terms still apply. This is the provider’s design description and rollout statement, not a guarantee that a customer is eligible or that every integration has the same settings.
The distinction matters for an organization that treats “zero retention” as a simple yes-or-no checkbox. The data lifecycle can include request content, tool output, system logs, provider-generated safety signals, and records kept by the customer. Ask which of those move, where they are stored, who can access them, and what happens after a warning or enforcement action.
Map the data path, not just the model endpoint
For each workflow, list the information that leaves your environment: prompt, retrieved material, attachments, tool results, identifiers, and generated output. Record the storage location, retention period, encryption arrangement, and access controls for every part. If the provider describes an option using customer-controlled keys, verify how keys are provisioned, rotated, and revoked in the specific deployment. Do not assume the account has a feature because a public announcement says access is expanding.
Ask the provider for the applicable contract, current product documentation, eligibility conditions, and configuration steps. Capture the version of the documentation and the person who confirmed the setting. A public blog post is useful for understanding design intent but may not define your organization’s actual service terms, exceptions, or current availability.
Treat alerts as a separate information class
A narrow safety signal may be less revealing than the original content, but it can still be sensitive. Define who receives it, what the signal contains, whether it identifies a user or workflow, and how long your team retains it. Establish a review path for legitimate activity that is flagged. Confirm whether staff can investigate using customer-side records and what information would be shared if an appeal is filed.
Exercise the workflow with harmless test prompts and verify the end-to-end behavior: ordinary work, a simulated alert, a blocked action, and a human review. Check whether the user is told what happened and whether the record is available to the right internal owner. Never use sensitive customer content as a test fixture unless the approved data process explicitly allows it.
Keep the assurance statement narrow and current
Document the precise service configuration and the statement your organization is prepared to make about it. “The provider announced a privacy-preserving design” is different from “this workflow meets our retention requirements.” Confirm the latter against the active contract, product settings, data map, and security review. Recheck when the provider changes the rollout, terms, supported models, or data path.
The immediate next step is to ask the provider which configuration applies to your account and what the safety process records. Then update the data map and confirm the alert owner before using the workflow with sensitive information. This turns a broad product announcement into a specific, reviewable decision. Record who is authorized to accept a provider configuration change and how that change will be reviewed. A new processing feature can alter the data map even when the business task stays the same. The change owner should confirm the setting and capture the provider’s current documentation before sensitive use resumes.