AI Subprocessor Checklist: Mapping Who Touches Your Data

AI adds subprocessors that most organisations have not mapped. This checklist covers the chain, drawn from FISTA Solutions' AI enablement governance work. This is general guidance, not legal advice.

Who is in the chain?

Six roles, each of which may see your data.

Role	What they process
Your direct vendor	Everything you send
Their model provider	Prompts and outputs
Inference host	Same, at the infrastructure layer
Vector or storage provider	Embedded content
Observability tooling	Logs including prompts
Human review services	Sampled interactions

Mapping

Build the list before assessing anything.

• Direct vendors listed per AI system
• Each vendor's subprocessors obtained in writing
• Model providers identified by name
• Inference hosting arrangements identified
• Storage and vector providers identified
• Observability and logging tools that see prompts identified
• Any human review arrangements identified

Terms and flow-down

Terms that stop at the first hop do not cover the processing.

• Data protection terms confirmed with each direct vendor
• Flow-down obligations confirmed to subprocessors
• Training use restrictions flow down
• Retention terms flow down
• Security obligations flow down
• Audit rights flow down or are otherwise satisfied
• Liability allocation understood across the chain

Change notification

The chain changes without your involvement unless you contract for notice.

• Notification obligation for new subprocessors agreed
• Notice period sufficient to assess and object
• Right to object documented with consequences
• Notification channel confirmed and monitored
• Someone named to receive and assess notifications
• Process defined for assessing a proposed change
• Historical changes reviewed for anything missed

Locations and transfers

Where processing happens affects what is required.

• Processing location per subprocessor documented
• Storage location documented separately from processing
• Cross-border transfer mechanisms confirmed
• Region-restricted options identified where available
• Regional commitments actually enforced, not just offered
• Failover locations included in the assessment
• Legal confirmation on transfer adequacy

Your own disclosures

Your commitments to customers may require updating.

• Your customer-facing subprocessor list reviewed
• New AI subprocessors added where required
• Your privacy notice updated if processing changed
• Customer notification obligations checked
• Contractual commitments to customers checked for conflicts
• Sales and security questionnaire answers updated
• A process defined for keeping the list current

Ongoing management

The map decays unless it is maintained.

• Chain reviewed at least annually
• Review triggered by vendor notifications
• Review triggered by adding a new AI system
• Records kept of each review with dates
• Owner named for the subprocessor register
• Register accessible to security, legal, and procurement
• Exit implications of each subprocessor understood

What are the most common failures?

Mapping only the direct vendor. Assuming model providers are infrastructure rather than processors. No notification rights. Ignoring observability tools that log prompts. And a register built once and never updated.

Who should own this?

Procurement maintains the register; legal assesses the terms; security assesses the posture. Without a named register owner it goes stale within a year.

How often should it run?

Annually, plus on every vendor notification and every new AI system. Re-check whenever a vendor announces a model change, since that may change the provider.

What evidence should it produce?

The current subprocessor register per system, written confirmations from vendors, transfer mechanism documentation, and dated review records.

What if a vendor will not disclose their chain?

That is itself a finding. A vendor unable or unwilling to name their subprocessors has either not assessed their own chain or does not want you to.

For systems processing personal data, it is usually grounds to decline or to escalate. Treat the refusal as information about their governance maturity. See AI third party risk checklist.

What should you do first?

Ask your main AI vendor for their current subprocessor list in writing. The response tells you how mature their governance is.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: the full subprocessor chain mapped past the direct vendor, with flow-down terms confirmed and notification rights secured before signature, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI third party risk checklist.