Before You Send Company Data to a Model, Check the Route

Say you are wiring an AI feature into a product. You pick a model by name, set the API key, and move on. That name settles less than it appears to.

On OpenRouter, the same model can be served by more than one provider, and those providers differ in whether they may log prompts. OpenRouter shows a data policy tag on model pages to indicate this, and it describes those tags as its best knowledge, not a definitive source of third-party policy. So a request routed under one model name can land on endpoints with different data handling. Checking the model is not the same as checking the route.

The documented controls

OpenRouter's provider routing accepts a data_collection setting of "allow" or "deny". The default is "allow", which permits providers that may log and train on user data. Setting it to "deny" restricts routing to providers that do not collect user data, per OpenRouter's own policy descriptions.

That field default alone does not establish effective routing, because account privacy settings can also filter providers. If account rules apply, they constrain what the request-level field does. Anyone relying on a request flag should confirm what the account layer is already doing.

OpenRouter also defines zero data retention (ZDR) as no provider storage of data, subject to a stated in-memory caching exception. A request can require ZDR with provider.zdr=true, documented in OpenRouter's ZDR documentation. Current account privacy settings support model-group scopes, and request settings cannot disable applicable account or guardrail enforcement. In other words, the stricter layer wins.

Three documented limits

These controls are narrower than their names suggest. Three limits come straight from the documentation.

First, scope. OpenRouter states that ZDR enforcement applies only to provider routing for inference requests. It does not apply to plugins and tools, which may have different policies. A request can satisfy ZDR at the inference step while a connected tool handles the same data under separate terms.

Second, caching. OpenRouter allows endpoints that use in-memory prompt caching under its ZDR policy, because it does not treat in-memory caching as data retention. If your definition of "no retention" excludes that behaviour, the documented definition and yours are not the same.

Third, ambiguity. When an endpoint's policy is unclear, OpenRouter assumes it retains and trains on data and marks it as non-ZDR. That is a conservative default, but it also means the label reflects OpenRouter's knowledge state, not a settled fact about the endpoint.

None of this makes the controls useless. It makes them bounded. I would treat routing flags as one part of a workflow data review, not as the whole review.

A bounded checklist

This is my recommendation, framed prospectively, not a description of any practice I have run. Other routers and providers have their own settings, and I make no claims about them here. For a workflow routed through OpenRouter, I would ask five questions before sending company data.

1. What is data_collection set to on this request: "allow", "deny", or unset? If unset, the documented default is "allow".

2. Do account privacy settings cover every model group this workflow can reach? Request settings cannot override account or guardrail enforcement, so the account layer needs to match the intent.

3. Does this request need ZDR, and if so, is provider.zdr=true set explicitly rather than assumed?

4. Which plugins and tools touch the same data? ZDR enforcement does not apply to them, so each one needs its own review.

5. Given the in-memory caching exception, does the documented ZDR definition match what the data actually requires? If not, routing controls alone may not be sufficient for that data.

Where any answer is unknown, I would document the answer before proceeding rather than assume the flag covers it.

The decision that matters

The model name is a starting point. The endpoint policy, the account layer, and the tools around the request decide where the data actually goes. None of the documented controls makes that decision for you, and none of them certifies a provider's conduct beyond what OpenRouter describes as best knowledge.

I am James Kouzinas, and I write about AI product and operations decisions at Nebula. My recommendation: before company data enters a routed request, write down the route, the settings, and the open questions. If the answers are not on paper, the review is not done.