Write your AI risk tolerance as a short set of statements by risk tier: what harm is acceptable, what needs approval, and what is off limits. The NIST AI RMF does not prescribe a tolerance, so each organization has to define its own and record it under MAP 1.5.
What NIST says
The framework defines risk tolerance as the organization's or AI actor's readiness to bear risk to achieve its objectives. It says tolerance is contextual, use-case specific, shaped by law and policy, and likely to change as systems and norms evolve. Where established guidelines do not exist, organizations should define a reasonable tolerance. Once defined, the framework can be used to manage risks and document the process.
Step 1: pick the dimensions
Choose four to six things you care about. Examples: customer harm, privacy exposure, security exposure, legal and regulatory exposure, financial loss, reputational damage, and over-reliance on unverified output.
Step 2: define levels per dimension
Use plain descriptions. For privacy exposure, for example:
- Low: no personal data processed.
- Moderate: limited personal data, with a vetted vendor and contractual limits.
- High: sensitive personal data or decisions about individuals.
Anything in the high band needs a named executive's approval and stronger testing.
Step 3: link levels to required controls
Tolerance becomes useful when it changes behavior. A table works: low-tier systems need an inventory entry and an owner; moderate adds pre-deployment testing and monitoring; high adds an impact assessment, independent review, and a documented rollback plan.
Step 4: set hard limits
State the uses you will not pursue, such as fully automated adverse decisions about individuals without human review. NIST also says that where a system presents unacceptable risk, such as imminent or occurring severe harm, development and deployment should stop safely until risks can be managed.
Step 5: assign sign-off and review
Say who can accept risk at each level and how long acceptance lasts. NIST's MEASURE 2.6 expects residual negative risk not to exceed the tolerance before deployment, so you need a number or a description to compare against.
Review the statement at least annually, and after any significant incident.
A worked example
Suppose you run a support assistant. Under customer harm, you might state: wrong answers about billing are tolerable if a person can correct them within a day, and wrong answers about account closure are not tolerable without human review. Under privacy, no sensitive categories of personal data may be sent to the assistant. Under security, the assistant gets read-only access to the knowledge base and no tool that changes records. Each statement is specific enough to test.
Quick check
Can we copy another company's tolerance statement?
Use it as a draft only. Tolerance depends on your objectives, regulators and customers.
Does zero risk make sense?
NIST notes that trying to eliminate risk entirely can be counterproductive, since not all incidents and failures can be eliminated.
Sources
Last reviewed: 19 October 2026.
