Private AI Inference Is One Boundary. Map the Rest of Your Business Data Path.

Private AI Inference Protects a Moment, Not an Entire Workflow

On October 30, OpenAI introduced Private Intelligence, grouping business-data controls with a Private Inference API preview. The announcement raises an important question for any company giving an AI coworker access to sensitive work: what happens to the information before and after the model processes it?

Imagine an operations Teammate preparing a response to a disputed invoice. It reads an account record, extracts an attachment, sends a relevant excerpt to a model, drafts a reply, stores a summary for tomorrow's follow-up, and hands an exception to a manager. A private model call could improve protection at one point in that journey. It would not decide whether the Teammate was allowed to read the attachment, whether the summary belongs in shared memory, or whether the manager's notification reveals too much.

OpenAI's product page distinguishes access restrictions, data ownership, permitted actions, and data security. It describes Zero Data Retention and Private Inference for eligible workflows and labels the latter an API preview. Those qualifiers matter. Do not assume a preview is available on every model, route, or account, or that a provider-side protection automatically covers your CRM, connector, application log, and exported report.

The practical approach is to draw the complete data path for one real business task. Mark where sensitive content enters, where it is copied, who can retrieve it, how long it stays, and what happens when a human takes over. Privacy is a property of the whole workflow, not a badge on its most technically interesting component.

Four Different Protections Answer Four Different Questions

The privacy conversation often collapses distinct controls into one reassuring phrase: “our AI is private.” That phrase is not a specification. A business owner needs to know what each protection changes and where it stops.

Access: what may the coworker retrieve?

A connected account can have permission to read a complete customer record. The current job may require only an invoice number, payment status, and the last customer message. The difference between can read and needs for this task is the first boundary.

Enforce access as close to the source as possible. Give the Teammate a role appropriate to the job, narrow the connector's query, and check the requesting user's own access where the task is performed on their behalf. An instruction saying “ignore unrelated fields” does not undo a broad retrieval. We covered the distinction between source-level authorization and side doors in AI coworker data access controls; this article follows the permitted data after it leaves the source.

Processing: who can access content while the model works?

Encryption in transit protects information on the way between systems. Confidential computing is aimed at protecting information during computation in a defined execution environment. OpenAI describes Private Inference as an API preview combining confidential computing with verifiable controls, but its public overview does not give every customer a complete supported-workflow matrix. Treat that as a question to verify with a provider, not a reason to claim universal protection.

Processing protection does not remove the need to limit the request itself. If a coworker sends a full personnel file to answer a question about one date, the model may process more data than the task warrants, even if the processing environment has strong controls. Minimize the payload first; then evaluate the protections on the selected route.

Retention: what survives the response?

Retention is a separate issue from access during processing. A provider's eligible Zero Data Retention setting concerns what that provider keeps under the applicable arrangement. OpenAI's Private Safety Processing guide describes a specific arrangement for selected safety-review records in customer-controlled storage; that is not the same thing as claiming every request vanishes everywhere. A provider setting does not delete your own request logs, connector traces, local files, chat transcript, memory entries, or third-party analytics. Nor should “zero retention” be treated as a universal property of every endpoint or service you connect.

Ask for a retention schedule by surface: original document, extracted text, model request, model response, human approval packet, operational log, and long-term memory. Some records must remain for audit or customer service; others should never be stored. The aim is deliberate retention, not deleting evidence that the business needs to explain a consequential decision.

Actions: what may happen with the answer?

Even a perfectly protected request can produce a risky action. A model might draft a refund, but the system should decide whether it may actually issue one. Separate reading and drafting from sending and changing records. Require a named human when the amount, customer impact, or uncertainty crosses a threshold.

OpenAI's October announcement lists available tools, permitted actions, and required approvals as controls businesses can set. These are not interchangeable with privacy during inference. The protection around an answer and the authority to act on that answer belong at different seams. Approval workflows are useful when the reviewer sees the evidence, proposed change, and consequence—not merely a button labeled approve.

Follow One Invoice Through the Whole AI Coworker Data Path

A data-flow diagram becomes useful when it follows a specific customer case rather than generic boxes marked “secure.” Take a service company that receives a disputed invoice by email. The operations Teammate is asked to prepare the facts for a manager, not to decide the dispute or send a final answer.

At intake, the email may contain an invoice PDF, an address, bank details, and unrelated personal notes. A connector reads the message and extracts text. A tool looks up the invoice in the accounting system. A model compares the two records and proposes a short summary. The Teammate saves a case note and notifies the manager. The manager checks the original evidence and decides whether to correct the invoice.

At every hop, ask a different question. Inbox: which mailbox and messages can the Teammate read? Extraction: where does the PDF text get stored? Lookup: does it retrieve the correct customer's record? Inference: which provider route handles the excerpt, and what controls actually apply there? Case note: does it contain unnecessary bank details? Notification: could another channel member see the customer's dispute? Decision: who may edit the invoice, and how is the correction recorded?

