The risks of AI, mapped.
Most talk about "AI risk" is either science fiction or a compliance checklist — and neither helps you decide anything. The useful truth is narrower and calmer: the real risks are knowable, and they enter your work in four places. Here's the map, the risks most people miss, and how to turn a map into something you can actually manage.
Not Skynet. Not a checklist.
The question that paralyses people — "is AI dangerous?" — has no useful answer, because it asks about the technology in the abstract. The question that pays is sharper: where, in our use of it, does risk actually enter? Ask it that way and the fog clears. Risk isn't one big cloud hanging over "AI"; it enters at four specific points, and each point has its own, very ordinary, failure modes.
Map it that way and two things follow. You stop worrying about the wrong things — and you start seeing the real ones early enough to do something about them.
Four places risk gets in.
We didn't invent this shape. It mirrors how the most rigorous risk maps — notably IBM's AI Risk Atlas — sort the danger: not by how frightening it sounds, but by where in a system's life it appears. The Atlas calls them input, inference, output and non-technical risks; in plainer words, four places — from the data going in to the way you govern the lot.
The data going in
What the model learned from — and what you feed it in the moment.
- Bias inherited from skewed or unrepresentative training data
- Confidential or personal data leaking in through prompts
- Copyright and IP exposure from data the model was never licensed to use
- Data poisoning — tampered inputs that quietly corrupt how it behaves
The way you use it
How the system can be pushed, tricked or probed once it is running.
- Prompt injection — hidden instructions that hijack what it does
- Jailbreaking — talking it past its own guardrails
- Extraction — coaxing out training data, or another user’s secrets
- Adversarial inputs crafted to make it fail
What comes back
The content it returns — and whether you can trust or explain it.
- Hallucination — fluent, confident and wrong
- Toxic, biased or otherwise harmful content
- Copyright infringement carried in the output itself
- Opaque decisions you cannot explain to the person they affect
What you do with it
The non-technical layer — where most real-world damage is actually decided.
- Over-reliance — a human who waves it through
- No clear owner when it goes wrong
- No logs, no monitoring, no way to prove what happened
- Lost trust, the day the gap is discovered
The same model can be safe in one zone and dangerous in another. A brilliant system fed the wrong data, or left without an owner, is still a problem — which is why a single "is it safe?" verdict never holds. You assess it zone by zone. And as AI shifts from chatbots to agents — systems that act, not just answer — every one of these risks is amplified: the tool now takes its own steps between your prompt and the outcome, with fewer moments where a human is looking.
The danger isn't only in the model. It's in how you trust it.
Almost every published risk list stops at the technology. But the most common way an AI causes harm in a real organisation isn't a dramatic failure of the model — it's a quiet failure of the human beside it. Put a capable tool in a workflow and human judgement starts to switch itself off, in predictable, well-documented ways:
The system doesn't have to fail for the decision to. A confident wrong answer and a tired human who nods it through is enough.
This is why "keep a human in the loop" is necessary but not sufficient — a human who rubber-stamps is a loop in name only. The fix is a deliberate habit of checking, built into the role: treat each output as a junior's first draft, verify what matters before you sign, and keep people doing enough of the work themselves that the judgement stays sharp.
And then there's the AI you never approved.
Every zone above assumes you know which systems you're running. Most organisations don't. Your staff are already using AI tools nobody signed off — often feeding them real, sometimes confidential, material, and rarely telling anyone. It isn't malice; it's people trying to get their work done. But it means the risks on this map are live in places you can't see, governed by no one.
Banning it doesn't make it stop — it makes it invisible. Why that happens, and what actually works instead, is its own guide: Shadow AI, explained.
What the regulator sees is a subset of this map.
The EU AI Act sorts AI systems by how much risk they pose to people's rights and safety — a few uses are banned outright, a defined set is high-risk and heavily regulated, some carry transparency duties, and the rest are largely free. That legal lens is essential, and it's the one with penalties attached. New to it? Start with the EU AI Act, explained.
But notice what it is: a subset. The Act is concerned with a specific slice of this map — the harms a legislator chose to regulate. A system can be entirely legal and still hallucinate you into a costly decision, or quietly deskill your team, or leak data through a side door the law never named. Compliance is a floor, not the whole picture. The risks the law doesn't reach are still yours to carry.
A risk you can name is a risk you can control.
A map is only worth having if you act on it — and the payoff of this one is that every risk on it has a matching control. Bias and leakage in the inputs answer to data hygiene and access rules. Injection and jailbreaks answer to prompt and permission controls. Hallucination and opaque output answer to human-review rules that actually bite. The governance zone answers to logging, monitoring and a named owner. Wiring those controls to the risks — and being able to show you did — is what governance actually is.
Stripped of jargon, governance is the capacity to say what your systems do, to whom, on what basis, and what happens when they're wrong — and to prove it. It isn't a binder or a job title; it's an operating model. We cover the what and why in AI governance, explained, and the who owns it in who owns AI governance?.
You can't manage a risk you've never named. The whole point of the map is to make the danger specific — and specific risks have specific answers.
We map your real AI uses — then match each risk to a control you can run.
We take the AI you're actually using — sanctioned and shadow — and place it on this picture: which zones it touches, which risks are live, which are noise for your context. Then we match each one to a proportionate control, prioritise by what would actually hurt, and build the capability in your team to keep it running. When there's a regulatory clock, that work runs through the AI Act Compliance Accelerator; when it's about the operating model, through the governance advisory.
Worried about the wrong risks? Bring your AI and we'll map the real ones.
Thirty minutes, an honest read of where the risk actually sits. No pitch.
Book a discovery call →Related guides
AI governance, explained
What it is, why it pays for itself, and how to make it live in your people instead of a binder nobody reads.
Read the guide Shadow AIShadow AI, explained
Your staff already use AI you haven’t approved. Why banning it fails — and what works instead.
Read the guide