The phrase "AI risk" is broad enough to hide almost anything. Security hears attacks and data leakage. Legal hears AI Act, GDPR and documentation. Business teams think about operational error. Leadership sees financial exposure, reputation and the ability to respond if something goes wrong. That is why many AI governance conversations stay vague: everyone agrees the risk matters, but nobody is quite sure which risk is being accepted.
There is more than one AI risk
A model can be accurate and still create unacceptable risk. Fraud detection may work while sensitive customer data is exposed. Document review may get faster, but leave no usable trace of why a case was escalated. A chatbot can answer most questions well and still fail on the few answers that legally bind the company.
For decision-makers, asking whether the AI is good is too blunt. The sharper questions are: what can it damage, who could be affected, would the failure be detected early enough, and what proof shows that the controls still work?
AI risk becomes manageable when teams separate the decisions, data, actions and evidence involved.
Six risk families that often get mixed together
Before choosing controls, teams need to name the risk in front of them. Otherwise the same meeting jumps from model quality to privacy, 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 it proposes a summary and a next action to the handler. Model risk means a wrong summary or a missed exclusion. Data risk means a medical or financial document visible beyond the claims team. Security risk can be a malicious attachment that changes the assistant's instructions. Regulatory risk appears when the company cannot explain or evidence the decision. Operational risk is the wrong amount paid, or a legitimate claim blocked. Reputation risk is the customer proving that the company relied on an opaque or unfair automated process.
These six families help name the kind of damage the company may have to carry. The six dimensions below do something else: they help assess the system so the company can decide, monitor and prove control.
Start from use, not model type
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 first on the use. Does the system advise a human? Rank cases? Make a decision? Trigger an action? Speak directly to customers?
That distinction matters more than the model family. A small classifier used for credit eligibility can carry more risk than a large language model summarizing public articles. A retrieval assistant becomes sensitive if it sees confidential files and answers employees without access checks. An agent becomes critical once it can send emails, create tickets, approve payments or modify production systems.
The six dimensions to examine
A practical AI risk assessment should force the system through six angles. Think of them as practical fault lines: the places where problems usually show up inside organizations.
- Privacy: what personal, confidential or regulated data can the system see, infer, retain or expose? Typical failures include 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? Look for prompt injection, data exfiltration, unauthorized tool use, secret exposure or an agent taking action with privileges it should not have.
- Accuracy: is the output reliable enough for the decision it supports? A hallucinated policy, a wrong score, a missed alert, an unsupported citation or a recommendation that contradicts the source material can be enough to make the system unsafe.
- Fairness: does the system treat comparable people or cases differently in ways the business cannot justify? The risk 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? If nobody can reconstruct, challenge or improve a decision, the control is too weak.
- Accountability: does the organization know who owns the system, who approves changes, who monitors incidents and where the evidence lives? A useful AI system with no owner, no version history, no logs and no escalation path is still a poor governance asset.
A concrete case: the claims assistant
The claims assistant is useful 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 repeat the same error across hundreds of files if teams trust it too quickly.
For privacy, check whether the assistant sees only the medical, identity and payment data needed for that claim. For security, uploaded PDFs, emails and customer notes need to be treated as possible carriers of hidden instructions. For accuracy, a general feeling of quality is not enough: compare the summary with the policy wording and the evidence in the file.
Fairness requires checking whether comparable claims are handled consistently across regions, age groups, languages or customer profiles. For explainability, the handler must see which documents and clauses support the recommendation. For accountability, the company needs a clear owner, review thresholds, logs and a way to correct the process when the assistant is wrong.
What the organization needs to prove
A board, auditor or regulator does not need to hear "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 that evidence current. 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.
A one-page decision discussion
A useful committee discussion should fit on one page. Before debating policy wording, ask seven questions about the system itself.
- 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. The system can still be useful, even low-risk. The organization just does not yet have enough evidence to say so.
Where the main frameworks point
The main frameworks use different vocabulary, but they ask for roughly the same discipline. 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 available. The legal mapping comes after that. If the facts are vague, the mapping will be vague too.
Use a risk sheet as the decision object
The output of this work should not be a long governance deck. Each important AI system needs a short risk sheet: 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.