The Practical Privacy Model for AI at Work
Most people ask whether an AI tool is “safe” as if safety were a switch. It is not. The better question is what the tool can see, what it can remember, where the data goes, and what happens when the output is wrong. Four questions. Most organizations skip three.
The risk is not only a dramatic data breach. It is accumulation. A meeting transcript here. A customer complaint there. A draft contract, a health detail, a private salary discussion. Each item looks harmless in isolation. Together they form a portrait of a workplace that nobody consciously agreed to create.
Map the data before you choose the model
Make a simple inventory with four labels: public, internal, confidential, regulated. Public marketing copy can go into a broad tool. A customer address cannot. A product roadmap may be internal but still damaging if it leaks before launch. Health, financial, and identity data deserve stricter handling and often legal review.
Do not let the user interface decide your classification. A friendly chat box is still an external system if the contract says the provider can retain prompts. Read the retention and training terms. If nobody owns that task, the organization is making a policy by accident.
Permission is not the same as privacy
A tool connected to a drive may be able to search every document the employee can access. That does not mean it should. Broad permissions turn one compromised account into a map of the company. Start with a narrow folder, a service account, and read-only access where possible. Expand only when the workflow proves it needs more.
The same applies to personal assistants. Calendar access, email search, and document access should be separate decisions. Convenience is not a security architecture.
Build a redaction habit
Before a prompt leaves your environment, remove names, account numbers, personal addresses, and anything that lets a stranger identify the person behind the problem. Replace them with stable labels: Customer A, Project B, invoice total. You preserve the reasoning task without shipping the entire file cabinet.
Redaction is not perfect protection. It is friction. Friction is underrated. Most accidental disclosures happen because the dangerous step is easier than the careful one.
Keep an audit trail that humans can read
For high-impact workflows, log the request, source documents, model version, reviewer, and final decision. Not because a spreadsheet is magical. Because six weeks later someone will ask why a customer was rejected, a claim delayed, or a contract changed. “The assistant suggested it” is not an explanation.
Let people challenge the result. A model that cannot be questioned is not an assistant. It is an unaccountable gatekeeper with a typing animation.
The household version
At home, turn off automatic access you do not use. Avoid pasting full medical records, legal disputes, or intimate conversations into a tool just because it can summarize them. Ask whether the convenience saves ten minutes or creates a permanent copy of something you would never post publicly.
You do not need to become a security engineer. You need to stop treating memory as a feature with no cost.
Your data is already gone from more places than you think. The work now is deciding what leaves next.
A small policy that works
Write three examples of data that may never enter a general-purpose model. Put them beside the keyboard. Then write three examples that may enter one only after redaction. Policies fail when they live in a PDF nobody sees. A reminder at the moment of action is more useful than a lecture during onboarding.
Review permissions every quarter. Remove access when a project ends, not when someone remembers. Test deletion with a dummy record. Ask the vendor what happens to backups. If the answer is wrapped in six layers of “generally,” treat it as unknown and plan accordingly.
Privacy is not a promise that nothing will ever go wrong. It is a discipline for limiting the blast radius when something does. Quiet controls beat dramatic speeches. They keep working after the security meeting ends.
Make the safe behavior the easy behavior. Put the approved tool in the obvious place, the data rules in plain language, and the review button where a tired person can find it. Security is what remains under pressure.
One final check is worth doing before you commit. Write down the assumption behind the recommendation, the person who bears the cost if it is wrong, and the smallest experiment that could disprove it. This turns a clever answer into a decision you can inspect. Keep the result in plain language so another person can challenge it without opening a technical manual. Good practice is not dramatic. It is repeatable, visible, and easy to stop when the evidence changes. That is the difference between using a tool and being used by one.
Top comments (0)