AI Governance Framework: Five Artifacts That Make It Real

---

The Problem

01

Why naming a framework changes nothing

Ask a team about their AI governance framework and you usually get a standard, a committee and a policy document. Ask who approved the model version currently running, and the room goes quiet.

That gap is the whole problem. A policy describes intent, and an audit asks for evidence, and those two things live in different places unless somebody deliberately connects them.

The connection is boring and specific. It is a list of systems, a record per version, and a name against each one.

---

Reference Points

02

Three reference points, three different jobs

Teams waste weeks choosing between these as if they competed. They do not.

The NIST AI Risk Management Framework is voluntary and organised around four functions: govern, map, measure and manage. It is the most useful of the three when you are starting, because it tells you how to reason about a system rather than what paperwork to file.

ISO/IEC 42001 is a management system standard. It describes the machinery around the work: an approved policy, defined roles, a risk register, impact assessments, internal audit and training records. You can be certified against it, which is why buyers increasingly ask for it.

The European Union AI Act is binding law for anyone placing AI systems on that market, and it classifies systems by risk rather than by technology. For most organisations the sequence is to use NIST to reason, ISO to organise, and the Act to set the obligations that are not optional.

---

What Makes It Real

03

Five artifacts that turn policy into evidence

These are what an auditor, a customer or your own incident review actually asks for. Everything else in a governance programme exists to produce them.

The inventory is missing most often. It is also the one everything else depends on, because you cannot govern systems nobody has listed, and in most organisations several arrived through a product feature rather than through a project.

The decision log is the one people underestimate. Recording what the model saw, what it suggested, and what a person did with it is the difference between explaining an outcome and guessing at it a year later.

---

Action

04

How to start without a programme

You do not need a committee to begin. You need a spreadsheet and two weeks.

1. List every system, including bought ones. Anything that makes or suggests a decision, whether you built it or it arrived inside a product you licence. This list is usually longer than expected.
2. Classify by consequence, not by technology. What happens if it is wrong, and who is affected. This is the same question the AI Act asks, and it sorts your effort faster than any capability label.
3. Put a name against each one. Not a committee. One person who owns whether it still works, including retraining, as covered in the AI readiness assessment.
4. Record versions and decisions for the top of the list. Start with the systems where being wrong costs the most, and accept lighter records elsewhere.
5. Write the incident route. Who is told, how fast, and what gets switched off. Both standards expect this and most teams discover it missing during the incident.

Governance effort should track consequence. A model that drafts internal text does not need the machinery that a model touching safety or money does, and treating them alike is how programmes stall.

---

Dev Station

05

Building the evidence in rather than around

Most of this is an engineering problem disguised as a policy problem. A decision log that somebody maintains by hand will be wrong within a month, while one the system writes as it runs stays correct for free.

Dev Station builds AI features into inspection and field data systems where the record is the deliverable, so version, inputs, suggestion and the human decision are written as the work happens. The pattern behind that is set out in AI agents in production, and the process selection side in AI business process automation.

Much of our work is for operators in the United States and the United Kingdom, so SOC 2 on one side and GDPR with ISO 27001 on the other are in the specification rather than in a later remediation. Our engineers work from Vietnam with overlap into US Eastern, US Pacific and UK GMT hours, and we invoice in USD or GBP.

Send us the system you need to evidence and we will tell you what the record has to capture. The build side sits in AI and ML development.

---

FAQ

06

Frequently asked questions

What is an AI governance framework?

A structured way of deciding which AI systems you run, who is accountable for each, how risk is assessed, and what evidence you keep. In practice it is the combination of a method such as the NIST AI Risk Management Framework and a management system such as ISO/IEC 42001.

Should we choose ISO 42001 or NIST AI RMF?

They answer different questions, so most organisations use both. NIST gives you a way to reason about risk and costs nothing to adopt, while ISO/IEC 42001 gives you something a customer or auditor can certify against.

Do we need this if we only use bought AI tools?

Yes, and that case is often the harder one. You still decide where those tools are used and what happens when they are wrong, and the inventory step exists precisely because this kind of AI arrives without a project behind it.

Where do most governance programmes fail?

At the inventory and the decision log. Teams write the policy first, discover later that nobody knows the full list of systems, and find that explaining a past outcome is impossible because nothing recorded what the model saw.