Add files via upload

Author: v-mangrandhi

learn-pr/wwl-azure/apply-governance-controls-ai-ready-workloads/includes/2-discover-classify-ai-infrastructure-assets.md

@@ -0,0 +1,34 @@
+Before you can govern AI infrastructure, you need visibility into what exists across your Azure environment. Consider a scenario where your data science teams have deployed Azure OpenAI Service instances, Azure Machine Learning workspaces, and storage accounts for training datasets across multiple subscriptions. Without a centralized catalog, your governance team can't answer fundamental questions: How many AI models are running in production? Which datasets contain regulated data? Who owns each resource?
+
+Microsoft Purview Data Map solves this discovery challenge by automatically scanning your Azure subscriptions and cataloging AI resources. Unlike manual inventory spreadsheets that become outdated within days, Purview maintains a real-time catalog that reflects your actual environment. The Data Map discovers four critical categories of AI assets: Azure OpenAI Service deployments, Azure Machine Learning models and endpoints, training datasets in storage accounts, and inference pipelines. Each discovered asset appears in Purview's unified catalog with metadata including resource location, creation date, and ownership information.
+
+## Automated discovery process
+
+Purview's discovery engine integrates with Azure Resource Graph to enumerate AI resources across subscriptions you specify during setup. When you register an Azure subscription as a data source in Purview, the scanner queries Resource Graph APIs to identify Azure OpenAI Service instances, Azure Machine Learning workspaces, and storage accounts tagged for AI workloads. This automated approach eliminates the manual effort of tracking resources across environments. The scanner runs on a schedule you configure—typically daily for production environments—ensuring your catalog stays current as teams deploy new models or decommission old ones.
+
+Once discovered, each asset requires classification to support governance decisions. With this foundation of discovery in place, you need a systematic approach to categorizing the sensitivity of your AI resources and the data they process.
+
+## Classification schemas and sensitivity labeling
+
+Purview applies classification rules to AI assets using built-in and custom schemas that identify sensitive data patterns. For training datasets stored in Azure Data Lake Storage or Blob Storage, Purview's automated classification engine scans file contents looking for patterns that match regulatory categories: credit card numbers, social security identifiers, healthcare records, or personal data. When the classifier detects sensitive patterns, it applies appropriate labels automatically—eliminating the manual review burden that slows governance initiatives.
+
+Building on automated classification, you can integrate information protection sensitivity labels that propagate throughout the AI lifecycle. Suppose your organization defines a "Confidential - Customer Data" label for datasets containing personal data. When Purview classifies a training dataset with this label, the protection follows the data through transformation pipelines. The Azure Machine Learning model trained on that dataset inherits the sensitivity label, as does the inference endpoint that serves predictions. This cascading protection ensures governance controls remain consistent from source data to production deployment.
+
+At the same time, you maintain flexibility for AI assets that require manual classification decisions. Custom classification rules let you define business-specific patterns—for example, identifying proprietary product designs or internal financial forecasts in training data. You create these rules using regular expressions or keyword matching, then assign them to scan policies that target specific storage accounts or resource groups. This becomes especially important when your organization's data sensitivity extends beyond regulatory categories into competitive intellectual property.
+
+:::image type="content" source="../media/confidential-sensitivity-label-applied-train-dataset.png" alt-text="Diagram showing how a Confidential sensitivity label applied to a training dataset automatically propagates to derived models during training.":::
+
+## Integration with governance workflows
+
+The classified asset catalog becomes the foundation for downstream governance capabilities. With assets discovered and labeled, you can enforce access controls based on sensitivity. For example, your policy might restrict "Highly Confidential" AI models to private network access only, preventing public internet exposure. Purview's integration with Azure role-based access control (RBAC) lets you map sensitivity labels to permission requirements: data scientists can read training datasets labeled "Internal Use Only," while only designated model reviewers can access "Confidential" model artifacts.
+
+Consider what happens when a new data scientist joins your team. Without Purview classification, they might accidentally use a dataset containing customer personal data for an experimental model, creating compliance risk. With classification in place, the dataset's "Confidential" label triggers an approval workflow before granting access. The data scientist submits a justification, their manager approves, and Purview logs the decision for audit purposes. This automated governance reduces security team workload by 40-60% compared to manual access request processing.
+
+Now that you understand how Purview discovers and classifies AI assets, you're ready to explore how Azure Policy enforces guardrails that prevent noncompliant deployments before they reach production. The combination of asset visibility and proactive policy enforcement creates a defense-in-depth governance strategy.
+
+:::image type="content" source="../media/microsoft-purview-data-map.png" alt-text="Diagram showing Azure subscriptions feeding into Microsoft Purview Data Map through Azure Resource Graph.":::
+
+*Microsoft Purview Data Map discovering and cataloging AI assets across Azure environments with automated classification and sensitivity labeling*
+
+
+

learn-pr/wwl-azure/apply-governance-controls-ai-ready-workloads/includes/3-implement-azure-policy-guardrails-workloads.md

