At an organization with a single location and a single procurement department, the picture is usually still manageable. With multiple locations, that changes. Each location typically has its own budget, its own manager who signs off on subscriptions, and often its own relationship with local suppliers. That makes procurement and licensing data one of the few sources that reveal something the central IT list misses.
The IT department records what has been requested and approved through its own channels. A location manager who has a credit card and thinks a tool is needed doesn't have to go through that. The subscription is taken out, the invoice arrives at the local administration or at the accounts payable department at head office, and no one links that expense back to a central system overview. That is exactly why this source is valuable: it records expenses, not approvals. What's there is what was actually purchased, regardless of whether it went through the proper channel.
A usable overview starts with a number of fields per line:
Together, these fields do not give a complete picture of what a tool does. They do give a list of names to investigate further.
With multiple locations, there are usually several sources at once:
Combining these sources produces overlap and contradictions: the same supplier with different contract forms per location, or a subscription being paid in two places without anyone noticing. That is not a flaw in the method; that is what happens when procurement is organized on a decentralized basis. Which other sources within your organization yield comparable signals is described at the IT signals that are useful across multiple locations.
A line in the accounts payable ledger says that a payment was made. It does not say who uses the tool, for what, with which data, or whether the tool is still active. A subscription taken out three years ago may by now be unused, or may have grown into a fixed part of a process without that ever being documented. The procurement data provides a starting point: a name, a location, an amount. The conversation with the requester or the department provides the rest. Without that conversation, the list remains a list of suspicions.
Procurement data pointing to AI use touches on more than technology. A tool that generates text, classifies data, or supports decisions may fall under a role with obligations — as provider, as user, or sometimes both at once, depending on how the tool has been deployed and adapted. Which role applies and when it changes is explained on the page about whether you are a provider or a user and on the page about the moment your role changes. Procurement data does not tell you which role applies, but it does tell you where to start asking questions.
A list of supplier names and locations is a starting point, not an inventory. The next step is organizing those signals by application, risk level, and responsible department — a process described step by step on the page about building an AI inventory, including what needs to be recorded per application. Those who follow this route often discover that the picture IT maintains centrally covers only part of reality — a discrepancy discussed in more detail on the page about why that central list is inaccurate.
An overview of which tools exist naturally raises a follow-up question: what those tools actually do with the work people still perform themselves. Those who want to answer that question at the level of individual tasks will find, at the werkscan from FTE TO AI, a way to calculate per task which part of it can be taken over by AI, regardless of which tool is used for that or who purchased it.
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.