Governance DocsGovernance Docs
Browse Toolkits

CART

No products in the cart.

ISO Compliance Insights & Best Practices

AI risk assessment chart with key risks listed for governance.

Generative AI Risk Assessment: The Complete 2026 Guide with Example

A generative AI risk assessment is the step most organizations skipped on the way to rolling out chatbots, writing assistants and AI coding tools. The tools arrived first, often through a free trial or a feature a supplier switched on, and the questions came later: what happens when the model makes something up, what staff are pasting into it, and who is accountable when a customer acts on a wrong answer. This guide shows how to assess those risks properly, using the ISO/IEC 42001 method, and walks through a worked example you can compare with your own.

It is written for the people who have to sign off the use of generative AI: a CISO, a compliance lead, a product owner or a founder who has been asked “is this safe?” and needs an answer an auditor or a board can follow.

AI risk assessment chart with key risks listed for governance.
Illustration of AI risk assessment highlighting key risks like transparency and data issues.

What Makes a Generative AI Risk Assessment Different

The method is the same as any management-system risk assessment: set criteria, list what is in scope, identify risks, rate them and decide how to treat each one. What changes is the kind of risk. A traditional model predicts a number or a category from a fixed set; a large language model produces open-ended text, code or images, takes instructions in plain language from anyone who can type, and is usually built by someone else. That creates risks that a standard information security assessment does not look for.

QuestionTraditional AI or softwareGenerative AI
What can go wrong with the output?A wrong score or classificationFluent, confident content that is false, biased, harmful or infringes someone’s rights
How can it be attacked?Through code, access and dataAlso through words: prompt injection in a message, document or web page
Where does sensitive data go?Into defined fields and databasesInto free-text prompts, which may reach a third party
Who built the model?Often youUsually a provider whose training data and testing you cannot see
Does behaviour stay the same?Until you change itIt can change when the provider updates the model or a prompt is edited

Two public references help you find the risks. The NIST Generative AI Profile (NIST AI 600-1), published in July 2024, lists 12 risks that generative AI creates or makes worse, including confabulation, data privacy, harmful bias, information integrity, information security, intellectual property and value chain and component integration. The OWASP Top 10 for LLM Applications 2025 covers the security side, from prompt injection and sensitive information disclosure to excessive agency and misinformation. Our guide to the NIST AI RMF Generative AI Profile covers the NIST list in more depth.

How ISO 42001 Frames a Generative AI Risk Assessment

ISO/IEC 42001:2023 asks for an AI risk assessment in clause 6.1.2 and AI risk treatment in clause 6.1.3. The requirements that matter most here are simple to state. Risk criteria must tell acceptable risks from unacceptable ones. Consequences must be assessed for the organization, for individuals and for society, not only for the business. And the controls chosen to treat each risk must be compared with the 38 controls in Annex A and recorded in a Statement of Applicability, with a reason for every inclusion and exclusion. Our pillar guide to the ISO 42001 risk assessment covers the full method.

Clause 6.1.4 adds a separate AI system impact assessment, which looks in depth at what a particular system could do to the people and groups it affects. For a customer-facing generative AI system, the two usually go together: the risk assessment tells you where the impact assessment matters most. Our article on the AI system impact assessment explains how to run one.

The Generative AI Risks to Look For

Most generative AI risk assessments end up with the same core set of scenarios. Write each one as an event, the weakness that lets it happen and the consequence, so it can be rated and owned.

  • Made-up output. The model states invented facts, figures, policies or references with confidence, and nobody checks before a customer or a decision relies on them.
  • Confidential data in public tools. Staff paste customer data, contracts or source code into consumer AI tools that have no contract with you, and possibly use inputs for training.
  • Prompt injection. Text hidden in an email, document or web page makes the model ignore its instructions, reveal data or take an action through a connected tool.
  • Harmful or biased content. Outputs that are offensive, discriminatory or unsafe, especially where vulnerable users are involved.
  • Over-reliance. Staff accept drafts, code or summaries without review because the output is usually good.
  • Third-party model risk. A model bought or accessed through an API without any review of how it was built, tested and governed, or a provider that changes or retires the model at short notice.
  • Intellectual property. Outputs that reproduce protected material, or inputs you had no right to use.
  • Transparency. Customers who are not told they are talking to AI or receiving AI-generated content. Under the EU AI Act, the Article 50 transparency obligations have applied since 2 August 2026.

