Image: Unsplash, used under the Unsplash License.
This is for the founder, ops lead or part-time compliance owner who has been asked "what are our AI risks?" and has no risk team to hand it to. The template below is a register you can use today: a scoring scale, the risks small teams actually hit when they use AI tools (pasted customer data, made-up citations, deepfake payment requests, an agent that acts on its own), a starting control for each, and the rule or framework the row answers to.
The starting scores are ours, not a regulator's. We set them for a small company that uses chat assistants, an AI coding tool and maybe a support bot. Your scores will differ, and that difference is the point: the value of a risk register is the conversation it forces about which three rows get fixed first.
If you don't yet know which AI tools your team uses, start with the AI register template, the inventory this risk register reads from. One row per tool there, one row per risk here.
How to score each risk
Score likelihood and impact separately, from 1 to 5, then multiply. Two people should score each row: the person who owns the tool and someone who doesn't. When they disagree by more than one point, write down why.
| Score | Likelihood: how often | Impact: how bad |
|---|---|---|
| 1 | Rare: no known case in your sector; several things would have to fail | Minor: an internal annoyance, fixed in a day, no customer notices |
| 2 | Unlikely: has happened elsewhere, not to you | Limited: one customer or one document affected, fixed within a week |
| 3 | Possible: could happen this year given how you use the tool | Moderate: several customers affected, a complaint, rework or a contract conversation |
| 4 | Likely: has happened to you or a peer, or staff already do it | Major: a regulator's question, a lost client, personal data exposed |
| 5 | Almost certain: happening now or will this quarter | Severe: a fine, a lawsuit, a breach notice, or harm to someone's job, credit or health |
| Rating | Score | What to do |
|---|---|---|
| High | 15-25 | Named owner, a fix date within 30 days, and leadership hears about it at the next meeting |
| Medium | 8-12 | Named owner and a control in place within the quarter |
| Low | 1-6 | Accept it, write down why, recheck at the next review |
This follows the NIST AI Risk Management Framework without copying its paperwork. Its Map 5.1 asks for the "likelihood and magnitude of each identified impact", and Manage 1.2 says treatment "is prioritized based on impact, likelihood, and available resources or methods." The framework is intended for voluntary use, so the scale is yours to adjust; just keep it the same across rows.
Chart: AI Policy Desk. Source: the scale and bands above.
The pre-filled AI risk register
Copy the table into a spreadsheet, or download it ready to use: an Excel workbook (.xlsx) that calculates the score and rating as you type, with owner, review date and status columns and the scale on a second sheet, or a Word document (.docx). Both are built from this page.
| ID | Risk | Likelihood | Impact | Score | Starting control | Rule or framework |
|---|---|---|---|---|---|---|
| R1 | Staff paste customer or confidential data into personal AI accounts | 4 | 4 | 16 | Approved-tools list, company accounts only, a one-page shadow AI policy | GDPR Art. 28(3) processor contract; Art. 30 record of processing |
| R2 | An AI vendor keeps or trains on your inputs | 3 | 4 | 12 | Check retention and training terms before purchase; redline the contract | GDPR Art. 28(3); NIST AI RMF Manage 3.1 |
| R3 | Made-up facts, figures or citations reach a client or a court | 4 | 4 | 16 | A named human checks every citation and number before it leaves the company | Court sanctions for AI-made-up citations (tracker) |
| R4 | A hiring or screening tool treats applicants unfairly | 2 | 5 | 10 | Bias audit before use, human review of every rejection the tool drives | EU AI Act Annex III point 4(a); NYC Local Law 144 bias audit |
| R5 | A decision with legal or similar effect is made by software alone, with no human route | 2 | 5 | 10 | A human reviews before the decision lands; a way to contest it | GDPR Art. 22(1) and 22(3) (guide) |
| R6 | A customer-facing chatbot hides that it's a bot, or has no route to a person | 3 | 3 | 9 | Bot disclosure in the first message; a one-step "agent" option | EU AI Act Art. 50(1); NYC DCWP proposed rule |
| R7 | AI-generated image, audio or video of a real person is published without a label | 2 | 4 | 8 | Label rule in the content checklist; consent on file for any real person | EU AI Act Art. 50(4) |
| R8 | A deepfake voice or video of a manager is used to request a payment | 3 | 5 | 15 | Call-back on a known number for any new payee or changed bank details | No AI-specific rule: your payment-verification policy (case) |
| R9 | An AI agent takes an action nobody approved (sends, deletes, pays) | 3 | 4 | 12 | Least-privilege access; a human approves anything irreversible (agent vetting) | Internal approval policy; NIST AI RMF Manage 1.3 |
| R10 | API keys or credentials leak through an AI coding tool | 3 | 4 | 12 | Secret scanning on every repo; a key rotation runbook | Internal security policy |
| R11 | A key AI vendor goes down, changes its terms or leaves your market | 3 | 3 | 9 | A second model or a manual fallback for each critical workflow (example) | NIST AI RMF Manage 3.1 |
| R12 | A vendor or its owner lands on a sanctions or federal exclusion list | 1 | 5 | 5 | Screen vendors against OFAC's SDN and Consolidated lists at onboarding and yearly (NS-MBS case, FASCSA case) | OFAC sanctions lists; FASCSA orders for federal contractors |
| R13 | Nobody knows which AI tools are in use | 4 | 3 | 12 | Keep an AI register, reviewed quarterly | NIST AI RMF Govern 1.6 |
| R14 | You can't produce logs or evidence when a client or regulator asks | 3 | 3 | 9 | Decide which tool logs you keep and for how long; store test results with the register | EU AI Act Art. 26(6) (high-risk deployers); Texas TRAIGA Sec. 552.105(e) |
| R15 | Staff aren't told before AI is used to manage or monitor them | 2 | 3 | 6 | Written notice to staff before rollout (workforce policy) | EU AI Act Art. 26(7) (high-risk, workplace) |
| R16 | Staff use AI tools without basic training on their limits | 4 | 2 | 8 | A short onboarding session and the acceptable use policy | EU AI Act Art. 4, as amended by Regulation (EU) 2026/1744 |
| R17 | Output copies protected material or someone else's IP | 2 | 3 | 6 | No AI output in shipped code, logos or published copy without a human check | NIST AI RMF Map 4.1 |
Three rows start High: pasted customer data, made-up citations and deepfake payment requests. They share a cause: a person trusts the tool, or the voice, more than the process. Each control above puts a second person or a second channel in the way.
How to fill it in
- Start from your AI register. Every tool on it should map to at least one row here. A tool with no row is either low-risk (say so in a note) or a row you haven't written yet.
- Delete what doesn't apply and add your own. No hiring tool means no R4. If you need ideas, MIT's AI Risk Repository captures "1700+ risks extracted from 74 existing frameworks and classifications of AI risks," sorted into 7 domains and 24 subdomains. For a small team we'd keep it to a few dozen rows at most; a register nobody can read in one sitting doesn't get reviewed.
- Rescore with two people. Use the scale above. Change our starting scores freely; keep a note when you move a row by more than one point.
- Pick a response for every Medium and High row. NIST's Manage 1.3 lists the options: "mitigating, transferring, avoiding, or accepting." Transferring usually means a contract clause or insurance; avoiding means not using the tool for that job.
- Record what's left. After the control, rescore the row and keep both numbers. Manage 1.4 asks that residual risks be documented, and a client's security questionnaire will ask the same thing.
- Set the review. Put a quarterly date in the calendar and a named owner on the register itself. Govern 1.5 asks for "periodic review" with roles and frequency "clearly defined." Reopen it early when you add a tool, change a vendor, or something on the list actually happens.
Screenshot: MIT AI Risk Repository, airisk.mit.edu.
Which rules a risk register helps with
| Rule | What it asks | Applies to |
|---|---|---|
| EU AI Act Art. 9 | "A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems." | Providers of high-risk AI; Annex III systems from December 2, 2027 |
| EU AI Act Art. 26 | Deployers keep the system's logs, assign human oversight, inform workers before workplace use | Deployers of high-risk AI, same date |
| EU AI Act Art. 50(1) and 50(4) | Tell people they are talking to an AI system unless obvious; disclose deep fakes | Providers and deployers; the Act has applied since August 2, 2026 |
| GDPR Art. 22 and 30 | Safeguards for solely automated decisions; a record of processing activities | Controllers and processors under the GDPR; Art. 30(5) exempts some smaller organisations, so check whether yours qualifies |
| Texas TRAIGA Sec. 552.105(e) | No liability for a violation the defendant discovers through feedback, testing (including red-team testing), state agency guidelines, or an internal review while substantially complying with NIST's Generative AI Profile or another recognized framework | A defendant in a civil penalty action under Sec. 552.105 |
| NIST AI RMF | Map, Measure, Manage and Govern outcomes, including the inventory (Govern 1.6) | Voluntary |
A register is not an Article 9 risk management system on its own: Article 9 also requires testing "against prior defined metrics" before a high-risk system is placed on the market, which our high-risk documentation templates walk through. For a Texas business, the register's value is evidence: a dated row showing a risk was found through testing or review and then fixed is the paper trail the TRAIGA defense turns on.
Screenshot: NIST AI Resource Center, AI RMF Core, Figure 5.
What it doesn't cover
This register is not a fundamental rights impact assessment under EU AI Act Article 27, not a GDPR data protection impact assessment, and not a vendor assessment. For a single tool before purchase, use the third-party AI tool risk assessment. We found no rule in the sources we checked that requires a document called an "AI risk register"; the rows above point to the rules where a register is the easiest way to show your work.
