Crosswalk pair
AI Governance Essentials and NIST AI Risk Management Framework, control by control
13 canonical controls in Keel’s library satisfy clauses of both AI Governance Essentials 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.
AI Governance Essentials is free on every plan. 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.
13
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
24
In Keel’s library for AI Governance Essentials
54% of them also map to NIST AI Risk Management Framework.
27
In Keel’s library for NIST AI Risk Management Framework
48% of them also map to AI Governance Essentials.
33
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
13 controls of 24 in Keel’s library for AI Governance Essentials also map to NIST AI Risk Management Framework.
-
NIST AI Risk Management Framework 48%
13 controls of 27 in Keel’s library for NIST AI Risk Management Framework also map to AI Governance Essentials.
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 | AI Governance Essentials clauses | NIST AI Risk Management Framework clauses |
|---|---|---|
| Governance & Risk | ||
| AI policy A documented, leadership-approved policy for the responsible development and use of AI, aligned with the organization’s other policies and reviewed at planned intervals. The policy is where the AI risk management process is established, rather than the process being whatever practice has grown up: it states how AI risk is assessed, who decides what, which of the organization’s risk priorities make an activity mandatory and which leave it to judgment, and what has to be recorded when a decision is taken. It is written to be read by the people it binds and published to them, so the process and the outcomes it produces rest on transparent policy, procedure and control rather than on the standing of whoever happens to be running it. Top management establishes the policy itself rather than ratifying one drafted beneath it: the policy is appropriate to the organization’s purpose, it provides the frame within which AI objectives are set, and it carries a commitment to meet the requirements that apply and to keep improving the management system. It is kept as documented information, communicated inside the organization, and made available to interested parties where that is appropriate. The policy states boundaries as well as principles - where AI may be used, where it may not, and which uses the organization has decided to prohibit outright - written as a rule somebody can be held to rather than as an aspiration, so that a proposed use can be tested against it before any work starts. | GV.1, GV.4 | GOVERN-1.2, GOVERN-1.4 |
| AI roles & accountability Defined and allocated responsibilities for AI across the organization, plus a way for staff to raise concerns about the organization’s AI. Executive leadership holds the decisions about AI risk rather than delegating them out of sight: the decision to develop or deploy an AI system, and the acceptance of the risk that comes with it, is taken by a named executive who answers for it, and the name is recorded with the decision rather than reconstructed afterwards. One owner is named for AI governance as a whole - a single accountable role rather than a committee that shares the answer - and the responsibilities of the teams that build, buy, operate and rely on AI are defined against that ownership, so nothing lands in the gap between two functions. | GV.2 | GOVERN-2.1, GOVERN-2.3 |
| AI system impact assessment A process to assess the potential impacts of AI systems on individuals, groups, and society, and to document and act on the results. The assessment weighs both sides of the ledger. The benefits expected from the system’s intended functionality and performance are examined and written down, rather than assumed from the fact that somebody wanted to build it. So are the potential costs that follow from an expected or realized error, or from functionality and trustworthiness falling short - including the costs that are not monetary, such as time taken from the people it is used on, harm to those wrongly classified, and the erosion of trust that is expensive to rebuild - and both are read against the organization’s stated risk tolerance rather than against nothing. The team that designs, develops, deploys, evaluates or uses the technology is the team that documents its risks and potential impacts, and it does not stop at documenting them: what it found is communicated more broadly, to the people who take the deployment decision and to those who will live with it. The process is defined before it is used and then run to plan: when an impact assessment is required, who performs it, and against what criteria are settled in advance; it is performed at planned intervals and again when circumstances change; and the results of each are retained as documented information. Impacts on wider society are assessed in their own right alongside impacts on individuals and groups - effects on the environment the system operates in, on economies and livelihoods, on public discourse, and on the institutions people rely on - because a system can leave every individual user unharmed and still move something at that scale. | RM.1, RM.2 | MAP-3.1, MAP-3.2, MAP-5.1, GOVERN-4.2 |
| 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. | TR.2 | 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. | TR.1, TR.3 | 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. | HO.1, HO.2 | GOVERN-3.2, MAP-3.5 |
| Infrastructure & Operations | ||
| AI fairness & bias evaluation Fairness and bias are evaluated as a measurement of their own, against the fairness and bias risks identified when the system was mapped, and the results are documented. The evaluation names the groups it is testing for and why those groups; it states the fairness measure being used and what that measure actually claims - an equal error rate and an equal outcome rate are different claims, and choosing between them is a decision that gets recorded rather than absorbed into a tool default; and it reports results per group rather than only in aggregate, since an average is precisely where a disparity hides. It reaches past the model to the data and to the deployment: bias in what was collected and how it was labeled, bias introduced by how people use or over-rely on the output, and bias that only appears in one of the contexts the system runs in. It is repeated rather than performed once before launch, because the population, the data and the use all move. Where a disparity is found, what was decided about it - mitigated, accepted with a stated reason, or the system not deployed - is recorded with the result rather than left in the analyst’s working. | RM.3 | MEASURE-2.11 |
| AI system deactivation & decommissioning An AI system can be turned off, and the organization knows how. Mechanisms exist and are exercised to supersede a system with a replacement, to disengage it from the decisions it feeds, or to deactivate it altogether when its performance or its outcomes turn out to be inconsistent with the use it was intended and approved for - and the responsibility for invoking each of those is assigned to a named role and understood by the people who would have to act, before the day they have to. Decommissioning and phasing a system out is a documented process rather than an unplugging: what depends on the system and what becomes of those dependencies; what is done with the model, the training data and the logs; what is retained so that questions about decisions the system already made can still be answered; what users and affected people are told, and when; and what takes over the function, if anything does. The process is designed so that retiring a system does not raise risk elsewhere or cost the organization the trust it built - an abrupt withdrawal, a silent fallback nobody was told about, and a record destroyed while it was still needed are the three failures it exists to prevent. Rollback belongs to the same capability rather than to a separate hope: a previous version that is known to work is retained and can be returned to, and the route back is exercised rather than assumed to exist. | LC.5 | GOVERN-1.7, MANAGE-2.4 |
| AI system inventory A maintained inventory of the AI systems the organization develops, deploys, or uses, with each system's purpose, owner, and risk classification. | GV.3 | GOVERN-1.6 |
| 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. | SR.2, LC.1 | 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. | LC.3, LC.4 | MANAGE-2.3, MANAGE-4.1, MANAGE-4.3 |
| Third-party Risk | ||
| AI supplier & third-party management Allocation of responsibilities with, and oversight of, the suppliers and third parties involved in developing or providing AI systems and components. The technology and legal risks a third-party component carries are mapped before it is adopted and re-checked while it is in use: what the component actually does, what data it was built on, what the license does and does not permit for the organization’s use of it, and whether that use risks infringing a third party’s intellectual property or other rights - with the approach for doing this in place, followed, and the result documented rather than settled in a procurement thread. Pre-trained models taken from outside and built into a system are monitored on the same terms as the parts the organization wrote, as part of regular monitoring and maintenance, because a model nobody here retrains still changes underneath the system when the provider ships a new version, deprecates the old one, or alters the terms it is offered under. And where a third-party dataset or AI system is judged high-risk, a contingency process is written and kept ready for its failure or its compromise - what the organization falls back to, who is authorized to invoke it, how service is carried on or withdrawn, and what the people relying on the system are told - so a dependency the organization does not control has a planned response instead of an improvised one. Diligence comes before the dependency: the governance, security and risk posture of a supplier whose AI the organization will rely on is assessed and the result recorded before the relationship starts, and re-checked while it runs. What the organization requires of third-party AI is then written into the contract rather than left to expectation - what the supplier may do with data it is given, what it must disclose about the model and its limits, what it must tell the organization when something changes or goes wrong, and who answers for an outcome. | TP.1, TP.2 | GOVERN-6.1, GOVERN-6.2, MAP-4.1, MANAGE-3.1, MANAGE-3.2 |
| People & Culture | ||
| AI competence & training The people and the partners who work with the organization’s AI are trained in AI risk management, pitched at what their duties actually are, so they can carry those duties out consistently with the policies, procedures and agreements that bind them - the people who build, the people who approve, the people who operate, the people who answer for it, and the suppliers and contractors doing any of those on the organization’s behalf. Separately from that awareness, the proficiency of the operators and practitioners who work with a system day to day is treated as a defined process rather than an assumption: what a person must be able to do with this system, including how to read its performance and its trustworthiness characteristics, is set out; they are assessed against it before they are relied on and again periodically; and the assessment is documented. Where relevant technical standards or certifications exist for the work, they are identified and the organization’s position on holding them is recorded rather than left open. Training and proficiency are refreshed when the systems change, when the risks change, or when an assessment showed somebody could not do something the role requires. The human resources the organization’s AI work needs are documented as a resource in their own right: which roles are required, what competencies each must hold, and where the gap sits between that and the people actually available - so a shortfall in people is visible on the same page as a shortfall in compute. The people who operate an AI system or act on its output are trained specifically in what it can and cannot do: the conditions under which its output should not be relied on, the failure modes it is known to have, and the correct way to use it - so its limits are known by the person taking the decision and not only by the team that built it. | HO.3 | GOVERN-2.2, MAP-3.4 |
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 13 controls
- 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
- EU AI Act also 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
- AI Governance Essentials and ISO/IEC 42001 13 shared controls
- AI Governance Essentials and EU AI Act 9 shared controls
- NIST AI Risk Management Framework and EU AI Act 6 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 AI Governance Essentials. 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.