AI Policy-as-Code: Deployable YAML Templates for 2026

Most AI governance lives in a PDF. A document someone wrote, the board approved, and three people in the business have actually read. That document does no work. It does not block a paste of customer data into ChatGPT. It does not flag a sensitivity label violation. It does not deprovision an OAuth token when someone leaves the business.

Policy-as-code is the move from governance-as-document to governance-as-configuration. The rules become YAML, JSON, and Bicep. The rules deploy into Microsoft Purview, Conditional Access, and Intune. The rules enforce themselves. This is the approach we use for every AI Governance engagement, and the templates below are the starting point.

Why policy-as-code matters for AI

The reason traditional AI policy fails is not that it is wrong. It is that there is no mechanism to apply it. A staff member at 9pm clearing their inbox does not pull out the AI Acceptable Use Policy PDF and check whether the email they are about to summarise contains personal information. They paste. The data leaves. The policy was correct and irrelevant.

Policy-as-code closes that gap. The classification structure, the DLP rules, the Conditional Access posture, and the vetting register all become deployable artefacts that live in your Microsoft 365 tenant. When the policy changes, the configuration changes. When an auditor asks how your AI controls are enforced, you show them the YAML, not the PDF.

The four artefacts below are illustrative versions of what we deploy. They are written for Australian SMBs running Microsoft 365 with Entra ID identity. They are not turnkey – your data classification framework, tenant configuration, and risk appetite will need to be reflected in the values. But they are close enough to your environment that a competent platform engineer can adapt them in an afternoon.

1. Sensitivity label structure with AI handling rules

This is the foundation. Microsoft Purview sensitivity labels carry through M365 and into the AI control plane. The schema below extends a standard three-tier label model with explicit AI handling rules per label.

sensitivity_labels:
  - name: "AI-Public"
    display_name: "AI - Public"
    description: "Data approved for any sanctioned AI tool"
    parent: null
    settings:
      protection: none
      content_marking: { header: null, footer: null }
    ai_handling:
      approved_tools:
        - claude_enterprise
        - microsoft_copilot_enterprise
        - chatgpt_enterprise
      data_residency: any
      retention_required: false
      
  - name: "AI-Confidential"
    display_name: "AI - Confidential"
    description: "Data requiring zero-retention enterprise AI only"
    parent: "AI-Public"
    settings:
      protection: encrypt_recipients_only
      content_marking:
        header: "AI - Confidential"
        footer: "Subject to AI Acceptable Use Policy"
    ai_handling:
      approved_tools:
        - claude_enterprise
        - microsoft_copilot_enterprise
      data_residency: australia_or_compliant_overseas
      retention_required: zero_retention
      
  - name: "AI-Restricted"
    display_name: "AI - Restricted (PIA Required)"
    description: "Prohibited from AI input without documented PIA"
    parent: "AI-Confidential"
    settings:
      protection: encrypt_specific_users
      content_marking:
        header: "AI - Restricted - PIA Required"
    ai_handling:
      approved_tools: []
      data_residency: australia_only
      pia_required: true

The critical field is ai_handling.approved_tools. This is the bridge between human-readable policy (“AI-Restricted data may not be used with any AI tool”) and machine-enforceable controls. Your DLP rules reference these labels. Your Conditional Access policies reference the approved tool list. Your audit logs surface label violations as policy events.

2. DLP rule for AI endpoint data protection

This rule blocks PII uploads to unsanctioned AI endpoints across email, SharePoint, OneDrive, Teams, and Windows endpoints. The trigger is the combination of Australian sensitive information types and the destination AI domain list.

dlp_policy:
  name: "AI Endpoint Data Protection"
  description: "Block sensitive data uploads to unsanctioned AI"
  locations:
    - exchange
    - sharepoint
    - onedrive
    - teams_messages
    - devices
  rules:
    - name: "Block-AU-PII-to-Unsanctioned-AI"
      conditions:
        - content_contains:
            sensitive_info_types:
              - australian_drivers_licence
              - australian_passport
              - australian_tax_file_number
              - australian_medicare_number
              - credit_card_number
              - australian_bank_account
        - destination_url_match:
            - "*.chatgpt.com"
            - "*.openai.com"
            - "*.perplexity.ai"
            - "*.character.ai"
            - "*.midjourney.com"
            - "*.suno.ai"
            - "*.poe.com"
      actions:
        - block_access: true
        - notify_user: true
        - notify_admin: true
        - log_to_purview: true
      user_notification:
        subject: "AI policy violation: sensitive data block"
        body: |
          The content you attempted to share contains Australian personal
          information that may not be sent to this AI tool. Use the
          approved AI platform via your SSO portal for sensitive content.
          Contact IT if you need help.

