Your AI policy exists. I know it exists because you wrote it, formatted it, distributed it to the team, and somebody nodded in the all-hands. It says things like “do not input confidential client data” and “always review AI output before sharing” and “use approved tools only.” It may have bullet points. There’s a good chance someone signed it.
The document looks rigorous. It probably took real effort to produce. It creates accountability artifacts: version numbers, signature lines, timestamps in the SharePoint audit log. Everything a governance document is supposed to have, it has.
None of that is governance.
Governance is what holds the line when the policy document isn’t in front of you. When you’re three hours into a deadline and copy-pasting context to speed things up. When the new hire hasn’t finished onboarding but has full tool access. When everybody knows the rule and a Tuesday happens anyway. A policy is a reminder. Reminders have a well-documented failure mode: they work right up until the moment you need them most, which is usually the moment you’ve forgotten they exist.
The Distinction That Predates Your Policy
Information security classifies controls by enforcement mechanism. A discretionary control requires a person to apply it. A mandatory control is enforced by the architecture regardless of what the person does or fails to do.
This is not a new idea. Security practitioners have been applying this distinction to access control systems, data classification regimes, and authorization frameworks across every domain where bad decisions under pressure carry material consequences, and they have been doing it since before most current enterprise AI policies were written. The distinction predates large language models by a generation. What’s new is that most organizations adopting AI are running entirely on discretionary controls and calling it governance.
The policy that says “don’t feed the model sensitive data” is discretionary. A person has to remember to apply it, classify the data correctly, and act on that classification before they paste. Every single time. The control fails the moment the person forgets, misjudges, or just doesn’t feel like it on a given day. That’s not a hypothetical; it’s a description of how human memory performs under cognitive load.
The architecture that gives the model no route to sensitive data is mandatory. It holds regardless of what the person does, regardless of what kind of day they’re having, regardless of whether they remember the training session. There is nothing to remember. There is no Tuesday on which it fails. The person racing to hit a 5pm deadline, who hasn’t slept well, who genuinely forgot the policy exists, runs into the same wall as the person who remembers every word of it. The architecture doesn’t have moods, doesn’t get tired, and doesn’t care.
One of these is a governance control. The other is optimism with formatting.
How Discretionary Controls Age
The six-months-in version of your AI policy looks like this: the document exists. The training session happened. Everyone nodded. And then, six months later, someone copy-pasted a client list into the chat because it was faster, because the policy lives in a shared drive folder and the model lives on their screen, and friction flows toward the model. Nobody noticed until later, or they did notice and said nothing. Either way, the control failed exactly as discretionary controls fail: at the moment of friction, in the direction of convenience.
What happens next is the part worth watching. The policy gets reviewed. A reminder email goes out. Maybe another training gets scheduled. The incident gets documented and filed under lessons learned. And then, somewhere between six and eighteen months after that, it happens again, not because the people are bad or nobody cared, but because the control was still discretionary, and discretionary controls have a ceiling they cannot exceed regardless of how many times you remind people it exists.
Not a people problem. This is the failure mode of the control class.
Security practitioners who have sat the CISSP exam know this cold. Discretionary controls degrade under load. They provide real protection against good-faith mistakes made by well-rested people with nothing else competing for their attention, which describes a narrower slice of your actual working conditions than you would probably like to admit. Most enterprise AI governance frameworks, apparently, are still arriving at this conclusion.
Eighteen Months of Production Data
I have been running an AI writing system in production for 18 months. The system manages a novel series I’m writing: a complex multi-book project with 90-plus characters, dozens of locations, and continuity spanning hundreds of chapters.
I built a canon database, a synthesis tracking layer, and a constraint system that governs what the AI is and is not allowed to do at each step of the workflow. I want to describe what architectural governance looks like in practice, because I watched this architecture hold in exactly the situations where a discretionary regime would have silently let something through.
The canon database is read-only. The AI has no write access to the source-of-truth data. It cannot modify a character’s established history, override a location detail, or contradict what happened in a prior chapter. The architecture enforces this not because a reminder sits in front of the model asking it to comply, but because the read-only surface admits no write operations from the AI layer at all. The violation is physically impossible rather than merely prohibited, and no amount of deadline pressure changes that. This is not a rule sitting in a prompt, not a mental note I make at the start of each session, not a checkbox I might skip in a week when I’m three chapters deep in something that isn’t working and running on four hours of sleep, but the physical shape of the surface itself, and surfaces do not forget.
The constraint system captures what has gone wrong before. Before the AI drafts anything, it runs against a database that encodes prior failures: a character voice that drifted, a formatting pattern that crept in, a continuity detail that conflicted with established canon. These fire before the model sees the task, not because I remember to run them, but because the pipeline has no path that bypasses them.
The practical difference between “I should probably check my notes before I start” and “the constraints execute automatically before the model sees the task” is the difference between a discretionary and a mandatory control. It’s also the difference between a system that holds eighteen months in and one that was working fine until the week I was sick.
The workflow enforces a separation between generation and decision. The AI generates. A human reviews. The AI cannot advance its own output through the pipeline, and the pipeline has no bypass route that produces a valid output. This isn’t a rule posted above the workstation. It’s the shape of the system itself.
That’s what I mean by architectural governance. Not a policy that describes what should happen. A system where what shouldn’t happen cannot happen.
Policy Is the Floor
I’m not arguing that policy documents are worthless. Documented standards beat undocumented ones. Training beats no training. The awareness both create provides genuine protection against casual mistakes and honest misunderstandings, and I don’t discard cheap wins.
What I’m arguing is that policy is the floor, not the ceiling. If your AI governance consists entirely of documented standards and training sessions, you have built the floor and left out the rest of the structure. The floor is real. It’s not nothing. But the gap between what your policy prohibits and what your architecture prevents is exactly where the six-months-in incident lives.
The failure mode isn’t that people ignore policy. Most people don’t ignore it most of the time. The failure mode is that discretionary controls have an operating limit, and real conditions exceed that limit constantly: deadline pressure, cognitive overload, ambiguous data classification, the path of least resistance, the new person who didn’t quite catch the nuance in the training. Any one of these is enough. You don’t need malice. You need a busy Thursday.
Mandatory controls don’t have that failure mode. Not because they’re infallible, but because their failure modes are different: they require correct implementation, correct maintenance, and someone who understood the threat model when they built them. Those are engineering problems. They are not problems that recur on the same schedule as human memory.
The architectural question worth asking is: what would it take to make the wrong action impossible, rather than just prohibited? That question is not being asked in most AI governance conversations. It should be the first one on the agenda.
Build It or Buy It
Someone dismisses this immediately. “We’re not a software company. We can’t build access boundaries and constraint layers.” Fair. But consider what a mandatory control actually looks like at the most practical level.
A Python function wired into your MCP layer that scans every input for classification markers before forwarding anything to the model. If the input contains a CUI header, a FOUO marker, a Social Security number pattern, or a credit card number, the function rejects it and returns an error. The model cannot store the data. Not because the policy says not to paste it, but because the architecture makes pasting it and having the workflow proceed physically impossible. That’s the control. The person hits a wall instead of a reminder.
That’s not a software project. That’s fifty lines of Python deployed as a single MCP tool, and it converts a discretionary control into a mandatory one. The policy said “don’t paste classified data.” The validator enforces it regardless of whether anyone remembers.
It won’t catch data that’s been stripped of its markers, and it won’t stop a determined insider. What it stops is the accident: the copy-paste that happened because nobody remembered the reminder existed.
Beyond that single example: local AI infrastructure that never routes data to external servers; MCP servers scoped to specific, bounded sources that the model can reach and nothing else; read-only database connections; approval gates between generation and delivery. None of these require being a software company. They require choosing tools with their governance properties in mind, rather than choosing whatever was easiest to sign up for and writing a policy to cover the difference.
Most organizations do the latter. The policy covers the gap on paper. The architecture doesn’t cover it at all.
Build it or buy it, but first recognize that discretionary controls have an expiration date.
Your policy will hold until it doesn’t. That’s not a warning about bad actors. It’s a description of how discretionary controls age.
AI cannot corrupt what it cannot touch. Build accordingly.
You may also like: - Safety First Is Not Security First - When the AI Service Dog Loses the Plot - The Architecture Underneath the Writing Room