In this analysis
Private visibility and zero retention are separate attributes: the upstream provider’s data policy remains relevant after a deployment is hidden from public listings.
A private endpoint controls how a deployment is exposed through OpenRouter. Zero data retention concerns what happens to request data after processing. The October feature explicitly separates those properties, so a team cannot infer a provider’s retention behavior from the absence of its endpoint in public listings.
Read the privacy statement directly
The October 14, 2026 announcement says private status does not make an endpoint zero-retention. The deployment’s provider continues handling prompts under its existing behavior, while OpenRouter records the declared data policy.
The causal distinction is between discovery and processing. Hiding a route from public search changes who encounters it. It does not, by itself, change the upstream operator’s data lifecycle. Both controls can be useful without one supplying evidence for the other.
Earlier governance separated identity from selection
Workspaces on April 22, 2026 introduced a scoped operating context for keys and policy. Auto Exacto on March 12 addressed automatic provider selection. These are earlier examples of different controls around one model call.
Private Endpoints adds another layer: organization-specific deployment visibility. Our interpretation is that expanding enterprise routing creates more independent policy dimensions, making explicit separation more important rather than reducing them to one private label.
Follow the request beyond the catalog
An organization may use a dedicated deployment without presenting it in public model lists. Its request still travels through a gateway and reaches an upstream provider. The privacy question follows that execution path, including whichever participant handles the data.
The feature is an Enterprise add-on for customer deployments. It should not be described as a universal requirement for inference-provider onboarding or proof that arbitrary self-hosted hardware can be connected through it.
Keep a policy record with separate fields
An illustrative record can preserve the relevant dimensions:
| Field | Question |
|---|---|
| Visibility | Where is the deployment discoverable? |
| Routing eligibility | Which organization and workspace configuration can use it? |
| Retention | What data handling does the upstream deployment declare? |
| Location | Where does the request actually execute? |
A single “private” checkbox cannot answer every row. The setup test also sends a real request according to the announcement, so test data belongs within the applicable processing policy rather than outside the privacy review.
Make the conclusion about the actual deployment
The historical change is that a private customer deployment can join the same routing surface as public options. Its visibility and retention remain separate attributes, which is precisely why the feature can be useful without changing every upstream policy.
Privacy and retention explains the data-policy boundary. Provider routing explains eligibility and selection. Together they support a concrete interpretation: private discovery changes route exposure, while data handling still needs its own declared and applicable evidence.