How are you controlling AI use and protecting sensitive company data?
Asked by
MellowOrbit42
We're trying to figure out the best way to manage generative AI in our enterprise without employees pasting confidential information into personal accounts. So far, we've blocked most public AI services, allowed Microsoft Copilot, and introduced a policy prohibiting unsanctioned tools. The problem is that Copilot doesn't meet every department's needs, and leadership now wants one team to use Claude.
We're implementing Microsoft Purview DLP and reviewing Defender cloud-app controls. Our domain is federated through Okta for single sign-on, so I'm also trying to understand which session and access policies are still possible. We have Microsoft 365 E5.
What approaches are other IT teams using to support useful AI tools while preventing sensitive information—such as payroll spreadsheets—from being uploaded to consumer AI services?
Answers
First figure out exactly what that department needs: a browser chatbot, coding assistance, an agent, or something else. A managed Copilot or Copilot Studio deployment may cover some Claude-style use cases while keeping the organization under Microsoft’s enterprise protections. If they truly need direct Claude access, look at an enterprise contract and verify its retention, training, identity, audit, and data-processing terms against your policy.
Also, don’t quietly make an exception to an existing policy. Either the requested use case passes the policy or leadership should formally amend the policy and accept the risk.
Reply to this answer
For labeled files in SharePoint or OneDrive, review Azure Rights Management permissions and consider restricting copy or extract rights for sensitive categories. That can help prevent authorized AI features from freely extracting protected content. However, don’t assume the same control protects external Graph or Copilot connectors: those generally depend on the source system’s ACLs and connector configuration, not simply on RMS extract permissions. Audit connector scope and permissions separately to avoid oversharing.
Reply to this answer
The hardest part is convincing people to stop using personal AI accounts. We’re finding that the approved service has to be good enough for the common workflows, and the policy needs to explain the risk in practical terms rather than just saying “don’t use it.”
Reply to this answer
A Microsoft-focused environment can combine Purview sensitivity labels and DLP with Defender monitoring, firewall or DNS restrictions, browser controls, and identity-based access. Expect this to be an ongoing security-stack project—especially if browsers have built-in AI features that can index or process company content.
For Claude specifically, an enterprise offering or Claude through a managed cloud service such as Amazon Bedrock may provide better control than consumer accounts. A curated internal marketplace for approved models, agents, and plugins can also keep teams productive without letting everyone install arbitrary integrations.
Reply to this answer
Blocking every service usually drives users toward personal accounts and unmanaged phones, where your controls have no visibility. The better goal is to make the approved option convenient, capable, and clearly safer than the workaround. Provide sanctioned tools, publish examples of prohibited data, train users, and monitor for risky activity rather than relying on a blocklist alone.
Treat accidental uploads as inevitable: have an incident process, DLP alerts, data classification, and a way to investigate and contain exposure. Technical controls help, but users need a practical approved path.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions