Your AI Subprocessors Are Your Customers' Problem Too

A subprocessor is any third party that processes personal information on your behalf, including the model provider behind an AI feature you built. If you added a summarizer, a chatbot, or a drafting assistant this year, you almost certainly added a subprocessor, and your existing customer contracts almost certainly promised to tell them.

Most companies did not. Not deliberately: the feature was built by engineering, the subprocessor list lives in a legal page nobody owns, and no process connected the two.

Why does this matter under Canadian law?

Because accountability does not transfer down the chain. Under PIPEDA, an organization remains accountable for personal information transferred to a third party for processing, and is expected to use contractual or other means to provide comparable protection. Quebec's Law 25 goes further on transparency, with obligations around informing people when information is communicated outside Quebec and assessing that transfer beforehand.

Neither law contains a clause saying "unless the third party is an AI vendor". The model provider behind your feature is a processor like any other, and the fact that the data passes through in milliseconds and is not retained does not remove it from the chain.

There is also a contractual layer that bites sooner than the regulatory one. If your customer agreement includes a data processing agreement, it very likely commits you to maintaining a current subprocessor list and giving notice before adding one. Shipping an AI feature without updating that list is a contract breach, discovered by a customer's procurement team at renewal, which is the worst possible time.

What actually has to be disclosed?

Enough for a reasonable customer to assess the chain. In practice, four things per entry.

Two judgment calls come up constantly here.

The first: should you name the vendor or describe the category? For a public legal page, naming the service category rather than the specific vendor is defensible and is what many companies do, particularly where naming would expose commercial detail. Where a contract commits you to naming subprocessors, however, the contract wins. Decide once, apply consistently, and do not let a marketing preference override a contractual promise.

The second: does a vendor's own subprocessor count as yours? Legally the chain is usually managed vendor to vendor, but practically your customers will ask, and "we don't know" is a bad answer. At minimum, know which model provider sits behind each AI vendor you use, and record it in your vendor inventory.

How does a subprocessor get added without anyone noticing?

Four routes, all of them common.

A feature ships. Engineering integrates a model API to build something useful. No purchase order, no vendor review, because the API key came from an existing account.

A vendor changes its own stack. Your help desk provider adds AI summarisation and switches model providers. Your data now reaches a company you never evaluated, under a notice buried in a product changelog.

A pilot becomes production. Something trialled on synthetic data quietly starts running on real customer records because the pilot worked.

A plan changes. The free tier had different data handling than the paid tier, or the reverse, and someone changed plans.

Only the first is preventable by procurement controls. The other three are why the subprocessor list needs a scheduled review, not just an intake gate.

How do you keep the list honest?

Attach it to the events that actually change it.

Make adding a model API to production a change that requires the subprocessor list to be updated in the same ticket. Engineers will do this if it is a checkbox in a template; they will not do it if it requires emailing legal. Put the customer notice obligation on the same trigger, because the notice period in your DPA starts when you add the subprocessor, not when someone remembers.

Then review quarterly against reality: pull the list of vendors from your vendor inventory, compare it to the published page, and reconcile the differences. Every reconciliation I have watched found at least one entry that was wrong in one direction or the other, usually a vendor that had been replaced months earlier.

Where transfers leave Canada, the assessment is its own obligation, and a cross-border transfer assessment belongs with the entry rather than in a separate file nobody links.

What do you tell a customer who asks?

Straightforwardly, and faster than they expect. Enterprise buyers are not shocked that you use a model provider; they are shocked when you cannot say which one.

Keep a page that answers it without a sales conversation, and keep it current. A public trust page with the subprocessor list, processing locations, and your certifications removes a week from most security reviews, and it does more for a deal than a well-written policy nobody reads.

For the broader vendor relationship, third-party risk and why your compliance is only as strong as your vendors covers the diligence side.

This is general information, not legal advice.

Valdra keeps vendors, their sub-processors, transfer assessments, and the customer-facing disclosure in one chain, so the list on your trust page matches what is actually running.