Can a single vendor cover all four shapes?

A small number of vendors claim coverage across multiple shapes. In practice the architectural property that makes a strong runtime enforcement layer (HTTP-boundary placement, audit write path independence, fail-closed defaults) is different from the property that makes a strong GRC platform (control catalog depth, workflow features, attestation campaigns) or a strong model registry (lineage depth). Most regulated buyers end up with separate vendors for each shape rather than a single bundled product.

How does the comparison change for buyers who run only one foundation model vendor?

When the deployment is single-vendor (only OpenAI, or only Bedrock), the buyer can sometimes use the model vendor's native guardrails as a piece of shape D. The architectural failure mode is that the model-vendor guardrails do not produce a record series independent of the vendor, which means the deployer cannot demonstrate the audit trail under an EU AI Act review without the vendor's cooperation. Most regulated buyers add an independent shape D layer regardless.

How does this comparison apply to public-sector buyers?

Public-sector buyers usually face additional procurement constraints (FedRAMP for US federal, the equivalent national certifications in EU member states) that filter the vendor lists in each shape. The shape split is the same. The combination is the same. The vendor filter applies on top.

What does the timeline look like for a buyer starting in May 2026?

Shape D evaluation in May. Shape D procurement decision in early June. Shape D deployment in June and July. Operational handover in early August, in time for the EU AI Act August 2 deadline and the Fannie Mae August 6 deadline. The other shapes (registry, GRC, posture scanner) usually run in parallel programs and have longer timelines, but shape D is the critical path.

Where do free-tool category landing pages fit into this comparison?

Free-tool products (open-source guardrails libraries, lightweight gateways like LiteLLM, free policy generators) cover narrow gaps and supplement the paid categories above. They do not by themselves close any of the major regulatory obligations because the audit write path and integrity guarantee are left to the deployer to wire up. The cost of closing the gaps in operational engineering often exceeds the licensed product cost.

AI Governance Tools Comparison: Where Each Category Sits and Which Obligation It Closes

AI governance tools comparison content typically treats the category as a single list of competing vendors. The treatment misses the architectural property that actually drives buying decisions in 2026: the category covers four very different product shapes that sit at different layers of the AI stack, and each shape closes a different obligation under the major regulatory regimes taking effect this year. A flat-list comparison ranks vendors that are not actually substitutes. The useful comparison ranks vendors inside each shape and shows how the shapes combine.

I want to walk through the four product shapes the category covers, the obligation each shape closes under EU AI Act Article 12, Fannie Mae LL-2026-04, NIST AI RMF, and ISO 42001, the evaluation criterion that distinguishes vendors inside each shape, and the combination most regulated buyers end up purchasing.

Shape A: model registries and MLOps catalogs

Shape A products track model artifacts, training data lineage, version metadata, and promotion approvals. The category includes MLflow, Weights & Biases, the cloud-vendor MLOps catalogs (SageMaker Model Registry, Vertex AI Model Registry, Azure ML Registry), and observability-leaning products like Datadog AI Observability and Arize.

The obligation this shape closes is the technical-documentation requirement under EU AI Act Article 11 and the artifact side of the Article 9 risk management system. The record series is artifact-shaped: this model was trained on this data and promoted at this timestamp.

The shape does not close Article 12 (per-decision recording) because the record is per-artifact, not per-request. The shape does not close the Fannie Mae LL-2026-04 disclosure obligation, which is per-decision.

Inside-shape vendor distinctions: data lineage depth, support for foundation-model API tracking, registry-to-runtime promotion workflow, and integration with the GRC system. The major MLOps catalogs are similar enough on these axes that the buying decision usually falls on which cloud the AI workloads run in.

Shape B: GRC and policy authoring platforms

Shape B products produce written governance documents, store approval workflows, capture attestations against a control catalog, and run risk register updates. The category includes Collibra AI Governance, OneTrust AI, IBM watsonx.governance, RSA Archer, ServiceNow GRC, and MetricStream.

The obligation this shape closes is the documented-system side across all four regimes: the policy library under EU AI Act, the management system under ISO 42001, the Govern function under NIST AI RMF, and the documented procedures under Fannie Mae LL-2026-04. The record series is document-shaped: this policy was approved by these reviewers at this timestamp.

