Essay

An approval gate is a control. An AI policy is not.

Most AI governance programs fail at the same place: the moment someone has to be told no. Here is what an enforceable gate looks like when the data in question is protected health information.

Ketrica R. Green

Almost every organization I have worked with in the last three years has an AI policy. Very few have AI governance.

The difference is not semantic. A policy is a document describing principles — use AI responsibly, protect sensitive data, consider ethical implications. It is written, circulated, acknowledged, and filed. It has no enforcement point. There is no moment in the deployment path at which the policy stops anything, which means the policy is not a control. It is a statement of intent that a business unit can satisfy by reading it.

Governance is different. Governance is the point in the process where a deployment does not proceed. If your AI program has no such point, you do not have governance regardless of how good the document is — and the way you discover this is that a business unit has already deployed something and nobody in security was told.

The question that forces the issue

In healthcare the abstraction collapses into a specific and uncomfortable question: how do you let clinicians use large language models against protected health information without creating a HIPAA breach?

The obvious answer is to keep the model inside the environment. Self-hosted models avoid third-party sharing, avoid the business associate agreement question with a foundation model provider, and keep inference traffic off the public internet. This is genuinely better than the alternative. It is also where most programs stop thinking, and that is the error, because a local model introduces new leak paths that a hosted one does not.

There are at least five worth naming. Model weights of unverified provenance can carry poisoned or backdoored behavior. Prompt and response logs — enabled by default in most inference stacks for debugging — quietly accumulate PHI in a location nobody classified. Vector stores flatten record-level access control: a document a given clinician could not open in the source system becomes retrievable as a chunk, because the embedding index has no concept of who is asking. Inference endpoints frequently ship without authentication, on the assumption that internal means safe. And agentic deployments, which can call tools and take actions, can be steered by content they retrieve into doing things nobody authorized.

None of those are solved by hosting the model yourself. Several are created by it.

What we built instead

Rather than a policy of general principles, we built a hard control: no local model processes PHI until an approval gate is passed and signed by all required approvers. The gate is binary. There is no partial pass, no provisional approval, no deploy-now-remediate-later.

Five controls sit at priority one. Failing any single one fails the gate.

• Endpoint authentication. The inference endpoint authenticates every caller. Network position is not identity, and an unauthenticated endpoint on an internal subnet is an unauthenticated endpoint.
• Attributable audit. Every inference is attributable to a specific human identity. Not to a service account, not to an application — to a person. Without this you cannot investigate anything after the fact, and you cannot answer the question an auditor will ask about who accessed what.
• No PHI in logs. Prompt and response logging is off, or redacted at source before it is written. This is the single most commonly failed control, because logging is on by default and nobody classified the log store.
• Retrieval authorization. The retrieval layer enforces the same access control as the source system. If the requesting user cannot open the record, the retriever cannot return the chunk. Solving this properly is more work than standing up the vector store in the first place.
• Model weight provenance. The weights come from a verified source with a documented chain of custody. You are executing someone else's artifact inside your environment; the supply chain question applies exactly as it does to any other binary.

Agentic deployments carry additional controls before go-live: human-in-the-loop for consequential actions, least-privilege scoping of every tool the agent can call, and validation of outputs before they are acted upon. An agent with broad tool access and no human checkpoint is not an AI risk — it is an unmanaged privileged account that happens to be a model.

Keeping cardholder data out of the model path

The same architecture had adjacency to a cardholder data environment, and there the governing principle was different: the model operates near the CDE but never sees cardholder data. Enforced through tokenization, redaction, and a broker pattern that sits between the application and the model.

The reasoning is scope. If unredacted primary account numbers cross into a foundation model API, you have pulled that provider into PCI scope as a third-party service provider and materially expanded your CDE boundary — which is a decision with assessment consequences that nobody making the request was thinking about. So the gate forces the decision the other way: default no, and anyone arguing for yes has to justify why tokenization or the last four digits cannot satisfy the use case.

A control that is easier to follow than to bypass is the kind that survives.

Almost always, they can. The request for full PAN in a model prompt is usually habit rather than requirement, and asking the question once at the gate is cheaper than discovering the answer during an assessment.

Making it survive contact with the business

A gate that exists only at first deployment decays. Ours registers every approved deployment, re-attests annually and on material change, and reflects each one in the HIPAA Security Risk Analysis — so the AI inventory is not a separate spreadsheet that drifts out of date, it is part of a document the organization is already obligated to maintain.

That integration principle mattered more than any individual control. AI governance run as a parallel program competes for attention with the audit obligations the organization already has, and loses. Folded into HITRUST, SOX, NIST and CMMC evidence collection, it inherits the cadence and the accountability that already exist.

The outcomes were 100% of models under governance, a 25% improvement in threat detection, and — the one I care most about — PCI scope held stable while AI capability expanded. Acquired-entity AI usage is now explicitly treated as inherited risk and flagged for discovery during integration, because the fastest way to acquire ungoverned AI is to acquire a company.

The test

If you want to know whether an organization has AI governance or an AI policy, do not read the document. Ask a simpler question: when was the last time a proposed AI deployment was stopped, and who signed the decision?

If the answer is never, the gate is not a gate. It is a form.