D3. Risk Management
AI brings risks that can determine success or failure. The opportunity side is assessed at the strategy level in chapter B1; here the risk side is managed.
What this chapter delivers: the tool to identify, assess, treat, and monitor AI risks. These four steps form the cycle in the figure, and the four numbered sections of this chapter are exactly those steps. The core artifact is the risk register, which carries each individual risk entry through all four steps.
How the parts fit together: the risk areas in step 1 tell you what to look for. Every concrete risk becomes a row in the register and then runs through the remaining steps: assess and compare against the appetite (step 2), choose a treatment strategy (step 3), monitor with a leading indicator and review regularly (step 4).
1. Identify: collect risks and enter them in the register
It starts with the question of which risks even come into play. Seven risk areas recur across AI initiatives. They are the search grid: for each area, the concrete risks of your own initiative are collected, and each of them becomes its own row in the register. One area may thus yield several entries, another none. An often underestimated danger is not the technology but a lack of trust and a lack of interface competence, that is, people who connect technology, law, and culture.
The seven risk areas
| Risk area | Examples of concrete risks (one register entry each) | Read more |
|---|---|---|
| Data protection and regulation | missing legal basis, omitted data protection impact assessment (DPIA), unlawful processing, conflicting requirements per country | chapter B8 |
| Model and output quality | bias and discrimination, hallucination, drift, faulty diagnoses | chapter B10 |
| Security and misuse | prompt injection, leakage of sensitive data, model theft, poisoned training data | chapter B9 |
| Dependency on vendors | vendor lock-in, price or license jump, export controls, outage of a provider | chapter B3 |
| Operations and economics | cost blowout, poor availability, lack of scalability | chapter D2 |
| Skills, acceptance, and culture | talent gap, lack of trust, resistance, ineffective oversight | chapter B11 |
| Generative AI and agents | uncontrolled agent actions, misinformation, copyright infringement | chapter A2 |
Template: risk register
Every concrete risk becomes a row here. At capture, the risk, its category (one of the seven areas), and the owner are entered; the columns from probability to risk score are filled in step 2, the strategy column in step 3. The example row shows a fully completed entry.
| Risk | Category | Probability (1 to 5) | Impact (1 to 5) | Risk score | Strategy | Mitigation | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| Example: API price increase by the model provider | Dependency on vendors | 3 | 4 | 12 | Mitigate | Second vendor qualified, switching path documented | FinOps lead | In progress |
Steering: high-score risks are actively treated and reported to the Portfolio Board (see chapter B7). The register is updated with every new use case and on a fixed cadence.
2. Assess: risk score and approval level
Every entry is assessed twice. First the risk score: probability times impact (each 1 to 5), the product is the score; from about 12 a risk counts as high and demands active treatment with a named owner. Then the comparison against the risk appetite, which defines how much the company deliberately carries.
The appetite is not set per risk area but by the severity of the possible consequence. Every entry, from whichever area, carries such a consequence: a vendor outage hits the company economically, unlawful processing legally. Without this directive, every project decides for itself, and comparable risks get carried in one place and stopped in another.
Template: risk appetite and approval levels
Leadership sets the appetite per consequence type once; from it follows who must approve an overrun. The middle columns show a pattern; each company sets the thresholds to fit its sector and supervision.
| Consequence type | Appetite (pattern) | What this means in practice | Approval when exceeded |
|---|---|---|---|
| Breach of law and data protection | Zero to very low | No initiative goes live before the legal basis is in place; when in doubt, stop | Board; no project discretion |
| Harm to affected persons (fairness, safety) | Low | High-risk cases only with human oversight and a documented trade-off | Risk or ethics committee |
| Reputational damage | Low to medium | Depends on visibility; customer-facing cases stricter than internal ones | Committee, board where visibility is high |
| Economic risk (cost, ROI) | Medium | Deliberate bets allowed as long as the loss is limited and bearable | Portfolio Board |
How to use the template: for every entry, the risk score is compared against the appetite of its consequence type. If it lies above, the approval level in the right-hand column applies: the decision is then no longer a matter of project discretion but the responsibility of the named committee or the board (see chapter B7). The result is a leadership-owned directive against which every later approval is measured.
3. Treat: one strategy per entry
Assessment alone changes nothing. For every entry in the register, exactly one of the four strategies is now chosen and recorded in the strategy column. Without this decision, the register remains a watch list without effect.
| Strategy | What it means | AI-typical example |
|---|---|---|
| Avoid | Do not implement the risky use, or implement it differently | Forgo fully automated decisions, a human decides (which also lowers the regulatory classification, see chapter B8) |
| Mitigate | Reduce probability or impact through measures | Protection architecture and human-in-the-loop (see chapter B9), fairness countermeasures (see chapter B10), a second vendor against lock-in |
| Transfer | Shift the risk contractually or via insurance | Contractual penalties and liability rules with the vendor (see chapter B3), cyber insurance; note: reputational and regulatory accountability stays with the deployer |
| Accept | Carry the residual risk deliberately and documented | A low hallucination rate for an internal assistant with trained users; with justification, owner, and review date |
Principle: accepting is legitimate, silently accepting is not. Every acceptance decision carries a name and a resubmission date.
4. Monitor: warn early and stay current
A treated risk is not a closed risk. The final step keeps the register alive: leading indicators warn before a risk turns into damage, and fixed triggers force reassessment.
Leading indicators
Leading indicators are metrics that deteriorate before a risk turns into damage. They connect risk management to the ongoing measurement system (see chapter D1). For each material risk, an indicator with a threshold is set whose breach triggers a review:
| Risk | Leading indicator | What the deterioration signals |
|---|---|---|
| Declining model quality | Rising drift, falling hit rate | The model no longer matches reality, wrong decisions accumulate |
| Slipping generative quality | Rising hallucination rate, rising intervention and faulty-action rate for agents | The generative or agentic solution becomes unreliable |
| Ineffective oversight | Override rate near zero at high case volume | Human review merely rubber-stamps (see chapter B10) |
| Waning adoption | Falling usage rate over several measurement points, falling training coverage | The use case delivers no value because it is not used |
| Cost blowout | Cost per request over budget, rising trend | Ongoing operation becomes uneconomical |
| Growing vendor dependency | Rising share of volume with one vendor, contract expiry approaching without an alternative | Switching becomes increasingly unaffordable |
| Worsening security situation | Rising rate of intercepted attacks, more anomalies | The system comes under increasing pressure |
Not every risk announces itself through a trend. Abrupt, event-driven risks such as a new regulation, a sudden vendor exit, or a single severe incident have no leading indicator; they are caught by the triggers in the next section.
Ongoing review
A risk register is only as good as its currency. Fixed triggers for reassessment:
| Trigger | What to check |
|---|---|
| New use case | Full reassessment using the standard register |
| Substantial change to the system (data, model, function, integration) | Impact on existing risk scores, especially fairness and robustness |
| Expansion of use (more users, new region, higher volume) | Reach and potential harm grow; reassess affected risks |
| Vendor or model change (exit, deprecation, price or terms change) | Reassess dependency and cost risk, check the fallback plan |
| Regulatory change | Reconcile with chapter B8, new deadlines and obligations |
| Incident (security, quality, or harm to affected persons, including at third parties and vendors) | Immediate reassessment of affected risks, regardless of the regular cadence |
| Leading indicator breaches its threshold | Reassess the affected risk before damage occurs |
| Fixed cadence (at least quarterly) | Walk through the entire register, close resolved risks, add new ones |
Embedding into enterprise risk management
The entire cycle does not run in a parallel system but within the existing enterprise risk management. The risk register from this chapter is its extension, not a rival to it:
- One register, one methodology: the same assessment logic and escalation paths as for other corporate risks; AI risks get their own category, not their own tool.
- Use existing bodies: the Portfolio Board steers operational AI risks; material risks flow into the existing risk committee and the board report (see chapter D4).
- Regulated industries: the AI risk register simultaneously serves the supervisory requirements (MaRisk/MaGo, DORA) and the risk management obligation of the EU AI Act (Art. 9 for providers, and for deployers the corresponding obligations under Art. 26); shared artifacts instead of duplicate documentation.
- Feedback from incidents: findings from security and quality incidents flow into the register as new or reassessed risks.
Checklist: risk management before the start
The checklist follows the four steps of the cycle; open items are the next steps:
- All seven risk areas worked through, concrete risks per area entered in the register (category and owner set)
- Risks specific to generative AI and agents captured: hallucination, prompt injection, uncontrolled actions
- Dependency and vendor lock-in risk captured
- Risk score calculated per entry (probability times impact)
- Risk appetite set per consequence type, approval level tied to risk score and appetite
- Regulatory classification considered
- Treatment strategy explicitly chosen per entry (avoid, mitigate, transfer, accept)
- Every acceptance decision carries a rationale, an owner, and a review date
- Leading indicator with a threshold set per material risk and connected to the measurement system
- Triggers for reassessment defined and anchored in the Portfolio Board
- Feedback from security and quality incidents into the register regulated
- Fixed cadence for the overall register review established
- Register embedded into enterprise risk management, no parallel structure