How the MIT AI Risk Initiative Maps AI Laws and Policies to Risks

Updated

The MIT AI Risk Initiative maps global AI laws, policies, and frameworks against the specific risks they address, then lets you filter that mapping by risk domain, sector, lifecycle stage, value chain actor, legislative status, and technical scope. Use it when you need to answer a question like "which rules actually cover this risk, and where?" rather than "what does one law say?" The mapping lives in the Governance section of the site and is connected to the initiative's other datasets through the AI Risk Navigator.

What the mapping actually connects

The site describes its governance data as "Global AI laws, policies, and frameworks, mapped against the risks they address." That means each entry is treated as a law or framework on one side and a set of risks on the other, with the link between them being the thing you browse. This is a coverage view, not a legal analysis: it tells you which instruments touch which risks, not whether a given instrument is strong, enforceable, or sufficient.

The risks themselves come from the initiative's living repository of AI risks, so the governance mapping inherits that taxonomy. If you want to understand a risk category before checking coverage, read the risk entry first — the law mapping will make more sense against that definition.

The six filters and what each one is for

Filter What it narrows Typical use
Risk domain The category of risk being addressed Find every instrument touching a specific harm area
Sector The industry or application area Check coverage for a regulated field rather than all AI
Lifecycle stage Where in the AI lifecycle the instrument applies Separate development-stage rules from deployment or monitoring rules
Value chain actor Who the instrument targets Distinguish obligations on developers, deployers, or other actors
Legislative status Where the instrument stands Separate enacted law from proposals or frameworks
Technical scope The technical reach of the instrument See whether a rule is model-specific, system-wide, or broader

The practical move is to combine filters rather than use one at a time. Filtering by risk domain alone gives you a long list; adding legislative status separates binding rules from aspirational frameworks, and adding value chain actor tells you whether the obligations land on the party you care about.

A worked example

Suppose you need to know what exists for a risk in a specific sector, aimed at deployers, and actually in force. Start with the risk domain filter to pull the relevant risk category, add the sector to drop instruments aimed elsewhere, set value chain actor to deployers, and set legislative status to enacted instruments only. What remains is a short list you can read individually. Reverse the order — start from a law you already know and read its mapped risks — when you are auditing an existing instrument rather than searching for coverage.

How this fits the rest of the site

The governance mapping is one of several connected datasets. The site also publishes expert consensus on which risks are expected to cause the most severe harms and who is responsible for addressing them, a living repository of AI risks, a database of real-world incidents filterable by risk domain, harm type and severity, people affected, alleged developer, time, and national security impact, and a company disclosure dataset covering which of 24 AI risks 200 of the world's largest companies acknowledge in public documents.

The AI Risk Navigator connects these so you can move between them. A useful sequence: check expert consensus for priority, check company disclosures for whether firms acknowledge that priority, then use the governance mapping to see what rules cover it. Gaps between the three are often the most informative output.

Limits to keep in mind

  • Coverage is not compliance. A law appearing against a risk does not mean it is enforced or effective.
  • The risk taxonomy is the initiative's own, so results are only as granular as that taxonomy.
  • Legislative status changes; treat status filters as a snapshot and verify against the primary source before relying on it.
  • The site presents itself as producing data and frameworks for identifying, prioritizing, and managing AI risk. It is a research resource, not legal advice — for a decision with legal consequences, confirm against the actual text of each instrument.