CONCEPT Cited by 4 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:
- Centralised security and audit.
- One identity substrate for all tools (single SSO across coding agents, MCP servers, internal services).
- Every request audit-logged in a single store (Unity Catalog on Databricks' instance; Workers KV / D1 + AI Gateway logs on Cloudflare's).
- Per-provider credentials injected server-side — no keys on user laptops (BYOK).
- Single bill + cost controls.
- Inference capacity available from a first-party source (Databricks Foundation Model API; Cloudflare Workers AI) with external capacity bring-your-own supported.
- One bill, one budget model, budgets enforced per identity, not per tool — patterns/unified-billing-across-providers.
- Gateway sees all traffic → quotas are portable across whichever tool the developer picks.
- Unified observability.
- All tool telemetry flows into one observability store (Unity-Catalog-managed Delta tables via OpenTelemetry on Databricks; AI Gateway logs + Workers Analytics on Cloudflare).
- Joinable with business data (HR / PR-velocity / rate-limit capacity-planning signals).
- 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/data-centric-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 (patterns/automatic-provider-failover) + buffered resumable streaming (patterns/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 (concepts/governance-travels-with-resources). See concepts/four-pillars-of-agent-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.
Related¶
- concepts/coding-agent-sprawl — the forcing function.
- concepts/byok-bring-your-own-key — the secrets posture.
- concepts/observability — the broader observability-plane discipline the third pillar specialises.
- patterns/ai-gateway-provider-abstraction — the enabling pattern.
- patterns/central-proxy-choke-point — posture.
- patterns/telemetry-to-lakehouse — Lakehouse-side shape.
- patterns/unified-billing-across-providers — cost shape.
- systems/unity-ai-gateway — Databricks instance.