Your AI Policy Can’t Enforce Itself

Governance has spent years describing what systems and people should be allowed to do. AI is forcing a harder question: where does the rule become something the system can enforce?

TL;DR: Most governance programs are built around decisions. Which data is authoritative? Who should have access? Which technologies are approved? What requires review? When the answers to these questions live primarily in policies, committees, tickets, and documentation, people and systems still have to remember to follow them.

AI makes that old weakness a lot harder to ignore. Automated systems can query data, invoke tools, write code, and take actions at a speed manual oversight simply can't match. The practical shift is from governance as documentation to governance as system behavior: definitions encoded in the data layer, access standards enforced through identity, approved models restricted at the platform, agent rules evaluated before an action executes, and evidence captured while the work happens. The goal is not a larger governance program, but a system that knows the rules.

The Policy Isn’t the Control

Consider one of the simplest AI governance decisions an organization can make.

Only three models are approved for enterprise use. Security has reviewed them, and procurement has approved the vendors. The policy has been circulated. Everybody has done the responsible organizational work.

Then, a developer points an application at model number four.

What happens next tells you more about the maturity of the governance program than the policy itself. If somebody eventually notices, the organization has monitoring. If somebody catches it during review, it has oversight. If the request fails because the environment only permits approved models, it has enforcement.

This distinction isn’t unique to AI. A data council can decide which system owns the authoritative customer record, but if two applications keep pulling different sources, the business still has two truths. Security can require access to be revoked when someone leaves, but the requirement means little to the account that remains active. A business owner can set an AI spending limit, but if enforcement depends on someone opening a dashboard next Thursday, the limit is really more of a request.

Governance becomes operational when the decision changes what the system can do.

Why Governance Earned Its Reputation

Data governance had its big enterprise moment well before generative AI arrived. Organizations formed councils, cataloged data, worked through definitions, and asked leaders from across the business to create a common set of rules. Many of those programs struggled to turn all of that agreement into something people experienced differently in their day-to-day work.

Jim Burnham, a Principal Consultant in Sparq’s Data, Analytics, & AI practice, describes part of the problem as a mismatch of jobs. The council was often asked not only to make governance decisions, but to carry out the research required to make decisions and then implementation required to put them into practice. His preferred model keeps the governance body firmly in place but changes its role: business and technology leaders create requirements as well as approve and own the rules; technical specialists do the research, present the research for a decision, and turn those decisions into the systems that enforce them.

That separation is important because the people best positioned to decide what “customer” means, which financial data a role should see, or what level of AI risk is acceptable aren't necessarily the people who should translate each decision into identity architecture, data permissions, deployment controls, or an audit system. Governance needs business ownership; Research needs a governance expert; Enforcement needs engineering.

AI hasn’t created that problem, but it has removed a lot of the room organizations once had to work around it.

AI Is Forcing Governance Into the Architecture

A human analyst operating inside an ambiguous environment can compensate. They know which dashboard Finance trusts. They remember that a particular field shouldn’t be shown to one group. They ask somebody before doing something unusual. A surprising amount of enterprise governance has survived because people carry the context that the system doesn’t.

AI is much less forgiving of that arrangement. An application asking questions against governed data needs to know which sources are authoritative and which rows or columns the person asking is entitled to see. An agent calling tools needs more than infrastructure permission; it needs rules about whether this action, in this context, should be allowed. If governance remains tribal knowledge, it becomes invisible precisely when automated systems need it most.

Kenneth Cavner, another Principal Consultant in Sparq’s Data, Analytics, & AI practice, makes a related distinction between governance during AI development and governance in the production system. Compliance requirements, data restrictions, and organizational rules should influence how the application is built, then continue to hold once that application is running. Treating governance as a bolt-on at either stage forces teams to rediscover the same requirements later, when changing the system costs more.

That’s the architectural shift underneath the governance conversation. The rule still starts with people. It just can’t end there.

One Governance Program Has More Than One Enforcement Point

This becomes especially clear in AI because different governance questions belong at different levels of the system. Sparq’s current framework separates them into three gates: intake, platform, and action. They work together, but each answers a question the others can’t.

