How to Run an AI Risk Assessment for Your Business

Photo: RDNE Stock project / Pexels
Key takeaways
- An AI risk assessment is four questions: which tools, what data, what safeguards, what happens if they fail.
- Start with a full tool inventory across every team, not just IT - shadow AI is usually the biggest chunk of it.
- Classify data by sensitivity first: public, internal, personal data, and regulated data (health or financial).
- For anything sensitive, check training defaults, retention periods, DPA/BAA availability and SOC 2 or ISO 27001 status.
- Re-run the assessment quarterly, or whenever a new tool gets requested.
An AI risk assessment sounds like a job for a compliance department with a budget and a template nobody reads. It isn't. For a team without one, it comes down to four honest questions: which AI tools do we actually use, what data goes into them, what protections does the vendor actually offer, and what happens if those protections fail. Answer those four and you've done the AI risk assessment that most auditors, regulators and enterprise customers are really asking for. This guide walks through each step, with a worked example, a scoring approach and a table you can copy, so you can run the whole thing in an afternoon rather than a quarter.
What an AI risk assessment actually covers
It isn't a general cybersecurity audit, though the two overlap. An AI risk assessment specifically asks how AI tools handle the data you feed them: whether a vendor trains its models on your inputs by default, how long it retains what you send, whether it will sign a data processing agreement (DPA) or, for health data, a business associate agreement (BAA), and whether it holds SOC 2 or ISO 27001 certification. Most teams already have some of this scattered across vendor emails and terms-of-service pages nobody has reread since signup. It roughly mirrors what the NIST AI RMF calls mapping and measuring risk, scaled down to something a small team can finish without a consultant. The assessment just pulls it into one place and forces a decision on each tool: approved, conditionally approved, or not approved.
Step 1: build the tool inventory
You can't assess a tool you don't know exists, and this is where most first attempts stall. Ask every team, not just IT, what AI tools they use day to day: the ones bought centrally, the ones an individual pays for out of pocket, and the AI features quietly built into other software - a summarise button in your video-call tool, a writing assistant inside Notion, a drafting feature in your CRM. That third category is usually the biggest, and it's exactly what shadow AI looks like in practice. A spreadsheet with one row per tool and columns for department, purpose and data type is enough to start; you don't need software for this step.
Step 2: classify what each tool actually touches
For every tool on the list, write down the most sensitive data that realistically goes into it, not the most sensitive data it's supposed to handle. Public information carries almost no risk. Internal plans and product roadmaps carry moderate risk. Personal data such as customer names and email addresses is high risk under GDPR. Protected health information and financial account data are the two categories that turn a policy gap into a legal one. Sort your inventory by this scale before doing anything else - it tells you where your limited time is actually worth spending, rather than treating every tool as equally urgent.
Step 3: check the safeguards that actually matter
For anything above 'internal', check four things: does the vendor train on your inputs by default, what's the stated retention period, is a DPA or BAA available, and is SOC 2 or ISO 27001 certification current - some vendors let certificates lapse quietly, so it's worth checking the date rather than trusting a badge on a marketing page. Retention terms move, too: Anthropic cut its API log retention from 30 days to 7 days in September 2025, a reminder that these figures are worth re-checking rather than assuming from memory. Business tiers usually clear these checks; free consumer accounts almost never do. Our AI Tool Risk Directory has this pulled together for 60-plus common tools, sourced from vendors' own policies, so you don't have to read every privacy page yourself.
Step 4: score it and decide
You don't need a scoring algorithm. A simple three-column outcome works: approved (safeguards match the data sensitivity), conditionally approved (fine for internal use, not for client or personal data, until a business tier is bought), or not approved (no DPA, trains on inputs by default, and the data involved is sensitive). Write the reason next to each decision in one sentence - 'no DPA offered, used for client emails' is enough - because six months later nobody remembers why a tool was blocked, and someone will ask.
Where to keep the record
Keep the finished assessment somewhere it can actually be produced on request, not buried in one person's downloads folder. If you're pursuing or maintaining SOC 2, auditors expect vendor risk decisions to be documented and dated, and an AI tool inventory is increasingly treated the same way as any other third-party vendor list. A shared drive with a clear file name and a review date is enough for most small teams; you don't need a dedicated GRC platform to make the record credible.
Does a five-person company really need to do this?
Yes, and it's smaller than it sounds. A 12-person bookkeeping firm we've seen go through this found the whole exercise took under three hours: eleven tools on the list, two of them AI features nobody had previously flagged as 'AI' at all, and one clear decision - moving from personal ChatGPT accounts to a paid Team account for anything touching client financials. The output wasn't a binder or a consultant's report. It was three new rows in a spreadsheet and one added line in their existing policy, and it's the kind of thing a founder or ops lead can finish between meetings rather than something that needs an outside consultant.
What happens if you skip it
Nothing happens, until it does. The two most common failure points are a SOC 2 auditor asking for your AI tool inventory and getting a shrug, or a customer's data-privacy questionnaire asking which AI vendors touch their data and nobody being able to answer with confidence. A third, quieter one: a data subject access request under GDPR that requires you to say which systems hold a customer's personal data, including any AI tool it was ever pasted into. A fourth, and the one that stings most in hindsight: an employee pastes a client contract into a free consumer tool to 'summarise it quickly', and there's no record it happened until it turns up somewhere it shouldn't. None of these are catastrophic on their own, but all of them slow down deals or audits, and all of them are avoidable with an assessment that takes an afternoon rather than a scramble.
Turning it into a habit, not a one-off
Re-run the classification step whenever a new tool is requested, and do a full pass quarterly, since vendor terms, retention windows and certification status change more often than most people expect. Tie the outcome to your AI usage policy so the assessment actually changes what staff are allowed to do, rather than sitting in a spreadsheet nobody reopens until the next audit forces the question. Put a named owner on the calendar reminder too - 'someone will get to it' is how a quarterly habit quietly becomes an annual one.
Start with the tools you already have
The fastest way in is to run a free AI vendor risk assessment on the two or three tools your team uses most, then work outward from there. It won't take a quarter, and by the end of the afternoon you'll have a clearer answer than 'we think it's probably fine.'
| Tier | Example data | Minimum safeguard to require |
|---|---|---|
| Public | Marketing copy, published blog drafts | None - any approved tool is fine |
| Internal | Internal plans, non-public roadmaps | No training on inputs; business-tier account |
| Personal data (PII) | Customer names, emails, addresses | GDPR-ready DPA; clear retention terms |
| Regulated (PHI/financial) | Patient records, financial account data | Signed BAA where health data is involved; SOC 2 Type II |
“Managing the risks of an AI system is not a one-time activity; it needs attention across the system's whole lifecycle.”