An AI risk framework is a structured model for identifying, organizing, and assigning ownership of the risks an organization takes on by building or using AI systems. Some frameworks govern how AI risk is managed. Others locate where that risk actually surfaces.
Key takeaways
- An AI risk framework organizes AI risk so teams can identify it, measure it, and assign an owner.
- AI risk management frameworks govern the process, while AI security risk frameworks locate where risk surfaces in a live environment.
- Most organizations need both, because the two answer different questions.
- Common examples of AI risk frameworks include the NIST AI RMF, MITRE ATLAS, the OWASP Top 10 for LLM Applications, and Expel’s AI security risk framework.
- Passing a compliance audit doesn’t mean AI risk is covered, because compliance and risk control are different jobs.
Search for “AI risk framework” and most of what comes back is about governance: how to set policy, document decisions, and report risk to a board. That’s useful, but it’s only half the picture. Security teams also need to know where AI risk actually shows up—in which identities, data flows, and agent actions—and who’s responsible for each. Those are two different kinds of frameworks, and confusing them is how gaps form. This page explains the difference, what a good framework should include, and how common frameworks fit together. For a worked example of the security kind, see Expel’s guide to thinking about AI security risk, which maps AI risk to ten domains and six control planes.
What’s the difference between an AI security risk framework and an AI risk management framework?
A risk management framework defines the governance process: how an organization identifies, measures, and reports AI risk, and who signs off. A security risk framework identifies where that risk surfaces technically and which team controls each point.
Put simply, one tells you how to govern AI risk. The other tells you where to look for it.
| AI risk management framework | AI security risk framework | |
|---|---|---|
|
Purpose |
Governs how AI risk is identified, measured, and reported | Locates where AI risk surfaces in a live environment |
|
What it answers |
Do we have a sound process for managing AI risk? | Where can AI risk hurt us, and who can act on it? |
|
Who typically owns it |
Governance, risk, and compliance (GRC), legal, and risk committees | Security leaders and the teams that run identity, data, cloud, and detection |
Most organizations need both. A governance framework without a security framework produces policies nobody can enforce. A security framework without governance produces controls nobody’s accountable for.
What should an AI risk framework include?
Whatever its purpose, a usable framework does three things:
- It names the risk categories. Vague buckets like “AI misuse” don’t help anyone prioritize. Categories should be specific enough that a team can tell whether a given incident belongs to them.
- It says where each risk is enforced or measured. A category without an enforcement point is a worry, not a control. A good framework connects each risk to the layer where it can be observed and acted on, like identity, data, or execution. Expel calls these layers security control planes.
- It makes ownership assignable. AI risk crosses team boundaries. A framework should let a security leader route work down to the teams that can fix it and report up to leadership in terms they can act on.
It should also account for whether you can reconstruct what an AI system did after the fact. If you can’t, none of the other controls can be verified. We cover that in depth in our what is security observability? page.
What are some examples of AI risk frameworks?
Each of these does a different job. They’re complementary, not competing. If you’re newer to the space, our overview of AI in cybersecurity is a good place to start.
- NIST AI Risk Management Framework (AI RMF): A governance framework from the National Institute of Standards and Technology that organizes AI risk management into four functions: govern, map, measure, and manage.
- MITRE ATLAS: A knowledge base of real-world tactics and techniques bad actors use against AI and machine learning systems. See our guide to MITRE ATLAS.
- OWASP Top 10 for LLM Applications: A ranked list of the most critical application-level vulnerabilities in large language model (LLM) apps, such as prompt injection.
- Expel’s AI security risk framework: An operational framework that maps where AI risk surfaces across ten risk domains and six control planes.
Do you need an AI risk framework if you already follow the NIST AI RMF?
Often, yes. The NIST AI RMF is a strong governance foundation, and it’s voluntary and intentionally flexible. It tells you to map and measure AI risk. It stops short of naming where that risk surfaces in a live environment or which security control catches it.
That’s the gap a security risk framework fills—it gives teams specific domains to instrument, measure, and assign to owners. “Measure AI risk” turns into “log prompts for this agent, restrict that service account, and review this data flow.”
The two work together. Use NIST to structure governance and reporting. Use a security risk framework to decide what your security team actually does on Monday morning.
How do you put an AI risk framework to work?
- Start with an inventory. List every AI system you build or use, including AI features inside SaaS tools and agents with their own credentials.
- Decide which question you need answered. If the board wants to know whether AI risk is governed, start with a management framework. If your SOC needs to know where to look, start with a security framework.
- Map each risk to an owner. Every category should have a team that can act on it, not just a team that reports on it.
- Check what you can observe. For each risk, confirm you can reconstruct the activity after the fact. If you can’t, fix that first.
- Revisit as AI use changes. New agents, models, and integrations change your risk surface faster than annual reviews can keep up.
Expel’s take
We built our AI security risk framework because the frameworks we had didn’t answer the question our SOC actually faces: when AI is involved in an incident, where did control fail, and who could have caught it? Governance frameworks tell you to manage AI risk, but they don’t tell an analyst which identity, data flow, or agent action to examine first.
The framework, authored by James Shank, Expel’s Director of Threat Operations, splits AI risk into ten domains (where risk surfaces) and six control planes (where control is held or lost). It’s grounded in what we see across customer environments, where AI-related activity rarely stays in one lane. A single instruction manipulation attack can touch data access, agent execution, and logging at once.
We’re not arguing anyone should drop NIST. Instead, we’re arguing that governance and security are different jobs, and a security team needs a map built for its own.
Frequently asked questions
What is an AI risk framework?
An AI risk framework is a structured model for identifying and assigning ownership of the risks created by building or using AI systems. Some frameworks govern the risk management process, like the NIST AI RMF. Others locate where risk surfaces operationally, like Expel’s ten risk domains.
What’s the difference between an AI security risk framework and an AI risk management framework?
A risk management framework defines the governance process: how an organization identifies, measures, and reports AI risk. A security risk framework identifies where that risk actually surfaces technically and who controls each point. They answer different questions, and most organizations need both.
What should an AI risk framework include?
A usable framework names the risk categories, says where each one is enforced or measured, and makes ownership assignable across teams. Expel’s framework does this with ten risk domains mapped to six control planes, so a security leader can route work down and report up.
Do you need an AI risk framework if you already follow the NIST AI RMF?
Often, yes, because they do different jobs. The NIST AI RMF defines the governance process but stops short of naming where AI risk surfaces in a live environment. A security risk framework fills that gap, giving teams specific domains to instrument, measure, and assign to owners.
Are AI risk frameworks the same as compliance frameworks?
No. Compliance frameworks measure conformance against an external standard such as GDPR or the EU AI Act. AI risk frameworks organize risk for internal decision-making and ownership. A framework can support a compliance program without being one, and passing an audit doesn’t mean risk is covered.