The AI landscape is evolving at a rate that’s outpacing nearly every prior technology wave, including the early internet. Despite the hype cycle, these tools are by no means a panacea. With every model upgrade, new threat vectors emerge: prompt injection, shadow AI, agentic systems taking unscoped actions on real infrastructure. Yet the productivity gains employees are seeing cannot be discounted, which makes it obvious why adoption continues to accelerate even as the risk surface grows.

Which raises the real question: how do organizations implement AI governance in a way that reduces risk without hampering the productivity benefits their teams are already seeing?

Know Your Risk Level

Most organizations treat AI security as a single problem with blanket controls, either too permissive or too restrictive. In practice, AI risk lives on a spectrum, and the controls that matter at each tier are different. The goal is not to slow the builders down; it is to match the right guardrail to the right layer of exposure, so the organization can move fast where it is safe to, and with care where it isn’t.

Tier	Scope	Primary Risk	Primary Controls
Tier 1	Frontier API Consumption — Users interacting with hosted LLMs (Claude, ChatGPT, Copilot) for research, drafting, analysis.	Sensitive data leaving the tenant boundary. Shadow AI. Uncontrolled vendor exposure.	Sanctioned tier with ZDR. Purview DSPM + Endpoint DLP. Entra Conditional Access. AUP and role-based training.
Tier 2	AI-Assisted Development (“Vibe Coding”) — Business users and analysts building apps and automations with AI-generated code.	Hallucinated dependencies. Hardcoded secrets. Unreviewed code reaching production. Supply chain exposure.	Source control with branch protection. Secret scanning + SCA. Human-in-the-loop review. Environment separation.
Tier 3	Agentic Systems — Autonomous or semi-autonomous agents with tool access, API calls, or multi-step task execution.	Blast radius from unscoped actions. Prompt injection chaining into real systems. Identity and privilege abuse.	Scoped workload identities. Least-agency design. Approval gates for high-impact actions. Full audit trails.
Tier 4	Proprietary Model Building & Fine-Tuning — Training, fine-tuning, or hosting models on firm data.	Data poisoning. Model inversion. Sensitive info memorization. Eval drift over time.	Data provenance controls. MLSecOps pipeline. Model registry with signing. Continuous eval + red team.

Most organizations operate in Tier 1 and Tier 2, with a few power users and key roles experimenting in Tier 3. Match the workload to the correct tier based on the classification of the data it touches.

The guiding principle is Data Sensitivity drives inference architecture.

Commercial API with ZDR → Azure OpenAI private endpoints → Dedicated capacity → On-prem → Air-gapped

Build Your Policy and Enforce It

Let me start by saying these principles apply regardless of platform, but the specifics here assume M365 because that’s where most mid-market and enterprise organizations actually live. Also, Microsoft rebrands and restructures these tools frequently; if the exact product names here are slightly different by the time you read this, the underlying capabilities and the principles below still apply.

Your organizational policy is only as good as the mechanism enforcing it. A policy document that says “don’t put sensitive data into ChatGPT” is not a control. It is a wish. If you have no way to monitor when it happens, no way to block an action when it matters, and no way to differentiate between sanctioned tool use and an unsanctioned one, you do not have AI governance. You have a PDF in a SharePoint folder forgotten a week after onboarding.

Good AI policy rests on two pillars. It tells your team what “good” actually looks like, and it gives your security team the telemetry and tools to verify and enforce it. One without the other fails.

What an AI Acceptable Use Policy Should Cover

Keep it practical, keep it short, and do not over-engineer. A policy nobody reads due to complexity is a policy nobody will follow.

At minimum, your AUP should address:

Sanctioned tools list. Be explicit about which AI tools are approved, and what tasks they are approved for. Claude Enterprise for analysis and drafting is different from the free web app, and your policy should make that clear. If a tool is not on the list, it is not approved. Update this list quarterly at minimum, because the landscape moves faster than an annual review cycle.
Data classification rules per tier. Map your organization’s existing data classifications (Public, Internal, Confidential, Restricted, or whatever scheme you use) to what can go into which tier of AI tool. Restricted data does not go into a commercial API, period. Confidential data might be fine in a sanctioned tier with Zero Data Retention (ZDR) but not in a consumer tool. Make this a table your users can actually reference.
Human-in-the-loop requirements for AI-generated code. Any code generated by an AI tool that is destined for production gets reviewed by a human. Full stop. This is the most important control for Tier 2 and it needs to be non-negotiable.
Incident reporting expectations. If someone realizes they pasted client data into the wrong tool, you need them to tell you within a defined window. Make the reporting process blameless and fast. The goal is transparency, not punishment. The faster an incident comes to light, the faster it can be contained.
Consequences for violations. Vague policies get ignored. Be clear about what happens when a policy is broken, while also making sure the response is proportionate. A first-time accidental paste is a learning experience and calls for coaching. A repeated deliberate workaround to defeat guardrails is a different conversation.

