AI Governance Metrics and KPIs: What to Measure at the AI Request Layer

IBM's Cost of a Data Breach study found that breaches linked to shadow AI take 247 days to detect, six days longer than the average breach. That gap is a measurement failure before it is a security failure. An organization that could measure which identities were calling which models would have closed the window earlier. Most governance dashboards track policy documents authored and training modules completed, which are activity counts that say nothing about whether AI requests are actually controlled.

I want to define the metrics that come from the point where AI requests flow, because those are the numbers that describe the state of the system rather than the state of the paperwork.

Governance metrics that describe the paperwork

Common AI governance scorecards report the number of policies published, the percentage of staff who completed AI training, and the count of models registered in a catalog. Each of these is a leading indicator at best. A published policy with no enforcement point constrains nothing. A registered model with no runtime controls around it carries the same risk as an unregistered one.

Cloud Radix reported that 86% of IT leaders are blind to employee AI interactions. A governance metric drawn from a self-reported catalog inherits that blindness. The catalog shows the models the organization knows about, and the risk lives in the traffic it does not.

Metrics that describe the system

The metrics worth reporting come from the AI request layer, where every call to a model can be counted, attributed, and evaluated. Six of them describe the actual control state:

• AI route coverage. The percentage of AI request paths that pass through a policy decision. Coverage below 100% names the ungoverned routes precisely, which turns the shadow-AI problem into a work list.
• Identity attribution rate. The percentage of AI calls bound to a known user or agent identity. Unattributed calls are the ones an incident responder cannot trace.
• Audit-log completeness. The percentage of AI decisions that produced a per-decision record. Article 12 of the EU AI Act asks for logging over the lifetime of the system, and completeness is how you demonstrate it.
• Policy-decision latency. The overhead the enforcement layer adds per request. Internal DeepInspect testing measures this under 50 ms, which is the budget that keeps inline enforcement from degrading the application.
• Exception rate and time-to-close. How many policy exceptions are open and how long they stay open. A rising exception backlog is governance debt accumulating in plain sight.
• Blocked-request rate by data class. How many requests were stopped inline for attempting to move a sensitive data class. This is the metric that shows the control is doing work, not just watching.

Each of these is a number the enforcement layer produces as a side effect of doing its job. None depends on a survey.

Tying metrics to the number that matters

Gartner projects that unlawful AI-informed decision-making will generate over $10 billion in remediation costs and damages by mid-2026. Governance metrics exist to keep an organization on the safe side of that figure and to prove it did so. Coverage and audit-log completeness are the two that a regulator or plaintiff's counsel will ask for directly, because they answer whether the organization could reconstruct what its AI systems did.

Report the six system metrics to the governance oversight body on a fixed cadence, and feed the same numbers into the AI governance implementation roadmap so each phase has an exit criterion drawn from data. Metrics reported this way also satisfy the monitoring expectations in the NIST AI RMF MEASURE function.

DeepInspect

DeepInspect produces these metrics as telemetry from the enforcement layer. It sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM, evaluating each request against identity-bound policy before the model receives it.

Because every request passes through the proxy, coverage, attribution, latency, and blocked-request counts are measured rather than estimated. Because every decision produces a signed record with identity, role, policy version, data classification, outcome, and timestamp, audit-log completeness is structural to the design. The governance dashboard stops reporting how many policies were written and starts reporting how many AI decisions were controlled and recorded.

If your current AI governance metrics count documents instead of decisions, the dashboard is measuring the wrong layer. Book a demo today.