@@ -0,0 +1,47 @@
+Asset discovery and classification provide visibility, but visibility alone doesn't prevent compliance violations. You need enforcement mechanisms that stop noncompliant AI deployments before they reach production. Consider a real scenario: your organization's compliance team mandates that all AI training data remains within European Union regions to satisfy regional data residency requirements. Without policy enforcement, a developer might unknowingly deploy an Azure OpenAI Service instance in East US using a training dataset from EU-based storage, creating an immediate compliance violation that triggers regulatory scrutiny.
+
+Azure Policy transforms compliance requirements from documentation into executable guardrails. Unlike manual approval workflows that create bottlenecks and delay innovation, Azure Policy evaluates every resource deployment request automatically and enforces governance standards in real time. When a developer attempts to deploy an AI resource, Azure Policy evaluates the deployment against your defined rules before provisioning begins. Compliant deployments proceed immediately, while noncompliant requests are blocked or flagged for review—reducing governance team workload by 50-70% compared to manual review processes.
+
+## Policy definitions for AI governance
+
+Azure Policy operates through policy definitions that specify governance rules and their enforcement mechanisms. For AI infrastructure, you typically implement four categories of policies: data residency controls, encryption requirements, network isolation mandates, and cost management tags. Each policy definition includes a condition that describes the desired state and an effect that determines enforcement behavior. Understanding these policy patterns helps you design governance controls that balance security with developer productivity.
+
+
+## Data residency enforcement for AI deployments
+
+Organizations can use data residency policies to ensure AI services are deployed only within approved geographic regions. For example, if an organization operates in Europe and must comply with regional data residency requirements, it can define a policy that evaluates the deployment location of Azure OpenAI Service and Azure Machine Learning workspaces. Only regions such as West Europe, North Europe, and France Central are allowed, while deployment requests targeting regions like East US are automatically denied with a compliance-related error message, preventing noncompliant resources from being created.
+
+- Restricts AI deployments to approved geographic regions  
+- Evaluates resource location during deployment requests  
+- Blocks noncompliant regions before violations occur  
+
+## Encryption policy enforcement for AI assets
+
+In addition to geographic controls, encryption policies help protect AI data both at rest and in transit. Azure supports platform-managed keys, customer-managed keys, and double encryption, allowing organizations to define security requirements based on data sensitivity. For instance, a policy can require customer-managed keys for Azure Machine Learning workspace storage accounts that store training data classified as Confidential or higher, denying deployments that rely solely on platform-managed encryption until stronger protections are configured.
+
+- Enforces encryption standards based on data classification  
+- Supports multiple encryption models, including customer-managed keys  
+- Blocks deployments that do not meet required encryption settings  
+
+
+## Policy effects and enforcement strategies
+
+Azure Policy supports five primary effects that determine how policies enforce governance rules, and choosing the right effect requires understanding your organization's risk tolerance and operational maturity. The Deny effect blocks noncompliant deployments entirely, providing the strongest enforcement but potentially frustrating developers who lack context about compliance requirements. The Audit effect logs noncompliant deployments without blocking them, creating visibility for governance teams while allowing work to continue. This becomes your preferred approach during policy testing phases.
+
+Consider a staged rollout strategy for new governance policies. You start with Audit effect to measure current compliance levels without disrupting workflows. After two weeks of auditing, your compliance dashboard shows that 23% of AI resource deployments violate data residency rules—mostly due to developers using default region settings in deployment templates. With this baseline established, you communicate the upcoming enforcement change to development teams, provide updated templates with correct region configurations, and switch the policy effect from Audit to Deny. This gradual approach reduces friction while establishing clear compliance boundaries.
+
+At the same time, the DeployIfNotExists effect enables automated remediation that fixes noncompliant resources without manual intervention. Suppose your security policy requires all Azure OpenAI Service instances to use private endpoints that restrict access to your corporate virtual network. Rather than blocking deployments that lack private endpoints, your DeployIfNotExists policy automatically provisions the required private endpoint configuration when developers create new OpenAI instances. This approach maintains security standards while removing configuration burden from developers, reducing deployment time by 40% compared to manual network setup.
+
+## Policy scope and exemption management
+
+Policies apply at specific scopes within your Azure hierarchy: management groups, subscriptions, or resource groups. This hierarchical model lets you implement different governance controls for production versus development environments. For production subscriptions, you enforce strict policies with Deny effects that block any compliance violations. For development and testing environments, you use Audit effects that provide visibility without blocking experimental work. Your policy assignments cascade down the hierarchy—a policy assigned at the management group level automatically applies to all child subscriptions and resource groups.
+
+However, this changes when legitimate business cases require temporary exemptions from governance policies. Suppose your data science team needs to deploy an Azure OpenAI Service instance in East US for a three-month collaboration with a US-based partner, despite your standard European data residency requirement. Rather than disabling the policy globally, you create a scoped exemption that allows this specific deployment while maintaining protection everywhere else. The exemption request flows through an approval workflow: the data scientist documents the business justification, their manager approves, the compliance team validates legal requirements, and finally an exemption is granted with an expiration date. Purview logs all exemption activity for audit trails.
+
+Now that you understand how Azure Policy enforces governance guardrails at deployment time, you're ready to explore how Microsoft Purview captures data lineage that traces AI workload dependencies from source data through training to production inference.
+
+:::image type="content" source="../media/azure-policy-enforcement-flow.png" alt-text="Diagram showing a policy definition assigned at management group level that covers production and development subscriptions.":::
+
+*Azure Policy enforcement flow for AI infrastructure provisioning across production and development environments with different policy effects*
+
+