Dev.to AI 🤖 Ai 👁 0 📖 4 min read

The risk register that went stale the day after launch

We wrote a risk register. It was a decent one for a document produced in a kickoff week. Months later it described a system that no longer existed, and nobody had noticed, because nothing in our process ever asked us to

We wrote a risk register. It was a decent one for a document produced in a kickoff week. Months later it described a system that no longer existed, and nobody had noticed, because nothing in our process ever asked us to open it again.

That is not a failure of the register. It is a failure of treating risk management as an artefact instead of a process. Article 9 of the EU AI Act describes a risk management system for high-risk AI systems as continuous and iterative across the lifecycle: identify and analyse known and foreseeable risks, estimate and evaluate residual risk, adopt controls, and document and test all of it, including risks from the intended purpose and reasonably foreseeable misuse. A one-time spreadsheet is not that.

A register is a snapshot, the obligation is a loop

A kickoff register is good at the hazards you can imagine before launch and bad at the ones that appear after: a new data source, a model update, a use case nobody predicted, an incident, a drift in how people use it. Article 9 expects the analysis to be revisited as the system and its context change, and the residual-risk reasoning to be written down, not just the initial hazards. I had the initial hazards. What I did not have was a trigger that said "re-open the register now". Without one, re-evaluation happens when someone remembers, which is to say it does not. The register stays green because nothing was added to it, not because nothing changed.

I was also missing residual risk. We listed hazards and controls but rarely wrote the sentence connecting them: after this control, here is the risk that remains and why we judge it acceptable. That is the part an assessment tests, and it goes stale fastest, because a control adequate at launch may not be after the input distribution shifts.

The fields I should have had from the start

I rewrote each risk item to carry the hazard, an estimate of likelihood and severity, the control, an explicit residual-risk statement, and a trigger for re-evaluation. That last field turns a register into a loop. "Re-evaluate when the model version changes" and "after a serious incident" are boring lines and the whole point. A missing risk theme is a more useful signal than a long list of individually plausible hazards.

I built RmsForge to draft that scaffold. You paste how you run an AI system, and it returns an Article 9 risk-management starter: the risk themes, the residual-risk gaps, the lifecycle triggers for re-evaluation, and the evidence gaps. That is the whole feature set. It does not know your hazards, test your controls, or run an assessment for you.

A starter cannot know your hazards

RmsForge produces a draft scaffold: themes to cover, places where residual-risk reasoning is missing, and lifecycle triggers to adopt. The hazards, estimates, controls, and the judgement that a residual risk is acceptable come from the people who know the system. A tool that has read one pasted paragraph cannot tell you what goes wrong in your deployment. A thin description comes back with themes that have nothing behind them, and a register nobody maintains is worse than a short one that is actually revisited.

The limits, stated plainly

This is a decision-support tool. It is not legal advice, it is not a certification, and it is not a live audit harness. It does not observe your system, verify your controls, or decide whether Article 9 applies to you. That depends on high-risk classification under the Act, including the Annex III use cases, and on your role. If your system is not high-risk, most of this work does not apply.

I am referencing a real obligation, not a deadline, not a fine, and not a guarantee that a completed draft makes anything compliant. Article 9 asks for a documented, iterative risk management system across the lifecycle. The output is a starter for that system. It is not the system. If your risk register is a kickoff spreadsheet nobody has opened since launch, the paste-first starter at RmsForge gives you a scaffold to argue with.

FAQ

What does RmsForge produce?

An Article 9 risk-management starter from a description you paste: risk themes, residual-risk gaps, lifecycle triggers for re-evaluation, and the evidence gaps. A draft scaffold, not a certified risk management system.

Does it identify my actual hazards or test my controls?

No. It has only the description you paste. The hazards, estimates, controls, and the judgement that a residual risk is acceptable come from the people who know the deployment.

Is this legal advice or a certification?

Neither. It is a decision-support draft, not legal advice, not a certification, and not a live audit harness. It cannot verify your controls or decide whether the obligations apply.

Do I need it if my system is not high-risk?

Probably not. The risk-management duties here are tied to high-risk systems, including Annex III categories. If that is not your situation, most of the scaffold will not apply.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.