← Blog

AI Governance Tools: Production Control Compared

Parminder Singh
Parminder Singh··5 min read
Summarize with AI

AI governance tools serve four production jobs: model registry, GRC policy, AI inventory, and runtime request control. This comparison shows the record each category creates, the regulatory evidence it can support, and the production control a regulated program still needs for each LLM request.

Compliance & Regulationai-governanceai-governance-toolscomplianceeu-ai-actvendor-evaluationprocurement
AI Governance Tools Comparison: Where Each Category Sits and Which Obligation It Closes

An AI governance tool earns its place when a buyer can retrieve the record it creates after a production request: lineage, a policy approval, an inventory finding, or a decision tied to that request. A flat vendor list hides that difference. This comparison maps four categories to their evidence and shows the production gap each category leaves in an LLM deployment.

I will cover model registries and GRC policy platforms, then posture scanners and runtime enforcement layers. For each category, I will name the record it creates and the production test that separates meaningful coverage from a feature checklist. The regulatory framing starts with the EU AI Act and Fannie Mae LL-2026-04, then uses NIST AI RMF and ISO 42001 for control context.

TL;DR

  • A model registry records artifacts and lineage, while a GRC platform records policy approvals and attestations.
  • An inventory scanner identifies AI services in use, while runtime enforcement records a decision for each routed LLM request.
  • A production review should trace one authenticated request through policy evaluation and retrieve the decision evidence before selecting vendors.

Shape A: model registries and MLOps catalogs

Shape A products track model artifacts, training lineage, and promotion metadata. The category includes MLflow, Weights & Biases, cloud MLOps catalogs from Amazon SageMaker, Google Vertex AI, and Azure Machine Learning, plus observability-leaning products such as 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 offerings with AI modules (Wiz AI-SPM, Orca, Lacework), CASB services with AI feeds, and SaaS discovery tools.

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. Related routing and observability products include Kong, Databricks, Helicone, Portkey, MLflow, and Langfuse. Their deployment topology can overlap, but their policy and audit surfaces differ.

The obligation this shape closes is the per-decision recording requirement under EU AI Act Article 12. Article 19 addresses provider record-keeping, while deployer retention appears in Article 26(6). The same request-level evidence can support the Fannie Mae LL-2026-04 disclosure obligation, the Manage 4 expectation under NIST AI RMF, and ISO 42001 operational controls. 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).

Production control selection

A regulated enterprise commonly combines runtime control with its existing model-governance and inventory systems. The exact mix follows the evidence gap rather than a calendar countdown. 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 starts with a request-flow test: identify a real caller, trace one HTTP request to its model endpoint, apply a policy, and retrieve the resulting decision record. A registry, GRC platform, and inventory scanner can supply valuable evidence around that flow. The runtime layer supplies the record of the decision itself.

DeepInspect

DeepInspect is a runtime enforcement layer. It sits inline on the HTTP path between authenticated users or agents and an 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 supports request-level evidence for EU AI Act Article 12, Fannie Mae LL-2026-04, NIST AI RMF Manage 4, ISO 42001 operational controls, and HIPAA audit controls within the traffic that actually traverses the proxy.

The deployment review should start with a production request and its evidence record. That exercise exposes whether the team needs a registry integration, a GRC workflow, an inventory feed, a runtime control, or a combination.

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

Frequently asked questions

Can a single vendor cover all four shapes?

A small number of vendors claim coverage across multiple shapes. Runtime enforcement depends on HTTP-boundary placement, audit write-path independence, and fail-closed defaults. GRC platforms need a deep control catalog and workable attestation workflows. A model registry succeeds on 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?

Start with the runtime request-path test, then plan the approval and deployment sequence around the buyer's own release process. Registry, GRC, and posture-scanner programs can run in parallel, while runtime enforcement needs enough time for identity mapping, policy review, and evidence validation before production traffic moves through it.

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.