Kennisbank

A supplier deployed AI in your product without saying so

How this comes about

A supplier adds a feature that under the hood runs on a language model or a third-party API. For the supplier, it's a product update, not an event that warrants notification. The release notes mention a new button, not the technology behind it. Your organization is already using the software, the contract was signed based on the old functionality, and the change doesn't come in through procurement or security — they only see what happens with new purchases, not what an existing product quietly gains.

The pattern is the same as with a browser extension with access to your email: the access and the feature already exist before anyone has assessed them. With a supplier, the distance is simply greater — you cannot look into the source code and must rely on what the supplier says, or doesn't say.

Why it doesn't disappear on its own

There is no moment at which this announces itself. An employee uses the new feature because it's convenient, not because he recognizes an AI component. The supplier has no incentive to actively report this as long as no one asks: it generates no revenue and may well raise questions. And the chance that you encounter it yourself is small, unless there is an incident or a periodic check picks up on it.

This resembles an internal pilot that has lingered on: just as with a test setup that was never switched off, what's missing is not malicious intent, but a moment at which someone asks the question. With a supplier, there is the added factor that you depend on their willingness to answer.

What you can do

The starting point is not to legally enforce the contract at the first sign of doubt, but first to know what is going on. That begins with asking the supplier questions: which parts of the product use AI, what data goes there, and has that changed since the contract was signed. Suppliers who can answer without consequences are more likely to do so truthfully than suppliers who suspect that an honest answer endangers the contract.

The same logic applies within the organization: employees who use a tool that no one knows contains AI will only report it once reporting carries no penalty. How you organize that is described at employees using a tool that no one has approved. For a supplier, the principle works the same way: a question asked without suspicion gets a different answer than a question read as a prelude to sanctions.

Once it is clear what the supplier has added, the follow-up question is not legal but functional: what role does this AI component play in the process, what is the risk level, and what needs to be recorded about it. You ask those same questions of every AI application you deploy yourself, whether it arrives via a supplier or via an employee using a free tool — see also company data ending up in a free chat window. What you record per application depends on what that application does and with which data, not on where the application comes from. An overview of what is relevant here can be found at what you need to record per application.

A supplier that adds AI without notice should therefore not be treated separately as an incident, but incorporated into the inventory you are already building for the rest of the organization. How that inventory is built in practice — including how you give suppliers a place in it — is described at how you build an AI inventory.

What this is not

This is not grounds for a legal offensive against every supplier that failed to report something. Establishing breach of contract is a different question from establishing risk, and the two do not automatically go together: a supplier may have failed to report something without the application carrying a high risk, and vice versa. The first step is assessing the risk, not the question of fault. Whoever starts with sanctions will get less information from suppliers going forward, not more.

The next question

Once it is clear which AI components are active within the organization via suppliers, employees, or internal initiatives, another question arises: what does that mean for the work itself. Not every AI application that comes in actually does something useful with the process it's part of — and not every process that currently runs manually is by definition better off without AI. FTE TO AI's work scan calculates per task which part of the work can reasonably be taken over by AI, regardless of how that AI entered the organization. That turns the inventory you are now building into not just a governance instrument, but also a starting point for determining where AI actually makes a difference.