Pt III | Running the Risk -V- A Risky Register.
Why the register and the risk tier only count as governance when they keep running.
Last week, I argued that policy should not be the starting point in an AI governance program. It’s the part that we hear the most about, but carries little weight if you have not looked around to classify what exists before any rule that you write can c.
This week, we’ll cover what “looking around” consists of.
Two components are involved in that work: the AI inventory and risk classification. Both run the risk of failing silently because they often get built out once and then left alone.
| The AI Inventory.
The inventory is intended to be the authoritative record of what AI lives in an organization and who owns each system. The trouble is that most organizations do not know their full AI footprint.
There is shadow AI that entered the org through a team looking for a quick planning solution; there is vendor AI embedded in every tool that was purchased for something entirely unrelated; and there’s a random feature toggled on by default during a SaaS product’s latest update.
As to be expected, the first version of an inventory is incomplete 9 times out of 10. That is fine if it is a living record. It gets dangerous if it is a one-time spreadsheet, because a stale inventory is worse than a non-existent one. It manufactures false confidence, with leadership believing they are holding a map, meanwhile the map is six months old and there’s been construction done since the last rendition.
This is why an inventory that nobody maintains is worse than no inventory at all. The absence of a list is honest, it tells you that you do not know what you have. A stale list, on the other hand, gives false assurance that you are covered.
| Risk Classification.
Now for risk classification. This is the component that sorts each use case by severity and decides how much scrutiny it should undertake. Without the proper classification of risks, one of two things happens:
- Everything gets assigned the same treatment, which in practice means the lowest classification is applied as a blanket across the board.
- Scrutiny is only given to whoever escalates the loudest.
Neither is governance in its best practice.
A risk tier is the mechanism that decides ‘use case X’ earns a light review, while ‘use case Y’ earns a full impact assessment with a halt condition attached.
Get Mercedes D. Edwards’s stories in your inbox
Join Medium for free to get updates from this writer.
A tier assigned once has the same failure mode as the inventory. A system that was classified as low risk at launch can drift into a higher tier when its use is expand, its data shifts, or its outputs start feeding a decision it was never assessed for. A risk classification that is never revisited is a snapshot wearing the costume of a control — risky register.
When you put the two together, the shape is clear. The inventory tells you what exists. The classification tells you what to worry about. Neither survives as a one-time exercise, because the thing they describe does not stay static.
The real design question is not whether you have an inventory and a risk rubric, most programs can produce both as documents. The question is whether they are fed and re-fed by a process, or whether they are artifacts that were true once and have been decaying ever since.
| Continuous Monitoring for AI Inventory and Risk Profiles
Here is what continuous looks like when it is built rather than declared.
In the intake layer I have been developing, a use case does not enter the register as a hand-typed row. It enters through a parser that takes the messy proposal, a project brief, a README, or a business request, and extracts the system facts into a structured profile.
It assigns a preliminary risk tier, on the EU AI Act pattern, with the reasoning attached, so the tier is never a bare label that somebody can ignore. Where a proposed use-case is missing information that the risk classification depends on, it flags the gap rather than scoring past it.
A use case with unknown training data does not slip through as low risk. It comes out as incomplete, which is the honest result.
That last behavior is the one that matters most. The failure mode of every inventory and every risk assessment is the confident blank: the field nobody filled, read later as if it were a zero instead of an incomplete field required to make a determination. Making a gap a part of the record instead of brushing it over is what keeps the inventory honest and the tier defensible when someone finally audits it.
None of this removes human judgment. The parser produces a preliminary tier, not a verdict, and a person still owns the decision. The point is narrower and more durable than automation. The register is always current to the last submission. Every entry carries its own reasoning. The gaps are highlighted on the surface of the record instead of buried inside it. That is the distance between an inventory you actively maintain and one that only maintains the appearance of control.
Named versus running is the spine of this series, and it presses hardest here, because a list of AI systems and a risk rubric are the two easiest governance artifacts to produce, and the two easiest to let rot.
If you want to learn more about the AI Use Case & Inventory solution that I’m building out, visit here.
Or have some fun and get an AI use case assessed with the AI Use Case Assessor tool that I host on my portfolio, here.
If you try it, let me know your thoughts!
Next Tuesday: lifecycle monitoring and auditing, the mechanism that checks an approved system is still behaving and produces the evidence when someone asks for it.
This is Part 3 of a five-part series working through the components of an AI governance program from a technical program and risk perspective. It reflects my own architectural decisions and the trade-offs behind them.
