An AI risk register is a single, owned list of the risks your organisation's AI systems create, with a likelihood and impact score, the controls in place, the person accountable and the evidence that the controls work. It is the working document behind an AI governance framework: the place where "we take AI risk seriously" turns into named rows a board, an auditor or a regulator can check.
This guide gives you a template with 15 pre-filled risks that most organisations using AI face in 2026, each mapped to ISO/IEC 42001, the NIST AI Risk Management Framework and the EU AI Act. Copy the table into a spreadsheet or GRC tool, delete the rows that do not apply, and add your own. For the governance structure the register sits inside, see our AI governance framework mapping. For what the board should see from it, see what a board AI risk assessment should cover.
What is an AI risk register?
A risk register records, for each risk: what could go wrong, how likely it is, how bad it would be, what you are doing about it, who owns it, and how you know the control works. An AI risk register applies that discipline to AI systems: the assistants staff use, the models built into products and the agents that can read data, call tools and change systems.
The standards expect one. ISO/IEC 42001 requires an AI risk assessment and AI risk treatment process (clauses 6.1.2 and 6.1.3, carried out in operation under clauses 8.2 and 8.3). The NIST AI RMF's Map and Manage functions assume risks are identified, prioritised and tracked, and GOVERN 1.6 asks for an inventory of AI systems. The EU AI Act requires providers of high-risk AI systems to run a documented risk management system throughout the system's life (Article 9), and places monitoring, oversight and log-keeping duties on the organisations that deploy them (Article 26).
Research supports keeping the register specific. Weidinger and colleagues' taxonomy of language model risks separates discrimination, information hazards, misinformation, malicious use, human-computer interaction harms and wider societal harms, each needing different controls (Weidinger et al., 2022). The AIRO ontology shows how risks, sources, consequences, controls and the AI Act's categories can be recorded in one consistent structure (Golpayegani et al., 2022). The MIT AI Risk Repository collects more than 1,700 AI risks from 65 published frameworks if you want a longer list to check yours against.
How is an AI risk register different from an IT risk register?
Three things change when the asset is an AI system.
- The system decides. A model's output can be wrong in ways that look right, and an agent can take actions no one scripted. Risks need an owner for the decision, not only for the platform.
- The inventory moves. Staff adopt AI tools and developers connect AI agents to systems faster than procurement sees them. The register is only as good as the inventory under it.
- Evidence is scattered. What an AI system did is split across the provider's logs, the identity system, the tool, the network and the system it changed. A control you cannot evidence is a control an auditor will not accept.
The AI risk register template
Score likelihood and impact from 1 to 5 using the scale below the table. The inherent score is likelihood multiplied by impact before controls. Record a residual score after controls, and a review date, in your own copy.
| ID | Risk | Owner | Controls | ISO/IEC 42001 | NIST AI RMF | EU AI Act | Evidence the control works |
|---|---|---|---|---|---|---|---|
| AI-01 | AI systems in use that security does not know about (shadow AI) | CISO | Discovery across identity, endpoint and network; named inventory; approval process | A.4.2 | GOVERN 1.6 | Art. 26 (you cannot meet deployer duties for systems you have not found) | Current inventory with discovery method, refresh date and unapproved systems found |
| AI-02 | Personal or confidential data entered into AI tools and retained or exposed | DPO and CISO | Approved-tool list; data handling rules; monitoring of uploads to AI services | A.7.2 to A.7.6 | MEASURE 2.10 | GDPR applies alongside the Act | Policy, monitoring alerts, record of incidents and outcomes |
| AI-03 | Prompt injection makes an AI system or agent take an unintended action | System owner | Separate untrusted content from action tools; approval for consequential actions; injection testing | A.6.2.4 | MEASURE 2.7 | Art. 15 (accuracy, robustness and cybersecurity, high-risk systems) | Test results including injection; approval records |
| AI-04 | An AI agent holds more access than its task needs | System owner | One identity per agent; minimal tool and data scopes; periodic access review | A.9.2, A.9.4 | GOVERN 3.2 | Art. 14 (human oversight, high-risk systems) | Scope list per agent; last access review |
| AI-05 | No reliable record of what an AI system or agent did | CISO | Log each action with identity, tool, destination and target-system change; central, protected retention | A.6.2.8 | MANAGE 4.1 | Art. 12 (record-keeping); Art. 26(6) (deployers keep logs at least six months) | A reconstructed action from last month, prompt to target-system change |
| AI-06 | An AI system cannot be stopped, or its changes cannot be reversed, quickly | System owner | Revocation and kill-switch procedure; rollback for agent changes; named approvers | A.6.2.6 | MANAGE 2.4 | Art. 14(4)(e) (ability to interrupt the system) | Record of a revocation drill and time taken |
| AI-07 | A model provider changes, degrades or withdraws a model you depend on | Procurement and system owner | Supplier assessment; contract terms on change notice; fallback plan | A.10.3 | GOVERN 6.1; MANAGE 3.1 | Art. 25 (responsibilities along the value chain) | Supplier assessments; contract clauses; tested fallback |
| AI-08 | A third-party plugin, MCP server or model package is malicious or compromised | CISO | Allow-list; version pinning; review before use; monitoring of tool calls | A.10.3; A.6.2.4 | MANAGE 3.1 | Art. 15 | Allow-list with versions; review records; see our MCP security checklist |
| AI-09 | Staff rely on inaccurate or fabricated AI output | Business owner | Defined intended use; human review for consequential outputs; accuracy testing | A.9.4 | MEASURE 2.5 | Art. 15 (high-risk); Art. 4 (AI literacy) | Intended-use statement; review process; test results |
| AI-10 | AI output discriminates against individuals or groups | Business owner and DPO | Impact assessment; bias testing on relevant groups; human review of decisions about people | A.5.4 | MEASURE 2.11 | Art. 10 (data governance, providers); Art. 27 (fundamental rights impact assessment, certain deployers) | Impact assessment; bias test results |
| AI-11 | AI is used for a prohibited or high-risk purpose without assessment | Legal and risk | Use-case approval against the Act's categories before deployment | Clause 6.1.4; A.5.2 | MAP 1.1 | Art. 5 (prohibited practices); Art. 6 and Annex III (high-risk) | Use-case register with classification and approval |
| AI-12 | Staff do not understand the AI they use or its limits | HR and CISO | AI literacy training matched to role | Clauses 7.2, 7.3 | GOVERN 2.2 | Art. 4 (AI literacy) | Training records by role |
| AI-13 | People are not told when they are dealing with AI or AI-generated content | Business owner | Disclosure rules for chatbots and generated content | A.8.2 | MEASURE 2.8 | Art. 50 (transparency) | Disclosure text in use; review record |
| AI-14 | Model or data drift degrades performance after deployment | System owner | Post-deployment monitoring with thresholds and alerts | A.6.2.6 | MEASURE 2.4; MANAGE 4.1 | Art. 72 (post-market monitoring, providers) | Monitoring dashboards; alerts and actions taken |
| AI-15 | An AI incident is not recognised, handled or reported | CISO | AI incident playbook; reporting route for staff; supplier notification | A.8.4 | MANAGE 4.3 | Art. 73 (serious incidents, providers); Art. 26(5) (deployers inform the provider) | Playbook; incident records and communications |
The EU AI Act column cites the article that applies to the obligation, whether it falls on providers, deployers or both. Most organisations are deployers of most of their AI. Check your role for each system before relying on the column, and take legal advice where a system may be high-risk.
Scoring scale
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare: not expected in the next three years | Minimal: no customer, legal or operational effect |
| 2 | Unlikely: could happen in the next three years | Minor: contained internally, fixed within a day |
| 3 | Possible: could happen in the next year | Moderate: customer or regulator notice possible, recoverable within a week |
| 4 | Likely: expected in the next year | Major: regulatory breach, material data exposure or service outage |
| 5 | Almost certain: happening now or expected within months | Severe: sustained harm to people, the business or its licence to operate |
Treat anything with an inherent score of 15 or more as board-level until the residual score is below your appetite.
How do you fill in an AI risk register?
- Start from the inventory. List every AI system, agent and tool in use, sanctioned or not, with an owner. Row AI-01 comes first because every other row depends on it.
- Classify each system. Record whether you are the provider or deployer, what the system is for, what data it touches and whether it can act. Systems that can change things come first.
- Walk the 15 rows for each system that can act. Delete what does not apply, add what is missing, and score inherent risk.
- Name controls you can evidence. For each control, write down the record that proves it works. If the record does not exist, the control is a plan, not a control.
- Test the evidence rows. Pick one real AI action from last week and try to reconstruct it for row AI-05. Run a revocation drill for row AI-06. Record what you found.
- Set a review cycle. Review the register quarterly and after any significant change to a system, a supplier or the law. Report the top risks and the residual scores to the board.
Raji and colleagues' framework for internal algorithmic auditing makes the same point from the audit side: accountability depends on documentation produced at each stage, not reconstructed afterwards (Raji et al., 2020).
Where SenseOn fits
The register's hardest rows are the ones that need evidence from across the estate: AI-01, AI-03 to AI-06 and AI-08. That evidence is SenseOn's Security for AI's job: know what your AI can do, prove what it did, reverse what went wrong.
- AI-01, the inventory. SenseOn's 7-day AI-use inventory gives you a human-reviewed list of the AI apps, agents and tools in your estate, who owns each one, what it can reach and which actions lack an approval gate. It starts from your Microsoft Entra tenant, plus endpoint or DNS and proxy data where in scope. Day one needs nothing installed.
- AI-04 and AI-06, authority and reversal. The Agent Control Plane holds identity, tool scopes, policy, approval, timeout and escalation for every agent that acts, including agents you did not build. Containment and rollback run under policy you set, with named approvers.
- AI-03, AI-05 and AI-08, the record. SenseOn connects provider, identity, tool, network and target-system evidence into one chain, so you can reconstruct an AI action end to end and show an auditor the result. For SenseOn's own agents, Decision Trace records the task, the evidence, the agent's contribution and the human decision.
The policy, legal classification and impact assessments stay with your governance, legal and risk owners. SenseOn supplies the evidence their rows depend on. See Security for AI for how it works.
Frequently asked questions
What should an AI risk register include?
Each row should have a risk description, the AI systems it applies to, an owner, likelihood and impact scores before and after controls, the controls in place, the evidence that those controls work, and a review date. Mapping each row to ISO/IEC 42001, the NIST AI RMF and the EU AI Act makes it reusable for audits.
Is an AI risk register required by law?
The EU AI Act requires providers of high-risk AI systems to operate a documented risk management system (Article 9) and places oversight, monitoring and log-keeping duties on deployers (Article 26). ISO/IEC 42001 certification requires an AI risk assessment and treatment process. A register is the usual way to show both.
What is the difference between an AI risk register and an AI impact assessment?
An impact assessment looks at one AI system's effects on individuals, groups and society, usually before deployment. A risk register tracks all AI risks across the organisation, with owners and controls, over time. Impact assessments feed risks into the register.
How often should an AI risk register be reviewed?
Quarterly as a minimum, and whenever a system, supplier, use case or relevant law changes. Agentic systems that can act on their own justify more frequent review of their access and evidence rows.
Who should own the AI risk register?
One executive should be accountable for the register as a whole, usually the CISO, chief risk officer or chief data officer. Each row still needs its own named owner who can change the controls.
Sources
- Weidinger, L. et al. (2022). Taxonomy of Risks posed by Language Models. ACM Conference on Fairness, Accountability and Transparency.
- Golpayegani, D. et al. (2022). AIRO: An Ontology for Representing AI Risks Based on the Proposed EU AI Act and ISO Risk Management Standards. Studies on the Semantic Web.
- Raji, I. D. et al. (2020). Closing the AI accountability gap: defining an end-to-end framework for internal algorithmic auditing. ACM FAT* 2020.
- ISO/IEC 42001:2023. Artificial intelligence: Management system.
- NIST (2023). AI RMF 1.0, NIST AI 100-1.
- European Union. Regulation (EU) 2024/1689 (AI Act).
- MIT. AI Risk Repository.
- NCSC (2023). Guidelines for secure AI system development.
How SenseOn writes, checks and corrects its content: editorial standards.
