Azure AI Governance

Ask "how do you govern AI in Azure" and most answers name one product — usually whichever one the person answering happens to work in. The honest answer needs four: a policy engine that writes the rules, a resource type those rules actually target, a platform to build and operate the AI on, and a data-governance layer that watches everything the other three produce. Miss one and the picture is incomplete — a tenant with airtight Azure Policy assignments and no Purview coverage still has no idea what its agents are doing with sensitive data.

None of these four services were designed as a single product. They converge because Azure Policy governs the resource Foundry is built on, and Purview watches what Foundry produces — not because a diagram says they should.

How the Four Pieces Connect

Policy governs the platform; the platform is built on a resource Policy can target directly; Purview watches the platform's output; and one screen — Foundry's own control plane — is where all three signals actually surface together.

The 360° Governance View

Four different questions, four different answers — confusing them is the most common way people misjudge what's actually covered.

Azure Policy — the Enforcement Engine

Azure Policy doesn't build or run anything — it decides what's allowed to exist, and what happens when something doesn't comply. Built-in policies cover the obvious guardrails (no public access, no local auth, encryption with a customer-managed key); custom policies handle the organization-specific ones, like a model allowlist or a connection-category limit, authored as JSON. What makes it enforcement rather than documentation is the effect attached to each rule — deny blocks the non-compliant resource outright, audit just flags it, modify auto-remediates, and DeployIfNotExist can provision a missing control automatically.

Microsoft Foundry — Build and Operate

Foundry is the actual workbench: the model catalog, the Agent Service, prompt flow and fine-tuning, organized into hubs and projects. That's the "build" half. The "operate" half — asset inventory, guardrail policy assignment, quota and admin management, fleet-wide observability — is what turns a collection of deployed models into something a security team can actually reason about.

Guardrails — Content Safety

Both halves rely on the same guardrail layer. Harm-category detection covers violence, hate, sexual content, and self-harm, each with its own configurable severity threshold. Prompt Shields catch both direct and indirect injection attempts. Checks run at every stage of a call — user input, tool call, tool response, and final output — and an AI red-teaming agent adversarially tests a deployment before it ever reaches production.

Cognitive Services — the Resource Underneath

Foundry is a developer experience layered on top of a specific Azure resource type — Microsoft.CognitiveServices/accounts. This is the detail that makes Azure Policy's role concrete: policy doesn't govern "Foundry" as an abstraction, it governs this resource type directly, the same way it governs a storage account or a key vault. Anyone writing a custom policy for AI workloads needs to know this is the actual target.

Microsoft Purview — the Data Governance Overlay

Everything above this line assumes the AI is behaving as intended. Purview is the check on that assumption — it doesn't build or enforce, it watches. DSPM for AI discovers AI apps across the tenant (Foundry, Copilot, and beyond) and scans what's actually flowing through prompts and responses for oversharing risk. DLP extends the organization's existing data-loss policies into AI interactions specifically. Compliance Manager maps whatever Purview and Policy are already enforcing back to named frameworks, and audit logging keeps the interaction history discoverable and subject to retention rules like everything else in the tenant.

Why the Convergence Point Matters

Governance tooling fails in practice for a boring reason: the evidence that something is under control is scattered across four consoles nobody checks together. Foundry's own control plane is the one screen built to close that gap — a policies tab that shows enforcement rules and live compliance status, an assets tab that ties a policy violation to the specific deployment that caused it, a guardrails tab that surfaces coverage gaps across deployments instead of per-deployment, and a security posture tab that puts Defender for Cloud and Purview's enablement status on the same pane. None of that is a new capability — it's the same four services, just finally visible in one place instead of four.