The Risks of AI: A Board-Level Taxonomy That Prices the Downside
Most AI risk lists are written for ethicists, not directors. The risks that actually destroy enterprise value sort into six categories a board can own and price — capability, cost, regulatory, security, dependency, and reputational. The honest version, with the mechanism behind each and what a wrong call costs.
The question that ended a strategy session I sat in on last spring was not about a model. It was a non-executive director, three items into an AI investment paper, asking the management team what the worst realistic outcome of the programme was and what it would cost. The paper had a risk section. The risk section had nine bullet points: algorithmic bias, hallucination, data privacy, workforce impact, third-party dependency, model drift, regulatory uncertainty, reputational harm, and ethical alignment. The director read them aloud, then asked which one the company would lose the most money to, in what year, and who on the executive team was accountable for it. Nobody could answer. The list was complete and useless at the same time — it named every risk a magazine article would name and priced none of them. The board approved the paper anyway, which was the second failure.
That is the shape of the problem with how the risks of AI are usually discussed. The public conversation about AI risk is an ethics conversation, and it is a worthwhile one, but it is not the conversation a board is equipped to have or accountable for having. A director cannot own “algorithmic bias” as a line item. A director can own “the customer-facing system makes decisions we cannot defend in a regulatory audit, the exposure is roughly this large, and the accountable executive is the CISO jointly with the DPO.” The first is a topic. The second is a risk. The work of governing AI risk is the work of turning the topics into risks — into categories with owners, exposures, and budget lines — and the public lists do not do that work for you.
I am writing this taxonomy because the search behind “risks of ai” and “enterprise ai risks” splits cleanly into two intents, and the high-volume content serves only one of them. The general searcher wants the ethics overview, and they are well served. The decision-maker wants the version that maps risk onto accountability and cost, and they are not. This page is for the second reader. The six categories below are the ones I check first on any engagement, ordered roughly by how early they bite rather than by how dramatic they sound.
Risk one: capability risk — the system does not reliably do the job
The most common way an AI programme destroys value is the least dramatic. The system does not do the thing it was funded to do, reliably, on real input rather than demo input. Capability risk is the gap between the pilot that worked on the curated test set and the production system that meets the long tail of real-world cases the test set did not contain. It bites first because it surfaces the moment the system meets production traffic, and it bites hardest in customer-facing generative work, where the failure is visible to the people whose trust the system was meant to earn.
The mechanism is distribution shift, and it is structural rather than a matter of effort. A demo is built on inputs the team chose; production runs on inputs the world chooses, and the world’s distribution has a tail the demo did not sample. A document-triage assistant that is 95% accurate on the evaluation set can be 78% accurate on live mail because live mail contains formats, languages, and edge cases the evaluation set under-weighted. The 17-point gap is not a bug to be fixed; it is the cost of having validated against the wrong distribution. The board-relevant fact is that this gap is predictable in direction and roughly estimable in size before deployment, and most business cases do not estimate it.
Capability risk is owned by whoever owns the capability’s P&L — usually the CTO or a business-unit lead, not a central AI function. The exposure is measurable: it is the difference between the funded business case and the achievable performance, expressed in whatever unit the case was built in. The governing discipline is to require every business case to state the evaluation distribution explicitly and to fund a production-shadow phase before committing to the headcount or process changes that assume the capability works. I have written the per-cluster failure rates that quantify this elsewhere; customer-facing generative work fails at roughly 70% against its original business case, infrastructure-facing AI at roughly 30%, and the cost of those failures is itemisable rather than mysterious.
Risk two: cost risk — the unit economics move under you
The second risk to bite is the one the business case is least built to absorb. The cost-per-call, cost-per-token, or cost-per-resolved-task figure that justified the investment was a snapshot of a fast-moving pricing market, and it will be a different number within a year. Cost risk is the exposure created by treating a variable input as a fixed one. It arrives later than capability risk — usually around month nine — and it is more insidious because the system is working; it is simply costing what the business case said it would not.
The mechanism is the volatility of the underlying model market, and it is asymmetric. Commodity capabilities get cheaper as providers compete, often by 50% to 80% over eighteen months; frontier capabilities arrive at a premium and stay there. A programme that locked its business case to a specific cost-per-call is exposed in both directions — it over-pays for the commodity work it could have re-architected onto a cheaper model, and it under-budgets for the frontier work it wants to add. The board-relevant exposure is the unhedged delta between the business-case cost and the realised cost, and it compounds across every capability built on the same pricing assumption.
Cost risk is owned by the same P&L holder as capability risk, and the governing discipline is to mark every cost figure in a business case as snapshot-dated and to reserve engineering capacity for a cost re-architecture at least once a year. This is part of a broader set of structural facts about the AI market that I have catalogued as strategy considerations — the appendix material that decides whether the visible decisions in a strategy survive their second year. Cost volatility is the one of those that bites the most reliably.
Risk three: regulatory risk — the obligation you acquired without noticing
Regulatory risk is the category most enterprises handle as a compliance afterthought and most regulators are now handling as a priority. The risk is that a deployed system carries an obligation the organisation did not price at approval time — a high-risk classification under the EU AI Act, a lawful-basis problem under GDPR, a sectoral rule in financial services or health that the AI layer triggered. It bites later than cost risk because enforcement lags deployment, and it costs more per incident because the remedy is often to stop the system, not to patch it.
The mechanism worth understanding at board level is that the EU AI Act preserves GDPR rather than replacing it, so an enterprise portfolio acquires both sets of obligations simultaneously, and the interaction between them compounds at portfolio scale in ways per-use-case reviews never surface. The August 2026 high-risk obligations bite on a fixed calendar that is public and rarely tracked by operating teams. The board-relevant exposure is not the fine, which is bounded; it is the operational cost of a forced stop on a customer-facing system the business has come to depend on, plus the licence-to-operate damage of being the named enforcement example.
Regulatory risk is owned by the DPO and general counsel jointly, never by the engineering function alone, and the governing discipline is a regulatory cross-walk with a named owner and a quarterly refresh cadence. A cross-walk that nobody maintains is worse than none, because it manufactures false confidence. The governance landscape holds the operational detail on which frameworks apply when; what belongs at board level is the acknowledgement that regulatory consistency across the portfolio costs roughly one full-time equivalent for a mid-sized enterprise and rises every quarter as the landscape thickens.
Risk four: security risk — a new attack surface, not the old one
AI security risk is not a rebrand of the security risk the CISO already manages. It is a genuinely new attack surface with failure modes the existing security programme was not built to detect. Prompt injection, training-data poisoning, model extraction, and the use of an over-permissioned AI agent as a lateral-movement vector are not variants of the threats in the existing register; they are additions to it. The risk bites whenever the system is exposed to adversarial input, which for any customer-facing or tool-using deployment is immediately.
The mechanism that makes this category distinct is that AI systems take instructions and data through the same channel. A traditional application separates code from input; a language model reads its instructions and its untrusted input in the same context window, which means untrusted input can rewrite the instructions. An agent with tool access and a poorly bounded permission set is a confused deputy waiting for an adversary to point it somewhere. The board-relevant fact is that the NIST AI Risk Management Framework and the emerging red-teaming practice treat these as first-class threats, and a security programme that has not added them is exposed to a class of incident it cannot currently see.
Security risk is owned by the CISO, with the explicit mandate to treat AI deployments as a distinct surface requiring AI-specific testing rather than as another application behind the existing controls. The governing discipline is adversarial testing before deployment and bounded, least-privilege permissions for any agent with tool access. The mistake worth naming is the assumption that the existing security posture covers the new surface; it does not, and the gap is invisible until the first incident makes it visible.
Risk five: dependency risk — concentration you built without deciding to
Dependency risk is the exposure created by concentrating critical capabilities on a small number of external providers whose decisions you do not control. It is structurally different from traditional vendor risk because the switching cost in AI is not data export; it is the re-doing of prompt-engineering work, evaluation harnesses, and the institutional knowledge built around one model’s behaviour. The risk bites when a provider raises prices, deprecates a model, changes terms, or suffers an outage — and at portfolio scale, five capabilities built on the same provider are exposed to that single decision simultaneously.
The mechanism is that shared infrastructure lowers build cost and raises switching cost at the same time, and most programmes optimise the first without measuring the second. Building five capabilities against one provider’s models is efficient until the provider’s roadmap and yours diverge, at which point the portfolio-level switching cost is far larger than five times the single-capability cost, because the shared harness is single-provider-shaped. This is a board-level risk precisely because it crosses every capability and every seat; no single P&L owner sees the concentration that the portfolio carries.
Dependency risk is therefore a board-level and CTO-level concern jointly, and the governing discipline is deliberate multi-provider capability for at least the most critical workstreams, with an evaluation harness built from the start to run the same test suite against more than one provider. The cost is roughly 15% to 25% of platform-engineering capacity. The benefit is that the dependency stops being an unpriced concentration and becomes a measured, hedged parameter — which is the only form in which a board can actually govern it.
Risk six: reputational risk — the incident that prices the others
Reputational risk is the category that converts every other risk into a number the market notices. It is the exposure that a capability failure, a regulatory breach, a security incident, or a visibly bad AI-mediated decision becomes a public event that damages trust faster than the underlying problem damages operations. It bites rarely and costs the most per incident, which is exactly why it is the hardest to govern well — the data is sparse, the temptation to treat it as someone else’s problem is strong, and the incident that proves it real is the one you were trying to avoid budgeting for.
The mechanism is that AI failures are legible to the public in a way that most operational failures are not. A mispriced product is an internal problem; a chatbot that gives a customer harmful advice, a hiring model that produces a discriminatory pattern, or an automated decision the company cannot explain becomes a story, and the story prices the company’s entire AI posture, not just the one system. The board-relevant fact is that reputational exposure is correlated with the other five categories rather than independent of them — it is the amplifier, and it amplifies the failures you did not govern.
Reputational risk is owned at board level because it crosses every seat and every capability, and the governing discipline is a pre-agreed incident-response posture for AI-specific failures: who speaks, how fast, with what authority to pause a system. The organisations that handle an AI incident well are the ones that decided how they would handle it before it happened. The ones that handle it badly are the ones that treated reputational risk as the category too vague to plan for, which is the same category it amplified.
How the six sit together
The taxonomy is not a checklist to be scored once and filed. The six categories interact, and the interactions are where the surprises live. Capability risk realised in a customer-facing system becomes reputational risk. Cost risk left unhedged forces the corner-cutting that creates security risk. Dependency risk turns a provider’s regulatory problem into yours. Governing the categories in isolation — one owner per cell, no view of the interactions — is the governance failure that the nine-bullet risk paper at the start of this page embodied. Every risk was named; no interaction was, and the interactions are what cost the money.
The discipline that makes the taxonomy useful is the one the non-executive director was reaching for: for each category, name the owner, estimate the exposure, and reserve the budget. A risk with an owner, a number, and a budget line is a risk the board can govern. A risk that is only a topic on a slide is a risk the board has acknowledged and not addressed, which is the more dangerous state because it looks like governance and is not. The enterprise governance framework holds the operational structure for assigning the owners and running the quarterly review; this page is the input to it — the map of what the categories actually are.
What I would do on Monday morning
If you are a director or executive holding an AI investment paper, do the exercise the non-executive director did. Take the risk section and ask, for each item, which executive is accountable, what the exposure is in money or licence to operate, and in what year it bites. The items that survive that test are risks. The items that do not are topics, and they belong in a different document. A risk section that survives the test will be shorter than the nine-bullet version and far more useful, because it will be governable.
If you are writing the paper rather than reading it, build the risk section from the six categories above rather than from the public lists. Assign each an owner from the existing executive team, not a new acronym. Estimate each exposure even when the estimate is rough — a rough number the board can interrogate beats a precise topic it cannot. And name the interactions explicitly, because the interactions are the part the nine-bullet version always omits and the part the second-year incident always exploits. The honest version of an AI risk section is the one that prices the downside. Everything else is documentation of the fact that the downside was mentioned.
Sources & methodology
- EU AI Act, Regulation (EU) 2024/1689 — the regulatory anchor for risk three, including the August 2026 high-risk obligations calendar
- NIST AI Risk Management Framework, v1.0 — the public-domain reference underwriting the security and post-deployment-monitoring practice in risks one and four
- ISO/IEC 42001:2023, AI management systems — the management-system standard relevant to assigning owners and review cadence across the taxonomy
- Methodology: the category ordering, the per-cluster capability-failure ranges, and the per-category cost figures are drawn from approximately forty enterprise AI programmes audited or run between 2023 and 2026, anonymised. Figures are medians observed in mid-sized European enterprise engagements and will differ by geography and sector.
If your organisation carries a seventh category this taxonomy misses — and some regulated sectors do — send it and I will publish the addition with attribution.
