Your sales team, your HR people, your legal team, your accountants, and your developers all type confidential text every day - into Word, into emails, into your CRM, into chat. Modern productivity tools quietly send a lot of that text to remote services, usually US-based, sometimes outside any contract you actually signed, to power features that feel like they run locally. This article walks through four concrete cases your team probably uses without thinking - Microsoft Word, Grammarly, AI code completion, and ChatGPT or Claude - and explains what to do about each.
Microsoft Word: auto-correct, Editor, and Copilot
Plain auto-correct (the red squiggle for typos, capital-after-period) runs locally on your machine. That part is fine.
It gets more interesting once you turn on Microsoft Editor, the blue squiggle that suggests rephrasings, formality changes, and clarity rewrites. Many of those checks run as a cloud service, meaning the relevant chunk of your document is sent to Microsoft for inspection. The same is even more true of Microsoft 365 Copilot, which routinely sends document context to Microsoft (and onward to the OpenAI API) to generate its suggestions.
What that means concretely: when you draft a contract, an HR letter, a medical report, a legal brief, or a customer email in Word with Editor or Copilot turned on, the text transits Microsoft servers. Microsoft’s enterprise terms commit that the data is processed for the service and not used to train models. Worth noting: Microsoft is a US-headquartered company, so the data also sits under US jurisdiction once it leaves your machine, with everything that implies under US legal process.
For client-confidential, employee-confidential, or regulated content (health, finance, legal), this is a real disclosure path that very few users realise they have opted into.
What to do:
- For sensitive documents, turn Editor and Copilot off in the document or globally. In Word: File -> Options -> Proofing for Editor; File -> Options -> General for Copilot.
- If you administer Microsoft 365, scope Connected Experiences off for groups handling confidential data.
- Read your enterprise agreement: even when data is “not used for training”, it still transits Microsoft systems, and the CLOUD Act applies.
Grammarly (and similar browser-based writing assistants)
Grammarly runs as a browser extension and a desktop app. As your team types into Gmail, Outlook on the web, LinkedIn, Salesforce, HubSpot, or any internal CRM or admin tool, Grammarly watches the input field and sends the text to its servers to analyse grammar, style, and tone. The same is true of its desktop app, which can intercept text from Word, Slack, and other native apps.
That means every email your sales team drafts, every HR letter your people team writes, every customer-facing reply, every CRM note, every internal Slack message caught by the desktop app gets processed by Grammarly Inc., a US-headquartered company. Grammarly publishes a privacy policy and offers a Business tier with stricter handling, but the same caveats apply: data transits a US provider, and US legal process under the CLOUD Act reaches it.
The user pattern is also worth flagging: Grammarly is often installed by individual employees on their own, without IT going through a procurement review. So the data flow is not even on the company’s risk register.
What to do:
- Decide whether Grammarly should be allowed company-wide. If yes, require the Business tier with a documented data-processing agreement, and roll it out via IT, not as a personal install.
- Disable the browser extension on domains where regulated data lives (banking portal, electronic health record, payment back-office, audit tooling).
- For Swiss / EU firms with stricter requirements, prefer EU-controlled alternatives such as LanguageTool (which can be self-hosted) or DeepL Write.
VS Code (and Cursor, JetBrains, etc.): AI code completion
Modern editors offer an AI completion feature: GitHub Copilot, Cursor, Tabnine, JetBrains AI, Sourcegraph Cody, Continue. They all work the same way. As you type, the editor sends a snippet of context to a remote model, which sends suggestions back.
What leaves your laptop is more than the line you are typing:
- Code: not just the line, but enough surrounding code to make the suggestion sensible. Usually 50 to several hundred lines.
- Comments: including TODO and FIXME notes that may name client systems, internal projects, or vendors.
- Filenames and paths: which can themselves leak the structure of an internal codebase.
- Sometimes: secrets pasted into source files (API keys, connection strings) that the developer was about to clean up.
For an open-source project, this is fine. For a private repo containing customer data schemas, security logic, audit trails, or credentialed-system integration, this is the equivalent of pasting fragments of your codebase into a third-party API every few seconds.
What to do:
- Decide per-repository, not globally. Most assistants support an ignore file at the repo root (
.copilotignore,.cursorignore, etc.) or a “disable for this workspace” toggle. - For private codebases handling regulated data, prefer self-hosted models (for example Ollama plus Continue, or JetBrains AI with an on-prem option) or models routed through your own provider account with a no-training contractual clause.
- Audit what your editor sends: GitHub Copilot exposes a request log, Cursor has a privacy panel - check it.
Pasting into ChatGPT, Claude, or any LLM chat
The fastest way to leak confidential data is the most common one: pasting it into an LLM chat - “help me rewrite this”, “summarise this contract”, “translate this email”, “explain this stack trace”.
The chat input goes straight to the provider. Default consumer plans (free ChatGPT, free Claude) may use that input to improve future models unless you have explicitly opted out. Business plans (ChatGPT Team / Enterprise, Claude for Work, Anthropic API with zero retention) do not train on your data, but the data still transits the provider’s infrastructure, sits in their logs for some retention window, and is reachable by their jurisdiction’s legal process.
What gets pasted in practice that should not have:
- Customer lists with names and emails
- Draft contracts and NDA texts
- Salary tables and HR letters
- Patient summaries, lab reports, claims data
- Source code containing credentials or proprietary algorithms
What to do:
- If you use LLM chat for work, use a business tier with a documented data-handling agreement (zero retention, no training).
- For Swiss / EU regulated content, prefer local models (Ollama, llama.cpp, a Mistral instance served on your own infrastructure) or EU-hosted offerings.
- Establish a simple internal rule: “Never paste anything into an LLM chat that you would not paste into the URL bar of a public website.”
What this looks like at the company level
These three tools together form a near-invisible data-egress channel. People who would never email customer data to a stranger paste it into Copilot, Cursor, or ChatGPT every day, because the UX makes it feel local. It is not.
The fix is not to ban AI tools. The fix is to know which tier of which tool is in use for which kind of data, write that down in a short policy page, and configure the tools to match. That is the kind of work an audit will ask about, and it is much easier to set up before the audit than during it.
A practical rule of thumb
Plain offline tools (basic spellcheck, plain syntax highlighting, local LLMs): no data leaves the laptop. Use them freely for sensitive work.
Cloud AI assistants (Microsoft Editor, Copilot, ChatGPT, Claude, Cursor): data transits a third-party. Use the business tier with a documented zero-retention agreement, or turn the assistant off for confidential content.
If your industry has an audit (health, finance, legal, public sector), write down which tier of which tool processes which data. The auditor will ask.
