Audit-first AI governanceA control crosswalk for AI governance
The major AI-governance and model-risk regimes share a backbone. This map names them accurately, ties each to an enforceable control, and shows — honestly — which KAiM Helm controls satisfy them today and which are still being built.
Every regulated organization now answers to several AI-governance regimes at once, and the list keeps growing. A community bank running an AI-assisted underwriting workflow may sit inside the lineage of supervisory model-risk expectations, inside an internal AI policy modeled on a recognized management-system standard, and — if it touches EU customers or vendors — inside the reach of the EU AI Act. A health system, an insurer, and a public agency each carry their own overlapping stack.
The instinct is to treat each regime as a separate compliance project. That is expensive, and it misses the more useful fact: these frameworks rhyme. Underneath different vocabularies, they converge on the same small set of expectations about how an organization should govern automated decisions. Once you see the backbone, the work shifts from "satisfy four frameworks" to "stand up the controls the backbone demands, and map them outward."
This article does that mapping. It names the regimes precisely, states the shared control expectations at the level where they are well established, and shows which KAiM Helm control operationalizes each — with candid status, because the gaps matter as much as the coverage.
The regimes, named accurately
Four reference points cover most of what regulated organizations face.
NIST AI Risk Management Framework. A voluntary, widely adopted framework organized around four functions — Govern, Map, Measure, Manage. It is structural rather than prescriptive: it tells you what capabilities a risk program should have, not which thresholds to set.
EU AI Act. A binding, risk-tiered regime. It sorts AI systems by risk level and attaches the heaviest obligations to high-risk uses — including requirements around transparency and the provision of information to users (Article 13) and meaningful human oversight. Specifics vary by system and role; the durable structure is risk-tiering plus obligations that scale with risk.
ISO/IEC 42001. The management-system standard for AI — an "AI management system" in the same family as ISO/IEC 27001 for information security. It expects defined roles, documented policies, risk treatment, and continual improvement, and it is certifiable.
Bank model-risk management. The supervisory lineage associated with the OCC and the Federal Reserve, anchored by SR 11-7. Its established pillars are model development, independent validation and effective challenge, governance and controls, and ongoing monitoring. Though written for banks, its logic — independent challenge and continuous monitoring of consequential models — travels well.
These are not the same document, and we do not pretend they line up cleanly. But where they overlap, they overlap on controls. That overlap is the crosswalk.
The crosswalk
| Control expectation | Where it shows up | KAiM Helm control that operationalizes it | Status |
|---|---|---|---|
| Model / use-case inventory | NIST Map; ISO 42001 (scope & assets); model-risk (model inventory) | Each agent registered with a declared purpose and bounded authority; decision records make actual use observable | Partial — per-agent registration is built; a consolidated, organization-wide inventory view is being built |
| Risk tiering of use cases | EU AI Act (risk tiers); NIST Map/Measure; model-risk (materiality) | Authority bounds and check stringency set per agent according to the stakes of its actions | Built |
| Approval authority for deployment | ISO 42001 (roles & responsibilities); model-risk (governance); NIST Govern | Bounded authority defined per agent before it acts; actions outside bounds cannot self-approve | Built |
| Independent validation / effective challenge | Model-risk (SR 11-7 core); NIST Measure | Six-axis checks (Authority, Policy, Evidence, Harm, Regulation, Escalation) evaluated independently of the acting agent at the point of action | Partial — point-of-action challenge is built; periodic independent revalidation of an agent over time is sequenced |
| Ongoing monitoring | Model-risk (ongoing monitoring); NIST Manage; ISO 42001 (performance evaluation) | Append-only decision records capture every allow/block/escalate outcome for review | Partial — the record stream is built; quantitative monitoring dashboards and drift metrics are being built |
| Human oversight / escalation | EU AI Act (human oversight); NIST Manage; ISO 42001 | Escalate-rather-than-act fallback: when a check is uncertain or out of bounds, the agent routes to a human instead of proceeding | Built |
| Decision evidence / adverse-action support | EU AI Act (Art. 13 transparency); model-risk (documentation); NIST Govern | Signed, append-only decision records tie each action to the policy, evidence, and authority that permitted it | Built |
| Third-party / vendor risk | EU AI Act (provider/deployer duties); ISO 42001 (supplier controls); model-risk (vendor models) | Externally sourced agents and models run under the same bounded authority and six-axis checks as internal ones | Partial — runtime containment is built; formal vendor due-diligence intake is sequenced |
| Audit artifacts | All four (auditability is a shared premise) | The append-only record is the audit artifact — produced as a byproduct of operation, not reconstructed after the fact | Built |
| Limits & fallback behavior | NIST Manage; model-risk (controls); EU AI Act (oversight) | Hard authority limits per agent plus a default-deny fallback: absent a clear allow, the action does not fire | Built |
How to read this
Three things to keep in mind.
First, the "where it shows up" column points to the structural home of each expectation, not to a clause-by-clause citation. Mapping a specific control to a specific article or paragraph is the work of a scoped assessment against your actual systems — not something to assert in a library article. We have kept this column at the level the frameworks themselves are explicit about.
Second, status is honest, not aspirational. Built means the control fires today in KAiM Helm's design-partner pilots and controlled demonstrations. Partial means the core mechanism exists but a recognizable piece of the expectation is still being completed. Sequenced means it is on the roadmap with a known place in line, not yet in the product. We would rather you discover a Partial here than in a regulator's findings letter.
Third, KAiM Helm is at the design-partner and controlled-demonstration stage. The controls described are real and demonstrable; we make no customer-deployment or certification claims, and nothing here should be read as one.
Candid gaps
The honest weak spots are worth stating plainly. A consolidated model and use-case inventory — the single pane every framework implicitly assumes — is still being built; today the inventory is assembled from per-agent registration and the decision record. Quantitative ongoing-monitoring dashboards, including drift and performance metrics over time, are being built on top of the record stream rather than already presented. And formal vendor due-diligence intake is sequenced: KAiM Helm already contains third-party agents at runtime, but the structured intake-and-assessment workflow for vendors is roadmap, not product.
None of these gaps undermine the core claim. The point of KAiM Helm is enforcement at the point of action, and that is where the Built controls concentrate. The Partial and Sequenced items are largely reporting and process layers built on a foundation that already fires.
Key takeaways
- The regimes share a backbone. NIST AI RMF, the EU AI Act, ISO/IEC 42001, and bank model-risk management use different language but converge on roughly ten control expectations. Build to the backbone and you address all four at once.
- A framework is not a control. A policy document does not stop a non-compliant action; a control evaluated at the point of action does. KAiM Helm's value is turning expectations you already answer to into checks that actually fire — allow, block, or escalate.
- The strong coverage is at the point of action. Bounded authority, six-axis checks, escalate-rather-than-act, default-deny limits, and signed append-only records are Built. That is the enforcement core.
- The gaps are reporting and process, and we name them. Consolidated inventory, quantitative monitoring dashboards, and formal vendor due-diligence are Partial or Sequenced. Honesty about the line between built and roadmap is the point.
- The goal is fewer frameworks doing more work — not another one to track.
The frameworks are not going to consolidate themselves, and adding a fifth governance model on top of four is not progress. The useful move is to take the regimes you already answer to and turn their shared expectations into controls that fire at the moment a decision is made.
If you want to see where your own program sits against this crosswalk — what is Built, what is Partial, and where the real gaps are — start with a Control Gap Assessment. It is a scoped read of your AI decisions against the same backbone mapped above, with honest status for each control.