Walk into most enterprises that have taken AI governance seriously and you will find two things already in place. There is a program layer — a GRC platform, a model registry, a set of policies mapped to frameworks, an inventory of AI systems, and a stack of attestations. And there is a monitoring layer — dashboards for drift, fairness metrics, latency, and incident forensics. Both are real, both took work, and both are necessary.
And yet, when an examiner or an internal auditor asks the one question that matters — "Show me the governance record for this specific AI decision, and prove the policy was applied" — the answer is usually a scramble through application logs. That gap is not an accident of immaturity. It is structural. There is a third layer that most stacks simply do not have: a place where policy is enforced at the moment of the decision and where evidence is produced as a byproduct. Call it the enforcement plane. It is the missing layer.
The three layers of a complete governance stack
A complete enterprise AI governance stack has three distinct layers, each answering a different question. The confusion in the market comes from treating any one of them as if it were the whole thing.
Policies, model registries, framework mappings (NIST AI RMF, ISO/IEC 42001, EU AI Act obligations), risk assessments, and attestations. This is where the organization decides its rules and documents its posture. It is the layer of intent and record-keeping about the program itself.
Monitoring, drift detection, fairness trend analysis, performance dashboards, and incident forensics. This layer watches behavior over time and surfaces problems. Modern observability vendors do this well — but everything it sees, it sees after the action has occurred.
A deterministic gate in the request path that evaluates a proposed AI action against a versioned policy pack before it executes, returns ALLOW / BLOCK / MODIFY, fails closed, and emits a cryptographically signed decision certificate for every evaluation. This is the layer most stacks are missing.
Why the third layer is the one most stacks lack
The reason is historical. GRC tooling grew out of compliance and risk management, where the deliverable is documentation. Observability grew out of MLOps and site reliability, where the deliverable is a dashboard. Neither discipline was built to sit inline in a production request path and return a binding verdict in under a millisecond, and neither was built to emit tamper-evident, reproducible evidence per decision. So the enforcement plane didn't get built — it fell in the crack between two mature categories that each assumed the other had it covered.
| Layer | Question it answers | Position relative to the decision | Evidentiary value to an examiner |
|---|---|---|---|
| Program governance (GRC) | What should our governance be? | Before & around — sets policy | Documents intent, not the individual decision |
| Observability | What is the AI doing in aggregate? | After — observes outcomes | Trends & forensics, not per-decision proof |
| Enforcement plane | Was this decision governed correctly, and can we prove it? | At the decision — inline, pre-execution | Signed, reproducible record per decision |
Symptoms of a missing enforcement plane
You rarely notice the gap until a specific decision is in question. The symptoms are recognizable, and they tend to surface in the same three sentences:
- "We have policies, but we can't prove they were applied to this decision." The policy exists in a document and maybe in code, but there is no artifact tying it to the individual inference that a regulator is asking about.
- "Our audit trail is application logs we wrote ourselves." Logs are mutable, vendor-controlled, and self-attested. An examiner's reasonable next question — "who could have edited this?" — has no good answer.
- "Identical inputs produced different governance outcomes." When the control is probabilistic or model-based, the same case can be treated differently on two runs. That is an audit finding, not a feature.
If your organization received an examiner inquiry asking you to produce the governance record for one specific AI decision made 18 months ago — which rules were evaluated, what the disposition was, which exact policy version applied — could you produce that record, reproducibly, within 24 hours? If not, you have logging where you need a control. They are different things.
What the enforcement plane must provide
Three properties define the layer. Miss any one and it collapses back into "monitoring with extra steps."
1. A deterministic verdict, pre-execution, fail-closed
The gate evaluates the proposed action against a policy pack and returns ALLOW, BLOCK, or MODIFY before the action is used, with no stochastic step in the decision path. Same input plus same policy state produces the same verdict, every time. And when the gate is unavailable or uncertain, the default is to block — not to wave the action through. Deterministic, pre-execution governance is what makes the verdict a control rather than a suggestion.
2. Cryptographic, offline-verifiable evidence per decision
Every evaluation emits a signed decision certificate — inputs digest, policy identity and version, verdict, timestamp, signature, and key identifier — that anyone holding the public key can verify without calling back to the vendor. That is the difference between signed evidence per decision and a log line you are asking people to trust.
3. Policy versioning and runtime attestation
Each decision record references the exact policy version that governed it and the exact build that produced the verdict. Months later, you can answer not just "what was decided" but "which policy decided it, running on which code." Without this, reproducibility is impossible and the evidence is incomplete.
How the layers interlock
The enforcement plane does not replace the other two layers — it completes them, and it is what turns three disconnected tools into one control narrative an examiner can follow end to end.
- GRC defines the policy. The rules, thresholds, and framework mappings originate in the program layer.
- The enforcement plane executes that policy deterministically at each decision and emits the signed record.
- Observability watches the aggregate — trends across the stream of decisions, drift, and fairness over time.
Policy defined in GRC → enforced deterministically at the decision by the enforcement plane → signed evidence emitted → aggregate behavior watched by observability. An examiner can walk that chain in one direction, from the written policy to the individual signed decision and back. That end-to-end line is exactly what a missing enforcement plane breaks.
Building vs. buying the enforcement plane
The instinct at a well-resourced enterprise is to build it — a bit of request-path middleware that checks a rule and writes a log. It rarely survives model validation, for reasons that are architectural rather than a matter of effort.
This is also where GRC-first platforms fit into the picture. Program-governance tools such as Credo AI are strong at the first layer — the policies, registries, and attestations — but they are not designed to sit in the request path and return a binding, signed verdict on an individual decision. That is a complementary layer, not a competing one. It is worth mapping your own stack against all three layers before assuming a gap is filled; you can compare the full landscape here, and the platform overview shows where the enforcement plane sits.
A 90-day adoption plan
Adding the enforcement plane does not require ripping out anything. The pragmatic path is narrow and evidence-first:
- Days 1–15 — Assess. Identify your highest-stakes decision type — the one an examiner is most likely to ask about (adverse action, a coverage determination, a trade). Document the policy that should govern it and the evidence you can produce today.
- Days 15–60 — Pilot on one decision type. Put the enforcement plane inline for that single decision type, first in shadow mode (evaluating and recording without blocking), then enforcing. Validate that the signed certificates reproduce offline and that latency is within budget.
- Days 60–90 — Expand. Once one decision type is proven, extend to adjacent decisions. Wire the signed evidence stream into your existing observability and GRC tooling so the control narrative is continuous.
You are not replacing your governance program — you are closing the one hole in it. When the pilot is done, you can answer the 24-hour test for at least one decision type with a signed, reproducible record. Every subsequent decision type is an extension of the same pattern.
Frequently Asked Questions
Comparison based on publicly available product documentation as of June 2026; vendor capabilities evolve — verify current specifics with each vendor. Descriptions of tool categories are general and not an assertion about any specific product's roadmap.