Who actually answers your call

Two news items from the same week have nothing to do with each other on the surface, and everything to do with each other underneath. Both are allegations, not findings. Both point at the same operational blind spot: the name attached to a model in your stack tells you what a provider says it runs, not what actually processed your request.

Two accusations, same week, same gap

Two unrelated news items from the same week point at the same operational blind spot. First: authorities allege that a group of overseas labs extracted a rival's model capabilities at industrial scale, using tens of thousands of fake accounts and millions of exchanges to harvest outputs and train on them. Second, and closer to daily operations: a threat report describes two providers that allegedly routed roughly 300,000 user requests to a foreign model over ten days and returned the results labeled as their own. Neither claim has been tested in court. Treat both as allegations, not findings — but the gap they point at does not depend on which allegation turns out to be true.

A model name is a promise, not a receipt

Somewhere in your stack there is a configuration file, a vendor page, or a privacy notice that names a model. It is easy to read that name as a fact about where your data goes. It is not. A model name in a configuration file is a statement of intent by the provider — what they say they run behind the interface — not proof of the actual path a request took. Providers reroute around outages, cut costs, or quietly substitute a cheaper backend, and the interface in front of you gives no signal that any of that happened.

For anyone running automations on top of a vendor through which someone else's data flows, that distinction is not academic. Whoever signed the data processing agreement still owes proof of where the data actually went, regardless of what the vendor's own page claims.

What counts as verified

The convenient answer is to trust the declared provider name until something goes wrong. The operational answer is narrower: a path counts as verified only when the name on the contract and the name on the invoice line match. That is something you can check today, not a promise you have to take on faith.

Everything else — a model badge in a UI, a sentence in a privacy notice, a claim in a sales deck — is marketing until a receipt backs it up.

What to do with this

Pull the three automations in your stack that carry the most sensitive data. For each one, write down the model or provider named in its configuration, then check the most recent invoice for that line item. If the names match, that path is verified. If they do not match, or there is no invoice line specific enough to check, treat that pipeline as unverified starting today — not as an item on next quarter's audit list.