Subprocessor Management for AI SaaS Products

Adding an AI feature usually means adding a subprocessor. The moment customer data flows to a model provider, a vector database, or an inference host, your supplier risk surface changes. Most teams ship the feature first and update the subprocessor list later, if at all. That gap is exactly what a customer security review will find.

What counts as a subprocessor now

A subprocessor is any third party that processes personal data on your behalf. The definition has not changed. What has changed is how many of them an AI feature quietly introduces.

A single "summarize this document" button might touch:

• The model provider that runs inference, for example OpenAI, Anthropic, or a cloud-hosted model
• A vector database that stores embeddings of customer content
• An orchestration or observability tool that logs prompts and completions
• A separate provider for transcription, OCR, or image analysis

Each of these can receive customer data. Each belongs on your subprocessor list if personal data is involved. The observability tools are the ones teams forget, because engineers add them for debugging and never think of them as data processors. But a prompt-logging tool that captures user inputs is processing personal data as surely as your primary database.

The test is simple. Does the third party receive data that originated from your customers? If yes, it is a subprocessor, regardless of whether it is core to the feature or a supporting tool.

Training, retention, and the questions customers actually ask

Enterprise buyers have gotten specific about AI. The generic "do you use AI" question has been replaced by a short list that reveals whether you understand your own data flows.

Expect to answer:

• Is our data used to train the provider's models? For most enterprise API tiers the answer is no, but you must be able to point to the contractual term that says so.
• How long does the provider retain prompts and outputs? Many providers retain data for a limited window for abuse monitoring. Know the number.
• Is data processed in a specific region, and can you commit to that in a contract?
• Can the AI feature be disabled entirely for a given customer or tenant?

The last question matters more than people expect. Regulated customers frequently want AI features off by default, or gated behind their own approval. If your architecture cannot isolate AI processing per tenant, you will lose deals or grant exceptions you cannot cleanly support.

Get the answers in writing from each provider before you promise anything to a customer. The zero-retention or no-training terms often live in an enterprise agreement or a specific API configuration, not the default consumer tier. Assuming the default terms apply is a common and expensive mistake.

Keeping the subprocessor list honest

Your public subprocessor list is a commitment. Under most Data Processing Agreements you owe customers notice before adding a new subprocessor, often with a window to object. Ship an AI feature backed by a new provider without updating the list, and you have a contractual breach waiting to be discovered.

Practical ways to keep it current:

• Tie the list to a real trigger. The subprocessor list should update as part of the process for adding any new data-processing vendor, not on a quarterly cleanup. Make it a step in vendor onboarding.
• Assign an owner. Someone must be accountable for the list matching reality. In practice this sits with whoever owns your GRC function, informed by engineering.
• Automate the notice. If your DPA promises notice of changes, have a mechanism, an email list or an RSS-style feed, that fires when the list changes.
• Distinguish active from approved. A provider you evaluated but never shipped does not belong on the customer-facing list. Only what actually processes data should appear.

The discipline here is not glamorous, but it is visible. A subprocessor list that has not changed in eighteen months at a company shipping AI features tells a reviewer you are not tracking your own supply chain.

Diligence proportionate to the data

Not every subprocessor deserves the same scrutiny. A model provider handling raw customer documents is a different risk than a font CDN. Tier your diligence to the sensitivity of the data the provider touches.

For providers handling customer content, gather and keep:

• Their current SOC 2 Type II report or ISO 27001 certificate, and check the scope covers the service you use
• Their data processing terms, including retention, training, and sub-subprocessor disclosure
• Their sub-processors, because your subprocessor's subprocessors are part of your chain
• Their security contact and breach notification commitment

For AI providers specifically, read the model and usage policies, not just the security page. Terms about how inputs may be used, whether human review occurs, and what happens to flagged content are all relevant to what you can promise customers.

Keep this evidence somewhere retrievable. When a customer asks for your AI provider's SOC 2 report during a review, "we will get back to you" costs you momentum. Having it on hand signals a function that is actually running.

Mapping it to your ISO 27001 controls

If you are working toward ISO 27001, subprocessor management is not a separate exercise. It maps directly to the supplier relationship controls in Annex A, which expect you to identify suppliers, assess their risk, define security requirements in agreements, and monitor them over time.

AI providers fit this framework cleanly once you treat them as what they are, suppliers who process data. The internal artifacts an auditor will look for are:

• A supplier register that includes your AI and infrastructure providers, not just the obvious ones
• Evidence of risk assessment proportionate to the data each handles
• Security terms in the underlying agreements
• A record of ongoing review, even if that review is annual and lightweight

The value of the ISO framing is that it forces the questions to be asked once, at onboarding, and revisited on a schedule. That is exactly the discipline that stops the subprocessor list from drifting out of date. You are not building AI-specific governance. You are making sure your existing supplier governance actually captures the providers your AI features depend on.

Bottom line

AI features expand your subprocessor footprint faster than most teams update their records. The providers are real, the data flows are real, and the contractual commitments in your DPAs already apply to them. The fix is not complicated, but it does need to be deliberate: identify every third party that touches customer data, tier your diligence to sensitivity, keep the public list honest, and map the whole thing to your supplier controls.

If you are shipping AI features and are not confident your subprocessor list and supplier evidence would survive a customer security review, a Kellwick readiness review can show you where the gaps are before a buyer or auditor finds them.