An AI risk assessment is a short written record of what an AI tool will do for you, what could go wrong and what you will do about it. For a small organization it should fit on 1 or 2 pages per tool. The template below has 8 sections you can copy, fill in and sign off in a single meeting.
What an AI risk assessment is
An AI risk assessment answers 3 questions before a tool goes into daily use: what is this for, who could be hurt if it goes wrong, and is the remaining risk acceptable. It is the working core of AI risk management. It turns a vague worry (“is this safe?”) into a decision someone can stand behind.
It is not a security audit or a legal review. You do not need technical depth to complete it. You need the person who will own the tool, a clear description of the use, and honest answers about the data.
When to do one
Do an assessment when any of these happen:
- A new tool. Before anyone starts using it for real work, including free tools.
- A new use. The same tool moves from drafting newsletters to summarizing client case notes.
- New data. Staff want to paste in donor records, health information or anything about children.
- A new plan or version. You switch from a free plan to a paid one, or the vendor changes its terms.
- After an incident. A wrong answer reached a client, data went somewhere it should not, or a security advisory affects software you run.
Even when nothing changes, review each assessment at least once a year.
Why it matters for a small organization
Small organizations often adopt AI tools one person at a time. A volunteer signs up for a chatbot, a manager connects an assistant to the shared inbox, and soon sensitive data is flowing through services nobody approved. An assessment slows that down just enough to catch the obvious problems.
It also gives you something to show. Funders, board members and partners increasingly ask how you manage AI. A folder of signed, dated assessments is a clear answer.
The template, section by section
Copy the headings and prompts below into a document. Keep answers short. A sentence per field is usually enough.
1. Basics
- Tool or system name:
- Vendor:
- Plan or version: (free, team, enterprise, self-hosted version number)
- Owner: a named person, not a department
- Date of assessment:
- Next review date:
2. Use case
- What will the tool be used for? Describe the tasks in plain words.
- Who will use it? Staff, volunteers, contractors, or a mix.
- What decisions or outputs depend on it? Letters, reports, eligibility screening, code, public posts.
- What happens if it is wrong? Embarrassment, wasted time, harm to a client, a legal problem.
3. Data
- Categories of data going in: public, internal, confidential, restricted.
- Personal data involved? Yes or no. If yes, whose: donors, clients, staff, children.
- Where is the data stored and processed? Vendor’s service, your own server, a specific region if known.
- Retention: how long the vendor or your system keeps inputs and outputs.
- Does the vendor train on your data? Yes, no, or unknown, and how you know.
4. People affected
- Who could be harmed? Clients, donors, staff, the public.
- How? For each group, one line on the realistic harm.
5. Risks
List the risks that apply. Rate each one for likelihood (low, medium, high) and impact (low, medium, high). Use these prompts to get started:
- Wrong or made-up output (hallucination)
- Sensitive data disclosed to the wrong people
- The vendor training its models on your data
- Prompt injection, when the tool reads outside content such as emails, web pages or uploaded files
- Excessive access, for example full access to email or shared drives
- Bias or unfair treatment of the people you serve
- Vendor lock-in, or the vendor changing its terms
- Security vulnerabilities in self-hosted AI software
| Risk | Likelihood | Impact |
|---|---|---|
| (example) Wrong output sent to a client | ||
6. Controls
For each risk above, write what will reduce it and who is responsible. Typical controls:
- Plan choice: a plan with stronger data terms
- Settings: turning off features you do not need
- Access limits: only the folders or accounts the task requires
- Human review: a person checks output before it leaves the organization
- Training: a short briefing for everyone who uses the tool
- Policy rules: what data may and may not go in
7. Residual risk and decision
- Remaining risk after controls: low, medium or high, with one sentence of reasoning.
- Decision: approve, approve with conditions, or reject.
- Conditions (if any):
- Signed off by: name and role
- Date:
8. Monitoring
- What will be checked: output spot checks, the incident log, security advisories for self-hosted software, vendor policy changes.
- How often: for example, monthly spot checks and a quarterly look at vendor terms.
- Who checks:
How the template lines up with the NIST AI RMF
The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary framework released on January 26, 2023. NIST built it to help organizations think through AI risks to individuals, organizations and society. It groups AI risk work into 4 functions. The template maps onto them roughly like this:
| NIST function | Template sections |
|---|---|
| Govern | Owner (Basics), Decision |
| Map | Use case, Data, People affected |
| Measure | Risks, Monitoring |
| Manage | Controls, Decision |
You do not need to adopt the full framework to use the template. The mapping helps if a funder or partner asks which standard you follow. For a broader view, see AI governance frameworks explained.
A worked example
This is an illustration, not a real case.
A small community services organization wants to use a general-purpose AI chat assistant to draft thank-you letters to donors.
- Basics: The development coordinator owns it. Review date is set 12 months out.
- Use case: Drafting letters from a short brief. Two staff members will use it. Letters go out under the director’s name, so a wrong detail is embarrassing but not harmful.
- Data: The team first planned to paste in donor names, gift amounts and personal notes. That is confidential personal data. The free plan’s terms were unclear on training.
- People affected: Donors, whose giving details could be exposed.
- Risks: Training on donor data (medium likelihood, medium impact). Made-up details in letters (medium, low). Data disclosure (low, high).
- Controls: Move to a paid plan whose terms say inputs are not used for training. Paste in first names only, never amounts or notes; the coordinator adds those by hand. A second person reads every letter before it is sent.
- Decision: Approve with conditions. The director signed off.
- Monitoring: Monthly spot check of 5 letters, and a review whenever the vendor emails about policy changes.
The whole assessment took under an hour and fit on 1 page. The most useful outcome was the change in what data goes in, which cost nothing.
How to keep it current
An assessment goes stale the moment the tool, plan, data or use changes. Build a small routine:
- Keep all assessments in one shared folder, one file per tool.
- Put each next review date in a shared calendar.
- Ask staff to tell the owner before they connect the tool to new accounts or feed it new kinds of data.
- Check our advisories for any self-hosted AI software you run, and update the assessment when one applies.
- When a vendor announces new terms, reopen sections 3, 5 and 7.
- After any incident, write a line in the incident log and revisit the assessment within a week.
The tools page and the guide to AI vendor assessment questions can help when you need answers from a vendor.
Frequently asked questions
How long should an AI risk assessment take?
For most tools at a small organization, 30 to 60 minutes once you have the vendor’s terms in hand. The goal is 1 to 2 pages. If it is running much longer, the use case is probably too broad and should be split.
Does every AI tool need an assessment?
Any tool used for real work should have one, including free tools and AI features added to software you already use. Low-risk tools that only touch public data can get a very short assessment. The point is that someone has looked and made a decision.
Who should sign off?
Someone with authority to accept risk for the organization, usually the director, an operations lead or a board member responsible for risk. The tool’s owner should not approve their own assessment. For high-risk uses involving client or children’s data, consider asking the board.
What if the vendor will not answer our questions?
Record “unknown” in the template and treat it as a risk in its own right. Assume the less favorable answer, for example that the vendor may train on your data, and set controls to match, such as keeping confidential data out. If the gaps are serious, rejecting the tool is a legitimate decision.
Published Updated
Sources
- NIST AI Risk Management Framework, checked October 27, 2026