What an AI risk assessment template should produce
An AI risk assessment for a small business should produce one document you will maintain: a register with one row per AI use, recording who owns it, how it can fail, how serious that would be, what controls are in place, and when to look again. Fill it in before launch, while changing course is still cheap. The AI risk assessment template below adds the questions to ask, rating scales, eight hypothetical rows, and a mapping to the framework from NIST, the U.S. standards agency.
How to assess AI risk in five steps
List every AI use. Include AI features in tools you already pay for, and uses nobody approved; the shadow AI post covers how to find them.
Describe the context. Who uses the tool, whose data goes in, and who is affected by the output, including people who never chose it.
Name concrete failure modes. "It might be inaccurate" is not a failure mode; "it quotes last year's price list" is. The questions below make good prompts.
Rate likelihood and impact. NIST's AI Risk Management Framework (opens in a new tab) (AI RMF) treats risk as a combination of probability and magnitude and does not prescribe risk tolerance; where no sector rule applies, you decide what is acceptable.
Choose a response. The framework's options are mitigating, transferring, avoiding, or accepting a risk (MANAGE 1.3). Record the residual risk (what remains once controls work), who accepted it, and what triggers the next review.
AI risk assessment questions to ask for each row
Ask these before rating each use. A question you cannot answer is itself a finding.
- What can this use do without a person approving it?
- If it is confidently wrong, who finds out first: you or the customer?
- What data does it see, and does the vendor keep it or train on it?
- Could the output treat groups of people differently?
- What happens when the vendor changes the model or the service goes down?
- Could emails, documents, or web pages it reads carry instructions it might follow?
- Is there a human fallback, and has anyone actually used it?
- What record would let you reconstruct an output later?
- Who can switch it off, and how quickly?
The answers about off switches, fallbacks, and records also fill Part 1 of an AI incident response plan.
The AI risk register template
Copy the ten columns into a spreadsheet, with one row per use rather than per tool: the same tool can be low risk in one job and high risk in another.
| Column | What to write |
|---|---|
| Use | The task, tool, and channel, in one line |
| Owner | One named person who can change or stop the use |
| Data | What goes in, and where outputs and logs are stored |
| Who is affected | Customers, staff, job applicants, the public |
| Failure modes | Specific ways the use goes wrong |
| Rating before controls | Likelihood and impact, and the combined rating from the grid |
| Controls | What reduces the risk today, stated as something you can check |
| Rating after controls | The residual risk: the rating with controls working, and who accepted it |
| Review trigger | Events that force a re-look before the scheduled date |
| Review schedule | How often the row is reviewed, and the next date |
Rating scales and the risk grid
The scales and the grid combining them are an editorial starting point, not a standard. Adjust the wording, but keep everyone on one version.
| Rating | Likelihood | Impact |
|---|---|---|
| Low | Not expected in a year of normal use | Inconvenience, caught internally, easy to fix |
| Medium | Could happen a few times a year | A customer is affected; fixed with a correction and some cost |
| High | Expect it monthly or more often | Harm to a person, sensitive data exposed, legal exposure, or many customers affected |
| Likelihood (cells: combined rating) | Low impact | Medium impact | High impact |
|---|---|---|---|
| High | Medium | High | High |
| Medium | Low | Medium | High |
| Low | Low | Low | Medium |
Rate each row twice: before controls, to see the exposure, and after, to see what you accept. An unchecked control does not lower the rating, and any High impact stays a priority until its controls are tested.
AI risk register example: eight hypothetical rows
These rows describe a hypothetical service business; they are not ratings of any real product. The second table carries the ratings.
| Use | Owner | Data | Who is affected | Failure modes |
|---|---|---|---|---|
| Website chatbot for service questions | Office manager | Website content; visitor questions and contact details | Prospective customers | Wrong prices or policies; follows instructions hidden in a visitor's message; collects data it should not |
| AI phone receptionist that books jobs | Owner | Names, numbers, addresses, job details, recordings | Callers, field staff | Books the wrong service or slot; mishandles an urgent call; records without proper notice |
| AI-drafted client emails | Account lead | Client emails and project details | Clients | Wrong figures or dates; unchecked confident claims; client data pasted into an unapproved tool |
| AI-drafted review replies | Owner | Public reviews, customer names | Reviewers, the public | Discloses job details; argues with an upset customer; replies read as fake |
| Internal meeting summarizer | Operations lead | Meeting audio and notes | Staff; clients discussed | Misattributes decisions; captures sensitive discussion; keeps recordings too long |
| Quote drafting from job notes | Estimator | Job notes, photos, price list | Customers; your margin | Wrong quantities; outdated price list; quote sent without review |
| Website and social content drafting | Marketing lead | Public information, brand guidelines | The public | Invented facts; copied wording; claims the business cannot support |
| Resume screening | Owner | Resumes and contact details | Job applicants | Screens out qualified people unevenly across groups; reasons cannot be explained |
Ratings read likelihood / impact = combined rating.
| Use | Before controls | Controls | After controls (accepted by) | Review trigger | Review schedule |
|---|---|---|---|---|---|
| Website chatbot | High / Medium = High | Approved pages only; refunds, prices, and complaints go to a person; weekly transcript check | Medium / Medium = Medium (owner) | Page or price change; vendor model change; any complaint | Monthly |
| AI receptionist | Medium / High = High | Urgent keywords transfer to a person; recording notice; daily summary review | Low / High = Medium (owner) | New service; call-flow change; a missed urgent call | Monthly |
| AI-drafted client emails | Medium / Medium = Medium | A reviewer reads every draft; approved tool only | Low / Medium = Low (account lead) | New template; reviewer change | Quarterly |
| Review replies | Low / Medium = Low | Owner approves every reply; no job details | Low / Low = Low (owner) | Platform policy change; a public complaint | Quarterly |
| Meeting summarizer | Medium / Medium = Medium | Off for confidential meetings; recordings deleted on a set schedule | Low / Medium = Low (operations lead) | New meeting type; vendor terms change | Quarterly |
| Quote drafting | Medium / High = High | Estimator checks every line; price list version printed on the quote | Low / High = Medium (owner) | Price list update; any quote error | Monthly |
| Content drafting | Medium / Low = Low | Fact check before publishing; no performance claims without a source | Low / Low = Low (marketing lead) | New content type | Quarterly |
| Resume screening | Medium / High = High | Not used until counsel reviews it; if adopted, a person reviews every rejection and compares outcomes across groups | Not rated: avoided for now (owner) | Any plan to use it; a hire in a new location | Before any use |
Why the hiring row is avoided for now
Hiring tools affect people who never chose them, and some places regulate them directly. New York City's Local Law 144 (opens in a new tab), enforced since July 5, 2023, bars employers and employment agencies from using an automated employment decision tool unless it has had a bias audit within one year of use, and requires a public audit summary and notices to candidates. Rules elsewhere differ and, as of October 2026, are still changing. This is not legal advice; ask counsel before any AI touches hiring. An AI acceptable use policy can make that a written rule for staff. The bias exercise in how to red-team an AI system shows what testing this row would involve.
Mapping the register to the NIST AI RMF and AI 600-1
A mapping helps when a client, insurer, or acquirer asks how you manage AI risk. The AI RMF 1.0 (opens in a new tab) has four functions: Govern, Map, Measure, and Manage. The Generative AI Profile (AI 600-1, July 2024) (opens in a new tab) lists 12 risks that generative AI creates or makes worse. The mapping is editorial.
| Register column | AI RMF outcome | AI 600-1 risks to consider |
|---|---|---|
| Use, Owner | GOVERN 1.6 (inventory of AI systems); GOVERN 2.1 (roles and responsibilities) | Value Chain and Component Integration, for tools built on another vendor's model |
| Data, Who is affected | MAP 1.1 (intended purposes and context) | Data Privacy; Intellectual Property |
| Failure modes | MAP 5.1 (likelihood and magnitude of impacts) | Confabulation; Information Security; Harmful Bias or Homogenization; Human-AI Configuration; Information Integrity; Dangerous, Violent, or Hateful Content |
| Rating before controls | MANAGE 1.2 (treatment prioritized by impact, likelihood, and resources) | All that apply |
| Controls, Rating after controls | MANAGE 1.3 (response options); MANAGE 1.4 (residual risks documented) | All that apply |
| Review trigger, Review schedule | GOVERN 1.5 (periodic review); MANAGE 4.1 (post-deployment monitoring) | Value Chain and Component Integration |
Three AI 600-1 risks are left out because they rarely apply to a small service business: chemical, biological, radiological, or nuclear (CBRN) information or capabilities; environmental impacts; and obscene, degrading, or abusive content. NIST notes that the framework is being revised (opens in a new tab) as of October 2026, so recheck these AI RMF 1.0 (January 2023) outcome IDs before relying on them. The AI RMF Playbook (opens in a new tab) suggests voluntary actions for each outcome; NIST says it is not a checklist.
Keep the register alive
A register filed once goes stale at the first vendor update, so review each row on its schedule and whenever a trigger fires. The AI vendor evaluation checklist covers the model-change notice to ask for, so you hear about those updates before they land. When a pilot is about to go into production, its row should carry the acceptance thresholds described in why AI pilots stall.
Treat each Medium or High row as a test to run, not a box ticked. The AI Contingency Framework that Cleland & Co. publishes draws the same line: a register lists what could go wrong; rehearsal attacks, degrades, and misuses the system to test selected risks. It is a method used in advisory and fractional engagements, not a separate product; its rehearsal phase is the reasonable next step for a finished register.
