A support team enables an AI summarisation feature in its helpdesk tool. Three weeks later a customer asks for your list of subprocessors and a security review finds that ticket contents, including customer personal data, have been sent to a model provider in another jurisdiction with a 30-day retention default. What failed?

The trigger

A toggle in an existing vendor's admin console. No contract was signed, no procurement happened, and no engineer deployed anything. The vendor's own subprocessor list changed, and the feature flag was the mechanism by which that change took effect in your estate.

Why it propagated

Three control gaps, each of which looked covered.

Vendor assessment was point-in-time. The helpdesk tool was assessed at purchase, when its subprocessor list did not include a model provider. Nothing re-triggered the assessment when the list changed, because the trigger was a contractual notice email in a shared inbox rather than an event anyone processed.

The control was placed on procurement, not on data flow. A policy requiring approval for new processors governs purchasing. It has no purchase to attach to when a capability appears inside a product you already own.

The configuration surface was outside change management. Nobody treats a vendor admin console as a deployment target, so a change with the same effect as shipping code to production had none of the controls that shipping code has.

Why detection lagged

There was no signal. The data left through the vendor's own backend, not through your network, so egress monitoring never saw it. The only observable was a line in a vendor release note. Three weeks is fast for this failure mode; organisations routinely discover it at a customer audit a year later. The cost of the delay is not the data itself but the disclosure: a subprocessor you did not list is a contractual breach with every customer whose agreement names the list, which in a 400-customer book is 400 notifications.

The structural fix versus the tempting local fix

The tempting fix is a policy telling teams not to enable AI features without approval. It will be followed for a quarter.

The structural fixes, in order of effect:

1. Treat subprocessor notices as an event with an owner and an SLA. Most data-processing agreements grant a notice period of 30 days and a right to object; that right is worthless if the notice lands in an inbox nobody processes. One named owner, a register, and a rule that an unreviewed notice blocks the renewal. Choose this control first, because it is the only one that works on capabilities you did not buy.
2. Disable the capability at the tenant level, not at the policy level. Where a vendor offers administrative control over AI features and data-sharing defaults, set it, and make the setting part of the configuration baseline you audit. A control you have configured beats a control you have written down.
3. Make a vendor admin console a reviewed configuration surface for the handful of tools that hold regulated data: changes logged, a second approver, and a quarterly diff against the baseline.
4. Where your own services call model providers, route through a gateway you control, so the processor, the region, the retention setting and the redaction are architecture rather than a per-team choice. That covers your code; it does not cover your vendors, which is why point 1 exists.
5. Hold the data-protection impact assessment at the data-flow level, not the application level, so a new destination for existing data triggers review even when no new application was bought. What this costs is real: a register someone maintains, a review queue with an SLA, and a quarterly configuration diff on the handful of tools that matter — perhaps 2 days a month of someone's time, against a disclosure that is unbounded.

The general lesson

Your subprocessor list is a property of your vendors' roadmaps, not of your procurement decisions. Any control that attaches to the act of buying will miss capabilities that arrive inside products you already own, and the arrival rate of those capabilities is currently high. The same mechanism applies to a new region, a new analytics partner or a new support tooling integration; AI features are simply the most frequent instance right now.

When this is the wrong level of control

For a vendor holding no personal data and no confidential content, the notice-processing machinery is disproportionate: let the policy carry it. Scope the controls by what the vendor can reach, which means you need the register from the shadow-SaaS work first. Without that, you are applying controls to the vendors you remember rather than the ones that matter.