Which model host can see your customer's documents?

Sooner or later a customer's data protection officer sends you one question: when your product reads our policies, contracts and supplier files, who else sees them? If your answer is "we use an LLM provider", the deal slows down. The answer they need names every company in the chain, where it runs, how long it keeps the text, and which contract covers it. This guide shows how to get to that answer, and how we hold ourselves to it before a feature that reads documents reaches a customer.

Start with your role

In most compliance products your customer is the controller of the documents it uploads, and you process them on its instructions. That makes you a processor, and every company you engage to handle those documents a sub-processor, working on your customer's behalf. If you also use the documents for your own purposes, for example to improve your models, you become a controller for that processing, and the rest of this guide changes. Decide which one you are, and write it in your data processing agreement.

The chain is longer than you think

A document your product sends to a model usually crosses three companies. Your own hosting receives it. A router may receive it next, if you use one to reach several models through one API (OpenRouter is the common case). Then an inference host runs the model and sees the full text. With open-weights models the host is often not the company that trained the model: one model can be served by several hosts in several countries, and the router may pick a different one on each request unless you tell it not to.

Each of them that can see the text is a sub-processor. Policies and supplier contracts are full of personal data: a company name alone is not, but the signatories, approvers and named contacts behind it are, even in a purely professional capacity.

Four records per host

It is on your sub-processor list, with its location, its role and the transfer mechanism. If your customers give you a general written authorization for that list in your DPA (GDPR Art. 28(2)), adding a host that is not on it means telling them in advance so they can object, within the notice period your DPA sets. Under Art. 28(4) you stay fully liable to your customer for each host's performance.

You know which contract binds it, and you can produce it. That is either your own agreement with the host, or the router's agreement that imposes the same Art. 28(3) obligations on it. Read it for those obligations: documented instructions, confidentiality, security, help with data subject requests and breaches, deletion at the end of the service, audit rights. Ask for its ISO 27001 certificate or SOC 2 report too; customer DPOs often ask for those before the contract text. If the host is outside the EEA, check the transfer basis: an adequacy decision first (for a US host, whether it is certified under the EU-US Data Privacy Framework), otherwise the 2021 Standard Contractual Clauses (Module 3 between processors), with a transfer impact assessment either way for the SCCs.

You know its retention and training posture, and where it comes from. Zero data retention (ZDR) means the host keeps no copy of the prompt or the answer after serving it. Check whether that comes from a contract, from an account setting on the router, or from a flag in each request. All three are useful; they are not the same evidence, and an auditor will ask for the clause. The same goes for "no training on your data". Zero retention is also one of the supplementary measures your transfer impact assessment can cite.

It is reflected in your records of processing activities (GDPR Art. 30(2) for a processor, including any transfer outside the EEA and its safeguard), so the records, the sub-processor list and the contracts tell the same story.

Pin the route, then prove the pin

Most routers choose a host for you, and fall back to another one when the first is busy. That is good for uptime and bad for the four records above: a fallback to a host you never put on your list is processing by an unauthorized sub-processor, not just untidy logging. Three settings close that gap on a router such as OpenRouter: pin the providers you have checked, turn fallbacks to other providers off, and send the data controls in every request (no data collection for training, zero-retention endpoints only), so a request that cannot be served under those terms fails instead of going elsewhere.

Then prove the pin where it matters, in production. Your configuration says what you meant; the provider named in the response or in your own call log says what happened. Record which one you checked, and when.

How we do it before a feature reaches customers

This week we switched document review on in ISMS Copilot for our own test account only, ahead of customers: you upload a policy, a model reviews it, and any finding that does not quote your document word for word is dropped. It sends the whole text of a document to a model, so it passes two gates before it reaches any customer account. The first runs on the exact release commit: every model host configured for the review route must already be in our DPA's sub-processor section, our records of processing and our DPA inventory, or the release stops and the question goes to the CEO. The second asks, for each host that will receive customer documents, which agreement covers it and whether we can produce it on request. The review models are pinned to one host whose data processing addendum is in our files, the first model call in production was logged as served by that host, and changing a route means running the first gate again.

We drafted that gate with Claude and asked ISMS Copilot to review it like an auditor would. It challenged one line: a recorded risk decision documents why a gap is accepted, but it is not a contract and not a transfer safeguard. That distinction is now written into the gate.

If your customers need EU-only processing

Some customers will not accept any transfer outside the EU for this kind of content (we wrote about what that question looks like for an audit consultant). The clean answer is an EU-headquartered provider on an endpoint whose EU processing commitment is in the contract, not only on a web page, with zero retention. One trap: a provider can be based in the EU while its default endpoint makes no commitment on where inference runs. Mistral, for example, has a global endpoint and an EU-bound one (api.eu.mistral.ai); only the second is an EU processing answer. Point your code at the endpoint whose region you can put in writing, and fail loudly if someone changes it.

And send less. Where the task allows it, strip or replace names before a document leaves your system (pseudonymisation, GDPR Art. 25 and Art. 32). It is often the cheapest way to make a transfer easier to defend.

What the ISMS Copilot API does for you

We built the ISMS Copilot API for teams who want compliance-grade answers in their own product without rebuilding this chain (how compliance platforms use it). You choose the processing path by the model name you call:

• EU mode (isms-fast-eu, isms-thinking-eu): processed by Mistral AI on its EU-bound inference host, under our commercial zero data retention agreement with Mistral, with no transfer of model processing outside the EEA.
• Global mode (isms-fast, isms-thinking, isms-mini): routed through OpenRouter to a closed set of inference hosts, with zero data retention and no training.

Every successful response carries an x-isms-processing-region header (eu or global), so you can log and alert on the processing mode of each request (how zero retention works on the API). The API sub-processor list and the API data processing agreement are public on our trust center, so you can copy the facts you need into your own list instead of asking us. Eligible new API accounts get free credit while the offer runs.

A short checklist

1. State your role: processor for your customers, or controller for anything you do with their documents for yourself.
2. Draw the chain for each feature that sends documents to a model: your hosting, the router, every host the router can pick.
3. For each host, find the four records: on your list, the contract that binds it (with its transfer basis), its retention and training posture with the source, in your records of processing.
4. Pin the hosts you have checked, turn router fallbacks off, send the data controls in every request, and read the pin back in production.
5. Offer an EU-only path on an EU-bound endpoint for the customers who need it, make the path visible per request, and send less personal data where you can.

If you build with Claude, a good first pass is to ask Claude x ISMS Copilot: Claude reads your code and drafts the sub-processor list, then ISMS Copilot reviews it and challenges it like an auditor would. You decide what goes on the list.