Do we need all four shapes of AI governance tool?

Most regulated enterprises end up with at least three: a registry for model artifacts, a policy authoring layer for governance documents, and a runtime enforcement layer for per-decision records. The posture scanner is often covered by the existing CSPM with an AI module. The combination that actually closes the regulatory obligations is registry plus policy authoring plus runtime enforcement, with the runtime layer doing the heaviest evidentiary work.

Can a GRC platform replace the runtime enforcement layer?

GRC platforms produce document- and attestation-shaped records. They cannot produce per-request records at the granularity Article 12 requires because they do not sit on the request path. The GRC platform is the right home for the policy library, the control catalog, the risk register, and the audit attestations. It is the wrong home for the per-decision evidence series. A regulator reviewing under EU AI Act Article 12 will read both and credit the GRC platform for the policy framework, but the runtime evidence is what closes the obligation.

How does an AI governance tool handle agentic AI?

Agentic AI raises the per-decision-record obligation by an order of magnitude because the agent's actions are themselves audited events. The runtime enforcement layer authenticates the agent's identity, classifies the prompt and the tool calls, and commits a record per decision the agent makes. The registry and policy layers track the agent's configuration and the policies that apply. The NIST AI agent identity and authorization framework codifies the pattern. This is covered in the NIST piece and the autonomous AI agent governance article.

How does an AI governance tool produce evidence for an EU AI Act audit?

The runtime enforcement layer produces per-decision records carrying identity, classification, policy version, and decision outcome. The registry produces artifact lineage records. The policy authoring layer produces the governance document trail. The combined evidence package answers the questions a regulator asks: which model was used, what policy governed, who was the natural person behind the request, what data classification applied, what was the outcome, can you produce an immutable record of all of the above.

Where do free-tool category landing pages like Kong, Databricks, or Helicone fit in this category?

Those products are gateway and observability layers that overlap with the runtime enforcement shape on the deployment topology but differ in the policy and audit surface. Comparison details are covered in the DeepInspect vs Kong AI Gateway, DeepInspect vs Databricks AI Gateway, and DeepInspect vs Helicone pieces.

AI Governance Tools: What the Category Has To Cover and Where Most Products Stop

The "AI governance tools" category reaches the buyer with four very different product shapes. Some vendors apply the label to a model registry that tracks artifact lineage and training-data provenance. Some apply it to a policy authoring platform that produces written governance documents and approval workflows. Some apply it to a posture scanner that discovers AI service usage across cloud accounts. And some apply it to a runtime enforcement layer that intercepts AI requests, evaluates identity-bound policy, and commits a per-decision audit record. The four shapes solve different obligations under the same regulatory regimes. Buying one and assuming the others are covered is how organizations discover the runtime gap during their first regulator review.

I want to walk through the four product shapes the category currently covers, the obligation each one closes under the major frameworks, the gap each one leaves, and where the runtime record series gets produced.

The four product shapes the category covers

The first shape is a model registry. It tracks model artifacts, training data lineage, version metadata, and promotion approvals. Datadog AI Observability, MLflow, Weights & Biases, and the cloud-vendor MLOps catalogs sit in this shape. The record series is artifact-shaped: this model was trained on this data and promoted at this timestamp.

The second shape is a policy authoring platform. It produces written governance documents, captures approval workflows, and stores attestations against a control catalog. Collibra AI Governance, OneTrust AI, and the GRC vendors sit in this shape. The record series is document-shaped: this policy was approved by these reviewers at this timestamp.

The third shape is a posture scanner. It discovers AI service usage across cloud accounts and SaaS catalogs and produces an inventory. CSPM vendors with AI modules sit in this shape. The record series is asset-shaped: this account uses these AI services.

The fourth shape is a runtime enforcement layer. It intercepts AI requests at the HTTP boundary between authenticated users or agents and the LLM, evaluates identity-bound policy at request time, and commits a per-decision audit record. DeepInspect sits in this shape.

What each shape closes under EU AI Act, NIST, ISO 42001, and Fannie Mae

EU AI Act Article 9 requires a risk management system across the lifecycle of the AI system. Model registries support the artifact side of that obligation. Policy authoring platforms support the documented-system side. Posture scanners support the inventory side. None of them close Article 12, which requires automatic recording of events over the system lifetime sufficient to ensure traceability. Article 12 is a runtime obligation. The runtime enforcement layer is what produces the record series that survives the review.

NIST AI RMF has four functions: Govern, Map, Measure, Manage. The first three are document- and inventory-shaped and the first three product types cover them. Manage 4 expects ongoing tracking of AI risks and their controls, which is a runtime obligation that hits the inspection layer.

ISO 42001 defines an AI management system standard with controls that span policy, risk, lifecycle, and operations. The operational controls are runtime obligations.

Fannie Mae LL-2026-04 requires disclosure on demand for AI tools, providers, and safeguards, effective August 6, 2026. Disclosure on demand is a runtime obligation against per-decision records.

The pattern across regimes is the same: the document and inventory layers close the upfront obligations and the runtime enforcement layer closes the per-decision obligations.

Where each shape stops

A model registry stops at the artifact boundary. It records what the model is and how it got promoted. It does not record what happened when a specific user sent a specific prompt to the model in production. Article 12 is a per-request obligation. The registry record is per-artifact. The two are not interchangeable.

A policy authoring platform stops at the document boundary. The document says what the organization will do. The runtime evidence shows what the organization actually did. A regulator reviewing under Article 12 or Fannie Mae LL-2026-04 reads both, but the runtime evidence is what closes the obligation. The document alone fails the traceability test.

A posture scanner stops at the inventory boundary. The inventory says which services exist. It does not say what those services did at the request level. The scanner cannot answer "which natural person prompted this model on this day with what data classification under what policy version."

Runtime enforcement is where the per-decision record gets produced.

Where the runtime record series gets produced

The runtime record series gets produced at the HTTP request boundary between the authenticated caller and the LLM. The inspection layer terminates TLS at that boundary, authenticates the caller against the corporate identity provider, classifies the prompt content, evaluates policy against the identity and the classification, and commits a tamper-evident record before the model response returns to the application. The record carries identity, role, data classification, policy version, decision outcome, timestamp, and an integrity signature.

The fields map directly to Article 19 of the EU AI Act, the Fannie Mae disclosure requirement, the NIST RMF Manage 4 expectation, and the ISO 42001 operational controls. The same record series satisfies the per-decision obligation across regimes. The architecture is covered in the AI control plane piece and the AI audit log format spec.

DeepInspect

DeepInspect is the runtime enforcement shape of an AI governance tool. It sits inline on the HTTP path between authenticated users or agents and any LLM, evaluates identity-bound policy at request time, and commits a per-decision tamper-evident audit record. The record series satisfies the runtime obligations under EU AI Act Articles 12 and 19, NIST AI RMF Manage 4, ISO 42001 operational controls, and Fannie Mae LL-2026-04 disclosure on demand.

If the current AI governance stack is shaped as registry, policy authoring, or posture scanning, the runtime obligation is the open one. The August 2, 2026 EU AI Act deadline and the August 6, 2026 Fannie Mae deadline both require runtime evidence at the per-decision level the document and inventory layers were never designed to produce.

If you are facing the August deadline, let's talk.