Your governance structure says “assess risk.” Your AI policy says “classify by tier.” But nobody told you how to actually look at an AI tool and decide where it falls.
I’ll try to help.
Why Generic Risk Assessments Miss the Mark
Traditional IT risk frameworks weren’t built for this. They assess systems by confidentiality, integrity, and availability — which matters, but doesn’t capture what makes AI tools different.
Coding with Claude Code and a customer-facing chatbot with CRM access are not the same kind of risk. They differ in what data they touch, whether they act autonomously, whether they learn from your inputs, and how deeply they’re wired into your environment. A standard risk questionnaire won’t surface those differences.
You need dimensions that are specific to how AI tools actually work.
Six Dimensions That Matter
These six factors give you a practical framework for evaluating any AI tool. Each one scales from low to severe risk. The idea isn’t precision scoring — it’s forcing the right questions into the open before you approve anything.
1. Data Sensitivity
What data does the tool ingest, process, or have access to?
- Low: Public data only — marketing copy, open-source code, published research
- Medium: Internal business data — meeting notes, project plans, internal docs
- High: Confidential data — customer records, financial data, source code for proprietary systems
- Severe: Regulated data — PII, PHI, payment card data, anything with a compliance obligation attached
2. Access Permissions
What can the tool do inside your environment?
- Low: Read-only, no system access
- Medium: Limited write access — can create documents, send messages
- High: Broad write access — can modify records, trigger workflows
- Severe: Admin or privileged access — can change configurations, access credentials, or act on behalf of users
3. Integration Depth
How embedded is the tool in your infrastructure?
- Low: Standalone — browser-based, no integrations
- Medium: Connects to one or two systems via API
- High: Embedded in critical workflows — CI/CD pipelines, CRM, EHR, financial systems
- Severe: Privileged integration — has control-plane access or can modify other systems autonomously
4. Autonomy Level
How much does a human stay in the loop?
- Low: Human reviews every output before it’s used
- Medium: Human reviews some outputs — batch approval, spot checks
- High: Acts autonomously in defined scenarios — auto-replies, auto-triages, auto-escalates
- Severe: Makes decisions or takes actions without human review in high-stakes contexts
5. Data Persistence
What happens to your data after you use the tool?
- Low: Session-only — nothing retained after the conversation ends
- Medium: Data retained for limited period, not used for training
- High: Data retained and potentially used to improve the model or service
- Severe: Data incorporated into model training — your inputs become part of what the tool learns from
This is the one most teams forget to ask about. Vendor terms of service vary wildly here, and they change. Read them.
6. External Access
What can the tool reach outside your environment?
- Low: No external access — fully sandboxed
- Medium: Allowlisted external connections only
- High: Broad internet access for retrieval, search, or plugin execution
- Severe: Unrestricted external access with ability to send data, call APIs, or interact with third-party services
How to Score: Highest Factor Wins
Don’t average the scores. The highest rating across any single dimension determines the overall risk classification.
A tool that’s low risk on five dimensions but severe on data persistence is a severe-risk tool. That one factor — your data being used to train the model — doesn’t get diluted by the fact that the tool is otherwise well-behaved.
This feels conservative. It’s meant to. You can always approve a tool with compensating controls once you understand the risk. But you can’t make an informed decision without the information. The highest-stakes dimension is where you start the conversation.
Worked Example: Two Tools, Same Framework
Tool A: Internal meeting summarizer
| Dimension | Rating | Rationale |
|---|---|---|
| Data sensitivity | Medium | Internal meeting content, no regulated data |
| Access permissions | Low | Read-only, no system access |
| Integration depth | Low | Standalone, browser-based |
| Autonomy | Low | Human reviews summary before sharing |
| Data persistence | Low | Session-only, vendor confirms no retention |
| External access | Low | No external connections |
Overall: Medium. Department lead can approve. Annual review. Minimal guardrails beyond confirming no sensitive topics are discussed in summarized meetings.
Tool B: Customer support chatbot with CRM integration
| Dimension | Rating | Rationale |
|---|---|---|
| Data sensitivity | High | Customer PII, account history, support tickets |
| Access permissions | High | Can read and update CRM records |
| Integration depth | High | Embedded in CRM and ticketing system |
| Autonomy | High | Auto-responds to common queries without human review |
| Data persistence | Medium | Vendor retains conversation logs, no model training |
| External access | Medium | Connects to knowledge base and CRM APIs |
Overall: High. Full committee review with security, privacy, and legal. Quarterly reassessment. Requires monitoring, access controls, and output review protocols.
Same six questions. Completely different outcomes. That’s the point.
Risk Tiers as a Triage System
Here’s where this becomes operationally useful. Defining risk levels doesn’t just classify tools — it solves a workflow problem.
Most teams right now are drowning in AI tool requests. Every department has a new copilot, assistant, or plugin they want approved. If every request gets the same full-committee review, one of two things happens: the queue backs up and people wait weeks, or people stop asking and start using tools without approval. Neither is governance.
Risk tiers give you a triage system:
| Tier | Approval Path | Human Effort |
|---|---|---|
| Low | Auto-approved from pre-vetted list | Minimal — logged, not reviewed |
| Medium | Department lead approves with standard checklist | Light — one reviewer, documented decision |
| High | Full committee review with security, privacy, legal | Heavy — multi-stakeholder, detailed assessment |
| Severe | Exception process with executive sign-off | Maximum — compensating controls, ongoing monitoring |
Low-risk tools get approved by default. Not because you don’t care — because the intake form already captured the data you need. You have the tool in your registry, you know what data it touches, and you’ve confirmed it meets baseline requirements. You can revisit that decision anytime because the inventory is there.
That’s the real win. You’re not rubber-stamping — you’re making a risk-informed decision to focus human effort on the tools that actually need it. The meeting summarizer that uses public data and retains nothing gets a green light. The CRM-integrated chatbot handling customer PII gets the full review it deserves.
This keeps the intake pipeline moving without lowering the bar. People see that reasonable requests get approved quickly, so they keep using the process instead of going around it. And when a high-risk request comes in, the committee can give it the attention it actually needs instead of being buried in low-risk approvals.
Getting Started
You don’t need a perfect risk model. You need one that makes the next decision clearer than the last one.
-
Pick the six dimensions above — or adapt them to your environment. The categories matter more than the exact wording.
-
Score your existing tools. Start with whatever’s already in use. You’ll probably find most of them are low or medium risk, which is fine — now you know, and it’s documented.
-
Set your approval thresholds. Decide which tiers get auto-approved, which need a reviewer, and which need the full committee. Write it into your AI policy.
-
Use the workbook. Jason Robbins’ AI Security & Governance Workbook maps 45 AI tool functions to risk levels and required controls. It includes an intake form built around these dimensions. Don’t build your own spreadsheet when a good one already exists.
-
Revisit quarterly. Tools change. Vendors update terms of service. New capabilities get added. A tool that was medium risk six months ago might be high risk now because the vendor started training on customer data. Your registry makes that review possible.
Risk assessment isn’t about slowing things down. It’s about knowing which things deserve your attention and which ones don’t. Define the dimensions, score honestly, and let the tiers do the routing.
The goal isn’t to review everything. It’s to review the right things.
