Crosswalk pair
AI Governance Essentials and EU AI Act, control by control
9 canonical controls in Keel’s library satisfy clauses of both AI Governance Essentials and EU AI Act. 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. EU AI Act counts as one of your plan’s paid frameworks, or from $39/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.
9
Controls that satisfy both
Canonical controls that crosswalk to at least one clause of each.
24
In Keel’s library for AI Governance Essentials
38% of them also map to EU AI Act.
21
In Keel’s library for EU AI Act
43% of them also map to AI Governance Essentials.
24
Evidence artifacts expected
Across the shared controls, from Keel’s evidence guidance. Gathered once.
-
9 controls of 24 in Keel’s library for AI Governance Essentials also map to EU AI Act.
-
EU AI Act 43%
9 controls of 21 in Keel’s library for EU AI Act 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 | EU AI Act clauses |
|---|---|---|
| Governance & Risk | ||
| AI copyright & intellectual-property compliance The organization checks that what goes into its AI systems, and what comes out of them, respects other people’s intellectual property and the terms the material was made available under. Inputs are checked before use: training and tuning data, models, code and content taken from outside carry licenses, and what each license actually permits for this use - commercial use, redistribution, incorporation into a product the organization sells, retention of the weights derived from it - is established and recorded rather than assumed generous. Outputs are checked as well, because a system can produce material that infringes even where every input was licensed, and what the organization will do when that happens is decided in advance rather than during the complaint. Where the organization provides a general-purpose AI model, it additionally puts in place a policy to comply with Union law on copyright and related rights, and that policy is operative rather than declaratory: it identifies reservations of rights expressed by rightsholders against text and data mining and complies with them, using state-of-the-art technology to do so, and it is revisited as the means of expressing and detecting those reservations move. Who owns the policy, what it requires of a training run before the run starts, and the record of a run having been checked against it are held rather than left with whichever team launched the job. | DA.5 | GPAI-3 |
| 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 | HREQ-3 |
| 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 | TRANS-1, HREQ-5 |
| 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 | HREQ-6, HOBL-5 |
| Marking of AI-generated and manipulated content Where the organization provides an AI system that generates synthetic audio, image, video or text - a general-purpose AI system included - the system is designed and developed so that its outputs are marked in a machine-readable format and are detectable as artificially generated or manipulated. The marking is a technical solution held to a standard rather than a line in the terms of service: it is effective, interoperable, robust and reliable as far as is technically feasible, judged against the specificities and the limits of the content type, what implementing it costs, and the generally acknowledged state of the art - and it is re-tested when the generation pipeline changes, because a marking that survived last quarter’s encoder is not evidence about this one. The organization records which of its systems this applies to and which it has determined it does not: a system performing an assistive function for standard editing, or one that does not substantially alter the input the deployer provided or the meaning of it, with the reasoning written down, so an exclusion is an argument on the page rather than a silence. Separately from the machine-readable case, content that is generated or materially altered by AI is labeled to the people who will see it wherever its nature would otherwise mislead them, in terms they will actually read, at the point they encounter it. | TR.4 | TRANS-2 |
| Prohibited and high-risk AI use screening Every intended use of AI is screened against the categories the organization has decided it will not pursue and the categories that trigger heightened obligations, before development or procurement starts and again whenever the intended use changes. The prohibited list is stated as specific practices rather than as a principle, so that a proposal can be tested against it: an AI system that uses subliminal, purposefully manipulative or deceptive techniques to materially distort a person’s behavior in a way that causes or is reasonably likely to cause significant harm; one that exploits vulnerabilities of age, disability, or a specific social or economic situation to the same effect; one that evaluates or classifies people over a period of time by their social behavior or their personal characteristics, where the resulting social score leads to detrimental treatment in a context unrelated to where the data came from, or to treatment out of proportion to the behavior; one that predicts the risk of a person committing a criminal offense based solely on profiling or on assessing personality traits; one that creates or expands facial-recognition databases through untargeted scraping of facial images from the internet or from CCTV footage; one that infers the emotions of a person in the workplace or in an education institution, outside medical or safety purposes; one that categorizes individuals by their biometric data in order to deduce race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation; and real-time remote biometric identification in publicly accessible spaces for law enforcement, which is barred except in the narrow, separately authorized circumstances the law itself sets out. A proposal that matches one of these is stopped rather than mitigated. A proposal that matches a heightened-risk category is escalated to the people authorized to decide it. The screening result, the reasoning, and the decision are recorded either way, so a use that was allowed is as traceable as one that was refused. | RM.5 | PROH-1, PROH-2, PROH-3, PROH-4, PROH-5, PROH-6, PROH-7, PROH-8 |
| Data Protection & Privacy | ||
| Data governance for AI Governance of the data used to develop and operate AI systems: sourcing, quality, provenance, and preparation of training and operational data. Where each training and tuning dataset came from is recorded, and the organization confirms it is permitted to use it for that purpose before the data is used rather than after somebody raises the question. Data is checked for whether it is accurate and appropriate for the people and the cases the system will actually affect - representative of that population rather than of whoever was easiest to collect from - and a shortfall found is recorded and acted on instead of noted. Only the data the AI purpose needs is used: a field nobody can tie to the purpose does not enter the pipeline, and what is used is kept no longer than the purpose justifies, with the retention period stated per dataset and enforced when it ends. | DA.1, DA.2, DA.4 | HREQ-2 |
| 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. | SR.2, LC.1 | HREQ-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 | HOBL-5, HOBL-6, HOBL-7 |
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 9 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
- 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 AI Risk Management Framework 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
- AI Governance Essentials and ISO/IEC 42001 13 shared controls
- AI Governance Essentials and NIST AI Risk Management Framework 13 shared controls
- EU AI Act and ISO/IEC 42001 8 shared controls
- EU AI Act and NIST AI Risk Management Framework 6 shared controls
- AI Governance Essentials and ESG Essentials 1 shared control
- AI Governance Essentials and GDPR 1 shared control
The thesis
Why this is one project, not two
On a crosswalk-native model, EU AI Act 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 EU AI Act to the work you already did
Apply both frameworks in one workspace and see the overlap measured against the controls you already hold.