Crosswalk pair
EU AI Act and NIST AI Risk Management Framework, control by control
6 canonical controls in Keel’s library satisfy clauses of both EU AI Act and NIST AI Risk Management Framework. Implement each once, attach the evidence once, and it counts toward each standard. The overlap is the work you don’t repeat.
EU AI Act counts as one of your plan’s paid frameworks, or from $39/mo as an add-on. NIST AI Risk Management Framework counts as one of your plan’s paid frameworks, or from $19/mo as an add-on. See plans and pricing.
The overlap
What the two libraries have in common
Every figure here counts canonical controls in Keel’s library, not clauses of either standard. Each standard’s own authored count is on its framework page.
6
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
21
In Keel’s library for EU AI Act
29% of them also map to NIST AI Risk Management Framework.
27
In Keel’s library for NIST AI Risk Management Framework
22% of them also map to EU AI Act.
12
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
EU AI Act 29%
6 controls of 21 in Keel’s library for EU AI Act also map to NIST AI Risk Management Framework.
-
NIST AI Risk Management Framework 22%
6 controls of 27 in Keel’s library for NIST AI Risk Management Framework also map to EU AI Act.
The mapping
Controls that satisfy both
Each row is one control in Keel’s library and the clauses it answers on each side. Do the work once; both columns are then evidenced by the same artifacts.
| Canonical control | EU AI Act clauses | NIST AI Risk Management Framework clauses |
|---|---|---|
| Governance & Risk | ||
| AI risk management process A process to identify, analyze, prioritize, and treat the risks an AI system can pose, tracked over its lifecycle. The organization’s risk tolerances for AI are determined and written down first, and the level of risk management activity a given system attracts is set against them, so a low-stakes internal tool and a system that decides something about a person are not put through the same process by default. Tracking is continuous rather than a single pass: existing, unanticipated and emergent risks are identified regularly by named people working from documented approaches, and are read against both how the system was expected to perform and how it actually performs in the context it was deployed into. Where a risk cannot be assessed with the measurement techniques available, or no metric for it exists yet, that is not treated as an absence - a tracking approach is chosen for it deliberately and recorded, so the risk stays visible while it is unmeasurable. The resources needed to manage AI risk are accounted for as part of the treatment decision, and a viable non-AI alternative system, approach or method is weighed on the same terms as any other mitigation, because not building the system is sometimes what reduces the magnitude or likelihood of the impact most. The process itself is monitored and periodically reviewed on a plan: who reviews it and how often is decided in advance and written down, and both the process and the outcomes it produced are examined, so a process that has quietly stopped surfacing anything is noticed rather than trusted. The assessment is a defined process rather than an exercise: the criteria for accepting AI risk, and the criteria for deciding when an assessment is performed at all, are set in advance and applied the same way each time, so repeated assessments produce consistent and comparable results rather than a different answer depending on who ran them. It is performed at planned intervals and again when a significant change is proposed or has happened - a new intended use, a new model, a new data source, a new population it is used on - and the results of each run are retained as documented information. | HREQ-1 | GOVERN-1.3, GOVERN-1.5, MAP-1.5, MEASURE-1.1, MEASURE-3.1, MEASURE-3.2, MANAGE-1.2, MANAGE-1.3, MANAGE-2.1 |
| AI technical documentation Maintained technical documentation of an AI system’s design, development, and impact assessments, sufficient to demonstrate how it works and was built. It states the system’s knowledge limits - what it was built to handle, what it was not, and the conditions under which its output should not be relied on - together with how that output may be used and how a person oversees it, in enough detail that someone deciding whether to act on an output can decide well rather than guess. It also identifies, component by component, the internal risk controls the organization relies on for that component, third-party AI technologies and pre-trained models included, so the controls standing behind a system are documented in one place instead of being inferred from whichever team implemented each part. The documentation is written for the teams that rely on the system as much as for an assessor: its purpose, the data behind it, its limits and the use it is intended for are stated in one place they can find, and are kept current as the system changes rather than fixed at the version that was first written. | HREQ-3 | MAP-2.2, MAP-4.2 |
| AI transparency & disclosure Clear information for users and interested parties, including disclosing when people are interacting with an AI system and how to use it appropriately. The risks to transparency and accountability that mapping identified are examined and documented in their own right - a decision the system contributed to that could not be explained afterwards, an outcome whose ownership would be unclear if it were challenged, a disclosure that is technically present but not usable by the person it is for - rather than being treated as discharged by the fact that a disclosure exists. The model is explained, the explanation is validated rather than asserted, and both are documented; the system’s output is interpreted within the context it is used in, so that what an output means, and what it does not mean, informs responsible use and the governance decisions taken on top of it. Negative residual risk - what is left unmitigated after treatment - is written down and passed to the people who will actually carry it: downstream acquirers who will build on the system, and end users who will act on what it produces. People are told when they are interacting with an AI system, and when AI materially shapes a decision about them, at the point it happens rather than in a policy they would have to go looking for. The basis of a consequential AI-assisted decision can be given to the person it was about in plain terms - what mattered, and what would have had to be different - rather than only as a technical account that satisfies an engineer. Information owed to parties outside the organization is provided rather than waited for: what external interested parties need to know about the organization’s AI systems - regulators, customers, the people a system is used on, and those who represent them - is determined, and there is a route by which they receive it and can come back with a question. | TRANS-1, HREQ-5 | MEASURE-2.8, MEASURE-2.9, MANAGE-1.4 |
| Human oversight of AI Appropriate human oversight of AI systems, so people can understand, monitor, and intervene in how an AI system operates - the named people who hold that oversight have the competence, the authority and the access to the system to exercise it, and the system is operated in the way the instructions supplied with it specify, inside the purpose it was assessed and approved for rather than whatever use it turns out to support. Policy defines and differentiates the roles in each human-AI configuration instead of letting "a human is involved" stand for all of them: where a person decides and the system only advises, where the system decides and a person reviews before the outcome takes effect, and where the system acts alone with a person monitoring after the fact - each configuration naming who holds the oversight role, what they are expected to check, and what they are empowered to do about it. The oversight process for a given system is then defined in line with those policies, assessed against whether it actually works in practice rather than on paper, and documented. | HREQ-6, HOBL-5 | GOVERN-3.2, MAP-3.5 |
| Infrastructure & Operations | ||
| AI verification, validation & robustness Testing that an AI system meets its requirements and performs with appropriate accuracy, robustness, and security before and during use. Safety is evaluated on its own terms and on a regular cadence, against the safety risks identified when the system was mapped: the system is demonstrated to be safe before it is deployed, its residual negative risk is shown to sit inside the stated risk tolerance rather than merely to have been reduced by some amount, and it is shown to fail safely - particularly when it is driven beyond the limits of what it knows. The safety metrics used reach reliability and robustness, what is watched in real time, and how quickly a failure of the system is responded to. Validation before go-live is a gate rather than a report: what the system has to demonstrate about meeting its intended purpose and the risk criteria set for it is decided in advance, and a system that does not meet them does not go into service. Performance is tested for stability as well as for accuracy - across the range of inputs, populations and operating conditions the system will actually meet in production, not only on the data it was built on. | HREQ-7 | MEASURE-2.3, MEASURE-2.4, MEASURE-2.5, MEASURE-2.6, MEASURE-2.7 |
| Resilience & Continuity | ||
| AI monitoring & malfunction reporting Ongoing monitoring of AI systems in operation, with a process to detect, communicate, and report malfunctions and serious incidents. The process covers the risk nobody anticipated as well as the failure modes that were designed for: when a previously unknown risk is identified, there are procedures to follow rather than a meeting to convene - contain it, decide whether the system keeps running while it is understood, recover the service and the people it affected, and feed what was learned back into the risk record - and those procedures are actually followed and the run of them recorded. Monitoring is aimed at what degrades quietly as well as at what breaks: drift in the data or in the population, degradation in accuracy, and outcomes nobody expected are watched against a baseline recorded at deployment, on a stated cadence, with a threshold that triggers action rather than a chart somebody may look at. Incidents and harms are detected, recorded and responded to on a defined route with named responders, and what was learned goes back into the risk record and into the program rather than closing with the ticket. | HOBL-5, HOBL-6, HOBL-7 | MANAGE-2.3, MANAGE-4.1, MANAGE-4.3 |
Beyond the pair
Where else this work counts
A framework is lit when a shared control above also maps to it. Unlit means none of them do, which is an absence rather than a judgment about that standard.
Also reached by these 6 controls
- AI Governance Essentials also reached
- Amazon Appstore Child-Directed Apps not reached
- Apple App Store Kids Category not reached
- CIS Critical Security Controls not reached
- COPPA not reached
- ESG Essentials not reached
- FedRAMP 20x not reached
- FedRAMP Consolidated Rules not reached
- FedRAMP Rev5 Class B not reached
- FedRAMP Rev5 Class C not reached
- FedRAMP Rev5 Class D not reached
- GDPR not reached
- Google Play Families not reached
- HIPAA not reached
- ISO 9001 not reached
- ISO/IEC 27001 not reached
- ISO/IEC 42001 also reached
- NIST Cybersecurity Framework not reached
- NIST SP 800-171 not reached
- NIST SP 800-53 not reached
- PCI DSS not reached
- PIPEDA not reached
- SOC 2 not reached
- SOX (Sarbanes-Oxley) Section 404 not reached
- US Employment Law - Federal Baseline not reached
Nearby pairs
- NIST AI Risk Management Framework and ISO/IEC 42001 14 shared controls
- NIST AI Risk Management Framework and AI Governance Essentials 13 shared controls
- EU AI Act and AI Governance Essentials 9 shared controls
- EU AI Act and ISO/IEC 42001 8 shared controls
- NIST AI Risk Management Framework and ISO/IEC 27001 2 shared controls
- NIST AI Risk Management Framework and NIST Cybersecurity Framework 2 shared controls
The thesis
Why this is one project, not two
On a crosswalk-native model, NIST AI Risk Management Framework mostly lights up controls you already built for EU AI Act. You’re not re-uploading the same screenshot for a second audit. You apply the framework and see the genuine delta worth working. That’s the whole idea behind collect once, comply everywhere.
Next step
Add NIST AI Risk Management Framework to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.