Is it safe to paste customer details into an AI tool to draft a reply?

Not into an unapproved tool. Use personal data only with a defined purpose and lawful basis, minimized to what the task needs, knowing the provider's role and every permitted use of your input (storage, human review, abuse monitoring, improvement — not just training), with retention, transfer, security and transparency handled. A processor needs a binding Article 28 contract. Sensitive data has extra conditions — and review the draft before sending, because lawful input doesn't make the output correct.

If I remove the customer's name, is the data anonymous?

Usually not — and it may not even be pseudonymization in the GDPR sense, which requires that the person can't be identified without separately held, protected information. If the project, town, dates or amounts still point to them, it's just redacted personal data, and data-protection rules apply in full. True anonymization is genuinely hard; never treat "I took the name out" as a green light.

What data is safe to put into AI

A common and serious beginner mistake is treating "I removed the name" or "it runs locally" as if either made your data safe. Neither does, on its own. Sorting what you are about to paste is still worth doing — but the real work is deciding, before any personal data goes in, on what basis you are using it and how it is protected. Here is a realistic version of that.

Classify before you paste

A quick mental sort keeps the worst mistakes out. Think in terms of sensitivity rather than fixed rules:

Tier	Examples	Handle how
Highly sensitive	Recipes, designs, customer lists, strategy, secrets	Keep out of general cloud tools; use a controlled option and extra safeguards
Confidential	Salaries, customer data, contracts, financials	Only with the right basis, terms, and controls in place — see below
Internal	Processes, manuals, work instructions	With care, and terms that fit
Public	Press releases, published accounts, legal texts	Lower confidentiality risk — but still check personal data, copyright, licensing, and whether reuse fits

Two caveats: labels don't decide sensitivity — a "contract" can be public boilerplate or a bundle of health data, and salary information can outweigh any recipe, so rate the actual content, scale, and likely harm. And "public" means findable, not free to reuse: published material can still carry personal data and copyright. This sort is a habit, not a legal test — that's the checklist further down.

"Removing the name" is redaction, not anonymization

Writing "Mr M. from the Eupen project" instead of a full name and address does not make the data anonymous — and it isn't even pseudonymization in the GDPR's sense unless the person can no longer be identified without separately held, protected information. If the project, the town, the date and the amount still point to one person, you've merely redacted some identifiers, and the text remains personal data with the rules applying in full. (Even properly pseudonymized data stays personal data.)

Genuine anonymization — where no one can realistically be re-identified — is difficult and easy to get wrong. Treat stripping identifiers as risk reduction, useful but partial, never as a reason to skip the thinking below.

"It runs locally" is one control, not a guarantee

A genuinely local, correctly configured setup can keep inference data on your hardware — a real and valuable control. But local operation is not automatically confidential:

Device security — a compromised laptop can expose local prompts, outputs, model files and credentials.
Access control — who can open the machine, the app, and the files. Disk encryption protects a locked or powered-off device; it does nothing against malware or someone at an unlocked session.
Encryption — at rest and for any backups.
Backups — protected and tested, not another copy left exposed.
Network reality check — verify the application's traffic, telemetry, synchronization, extensions and update behavior; some "local" apps still phone home or fetch cloud models.

Treat local deployment as one layer in a stack, not the finish line.

Before using personal data, work through this

If what you are about to use relates to an identified or identifiable living person — a customer, applicant, or member of staff; it doesn't have to name them — settle these first:

Purpose and lawful basis. Why are you using this data, and on what legal footing?
Special categories. Health, beliefs, union membership, biometrics, sex life, criminal-offense data — an ordinary lawful basis isn't enough; extra legal conditions apply.
Roles. Is the provider your processor, or an independent or joint controller? Assess per purpose — one provider can be processor for your prompts and controller for its own telemetry and billing. Joint control needs an arrangement allocating duties; disclosing to an independent controller needs its own basis.
Contract. A provider processing on your behalf requires a binding contract with the Article 28 terms (commonly called a DPA) — required, not optional.
Every permitted use of your input. Not just training: storage, human review, abuse monitoring, evaluation, service improvement, account history, deletion and backups. Configure the settings deliberately.
Retention and transfers. How long inputs and outputs are kept, where processing happens, which subprocessors touch it, and how international transfers are safeguarded.
Transparency and rights. Can you tell the people involved (privacy notice covering the new purpose, recipients, transfers), and can you honor access, correction and deletion requests that reach into provider-held prompts?
Security and minimization. Access control, encryption — and sending only what the task needs.
DPIA screening. If the use is likely to create high risk to people's rights, a data protection impact assessment is mandatory before processing starts.
Authorization beyond privacy. NDAs, customer contracts, professional secrecy, licenses and trade-secret duties can forbid disclosure even where GDPR is satisfied.

A simple use may clear this quickly; sensitive, high-risk or international processing can need specialist advice — budget for that rather than assuming a morning suffices.

Other traps

Jurisdiction and access. Where data is processed, and which authorities can compel access, matters for sensitive material — factor it into the transfers question rather than assuming any provider is "safe".
Prompt injection. Invoices, emails, PDFs and web pages can carry hidden instructions that manipulate an AI system — and the danger scales with what the system can reach: don't give an AI that reads untrusted documents access to mailboxes, databases or action-taking tools it doesn't need, and require independent confirmation before external actions.
Shadow AI. When staff use unapproved tools, the organization can't show these checks happened. A short written AI policy helps — backed by approved tools, training, access controls, and a workable way to request exceptions, because paper alone changes nothing.
Lawful input ≠ reliable output. A permitted paste can still yield a reply that's wrong, leaks someone else's details, or invents commitments — review before anything is sent or acted on.

Get the habit of thinking before pasting into muscle memory, and you avoid the most common privacy and confidentiality failures in office AI.

What to do

Do the sensitivity sort before every paste — rating content and consequences, not document labels.
For anything relating to a person, run the checklist above before it goes in.
Treat removing identifiers, and running locally, as controls to combine — never as guarantees; the tools guide and AI tools we're watching cover the local and controlled options.
Write a one-page AI policy and give it teeth — approved tools, training, an exception route — and see the wider duties in the EU AI Act for small business and the service and contract trade-offs in the paid-AI guide.