Generative AI Risk Assessment Example

Brightwater Insurance (a fictional company) runs a customer service chatbot built on a third-party large language model, gives claims handlers a generative AI assistant for summarizing files, and has found staff using several public AI tools. It rates likelihood and impact on 1 to 5 scales, with impact described for customers and staff as well as for the company, and its appetite line is level 9 on a 1 to 25 scale. An extract from its register:

RefRiskLILevelDecision and ISO 42001 Annex A controls
R-01Chatbot misstates policy cover or claim terms; answers are not grounded in the policy wording4416Modify: answer only from approved documents and hand coverage questions to a person (A.6.2.4, A.9.4, A.8.2)
R-02Claims data pasted into public AI tools; no rules and no approved alternative4312Modify: roll out the approved assistant and block unapproved tools (A.9.2, A.2.2, A.10.3)
R-03Prompt injection through documents uploaded to the claims assistant3412Modify: restrict the assistant’s access and test it against injected instructions (A.6.2.2, A.6.2.4)
R-04Model provider changes the model version without notice339Retain, within appetite; monitor release notes
R-05Claims handlers accept AI summaries without checking the file3412No decision yet
R-06Customers not told they are talking to AI236Within appetite; disclosure already shown at the start of each chat

Read as a board would, this generative AI risk assessment says three things. The highest risk is the one customers see: wrong answers about their cover. Two of the risks above the line come from people rather than technology, which means training and clear rules will do as much as any technical control. And one risk, over-reliance on AI summaries in claims, has no decision yet, which is the first gap a reviewer would raise.

How to Run Your Own Generative AI Risk Assessment

  1. Find every generative AI system in use. Include features switched on inside existing software and tools staff use on their own. A generative AI risk assessment that misses shadow AI misses the biggest data leakage risk.
  2. Set criteria that weigh people. Describe impact for customers, staff and the public as well as in money and reputation, as ISO/IEC 42001 expects.
  3. Write scenarios, not headings. “Hallucination” is a category. “The chatbot invents refund terms because answers are not grounded in the policy library” is a risk someone can own.
  4. Rate with a reason. Sample real outputs where you can: a review of a few hundred conversations is better evidence than a guess.
  5. Treat and map to Annex A. Give each risk above the line a decision, an owner, a date and the Annex A controls it relies on, so the treatment carries into your Statement of Applicability. Our overview of the ISO 42001 controls lists all 38.
  6. Record and review. Keep the results in an AI risk register and repeat the assessment when a model, prompt, provider or use case changes, not only once a year.

You can do the whole generative AI risk assessment in our free AI risk assessment tool. Its library of 38 scenarios includes made-up output, prompt injection, data leaking into public AI tools, weak human oversight and third-party models, each mapped to the ISO/IEC 42001 Annex A controls that usually treat it. You get a heat map, a process score and the findings an auditor would raise, free.

Frequently Asked Questions

Do we need a generative AI risk assessment if we only use off-the-shelf tools?

Yes. Most of the risk in off-the-shelf use sits on your side: what data goes in, who relies on the output and what customers are told. ISO/IEC 42001 applies to organizations that use AI, not only those that build it.

How is it different from an information security risk assessment?

It covers security risks such as prompt injection and data leakage, but also risks with no security element: false output, bias, over-reliance, intellectual property and transparency. It also rates consequences for the people affected, not only for the organization.

Which framework should we use: ISO 42001 or NIST?

They work together in one generative AI risk assessment. ISO/IEC 42001 gives you the certifiable management system and the Annex A controls; the NIST Generative AI Profile and the OWASP list are good sources for identifying generative AI risks within it.

How often should it be repeated?

Repeat the generative AI risk assessment at least once a year, and whenever a model, provider, prompt, data source or use case changes significantly. Generative AI systems change more often than most software, so event-driven reviews matter more than the annual cycle.

For the AI policy, risk methodology, impact assessment and Statement of Applicability templates around this work, see the ISO 42001 Toolkit.

When a standard changes, know first

One email a month: edition changes, new deadlines, and what they mean for documentation you already have. No sales sequence.

We don’t spam! Read our privacy policy for more info.