A trustee AI risk register needs nine columns: risk, what could go wrong, who is affected, likelihood, impact, score, existing controls, owner and next review date. Score each risk 1 to 5 for likelihood and impact and multiply. Review it briefly at every board meeting, re-score it fully once a year, and earlier after any incident or new tool.
Most guidance for charities stays at principles: be transparent, protect data, keep a human in charge. Trustees nod and nothing changes, because no principle has an owner or a date. A register turns each principle into a named risk, a score, a control, a person and a review date. That is what a board can actually monitor, and it is what a funder or regulator would hope to see if they asked how the charity oversees its AI use. The staff-facing rules are a different document, covered in writing an AI policy for a small charity; this one is for trustees.
What a trustee register is for, and what it is not
The register answers one question for the board: what are we exposed to through AI, who is watching it, and what have we decided to do? It is a monitoring tool, not a technical document. Trustees do not need to understand how a language model works. They need to know where the charity uses AI (including the quiet, unofficial uses), what could harm beneficiaries, donors or reputation, and whether anyone has the job of checking.
It is not the staff policy. The policy tells people what they may and may not do. The register tells trustees how likely and how serious each failure is, and who is managing it. It is also not a place for long technical detail. If a risk needs two pages of explanation, put the explanation in a paper and keep one line in the register.
One practical point: the register should start from reality, not aspiration. Before writing anything, find out what is actually in use. A quick message to staff and volunteers asking "which AI tools have you used for charity work in the last three months, and for what?" will usually reveal tools the board has never heard of. A register built on the approved list alone misses the larger risk, which is the unapproved list.
The columns to copy
Keep the register to a single page that fits on a board pack. Nine columns do the job.
| Column | What goes in it | Example entry |
|---|---|---|
| 1. Risk | Short name, one line | Beneficiary data pasted into a public AI tool |
| 2. What could go wrong | The specific event and its harm | A caseworker pastes case notes into a free chatbot; sensitive details leave our control |
| 3. Who is affected | Beneficiaries, donors, staff, volunteers, funders | Beneficiaries; the charity's reputation |
| 4. Likelihood (1-5) | How probable in the next 12 months | 4 |
| 5. Impact (1-5) | How serious if it happens | 5 |
| 6. Score | Likelihood times impact | 20 (red) |
| 7. Existing controls | What is already in place | Policy bans case data in AI tools; no training yet |
| 8. Owner | One named role | Head of services |
| 9. Next review | A date, not "ongoing" | Next board meeting |
Add two optional columns once the basics work: "Action and due date" for anything above the amber line, and "Residual score" for the score after controls. Keep the first version simple. A register of nine columns and eight to twelve rows, owned and dated, beats a forty-row spreadsheet nobody opens.
A scoring rule trustees can apply in a meeting
Scoring is where registers become arguments. Fix the definitions on one slide so the board is scoring the same thing.
| Score | Likelihood (next 12 months) | Impact |
|---|---|---|
| 1 | Very unlikely | Minor inconvenience, fixed in a day |
| 2 | Unlikely | Some staff time lost; no outside effect |
| 3 | Possible | A complaint, a funder query or a small data slip |
| 4 | Likely | Harm to a beneficiary or donor, or a reportable data incident |
| 5 | Almost certain | Serious harm, loss of funding or public reputational damage |
Multiply the two scores. Treat 1 to 6 as green (monitor), 8 to 12 as amber (action planned, owner reports back) and 15 to 25 as red (action now, report at every meeting until it falls). These bands are a sensible starting point, not a standard; adjust them to your appetite for risk and write the final version into the minutes. Score before controls first, then after, so the board can see what the controls buy.
Two habits improve scoring quality. Score as a small group, not as individuals, then discuss any gap of more than two points, because the disagreement is usually where the missing information is. And never let one anxious or one dismissive voice settle a score; ask what would have to be true for it to be a 5, and a 1.
Worked example: a small charity's first register
Say a charity with eight staff, thirty volunteers and a mix of fundraising and advice services finds, after a staff and volunteer message, that people use free chatbots for drafting emails and appeal letters, a volunteer uses an AI note-taker in supervision calls, and the fundraising officer is trialling an AI donor-segmentation add-on. The board agrees a register. A first pass looks like this (illustrative scores).
| Risk | L | I | Score | Owner | Review |
|---|---|---|---|---|---|
| Case or donor data pasted into public AI tools | 4 | 5 | 20 | Head of services | Next board |
| AI note-taker records confidential supervision calls | 3 | 4 | 12 | Operations manager | Within 4 weeks |
| Fundraising add-on profiles donors in ways they did not expect | 3 | 4 | 12 | Fundraising lead | Before renewal |
| Appeal copy contains an invented fact or statistic | 4 | 3 | 12 | Communications lead | Quarterly |
| Funder application includes AI-written claims the charity cannot evidence | 3 | 4 | 12 | Chief officer | Per application |
| Over-reliance on one AI vendor; price or terms change | 3 | 2 | 6 | Operations manager | Annual |
| Deepfake or impersonation of a trustee or the charity in a scam | 2 | 4 | 8 | Chair | Six months |
| No record of which AI tools are in use | 5 | 3 | 15 | Chief officer | Next board |
The row that surprises boards is the last one. The risk of having no list of tools is itself rated high, because every other control depends on knowing what is in use. A first action might be a one-page tool inventory, due in four weeks, owned by the chief officer. The first red row triggers a short training session and a simple rule in the staff policy, which sits outside this register.
The pattern here, many risks in amber and a few in red, is typical of a first register. What matters is not the scores themselves but that every row has an owner and a date. If you want the general-purpose version of the same exercise, a simple AI risk register for small businesses gives a template with similar columns.
Eight risks charities commonly list
Use these as prompts for your own list, not as a standard. Delete what does not apply and add what does.
- Sensitive data in public tools. Beneficiary, donor, staff or volunteer data entered into tools whose terms allow retention or training. Controls: a clear rule, approved tools on paid plans, training. See what donor data must never be pasted into ChatGPT.
- Inaccurate or invented content. Appeals, impact reports or grant bids that contain wrong figures or claims. Control: a named person checks every number and claim before it leaves.
- Bias and unfair treatment. AI used to screen, prioritise or segment people may disadvantage groups. Control: no AI-only decisions about individuals; a person reviews any use that affects service access.
- Supporter-facing automation. A chatbot gives wrong advice to someone in distress. Control: clear limits, escalation to a human, regular review of transcripts. Related: how charities use AI chatbots for supporter questions.
- Consent and transparency. Supporters or beneficiaries not told that AI is involved where they would expect to be. Control: plain notices and a review of privacy wording.
- Funder and reputational risk. A funder objects to AI-written applications or a public mistake damages trust. Control: check each funder's stated expectations; keep an audit trail of who verified what.
- Vendor and cost risk. Terms change, prices rise or a tool is withdrawn. Control: avoid single-vendor lock-in for essential work; keep outputs in your own files.
- Security and impersonation. Fake voice or video of a trustee or staff member used to request payments. Control: a call-back rule for payment requests, whoever appears to ask.
Where a risk touches personal data, remember that data-protection law such as the GDPR may apply if you have supporters in the EU, and that rules vary by place, so ask a qualified adviser or your regulator's guidance rather than relying on this page.
Owners, and who does what
Every row needs one owner, and the owner must be able to act. Assign by the person whose job already touches the risk: head of services for beneficiary data, fundraising lead for donor profiling, communications lead for published content, chief officer for funders and the overall register. Give one trustee the sponsor role for the whole register, which means asking at each meeting whether the register has been updated and escalating anything overdue.
Owners are not responsible for solving the risk alone. They are responsible for knowing its current state, proposing actions, reporting changes and keeping their review date. Write this into the register's header, so it is not a surprise when an owner is asked for an update.
Avoid putting "all staff" or "the board" in the owner column. If the real answer is the chief officer, say so. If a risk has no obvious owner, that is itself information: either the risk sits in a gap between roles, or it is not a real risk for you.
Review cadence: three layers
Different layers need different rhythms, and trustees are busy. A workable pattern has three layers.
Every board meeting (10 minutes). The sponsor reports changes only: new risks, score changes, overdue actions and any incident. Red risks are reported in full. Nothing else is discussed unless a trustee asks.
Quarterly, owners update. Each owner reviews their rows, updates controls and scores and tells the chief officer what changed. This takes each owner about fifteen minutes and happens before the board pack goes out.
Annually (one meeting item, 30 minutes). A full re-score, a check that the register still matches the tools in use, deletion of retired risks and a review of the scoring bands. Pair it with the review of the staff AI policy.
Add trigger reviews. Re-open the register within a month if the charity adopts a new AI tool, has a data incident or near miss, receives a complaint involving AI, sees a change in a funder's rules or a change in the law affecting data or AI, or finds that staff are using a tool nobody listed.
Board paper wording you can adapt
Trustees read the paper, not the spreadsheet. A one-page cover note keeps the decision clear. Adapt this layout (illustrative):
PAPER: AI risk register, quarterly update
For: decision / noting (delete one)
Sponsor: [trustee name] Owner: [chief officer]
1. Summary. The register currently lists [n] risks: [r] red, [a] amber,
[g] green. Since the last meeting, [n] risks changed score, [n] were
added, [n] were closed.
2. Red risks. [Risk, score, controls, action and due date.]
3. New or changed AI use since the last meeting: [tools, purpose, who
approved].
4. Incidents or near misses: [none / summary].
5. Decisions requested: the board is asked to (a) note the register,
(b) approve [specific action or spend], (c) confirm the next
review date of [date].The "decisions requested" line is the one that stops the paper being wallpaper. If the board is only asked to note, say so. If it must approve a tool, a policy change or a budget, ask plainly. Minutes should record the decision and the reason; if your meetings use an AI note-taker, read whether an AI note-taker can write board minutes safely before turning it on for board business.
Use AI to draft the register, but not to score it
An assistant is a reasonable first-draft partner. Give it a short, anonymised description of how the charity uses AI and ask for candidate risks in your column format. Do not paste real names, case details or confidential figures. A prompt such as this works:
I am preparing an AI risk register for a small charity's trustees.
We use free chatbots for drafting, an AI note-taker in some calls, and
an AI add-on in our donor database. List 12 candidate risks in this
format: risk, what could go wrong, who is affected, existing controls
to check. Do not score them. Do not invent facts about our charity.Then the humans take over. The board and owners score, because scoring needs knowledge of your charity and its tolerance for risk, and because a trustee who scored a risk will remember why. Treat the AI list as a checklist of things you may have missed, and delete half of it.
One risk written out in full
A table row is a summary. Behind each red or amber risk, keep a short note that an owner can update. Here is the top risk from the worked example in full (illustrative).
RISK: Case or donor data pasted into public AI tools
Score: L4 x I5 = 20 (red) Owner: Head of services Sponsor: [trustee]
What could go wrong: a caseworker or volunteer pastes notes containing
names, health or money details into a free chatbot to tidy them up.
Existing controls: staff policy bans personal data in AI tools (in force
since [date]); no approved tool yet; no training delivered.
Actions: (1) approve one paid tool with business data terms - owner
chief officer, due [date]; (2) 30-minute briefing for staff and
volunteers - head of services, due [date]; (3) add a reminder to the
case-note template - operations manager, due [date].
Residual score if actions complete: L2 x I5 = 10 (amber).
Evidence to bring to the board: attendance list for the briefing,
screenshot of the approved tool's data settings, any incidents logged.The "evidence to bring" line keeps the register honest. A control that exists only in a document is weaker than one a trustee can see: a training record, a setting, a log. Ask owners for one piece of evidence per red risk, and treat a missing control as a reason to keep the score high.
When a risk turns into an incident
Say a volunteer pastes a donor list into a free chatbot to draft thank-you notes. The register shows what should happen next, which is better than inventing a response at the time. The owner logs the incident the same day, the chief officer decides whether the data-protection lead or an adviser must be told and whether the regulator's reporting rules apply, and the sponsor trustee is informed within an agreed time. The register row is re-scored, the controls are reviewed, and the board paper at the next meeting records what happened, what was done and what changed. Agree this chain before it is needed, and keep it as one paragraph in the register's header. Do not use this page as legal advice on breach reporting; it varies by place and by the data involved, so ask a qualified adviser.
Mistakes boards make with AI registers
Scoring everything amber, which hides what matters; force a ranking by asking which three risks the board would fix first. Listing technology risks only, and ignoring the human ones, such as staff trying tools in secret; most real incidents start with a person, not a model. Writing controls that are intentions ("we will train staff") instead of facts ("training delivered on [date], 24 of 30 attended"). Leaving benefits out of view: a board that sees only risks may ban useful tools and push use underground, so add a short "opportunities" note beside the register and revisit it at the annual review. And treating the register as a one-off, then discovering it is out of date when a funder asks.
How to tell the register is alive
Three signs show a register is working. Dates are current: no row has a review date in the past. Scores move: at least a few risks change after each review, because things change. And trustees ask questions: someone challenges a score, an owner or a control at least once a year. If none of that happens, the register has become a filing exercise. Shorten it, rotate the sponsor and ask the owners what they would drop.
If you are starting from nothing, begin with the inventory of tools, then three red and amber risks with owners, then the cover paper. A first meeting spent on that is worth more than a perfect register in six months. The funder side of the same risks is covered in using AI for grant writing without funders rejecting it.
Questions trustees ask about AI risk
Is an AI risk register different from the charity's main risk register?
Keep it as a separate page that feeds the main register. AI risks change faster and need more detail than a standard line item. Report the top two or three AI risks into the main register and keep the full list with its own owner and review date.
Who should own the register?
One named person, usually the chief officer or a senior manager, with a trustee as sponsor. Individual risks then get their own owners. A register owned by 'the board' is owned by nobody, and reviews slip.
How often should trustees review it?
Review the register briefly at every board meeting (new risks and changes only), re-score it in full once a year, and review it early after any trigger: a new AI tool, a data incident, a complaint or a funder or regulator change.
Do we need a register if we only use free AI tools?
Yes, a short one. Free tools are where staff and volunteers paste donor and beneficiary information with the least oversight. A register of five or six risks and a named owner takes an hour to set up and shows the board is paying attention.
Further reads
- Charity AI Risks: Data Protection, Deepfakes, and Donor Trust — The data, deepfake and donor-trust risks in depth.
- Charity Appeals and Social Posts With AI That Keep Your Voice — Check appeal copy that carries your voice.
- Turning Charity Data Into Impact Reports With AI — Impact reports with AI and how to verify them.
- Does a Five-Person Business Really Need an AI Policy? — Why even small teams need written AI rules.
- How to Roll Out an AI Policy So Staff Actually Follow It — How to roll a policy out so people follow it.
- How to Run Your First AI Pilot Project in a Small Business — Pilot the first approved tool once the register runs.
- OpenAI for Nonprofits: Who Qualifies and What to Check First — An independent checklist for a small charity: OpenAI's nonprofit offer, Goodstack verification, plan limits, donor-data rules and the alternatives.
- AI Implementation for Nonprofits: A Phased Plan for a Small Team — A 20-week pilot-to-rollout timeline for a small nonprofit team: inventory, pilot, policy, training, review and trustee sign-off.
- Charity Complaints Policy Template: Draft One With AI and Check It — A drafting prompt, a sceptical second AI pass and a made-up complaint walked through day by day, so a small charity's policy works in practice.
- Claude AI for Charities: Five Admin Jobs Set Up With Projects — Five Claude Projects for charity admin, each with files to upload, instructions to copy, a sample output and what to fix before anything is sent.
- Museum Accreditation Checklist: Policies and Evidence With AI — Copy your scheme's requirements into an evidence tracker, let AI find the policy gaps, and keep trustees as the approvers.
- Nonprofit Compliance Checklist: Can AI Track Filings and Deadlines? — Turn a nonprofit compliance checklist into a deadline register with owners, evidence, AI-written weekly digests and reminders that actually fire.
- Volunteer Onboarding Checklist for Charities: Build One With AI — A staged onboarding checklist with an AI step for each stage, copy-ready messages, and safeguarding items drafted by AI but approved by your safeguarding lead.
- How to Manage a Community Centre: Where AI Helps and Where It Cannot — Four tests that sort community-centre jobs into AI drafts and person-only decisions, with worked examples for bookings, rotas, newsletters and grants.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: general risk-management practice (likelihood and impact scoring); no standard is quoted here. Check your regulator's current guidance on trustee duties and data protection.