AI governance sounds like a committee problem. In practice it comes down to three questions: what AI are we using, what could go wrong with each one, and who decided that was acceptable.
Three documents dominate how organizations answer those questions. Here is what each actually says.
NIST AI Risk Management Framework
The NIST AI Risk Management Framework, version 1.0, was published in January 2023 by the United States National Institute of Standards and Technology. It is voluntary, free, and not a certification.
It is organized around four functions. Govern, which is the culture and accountability layer and runs through everything else. Map, which is understanding the context and what could go wrong. Measure, which is assessing and tracking those risks. Manage, which is acting on them and monitoring over time.
If that structure feels familiar, it is because it deliberately mirrors the NIST Cybersecurity Framework. NIST later added a Generative AI Profile that applies the framework specifically to generative systems, which is the more useful document for most security teams.
ISO/IEC 42001
ISO/IEC 42001 was published in December 2023 and is the first international standard for an artificial intelligence management system. It is certifiable, which is the important practical difference from the NIST framework.
Structurally it follows the same management system pattern as ISO 27001 for information security: define scope and context, set policy, assign roles, assess risk, apply controls, monitor, audit, and improve. Organizations already certified to ISO 27001 will recognize almost all of the machinery.
Certification matters commercially. It is something you can show a customer or a procurement team without asking them to trust your description of your own processes.
The EU AI Act
The EU AI Act entered into force on 1 August 2024. Unlike the other two it is law, and its obligations phase in over a period of years rather than all at once.
Its central idea is risk tiering. A small set of practices is prohibited outright. A defined set of high risk uses, including things like employment decisions, credit scoring, and certain critical infrastructure and law enforcement applications, carries substantial obligations around risk management, data quality, documentation, human oversight, and accuracy. Limited risk uses mainly carry transparency duties, such as telling people they are interacting with a machine. Everything else is largely unregulated by the Act.
Two points catch organizations out. It applies based on whether the output is used in the European Union, not on where the company is, in the same way GDPR does. And obligations differ depending on whether you are the provider of a system or the deployer of someone else's, and most companies are deployers.
What They Have in Common
All three ask for the same first step, and it is the one most organizations skip: an inventory. You cannot govern AI use you cannot list.
All three ask for risk assessment proportional to use. A model that suggests email subject lines is not the same as a model that ranks job applicants, and treating them identically produces either paralysis or theater.
All three ask for human oversight, documentation, and monitoring over time, on the reasonable assumption that a model's behavior in production will drift from its behavior in testing.
Building an AI Inventory That Works
Record, for each system, what it is used for, who owns it, what data goes in, where that data goes, what the output influences, what happens if the output is wrong, and who signed off.
Include the ones that arrived without a decision: AI features in existing SaaS products, assistants inside developer tooling, and anything an integration connected. Those come from the discovery work in shadow AI.
The output influences field is the one that determines everything else. A system whose output a human reviews before it matters is a very different risk from one that acts directly, which connects to agent security.
A Review Process That Is Not Theater
Tier by consequence, not by technology. Ask what happens if this is wrong, and who is affected.
For low tier uses, a short registration and the acceptable use policy is enough. Making it heavier just pushes people back into shadow use.
For higher tier uses, do the real work: assess the data, test for the failure modes that matter for that use case, define the human oversight step concretely, decide what gets logged, and set a review date.
Security testing belongs in that review. Prompt injection, excessive permissions, and data exposure through retrieval are all covered in prompt injection and attacks on AI systems.
Where to Start if You Have Nothing
Write the one page acceptable use policy and name approved tools. Build the inventory. Tier what you find. Do a real review on the top few. Set a date to do it again.
That is a defensible program, and it takes weeks rather than quarters. The frameworks are there to make it more rigorous once the basics exist, not to be adopted wholesale on day one.
Learn This at HackRange
Week 5 of the mentorship covers the framework landscape and risk registers, and Week 7 applies the same thinking specifically to AI use.