The AI feature that added a subprocessor you never disclosed

The model provider was now processing customer data on your behalf, which made it a subprocessor. Your customer agreements listed the old ones and had never been updated.

The AI feature that added a subprocessor you never disclosed

A privacy lead at a B2B company told me about an obligation the AI feature had quietly created. When they added a hosted model, that provider began processing customer data on the company’s behalf, which is the definition of a subprocessor. Their customer agreements included a list of subprocessors and a commitment to keep it current and, in many cases, to give notice before adding new ones. The AI feature had added one, and the list had never been touched. So the company was now, without meaning to be, out of step with commitments it had made in writing to its customers. Nobody decided to skip the disclosure. The AI feature was built by engineers, and the subprocessor obligation lived in a document those engineers had never seen.

Adding a model provider is often adding a subprocessor, and that carries obligations most engineering teams do not have on their radar. If the provider handles customer personal data on your behalf, your data protection commitments usually require that you disclose it, sometimes that you give advance notice, and sometimes that you offer customers a chance to object. The feature shipped as a technical change. The obligation it triggered was a legal one, and the two live in different parts of the company that rarely talk during a build.

The vendor chain grew and the paperwork did not

Your customers care not only about what you do with their data, but about who else touches it. That is why data protection agreements list subprocessors and govern how new ones get added. The list is a promise. It says these, and only these, are the third parties in the chain, and here is how we will tell you when that changes.

An AI feature can break that promise silently. Engineers pick a model provider on technical merits, wire it up, and ship. The provider is now processing customer data, which makes it a subprocessor, which triggers whatever your agreements say about adding one. But the engineers were solving a technical problem, and the subprocessor list is a compliance artifact they may not know exists. So the vendor chain grows and the paperwork stays frozen, and the gap sits there until a customer audit, a renewal, or a regulator surfaces it.

This is a coordination failure more than a technical one. The knowledge of the obligation and the action that triggers it live in different heads. The person who added the provider did not know about the list. The person who owns the list did not know a provider had been added. Nothing connected them.

Bring the AI vendor into the compliance picture

The fix is to treat adding a model provider as a change that touches compliance, not just engineering, and to route it accordingly.

What that involves:

  • Recognize the provider as a subprocessor. If it processes customer data on your behalf, it belongs in the same category as your other subprocessors and under the same obligations.
  • Update the disclosures. Add it to the list your customers rely on, and follow whatever notice or objection process your agreements require.
  • Connect the build to the paperwork. Make adding an AI vendor a trigger that involves whoever owns subprocessor commitments, so the two stop living in separate worlds.
  • Track the whole chain. If the provider itself relies on others to serve your requests, understand that chain too, because it may extend your obligations further.

The teams that get this right make the compliance step part of adopting a provider, not an afterthought discovered during an audit. The technical decision and the disclosure obligation move together, so the vendor chain and the paperwork stay in sync.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look at whether adding your model provider created subprocessor obligations and whether they have been met. It is a common gap, because the feature is built by people who do not own the customer agreements, and the agreements are owned by people who did not know a provider was added. Connecting the two before an audit does is far less painful than explaining the gap after.

A model provider that touches customer data is a subprocessor, and your agreements probably say you have to disclose it. Keep the AI vendor in your compliance picture, so the paperwork grows with the vendor chain.