AI System Governance: A 90-Day Plan for NIST and ISO

AI system governance means rules, roles and checks for every AI tool your business runs. It is not paperwork for later, and it is not only for big companies. A ten-person consulting or coaching business running AI on client work needs it too. Start with two moves today. List every AI system you use. Name one person who owns the list. Then build on two standards: NIST's AI RMF and ISO/IEC 42001.

What AI system governance has to cover

Think of an AI system like a car. You do not check it once at the factory. You check it when it is built, tested, driven, serviced and retired.

Governance works the same way. It follows the system from design to shut down.

These are the risks it has to catch:

• Bias. The system treats some people unfairly.
• Privacy gaps. Personal data leaks or gets misused.
• Security holes. Someone attacks or tricks the system.
• Misuse. Staff or customers use the tool in ways you never meant.
• Wrong answers. The system gets things wrong and nobody spots it.
• Supplier risk. A vendor's problem becomes your problem.

One point to get straight early. Governance is the set of rules and oversight. A technical control, like a filter that blocks rude outputs, is one tool inside it. You need both. They are not the same thing.

The AI governance framework to follow: NIST and ISO

You do not need to write your own rulebook. Two standards do most of the work.

The NIST AI Risk Management Framework sorts the work into four functions. Think of a kitchen.

Function	What it does	Kitchen version
GOVERN	Sets the rules and who owns them	The menu and the house rules
MAP	Works out the context and the risks	Knowing your ingredients
MEASURE	Tests and tracks the system	Tasting the dish
MANAGE	Acts on what you find	Dealing with it when something burns

NIST describes GOVERN as a function that runs through the other three. It is not a step you finish. A review that happens once a year will miss every model update your vendors ship in between.

ISO/IEC 42001 is a management system standard. If you already run quality or safety standards, the shape will feel familiar. It runs on a loop: Plan, Do, Check, Act. You plan the controls, do the work, check it, then act on what you learn.

For generative AI, NIST also publishes a generative AI profile. It turns the general framework into actions for tools that write text or make content.

The building blocks to put in place first

Get the basics in before anything clever. A shop needs staff, rules and a stock list before the doors open. So does this.

People and roles

1. A board member or senior leader who owns the risk appetite.
2. One named owner for AI risk. A title, not "the team".
3. The product and engineering people who build and run the systems.
4. Reviewers who check the work before launch.
5. Privacy and security leads who sign off on data handling.

The inventory

Give each system six fields: its name, what it is for, where its data comes from, what model it uses, its risk level, and which vendor supplies it.

Unlisted tools are the usual gap. Staff sign up to AI tools on their own and nobody records it. Njin's piece on shadow AI already inside your business explains why that matters.

The four policies

• Acceptable use. What staff can and cannot do with AI.
• Data movement. What data can leave the business and where it goes.
• Model change. What happens when a vendor updates the model.
• Escalation and exceptions. Who to call when a rule gets broken.

Acceptable use should also cover your brand. Staff need to know what AI may write in your name, and this guide to AI branding is a useful read on that side of it.

Our AI policy development guide walks through writing these in plain English. Keep each policy to one page. If staff cannot read it in two minutes, they will not follow it.

Data rules need their own depth. DevWiz covers that in its five-pillar model for AI data governance.

How to manage AI systems once they are live

Building the system is half the job. The other half is watching it.

Before launch, run these checks:

• Bias checks. Do outputs favour or harm any group?
• Performance checks. Does it do what you built it to do?
• Adversarial tests. Someone tries to break or trick it on purpose.
• TEVV records. TEVV means test, evaluation, verification and validation. NIST uses the term for the testing work across the lifecycle. Keep the records. You will need them in an audit.

Once it is running, watch for:

• Drift. Answers slowly get worse or stranger.
• Safety alerts. Anything dangerous or out of bounds.
• Logs. A trace of what happened and when.
• Human checkpoints. A person reviews outputs before they go out.

Things will still go wrong. Have a response playbook ready. Run a review after each incident. Keep your test records where you can find them. Our guide to AI agent governance goes deeper for teams running agents.

Why your cloud and AI vendors are a risk

Every AI tool you buy comes with strings. Some tie you down more than you would like.

Map every cloud provider and model vendor you rely on. For each one, write down:

• Any exclusivity clauses that stop you using other providers.
• Who owns the data you put in.
• What access rights they have to your information.

The FTC's staff report on cloud and AI partnerships looked at deals between cloud providers and AI developers. It found they can hand the cloud provider consultation rights, some control over decisions, and access to technical information. It also flagged higher switching costs for the business that relies on them.

Build three protections into every vendor contract:

• The right to export your data in a format you can use.
• Separate pipelines, so one vendor's failure does not take everything down.
• Audit rights, so you can check what they do with your data.

AI accountability standards: how to measure the work

Keep this simple. A few numbers checked often beat a thick report checked once a year.

Track these:

