Which rules apply to which system, and what do we do when they differ?
Enhanced: 22 controls
Who it applies to
Enter for every AI system whose letter is E or A (this area has no Baseline controls). Go as deep as your system letter, and implement in your mode.
Why it exists
Different systems of one organisation fall under different rules: sector rules, use-specific rules such as those on employment or credit decisions, and the regime of every country in which they produce effects. An organisation with subsidiaries in several countries does not face one AI regime but several, differing in scope, in the obligations they impose and in the pace at which they change. Do not resolve them at corporate level with a lowest common denominator; resolve them per system, with the deepest obligation winning. Three artefacts make this routine.
What to actually do
Build the applicability map. For every AI system in the inventory, record the jurisdictions in which it is placed on the market, put into service or produces effects on people (territorial scope); the regimes that follow — AI-specific regime, data-protection law, sector rules, use-specific rules such as those on employment or credit decisions (normative scope); and which entity of the group is provider, deployer or both for it (corporate scope). This is the artefact the rules factor is read from.
Build the regime map. For each jurisdiction in which you operate, list the obligations its AI-specific, data-protection, sector and use-specific rules impose on you, and trace each to the dimension of this framework that meets it. Most resolve to a small set that is already in the Baseline or the person-affecting pack: disclosure of AI use, human review of adverse decisions, impact or bias assessment before use, notice of decision criteria, provenance marking of synthetic content, incident reporting and documentation. Implement the dimension once; evidence it against each jurisdiction through the map. Keep the map current through the regulatory watch of Domain 1.
Apply the resolution rule. For each system, activate the obligations of every jurisdiction in which it produces effects. Where two impose the same kind of obligation at different depths, the deeper applies to that system. Resolve data-residency and processing-location constraints per system through the sourcing dimension, because a single system may lawfully serve one jurisdiction from a given region and not another.
Controls
Enhanced2 controls
Control 239
Maintain the applicability map for every system.
EnhancedPreventiveall rolesper system
What it is
Territorial, normative and corporate scope, kept current on change.
How to implement it · Minimum content
System identifier and name, from the inventory
Territorial scope: jurisdictions where it is placed on the market, put into service, or produces effects on people
Corporate scope: which group entity is provider, deployer, or both
Resulting rules tier for the system
Owner and last review date; update on new country, new use, new entity or rule change
How to start
Add these columns to the inventory and fill them first for systems that affect people.
Evidence
The applicability map with its review dates and the change events that updated it.
Mode: light / standard / full
light
The owner-manager fills the columns, usually for one jurisdiction, with an adviser if needed.
standard
Legal or compliance completes it with owners and updates it through regulatory watch.
full
A regulatory function maintains it across group entities, reviewed by each country's legal team.
Control 240
Apply the per-system maximum when regimes differ, and record the resolution.
EnhancedPreventiveall rolesper system
What it is
Including the residency decision per system.
How to implement it · Steps
From the regime map, list the obligations of every jurisdiction where the system produces effects
Group them by kind: disclosure of AI use, human review, impact or bias assessment, notice of criteria, provenance marking, incident reporting, documentation
Where two jurisdictions require the same kind at different depths, apply the deeper one to the system
Resolve data residency and processing location for this system through sourcing, noting which region may serve which jurisdiction
Record per obligation: jurisdictions, depth applied, reason, date
How to start
Take one system that produces effects in more than one country and build its resolution table.
Evidence
The recorded resolution per system, including its residency decision.
Mode: light / standard / full
light
With one jurisdiction there is usually nothing to resolve; note this and revisit on expansion abroad.
standard
Legal or compliance builds the table per multi-jurisdiction system; the owner implements it.
full
The regulatory function resolves centrally; sourcing applies residency decisions per region.
Evidence
The applicability map; the regime map with its last review date; the recorded resolutions per system.