AI Governance

Has your AI ever told you no?

MR By Monét Reid · August 17, 2026 · 8 min read

In the middle of a task I had already approved, my assistant interrupted itself.

"Stop, I need to correct myself before you go looking any further. I'm sorry I hallucinated. In my last message I said..."

Unprompted, mid-task

I was not auditing it. I was not asking it to double-check anything. I was moving, and it stopped me.

My first reaction was that the model had done something impressive. My second reaction, about ninety seconds later, was worse and more useful.

It had not done anything impressive. It had done exactly what I told it to do.

I wrote that sentence

I went looking for why it behaved that way, and I found the answer in two files I wrote myself and had mostly forgotten about. Both of them load before the model reads anything I type.

Read the first rule against what the model actually said. The correction is close to verbatim.

It did not develop a conscience. It executed an instruction. I wrote the sentence, and the machine said it back to me at the exact moment it was needed, without me asking, while I was busy looking somewhere else.

That is not a story about how good AI has gotten. It is a story about infrastructure.

What most people mean by AI governance

Ask ten people what AI governance means and you will get some version of the same answer. Rules about what you are allowed to paste into the tool. A policy about what you may publish. A note about client data. Maybe a training module, if the organization is large enough to have one.

All of that is real work and it matters. I am not dismissing it.

But look at what it governs. Every one of those rules governs the human sitting at the keyboard. It tells the person what to do.

No acceptable use policy in the world would have caught what happened to me, because the failure was not in my behavior. I did nothing wrong. I asked a reasonable question, got a confident answer, and was about to act on it. The policy layer had nothing to say about that, because the policy layer was never pointed at the model.

The three layers

Here is how I think about it now, and this is the part I would hand to anyone setting up their own environment.

What layer three actually looks like

It is less work than it sounds. A short list of rules, written in plain language, in the files the model reads before it reads you.

When you are uncertain, say so. Name the confidence level. Do not fill the gap with something that sounds right. An answer labeled "I am not sure, but" is worth more than a confident wrong one, because I can act differently on it.

Label every claim by where it came from. There is a difference between something you measured, something you read, and something you inferred. Say which one it is, every time, without being asked. Fabrication is what happens when the third one gets delivered in the voice of the first.

When you have fabricated, stop and say it plainly. No hedging, no burying it in a paragraph of qualifications, no quiet correction three turns later. Stop the task.

Gate anything irreversible. Before a command that deletes, resets, overwrites, revokes or publishes: run a read-only inventory first, show what will be destroyed, and state the recovery path in one sentence.

Write checkpoints, not dispositions

This is the distinction that took me longest to learn, and it is the one that decides whether a rule survives contact with a real working session.

A checkpoint fires at a nameable moment and leaves evidence you can inspect. Label this claim. Run the inventory before the destructive command. Show the output. You can look at the transcript afterward and see whether it happened.

A disposition asks for sustained vigilance across an entire session. Be careful. Be rigorous. Do not use that punctuation. Dispositions feel like the same kind of rule. They are not. They decay as the session gets longer.

I know this because I tested it on myself. One of my own style rules is a disposition, and in a four-hour session it was violated in nearly every message, while the technical work inside those same messages stayed measured and correct. The rules that fired at a specific moment held. The rule that asked for continuous attention did not.

This is not hypothetical. Here is the catalogue.

Every rule in my conduct layer exists because something went wrong first. I keep the failures written down next to the rules, with dates, because a rule with no incident attached is a preference.

None of those three was caught by a policy about what I am allowed to paste. Every one of them was a model behaving confidently at the exact moment it should have stopped.

Why this has to exist before you take off

The instinct is to build governance later, once the thing is working. Get moving first, add the guardrails when there is something worth guarding.

Run the cost of that decision forward.

Catching a fabrication in the chat window costs one turn. I lost ninety seconds.

Catching it after it has shipped in a client deliverable costs the client relationship, and it costs it in a specific way that is hard to recover from, because the client now has to wonder what else you did not check.

Catching it after it has been wired into something automated costs everything downstream of that automation, silently, for as long as nobody looks.

That correction was not a lucky break. It was the return on a file I wrote before I needed it. Governance is not a brake on speed. It is the thing that makes speed survivable, which is the only reason anyone would build it in the first place.

You do not install brakes at altitude.

What this does not prove

I want to be precise, because the overclaim here is easy and it would be dishonest.

This proves one model executed one written rule one time. It does not prove that models reliably police themselves, and I would not build a business on the assumption that they do. The line I keep in my own instruction file is blunter than anything I would put in a headline.

"Self-review does not catch fabrication. Re-reasoning over a wrong claim re-confirms it. Only an external oracle catches it."

From my own instruction file

That is the whole caveat. You are running the error back through the machine that made it. Writing conduct rules changes the probability that something surfaces early. It does not remove the need for a check that comes from outside the model: a command that actually runs, a document you can actually open, a number you can actually verify.

Layer three is not a replacement for verification. It is what makes verification affordable, by surfacing the cheap failures early enough that you only have to verify the expensive ones.

The test

The question at the top of this page is the first of three. They take about thirty seconds together.

If the answer is no to all three, there are two possible explanations. Either it has never been wrong, or nothing in its environment has ever told it to say so.

It has been wrong.

A model that always agrees with you is not aligned with you. It is unsupervised.

And the gap between those two things is invisible right up until the moment it is expensive.

I build the third layer with people, in their own environment, on their own files. If you ran the test and did not like your answers, that is usually where we start.