Company data, privacy, and rules

Two things are usually true at once here: the question feels enormous, and the honest answer for most day-to-day work is “yes, on the right account.” It feels enormous because “is this safe?” is really several questions bundled together — whether the vendor trains on what you send, who at the vendor can see it and for how long, and whether your own contracts permit sending it to a third party at all. Different answers, different owners, and most arguments about AI and data are two people answering different ones at each other.

The variable that changes every one of those answers is which account someone is signed into. Consumer and business plans are governed by different terms — on training, on retention, on what an administrator can see. Two colleagues doing identical work, one on a personal login and one on a company account, are in genuinely different positions. Settling that once, in writing, with the date on it, ends a debate your team would otherwise repeat every month.

The half people forget is that privacy isn’t only about what goes in. The moment you let Claude read a web page, an inbox, or a document someone outside your team wrote, you’ve also let it read whatever instructions were hidden in there. That’s prompt injection, defined below, and it’s the reason approval steps aren’t bureaucracy: permissions are what stands between a hostile document and a real action on your systems. The same caution applies the first time you install a connector — see connecting Claude to your other tools.

So a rule that actually works has two sides: tiers governing what your team may hand over, and guardrails governing what the tool is allowed to do with what comes back. The two guides below give you one side each — how to separate the questions and tier your material, and how to write ground rules short enough that people read them instead of routing around them.