GOVERNANCE & SECURITY

Your AI workloads are running. Do you know what they can access, what they cost, and who owns them?

Most organizations started deploying AI the same way they started with cloud in 2015 - fast, decentralized, each team making its own infrastructure decisions. Cloud took a decade to reach governance maturity. AI is moving faster, with more data exposure, and the infrastructure debt arrives sooner. Microsoft's current Cloud Adoption Framework guidance says AI workloads should use existing Azure landing zones and Azure Policy rather than bypass normal platform engineering standards. A pattern is a pre-configured environment a new team provisions instead of designing from scratch - network isolation, identity, cost tagging, and security baseline inherited before the first line of code runs. The platform has the controls. The question is whether the organization has operationalized them.

Research Area7 topicsGovernance & Security

Topics in this research area

Accountability & Agents

Who is responsible when an AI agent makes a wrong decision at scale.

→02

Regulatory Compliance

EU AI Act, NIST AI RMF, and sector requirements on Microsoft 365.

→03

Data Protection

Classifying and monitoring sensitive data before AI can reach it.

→04

AI Foundations

Governance architecture before agents proliferate across your environment.

→05

The Microsoft Control Plane

How Microsoft is becoming the control plane for enterprise AI governance.

→06

The Examiner Scenario

What an examiner will ask when your AI governance posture is tested.

→07

Governance Readiness Snapshot

A concise view of whether controls, ownership, and oversight are keeping pace.

→

THE PROBLEM

What actually happens when AI workloads run ahead of infrastructure governance

These are not hypothetical risks. They are the patterns that appear consistently when organizations deploy AI workloads without established infrastructure.

What breaks first

Cost control, security consistency, and data accountability all drift before leadership realizes the foundation is missing.

These scenarios are the recurring shape of AI infrastructure debt once teams start provisioning independently.

Abstract foundation image showing weight-bearing infrastructure prepared before load arrives.

Active scenario

Every team is solving the same problem from scratch

The data engineering team built their own Azure AI Foundry project with their own network configuration. The product team built a different one a month later and made different security decisions. Nobody compared notes. Three months in, you have four separate AI environments, none of them consistent, and a new team asking how to set up theirs. Microsoft's current Cloud Adoption Framework guidance recommends policy-driven governance and reusable landing zone patterns as the remedy. The answer to "how do we set up AI infrastructure" should not depend on which engineer a new team happens to ask. Without shared patterns, it always does.

Scenario 1 of 7

THE PATTERNS

What enterprise-grade AI infrastructure governance looks like in practice

A pattern is a template that a new team uses on day one to get a working, secure, governed AI environment without making the decisions from scratch. Here is what each pattern covers.

Abstract landing zone image showing a defined perimeter before workload activity begins.

Landing zones

Microsoft's current Cloud Adoption Framework guidance says organizations do not need a separate AI landing zone. AI workloads can use the existing Azure landing zone architecture and its design areas for identity, networking, security, management, governance, and platform automation. AI-specific controls are added through the same policy-driven foundation. When a new team provisions from a landing zone template, it inherits the platform decisions instead of recreating them from scratch.

Microsoft Foundry project templates with managed network isolation

Private endpoints configured by default, no public compute exposure

Entra-based identity and access configured at environment creation

Resource group structure that maps to cost attribution from day one

Pattern 1 of 4

FOUNDATION WORK

How organizations close the gap between platform capability and platform governance

Microsoft's AI platform guidance now treats governance, secure networking, identity, monitoring, and operational management as connected parts of the workload foundation. The Cloud Adoption Framework says existing Azure landing zones are sufficient for AI workloads and includes current guidance for AI adoption, governance, security, and operations. Microsoft Entra Agent ID adds a distinct identity and lifecycle model for agents, while Agent 365 provides an enterprise control plane for observing, governing, and securing agents. The platform capabilities are real. The gap is between what the platform makes possible and what organizations have actually configured and enforced. Closing that gap follows a consistent sequence.

Abstract inventory image showing existing AI infrastructure catalogued before planning.

Step 1

Assess what already exists

Before designing anything, the current AI infrastructure needs to be inventoried. What Azure environments exist and how they were configured. What network isolation decisions were made and by whom. What data connections are undocumented. What costs are unattributed. What SDK versions workloads depend on. Azure Machine Learning SDK v1 support ended June 30, 2026, so any v1-dependent workload requires an owner, migration plan, and explicit remediation record. Which agents are running, under what identities, and whether they are visible in the organization's agent-management surfaces. The output is a concrete map of what exists, what is outside a defensible governance boundary, and where the gaps are.

Inventory of all AI deployments across Azure subscriptions

Configuration review against Microsoft's AI security baseline

Data connection audit for documentation and scope

SDK and dependency version assessment for upcoming EOL risk

Cost attribution gap analysis

Step 2

Design patterns that match the environment

