A vendor supplies an accounting package, an HR system, or a customer service tool. There is a contract, a data processing agreement, perhaps a security audit. Then the vendor adds an AI feature in an update: automatic classification, text suggestions, a chatbot set loose on your data. The release notes call it an improvement. No one in your organization had any say in it, because no one knew it was coming.
This is not an exception to how software is delivered. It has become the standard. Vendors compete on AI functionality and build it in as fast as possible, often as part of a subscription you already pay for. The question of whether this falls under your existing agreements is rarely asked before the feature goes live.
A procurement department vets a vendor at the time of purchase. After that, attention shifts to invoicing, uptime, and support. Functional updates run outside that process, because they fall under maintenance, not under a new purchase. Who should be reporting it? The vendor sees it as a product improvement. The buyer doesn't see the update, or does see it and assumes it's someone else's concern. The user within the organization mainly notices that a button does something smarter, and doesn't wonder whether a language model sits behind it that processes data externally.
The pattern resembles what happens with a browser extension with access to your email: access is granted at a moment when no one was thinking about AI, and then remains active unnoticed. With vendors, the scaling problem is bigger, because it doesn't involve one employee but an entire organization exposed through a single contract.
A contractual provision that enforces a duty to report AI functionality helps with new contracts. With existing contracts, the provision isn't there, and it's not a given that a vendor will accept it retroactively. Moreover, a clause doesn't solve the detection problem: if no one periodically checks what a vendor has actually added, the notification remains dependent on the vendor's willingness to report it themselves.
What does work is a fixed snapshot: a periodic inventory of what each core vendor currently delivers in terms of AI functionality, detached from what was assessed at the time of purchase. That is not a legal instrument but a factual overview, which can then be tested against the risk category of the process in which the vendor operates.
The same dynamic that keeps shadow AI among employees alive also plays out here, only at the vendor level. Whoever asks the question "are you using AI for this" wants an honest answer, not a defensive reaction from the account manager. That means the question should not be asked as a prelude to contract termination, but as part of a fixed process in which the answer has no consequence beyond classification. See how that works with employees who use a tool no one approved: useful information only comes loose once asking questions is separated from punishing.
A vendor list is a starting point, not an endpoint. For every vendor with access to production data, customer data, or personnel data, it is relevant whether AI functionality has since been added, what that functionality does with the data, and whether that use falls within the same risk category for which the vendor was originally approved. A vendor assessed five years ago as low risk because it only handles invoicing may now be running a module that automatically classifies invoices based on a language model trained externally. That is a different risk category, even though the same name appears on the invoice.
This inventory should not stand apart from the rest of an organization's AI governance. The same classification applied to internally built tools or to a pilot setup that was never switched off should also be applied to what vendors bring in. One overview, one risk scale, regardless of whether the AI was built internally, brought in by an employee, or added by a vendor without announcement.
Once it is clear which AI is entering through vendors, a follow-up question arises that goes beyond risk alone: what does that AI actually do with the work currently performed by people, and where does that overlap with tasks that were already candidates for automation. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, regardless of which vendor or system ultimately carries it out. That makes the inventory that starts with risk also useful for the question that comes after: not just what is running, but what the work is actually worth.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.