An organization’s AUP is a communication document, not a legal document. It should be written in plain language that everyone can understand because if users cannot understand it they cannot follow it.

Enforcement: Where Purview Earns Its Keep

Policy without telemetry is theater. This is where the Microsoft security stack becomes more than a line item on your renewal. The three tools that matter most for AI governance are Microsoft Purview, Endpoint Data Loss Prevention (DLP), and Entra Conditional Access. They each solve a different problem.

Microsoft Purview DSPM gives you visibility. It discovers which AI applications your users are actually interacting with, what data is flowing to them, and where the sensitive information lives that is most at risk of being exposed. This is the foundation. You cannot govern what you cannot see, and for most organizations the first run of DSPM is a wake-up call about just how much shadow AI exposure is already happening. A quick note on the product landscape: as of April 2026, Microsoft is actively rolling out a unified DSPM experience that brings the previously separate DSPM and DSPM for AI capabilities into a single solution, with AI observability and agent governance baked in. The classic experiences remain available and existing policies carry over automatically, but new deployments should target the unified experience.

Endpoint DLP gives you enforcement at the point of exposure. When a user tries to paste a spreadsheet of client account numbers into a browser session with an unsanctioned AI tool, DLP is what stops it. The policies can be tuned from warn-and-allow (solid entry point for early rollout and user education) to outright block (appropriate for your most sensitive data classes). The key is that enforcement happens where the data actually moves, not after the fact.

Entra Conditional Access gives you access control. Who in your organization can reach the sanctioned Tier 1 environment? Under what conditions? From which devices? This is how you make sure your ZDR-protected enterprise Claude or Copilot deployment is the path of least resistance for your users, while consumer tools require added friction to reach. The goal is to make the right thing easy and the wrong thing hard for your users.

Used together, these three tools give you the enforcement loop that turns your policy from a document into a functioning control. They add visibility into what is happening, enforcement at the moment it matters, and access control that shapes behavior before the fact.

What Purview Does Not Do

We need to be honest with ourselves about the limits of the tooling. DSPM is strong at Tier 1 visibility and getting stronger for Tier 2 as Copilot adoption expands. It is not the right tool for Tier 3 agentic risk, where the controls live in workload identity and approval gates rather than data loss prevention. It is not relevant at all for Tier 4 model-building risk, which is an entirely different discipline. Tier 3 calls for agent governance platforms and identity-centric permission controls; Tier 4 calls for MLSecOps tooling.

The Microsoft stack is the right starting point for most organizations because it is already in your environment and it covers the two tiers where most of your real exposure lives. Do not let it become the whole conversation.

The Practical Starting Point

If you are reading this and realizing you do not have any of this in place, here is an order that tends to work:

Enable AI monitoring in Purview DSPM and run it for two weeks before doing anything else. This will give you a baseline, and your findings will inform the rest of your work.
Draft the AUP in parallel, using what you learn from DSPM to ground the policy in actual usage patterns rather than hypotheticals.
Rollout Endpoint DLP in warn-and-allow mode first. Let users see the warnings, understand why the policy exists, and self-correct. Move to block mode for your most sensitive classifications once behavior has adjusted.
Tune Conditional Access to make the sanctioned tier frictionless and the unsanctioned tier inconvenient.
Communicate the policy, the tooling, and the reasoning to your users in that order. Be transparent. They will accept controls they understand the purpose of. They will route around controls that feel arbitrary.

Governance is not a project with an end date. It is a posture and culture that must be maintained. Unfortunately, the technology is evolving constantly and the risk surface keeps expanding with it, which means the work is never really done.

Upskilling: The Most Important Control

