AI Subprocessors: How to Disclose Your Model Providers

Most AI products are not running their own models. They are built on foundation models from OpenAI, Anthropic, Google, Mistral, or an open-weights host like AWS Bedrock or Together. That relationship is a subprocessing relationship — you are sending customer data to a third party to process — and enterprise buyers now require it to be disclosed as a condition of doing business. Getting this section of your trust center right removes a common procurement blocker.

Why AI providers are subprocessors

Under GDPR and standard data-processing agreements, a subprocessor is any third party that processes personal data on your behalf. When your app sends a user's prompt — which often contains personal or business data — to a model provider's API, that provider is processing data for you. It belongs on your subprocessor list exactly like your cloud host, your email provider, and your analytics tool.

The reason buyers single out AI subprocessors is that the data flowing to them is often richer and less predictable than a typical integration. A prompt can contain anything a user types. So reviewers want to know precisely which providers see that data, what they do with it, and where.

What to disclose for each AI provider

• Name and role. The provider (e.g., Anthropic) and its role: model provider, AI infrastructure, or AI subprocessor.
• Models used. Which specific models you call (e.g., Claude Sonnet, GPT-4o). Buyers use this to reason about capability and data handling.
• Data shared. What categories of data are sent — prompts, documents, metadata — and whether they can contain personal data.
• Training stance. Whether the provider may use your data to train its models on the tier you use. For business/API tiers the answer is usually "no," but state it explicitly and per provider.
• Location / data residency. Where the provider processes the data. This matters for EU customers who care about transfers.

The training question, front and center

The most important field is the training stance, because it is the question buyers ask first. Foundation-model providers offer business and API tiers with zero-retention and no-training defaults, distinct from their consumer products. Confirm which tier and terms apply to you, and represent it accurately: "customer data is not used to train models" is a powerful statement when it is true and documented, and a liability when it is vague.

Keep it current and notify on change

Subprocessor lists are not set-and-forget. When you add a new model provider or switch models, update the list — and ideally let subscribed customers know. Many enterprise DPAs require advance notice of new subprocessors, giving customers a window to object. A trust center that lets visitors subscribe to subprocessor changes turns this obligation into an automatic, low-effort process.

Practical setup

• List every AI provider as a subprocessor, tagged with its AI role so it stands out from ordinary vendors.
• Fill in models, data shared, training stance, and region for each.
• Publish under an AI Governance section so reviewers find it in one place.
• Enable change notifications so customers are informed when your AI supply chain changes.

Tools built for SMBs make this concrete: ShieldPage lets you tag a subprocessor with an AI role and record the models used and training stance, then renders a dedicated "AI Subprocessors & Model Providers" table on your trust center — the exact artifact a security reviewer is looking for, without an enterprise contract.

The takeaway

Your model providers are subprocessors, and in 2026 buyers treat AI subprocessor transparency as non-negotiable. Disclosing them clearly — with the training stance front and center — is one of the simplest, highest-impact things you can do to keep AI deals moving.