AI Vendor Subprocessors: Who Else Handles Your Company Data?

AI vendor subprocessors are the other companies your AI provider uses to deliver its service, and that may store, process or see your data along the way. They include model hosts, cloud infrastructure, logging tools and support platforms. To find out who else handles your company data, ask each vendor for its current subprocessor list, what each entry does, where it operates, and how you will be told when the list changes. Get that answer into the contract, not only onto a web page.

Key takeaways

• A subprocessor is any third party your vendor engages to handle your data on its behalf. An AI service chain often has more of them than a conventional software product.
• Ask for the list in writing, with the purpose, data type and location of each entry, and confirm that it is current.
• A list is only useful if changes come with advance notice, a named channel and a right to object.
• Every new subprocessor needs a short, documented decision: accept, accept with limits, or object.
• Sharing less data upstream shrinks the problem. A shorter data path means fewer parties to review.

What is a subprocessor in an AI service chain?

Most data protection frameworks use three roles. You are usually the controller, the party that decides why and how your company data is used. Your AI vendor is the processor, handling that data on your instructions. When the vendor hires another company to do part of that work, that company is a subprocessor. Terminology differs between jurisdictions and contracts, and this article is not legal advice, but the shape of the chain is the same almost everywhere.

AI makes the chain longer for practical reasons. A single request from an AI agent can pass through a messaging channel, an orchestration layer, a model provider, a memory store and a monitoring tool. Each hop may be run by a different company. The vendor you signed with may operate only one or two of those hops itself.

The question for a business owner is not whether subprocessors exist. They almost always do, and using them is normal. The question is whether you can see them, whether you accepted them, and whether you will hear about changes before they take effect.

Who typically sits in the chain?

The exact stack depends on the vendor, but these are the categories worth looking for when you read a list:

• Model providers that run the language model which reads your prompts and documents.
• Cloud infrastructure and hosting, including the regions where data is stored and processed.
• Databases, search indexes and file storage that hold the agent's memory and your documents.
• Logging, monitoring and analytics tools that capture requests and responses for debugging.
• Messaging and email channels through which the agent receives and sends content.
• Transcription, OCR or other specialist services that handle audio, scans and images.
• Support and operations tooling that a vendor's staff use to investigate problems.

One distinction matters. A tool you connect yourself, such as your own calendar or CRM, is usually your vendor relationship, not the AI provider's subprocessor. You authorize it, and the permissions you grant decide what the agent can reach. The [Google OAuth 2.0 documentation](https://developers.google.com/identity/protocols/oauth2) is a good reference for how scoped authorization works in practice. Keep both categories on the same map, but do not confuse who contracted whom, because it decides who owes you notice.

Why does the list matter to your business?

Because your promises to others travel down the chain. If you tell a client that their files are processed in a certain region, or that no third party can use their content for training, that promise is only as strong as the weakest party in the chain.

Here is an illustrative scenario. A small logistics company uses an AI agent to summarize supplier emails and draft replies. Its largest customer asked, in a security review, where shipment documents are processed. The company answered from the vendor's list at the time. Later the vendor adds a transcription service for voice notes, hosted elsewhere, and updates a page on its website. Nobody at the logistics company reads that page. At the next customer review, the earlier answer is no longer accurate, and nobody knows since when.

Nothing dramatic happened in that scenario. No breach, no leak. The cost was an answer that had silently become wrong. Subprocessor management is mostly about preventing that quieter failure. The same list also feeds your client security questionnaire answers, and each new entry is a candidate line in your AI risk register.

It also connects to wider risk guidance. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) treats third-party components and data as part of the risk an organization owns, and the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) includes supply chain among its risk categories. A subprocessor list is the most concrete form of that supply chain you can ask for.

How do you ask a vendor for a current list?

A polite, specific request gets better results than a general one. Use this plan:

• Step one: Identify the right contact. Ask for the vendor's security, privacy or legal contact, not general sales.
• Step two: Request the list in writing, dated, and ask the vendor to confirm that it reflects what is in use today, not only what is planned.
• Step three: For each entry, ask for the legal entity name, the purpose, the type of data involved and the processing location.
• Step four: Ask whether each subprocessor is bound by terms that match the vendor's own obligations to you, including confidentiality and security duties.
• Step five: Ask about model providers specifically: whether your content may be retained, who can access it, and whether it can be used to improve models.
• Step six: Ask how the list is kept and published, and who at the vendor owns it.
• Step seven: Store the answer with the contract and record the date you received it.