The story of a remote team member leaking sensitive data through an AI transcription tool is not hypothetical. It is happening right now, across every industry, every week. This is not only happening through tools users deliberately choose. Every SaaS vendor in your stack is racing to bolt agentic functionality onto their product, often enabled by default, often processing your data on their infrastructure before anyone in security has had a chance to review the terms of service. Zoom, Grammarly, Notion, Slack, your CRM, your ticketing system. They have all shipped AI features in the last eighteen months, and most of them are on right now in your tenant whether you blessed them or not.

This is the shadow AI problem. You cannot block your way out of it. You can only teach your way out of it.

Training is Not a Compliance Checkbox

Most corporate training is terrible, and everyone reading this knows it. A reused slide deck someone built three years ago, a quiz at the end designed to be passed in under sixty seconds, a completion report that gets filed away and never referenced again. The “training” happens, the box gets checked, and nobody in attendance is more capable afterwards.

If that is your approach to AI training, you will fail. Not because your users are incapable of learning, but because they already know the training is theater and they will treat it as such. They will click through it on a second monitor during a meeting. They will skip to the quiz. And then they will go back to using whatever AI tool they were already using, because the training taught them nothing useful.

The organizations getting AI upskilling right are the ones that have flipped the framing entirely. The goal is not to teach users what they cannot do. The goal is to teach them how to do their jobs better with the sanctioned tools. That is a meaningfully different conversation, and it lands differently with users because it treats them as capable adults rather than risks to be managed.

Enablement and Protection Are the Same Work

Here is the insight that most security-led AI training programs miss. Enabling your workforce and protecting your organization are not competing priorities. They are the same work, approached from different angles.

When a user knows how to get real value out of your sanctioned Claude or Copilot deployment, they have no reason to paste client data into a consumer tool. When a user understands why a particular classification of data should never go into any AI system, they make the right call the next time a vendor pitches them a shiny new agent. When a user feels trusted and equipped instead of suspected and restricted, they become an active participant in your security posture rather than a problem to be managed.

Every hour invested making your sanctioned tools genuinely useful is an hour of shadow AI prevention. Every hour spent explaining the “why” behind the policy is an hour of future incident avoidance. The productivity outcome and security outcome go hand in hand.

What Good AI Training Actually Looks Like

A few principles that separate training that works from training that wastes everyone’s time.

Create a culture where questions are encouraged. This can be as easy as setting up a Slack channel, a weekly office hour, or organizing a lunch-and-learn. It just has to be somewhere a user can ask “is it okay to use this tool for this task” and get real answers from a real human in under a day. Most AI incidents aren’t malicious. They occur because people have questions and no clear place to ask.

Tier the training to the user. A business analyst writing summaries in Copilot has different needs than an analyst experimenting with vibe-coded automations, who has different needs than the security team triaging AI incidents. One generic deck for the whole company is the wrong answer. Training needs to be targeted to the user’s risk tier.

Teach the tools, not just the policy. Users do not need an hour on what they cannot do. They need thirty minutes on what they can do, done well. Show them real prompts. Walk through real workflows. Let them see a skilled user work and understand what is possible. The policy becomes the easy part once they see the value in the sanctioned path.

Make it hands-on and specific to their work. Generic AI training is forgettable. Training built around the actual workflows of the people in the room sticks. The accounting team should be practicing on redacted invoices and expense reports. The marketing team should be working with real campaign briefs. The legal team should be doing contract analysis on sanitized examples. Specificity is what makes training useful.

Keep it short and repeat it often. An annual ninety-minute deep dive is worse than a fifteen-minute refresher every quarter. The technology moves fast enough that annual training is obsolete the day it is delivered. Keep it short. Keep it frequent. Keep it current.

Measure the right things. Completion rates are a useless metric. Instead ask: Did the training change behavior? Did shadow AI exposure drop in DSPM after a training cycle? Did sanctioned tool adoption increase? Did the number of “can I use this tool” questions in your Slack channel go up (a good sign) or down (a bad sign)? Behavior change is the only metric that matters.

The Security Team Needs Training Too

One more crucial piece that is often forgotten. Your security operations team needs AI-specific training just as much as your end users do, and probably more urgently. The threats are new, the detection patterns are evolving, and the vocabulary is unfamiliar to analysts who came up on traditional SIEM (Security Information and Event Management) and EDR (Endpoint Detection and Response)s work. If your SecOps team cannot confidently triage an AI-related incident, the rest of your governance program is built on a foundation of sand.

