Cross-regime crosswalk
One AI system rarely sits under one regime. Where two obligations from different regimes ask for substantially the same thing, the work — and the evidence — is reusable. Every mapping below is an interpretive claim, so it carries its reasoning and its confidence openly.
Target market(s)European UnionUnited States (federal)change
The crosswalk in numbers
Regime pairs
Which regimes the graph currently connects, and how confident those connections are.
| Regime | Regime | Mappings | Established | Asserted |
|---|---|---|---|---|
| EU AI Act | GDPR | 4 | 1 | 3 |
| EU AI Act | ISO/IEC 42001:2023 (AIMS) | 3 | 1 | 2 |
| EU AI Act | NIST AI RMF 1.0 | 2 | 0 | 2 |
| AI Framework Act (KR) | EU AI Act | 1 | 0 | 1 |
| EU AI Act | EN 18286:2026 (QMS for AI Act) | 1 | 1 | 0 |
| EU AI Act | ISO/IEC 23894 (AI Risk Management) | 1 | 1 | 0 |
| EU AI Act | ISO/IEC 42005 (AI Impact Assessment) | 1 | 1 | 0 |
| EU AI Act | ISO/IEC 5259 (Data Quality for ML) | 1 | 1 | 0 |
| EU AI Act | ISO/IEC 27001:2022 + A.8.28 | 1 | 1 | 0 |
| EU AI Act | NIST AI 600-1 (GenAI Profile) | 1 | 0 | 1 |
| EU AI Act | NIS2 Directive | 1 | 0 | 1 |
| EU AI Act | DORA | 1 | 0 | 1 |
| EU AI Act | Colorado AI Act | 1 | 0 | 1 |
| EU AI Act | NYC Local Law 144 (AEDT) | 1 | 0 | 1 |
| GDPR | NIS2 Directive | 1 | 1 | 0 |
Every mapping, with its reasoning
Art. 17 requires a documented quality management system for high-risk providers; ISO/IEC 42001 specifies a certifiable AI management system with the same governance objects (policy, roles, risk and change control, documented information). The mapping is established practice — EN 18286:2026 exists precisely to harmonise the AI Act QMS duty with management-system structure. It is a management-system equivalence, not a product presumption of conformity.
EN 18286:2026 is the European QMS standard written against the Art. 17 quality-management duty. Following it is the intended route to that duty; a presumption of conformity depends on citation in the Official Journal, which the standards-watch layer tracks separately.
Art. 9 requires a continuous risk-management system across the lifecycle; ISO/IEC 23894 supplies the AI-specific extension of ISO 31000 that structures exactly that cycle. Overlap, not equivalence: the standard is guidance and does not carry the Art. 9 residual-risk acceptability test.
The NIST AI RMF Map and Measure functions produce the quantified risk information the Art. 9 register needs, and the Govern function covers the surrounding accountability. Asserted: the RMF is voluntary and organised by function rather than by lifecycle stage, so the fit is analytical rather than clause-by-clause.
Both are pre-use impact assessments over the same deployment. Art. 27(4) states expressly that where a DPIA has already been carried out, the FRIA complements it — so the DPIA covers processing risk to data subjects and the FRIA covers fundamental-rights harm to affected persons and groups. One assessment file with two labelled parts is the usual answer.
- Art. 27 — Fundamental Rights Impact Assessmentoverlaps withISO/IEC 42005 (AI Impact Assessment)established
ISO/IEC 42005 defines an AI system impact-assessment process. It supplies the method; Art. 27(1) supplies the mandatory content list. Running the standard's process without the Art. 27(1) enumeration leaves the legal duty unfinished.
Art. 10 sets data-governance duties over training, validation and test data; ISO/IEC 5259 defines data-quality measures, processes and reporting for machine learning. The standard operationalises the duty; it does not cover the Art. 10(5) special-category exception.
Art. 15 requires accuracy, robustness and cybersecurity across the lifecycle. ISO/IEC 27001 with A.8.28 covers the security half of that duty for the surrounding system; accuracy and adversarial robustness of the model are outside its scope.
The NIST GenAI profile (AI 600-1) enumerates generative-AI specific risks and mitigations that map onto the Art. 15 robustness and cybersecurity duty for GPAI-based systems. Asserted: it is a US voluntary profile with no formal relationship to the AI Act.
Annex IV technical documentation and the ISO/IEC 42001 documented-information requirements ask for overlapping artifacts (system description, risk treatment, change history). Asserted: the standard prescribes control of documents, not the Annex IV point structure, so an AIMS document set is a starting point and not a technical file.
Art. 4 requires AI literacy of staff operating or affected by AI systems; ISO/IEC 42001 Clause 7.2 requires competence for persons doing work affecting AI performance. Asserted: the standard's competence duty is narrower than the Act's literacy duty, which also reaches affected persons.
Art. 12 record-keeping produces the traceability evidence the RMF Measure and Manage functions assume. Asserted: the RMF names no retention period and no log content, so it cannot discharge the Art. 12 duty on its own.
- Art. 72/73 — Post-Market Monitoring & Incidentsoverlaps withNIS2 Art. 23 — Significant-Incident Reportingasserted
Both are post-market incident duties over the same operational event, on different clocks and to different authorities (market-surveillance authority vs CSIRT/competent authority). Evidence is reusable — one incident register feeds both — but the deadlines are not interchangeable. Asserted: the classification thresholds differ (serious AI incident vs significant incident).
- Art. 72/73 — Post-Market Monitoring & Incidentsoverlaps withDORA Art. 19 — Major ICT-Incident Reportingasserted
For financial entities a major ICT incident involving an AI system can trigger both the DORA Art. 19 report to the competent authority and the AI Act serious-incident report. Asserted: DORA's classification criteria are set by its own RTS and do not track the AI Act definition.
- GDPR Art. 33/34 — Personal-Data Breach Notificationoverlaps withNIS2 Art. 23 — Significant-Incident Reportingestablished
A single security event frequently is both a personal-data breach (72 hours to the supervisory authority) and a significant incident (24-hour early warning, 72-hour notification). The overlap is well documented in supervisory guidance; the notifications go to different authorities and cannot be merged.
GDPR Art. 22(3) requires the right to obtain human intervention in solely automated decisions; Art. 14 requires human oversight designed into high-risk systems. Asserted: Art. 14 is a design duty on the provider and Art. 22 is a data-subject right against the controller — the same oversight capability serves both, the legal tests differ.
Data protection by design and by default (minimisation, purpose limitation) constrains the same data pipeline that Art. 10 governs for quality and representativeness. Asserted: the two duties can pull in opposite directions, which is exactly why the mapping is a planning aid and not an equivalence.
Korea's AI Framework Act imposes risk-management, documentation, human-oversight and transparency duties on high-impact AI that mirror the AI Act's high-risk duty set, which makes one control set largely reusable. Asserted: the high-impact scope definition and the enforcement architecture are Korea's own, and the Presidential Decree detail is still settling.
The Colorado AI Act works from the same building blocks — a consequential-decision trigger, developer/deployer split, impact assessment, notice duties — so an AI Act programme covers much of it. Asserted: Colorado's duties turn on algorithmic discrimination rather than a conformity-assessment regime, and its dates and text have moved repeatedly.
NYC Local Law 144 requires an independent bias audit before using an automated employment decision tool, and Art. 27 requires a fundamental-rights impact assessment before deploying a high-risk system in the same hiring context. Asserted: LL 144 prescribes an external audit with published results, which the FRIA does not — the FRIA cannot substitute for it.
Art. 12 with the Art. 19 retention duty requires automatically generated logs to be kept (at least six months for deployers under Art. 26(6)), while GDPR Art. 17 gives data subjects erasure rights over personal data those logs contain. The tension is real and must be resolved deliberately — usually by pseudonymising log payloads and relying on the Art. 17(3)(b) legal-obligation exception for the retention window, documented in the retention policy. Asserted: the resolution is a legal judgement, not a settled position.
Comply once, evidence many
Computed from the graph's evidenced_by edges, not asserted here: these artifacts already discharge obligations in more than one regime. Build them first.
- Event Logs & Decision Traces10 regimes
- EU AI Act — Art. 12 — Record-Keeping / Logging · CO: Log Completeness & Coverage · CO: Log Integrity & Non-Repudiation · CO: Non-Human Identity Governance
- DORA — DORA · DORA Art. 19 — Major ICT-Incident Reporting
- GDPR — GDPR · GDPR Art. 33/34 — Personal-Data Breach Notification
- HIPAA (US Health Privacy) — HIPAA (US Health Privacy) · HIPAA Breach Notification Rule
- NIS2 Directive — NIS2 Directive · NIS2 Art. 23 — Significant-Incident Reporting
- AI Liability Directive (withdrawn) — AI Liability Directive (withdrawn)
- Cyber Resilience Act — CRA Art. 14 — Vulnerability & Severe-Incident Reporting
- FprEN ISO/IEC 24970 (AI Logging) — FprEN ISO/IEC 24970 (AI Logging)
- Revised Product Liability Directive — Revised Product Liability Directive
- SEC Cybersecurity Disclosure Rules (Item 1.05 Form 8-K) — SEC Form 8-K Item 1.05 — Material Cybersecurity Incident
- Serious-Incident Register5 regimes
- Cyber Resilience Act — CRA Art. 14 — Vulnerability & Severe-Incident Reporting
- DORA — DORA Art. 19 — Major ICT-Incident Reporting
- EU AI Act — Art. 72/73 — Post-Market Monitoring & Incidents
- NIS2 Directive — NIS2 Art. 23 — Significant-Incident Reporting
- SEC Cybersecurity Disclosure Rules (Item 1.05 Form 8-K) — SEC Form 8-K Item 1.05 — Material Cybersecurity Incident
- Post-Market Monitoring Plan & Incident Reports3 regimes
- EU AI Act — Art. 72/73 — Post-Market Monitoring & Incidents · CO: Performance Monitoring & Drift Management
- DORA — DORA
- NIS2 Directive — NIS2 Directive
- Vendor & Model Due-Diligence Records3 regimes
- EU AI Act — Art. 26 — Deployer Obligations · CO: Embedded-AI Vendor Governance
- DORA — DORA
- HIPAA (US Health Privacy) — HIPAA (US Health Privacy)
- Human-Oversight Protocol & Intervention Records2 regimes
- EU AI Act — Art. 14 — Human Oversight · CO: Log Access & Retention Governance · CO: Oversight Competence & Authority
- GDPR — GDPR Art. 22 — Automated Decisions
- SBOM & Vulnerability Management Records2 regimes
- Cyber Resilience Act — Cyber Resilience Act
- NIS2 Directive — NIS2 Directive
- Immutable Decision Ledger (WORM)2 regimes
- EU AI Act — CO: Log Integrity & Non-Repudiation · Art. 12 — Record-Keeping / Logging
- IFRS / US GAAP Reporting Assurance — IFRS / US GAAP Reporting Assurance
- Personal-Data Breach Notification Record2 regimes
- GDPR — GDPR Art. 33/34 — Personal-Data Breach Notification
- HIPAA (US Health Privacy) — HIPAA Breach Notification Rule
- Individual Explanation Letters & Counterfactual Records2 regimes
- EU AI Act — Art. 86 — Right to explanation of individual decision-making
- GDPR — GDPR Art. 22 — Automated Decisions
Indicative decision support, not legal advice. Risk classification depends on your concrete deployment context and can change with scope drift — validate the result with qualified counsel.