Enforcement vs. observation: why logging what your automations do is not governance

In the last year, “AI agent governance” has become a label attached to almost any product that can produce a dashboard. Most of what ships under that label is observability: the agent acts, the platform records, someone reviews. That architecture is familiar, useful — and structurally unable to do the one thing governance means.

The observability reflex

When software misbehaved historically, we instrumented it. Metrics, traces, logs — the whole discipline assumes that the cost of a bad action is bounded and reversible, so it is enough to detect it quickly. A slow endpoint costs latency; you find it, you fix it.

Agents break that assumption. An agent with production credentials doesn't produce slow endpoints; it produces purchase orders, refunds, contract clauses and data transfers. By the time the anomaly shows up on a dashboard, the action has legal and financial existence. One European e-commerce company we spoke with watched an inventory agent place 127 duplicate purchase orders — €340,000 — in four hours. The logs were perfect. Nobody was looking at 2 a.m.

A log is not a control

Auditors distinguish between detective and preventive controls, and the distinction is exactly the one that matters here. A log — even a perfect, immutable, cryptographically sealed log — is a detective control. It changes what you can prove, not what can happen.

Observation changes what you can prove. Enforcement changes what can happen.

For human employees, companies never accepted detective-only controls for consequential actions. Payments require approval chains; access requires provisioning; contracts require signature authority. The uncomfortable question is why an agent — faster than any employee and less predictable than any script — should operate with weaker controls than the intern.

What pre-execution authorization changes

A policy decision point in front of the action inverts the default. The agent asks first; a declarative policy answers in milliseconds; the verdict — allow, review or block — is signed and time-boxed. The runaway inventory agent meets a different fate: the third duplicate order fails policy, authorizations stop, and a human is paged with the full decision context. The loss is bounded by the policy, not by whoever wakes up first.

Crucially, this doesn't require rebuilding the agent. The decision point can sit inside an n8n flow as a node, inside Salesforce as a connector, or behind an SDK call — the agent's own rails execute the action, under a verdict that already exists when they do.

What the regulator will ask

The AI Act's human-oversight provisions (Article 14) are written in the language of prevention: measures that allow humans to “intervene” and “interrupt” the system. An architecture that can only narrate what already happened does not have an intervention story. An architecture where every consequential action carries a pre-execution verdict, an accountable human and a sealed record — does.

Observability stacks remain essential — after Kimetai authorizes an action, the trace of its execution still belongs in your SIEM, and we export there natively. The point is narrower: keep calling that layer monitoring. Governance is the layer that decides.