- Governance without an inventory is theatre. Every other artefact you produce refers to a list of systems, and if that list is wrong the rest is decoration.
- The two named frameworks answer different questions. NIST AI RMF is voluntary guidance organised around four functions. ISO/IEC 42001 is a certifiable management system standard.
- You cannot be certified against NIST AI RMF and you do not get a methodology from ISO 42001. Picking one because a customer asked is normal and picking both is common.
- Tier your systems against the EU AI Act categories even if you are outside the EU, because it is the only classification a customer or an auditor is likely to ask about, so you classify once.
- The hard part is not writing the policy. It is finding the tools already in use that nobody told you about, and that job never finishes.
You have been made accountable for AI use across the company. You have no budget, no team, and a vague expectation that something will exist by the end of the quarter. Here is the claim this article rests on: if you produce a policy before you produce an inventory, you have produced nothing.
A policy describes what may be done with systems. An inventory says which systems exist, and it is the unnamed prerequisite behind almost every line of the EU AI Act obligation map too. Written in that order, the policy governs an imagined company and the real one carries on unobserved. Written the other way round, the policy is short, specific and about things that are actually running.
What is the difference between NIST AI RMF and ISO 42001?
They are not competing options. They answer different questions, and confusing them wastes the first month of most programmes.
The NIST AI Risk Management Framework was released on 26 January 2023 and is explicitly intended for voluntary use, developed through an open consensus process across the public and private sectors. It is organised around four functions: govern, map, measure and manage. It tells you how to think about AI risk and gives you a vocabulary for doing so. There is no certificate.
ISO/IEC 42001, published in December 2023, is a management system standard. BSI, which describes itself as the first certification body accredited by UKAS to certify against it, puts its purpose as helping an organisation establish, implement, maintain and continually improve an AI management system. It is built on the same harmonised structure as ISO 27001 and ISO 9001, meaning a plan, do, check and act cycle with defined scope, leadership commitment, operational controls and performance evaluation. Its Annex A carries a reference set of 38 controls grouped under nine objectives. It is certifiable by third party audit.
| Question | NIST AI RMF | ISO/IEC 42001 |
|---|---|---|
| Can you be certified? | No. There is no certificate to hold up. | Yes, by an accredited third party auditor. |
| Audit burden | Self assessment. As heavy or as light as you make it. | Formal, recurring, with evidence requirements and surveillance audits. |
| What it demands you produce | Risk documentation organised by govern, map, measure and manage | A scope statement, a policy, an impact assessment process, control evidence against Annex A, records of review |
| Who typically asks for it | US federal buyers, security teams, internal risk functions | Enterprise procurement, insurers, partners who already ask for ISO 27001 |
| What it does NOT cover | Legal compliance. It is not a route to meeting any statute, including the EU AI Act. | Whether your specific AI decisions are any good. It audits the system, not the judgement. |
That last row is the one nobody writes and it is the one that decides expectations. Neither framework tells you whether a given model should be used for a given purpose. NIST gives you a structure for asking. ISO gives you evidence that you asked consistently. A regulator asking whether your hiring tool discriminates will not be satisfied by either.
Why start with an inventory rather than a policy?
Because every subsequent artefact refers to it, and because it is the only one you cannot fake.
A risk tier applies to a system. A control applies to a system. An approval route governs systems entering the estate. If the list of systems is incomplete, the tiering is incomplete, the controls protect the wrong things, and the approval route is a gate beside an open field.
The uncomfortable part is that shadow AI use is already in the building. Not as a hypothetical: as a browser extension somebody installed, a personal account used for a work document, a plugin connected to the shared drive, and a vendor whose product added an AI feature without asking anyone. None of that arrives through procurement, and none of it appears on an asset register.
Three methods find most of it, and you need more than one. Ask people directly, with an amnesty and a genuinely short form, because the alternative is that they hide it. Pull the list of applications with access to your identity provider and your document storage, which surfaces every connected tool regardless of who authorised it. And read your expense reports for the last six months, because individual subscriptions show up as small recurring charges long before anyone declares them.
How should you tier risk without inventing a scheme?
Use the EU AI Act categories, whether or not you are subject to it. The reasoning is practical rather than legal: it is the classification your customers, your insurers and your auditors are most likely to reference, so adopting it means classifying once instead of maintaining a private scheme and a translation table.
The European Commission's regulatory framework for AI sets out four levels. Unacceptable risk covers nine banned practices including social scoring, untargeted biometric scraping, and emotion recognition in workplaces and education. High risk covers systems that threaten health, safety or fundamental rights, and the list includes education and employment tools, access to essential services, biometric identification and critical infrastructure components. Limited risk means transparency obligations, principally that people are told they are dealing with a machine and that synthetic content is identifiable. Minimal risk covers the large majority of systems, including spam filters, with no specific requirements.
The obligations attaching to high risk are the ones to read even if you believe nothing you run qualifies, because they double as a decent control set: risk assessment and mitigation, data quality sufficient to limit discriminatory outcomes, activity logging for traceability, technical documentation, instructions for deployers, human oversight, and robustness with cybersecurity and accuracy standards.
The timeline matters for sequencing. Prohibited practices and AI literacy obligations applied from 2 February 2025. Governance and general purpose model obligations from 2 August 2025. Transparency rules in August 2026. High risk systems in sensitive areas from 2 December 2027, and high risk systems embedded in regulated products from 2 August 2028. We laid the full decision tree out in the EU AI Act read as tiers and dates, and the practical point for a governance programme is that the transparency obligations are the nearest ones and the cheapest to satisfy.
Tiering is a property of the use, not of the tool. The same general purpose assistant is minimal risk when drafting a marketing email and potentially high risk when screening job applications. Tier the entries in your inventory by what they are used for, or the exercise produces one row that says nothing.
The first 90 days, and what each step leaves behind
Judge each phase by its artefact. A phase that produced a meeting produced nothing.
Days 1 to 20: the inventory
Artefact: a spreadsheet. One row per use, with the tool, the owner by name, the business process, the data categories touched, whether the data leaves the organisation, and whether there is a contract. Not a policy, not a framework mapping, a list. Expect it to be wrong and plan to revise it. An inventory that finds nothing you did not already know has not been done properly.
Days 21 to 40: risk tiering
Artefact: the same spreadsheet with a tier column. Apply the EU categories to each row. Most entries will be minimal, a few will be limited risk with a disclosure obligation attached, and one or two will make you uncomfortable. Those are the programme. Everything else is administration.
Days 41 to 60: the written policy
Artefact: one page. What is permitted without asking, what is banned outright, what requires approval, and where to go for the last of those. The single most common failure in this step is length. A policy people do not finish reading is a policy that governs nobody, and every additional page reduces the share who reach the end. Ours is published rather than internal, which is a discipline in itself: our own AI policy is short because it has to survive being read by someone who did not want to read it.
Days 61 to 75: the approval route
Artefact: a named person, a form and a service level. The service level is the part that determines whether the route is used. If approval takes three weeks, people will route around it and your inventory starts decaying the day it is finished. Two working days, decided by one person, with a documented reason, beats a committee that meets monthly.
Days 76 to 90: logging and review cadence
Artefact: a decision log and a diary entry. The log records what was approved, by whom, on what basis. The diary entry is the date you re run the inventory, which should be quarterly. This is what an auditor actually looks for, and it is what most programmes skip because it produces nothing visible in the first quarter.
What belongs in an inventory row?
Eight fields, and the discipline is refusing to add a ninth in the first pass. An inventory that asks for too much never gets filled in, and an empty comprehensive template is worth less than a complete crude one.
| Field | What good looks like | Why an auditor cares |
|---|---|---|
| Use, not tool | Drafting support replies, not the vendor name | Risk attaches to the use. One tool can generate several rows. |
| Named owner | A person, not a department | A department cannot answer a question. Unowned rows are how estates decay. |
| Data categories touched | Customer names, payment data, employee records, none | It determines which other obligations you already have and are now extending. |
| Does data leave | Yes to a named vendor, or no | This single field decides whether contracts and transfer questions apply. |
| Human review step | Who reads the output before it has an effect, or nobody | The presence or absence of a human is the first thing anybody asks about. |
| Contract status | Enterprise agreement, personal subscription, free tier | A free tier usually means no data processing terms at all. |
| Date added and last reviewed | Two dates | Without the second date, the whole document has an unknown age. |
| Risk tier | One of the four EU categories | It is the shared vocabulary between you and everyone who asks. |
The field that produces the most argument is the first one. People want to list tools, because tools are countable and visible. Listing uses feels like duplication, since the same assistant appears five times. That duplication is the point: it is the only structure in which the tiering, the review step and the data fields can all be true at once. A single row covering a tool used in five different ways has to be wrong about at least four of them.
The field that produces the most useful surprise is contract status. A meaningful share of what you find will be on free tiers or personal subscriptions, which typically means no data processing agreement, no committed retention behaviour and no route to a support conversation if something goes wrong. That finding, on its own, usually justifies the whole exercise to a board.
Who should own this in a company with no team?
One person, part time, with the authority to say no and a route to somebody who can overrule them. The pattern that fails is a committee, because a committee cannot meet at the speed of a procurement decision and its members each assume another member is watching the inventory.
Where that person should sit depends on what the company already has. If there is a security function, put it there, because the discovery methods overlap almost entirely with what a security team already does and the incident path is one they already run. If there is a legal or compliance function and no security function, put it there and give them a technical partner for the inventory work, since reading an identity provider's application list is not a legal skill. If there is neither, it lands with an operations lead, and the important thing is that it lands somewhere named rather than being distributed across everyone.
Two authorities make the difference between a role and a title. The first is the ability to block a new tool pending review, which is what makes the approval route real. The second is a standing slot to report to whoever is accountable, quarterly, whether or not there is news. A governance owner who only appears when something has gone wrong becomes associated with bad news and stops being consulted early, which is the exact opposite of the intended effect.
What documentation is worth producing beyond the policy?
One thing, and it predates both frameworks. The 2018 paper Model Cards for Model Reporting, by Mitchell, Gebru and colleagues and presented at FAT* in 2019, proposed a short standard document accompanying a released model: its intended use cases, the context it was built for, how it was evaluated, and performance broken out across groups rather than reported only in aggregate.
For a company that buys rather than builds models, the useful adaptation is a one page record per high or limited risk entry in the inventory: what this system decides, what it was evaluated on, who is accountable, what the human review step is, and what it must never be used for. That last field is the one that saves you, because scope creep is how a marketing tool ends up screening candidates and nobody remembers approving it.
What breaks a governance programme in year one?
Four things, in roughly this order of frequency.
The inventory goes stale. It was accurate in March and nobody re ran it. By September it describes a company that no longer exists, and every artefact built on it is invalid. This is why the review date matters more than the initial exercise.
The approval route is slower than the workaround. Every governance process competes with the option of not using it, and it loses on speed unless you deliberately design for speed.
Incidents have no route. Something goes wrong, the person who notices does not know who to tell, and the first formal record is a customer complaint. This is a genuinely unsolved area rather than an oversight: we looked at how thin the established practice is in why AI incident reporting has no playbook for autonomous agents, and the honest answer for most companies is to reuse the security incident process rather than invent a parallel one.
Governance stops at the model and ignores the tooling. The controls cover which models are allowed while the actual exposure sits in what the agents and integrations around them can reach. An assistant with a narrow model and a broad credential is a wider risk than the reverse, which is the pattern behind how prompt injection turns a helpful agent into an exfiltration path.
Do you need a framework at all if nobody has asked?
You need the inventory. Whether you need a framework depends entirely on who is asking and why, and it is worth being blunt about that rather than adopting one for its own sake.
If a customer's procurement questionnaire asked, they usually want ISO 42001 or a credible plan toward it, because a certificate is the only thing that transfers. If your own board or a regulator is asking, NIST AI RMF gives you a defensible structure without an audit bill. If nobody has asked and you are acting ahead of the requirement, do the inventory and the one page policy and stop there. Those two artefacts are the input to any framework you later adopt, and neither is wasted.
What is wasted is a control matrix mapped against a standard you have no intention of certifying against, built before anyone knew which systems were in scope. It is the most common first artefact in this field and it is the one that convinces an organisation that governance is paperwork.
The sentence to keep
Governance is the ability to answer three questions on a bad day. What AI is running here. Who decided it could. What happens when it is wrong.
The inventory answers the first. The approval route and its log answer the second. The incident path answers the third. Everything else, including both frameworks and every control matrix, exists to make those three answers reliable rather than remembered. If you get to day 90 with honest answers to all three and nothing else, you are ahead of most companies with a certificate.