Ask a leadership team how much AI the organization uses and you will usually get a confident number. Twelve tools, perhaps, or “a few pilots and the copilot rollout”. Then ask a second question: for each of those, what can it read, what can it change, and which decisions does it shape? The confident number tends to dissolve. Not because anyone is hiding anything, but because the honest answer is that nobody has ever drawn the map.
The frameworks agree that the map comes first. The NIST AI Risk Management Framework, the voluntary standard many organizations already cite, includes among its governance outcomes that “mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities” (National Institute of Standards and Technology [NIST], 2023, GOVERN 1.6). The new AI Baseline Control Framework makes the same move in plainer language, asking that deployed AI systems and providers are “registered and classified” and that, where AI acts autonomously through agents, scripts or automations, “what it does is described” (van Dijke, 2026, RG.1–RG.2). So far, so sensible. Write a list, give each item a risk label, review it once a year.
The complication is that the list many organizations write is a list of products, and products are not where the exposure lives. A chat assistant licensed from a vendor is one line in a register. The same assistant connected to your ticketing system, given access to a shared drive, wired to send emails and fed a prompt template that someone edited last Thursday is a different system, even though the line in the register has not changed. The OWASP project, which catalogues security weaknesses in applications built on large language models, lists “excessive agency” among its top risks for exactly this reason: the danger often comes from the permissions and tools a model has been handed, not from the model alone (OWASP GenAI Security Project, 2025). An inventory that records the product but not the connectors, the tools, the retrieval sources and the prompt variants is an inventory of brand names.
In Operational AI Readiness I argue that the unit worth inventorying is the workflow, not the tool. A workflow record is short. It names the system and its purpose, the uses it is explicitly not meant for, the people and decisions it can affect, the data and connectors it depends on, and one named owner (Bakos, 2026). That last item is where, in my experience, inventories most often quietly fail. In one of the book’s scenarios, an HR screening assistant is maintained by engineering, sponsored by HR leadership and supplied by a vendor, and when a candidate challenges an outcome the question is who owns the explanation. “If the answer is a meeting invitation with six people on it, the ownership model is weak” (Bakos, 2026). Many teams that have tried this exercise will recognise the feeling.
Here is the part that surprises people, and it is FairByDesign analysis drawn from the book’s sprint rather than a measured statistic. When a team builds an honest workflow inventory for the first time, the inventory itself becomes a finding. It surfaces the connector nobody remembered approving, the prompt variant that lives in one engineer’s notes, the spreadsheet macro that calls a model API, the assistant whose “drafting help” has drifted into drafting the decision. The point is not to shame anyone. The point is that you cannot govern, monitor, log or stop something you have not noticed is there.
If you want to try this, the cheapest version takes an afternoon. Pick the one AI workflow that touches money, employment, access, security or customers most directly, and write a one-page record of what it is for, what it is not for, what it connects to, and the single person who answers for it. If you cannot name that person without a meeting, you have found your first gap, and it is a useful one.
Because the moment you have a name, a harder question arrives. Owning a workflow is not the same as being able to stop it. When this system does something it should not, who has the authority to pause it, and would they know in time? That is next.
Go further. Chapters 3 and 4 of Operational AI Readiness walk through classifying decision-influencing AI honestly and building the minimum viable control stack, starting with the inventory; Week 1 of the book’s 30-day sprint turns it into a working record. The complete Standard edition is free: read or download it here, and test one workflow with the free readiness assessment.
References
Bakos, V. (2026). Operational AI readiness: A practitioner guide to governing AI that is already live. FairByDesign. https://fairbydesign.org/operational-ai-readiness/
National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1
OWASP GenAI Security Project. (2025). OWASP top 10 for LLM applications 2025. https://genai.owasp.org/llm-top-10/
van Dijke, J. (2026, October 2). AI Baseline Control Framework (AI BCF) (Version 1.0). https://aibcf.org/controls/
FairByDesign is reader-funded. Give once ($5, $10, $25, $50 or any amount), give monthly ($10 or $25), or become a patron.
Give $5 · Give $10 · Give $25 · Give $50 · Any amount · $10 a month · $25 a month · Become a patron
Support never buys editorial control.

Leave a Reply
You must be logged in to post a comment.