In many of the Microsoft 365 environments I work with, worries about insider risk from risky AI usage have grown sharply since Copilot and other generative AI tools became part of everyday work. The classic Insider Risk Management features in Microsoft Purview did a good job with traditional data leaks, but AI-specific scenarios such as sensitive prompts or Copilot output were largely invisible. The dedicated policy template for risky AI usage finally changes that. Below I describe what works and what doesn't when you set it up, what comes up in privacy and works council discussions, and how to handle the large number of alerts you will get in daily operations.
The risky AI usage policy covers prompts and AI responses
The "Risky AI usage" policy template in the Purview portal targets two threats. The first is users entering sensitive data (customer lists, confidential project details, personal information) into Copilot or other enterprise AI. The second is AI-generated responses that leak sensitive content or help someone exfiltrate data. You find it under Insider Risk Management → Policies → Create policy → Risky AI usage. According to the current announcement, it covers both Microsoft 365 Copilot and other connected AI applications.
For an overview, Microsoft's page on insider risk management policy templates is a good place to start. The template ships with ready-made indicators for risky prompts and responses. You can choose which of them are active and adjust their thresholds in the settings (see the reference for policy indicators).
Audit logging and AI indicators have to be in place first
Without a few basics, the policy simply won't trigger. Start by enabling Microsoft Purview audit logging with the longest retention your licence allows, so older AI interactions aren't lost. Then turn on advanced analytics and the indicators for AI activity in Insider Risk Management (Purview portal → Insider Risk Management → Settings). If you want to escalate high-risk cases for investigation, also integrate with Microsoft Defender XDR, which lets those incidents run through your main SOC workflow.
The setup itself goes like this:
- Purview portal → Insider Risk Management → Policies → Create policy
- Select “Risky AI usage” template
- Configure users/groups, trigger thresholds, and escalation paths
- Activate and test the policy
You need at least Insider Risk Management or Compliance Manager permissions. If you also want to tie in DLP or DSPM controls, my article on DSPM for AI in Purview has practical guidance from real projects.
Pseudonymisation is the basis for the works council conversation
In Germany in particular, privacy is the topic everyone is thinking about, and it's usually the works council's first question. Insider Risk Management relies on pseudonymisation. The identities behind risky activity are hidden by default and only revealed through a four-eyes (dual approval) process when escalation is necessary. That matters for GDPR as well as for German co-determination law. You still have to align the policy with the works council, document who accesses the data and how, and be transparent about thresholds and review workflows. The Purview settings let you adjust these details, including escalation logic and audit logging.
A three-tier triage keeps risky AI alerts manageable
Once you switch on risky AI usage policies, the alerts pile up quickly. Many are harmless (test data, generic prompts), a few are genuinely serious. I often see teams overwhelmed at first because they can't tell which alerts point to real intent to exfiltrate or misuse data. And not every alert means a malicious insider. People regularly paste sensitive information by accident without thinking about where it ends up. You need a structured triage process that sorts alerts by risk and context, otherwise alert fatigue sets in fast.
The approach that has worked best for me is a three-tier system:
- Clearly benign (dummy data, lorem ipsum)
- Unclear/needs review (e.g. customer names, but benign in context)
- Clearly critical (trade secrets, personal data, export attempts)
Current alert management lets you set up a review workflow per category and assign follow-up actions. In many organisations I recommend regular review cycles with the SOC or the data privacy team to keep improving the ratio of real signals to noise.
The Mermaid diagram shows how a risky AI alert flows
Before you design your incident process, it's useful to sketch the typical alert flow. The Mermaid diagram below traces the path from a detected risky AI action to a possible escalation:
flowchart TD
AI_Event["Risky AI action detected"] --> Alert["Insider risk alert created"]
Alert --> Pseudonym["Pseudonymisation active"]
Pseudonym --> Triage["Triage by risk team"]
Triage -->|Benign| End1["No action"]
Triage -->|Critical| Escalation["Identity revealed (four-eyes)"]
Escalation --> Incident["Incident management"]
Figure: From risky AI alert to escalation in Insider Risk Management.
AI risk also needs DSPM and a close eye on departing users
The risky AI usage policy is a real step toward data loss prevention for AI, but it won't solve everything on its own. It depends on sensible thresholds, realistic reviews and an honest conversation with users and the works council before you go live. The organisations I see getting the best results combine classic DLP, DSPM and Insider Risk Management. That matters more and more as departing users find inventive ways to export data with AI tools, often in ways no legacy rule would pick up.
Pro tip: Keep Purview audit log retention at 90 days or more. With less, you have no visibility into risky AI prompts or Copilot outputs that triggered late.
If you build the policy with privacy in mind from the start, triage alerts in context and adjust your workflow regularly, insider risk from risky AI usage stays manageable without getting in the way of people's actual work.
