AI Risk Management: A Practical Guide

Of the three pillars of AI governance, risk management is the one gaining weight fastest right now. This guide covers the risks that actually cause incidents in 2026, the four-bucket sort I use when I walk into a new client, how to tier your effort so the program does not collapse under its own weight, and the frameworks worth borrowing instead of inventing.

What you will learn

• The four AI risks that show up in real incident reports
• A risk-tiering approach that fits effort to exposure
• How to govern AI risk you do not own (third-party and embedded)
• A 60-day starter plan that produces evidence, not paperwork

Why risk is the pillar moving fastest

I watch how the professional conversation shifts week by week, and risk assessment has been climbing in real influence even while the generic AI chatter fades. That tells me something specific: the people doing this work have moved past the demo. You do not think hard about risk until you are about to put something into production that can hurt you. A whole industry crossed that line at once.

There is a music-studio version of this. A bedroom producer never thinks about gain staging. The moment you play a real room with a real PA, clipping is the only thing you think about, because now it is audible and it is expensive. AI just got plugged into the real PA. The capability rooms are quieter; the control rooms are louder. Every operator I talk to is making the same shift, and most of them are doing it for the same reason: a peer in their sector had a public failure in 2025 and the board read the headlines.

The honest read on 2026 is that the model is now the smallest part of the risk story. The riskiest AI in most organisations is not the model the data science team is carefully validating. It is the AI nobody on the governance call has heard of: a tool a vendor quietly added to their product, a script an engineer wired up, a chatbot a department signed up for on a credit card.

The four risks that actually cause incidents

Most teams obsess over model risk and ignore the other three. In practice the incidents I hear about cluster in data risk (the unglamorous one), third-party risk (the invisible one), and autonomous-action risk (the new one nobody had to think about two years ago). Let me walk each.

Model risk. The model itself is wrong, biased, or drifts. Model risk teams have lived inside banks for years and they have the vocabulary down: validation, monitoring, challenger models, drift detection. If you come from financial services, this is the comfortable one. The trap is treating model risk as the whole problem when it is the smallest of the four. The model is the bit you can see. The other risks are the bit you cannot.

Data risk. Bad data in, bad decisions out, at machine speed. The data feeding your model is wrong, stale, biased, leaked, or non-compliant. A model trained on unclassified data leaks classified data on demand. A model fed unrepresentative training sets discriminates by accident. This is the risk that 7wData has worked on for fifteen years under a different name (data governance), and AI did not change the problem, it raised the cost of getting it wrong. Mise en place: prep before you cook.

Third-party and embedded risk. Most of your AI risk in 2026 is not in models you built. It is in the AI quietly baked into the tools you already pay for. The CRM added a “smart” summary feature; the support platform added auto-triage; the HR system added a screening score; the security tool added an anomaly classifier. Each one is an AI system, each one carries the same questions a model you built would carry, and each one is invisible on most governance inventories. If a vendor cannot tell you how their AI is trained, monitored, and bounded, you have not bought a tool, you have bought their risk.

Operational and autonomous-action risk. The new category. An assistant that says something wrong is embarrassing; an agent that does something wrong is a liability event. Agents act on systems, move money, send emails, update records. The failure mode is not a wrong answer a human reads and discards. It is a wrong action that lands in a downstream system before anyone notices. The controls are not new (authorisation, audit, a hard stop, a human checkpoint on consequential actions, a termination condition when the agent goes out of its lane). We just have to apply them on purpose, before the agent goes live. The deep dive on the operating model is in Building an AI Governance Framework.

Tier your effort to your exposure

You cannot apply heavy controls to every model. You will run out of people, the controls will rot, and the program will collapse under its own weight. Borrow the risk-tiering logic from the EU AI Act: most systems are low risk and deserve a light touch, a few are high risk and deserve everything you have got. Spend your governance budget where the blast radius is largest. A spam filter and a credit-decision model do not get the same treatment.

The 80/20 of this work is brutal and freeing. Once you accept that twenty systems matter and the other eighty are noise, you can stop spreading the program thin across everything. The cost of trying to govern everything equally is that you govern nothing well. The cost of accepting tiers is one uncomfortable meeting where you tell the team that some of their work will not get scrutiny. That meeting is cheaper than the alternative.

A worked tiering pass I run with clients fits on one page: list every system; for each, mark blast radius (who and how many get hurt if it fails) and reversibility (can you undo the action). Anything high blast plus low reversibility is high tier and gets the full set of controls. Everything else gets an owner and a yearly review. That is it. You will be tempted to add more axes. Resist.

The risk you do not own

The third-party category deserves more than a row in the table because it is where most of your real exposure lives. Three patterns recur.

AI features bolted onto SaaS. The vendor added an AI feature you did not buy and you cannot turn off cleanly. The contract probably allows it; the security review probably did not catch it. Ask procurement to add an AI clause to every renewal: notification of new AI features, ability to opt out, data-use commitments, transparency about subprocessors.

Embedded models you cannot audit. A piece of infrastructure (a fraud screen, a content moderator, an anomaly detector) uses an AI model the vendor will not document. Your obligation under the EU AI Act and most sector rules does not transfer to them; you carry the liability. Either get the documentation, accept the risk in writing, or replace the vendor.

Open-source weights downloaded from a hub. A model you pulled from a registry is not necessarily what its README claims. Provenance matters. Verify checksums, prefer mirrors you trust, and treat weights like any other software dependency: pin versions, log what you deployed, monitor for advisories.

Frameworks worth borrowing

Do not invent a risk taxonomy from a blank page. Two reference points carry most of the weight:

• The NIST AI Risk Management Framework gives you a four-part structure (Govern, Map, Measure, Manage) that maps cleanly onto how enterprise risk programs already run. It is voluntary, travels well across jurisdictions, and the Govern function pairs naturally with the operating model in Building an AI Governance Framework.
• ISO/IEC 23894 is the AI-specific risk guidance that slots into ISO 31000 (the general enterprise risk standard) without re-inventing the wheel. If your organisation already runs an ISO-shaped risk program, this is the cheaper integration path.

Use them as a checklist, not a religion. I have watched teams adopt NIST RMF as a binder and govern less than the team that picked three of its practices and ran them well. The frameworks are scaffolding. The work is what you bolt onto the scaffolding.

A 60-day starter plan that produces evidence

You do not need a year to make this real. Two months is enough to produce something defensible.

Days 1-20: Inventory. List every AI system in use, sanctioned and Shadow. Walk the floor, interview teams; surveys catch what people think they should say, interviews catch the tool they actually opened this morning. By day twenty you have one list, owned by one person, that the CISO and the Data Protection Officer both trust.

Days 21-40: Tier and own. Mark every system on the inventory with a tier (using the blast-radius + reversibility test) and a named owner. The high-tier systems are now the program. Everything else gets a yearly review and an entry on the inventory. Most organisations discover the high-tier list is shorter than they feared.

Days 41-60: Wire and document. For each high-tier system, put the four matching controls in place (the ones in the diagram above), then write the documentation to describe what you actually did, not what you wish you did. Schedule the first quarterly review for day 61. The deliverable at the end of day sixty is not a polished policy. It is a small, true map of your AI exposure with controls actually wired to the few systems that matter.

This is the order that works. I have watched the reverse order (policy first, reality later) fail enough times to know the policy ends up describing a company that does not exist.