The endpoint list is the part that needs the most maintenance. New consumer AI services launch monthly. We refresh ours on a monthly cadence and ship the updated list to clients as part of the AI Governance service. If you are running this internally, calendar a recurring review.

3. Conditional Access policy for unsanctioned AI services

Conditional Access in Microsoft Entra ID lets you block sign-ins to unsanctioned AI services from corporate identities. This is the second layer of defence after DLP. Even if a staff member tries to sign in with their work email to ChatGPT consumer, the sign-in is blocked at the identity provider.

{
  "displayName": "CA - Block unsanctioned AI services",
  "state": "enabled",
  "conditions": {
    "applications": {
      "includeApplications": [
        "0000000d-0000-0000-c000-000000000000"
      ],
      "_comment_apps": "Replace with App IDs of unsanctioned AI services from Entra app gallery, or use cloud app filter"
    },
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["AI-Approved-Override-Group"]
    },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

The override group is intentional. There will always be staff with a documented business need that sits outside the approved tool list. The CA policy provides the audit trail: who was granted the exception, when, and by whom. The exception is not the absence of governance. The exception is the governance.

4. AI tool vetting register schema

The register is the artefact that links sensitivity labels, DLP rules, and Conditional Access together. Every tool gets an entry. Every entry includes the risk assessment, the score, the conditions of use, the owner, and the next review date. The schema below is the structure we use.

tools:
  - tool_id: "claude_enterprise"
    name: "Anthropic Claude Enterprise"
    vendor: "Anthropic"
    status: approved
    risk_assessment:
      data_retention: zero_retention_enterprise
      data_residency: us_aus_eu_options
      authentication: sso_entra_id
      admin_controls: full_workspace_management
      certifications: [soc2_type_ii, iso_27001]
      iso_42001_aligned: in_progress
      transparency: published
      vendor_viability: high
    score:
      total: 32
      threshold: 28
    conditions_of_use:
      approved_data_classes: ["AI-Public", "AI-Confidential"]
      prohibited_data_classes: ["AI-Restricted"]
      use_cases:
        - "document drafting and review"
        - "data analysis and modelling"
        - "internal communications drafting"
    governance:
      tool_owner: "Chief Operating Officer"
      review_date: "2026-11-24"
      review_frequency: "6_monthly"

The register lives in source control. Changes are pull requests with reviewers. Status transitions (approved to conditional, conditional to prohibited) are auditable events. This is not how most businesses run their AI governance today. It is how it will need to run by the time the December 2026 Privacy Act amendments require disclosure of substantially automated decisions.

What this stack does not give you

Three honest caveats.

First, this is the technical control layer. It does not replace the seven-pillar governance framework covered in our AI Governance Australia guide. The framework defines what good looks like. The YAML defines how to enforce part of it. You need both.

Second, this stack covers Microsoft 365. It does not extend to AI agents reaching into Xero, Salesforce, or HubSpot. Cross-platform AI governance needs additional architecture, which we cover in why your AI governance stops at M365.

Third, this is a starting point, not a finished product. Your data classification framework, sensitive information types, and risk threshold will be different from the values above. Treat these as templates to adapt, not as drop-in production configuration.

What you should do now

Download the full template library. The four artefacts above are the illustrative versions. Download our full AI Governance white paper for the complete deployable set including the Intune browser extension blocklist, the AI Acceptable Use Policy template, and the Bicep templates for tenant-wide deployment.

Map your existing controls against the four artefacts above. Most Microsoft 365 tenants already have a partial DLP and sensitivity label setup. The gap is usually AI-specific endpoints, AI handling rules on labels, and the absence of a tool vetting register. A two-hour assessment will tell you where you stand.

Book an AI Readiness Assessment. If you want help deploying these into your tenant, our AI Governance service handles the full implementation including DLP tuning, Conditional Access rollout, Purview label deployment, and ongoing maintenance of the AI endpoint list.