The intake gate decides what the organization is willing to pursue in the first place. Which models, vendors, and use cases are approved? Who owns that decision? What needs to be true before engineering starts? This is where the Center of Excellence or other governing body matters most.

The platform gate governs the environment once work is underway. Identity, network access, approved model endpoints, keys, private connectivity, logging, and cost controls live here. This layer can turn an approved-model list from a document into something the cloud itself enforces.

The action gate appears when agents begin doing work. Infrastructure may know an authorized user is allowed to access a system, but that doesn’t necessarily tell it whether an agent working on one client should open another client’s directory, invoke a particular tool, or perform an action above a financial threshold. Those are contextual decisions made at execution time.

This is why one strong governance mechanism can create a false sense of completeness. An organization can have a mature AI landing zone and still lack action-level controls over agents running on developer machines. A vendor can ship excellent built-in safety controls without knowing the organization’s client boundaries, approval rules, or internal policies. A Center of Excellence can make sound decisions without anything in the architecture to make those decisions binding.

The useful question isn’t whether an organization “has AI governance,” but which decisions it’s made, where those decisions are enforced, and what remains dependent on a person remembering the rule.

Turning Decisions Into Mechanisms

Once you view governance this way, the work becomes far more concrete.

An approved-model list becomes an identity policy that only permits sanctioned endpoints. Access decisions become federated roles, explicit denies, and row- or column-level permissions that allow an application to answer only as much of a question as the person asking is entitled to see. A sanctioned tool catalog becomes an authenticated endpoint rather than a page on an internal wiki. Agent policies become versioned rules checked before an action executes. Audit requirements become records written as the system runs rather than assembled during a review.

None of those mechanisms decides what the organization’s policy should be. That remains a governance decision. Engineering makes the decision durable enough to survive contact with real work.

This is also where governance can stop being synonymous with delay. Kenneth described one client that had no repeatable model and had to work governance requirements out again for every project. Another already had the relevant people and decision structure in place, which made it far easier to implement the controls a new initiative needed. The difference wasn’t less governance. It was less reinvention.

The Next Use Case Should Be Easier

That leads to a more useful measure of governance maturity than the number of policies published or committees formed: does the next use case get easier to put into production?

Sparq’s current AI maturity model identifies “rebuilt every time” as one of the places organizations stall. Use case one pays to establish identity, logging, approval paths, access patterns, and other controls. Then use case two arrives and pays for them again. Nothing from the first project became infrastructure the second could inherit.

A real foundation behaves differently. Common controls already exist, the governed path is known, decision rights are clear, evidence is captured consistently, and new projects still have requirements specific to their data and workflow, but they don’t begin from zero every time.

The model’s health metric is deliberately simple: time to production for the next use case should get shorter every time.

Governance is usually framed as a trade—accept more friction now in exchange for less risk later. Poorly designed governance can work exactly that way. But controls that are engineered into a reusable foundation remove repeated decisions, repeated implementation work, and repeated uncertainty. The first governed use case establishes the path. Every one after it should get more of that path for free.

A Quick Test for Where Your Governance Lives

You don’t need a maturity assessment to spot the most obvious gaps. A few questions will usually tell you whether the rules are embedded in the operation or still sitting beside it:

• If someone tries to use an unapproved AI model tomorrow, what stops them?
• If an AI application queries sensitive data, how does it know how much the person asking is allowed to see?
• If an agent proposes an action your organization prohibits, where does the denial happen?
• If a reviewer asks what happened three months ago, does the answer come from a query or a reconstruction project?

If every answer points to a meeting, a wiki, someone’s memory, or a manual check, the organization may have good governance decisions and weak enforcement. If the answers point to identity policy, governed data, platform controls, action gates, and records created as the work happens, the architecture is carrying more of the responsibility.

AI continues to push governance in this direction. Not away from people, and not toward some fantasy of completely automated oversight. The business still has to decide what’s allowed, security still has to define acceptable risk, and governance leaders still have to own the rules.

The difference is that the systems finally have to know what those decisions were.

Put the rules where the work happens. Sparq engineers governance across data, identity, AI platforms, and agent actions so controls hold in production and the next use case starts from a stronger foundation. Explore Governance & Controls →