"Observability is not enforcement" is one of the most repeated lines in the 2026 AI-governance discourse — and one of the most misunderstood. Every observability vendor now claims some form of "control." Every gateway vendor claims some form of "visibility." The distinction has not disappeared. It has been blurred, and that blurring is expensive.
This post draws the line as precisely as possible, cites the sources actively shaping the debate, and shows what a defensible split looks like in a production stack.
What the debate is actually about
The two camps agree on the diagnosis and disagree on the remedy.
The diagnosis, per FERZ, Aurascape, Upwind and (more cautiously) the traditional observability vendors: enterprise AI is now a runtime system with the same governance requirements as any other production surface, and traditional MLOps monitoring is insufficient. This is not controversial.
The remedy: FERZ, Aurascape, ThinkNEO and the runtime-enforcement camp argue that the control point must be inline — a decision function on the request path. The observability-first camp argues that instrumenting existing pipelines with denser telemetry, plus alerts, plus a human loop, is sufficient.
The runtime camp wins the argument for one simple reason: a log entry cannot stop a call. Only a component with the authority to reject can stop a call, and to reject in time it must be on the path.
The definitions we will use
Definitions matter because vendors have started calling everything "governance."
- Observability: the discipline of capturing telemetry — traces, metrics, logs, payloads, tokens, latencies — from AI systems running in production. Its unit of value is a query answered after the fact.
- Runtime enforcement: the discipline of intercepting AI actions before they execute and applying a deterministic allow/deny/redirect decision. Its unit of value is a denied call.
- Governance (as a category): the umbrella program that defines what is allowed. Governance is a document plus a set of controls. Enforcement is one of those controls.
Observability is passive by design. That is its virtue — an observability system that started rewriting requests would break the invariant that logs describe reality. Enforcement is active by definition. That is its virtue — an enforcement system that only logs violations has failed its job.
Where the two overlap (and where they don't)
| Capability | Belongs to observability | Belongs to enforcement |
|---|---|---|
| Trace collection | Yes | Uses, does not produce |
| Metric emission | Yes | Uses, does not produce |
| Policy resolution | No | Yes |
| Allow/deny at request time | No | Yes |
| Cost attribution write | Yes | Emits, does not aggregate |
| Alert routing | Yes | Uses via observability |
| Immutable audit ledger | Sometimes | Yes, as evidence of decisions |
A healthy stack has both. The enforcement layer produces decision events; observability collects them and produces dashboards. When either side tries to absorb the other, the failure modes get worse.
The three failure modes to avoid
1. "Observability with alerts" as enforcement
The pattern: capture all LLM traces, add a spend threshold alert, treat the pager as the enforcement mechanism. This works during business hours for engineered incidents. It does not work at 03:00 UTC for a runaway agent that burns the annual budget in six hours.
2. "Enforcement with no telemetry" as governance
The pattern: hard limits at the gateway, no per-decision logging, no exportable evidence. This survives an incident but fails an audit. SOC 2 and ISO 42001 both require demonstrable, reviewable control history — not just the assertion that a control exists.
3. "One vendor for both" without clear ownership
The pattern: buy a single platform, delegate both layers to the same team, forget that the failure modes are opposite. Observability wants completeness (log everything, alert on anomalies); enforcement wants restraint (block only when the rule fires cleanly, avoid false positives on live traffic). These pull the design in opposite directions.
How to run both in practice
The reference pattern that has emerged in 2026:
- Put an enforcement gateway on the request path. It emits a rich decision event per call (rule id, inputs, outcome, timing).
- Send those decision events to your existing observability platform. Do not build a separate dashboard for enforcement — enforcement's dashboards are the same dashboards.
- Give the enforcement gateway a small, deterministic rule set that is version-controlled and auditable.
- Give the observability platform the full trace surface, including model input/output payloads (with PII redaction).
- Wire alerts from observability back to enforcement rule proposals — the loop closes when a repeated pattern in observability becomes a new deterministic rule at the gateway.
The buying-decision matrix
A quick way to know which layer you are short on:
- You can see every prompt and completion but cannot stop the next one → you need enforcement.
- You can block traffic but cannot answer "why did that call get blocked at 14:23" → you need observability.
- You can do both but cannot prove either to an auditor → you need an immutable ledger layer under both.
Bottom line
Observability and enforcement are complementary controls. They live in different planes, produce different artefacts, and fail differently. Buying one and calling it the other is the single most common architectural mistake in the AI-governance market this year. Draw the line explicitly, own it explicitly, and buy for both.
Related reading: What is AI runtime enforcement? · Enforcement vs guardrails · ThinkNEO vs Helicone