The shape does not close the per-decision evidence obligation. The document trail and the runtime record series are two different evidentiary layers, and a regulator reads both.

Inside-shape vendor distinctions: depth of pre-built AI control catalogs, integration with the underlying GRC platform, support for cross-framework mapping (EU AI Act to NIST to ISO), and the workflow features for attestation campaigns. The IBM and Collibra products are stronger on AI-specific controls. The GRC-platform AI modules (Archer, ServiceNow) are stronger when the organization already runs the platform.

Shape C: posture and inventory scanners

Shape C products discover AI service usage across cloud accounts, SaaS catalogs, and on-premises systems. The category includes CSPM products with AI modules (Wiz AI-SPM, Orca, Lacework), CASB products with AI feeds, and SaaS discovery products.

The obligation this shape closes is the inventory requirement under EU AI Act Article 9 risk management. The record series is asset-shaped: this cloud account uses these AI services.

The shape does not produce per-decision records or enforce policy at the request layer. A regulator's question "what prompt did this user send" cannot be answered from a posture scan.

Inside-shape vendor distinctions: coverage of foundation-model API usage (which is harder to discover than infrastructure-level AI deployments), classification accuracy for AI usage versus general SaaS usage, integration with the GRC system for control-state tracking, and remediation workflow. Most CSPM products with an AI module turned on cover the basics.

Shape D: runtime enforcement layers at the HTTP request boundary

Shape D products sit inline on the HTTP path between authenticated users or agents and the LLM endpoint. The category includes DeepInspect, the inspection mode of Lakera (now part of Check Point), Cloudflare One AI Gateway, the AI inspection products from Palo Alto and Zscaler, and a number of newer entrants. The category is also adjacent to AI gateway products like Kong AI Gateway, Databricks AI Gateway, Helicone, Portkey, MLflow AI Gateway, and Langfuse, which overlap in deployment topology but differ in the policy and audit surface.

The obligation this shape closes is the per-decision recording requirement under EU AI Act Article 12 and Article 19, the disclosure obligation under Fannie Mae LL-2026-04, the Manage 4 expectation under NIST AI RMF, and the operational controls under ISO 42001. The record series is request-shaped: this natural person sent this prompt to this model with this classification under this policy version with this outcome at this timestamp.

Inside-shape vendor distinctions: the twelve evaluation questions in the vendor evaluation criteria piece. The most-discriminating questions are placement (does the vendor sit at the HTTP boundary), audit write path independence, fail-closed behavior, and multi-vendor model coverage. The detailed comparisons against named vendors are in the comparison series (Lakera, Bedrock Guardrails, Kong, and the rest).

The combination most regulated buyers end up with

A regulated enterprise preparing for the August 2026 deadlines typically ends up with shape D plus one of shapes A or B plus shape C. Specifically:

Shape D (runtime enforcement) is non-substitutable because nothing else produces the per-decision record.
Shape B (GRC platform) is usually preferred over shape A (registry) because the documented-system obligation is broader than the artifact lineage obligation.
Shape C (posture scanner) is usually already deployed via an existing CSPM with an AI module turned on.

The buying decision pattern is therefore "what is our shape D vendor, given that we already have a GRC platform and a CSPM with an AI module." This is the question that drives the procurement process in May, June, and July 2026 against the August 2 and August 6 deadlines.

DeepInspect

DeepInspect is a shape D runtime enforcement layer. It sits inline on the HTTP path between authenticated users or agents and any LLM, binds identity from the corporate IdP, runs deterministic classification on prompt content, evaluates policy from a single version source, and commits a tamper-evident per-decision audit record before the model response returns to the application. The record series satisfies the per-decision evidence obligation across EU AI Act Articles 12 and 19, Fannie Mae LL-2026-04, DORA, NIST AI RMF Manage 4, ISO 42001 operational controls, and HIPAA audit controls.

For organizations evaluating the shape D category in May or June 2026, the deployment timeline runs in weeks. The handover to operations runs in early August. The evaluation should happen now.

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