How to make 'never' mean something: the enforcement problem in AI governance

I've been building AI governance systems for regulated environments where failure isn't just expensive.

It's existential.

The hardest part isn't writing the rules. That's the easy part. You sit down, map the regulatory requirements, identify the prohibited behaviors, document the constraints. CPS 234 says this. ISO 42001 requires that. The EU AI Act prohibits these specific practices.

Done.

The hard part is making those rules enforceable at runtime. Not aspirational. Not documented in a policy that lives in SharePoint. Enforceable in the actual system where the AI operates.

Because here's what I've learned: there's a token tax in using governance rules in the tools. Every constraint you add, every check you build in, every verification layer you stack—it costs compute. It costs latency. It costs money.

But the impact of not having to go back and redo things multiple times has been massive.

When you get the governance right upfront, tasks that have less sensitive information can be put on autopilot. Not theoretical autopilot. Actual autonomous operation where the AI handles the entire workflow without human intervention.

We're getting closer to that every day.

The enforcement gap that regulators are closing

2026 isn't theoretical anymore.

The EU AI Act reached general application. Colorado's AI regulations took effect. The FTC launched Operation AI Comply targeting deceptive AI marketing. Italy fined OpenAI €15 million for GDPR violations.

Regulators expect documented controls, technical safeguards, and evidence of compliance. Not aspirational ethics statements. Not policies that describe what you intend to do. Proof that the system actually does what you said it would.

The enforcement inflection has arrived.

And most organizations aren't ready because they've been treating governance as a documentation exercise instead of an engineering problem.

I've seen this pattern repeat: teams write comprehensive AI policies. They define prohibited practices. They establish review processes. They create approval workflows.

Then employees default to unsanctioned tools anyway.

Shadow AI spreads because legacy DLP lacks visibility into AI conversations, cannot assess the context or intent behind interactions, and forces binary block-or-allow decisions that don't map to how AI actually works.

The policy says "never use AI for X."

But there's no mechanism to detect X happening, no way to stop it in real time, and no consequences that matter when it does happen.

That's not governance. That's theater.

What 'never' actually requires

When you tell an AI system it must never do something, you're not writing a rule.

You're defining a boundary condition that has to hold across every possible execution path.

The EU AI Act has a category called "prohibited practices." These are AI applications that pose unacceptable risk: social scoring by governments, real-time biometric surveillance in public spaces, emotion recognition in workplaces.

Violations carry penalties up to €35 million or 7% of global annual turnover, whichever is higher.

Those prohibitions became enforceable February 2, 2025.

As of March 2026, no public enforcement actions for prohibited practices have been announced. Several investigations are reportedly underway, particularly around workplace emotion recognition and predictive policing.

Here's what that tells me: organizations are struggling with the same problem I've been solving in financial services.

How do you prove the system never did the thing it's not allowed to do?

Not just that you told it not to. Not just that you trained people on the policy. That the system itself cannot execute that behavior, even if someone tries to make it.

That requires enforcement mechanisms built into the architecture.

The constitutional stack I use for regulated AI

I've built a governance model that treats rules as constitutional constraints, not policy documents.

It's a sequential stack: CHARTER → NOMARK → CLAUDE → SOLUTION → PRD → PROGRESS.

The CHARTER layer defines what the system must never do. These aren't guidelines. They're invariants. Hard boundaries that cannot be crossed regardless of context, user intent, or optimization pressure.

The enforcement happens through three mechanisms:

1. Constitutional reasoning at the model level.

The AI evaluates every proposed action against the charter before execution. If the action violates a constitutional rule, it doesn't happen. Not delayed for review. Blocked at inference.

2. Tamper-evident audit trails.

Every decision, every input, every output gets logged with hash-chaining and WORM (write once, read many) evidence structures. You can't retroactively alter the record. You can't claim the system didn't do what the logs show it did.

3. Independence properties in the governance layer.

The enforcement mechanism operates separately from the operational AI. It's not part of the model being governed. It's a distinct architectural plane that monitors, evaluates, and controls what the operational system can do.

This isn't theory. I've implemented this in investment operations platforms where regulatory compliance isn't optional and audit trails need to survive hostile scrutiny.

The token tax is real. These checks add latency. They consume compute. They increase cost per interaction.

But the alternative is worse.

What breaks when enforcement is missing

AI delivers 15-20% net cost reductions across banking operations and automates 54% of customer interactions.

