AI Risk Management: A Practical Framework for Teams

AI risk management is the process of identifying, evaluating and reducing the risks that come from using AI tools at work. The risks are real: data leaking into model training, AI-generated errors treated as fact, regulatory exposure from tools that do not meet GDPR or HIPAA requirements, reputational damage from undisclosed AI use. None of this needs a risk-management background or a dedicated team. It needs four questions answered honestly and a simple record kept up to date. This guide covers exactly those four questions, in the order most SMBs actually meet them, plus the one artefact, a short risk register, that turns the answers into something you can show an auditor or a customer.

Risk 1: shadow AI and unmanaged tools

The highest-probability risk for most small and mid-sized businesses is not a rogue model. It is staff using AI tools nobody in the organisation has evaluated, marketing running a free ChatGPT account, support installing a browser extension, someone pasting a contract into an AI summariser found on Product Hunt. This is shadow AI: data flowing into systems you know nothing about, on terms you have not read. The control costs nothing but attention: maintain a list of approved tools, make it genuinely easy to request an addition, and check any request against how the tool actually handles data before saying yes. Our AI Tool Risk Directory has already done this for 60-plus common tools, so the check is usually a lookup, not a research project.

Risk 2: data classification failures

Not all data carries the same risk if it leaks. Public information, marketing copy, published pricing, is low risk. Internal plans and unreleased product detail are medium risk. Personal data, names, email addresses, health records, is high risk under GDPR and, in the US, HIPAA. The control is one sentence in your policy: do not put personal or confidential data into an AI tool that lacks the right contractual protections. The ICO's guidance on AI and data protection is explicit that data-minimisation duties apply to AI processing exactly as they do anywhere else; a model being involved does not create an exemption. That one rule, stated plainly with real examples, prevents most of the high-severity incidents an SMB will ever face.

Risk 3: over-reliance on AI output

AI systems produce confident-sounding answers that can simply be wrong. A support lead at a 30-person SaaS startup once let an AI tool draft refund-policy answers to customers, unreviewed, for a week before anyone noticed one had invented a policy that did not exist. No lasting harm was done, that time, but the fix was a one-line rule: any AI output going to a customer gets a human read before it sends. State the human-review requirement explicitly in your policy for anything reaching a customer, a regulator, or a decision with real consequences. Leaving it to individual judgement is how the gap opens in the first place.

Risk 4: regulatory exposure without an incident

If your organisation uses an AI tool that processes EU personal data without a Data Processing Agreement, or handles protected health information without a signed Business Associate Agreement, you are already out of compliance, regardless of whether a breach ever happens. HHS's guidance on business associates is clear that a BAA is required before PHI is shared with any vendor acting on your behalf, AI vendor or not. This is a paperwork risk, and it is the cheapest one to fix: require a DPA or BAA before approving any tool that touches regulated data, and check for one before the trial account starts, not after. Our AI vendor risk glossary entry explains what a DPA or BAA actually needs to cover.

Do you need NIST's full framework to do this properly?

No, but it is worth knowing the shape of it, because auditors and enterprise customers increasingly ask about it by name. The NIST AI RMF organises AI risk management into four functions: Govern (set policy and accountability), Map (understand where and how AI is used), Measure (assess the risks you have mapped), and Manage (respond to what you have measured). The four risks above map directly onto that structure without needing the full NIST AI RMF 1.0 document: your tool list is Govern and Map, your data-classification and human-review rules are Measure, and your register with review dates is Manage. If a customer or auditor asks whether you follow NIST's framework, you can honestly say your process mirrors its four functions, in a form built for a team without a dedicated risk function. See our guide to the NIST AI RMF for the longer version.

Turning the four risks into a register

Record each risk in a simple table: the AI tool, its risk category, the control in place, and the date you last checked it. That register, not a lengthy risk-management policy document, is the artefact that actually gets asked for in a SOC 2 review or an enterprise security questionnaire. Keep it current rather than comprehensive: a five-tool register that is accurate beats a fifty-tool register nobody has touched since it was created. Review it whenever you add a new tool, and at minimum every quarter, since tools change their data-handling terms more often than most policies get updated. A spreadsheet is a perfectly good place to keep it; the format matters far less than whether it is actually current when someone asks to see it. Pair the register with your written AI usage policy and your attestation records, and you have covered the documentation expectations of the EU AI Act, ISO 42001, NIST AI RMF and SOC 2 without writing four separate compliance programmes.

What happens if you skip formal AI risk management?

Nothing happens, until it does. Most SMBs that skip this do not have an incident in year one, which is exactly what makes it easy to keep skipping. The cost shows up later: a customer's security questionnaire asks for your AI risk register and you do not have one, a regulator asks how you assessed a tool that mishandled data and the honest answer is 'we did not', or a new enterprise deal stalls in procurement because nobody can produce the paperwork. Compare that to the actual cost of doing it properly: a few hours to build the register, an afternoon to write the policy, and an ongoing habit of checking new tools before they are approved. The asymmetry, hours now against a stalled deal or a failed audit later, is the whole argument for starting before you are asked to.

Start this quarter, not next

You do not need a risk committee to begin. Pick your five most-used AI tools, check each one against our free AI vendor risk assessment, and note anything missing a DPA or BAA. Write the one-sentence data rule into your policy, or generate the whole thing with ModelCharter's policy generator if you are starting from nothing. That is the four risks handled, in an afternoon, with a register you can show anyone who asks.