What bad looks like: the team enables a private-processing option, then gives the Teammate full mailbox and accounting access. Every attachment is copied into a persistent shared workspace. The manager gets a chat message containing the entire extracted invoice and bank account. The protected model request is real; the business's claim that the workflow is private is not.

What good looks like: the Teammate reads a dedicated disputes queue, retrieves the single invoice by verified identifier, and passes only the necessary disputed lines and payment status into the model call. The temporary extraction has a documented deletion window. The case note includes a source link and issue category but omits account numbers. The manager receives a private handoff with enough evidence to inspect the original, while the Teammate has no authority to change a ledger or promise a refund.

This is purpose limitation made operational. It also makes mistakes easier to investigate. If the summary cites the wrong invoice, the owner can inspect the source reference and pause the workflow without searching through a giant, unrestricted pool of copied customer data. For the earlier question of whether a field should be used for a given job, see our customer-data purpose limits guide.

The October Private Intelligence announcement is a useful prompt to review this diagram precisely because it discusses several protections together. The danger is reading a combined product description as though each protection covered every surface of your own business process. A boundary diagram turns broad assurances into testable questions.

A Seven-Step Privacy Review Before Sensitive Work Goes Live

Do this with one workflow that handles real customer or employee information. A spreadsheet is enough to start. Assign an owner who can approve the data use and someone who can inspect the technical route; these may be the same person in a small company, but the responsibilities must be explicit.

1. Define the job and the forbidden jobs. Write the exact outcome: “prepare the disputed invoice packet for review.” State that the Teammate cannot issue a refund, change an account, or use the customer's financial details for another purpose. This is the intent boundary against which every later permission is checked.
2. List the fields genuinely required. Ask the human process owner to identify the smallest set of facts needed for a correct packet. Separate required fields from convenient context. If a source system only offers a broad record, add a filtering step before sending information to the model.
3. Trace every copy. Record inbox, connector, extraction, temporary workspace, model request, response, memory, audit log, notification, and human review destination. Include retries and error logs; these are common places where supposedly temporary payloads become durable.
4. Verify the provider arrangement on the actual route. Check the model, endpoint, account eligibility, retention setting, processing location, and whether a preview feature applies to this exact workload. Keep the provider's documentation and your confirmation with the workflow record. A feature described on a marketing page is not evidence that it is enabled for your requests.
5. Set retention and deletion per surface. Choose a period based on the operational and legal need, with counsel involved where appropriate. Preserve an audit record of actions and approvals without automatically preserving every raw customer document in general-purpose memory. Test deletion from your own systems; do not infer it from a provider setting.
6. Test a normal case and an awkward case. Use synthetic or suitably protected records. In one case, verify that the right manager gets a packet with the minimum data. In another, include an unrelated sensitive field and a mismatched invoice identifier. The expected outcome is exclusion or escalation, not a confident summary of the wrong record.
7. Make drift visible. Recheck the route when a model, provider, connector, logging setting, business process, or permission changes. Record who accepted the change and whether the same tests passed. When the task cannot be verified, the Teammate should retain safe preparation work and hand the case to a person instead of sending or writing automatically.

This routine is intentionally smaller than a full enterprise privacy program. It gives a business a repeatable decision: which specific facts are needed, what protections apply to them today, and which person takes over when the boundary is unclear. A better model or stronger inference protection can improve one part of the answer; neither can substitute for owning the path.

FAQ

Q: Does private AI inference mean my business data never leaves my systems?
A: No. If you send a request to a provider, relevant data still travels to that provider's service unless your actual architecture says otherwise. Private inference concerns protection during a defined processing stage. Verify the route, eligibility, and scope of the protection before making a data-location claim.

Q: Is Zero Data Retention the same as confidential computing?
A: No. Retention controls address what is kept after processing under a particular arrangement. Confidential computing addresses protection during computation in a defined environment. Neither automatically governs your CRM, application logs, or Teammate memory.

Q: Can an AI coworker remember a customer dispute without keeping the whole file?
A: Yes. Store the minimum useful case state: case identifier, issue category, source reference, next owner, deadline, and approved status. Keep the original document in its governed source system, with access checked when it is needed again. Do not copy sensitive fields into shared memory merely to save a lookup.

Q: What should a small business ask its model provider about a privacy preview?
A: Ask which models and endpoints qualify, how access is enabled, what retention policy applies, what processing protections cover, what evidence you can inspect, and what changes when a request uses a reseller or alternate route. Get answers for your actual configuration rather than assuming all traffic inherits a headline feature.

Q: Who approves a new data use for an existing Teammate?
A: The business owner of that process should authorize the purpose, required fields, retention period, and consequential actions. A technical owner should implement and test the restrictions. If a new use changes what customers were told or what law requires, seek appropriate privacy or legal review before deploying it.

If you're ready to give AI coworkers useful context without handing them an unrestricted copy of your business, Associates AI Teammates gives you persistent agent servers, configurable Skills, and clear operating boundaries. View pricing and get started with a team you can govern as the work changes.