But GenAI-enabled fraud is projected to reach $40 billion by 2027. The global average cost of a data breach in 2024 hit $4.88 million, a 10% increase from the previous year and the highest ever.

Those numbers represent what happens when deployment speed outpaces governance frameworks.

I've seen the pattern in project recoveries: organizations race to implement AI for competitive advantage, skip the enforcement architecture because it slows initial deployment, then face catastrophic failures when the system does exactly what it was never supposed to do.

A minor malfunction in an autonomous system triggers widespread scrutiny. Small failures become systemic headlines.

The complexity of AI systems doesn't dilute human responsibility. It expands the need for precision and foresight.

When something goes wrong, "we didn't think it would do that" isn't a defense. "We couldn't have known" doesn't hold when the failure was in the enforcement design, not in the model behavior.

The accountability gap isn't in the AI.

It's in the governance architecture that was supposed to prevent the failure in the first place.

Why legacy governance processes can't scale

Most governance frameworks in use today were designed for software systems that have deterministic behavior.

You write code. You test it. You verify it does what you specified. You deploy it. It keeps doing that thing until you change the code.

AI doesn't work that way.

The same model produces different outputs based on context, phrasing, temperature settings, and stochastic variation in the sampling process. You can't test every possible execution path because the space of possible behaviors is functionally infinite.

Legacy governance processes suffer from performance, cost, complexity, agility, and scaling issues when applied to AI models.

Gartner predicts that over 40% of agentic AI projects will be canceled by 2027.

Not because the models are bad. Not because organizations lack compute. Because the risk controls are inadequate, costs escalate without clear ROI, and governance structures were never designed for autonomous agents.

You can't govern an AI system the way you govern a database.

The enforcement model has to operate at the level where the AI makes decisions, not at the perimeter where you review outputs after the fact.

What convergence looks like in practice

Despite apparent regulatory fragmentation across jurisdictions, I'm seeing convergence around core principles:

Risk-based classification. High-risk systems get stricter requirements. Prohibited practices are banned outright. Minimal-risk applications have lighter obligations.

Transparency obligations. Organizations must document what the AI does, how it was trained, what data it uses, and how decisions get made.

Human oversight requirements. Meaningful human review at critical decision points, not rubber-stamping automated outputs.

Accountability mechanisms. Clear assignment of responsibility when things go wrong, with enforcement that targets the organization, not just the technology.

The differences are in implementation stringency, enforcement architecture, and whether governments prioritize regulation over innovation promotion.

But the direction is consistent: AI governance in 2026 is moving from high-level principles to enforceable rules.

Regulators expect documented AI inventories, risk classifications, third-party due diligence, and model lifecycle controls. Measured by clear KRIs or KPIs. Not just policies on paper.

The organizations that survive this transition are the ones building enforcement into the architecture now.

The difference between rules and enforcement

An AI policy defines the rules.

Enforcement is the operational machinery that turns those rules into technical controls at runtime.

Most organizations have policies. Very few have enforcement.

I've built enforcement mechanisms for systems where failure means regulatory sanction, client loss, or systemic risk to financial stability. The approach is consistent:

Define the constitutional layer first. What must the system never do? What boundaries cannot be crossed? What invariants have to hold regardless of optimization pressure or user intent?

Implement those constraints as architectural properties. Not as training objectives that can drift. Not as prompt engineering that can be bypassed. As hard boundaries in the system design that cannot be violated without breaking the system itself.

Build tamper-evident audit trails. Every decision gets logged with cryptographic integrity. You can prove what happened, when it happened, and why the system made that choice.

Separate the governance layer from the operational layer. The enforcement mechanism can't be part of what it's enforcing. Independence is a structural requirement.

Measure what matters. Not activity metrics. Not process compliance. Outcome verification. Did the system stay within bounds? Did the controls work? Can you prove it?

The token tax is worth paying.

Because the cost of rework, the risk of regulatory enforcement, and the reputational damage from failure dwarf the incremental compute cost of doing governance right.

What I've learned from building this

The ability for tasks with less sensitive information to run autonomously is accelerating.

But autonomy without enforcement is just automated risk.

The organizations that figure out how to make "never" mean something will be the ones that can actually deploy AI at scale in regulated environments. The ones that treat governance as documentation theater will hit the enforcement wall when regulators start asking for proof.

Writing the rule is easy.

Making it enforceable is a different problem entirely.

And that's the problem worth solving.