Intelligence in Risk Advisory + Compliance

AI Risk Tolerance Is Your Organization's Most Dangerous Undefined Variable

By Josh Fleming
Posted on Jun 03 / 2026

Intro

Most organizations responded to the AI surge by drafting acceptable use policies. Some went further and stood up AI governance committees. Almost none started where they should have: defining how much AI risk they're willing to accept, in which use cases, under what conditions, and with what escalation thresholds. 

That's the equivalent of writing firewall rules without a network security policy behind them. The policies exist, but without a risk appetite anchor, every AI decision gets improvised. And improvisation at scale is how you create liability you can't explain to a regulator.

Policy without risk appetite is just performance

Here's a pattern we see over and over in AI governance assessments. An organization has an AI acceptable use policy, maybe even a model inventory and a review board. But when you ask the executive team a direct question, "What level of AI risk is this organization willing to accept in customer-facing applications versus internal productivity tools?" the room goes quiet. 

That quiet is where the problem lives. It means every AI deployment decision is being made on the fly by whoever talks loudest or has the tightest deadline. There's no consistent threshold for when a use case needs deeper due diligence, when it requires board approval, or when it should be killed outright. NIST's AI Risk Management Framework deliberately does not define risk tolerance. It leaves that to each organization. And as one governance firm put it recently, undefined risk appetite is one of the primary friction points in AI governance programs, because controls tell you how systems operate, but risk appetite tells you how decisions get made. 

Without a defined risk appetite, you can't build a consistent policy. You can't tier your AI inventory by risk level. You can't staff governance proportionally. And you can't explain to a regulator why you approved one use case and blocked another. 

Risk tolerance has to come before policy

Risk tolerance is the decision that gives policy its meaning. When an organization defines its AI risk appetite, it's answering the questions that actually matter:

Are we willing to deploy AI in decisions that affect people's rights, employment, or financial access? Under what conditions?

Where do we require a human in the loop, and where are we comfortable with full automation?

How do we treat internal experimentation differently from production systems that touch customers, patients, or regulated populations?

These are not security questions. They are business strategy questions with risk dimensions. And they have to be answered before anyone writes a policy, because a policy's job is to operationalize the appetite, not to invent it retroactively.

How we run an executive risk tolerance workshop

Defining AI risk appetite is not a single meeting, but it does start with one. Here's the structure we use at Echelon Risk + Cyber:

Do the Homework: 

Your team should already have a current inventory of AI systems in use, including shadow AI, organized by function and data sensitivity. This gives the workshop real scenarios to work from instead of hypotheticals. 

Align the Room with Risk Dimensions:

Walk the executive team through the types of AI risk that apply to your organization: model accuracy, data privacy and provenance, bias, transparency, third-party dependency, and regulatory exposure. You're not scoring anything yet. The point is to get the leadership team working from the same vocabulary. We've run sessions where the CRO and the CTO couldn't agree on what "AI risk" meant. You want that disagreement to surface early, in the room, not six months later when a deployment goes sideways. 

Move to Tiered Tolerance Definitions:

Using the AI inventory as input, map risk tiers to your context. A model we've deployed in practice uses four tiers. Tier 1 covers minimal risk internal tools with no customer or regulated data exposure. Tier 2 covers internal tools that touch sensitive data and need standard controls. Tier 3 covers customer-facing or decision-influencing AI that needs enhanced review, human oversight, and ongoing monitoring. Tier 4 covers high-risk applications under the EU AI Act or similar regulatory scrutiny, where you need board approval and continuous compliance monitoring. 

This tiering aligns to the EU AI Act's four-level risk classification (unacceptable, high, limited, minimal) and maps to NIST AI RMF functions (Govern, Map, Measure, Manage). One framework, multiple regulatory reference points. 

Define escalation paths and decision rights:

Who approves deployments at each tier? What triggers a re-evaluation: model drift, a regulatory change, or an incident? What happens when a use case doesn't fit cleanly into a tier? These edge cases are where most governance programs fall apart, so spend time on them. 

The output is a documented AI risk appetite statement, ratified by executive leadership, that becomes the reference point for every AI policy, procedure, and deployment decision that follows.

If your organization has AI policies but no defined risk appetite, you built the house before you poured the foundation. Policy decisions are unanchored. Governance reviews are subjective. And the first serious regulatory inquiry will find the gap. Defining risk tolerance is not academic work. It is the governance decision that makes every other AI decision defensible. Do it now, on your terms, or do it later under pressure from an auditor or a regulator. The second version is always worse.

Echelon's AI Governance services help organizations work through exactly this, from defining risk tolerance to building the governance structure around it. 

Are you ready to get started?