Key facts
| Subprocessor list | Published with change notification and objection rights |
| Fourth parties | Upstream model providers and inference hosts sit behind the platform |
| Locations | Region pinning and deployment tiers constrain where processing occurs |
| Flow-down terms | Security, privacy and training-use restrictions must reach subprocessors |
| Concentration | Multiple models sharing one upstream creates correlated outage risk |
| Audit | Key/admin events and per-request logs with region attribution |
| Exit path | Export formats, deletion evidence and transition assistance are negotiable |
| Compliance posture | SOC 2 Type II and ISO 27001 readiness in progress (not yet certified) |
TL;DR
- Inventory fourth parties, not just the vendor you contract with.
- Map locations to your residency commitments and verify they match.
- Check that privacy and training-use terms flow down the chain.
- Concentration risk is availability risk: map shared upstreams.
- Write the exit path for each dependency before you need it.
How it works, step by step
- List every party that can touch your data, including upstream model providers.
- Map each party's role and processing location against your residency rules.
- Confirm security, privacy and training-use terms flow down contractually.
- Identify concentration points where one upstream serves many of your models.
- Verify change notification and objection rights for new subprocessors.
- Test the exit path: can you move workloads and get deletion evidence?
- Review the inventory quarterly and after every material platform change.
Try it yourself
Open the sovereign AI readiness score →
Who counts as a subprocessor in AI
- Infrastructure: cloud providers hosting inference, storage, logging and backups.
- Model providers: upstream parties serving the weights your requests reach — often invisible in a classic vendor review.
- Serving and routing: inference hosts and gateways that process prompts in transit.
- Support and observability: ticketing, monitoring and support tooling that may capture request metadata.
- Specialist services: transcription, moderation or embedding providers if your workflows call them.
The critical insight is that your vendor's subprocessor list is not the same as your data-flow map. Build the map yourself, from your architecture, then reconcile it with the published list.
Locations, transfers and residency
Residency commitments are only as strong as the weakest location in the chain. For each subprocessor, record where it processes data, under what legal mechanism and whether your deployment tier removes it from the path. Region-pinned deployment should keep in-scope processing inside the region; VPC, on-prem and air-gapped tiers remove external subprocessors from the inference path entirely, which is often the cleanest way to eliminate a problematic dependency rather than negotiate around it. Verify the actual configuration instead of relying on the vendor's default.
Flow-down, concentration and exit
Three reviews separate a real programme from a spreadsheet. Flow-down: confirm that security, privacy, retention and training-use restrictions apply to subprocessors, not just to your direct vendor. Concentration: map which of your models depend on the same upstream — one provider outage or policy change can hit several workloads at once, so plan fallback models and test failover during a pilot. Exit: for each dependency, ask how you would move, what format the data leaves in, how deletion is evidenced and what assistance is contractually available. Reference /legal/terms and /legal/sla for the enforceable positions, and keep the inventory current — it changes whenever the model catalogue changes.
Evidence for the vendor file
- Your own data-flow map reconciled with the published subprocessor list.
- Locations and transfer mechanisms per subprocessor.
- Flow-down clauses in the DPA and terms.
- Concentration analysis with fallback plans and test results.
- Change-notification records and objections raised.
- Exit plan with formats, timelines and deletion evidence.
Record that Plugsky's SOC 2 Type II and ISO 27001 status is readiness in progress rather than completed certification, and that upstream model providers may be subprocessors for your workloads. Neither point is unusual in AI procurement, but both belong in the risk register with owners and review dates.
Honest comparison
| Risk area | Plugsky | Global API aggregator | Self-hosted stack |
|---|---|---|---|
| Subprocessor list | Published with change notification | Varies by vendor | You contract each one |
| Fourth-party visibility | Model catalogue and deployment docs | Opaque upstream routing | Fully visible |
| Location control | Region pinning plus VPC/on-prem tiers | Provider routing | Your facilities |
| Flow-down terms | DPA and terms define the frame | Varies | You negotiate each contract |
| Concentration | Fallback models and automatic failover | Shared upstream exposure | Your design |
| Exit | Export and deletion on termination | Varies | Your procedures |
Frequently asked questions
What is an AI subprocessor?
Any party that processes your data on behalf of your vendor — cloud infrastructure, upstream model providers, inference hosts and support tooling. In AI, upstream model providers are fourth parties that classic SaaS reviews often miss.
How do I get the subprocessor list?
The DPA includes a published subprocessor list with change notification and objection rights. Reconcile it with your own data-flow map rather than relying on it alone.
What is concentration risk in AI?
When several models or workloads depend on the same upstream provider, one outage or policy change affects all of them. Map shared dependencies, define fallback models and test failover.
Can we object to a new subprocessor?
The DPA documents change notification and objection rights. Define internally who reviews notices, against what criteria, and how quickly, so the right is exercised rather than theoretical.
How does residency interact with subprocessors?
Every location in the chain must satisfy the commitment. In-region processing elsewhere in the chain breaks it, and VPC, on-prem or air-gapped deployment removes external parties from the inference path entirely.
What evidence should we keep?
Your data-flow map, subprocessor locations, flow-down clauses, concentration analysis, change notices, objection records and the tested exit plan.
What is Plugsky's certification status?
SOC 2 Type II and ISO 27001 are documented as readiness in progress rather than completed certification. Track that as a risk item and verify current evidence with the enterprise team.
How do we test the exit path?
Run a pilot migration of one workload: export data, verify formats, delete from the source, and obtain evidence. A plan you have exercised is worth more than one you have written.