If the vendor already publishes a list, ask whether it is complete and whether the contract refers to it. A published page that can change without notice is information, not a commitment. The data processing agreement checklist covers how to tie the list to the contract so that your rights follow it.

You can also ask about the vendor's own certifications and audit reports, which often describe how it selects and monitors its suppliers. The article on SOC 2 and ISO 27001 for AI providers explains what to request and how to read the answers.

What should change notifications look like?

A list that is correct today and silent tomorrow does not protect you. Define the notification terms as clearly as the list itself. A workable arrangement has these parts:

• Advance notice. The vendor tells you before a new subprocessor starts handling your data, with enough time for you to review and respond.
• A channel someone actually reads. Use a shared role mailbox such as a privacy or operations address, not one employee's inbox that may change when people leave.
• Useful content. The notice names the new party, the purpose, the data involved and the location, so you can decide without chasing details.
• A right to object. If you have a reasonable concern, you can raise it, and the contract says what happens next.
• A defined outcome. The vendor may offer an alternative setup, delay the change for your account, or allow you to end the affected service. Agree on which options exist before you need them.
• Emergency exceptions. Vendors sometimes replace a failing supplier quickly. Allow it, but require prompt notice afterward and the same right to object.

Two habits make this work. First, assign a named owner on your side who reads every notice. Second, set a standing review point, for example when the contract renews or when you change what the agent does, to ask the vendor for a fresh list even if no notice arrived. Absence of notices is not proof of absence of changes.

What do you do when a new subprocessor appears?

Treat each notice as a small decision, not an alarm. This guide helps you sort the common cases:

• If the new party performs the same function as an existing one, in the same region, under equivalent terms, record it and accept.
• If it processes your data in a new region, check your commitments to clients and any legal transfer requirements before accepting.
• If it can retain content or use it to improve models, ask for the retention terms in writing, and object if they conflict with your commitments.
• If it handles a new type of data, such as audio or scanned identity documents, review whether the agent needs to send that data at all.
• If the vendor cannot explain the purpose or terms clearly, pause acceptance and ask follow-up questions before the change takes effect.
• If your concerns are not resolved, use the objection right and discuss alternatives, including a different configuration or ending the service.

The cleanest way to reduce these decisions is to send less in the first place. If the agent only receives the fields it needs for its task, many subprocessors become irrelevant to you. The guide to data minimization for AI agents shows how to scope what the agent sees.

Record every decision with a date, the person who made it, and the reason. That record is what you will show a client, an auditor or a regulator if they ask how you manage your AI supply chain.

How does Be Human handle this in a managed engagement?

In a Be Human engagement, the first step defines one role for the agent, the memory and tools it needs, and the approval boundaries around it. That work already produces a written map of where data goes, which is the starting point for a subprocessor review. During managed operations, permission reviews and integration maintenance are the natural points to compare that map with the current lists of the services involved, and to bring any change to a named person on the client side for a decision. The client keeps control of what is accepted, what is limited and what is stopped.

Frequently asked questions

What is the difference between a subprocessor and an integration I connect myself? A subprocessor is engaged by your vendor to help deliver the service, so your vendor is responsible for choosing and managing it. An integration you connect yourself, such as your own email or CRM account, is a relationship you create and authorize directly. Both can touch your data, so track both, but notice obligations usually apply to the first kind.

Do I have the right to approve or reject a vendor's subprocessors? That depends on your contract. Some agreements give you a right to object to new subprocessors, while others only promise notice. Negotiate for at least advance notice and a defined path if you object, and read the terms before you rely on them.

How often should I ask for an updated list? Ask when you sign, when the contract renews, and whenever you change what the agent does or which data it receives. Between those moments, rely on change notifications sent to a monitored address. If a client or regulator asks you a question about data location, confirm the current list before you answer.

What if a vendor refuses to share its subprocessor list? Treat it as a significant finding. A vendor that cannot tell you who handles your data makes it hard for you to keep your own commitments. Escalate to its security or legal contact, and if the answer does not improve, weigh whether the service is suitable for the data you plan to send it.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.