Collibra AI Governance: Where the Data Intelligence Approach Ends and Request-Level Enforcement Begins

Collibra AI Governance extends the Collibra Data Intelligence Platform with capabilities for AI use case catalogs, model documentation, policy management, stakeholder workflows, and integration with the existing Collibra data catalog. The product positions itself as the governance layer that connects AI assets to the underlying data, the policies that apply, and the people responsible.

The product is well-scoped for the metadata layer over an enterprise's AI assets. The architectural question is whether metadata governance is sufficient on its own or whether a separate enforcement layer at the AI request boundary is also required. The answer is the same as it is for any data-catalog-centric AI governance product: the two layers cover different surfaces and a defensible architecture has both. I want to walk through what Collibra covers, where its boundary ends, and what an enforcement layer adds.

What Collibra AI Governance covers

The product is structured as an extension of the Collibra Data Intelligence Platform. Four capability areas track to the way data-catalog teams already work.

AI use case catalog

A central catalog of AI use cases in the organization. Each use case has a stakeholder map, an intended-use description, a risk classification, a status (proposed, under development, in production, retired), and a lineage trail to the data assets and models the use case depends on. The catalog answers "what AI is happening at this enterprise" from the use-case perspective.

Model documentation

Model cards, intended-use statements, evaluation reports, and risk assessments captured against each model in the use case catalog. The documentation aligns with EU AI Act Article 11 technical documentation expectations and with NIST AI RMF documentation practice.

Policy management

A policy catalog that maps regulatory and internal policies to the AI use cases they apply to. EU AI Act Article 14 human oversight mapped to use cases that trigger it. NIST AI RMF MEASURE function mapped to the measurement obligations per use case. Internal acceptable-use policies mapped to use cases per business function.

Stakeholder workflow

Approval workflows that move use cases through review gates. The risk officer approves the risk classification. The data steward approves the data lineage. The model risk committee approves the deployment. The product captures who approved what and when, producing an audit trail at the workflow level.

The combined product gives a data governance team a structured surface to track AI use cases alongside the data assets they were already cataloging. The integration with the existing Collibra deployment is the strongest part of the value proposition.

What Collibra AI Governance does not cover

The product operates at the metadata layer. The boundary ends at the catalog. Three categories of work sit outside the boundary.

The per-request decision

A production AI use case serves requests. Each request involves a specific user, a specific prompt, a specific data context, and a specific policy state at the moment the request lands. The per-request decision (allow, allow with redaction, deny, route to human oversight) is not the catalog's concern. The decision is made at the AI request boundary, between the calling user or agent and the model API.

Collibra catalogs the use case, the policy, and the approval. The catalog does not evaluate whether this specific request should reach the model. That evaluation happens in the enforcement layer.

Real-time enforcement at machine speed

Mandiant's M-Trends 2026 report found median attacker handoff time of 22 seconds. Real-time enforcement against AI traffic must happen at that tempo. A metadata catalog operates at human-workflow tempo (minutes to days). The two layers are designed for different time scales.

The independent audit trail at the request level

The audit trail Collibra produces is at the workflow level: who approved the use case, when, with what justification. The audit trail at the request level (what specific prompt was sent, by whom, against what policy, with what outcome) is not the catalog's surface.

The request-level audit trail satisfies EU AI Act Article 12 record-keeping. The workflow-level audit trail satisfies the Article 11 technical documentation obligation. Both are required; they cover different obligations.

Coverage of AI traffic outside the catalog

AI use cases that are not in the catalog do not produce records in Collibra. Shadow AI by definition is outside the catalog. SaaS-embedded AI features that the catalog has not been told about are outside. Internal copilots and agents stood up by engineering teams without going through the workflow are outside.

The catalog can only govern what is in it. The enforcement layer at the AI request boundary sees every request the enterprise produces, including those the catalog has not registered yet.

What an enforcement layer adds

A policy enforcement layer at the AI request boundary fills the gaps Collibra leaves uncovered.

Per-request policy decision

Every AI request is evaluated against identity, role, prompt-level classification, model authorization, and organizational policy. The decision is deterministic, made at the AI request boundary, and recorded.

Coverage of all AI traffic

The enforcement layer sees every AI request the enterprise makes, registered in the catalog or not. The visibility comes from the architectural position (in front of all LLM endpoints) rather than from the catalog's inventory completeness.

Independent audit record at the request level

The enforcement layer writes the per-decision audit record. The record is signed, identity-bound, and survives application crash. Regulators get an independent record at the request level that complements the workflow-level record Collibra produces.

Machine-speed enforcement

The enforcement layer operates at sub-50ms p99 overhead. The decision is made before the model receives the request. The cycle time matches the speed of AI traffic, not the speed of metadata workflows.

How the two layers fit in practice

A mature enterprise AI architecture uses both layers.

Collibra owns the metadata catalog: use case inventory, model documentation, policy mapping, stakeholder workflow. The output is the body of evidence that the organization knows what AI it is running, has documented it, has mapped policies to it, and has approval trails for the deployment decisions.

The enforcement layer owns the AI request boundary: per-request policy evaluation, identity-aware decisions, per-decision audit records. The output is the body of evidence that each request was governed at the moment it was made.

The two layers feed each other. The use case classification in Collibra informs the policy rules at the enforcement layer. A use case classified as high-risk in Collibra triggers stricter policy at the enforcement layer. The enforcement layer's per-decision records flow back into Collibra as production evidence against the documented use case.

The mistake to avoid is treating either layer as sufficient on its own. A catalog without enforcement leaves the AI request boundary uncovered. An enforcement layer without a catalog produces records that have no organizational context.

Regulatory framing

EU AI Act Article 11 technical documentation expects model and use case documentation. Collibra produces it.

EU AI Act Article 12 record-keeping and Article 19 automatically generated logs expect request-level records with identity context. The enforcement layer produces them.

EU AI Act Article 14 human oversight applies at both layers: workflow-level oversight in the catalog and request-level oversight at the enforcement boundary.

EU AI Act Article 26 deployer obligations span both surfaces: monitor the system (catalog plus enforcement), assign human oversight (catalog), maintain Article 19 logs (enforcement layer).

NIST AI RMF's MAP, MEASURE, and MANAGE functions map across both layers. MAP and MEASURE align with the catalog work. MANAGE aligns with the enforcement layer.

DeepInspect

DeepInspect is the policy enforcement layer at the AI request boundary, complementary to data catalog products like Collibra AI Governance. The two layers cover different surfaces. Together they produce the body of evidence regulators and auditors expect.

DeepInspect is model-agnostic. The same enforcement layer sits in front of every LLM endpoint the enterprise calls. The use case inventory in Collibra is the workflow-level record; the per-decision audit record from DeepInspect is the request-level record. The two records reference each other through identity and use case identifiers.

Want to see this running on your stack? Book a technical deep dive at deepinspect.ai.