• Inventory coverage. How many AI systems are logged.
• Risk rating rate. How many have a risk level.
• Control coverage. How many high-risk systems have controls.
• Incidents. The count over time, so you can see the trend.
• Time to fix. How long an issue stays open once found.

Set the rhythm to match. A monthly review for the people running the systems. A quarterly update to the board. An outside check each year if your risk calls for one.

Keep the board report short: a risk heatmap, the fixes still open, any exceptions granted, and the key incidents.

A 90-day roadmap for governance in artificial intelligence

You do not need a year to get moving. Three phases will do it.

1. Weeks 0 to 2. Build the inventory. Run a quick risk check on each system. Name the owners. Book a briefing with the board.
2. Weeks 3 to 6. Write the four policies. Set up basic monitoring on your top systems. Start pre-launch testing on anything new.
3. Weeks 7 to 12. Build the incident playbook. Run a red-team exercise or bring in an outside reviewer. Prepare your first quarterly report.

Do not wait for perfect policies before you start monitoring. A rough dashboard today beats a polished one you never finish.

Ethics and bias in practice

Machine learning ethics is not a separate box to tick. It sits inside every decision above.

Bias gets in through training data, through who tests the system, and through who it gets used on. If your customers are diverse and your test group is not, your customers will find the problems for you.

Four steps help:

• Test outputs across different groups before launch. Overall accuracy hides a lot.
• Record what data trained the model, so you can trace a problem to its source.
• Give someone outside the build team the power to say no before launch.
• Give staff and customers a clear way to flag something that feels unfair.

Be honest about limits too. If a model was not trained on data that fits a group of your customers, say so. Send those cases to a person.

AI regulatory compliance: what it asks of you

AI rules are still forming, and they differ by country and sector. Do not chase every proposal. Build around the standards regulators already point to.

ISO/IEC 42001 matters here because you can be certified against it. Auditors check that what your teams do matches what your policies say. That evidence helps when a regulator or a large customer asks how you manage AI risk.

It is worth seeing how a regulator handles its own use of AI. The FTC's AI page publishes the agency's AI compliance plan and its inventory of AI use cases. The same two moves this article opens with: a list and a named owner.

Treat compliance as the floor. Build your inventory, roles and testing so they would satisfy a regulator before one asks. Finance and healthcare often demand stricter checks, so confirm what applies to your sector.

How to score AI risk

Generic risk checklists do not fit AI well. Score each system on how it can fail.

NIST's MAP function tells you to understand the context first. A chatbot that answers general questions carries a different risk to one that approves loan applications.

Score each system on four things:

• Impact. How much harm a mistake could cause.
• Reach. How many people it touches.
• Autonomy. How much it decides without a person checking.
• Data sensitivity. Whether it touches personal or confidential information.

Roll those into a tier: low, medium or high. High-risk systems get the full testing and monitoring above. Low-risk ones get lighter checks. A tool that summarises internal meeting notes does not need a red team.

Score again whenever the system changes. A vendor model update can shift your risk level without anyone noticing.

Who needs to hear what

Governance fails when only the tech team knows it exists.

• Leadership needs the big picture: risk levels, incidents and what is being done.
• Engineering and product need the detailed rules to build against.
• Legal and privacy need to see data flows and vendor contracts.
• Frontline staff need plain guidance on what they can and cannot do.
• Customers deserve honesty about where AI sits in the service they get.

Keep updates short and regular. A one-page monthly note beats a fifty-page annual report nobody reads. Our AI change management guide covers how to bring a team along.

Two failure modes to design against

Governance gets reviewed once a year, then forgotten. Fix it with a live dashboard and a calendar slot. A yearly memo will not do it.

Policies exist on paper and nobody checks them. Fix it with real tests and launch gates that block a bad release.

Small mixed teams help with both. People trust the rules more once they see them catch something real.

Where governance sits in an AI Operating System

Here is how we run it ourselves. We treat AI as an enthusiastic intern, not a magic button. So the work runs 10/80/10: 10% planning, 80% the AI doing, 10% a person making it right. The two 10%s are where the judgment lives. Nothing goes out without a human yes.

Security is part of the same system. Once you run AI across a team, your AI accounts become a target, the same as a bank login. We learnt that the hard way once. Now it is individual logins, two-factor on everything and hard spend caps.

That is the difference between a governance binder and an AI Operating System. In the system, the rules are built into how the AI employees work. Roles, approval gates and review cadence live in the same place as the workflows, so the policy and the practice cannot drift apart. We build these with Claude Code, and you can see the approach in custom AI delivery systems built with Claude Code.

Structure beats raw intelligence. A smarter model will not fix a system with no owner and no gate.

James Killick

Your next step

Start with the inventory and the owner. That is week one, and it costs nothing.

If you want to know where your business stands before you build, take the assessment. It takes a few minutes and tells you where to start.

Sources

• Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• ISO/IEC 42001
• Partnerships Between Cloud Service Providers and AI Developers (FTC 6(b) staff report)
• AI RMF generative AI profile (NIST)