The phrase "AI risk" is broad enough to hide almost anything. One team hears cybersecurity. Another hears bias. A third hears hallucination, regulatory exposure, vendor risk or public embarrassment. That is why many AI governance conversations stay vague. Everyone agrees the risk matters, but nobody is sure which risk is being accepted.
AI risk is not one risk
A model can be accurate and still create unacceptable risk. It can predict fraud correctly while exposing sensitive customer data. It can automate document review while giving no usable trace of why a case was escalated. It can answer most questions well and still fail on the five questions that are legally controlled.
For decision-makers, the useful question is not whether the AI is good. The useful question is what the system can damage, who would be affected, how quickly the failure would be detected and what proof exists that the controls work.
AI risk becomes manageable when it is split into decisions, data, actions and evidence.
Six risk families often get mixed together
Before choosing controls, teams need to name the type of risk they are discussing. Otherwise the same meeting can jump from model quality to privacy, from privacy to regulation, then from regulation to customer trust, without ever making a clear decision.
- Model risk: the system gives a wrong answer, makes a weak prediction, hallucinates, drifts over time or fails outside the cases seen during testing.
- Data risk: the system uses sensitive, biased, stale, incomplete or badly governed data, or uses data for a purpose the organization did not approve.
- Security risk: the system can be manipulated, bypassed or used to reach data, tools or permissions that should remain protected.
- Regulatory risk: the organization cannot show that the system meets its obligations on documentation, oversight, impact assessment, logging, transparency or incident management.
- Operational risk: the system disrupts a workflow, delays a case, repeats an error at scale, triggers the wrong action or leaves teams without a reliable fallback.
- Reputation risk: customers, employees, partners or the public lose trust because the system behaves unfairly, absurdly, opaquely or in a way the company cannot defend.
Take a claims assistant in insurance. It reads accident descriptions, medical attachments, policy terms, invoices and previous decisions, then proposes a summary and a next action to the handler. The model risk is a wrong summary or a missed exclusion. The data risk is exposing medical or financial documents beyond the claims team. The security risk is a malicious attachment that changes the assistant's instructions. The regulatory risk is being unable to explain or evidence the decision. The operational risk is paying the wrong amount or blocking a legitimate claim. The reputation risk is the customer proving that the company relied on an opaque or unfair automated process.
These six families answer one question: what kind of damage can the company carry? The six dimensions below answer a different question: how should the system be assessed so the company can decide, monitor and prove control?
Start with the business impact
A customer support chatbot, a credit scoring model, a fraud detection engine, a claims assistant and a clinical triage tool do not fail in the same way. The business impact depends on what the system touches. Does it advise a human, rank cases, make a decision, trigger an action or communicate directly with customers?
That distinction matters more than the model family. A small classifier used in credit eligibility can carry more risk than a large language model used to summarize public articles. A retrieval assistant can become high-impact if it sees confidential files and answers employees without access checks. An agent can become critical once it can send emails, create tickets, approve payments or modify production systems.
The six dimensions leaders should use
A practical AI risk assessment should force the discussion into six dimensions. They are not academic categories. They are the six ways an AI system usually creates harm inside an organization.
- Privacy: what personal, confidential or regulated data can the system see, infer, retain or expose? A bad outcome is a chatbot revealing another customer's information, a document assistant surfacing HR records or a model retaining data outside the declared purpose.
- Security: can the system be manipulated, bypassed or used as a path into another system? A bad outcome is prompt injection, data exfiltration, unauthorized tool use, secret exposure or an agent taking an action with privileges it should not have.
- Accuracy: is the output reliable enough for the decision it supports? A bad outcome is a hallucinated policy, a wrong score, a missed alert, an unsupported citation or a confident recommendation that contradicts the source material.
- Fairness: does the system treat comparable people or cases differently in ways the business cannot justify? A bad outcome is unfair rejection, worse service quality for a protected group or a ranking rule that reproduces historical discrimination.
- Explainability: can the organization explain the decision, recommendation or action at the level expected by the user, auditor or regulator? A bad outcome is a decision nobody can reconstruct, challenge or improve.
- Accountability: does the organization know who owns the system, who approves changes, who monitors incidents and where the evidence lives? A bad outcome is a useful AI system with no owner, no version history, no logs and no escalation path.
Follow the claims assistant through the six dimensions
The claims assistant is a useful example because it looks ordinary. It does not approve payment alone. It helps the handler read the file faster. Yet it touches sensitive data, influences a financial decision, shapes the explanation given to the customer and can create repeated errors if teams trust it too quickly.
On privacy, the question is whether the assistant sees only the medical, identity and payment data needed for that claim. On security, the question is whether an uploaded PDF, email or customer note can smuggle instructions into the assistant. On accuracy, the question is whether the summary matches the policy wording and the evidence in the file.
On fairness, the insurer needs to check whether comparable claims are handled consistently across regions, age groups, languages or customer profiles. On explainability, the handler must see which documents and clauses support the recommendation. On accountability, the company needs a clear owner, review thresholds, logs and a way to correct the process when the assistant is wrong.
Evidence beats confidence
A board, auditor or regulator does not need a team to say "we tested the model". They need to see what was tested, when, against which version, with which thresholds and what happened when a test failed.
Good evidence is usually ordinary: an inventory entry, a risk classification, a data map, a test set, evaluation results, logs, model and prompt versions, known limitations, incidents, remediation decisions and an accountable owner. The hard part is keeping those elements current as the system changes.
This is where AI differs from many traditional applications. The behavior can change after a prompt update, a retrieval index refresh, a model provider change, a new tool permission, a new data source or a shift in user behavior. Evidence from last quarter may no longer describe the system running today.
How to use the framework in a decision meeting
A useful committee discussion should fit on one page. For each AI system, ask seven questions before debating policy wording.
- What does the system do? Advice, ranking, decision, action or external communication.
- Who can be affected? Customers, employees, patients, counterparties, suppliers or the public.
- Which data does it touch? Personal data, confidential documents, regulated records, transaction data or public information.
- Which dimensions are critical? Privacy, security, accuracy, fairness, explainability, accountability, or several at the same time.
- What evidence exists today? Tests, logs, monitoring, approvals, incident history and remediation decisions.
- What control would stop the worst failure? Human review, access limit, tool restriction, threshold, release gate, rollback plan or customer disclosure.
- What residual risk is the business accepting? Not in abstract terms, but in numbers, affected users, financial exposure, legal exposure and operational impact.
If the team cannot answer those questions, the system is not ready for a risk acceptance decision. It may still be useful. It may even be low-risk. But the organization does not yet have enough evidence to say so.
Where regulations and standards converge
The main frameworks use different vocabulary, but they point in the same direction. The EU AI Act turns high-risk AI governance into operational obligations such as risk management, data governance, logging, transparency, human oversight, accuracy, robustness and cybersecurity. The GDPR asks for impact assessment when processing is likely to create high risk for people. NIST AI RMF structures risk work around Govern, Map, Measure and Manage. ISO/IEC 42001 turns AI governance into a management system with policies, roles, processes and continual improvement.
For a decision-maker, the lesson is simple: do not start from article numbers. Start from the system, its impact, the six risk dimensions and the evidence you can show. The legal mapping comes after that. If the facts are vague, the mapping will be vague too.
The useful output is a risk sheet
The output of this work should not be a long governance deck. It should be a risk sheet for each important AI system: scope, owner, use case, data, users affected, applicable frameworks, the six dimensions, test evidence, open gaps, remediation plan and accepted residual risk.
That sheet gives a board a real decision object. It also gives security, legal, data and product teams the same source of truth. When the system changes, the sheet changes. When a regulator asks what controls exist, the answer is not a narrative assembled after the fact. It is the evidence trail already attached to the system.
References
- Regulation (EU) 2024/1689 (AI Act), Articles 9, 10, 12, 13, 14 and 15, eur-lex.europa.eu/eli/reg/2024/1689/oj.
- Regulation (EU) 2016/679 (GDPR), Article 35, eur-lex.europa.eu/eli/reg/2016/679/oj.
- NIST, Artificial Intelligence Risk Management Framework 1.0, Govern, Map, Measure and Manage, nist.gov/itl/ai-risk-management-framework.
- ISO/IEC 42001:2023, Artificial intelligence management system, iso.org/standard/42001.