An engineering control plane for AI governance, across NIST, ISO 42001, and the EU AI Act

For most of the last decade, governing artificial intelligence was largely voluntary. That is no longer the case. The field is moving from optional guidelines to enforceable obligations, and an organization that deploys consequential systems now sits at the intersection of three instruments, each built for a different purpose and none sufficient on its own.

The first is the Artificial Intelligence Risk Management Framework from the United States National Institute of Standards and Technology. It is a voluntary, risk based methodology organized around four functions, which are to govern, to map, to measure, and to manage. Its companion document, the Generative Artificial Intelligence Profile published as the publication numbered AI 600-1, adapts those functions to the specific risks of generative systems and names twelve risk categories, from confabulation to information security to harmful bias.

The second is the international standard for an artificial intelligence management system, published in late 2023 as ISO and IEC 42001. It is the first standard of its kind that an organization can actually be certified against, which matters, because certification is how you demonstrate maturity to a regulator, a partner, or a customer rather than merely asserting it.

The third is the European Union Artificial Intelligence Act, the regulation numbered 2024 stroke 1689, which is the world's first comprehensive and legally binding framework for the technology. It classifies systems by risk, bans a small set of unacceptable uses outright, and places substantial obligations on the systems it deems high risk. Its reach is extraterritorial, so an organization outside the Union whose systems are placed on the Union market or whose outputs affect people in the Union is within scope regardless of where it is headquartered.

The timeline that makes this urgent

The Act applies in phases. The prohibitions on unacceptable uses, together with the obligation to ensure staff have adequate understanding of the technology, took effect in February 2025. The obligations on general purpose models followed in August 2025. The substantial obligations on high risk systems were set to apply from August 2026, although a political agreement reached in May 2026, often referred to as the simplification package, has deferred parts of the high risk timeline. The deadlines moved, but the work required to meet them did not, so the deferral only changes how much time you have to do it. The penalties are designed to be felt even by the largest organizations, reaching up to thirty five million euros or seven percent of worldwide annual turnover for the most serious violations.

Why the three instruments share the same underlying controls

This is the point that turns a large compliance requirement into a manageable engineering project. These three instruments overlap heavily in substance. The framework from NIST provides the risk management methodology. The standard provides the auditable management system. The Act provides the legally binding obligations. An organization that implements all three, using the published crosswalks to align them, does almost no duplicated work, because the controls underneath are shared. The standard alone maps closely to seven core articles of the Act, covering risk management, data governance, technical documentation, record keeping, transparency, human oversight, and quality management.

Turning governance into engineering

The mistake that makes governance painful is treating it as a separate compliance checklist that someone fills in after the system is built. The far better approach, and the one that fits how engineering teams actually work, is to express each control as something the system produces as a side effect of being built well. A system inventory becomes a registry that every deployment writes to automatically. A risk assessment becomes a structured document attached to each system and reviewed at defined gates. Data governance becomes lineage and quality metrics captured in the pipeline. Evaluation becomes a test suite that runs continuously, the same discipline I wrote about for retrieval systems. Monitoring and logging become the same observability you already run, extended to record model behavior. Human oversight becomes an approval step in the workflow. And technical documentation becomes evidence generated as you go, rather than reconstructed under deadline.

Done this way, the three instruments stop being three projects. They become three views over one body of evidence. When the auditor arrives for the standard, when leadership asks about alignment with the framework, and when the regulator asks about the Act, you are drawing different reports from the same control plane.

The payments lens

None of this is unfamiliar to anyone who has worked in a regulated industry. Payments, banking, and utilities have lived under exactly this model for decades, where controls are designed in, evidence is generated continuously, and an external party can audit the result. Artificial intelligence is simply another regulated workload arriving into an organization that, if it is in one of these industries, already knows how to do this. The advantage goes to teams that recognize the pattern and reuse the muscle they already have, rather than treating AI governance as something exotic.

Summary

Treat the three instruments as three dialects describing one set of controls, build those controls into the way your systems are made rather than bolting them on afterwards, and generate the evidence as a by product of good engineering. That turns a frightening compliance picture into something a competent engineering organization already knows how to deliver.