Not every AI use case deserves the same depth of review, and applying uniform scrutiny across every system wastes effort on low-risk features while potentially under-scrutinizing the genuinely high-risk ones. A practical risk classification framework needs to predict actual worst-case impact reliably enough to point review effort in the right direction, using factors that actually correlate with harm rather than factors that just feel significant.
Action capability is the strongest predictor of impact
The single most predictive factor for an AI use case's worst-case impact is whether it can take real-world action, and if so, what kind. A system that only produces text a human reads has a bounded worst case: a wrong or inappropriate answer. A system that can send money, modify records, or communicate externally on the organization's behalf has a worst case scaled to whatever that action allows, largely independent of how good the underlying model even is. Classification should weight this factor heavily, often more heavily than factors like a system's apparent sophistication or how much internal attention it's gotten.
Data sensitivity is the second major factor
What data a system touches, and how sensitive that data is, decides the worst-case impact of a data exposure failure specifically. A system working only with publicly available information carries limited data exposure risk no matter what else is going on. A system touching personal health information, financial data, or legally privileged content carries elevated data exposure risk that deserves classification weight on its own, whether or not the system can also take action.
Reach determines how many people a failure can affect
A system's reach, how many users can interact with it and how easily an adversary can reach it, affects both the likelihood of an attack attempt and the scale of a failure's consequence. An internal tool reachable only by a small, identifiable group of employees carries different risk than a public, unauthenticated customer-facing assistant reachable by anyone on the internet, even if the two systems otherwise look similar on action capability and data sensitivity.
Combine factors rather than relying on any single one
A useful classification combines these three factors instead of leaning on any single one in isolation, since a system can be low-risk on one dimension and high-risk on another at the same time. A public-facing, read-only chatbot with no sensitive data access might rank low on action capability and data sensitivity but higher on reach, landing in a moderate overall tier. An internal agent with broad database write access and financial transaction capability might rank low on reach but high enough on action capability and data sensitivity to warrant the highest tier of review anyway, despite its small audience.
Avoid over-weighting novelty or technical sophistication
A common classification mistake weighs a system's technical novelty or sophistication heavily, treating the most technically interesting or cutting-edge system as automatically the top priority for review. That doesn't correlate reliably with actual risk. A technically simple system with broad database write access deserves more review attention than a sophisticated but narrowly scoped, read-only research tool, and a classification framework should resist the pull to prioritize based on what's most interesting to talk about rather than what's most likely to cause real damage.
Use the classification to set proportional review depth
Once classified, use the resulting tier to set how much review depth and what ongoing monitoring a given system gets. High-tier systems, ranking high on action capability, data sensitivity, or reach, deserve thorough pre-launch review and continuous monitoring. Low-tier systems can move through a lighter, faster review process, since spending the same review effort on every system regardless of tier slows down low-risk work without meaningfully improving safety anywhere.
Revisit classification when a system's capabilities change
A system's risk classification isn't permanent. Adding a new tool, a new data source, or expanding reach to a new user population changes the factors the classification depends on, and the classification should get revisited whenever one of those changes happens, rather than treating the original classification as valid forever no matter how the system evolves.
Where TELEON fits
TELEON's audit trail can provide the activity data, what tools were called, what data was touched, how frequently, that supports validating whether a system's actual behavior in production matches its assigned risk classification, applied through the gateway or supported middleware.
Assigning the initial classification, and deciding the specific review depth and monitoring intensity appropriate for each tier, remains a governance decision that has to be made by the organization based on its own risk tolerance and the specific factors relevant to each use case.
A short checklist
- Weight action capability heavily, since it is the strongest predictor
of worst-case impact.
- Assess data sensitivity independently, since it drives a distinct
category of risk.
- Factor in reach, since it affects both attack likelihood and failure
scale.
- Combine all three factors rather than relying on any single one.
- Resist weighting technical novelty or sophistication over actual risk
factors.
- Set review depth and monitoring intensity proportional to the assigned
tier.
- Revisit classification whenever a system's capabilities or reach
change.
Classifying AI use cases by risk works best when it weighs action capability, data sensitivity, and reach together, since these three factors predict actual worst-case impact far more reliably than a system's technical sophistication or how much internal attention it has received.