Join our Newsletter — 33% off our NHI Course

How should organisations implement AI risk management so it covers both technical and social impacts?

Organisations should treat AI risk management as a socio-technical discipline, not just a model-testing exercise. Start by mapping the system’s purpose, context, and intended users, then measure risks with both quantitative and qualitative methods, manage higher-risk use cases first, and govern through clear policies, structures, and accountability. That approach helps teams capture harms that pure computational metrics miss.

Why AI Risk Management Has to Combine Model Quality and Social Impact

AI risk management works best when it treats a system as more than a model. A technically accurate system can still create harm if it is deployed in the wrong context, interpreted too confidently, or optimised for the wrong outcome. That is why the risk question has to include purpose, intended users, operating setting, and the people or processes affected by the system’s decisions.

A useful way to frame this is to separate model behaviour from system behaviour. Model evaluation can tell you how well a system predicts, classifies, or generates outputs under test conditions, but it does not by itself reveal whether those outputs are fair, understandable, contestable, or safe in practice. The broader socio-technical view is especially important when the AI system influences access, eligibility, prioritisation, or other decisions that affect individuals or groups.

That is also why NIST AI Risk Management Framework and ISO/IEC 42001:2023 AI Management System Standard are both useful reference points: they push teams to govern AI as a managed capability, not as a one-off technical artefact. Where the use case involves high-impact or generative systems, the control lens becomes even broader because deployment choices, monitoring, and accountability shape the real-world risk profile as much as training data or model architecture do.

How to Measure Risk Beyond Purely Quantitative Metrics

Teams often over-rely on numeric scores because they are easy to compare, but that can hide important harms. Quantitative testing is still necessary for performance, error rates, drift, and bias indicators, yet qualitative methods are needed to understand whether the system is interpretable, whether people trust it appropriately, and whether it shifts burden or decision-making in harmful ways. The strongest programmes use both, then compare the results against the actual business and human context.

In practice, this means asking whether the metric reflects the decision that will actually be made. A low error rate may still be unacceptable if the AI sits in a high-stakes workflow, and a technically acceptable model may still be unsuitable if users are likely to over-automate, under-challenge, or misread its confidence. For that reason, risk review should include scenario analysis, stakeholder review, and documented assumptions about who can override the system and under what conditions.

Current guidance also supports looking at governance artefacts, not just test output. A well-run programme should be able to show the intended purpose, user population, human oversight design, and escalation path for adverse outcomes. That makes it easier to evaluate whether the system’s social impact is actually being measured, or merely assumed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework Control / Reference Relevance
NIST AI RMF GOVERN — Govern AI risk management needs accountability, policies, and oversight for socio-technical harms.
MAP — Map Mapping purpose, context, and affected users is central to evaluating AI risks in use.
MEASURE — Measure The question calls for both quantitative and qualitative risk measurement methods.
Recommendation — Establish accountable AI governance and oversight for the system’s intended purpose and impacts. Document the system context, intended users, and impact pathways before approval. Use combined quantitative and qualitative testing to assess performance and social harm.
ISO/IEC 42001:2023 4.1 — Understanding the organisation and its context AI risk must reflect operational context, not model outputs alone.
6.1 — Actions to address risks and opportunities The page is about managing AI risks through structured treatment and prioritisation.
5.3 — Organisational roles, responsibilities and authorities Clear accountability is required to govern technical and social impacts.
Recommendation — Define the organisational and use-case context that shapes AI risk exposure. Prioritise higher-risk AI uses and treat them through documented risk actions. Assign clear AI risk ownership and decision authority across the programme.

Practitioner Guidance

What to prioritise: Start with the use cases that can create the most consequential harm, not the ones with the most elegant model metrics. If the system influences employment, credit, health, safety, access, or other high-stakes outcomes, require a broader review than you would for a low-impact internal productivity tool.

What to verify: Confirm that the risk file includes both technical evidence and social-impact evidence. You should be able to point to the intended users, the affected populations, the human override model, and the reason quantitative tests are considered sufficient or insufficient for the decision being made.

Common mistake: Treating “good model performance” as proof of acceptable deployment. In practice, the failure often appears in the surrounding workflow, where users misunderstand outputs, defer too much to automation, or experience outcomes the model tests never captured.

Practitioner takeaway: The key judgement is whether the organisation is managing the AI system it actually deploys, not just the model it trained. If the governance process cannot explain both technical performance and real-world impact, it is not yet covering AI risk in a meaningful way.