A DPA is not a sub-processor list

Two documents decide whether a European buyer can audit an AI vendor's data path, and procurement teams routinely treat them as one. A data processing agreement sets the rules. A sub-processor list names the companies those rules have to reach. Of the 83 vendor records in this registry, 69 publish a DPA, and 13 publish nothing that identifies where their sub-processors sit. The contract is close to universal. The roster is not.

The DPA is a rulebook, not a roster

A DPA is the contract between you, as controller, and the vendor, as processor. It fixes the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subject. It then binds the vendor on the things you cannot check from outside: confidentiality, security measures, assistance with data subject requests, deletion or return of the data when the contract ends, and your right to audit.

It also governs the chain. Under the GDPR a processor may not engage another processor without your written authorisation, and where that authorisation is general rather than specific, the processor owes you notice of intended changes and an opportunity to object. The DPA is where that mechanism is written down. It is not where the names are.

The grades show how little the contract on its own separates vendors.

A published DPA puts a vendor on the registry median of 56. It is a floor, not a distinguishing feature. The eight records with no published DPA sit well below it, at a median of 42: Replicate is the clearest case, with no DPA, no sub-processor list, no trust centre, and a privacy policy that names categories of service provider but not one company. The five records where a DPA is structurally not applicable are the highest scoring group in the registry, at a median of 95, and that is not a paradox. Whisper, self-hosted, Continue and Nextcloud's Assistant have no processor to contract with, because nothing leaves the operator's own hardware. One further record has no value recorded for this field.

The sub-processor list is the roster

A sub-processor list is disclosure, not a legal instrument. It is how the notice half of general authorisation gets delivered in practice, and it is the only routine way to learn which companies actually touch your prompts, your recordings or your code.

A useful list does four things, and the registry has a clean example of each:

• Names the legal entity, not the brand. Berget AI lists every sub-processor in an appendix to its DPA with the company name, its Swedish organisation number and the service it provides. The only non-Swedish entry is Stripe's Irish entity, for card payments.
• States the processing activity. Amberscript names human transcribers, working under non-disclosure and data-processing agreements with no download rights, as part of its chain. That is the sort of entry a category label hides.
• States the processing location. Otter.ai publishes each entity, the activity it performs and its country, with an effective date and a commitment to notify account owners of changes.
• Names the transfer safeguard per entry. Nscale marks EEA colocation operators as needing none and tags each non-EEA entry with the instrument it relies on, so the transfer analysis is done row by row rather than left to the buyer.

General authorisation is the default, specific authorisation is a choice

General authorisation is the norm here, and it is the model every US vendor in the registry uses: publish a list, give notice before changing it, allow an objection. Exoscale writes the stricter version into its DPA and appoints no sub-processor at all unless the customer authorises it first, with a right to terminate if the customer objects.

The clause and the roster are separable, which is worth checking rather than assuming. Poolside has a DPA that defines an authorised sub-processor approval mechanism and publishes no roster to go with it. The mechanism is real, and there is nothing to run it against.

Disclosure and structure are different variables

Where the chain sits and whether the vendor will say are recorded separately, and the methodology scores them as separate inputs.

Two things in that table are worth separating. A fully disclosed American chain has a median of 52, which is a mediocre result for a European buyer but an assessable one: you know the entities, you know the jurisdiction, and you can price the risk. An undisclosed chain has a median of 34, and 11 of the 13 undisclosed records fall in the registry's low band. The A band contains none of them.

When the roster is missing

Missing disclosure is rarely a refusal, and it is not evidence of bad practice. It is absence of evidence, which for a regulated buyer produces the same procurement answer.

• Gladia is a French vendor with a French default region and a real DPA. Its compliance hub says a maintained list of sub-processors, purposes and locations exists, and is available on request.
• Augment Code holds an independent security attestation and an AI management system certification, which almost nobody in its category has, and directs anyone asking about sub-processors to contact the company.
• Windsurf has a sub-processors URL that resolves and returns a page whose body says the page does not exist.
• Qodo publishes a trust centre that refused every automated path tried during this pass.

Each of those vendors publishes a stated position on training. None of them lets you see who would be bound by it.

Read the scope before you read the names

A published list covers what the vendor says it covers, and that is often not the inference path.

• Exoscale's list is corporate functions only: billing, payments, telephony, marketing. None of it sits in the customer data path.
• GitLab's published list applies to the GitLab-managed AI gateway. Run your own gateway and your own models, and there is nothing in the inference path for that list to describe.
• Speechmatics publishes its full processor and sub-processor list inline in its privacy policy rather than on a separate page, and the on-premises product it sells has none of those entities in the audio path.
• Fireworks AI publishes its list, with processing locations, inside a schedule of its public DPA, where a buyer who only looked for a sub-processors page would miss it.

The corollary matters for the good cases as much as the bad ones. Otter's page is the strongest in its category, and what it discloses is that the entire supply chain is American. That is a service to the buyer, not a mark against the vendor. A vendor that publishes a bad answer has told you something. A vendor that publishes nothing has told you only that the assessment cannot be completed.

What to check in your own stack

For each AI vendor already in production:

• Hold both documents. The DPA and the sub-processor list are separate artefacts. A trust centre badge is neither.
• Check the fields. Every entry should carry a legal entity, an activity and a processing location. Brand names without locations do not let you finish a transfer assessment.
• Check the scope. Confirm the list covers the AI path rather than corporate functions, and that the model providers appear on it at all.
• Read the authorisation clause. If authorisation is general, find out what notice you get and what happens when you object, then route that notice to somebody who will read it.
• Ask in writing where the list is missing, before renewal. A list on request is worth something. A list that never arrives is a finding you can record.
• For self-hosted and on-premises deployments, confirm what the published list applies to. It usually describes the vendor's hosted product, not your deployment.

This article was researched and written by an automated pipeline from the Sovereign AI Registry's own data, then published without human review. Every figure is computed from the registry's live records. Corrections: open an issue.