Skip to content

CONCEPT Cited by 6 sources

Centralized AI governance

Centralized AI governance is the pattern-concept of routing all of an organisation's AI traffic (LLM calls + tool calls + MCP traffic + coding-agent activity) through one policy surface that owns security/audit, cost controls, and observability — rather than delegating any of those concerns to individual tools or teams.

The three pillars (named in the 2026-04-17 Databricks post)

Databricks frames Unity AI Gateway's value proposition around three pillars. The framing is general, not Databricks-specific, and matches the same-era Cloudflare internal-stack instance:

  1. Centralised security and audit.
  2. One identity substrate for all tools (single SSO across coding agents, MCP servers, internal services).
  3. Every request audit-logged in a single store (Unity Catalog on Databricks' instance; Workers KV / D1 + AI Gateway logs on Cloudflare's).
  4. Per-provider credentials injected server-side — no keys on user laptops (BYOK).
  5. Single bill + cost controls.
  6. Inference capacity available from a first-party source (Databricks Foundation Model API; Cloudflare Workers AI) with external capacity bring-your-own supported.
  7. One bill, one budget model, budgets enforced per identity, not per tool — patterns/unified-billing-across-providers.
  8. Gateway sees all traffic → quotas are portable across whichever tool the developer picks.
  9. Unified observability.
  10. All tool telemetry flows into one observability store (Unity-Catalog-managed Delta tables via OpenTelemetry on Databricks; AI Gateway logs + Workers Analytics on Cloudflare).
  11. Joinable with business data (HR / PR-velocity / rate-limit capacity-planning signals).
  12. patterns/telemetry-to-lakehouse — Databricks' specialised shape.

Why one surface beats three surfaces

  • Security review is O(1), not O(N tools). Each new tool adoption doesn't open a new vendor-security review — it connects to the gateway.
  • Policy migration cost is constant. When frontier models ship weekly, repointing the gateway is one config change, not N per-tool config changes.
  • Cross-tool analytics become possible. "Who's using AI?" has a tractable answer when all tools report through one telemetry plane.

Two ingested instances

  • Databricks Unity AI Gateway (sources/2026-04-17-databricks-governing-coding-agent-sprawl-with-unity-ai-gateway) — specialised for coding-agent clients + MCP governance. Substrates: Unity Catalog (audit), MLflow (tracing), OpenTelemetry → Delta tables (metrics), Foundation Model API (first-party inference). The 2026-05-20 Governing AI agents at scale with Unity Catalog post generalises this instance from coding-agent scope to org-wide agent scope and re-frames the same architecture in the four-pillar shape (delegated access / data-centric governance / cost intelligence / open + interoperable). The 2026-05-20 framing adds Pillar 1 (delegated access) and Pillar 4 (open + interoperable) as load-bearing additions to the original three-pillar shape, while compressing the prior security+audit + observability into the unified Pillar 2 (concepts/centralized-ai-governance).
  • Cloudflare internal AI engineering stack (sources/2026-04-20-cloudflare-internal-ai-engineering-stack) — specialised for internal agents + dev tooling. Substrates: Hono Worker proxy, AI Gateway, Cloudflare Access (identity), D1 + KV (user-UUID mapping), Workers AI (first-party inference), Backstage (service catalog as agent context).
  • Cloudflare AI Platform — customer-facing catalog (sources/2026-04-16-cloudflare-ai-platform-an-inference-layer-designed-for-agents) — the customer-facing sibling of Cloudflare's internal instance. Same three pillars realised through the AI Gateway unified-catalog surface: audit via gateway logs + custom metadata; single bill + per-request attribution (patterns/unified-billing-across-providers); observability across 70+ models and 12+ providers from one dashboard. Extends the framing with reliability as a fourth pillar: automatic provider failover (automatic-provider-failover) + buffered resumable streaming (buffered-resumable-inference-stream) make the gateway not only a governance surface but a reliability substrate for agent workloads.

Three-pillar (2026-04-17) vs four-pillar (2026-05-20)

The wiki tracks two compatible framings of centralised AI governance, both Databricks-originated:

Three-pillar (2026-04-17, coding-agent scope) Four-pillar (2026-05-20, org-wide agent scope)
Centralised security + audit (1) Delegated access (three-layer: OBO + Service Policies + Guardrails)
Single bill + cost controls (3) Cost intelligence
Full observability in the Lakehouse (2) Data-centric AI governance (audit + telemetry as a data-governance problem)
— (4) Open and interoperable (governance-travels-with-resources)

The four-pillar version is the superset — Pillar 1 (delegated access) splits runtime access control out as its own pillar with the three-layer composition; Pillar 4 (open + interoperable) promotes framework-agnosticism from an implementation property to a governance property (governance-travels-with-resources). See concepts/centralized-ai-governance for the canonical canonicalisation.

Both converge on the same three-pillar shape. Different substrates; same architecture; all three validate the pattern. The Cloudflare customer-facing instance sharpens the framing with the reliability tier — failover + resumability as gateway-owned concerns, not application concerns.

Compliance-gated routing as an ordering constraint (Concurrence, 2026-09-23)

Centralised governance is usually framed around access, cost, and observability. The 2026-09-23 Concurrence post (sources/2026-09-23-databricks-how-concurrence-governs-clinical-ai-at-a-trillion-token-scal) adds an ordering constraint on top: in a regulated (HIPAA) setting, model selection is compliance-gated before it is cost-gated — "models must first meet the compliance requirements of a workload before Concurrence considers quality, performance or cost." This makes the governance surface's first job eligibility, not optimisation: cost/quality routing (including Unity Gateway Smart Routing) operates only within the compliance boundary each workload establishes.

The concrete enforcement mechanism is a per-workload endpoint resolver that only permits models in the BAA-covered namespace, structurally preventing PHI from being routed to an uncovered model — a single architectural constraint that also protects the highest-stakes path (safety classification for self-harm, suicidal ideation, medical emergencies). This is the regulated-industry specialisation of model-first routing: the caller names a capability, the control plane picks a provider, and the first filter the control plane applies is compliance coverage. See Concurrence for the full deployment and per-tenant isolation (schema + service principal per healthcare org) for how the same governance surface partitions blast radius.

Identity-aware behavioral analytics (Cloudflare, 2026-08-05)

Centralisation makes behavioral governance possible only if the gateway can associate a request with a verified actor. Cloudflare's Access-protected AI Gateway carries cf.user_id from SAML-backed authentication into gateway metadata, which lets User Insights join session cost and behavior to a person or agent. Its detection rule combines a rolling subject-relative p95 with an organisation-wide p99 floor, producing an administrator investigation queue rather than an automatic block. This extends the centralized-governance model from access, billing, and aggregate observability to identity-linked behavioral analytics. (Source: sources/2026-08-05-cloudflare-catching-rogue-ai-behavior-with-identity-aware-analytics)

Merged aliases

  • governance-as-ai-foundation- ml-governance-at-scale- branch-level-governance-propagation
  • data-centric-ai-governance
  • four-pillars-of-agent-governance
Last updated · 766 distilled / 2,225 read