What is a risk-based approach to AI regulation?

How it works

<strong>It starts with the harms the regime cares about</strong>

A risk-based regime begins by choosing which kinds of harm count for regulatory purposes. In modern AI governance, that usually goes beyond technical failure. Official frameworks and laws now treat safety, discrimination, privacy, data protection, cybersecurity, information integrity and other rights-related harms as part of the risk picture. Some international instruments frame the problem even more broadly, linking AI governance to human rights and responsible business conduct.

This matters because the protected interests shape the rest of the architecture. If a regime is mainly about product safety, it will look different from one that also cares about labour rights, access to education, democratic integrity or the treatment of vulnerable groups. In other words, classification is never just a technical exercise. It reflects a legal choice about which harms deserve escalation.

<strong>Classification is usually about use and context</strong>

The core move in a risk-based system is classification. But mature frameworks do not usually ask only what type of model is involved. They also ask what the system is used for, who is affected, what kind of decision it supports, whether it can materially affect rights or access to essential services, whether vulnerable groups are involved, how reversible a mistake would be, and whether the system can be meaningfully supervised, explained or audited.

That is why the same foundation model or AI component can fall into different governance bands in different deployments. A tool that helps draft low-stakes internal text is not usually treated like a tool that screens job applicants, supports diagnostic decisions or shapes access to benefits. Risk-based regulation is therefore best understood as use-based and context-sensitive, even when it also includes separate rules for especially capable general-purpose models.

<strong>Duties rise as the assessed risk rises</strong>

Once the regime sorts uses by risk, it attaches an escalator of duties. At the light end, the law may ask mainly for transparency, such as telling people they are interacting with AI or indicating that content is AI-generated. In the middle, the law may leave most AI-specific uses outside hard ex ante controls but still expect organisations to respect other applicable law and basic governance discipline.

As the risk increases, the compliance stack usually becomes much heavier. Higher-risk uses commonly trigger requirements around documented risk management, data governance, testing, traceability, technical documentation, human oversight, accuracy and security controls, incident handling, and some form of pre-release assessment. At the top of the ladder, the regime may decide that the issue is not whether the system can be controlled better, but whether the use is acceptable at all. That is the point where a risk-based model moves from regulation to prohibition.

<strong>The real mechanism is evidence, not labels</strong>

In practice, a risk band is only meaningful if the organisation can show why it put a system there and what it did next. This is why risk-based AI regulation is also an evidence model. It pushes organisations to create a record of purpose, context, classification logic, testing, data controls, human oversight arrangements, incidents, corrective action and review.

That evidence is what allows a legal duty to connect to assurance and audit. A regulator, investigator, procurement team or board committee will usually want more than a statement that a system was considered low risk or high risk. They will want to see the file trail: what factors were assessed, what assumptions were made, what was tested, what was left uncertain, which controls were chosen, and what happens if the system drifts, is fine-tuned, is integrated into another process or starts producing harmful errors in the real world.

<strong>Standards and frameworks turn the law into operating practice</strong>

Risk-based AI regulation rarely works on statute alone. Organisations need an operating method for carrying legal expectations into daily work. That is where standards and governance frameworks matter. NIST's AI RMF gives a widely used structure built around Govern, Map, Measure and Manage. It is voluntary and non-prescriptive, but it provides a durable vocabulary for identifying relevant context, measuring harms, prioritising remediation and assigning accountability.

NIST is especially useful because it makes two points that legal teams and product teams often forget. First, AI risk is contextual and can change across the lifecycle. Second, a framework can help prioritise risk without itself fixing the level of risk a society or organisation should accept. That distinction matters because law sets hard limits in some areas, while internal governance still has to make judgement calls in many others.

The same logic carries into generative AI. NIST's Generative AI Profile highlights recurring concerns such as confabulation, information integrity, privacy, intellectual property and third-party component risk. OECD's due diligence guidance adds another important dimension by treating AI governance as an enterprise process: embed governance, identify and assess harms, prevent or mitigate them, track them, communicate about them and provide remediation where appropriate. That helps explain why risk-based regulation has become more than a classification exercise. It is now tied to how firms document and govern the full AI value chain.

<strong>Responsibilities are spread across the value chain</strong>

A risk-based regime normally distinguishes between different actors. The builder of a model, the provider of a tool, the distributor, the integrator, the buyer and the deployer do not all see the same risks and should not all carry the same duties. The organisation placing a system into a real workflow may create new risk through fine-tuning, poor oversight, weak user training, bad procurement decisions or deployment into a context the original provider never anticipated.

That is why modern frameworks increasingly allocate obligations by role. Providers may need to produce technical documentation and carry out pre-release checks. Deployers may need to ensure real human oversight, monitor use and report problems. Buyers may need contractual access to evidence, testing records and incident support. Procurement therefore becomes part of regulatory compliance, not just a commercial step.

<strong>Classification is iterative, not once and done</strong>

One of the most durable lessons in official AI frameworks is that risk is not static. A system can look manageable in development and become much more serious in operation. Risk can rise when a model is adapted to a new domain, retrained on new data, connected to another product, inserted into a higher-stakes workflow or deployed at a scale that changes its social effect.

That is why post-release monitoring sits alongside pre-release checks in serious risk-based regimes. The right question is not only what risk category applied on launch day. It is whether the organisation has a mechanism for reassessing classification when facts change. A risk-based approach works properly only when classification, testing, oversight and review continue throughout the lifecycle.