This is not a place to cut corners. Bring in outside expertise if you need to. Get your team comfortable with prompt injection, data exfiltration via AI tools, supply chain risks in AI-generated code, and the emerging category of agentic incident response. Learn from others’ mistakes. Build case studies from publicly reported incidents at peer organizations and train your team against them. The team that protects the organization needs to understand what it is protecting against.

The Real Test

You will know your training program is working when your users start coming to you proactively. When a vendor pitches a new AI feature and the account owner forwards it to security before enabling it. When an analyst asks whether a particular workflow is okay before they build it. When someone spots a colleague about to paste the wrong thing into the wrong tool and stops them, not because they were told to, but because they understood why it mattered.

That is the outcome you should be working toward. Not perfect compliance. Not zero incidents. An informed workforce that is actively participating in an organization’s culture of security because you gave them the knowledge and the trust to do so.

Final Thoughts

The purpose of this piece is to answer whether organizations can implement AI governance in a way that reduces risk without hampering the productivity their teams are already seeing. The honest answer is yes, but not by accident and not by defaulting to what feels safest.

The organizations that will get this right over the coming years are not the ones with the most restrictive policies or the most expensive tooling. They are the ones that have proactively done the harder work of thinking clearly about where their real risk lives, codifying it into policy that people can actually follow, enforcing it with the tools they already own, and investing in their people as the primary control rather than an afterthought.

The organizations that will get this wrong are the ones that treat AI as a threat to be contained rather than a capability to be governed. They will write complex sprawling policies that nobody can follow, deploy tooling that nobody tunes, and ban tools that their users will access from their phones anyway. They will lose both the security outcome and the productivity outcome, and have no answer to why.

The difference between those two outcomes is not budget. It is not tooling. It is not even risk appetite. It is the willingness to treat AI governance as a discipline that deserves real thought, real investment, and real engagement with the humans who are actually using these tools every day.

Start with the tier framework. Build the policy that matches your actual risk. Turn on the tooling you are already paying for. Invest in your people. Repeat every quarter, because the landscape will have moved by the time you are done. (I cannot wait to see how outdated this is a month after I post it.)

The work is never done, and that is not a problem to be solved. It is the nature of the terrain.

Useful Resources

Here is a list of resources and references used in researching this article.

Frameworks and Standards

OWASP Top 10 for LLM Applications The definitive community-maintained list of the most critical security risks in LLM applications. Essential reference for anyone operating at Tier 2 or Tier 3. OWASP GenAI
NIST AI Risk Management Framework (AI RMF 1.0) The foundational U.S. government framework for managing AI risk. Broader and more strategic than OWASP, useful for leadership conversations about governance posture. NIST AI RMF
MITRE ATLAS The adversarial threat landscape for AI systems. Maps real-world attack techniques against AI and machine learning systems, similar in spirit to ATT&CK for traditional threats. MITRE ATLAS

Microsoft Security Stack

Microsoft Purview Data Security Posture Management Official documentation for the unified DSPM experience referenced throughout this piece. Start here if you are evaluating or deploying DSPM in your tenant. Microsoft Learn
Microsoft Purview Data Security and Compliance Protections for Generative AI Apps Microsoft’s official guidance on securing AI usage across Copilot and third-party AI apps using the Purview suite. Microsoft Learn
Entra Conditional Access Documentation for the access control layer referenced in the enforcement section. Required reading if you are building the sanctioned-tier-frictionless architecture. Microsoft Learn
Microsoft Purview Endpoint DLP Documentation for device-level data loss prevention, including the browser-based controls that matter most for AI tool governance. Microsoft Learn

Industry Perspective

Anthropic’s Responsible Scaling Policy One of the more substantive public commitments from a frontier AI lab on how they think about risk at the model-building tier. Useful context even if your organization is nowhere near Tier 4. Anthropic
Google Secure AI Framework (SAIF) Google’s counterpart framework for securing AI systems. Worth reading alongside the Microsoft materials for a cross-vendor perspective. Google SAIF
Simon Willison’s Weblog A practitioner-level blog covering the evolving landscape of LLMs, AI security, prompt injection, and applied tooling. One of the most consistently useful independent voices in the space for staying current on real-world AI capabilities and risks. simonwillison.net