The Market Map: Who Enforces What (and Who Enforces Nothing)
W10 | March 2026
This is The Market Map — a weekly landscape analysis for AI governance practitioners. Each Friday, we map the territory so you can navigate it.
This week: we analyzed 21 governance platforms across Enterprise Architecture (EA), Governance, Risk, and Compliance (GRC), policy-as-code, API governance, and dedicated AI governance. We looked at three questions for each:
How do they store policy? Structured data, prose documents, or code?
Can they enforce it at runtime? Can the platform block or gate an action before execution — or is enforcement manual, integration-dependent, or absent?
Are they pivoting toward AI governance? And if so, from which direction?
The findings confirm what Thursday's analysis mapped from the vendor side: the market is converging on runtime enforcement, but the structural gap between governance registries and execution-time policy remains wide open.
The short version
Of 21 platforms analyzed:
7 have no runtime enforcement. Policy is prose. Compliance is attestation. Enforcement is a human reading a document and deciding whether to act.
5 have partial or indirect enforcement. Monitoring, thresholds, alerting, and integration-dependent hooks — but no deterministic allow/deny decision at execution time.
9 have some form of machine enforcement. But the majority enforce low-level rules (infrastructure, traffic, API design) rather than business-level governance constraints. And several enforce only at design time, not runtime.
Fewer than half can enforce a single rule at runtime. Fewer still can enforce a business policy — the kind a CISO or compliance leader would recognize — at the moment an AI system acts.
How to read the table
The full 21-platform table below maps each platform across four dimensions:
Storage Model: How the platform represents governance objects. "Structured" means typed objects with fields and relationships. "Hybrid" means structured records with prose policy content attached. "Code" means policies are inherently machine-readable.
Machine-Enforceable: Whether the platform can evaluate and enforce rules without human interpretation. "Yes" means deterministic runtime enforcement. "Partial" means some automation but enforcement depends on integrations or human action. "No" means enforcement is manual.
AI Pivot: Whether and how the platform is positioning toward AI governance.
Enforcement Scope: What the platform actually enforces — infrastructure rules, data access, API design, or business-level governance constraints.
Tier 1: EA and GRC Platforms
These platforms store governance well. They enforce it poorly.
Platform | Storage | Enforceable | AI Pivot | Enforcement Scope |
|---|---|---|---|---|
Structured graph (components, relationships, fields) | No — API enables queries, not runtime gating | Early AI for data quality; no AI governance enforcement | None — analysis and guidance only | |
Structured fact sheets with enumerated fields | No — reports and lifecycle checks, not runtime controls | GenAI compliance tracking via fact sheets; MCP server for AI agents | None — outputs are for human action | |
MEGA | Hybrid repository (structured objects + document attachments) | No — workflow-based consistency checks, not policy evaluation | AI for suggestions and impact analysis; no AI governance module | None — semi-automated workflows |
BiZZdesign | Hybrid model repository (ArchiMate, BPMN + text descriptions) | No — modeling rules only; governance policies are documented, not executable | No dedicated AI governance | None — modeling consistency only |
Hybrid (structured policy records + rich-text content) | Partial — automated tasking and control indicators; GRC data can drive external enforcement via API | AI for risk insights; Autonomous Workforce agents embed configurable governance | Workflow-level enforcement; not a runtime policy engine | |
RSA Archer | Hybrid (hierarchical records decomposed from documents + prose) | No — workflows and attestation; policies remain human-readable | No AI governance product | None — cataloging and attestation |
IBM OpenPages | Hybrid (structured risk/control objects + document attachments) | Partial — connectors and automated control testing; core policies require human interpretation | Watson AI assistance; AI governance via external frameworks | Limited — integration-dependent |
Hybrid (GRC records + FairNow AI registries post-acquisition) | No — assessments, risk scoring, evidence collection; no runtime gating | FairNow acquisition adds AI registries and dynamic risk assessments | None — assessment and reporting |
The pattern: Strong catalogs. Structured metadata. Prose policy content. Enforcement is attestation, workflow routing, or "someone reads the policy and decides." These platforms know what the rules are. They cannot make the rules execute.
Tier 2: Policy-as-Code and API Governance
These platforms enforce well. They lack business context.
Platform | Storage | Enforceable | AI Pivot | Enforcement Scope |
|---|---|---|---|---|
Code (Rego policies over structured JSON input) | Yes — runtime allow/deny decisions for any integrated service | Used in ML pipelines; AI pivot via use cases, not repositioning | Infrastructure, authorization, data access — not business policy | |
Code (Sentinel language over Terraform/infra state) | Yes — blocks non-compliant infrastructure changes before apply | Secures AI infrastructure; not marketed as AI governance | Infrastructure policy only | |
Code (managed OPA/Rego with versioning and metadata) | Yes — centralized policy deployment with automated enforcement via OPA | Markets AI security use cases on same foundation | Infrastructure and authorization | |
Code (formal policy language over JSON-like data) | Yes — fine-grained runtime authorization enforcement | Applied to AI via access control; no distinct AI governance product | Authorization — not broader governance | |
Structured config (services, routes, plugins) | Yes — runtime enforcement via gateway plugins | AI governance via API gateway integrations; no separate module | Traffic, authentication, rate limiting — low-level | |
Hybrid (OpenAPI specs + governance rulesets as JSON/YAML) | Yes — design-time linting and blocking of non-compliant APIs | No AI governance pivot | API design compliance — design-time only | |
Hybrid (collections and governance rules as structured JSON) | Yes — design-time enforcement of naming, auth, and security rules | AI features for API design; no AI governance | API design compliance — design-time only |
The pattern: Policies are code. Enforcement is real — deterministic, automated, in the execution or design path. But the rules these platforms enforce are low-level: infrastructure configuration, API design standards, traffic policies, authorization. They do not speak the language of business governance — regulatory obligations, risk thresholds, clinical review requirements, data use restrictions. The enforcement engine works. It has nothing to enforce at the business layer.
Tier 3: AI Governance Vendors
These platforms have the business context. Enforcement is emerging but incomplete.
Platform | Storage | Enforceable | AI Pivot | Enforcement Scope |
|---|---|---|---|---|
Structured registries (models, datasets, risks, controls as typed objects) | Partial — maps use cases to controls and metrics; enforcement via ML pipeline integrations | Native AI governance platform | Risk assessment, compliance mapping — enforcement is integration-dependent | |
Hybrid (structured catalogs + narrative reports) | Partial — monitoring and risk scoring; markets "automatic enforcement" via API/SDK | Native AI governance platform | Assessment, monitoring, emerging enforcement across models and agents | |
Arthur AI | Hybrid (structured metrics and model metadata + narrative reports) | Partial — monitoring thresholds and guardrails; enforcement via CI/CD integration | MLOps-to-AI-governance pivot | Monitoring and alerting — indirect enforcement |
Fiddler AI | Hybrid (structured metrics and explainability artifacts + dashboards) | Partial — threshold-based alerting and integrations | Explainability-to-AI-governance pivot | Monitoring — enforcement is indirect |
The pattern: These platforms understand governance as a domain. They store models, risks, controls, and policies as structured objects — not just documents. But enforcement remains integration-dependent. The platform can define a rule and detect a violation. Whether it can block an action at execution time depends on how tightly it connects to the infrastructure where the action occurs. The registry is strong. The enforcement path has gaps.
Cross-cutting: OneTrust Data Use Governance
OneTrust deserves separate treatment because it is the closest incumbent to bridging the governance-to-enforcement gap.
Data Use Governance converts policy documents into machine-readable labels and pushes enforcement logic — column masking, row filtering — into data platforms like Snowflake and Databricks. Policies become code. Enforcement happens at the data layer. Audit evidence flows from the platform's native logs.
What makes it notable: OneTrust attacks from the data platform side with genuine policy-to-code conversion and real runtime enforcement. This is structurally aligned with where the market needs to go.
Where it stops: Enforcement scope is data access controls. The full range of agent actions and AI-driven decisions enterprises need to govern — clinical recommendations, hiring decisions, content generation, autonomous workflow execution — sits outside the data access layer. OneTrust governs what data AI can see. It does not govern what AI does with it.
The structural gap
Across all 21 platforms, the same gap appears:
EA and GRC platforms store structured metadata about policies, but policy logic remains prose. The rule is something a human reads.
Policy-as-code engines enforce deterministic rules at runtime, but lack business context. The rule is something a machine evaluates — at the infrastructure layer only.
AI governance vendors have registries and assessments with real business semantics, but enforcement is integration-dependent. The rule is structured but not executable.
Runtime security vendors can block actions inline, but enforce low-level policies — not business constraints.
Nobody takes structured business constraints from a governance registry and transpiles them into deterministic policy-as-code for execution-time enforcement. The governance catalog and the policy engine remain disconnected.
This is the bridge the market has not built.
What to watch
This table is a snapshot. The landscape is moving. Three developments will signal whether the gap is closing:
Security vendors ingesting governance registries. If VAST, Lasso, or AccuKnox start consuming structured policy objects — not just infrastructure rules — the enforcement layer gains business context.
AI governance vendors shipping inline enforcement. If Holistic AI or Credo AI move from integration-dependent hooks to deterministic policy evaluation in the execution path, the registry gains runtime authority.
GRC platforms adopting policy-as-code. If ServiceNow, AuditBoard, or IBM OpenPages connect their governance records to OPA, Cedar, or equivalent engines, the catalog gains enforcement capability.
We will update this table as vendors move. Subscribe to The Market Map to receive updates when the landscape shifts — who moved, who didn't, and what it means for your governance stack.
Sources
EA and GRC Platforms
Ardoq Generic Regulatory Compliance Metamodel — Ardoq Help
LeanIX Governance Factsheet for Compliance Assessments — LeanIX Community
ServiceNow GRC Policy & Compliance Management — ServiceNow Docs
ServiceNow AI Governance for Autonomous Workforce — TechTarget
AuditBoard Acquisition of FairNow — AuditBoard
Policy-as-Code and API Governance
Policy as Code Explained — HashiCorp
Governance as Code — Spacelift
Governing Enterprise Data & AI with Policy-as-Code — Ethyca
AI Governance Vendors
Credo AI Responsible AI Governance Platform — UK Government
Credo AI Platform — Credo AI
Govern Every AI Model and Agent Automatically — Holistic AI
Cross-cutting
OneTrust Data Use Governance — OneTrust
Runtime Security and Enforcement
VAST PolicyEngine Analysis — Hyperframe Research
AI Runtime Security — Lasso Security
Runtime AI Governance Security Platforms — AccuKnox