AI Risk Assessment Template: Section by Section for the EU AI Act
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
An AI risk assessment template is a structured document for recording what an AI system does, how the EU AI Act classifies it, which harms it could cause, how likely and severe each harm is, which controls reduce it and who accepts the residual risk. Complete one per AI use case and review it whenever anything material changes.
Key takeaways
- A good template covers twelve sections: system description, intended purpose, AI Act classification and role, risk identification, scoring, controls, residual risk, human oversight, sign-off and review triggers.
- Article 9 of the AI Act requires a formal, lifecycle-long risk management system from providers of high-risk AI. Deployers have no Article 9 duty, but they need their own risk practice to meet Article 26 and, in some cases, Article 27.
- ISO/IEC 23894 gives guidance on AI risk management, and ISO/IEC 42001 requires an AI risk assessment, risk treatment and AI system impact assessment inside a management system.
- Score risks on a simple 5 × 5 likelihood-by-impact matrix, but write the reasoning down. The narrative matters more than the number.
- As of October 2026, Annex III high-risk obligations apply from 2 December 2027, so now is the time to build the habit.
Why you need an AI risk assessment
Most organisations already run information security and data protection risk assessments. AI systems add risks those processes were not designed to catch: a model that ranks women lower in a shortlist, a chatbot that invents a refund policy, a coding assistant that leaks a customer's API key into a prompt, or a supplier that quietly retrains on your data. A dedicated AI risk assessment makes those risks visible and gives each one an owner.
It is also the backbone of EU AI Act readiness. You cannot decide which obligations apply until you know what the system is, what it is used for and what role you play. If you have not mapped that yet, our EU AI Act guide explains how the regulation works, and the free EU AI Act readiness assessment writes an AI Risk Assessment Template for your organisation from your answers, together with three other governance documents.
Need expert help with ai risk assessment template?
Our cloud architects can help you with ai risk assessment template — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
Article 9 versus deployer risk practice
Article 9 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to establish, document and maintain a risk management system that runs across the whole lifecycle. It must identify known and reasonably foreseeable risks to health, safety and fundamental rights, estimate risks under intended use and reasonably foreseeable misuse, evaluate risks emerging from post-market monitoring, and adopt targeted measures. Residual risk must be judged acceptable, and testing must take place against defined metrics before the system is placed on the market.
Deployers, meaning organisations that use an AI system under their own authority, are not bound by Article 9. Their duties for high-risk systems sit in Article 26: use the system according to the provider's instructions, assign competent human oversight, make sure input data is relevant, monitor operation, keep logs for at least six months, inform workers before workplace use and inform affected people. Certain deployers must also carry out a fundamental rights impact assessment under Article 27. You cannot do any of that well without a documented view of the risks, which is why a deployer-side template is worth having even when the law does not name it.
| Aspect | Provider (Art. 9) | Deployer (Art. 26 practice) |
|---|---|---|
| Legal basis | Mandatory risk management system for high-risk AI | No named risk assessment duty; needed to meet Art. 26 and Art. 27 |
| Scope | Design, data, testing, post-market monitoring | Your context: users, data you feed in, affected people, oversight |
| Main inputs | Training data, test results, intended purpose | Provider's instructions for use, your process, your workforce |
| Output | Technical documentation, residual risk judgement | Risk register entry, controls, oversight plan, FRIA where required |
Standards that shape the template
Three frameworks are worth knowing. ISO/IEC 23894:2023 is guidance on AI risk management that adapts the ISO 31000 process (establish context, identify, analyse, evaluate, treat, monitor) to AI. ISO/IEC 42001:2023 is the certifiable AI management system standard. Its clause 6.1 requires an AI risk assessment, an AI risk treatment process with a statement of applicability against its Annex A controls, and an AI system impact assessment on individuals, groups and society. The voluntary NIST AI Risk Management Framework organises the work into four functions: Govern, Map, Measure and Manage. The template below is compatible with all three.
The AI risk assessment template, section by section
1. Document control
Assessment ID, system name, version of the assessment, date, author, risk owner and next review date. Keep a change log at the end.
2. System description
What the system is, in plain language. Vendor or internal team, model type (rules, machine learning, large language model), underlying general-purpose model if any, deployment model (SaaS, private cloud, on-device), integrations, data inputs and outputs, and the people who use it. Link the entry to your AI inventory register so the two never drift apart.
Sample wording: "TalentRank is a SaaS module of our applicant tracking system. It uses a machine learning model supplied by the vendor to score CVs against a job profile and returns a ranked shortlist to recruiters."
3. Intended purpose and context of use
The purpose the provider states, the purpose you actually use it for, the decisions it informs, who is affected and what is out of scope. Record reasonably foreseeable misuse too, such as recruiters treating the score as a final decision.
4. AI Act classification and your role
Record the risk tier (prohibited, high-risk, transparency, minimal) and the reasoning. For high-risk, cite the Annex III point or Annex I legislation. The four AI Act risk tiers are explained separately, and high-risk AI systems and Annex III covers the detail. Then record your role: provider, deployer, importer or distributor. Note any trigger that could turn you into a provider, for example putting your own name on the system or substantially modifying it.
5. Risk identification
Work through each category and write concrete risk statements in the form "cause, event, consequence". Generic entries like "bias" are useless; "the model under-scores candidates with career gaps, which disproportionately excludes women returning from parental leave" is actionable.
| Category | Questions to ask |
|---|---|
| Health and safety | Could an output cause physical harm or unsafe action, directly or through a person relying on it? |
| Fundamental rights and discrimination | Could outcomes differ unfairly by sex, age, ethnicity, disability or another protected ground? Is there a route to contest a decision? |
| Privacy and data protection | Is personal or special-category data processed? Lawful basis, minimisation, retention, automated decision-making under GDPR Art. 22? |
| Security | Prompt injection (direct and via documents or web content), data exfiltration through outputs, model or plug-in supply chain, over-broad permissions for agents, secrets in prompts. |
| Accuracy and robustness | Error rates on your data, hallucination, drift, behaviour on edge cases and adversarial input. |
| Transparency | Do people know they are dealing with AI (Art. 50)? Can staff explain an output to an affected person? |
| Third party and vendor | Does the supplier train on your data, change models without notice, store data outside the EU, or lack incident notification? |
| Operational and reputational | Over-reliance, loss of skills, outages, embarrassing outputs in public channels. |
6. Likelihood and impact scoring
Use a 1–5 scale for each and multiply. Define the scales in your template so two assessors would score the same risk the same way.
| Likelihood ↓ / Impact → | 1 Negligible | 2 Minor | 3 Moderate | 4 Major | 5 Severe |
|---|---|---|---|---|---|
| 5 Almost certain | 5 | 10 | 15 | 20 | 25 |
| 4 Likely | 4 | 8 | 12 | 16 | 20 |
| 3 Possible | 3 | 6 | 9 | 12 | 15 |
| 2 Unlikely | 2 | 4 | 6 | 8 | 10 |
| 1 Rare | 1 | 2 | 3 | 4 | 5 |
A common banding is 1–4 low (accept and monitor), 5–9 medium (treat within a set period), 10–16 high (treat before go-live or continued use) and 20–25 critical (stop or redesign). Impact on people's rights should weigh at least as heavily as financial impact; a "minor" cost to the business can be a severe outcome for a rejected job applicant.
7. Existing and planned controls
For each risk, list the controls already in place and the ones you will add, with an owner and a date. Typical AI controls: bias testing on representative data, confidence thresholds, human review of adverse decisions, output filtering, retrieval restricted to approved sources, least-privilege connectors, pseudonymisation before data reaches the model, logging, user training and contractual clauses with the vendor.
8. Residual risk
Re-score after controls. State explicitly whether the residual risk is within appetite and, if not, what happens next. Article 9 requires providers to judge residual risk acceptable; deployers should apply the same discipline.
9. Human oversight
Who can intervene, what they see, what authority they have to override or stop the system, and what training they have received. For high-risk systems this connects to the provider's oversight measures under Article 14 and your Article 26 duty to assign people with the necessary competence, training and authority.
10. Data protection link
Reference the DPIA if one is needed, the lawful basis and retention. Avoid duplicating it; cross-reference.
11. Sign-off
Risk owner, business owner, DPO or privacy lead, security lead and, for high or critical residual risk, an executive. Record date and decision: approve, approve with conditions, or reject.
12. Review triggers
Annual review as a minimum, plus event triggers: a new model version from the vendor, a new use case or user group, new data sources, a serious incident or near miss, a complaint from an affected person, a change in law or guidance, or monitoring metrics crossing a threshold.
Sample filled rows
Scores below are illustrative.
| System and classification | Risk | L × I (inherent) | Controls | Residual |
|---|---|---|---|---|
| CV-screening tool. High-risk, Annex III point 4 (employment). You are deployer. | Model under-scores candidates with career gaps, indirectly disadvantaging women and carers; recruiters rely on rank without review. | 4 × 4 = 16 | Vendor bias test results requested and reviewed; quarterly adverse-impact check on own data; recruiters must review every rejection; candidates told AI is used and how to request human review; logs kept 12 months. | 2 × 4 = 8 (medium, accepted by HR director with quarterly review) |
| Customer-service chatbot on the website. Transparency risk, Art. 50(1). You are deployer. | Bot states an incorrect refund policy; customer relies on it. Indirect prompt injection via pasted text makes it reveal internal instructions. | 3 × 3 = 9 | Answers grounded only in approved knowledge base; refusal outside scope; clear "you are chatting with an AI assistant" notice; handover to a human; system prompt hardening and injection tests before each release. | 2 × 2 = 4 (low) |
| Internal Copilot-style assistant for all staff. Minimal risk under the AI Act; GDPR and security in scope. | Assistant surfaces documents a user should not see because SharePoint permissions are too broad; staff paste customer personal data into prompts. | 4 × 4 = 16 | Permissions clean-up and sensitivity labels before rollout; acceptable use policy and training; DLP rules; usage logging; phased rollout by department. | 2 × 3 = 6 (medium) |
Notice that the internal assistant scores as high as the CV tool before controls, even though the AI Act treats it as minimal risk. Regulatory tier and business risk are different questions, and the template should answer both.
How to run the assessment in practice
- Start from the inventory. List every AI system and use case, including AI features switched on inside existing SaaS tools.
- Triage. Run a short screening on everything; do a full assessment for high-risk, customer-facing or data-heavy systems first.
- Get the provider's documents. For high-risk systems ask for instructions for use, accuracy metrics and known limitations. Our AI vendor due diligence checklist lists the questions.
- Run a workshop. Bring the business owner, a user, someone from privacy, security and, where possible, a person who represents those affected. Ninety minutes is usually enough per system.
- Score, treat and sign off. Then feed actions into your normal project or risk tooling so they are tracked.
- Monitor. Set two or three metrics per system, such as override rate, complaint volume and error rate on a sample, and act when they move.
If you are unsure where your gaps lie across the wider programme, an EU AI Act gap analysis puts risk assessment alongside policy, inventory, literacy and vendor management so you can prioritise.
Common mistakes
- One assessment for "AI". Risk depends on the use case. A model used for marketing copy and the same model used for credit decisions need separate entries.
- Scoring without definitions. If "likely" is not defined, scores are opinions.
- Ignoring affected people. Rights risks fall on applicants, customers and citizens, not on the organisation. Score from their point of view.
- No review trigger. A vendor model swap can change behaviour overnight.
Frequently asked questions
Is an AI risk assessment mandatory under the EU AI Act?
For providers of high-risk AI systems, yes: Article 9 requires a documented risk management system across the lifecycle. Deployers have no identically named duty, but Article 26 obligations on oversight, monitoring and input data, and the Article 27 fundamental rights impact assessment for certain deployers, are very hard to meet without a documented risk assessment.
What is the difference between an AI risk assessment and a FRIA?
An AI risk assessment covers all relevant risks, including security, accuracy, vendor and business risks. A fundamental rights impact assessment under Article 27 is narrower and legally prescribed for specific deployers of high-risk systems, such as public bodies and those assessing creditworthiness. It focuses on the people affected, the specific harms and the measures if risks materialise. Many organisations run the FRIA as an extension of the risk assessment.
How often should an AI risk assessment be reviewed?
At least once a year, and whenever something material changes: a new model version, a new use case, new data, an incident, a complaint or new regulatory guidance. For generative AI services, check the vendor's release notes regularly, because model updates can change behaviour without any change on your side.
Can I use ISO/IEC 23894 or the NIST AI RMF instead of a custom template?
They are frameworks, not fill-in templates. ISO/IEC 23894 describes the risk management process for AI and NIST AI RMF gives functions and suggested actions. A practical template, like the one above, puts those principles into a format your teams can complete for each system and that maps to AI Act roles and obligations.
Who should sign off an AI risk assessment?
The risk owner, normally the business owner of the use case, signs off with input from privacy, security and legal or compliance. High or critical residual risks should be accepted by an executive with the authority to stop the system. Record the decision and conditions so the acceptance can be traced later.
Get your AI Risk Assessment Template written
You can build the template above from scratch, or answer the questions once and let us draft it. Opsio's free AI governance assessment takes about 40 minutes across 14 steps. When you submit, it writes four editable Word documents from your answers: an AI Governance Framework, an AI Acceptable Use Policy, an AI Vendor Due Diligence Checklist and an AI Risk Assessment Template, plus a maturity score across ten governance areas. Free, no card, and the documents are yours to keep and adapt. If you want help running assessments across a larger portfolio, see our AI governance consulting.
This article is general information, not legal advice. Check the consolidated text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. Dates and standards status are as of October 2026.
Related Articles
About the Author
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by a certified practitioner and reviewed by our engineering team. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