An organization is not a blank sheet. Existing Azure Landing Zones may already exist, or they may not. Existing Entra policies may already exist, or they may not. Teams may already be building on Microsoft Foundry, or they may just be starting. The patterns need to work with what exists. Rebuilding the cloud environment to adopt AI governance is not required. The AI-specific layer sits on top of what already works.

Landing zone template design for the subscription and network topology

Security baseline aligned to Microsoft's AI security benchmark

Data pattern design for the specific enterprise data sources

Cost attribution model that fits existing FinOps practices

Step 3

Deploy patterns and start using them

Patterns are infrastructure as code. When they are deployed, the result is a set of Bicep or Terraform templates that any team in the organization can use to start a new AI project correctly. Documentation explains how to use them, the first team is trained through the process, and support remains available for the first three deployments.

Landing zone templates deployed using existing Azure landing zone architecture with AI-specific policy overlays - not a separate AI environment

Security controls active, cost tagging enforced, network isolation in place

Runbook for new project provisioning that any team can follow

First team walked through provisioning from the template

Step 4

Let teams run this independently

The goal is not dependency. It is a foundation engineers own and maintain. Every decision is documented and the reason for it is recorded. The templates, runbooks, and pattern library remain in the environment. When Microsoft releases a new Foundry capability or changes a best practice, the team has enough context to update the patterns themselves.

Complete infrastructure as code in the repository, with comments

Decision log explaining every architectural choice

Runbook for ongoing pattern maintenance and updates

30-day availability for questions after handoff

Foundation Blueprint

A governed AI environment should feel repeatable before it feels fast.

Operational View

Starting Condition

Teams arrive with AI demand, not with shared infrastructure decisions.

The foundation exists so identity, network isolation, and cost controls are inherited before a project starts moving quickly.

Controls

Identity, network, cost tagging

Applied once in the pattern instead of re-decided by each team.

Outcome

Faster setup with fewer surprises

Projects inherit the baseline and start from a controlled posture.

Operating Model

Reuse beats rework

The pattern becomes the default path for each new AI workload.

Pattern Sequence

Assess the current estate

Design reusable AI patterns

Deploy and operationalize templates

Hand off ownership with documentation

Baseline

shared starting point for new AI projects.

Drift

Down

less variation in how identity and security get configured.

Ownership

Clear

teams know what they inherit and what they maintain.

Why it works

Teams start from a known-good configuration instead of recreating the same control decisions from scratch.

The result is faster project setup, clearer accountability, and fewer surprises when a pilot starts behaving like production.

WHAT YOU GET

What a working foundation looks like

The deliverables are designed to leave the team with working assets, not just recommendations. Each output is meant to be reused by the next AI project without redoing the design work.

Abstract identity and access image showing authorization decisions before agents reach resources.

Active deliverable

Landing zone templates

Deployable Bicep or Terraform templates for AI workloads. Managed network isolation configured. Entra identity baseline in place. Cost tagging schema enforced. A new team provisions in hours, not weeks, and inherits security defaults without making configuration decisions.

Selected deliverable

01 of 5

RIGHT FIT

When this work is worth doing

Best Fit

When this foundation work becomes urgent

Teams are building AI workloads in Azure and each one looks different

You have had at least one cloud cost surprise tied to an AI project

Security or compliance has flagged AI infrastructure as a gap

You are planning to deploy more AI workloads and want a repeatable starting point

You have been in a situation where nobody could answer 'what data does this AI touch'

Can Wait

When this work can wait

Your AI footprint is a single Copilot deployment with no custom workloads

You already have a platform engineering team actively maintaining AI infrastructure patterns

You are purely using SaaS AI tools with no Azure compute or custom deployments

You have fewer than three AI projects planned in the next twelve months

COMMON QUESTIONS

What people ask before starting

The questions below are the ones that usually come up once teams realize this is infrastructure design work, not just another AI pilot.

No. The landing zone pattern covers the full AI infrastructure stack on Azure: Azure AI Foundry, Azure OpenAI, Azure Machine Learning, and the networking, identity, and storage services they depend on. If you are building AI workloads on Azure, this applies regardless of which specific AI service you are using.

Abstract operating rhythm image showing recurring governance intervals accumulating evidence over time.

AI infrastructure decisions made informally in 2024 and 2025 are becoming the debt organizations pay back in 2026.

The Governance Gap covers enterprise AI governance on the Microsoft stack - infrastructure patterns, Agent 365 governance architecture, Entra Agent ID as the identity foundation for agents, and the specific controls that prevent AI sprawl from becoming a security and cost problem. Agent 365 is generally available for the commercial segment as of May 1, 2026. The control plane for AI governance is more integrated, but the gap remains between platform capability and organizational decisions. New editions publish every Tuesday.

Built on verified Microsoft documentation

Written from 13 years inside enterprise regulatory and biomedical research environments

Updated as the Microsoft platform evolves

Read the Governance Gap Explore all governance research

<- Regulatory Compliance The Microsoft Control Plane ->