Before an organization can determine what AI is allowed to do, it must know what is actually being decided. That sounds obvious, but in practice few boards can provide, on request, a complete overview of the decisions made daily within their organization. Who makes them, based on what data, and what happens if that decision turns out wrong. A decision inventory is nothing more and nothing less than the answer to those questions, written down systematically.
The inventory is not a technical document. It is an organizational document that lays the foundation for every conversation about automation, responsibility, and pace.
A usable inventory describes at least four things for each decision. First: who currently makes the decision, and whether that is a role, a team, or a system. Second: what information is needed to make the decision, and where that information comes from. Third: what the impact is if the decision turns out wrong, expressed in the type of damage — financial, legal, reputational, safety — not in an amount. Fourth: how often the decision occurs, because frequency determines whether automation ever delivers anything.
These four columns together show which decisions are predictable and which are not, which occur often and which are rare, and which have consequences the organization can bear and which it cannot. That combination is more valuable than a list of task names.
The inventory does not calculate which part of a decision can be taken over by AI. That is a separate question, with a separate method, and it is a mistake to try to answer both in one step. Anyone who wants to know first whether a decision is AI-ready before it has been established what the decision actually entails and who is responsible for it, is building on sand.
The inventory also makes no statement about whether a decision should be automated. That is a choice the organization makes itself, with knowledge of the risks and its own tolerance for them. Some decisions belong in the category that should never be automated, simply because the consequences of an error cannot be undone. The inventory signals that such decisions exist; it does not decide on the organization's behalf.
An interesting effect of creating a decision inventory is that different people within the same organization have a different picture of who makes which decision. An operational manager thinks a decision lies with the team; the board thinks it decides on it itself. Both can be right for different situations, but if no one has explicitly recorded that, noise arises as soon as automation comes up.
This divergence is exactly why board members disagree on the pace of AI adoption: they look at the same organization but see a different decision landscape, because no one has ever written it down together.
An inventory without a follow-up is a document that disappears into a drawer. The follow-up consists of two tracks. The first track is drawing up rules for what a system may and may not do independently — agreements that establish within which boundaries automated decisions may be made. Without those rules, every decision about automation remains an individual judgment call, with all the inconsistency that comes with it.
The second track is the conversation about pace: which decisions may be examined first, and which wait until the organization is ready for them. That conversation goes better when the board and management share the same picture of what is achievable within what timeframe, rather than each negotiating from their own assumptions.
The decision inventory describes the current situation. It says nothing about whether the organization is capable of letting AI participate responsibly in decision-making — that is a question about capacity, not about decisions in themselves. The difference between the two is explained on the page about the distinction between AI bearing and AI taking over, and that distinction is the reason an inventory is never meant to be an endpoint.
The inventory is also not a snapshot that remains valid forever. Decisions change, responsibilities shift, and new sources of information emerge. How often an organization must repeat the underlying measurement depends on how much has changed in the meantime; that is addressed on the page about the frequency with which a maturity measurement should be repeated.
Once it is clear which decisions exist, who makes them, and what is at stake, the question arises that the decision inventory itself does not answer: which part of the underlying work can actually be taken over by AI. That is the domain of the work scan from FTE TO AI, which calculates per task which share qualifies for takeover. The work scan builds on what the inventory has exposed, but looks at a different layer: not whether the organization is ready to bear it, but what can concretely be taken over once it is.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.