The risk breakdown structure now has an AI branch

Your risk register has forty rows, it is up to date, and the project still surprised you from a side nobody had looked at. That is not unusual and it is not the register’s fault. A register lists risks one by one, and a flat list is exactly what hides the holes.

What an RBS is and how it differs from the register

On 15 September 2026 PMI published a post that defines it precisely. The risk breakdown structure, the RBS, is a hierarchical, source-oriented map of everything that could put your project at risk, organized from broad categories down to specific origins.

The analogy it uses is the one that explains it best. Just as a work breakdown structure organizes the work to be done, the RBS organizes the risk that work involves. Categories sit at the top, classically technical, management, commercial and external. Each one opens into more specific sub-branches, as many levels down as the project needs.

And here is the distinction worth pinning down, because almost everyone skips it. The tree names sources, not risks. The individual risks and your strategy for each one keep living in the register, mapped onto the branches. The RBS does not replace the register, it orders it by origin so you see the clusters and blind spots a flat list covers up.

According to that same post, the discipline is not new. PMI’s risk management practice guide treats source-based categorization as core, and the PMBOK Guide names an RBS as a tool for organizing risk.

Where this shows up in the exam

In the July 2026 outline risk lives in Business Environment, the domain that weighs 26 per cent, and not where it used to sit. If that sounds new, we covered the whole move in the Business Environment post.

The task is called plan and manage risk, and it has seven enablers. Identify risks, analyse risks, monitor and control risks, develop a risk management plan, maintain a risk register, execute the risk management plan, and communicate the status of a risk impact on the project.

Look at the first and the fifth side by side. Identifying risks and maintaining the register are separate enablers, and the outline splits them on purpose. The RBS works on the first. The register is the fifth. Confusing them is the mistake that costs you in the items where the scenario tells you the team reviewed the register and a threat nobody saw coming showed up anyway.

The four classic categories and the seven AI risk sources come from the post PMI published on 15 September 2026.

What it is actually good for

PMI gives it three uses and the second is the one most people miss.

The first is covering every source. The upper branches work as a prompt list in identification workshops, so no whole category slips past unnamed. The third is reporting and reuse, because totals roll up for executives and drill down into detail for the team, and the same tree gets reused across projects to compare.

The second is finding where the greatest exposure sits, and it comes with a twist. You map each risk to its lowest branch and total a probability-and-impact score per branch. What tells you where to look first is the highest total, not the highest count. A branch with two severe risks outweighs one with fifteen minor ones, and a list sorted by quantity sends you to exactly the wrong place.

The branch PMI added this year

The classic tree assumes two things, that systems behave predictably and that a person makes the decisions. AI breaks both, with probabilistic behaviour, autonomous action and decision processes that may be hard to explain.

PMI’s proposal is not to rebuild the tree. It is to keep your top-level categories and hang one distinct branch beside them, AI and intelligent systems risk, which opens into seven sources.

Data, covering quality, bias, privacy, provenance and drift. Model, covering accuracy, robustness, drift, hallucination and calibration. Autonomy, which is acting beyond the intended authority, failing to escalate or executing without enough oversight. Explainability, which is opacity and audit difficulty. Governance, which is unclear accountability and weak controls. Ethical, which is unfairness, harm, misuse and erosion of trust. And AI-specific cybersecurity, which includes prompt injection, data poisoning and insecure tool access.

Each source gets defined, gets someone assigned to watch it, and the branch slots in beside the ones you already had. PMI’s AI standard, which we broke down at the time, is the wider frame behind all of this.

What does not change

The post closes with three principles that hold for any tree. Sources and not symptoms, because each branch has to name an origin capable of generating many risks. Tailor the tree, because no single RBS fits every project and you start from a generic one. And every branch needs someone watching it, because a source nobody monitors slips past on its own.

There is a closing line worth taking to the exam and to the office. Automation can carry the register and even recommend the response. What it never carries is the accountability.

Join the waitlist

At The PM Architect we write the PMBOK study guides in five languages, with real classroom cases and exercises that come with an explanation. They will be free. Leave your email on the home page and we’ll let you know the moment they’re ready.