Last Tuesday, someone on your team pasted a customer support transcript into ChatGPT to draft a response. The transcript included a name, an email address, a billing dispute amount, and a partial account number. The reply that came back was polished and helpful. The problem is not the output. The problem is what just happened to that input.
This is not a hypothetical edge case. It is the most common way small businesses expose sensitive data to third-party AI systems: not through a breach, not through a sophisticated attack, but through a well-intentioned employee trying to save twenty minutes.
If your team uses any large language model — ChatGPT, Claude, Gemini, or any other hosted service — you need a clear, grounded framework for what goes in and what stays out. Not a 40-page policy document that nobody reads. A set of principles your people can actually apply in the moment they are about to hit paste.
Why the Risk Is Real, Not Theoretical
When you send data to a third-party LLM, you are transmitting it to infrastructure you do not control. Depending on the provider, the plan tier, and the specific terms of service in effect on the day you send it, that data may be:
- Stored on the provider's servers for some retention period
- Used to train or fine-tune future model versions
- Accessible to the provider's employees for quality review
- Subject to legal jurisdiction rules that differ from yours
- Potentially surfaced — in fragments or patterns — in responses to other users
Most major providers have improved their data handling policies significantly over the past two years. OpenAI's API, for example, has different data retention and training terms than the free ChatGPT consumer product. But terms of service change. Defaults change. And the burden of understanding those distinctions falls entirely on you.
For a small business without a dedicated legal or compliance team, the safest posture is not to read every policy update and hope you catch the important ones. The safest posture is to decide, in advance, what categories of data never leave your walls — regardless of what any provider promises.
The Three-Category Framework
Not all data carries the same risk. A practical AI usage policy for employees starts by sorting information into three categories based on what would happen if it were exposed.
Category 1: Safe to Send
This is information that is already public, generic, or contains no identifying details. Sending it to a third-party LLM creates no meaningful risk.
- Publicly available content you want rewritten or summarized — blog posts, marketing copy, product descriptions that are already on your website
- Generic business questions — "What are best practices for onboarding new employees?" or "Write a job description for a warehouse coordinator"
- Code snippets that contain no credentials, no API keys, no proprietary business logic, and no internal system names
- Fully anonymized data — statistics, aggregates, trends with every identifier removed
- Drafts and outlines where no real names, accounts, or proprietary details appear
The test is simple: if this exact text appeared on a public website tomorrow, would it cause any harm? If the answer is no, it belongs in Category 1.
Category 2: Send Only After Scrubbing
This is information that has real business value but can be stripped of identifying details before it reaches an LLM. The content is useful for AI-assisted work, but it needs preparation first.
- Customer support transcripts — useful for generating response templates, but only after you replace real names, account numbers, and contact details with placeholders
- Internal process documents — helpful for building SOPs or training materials, but may reference proprietary systems, vendor names, or internal metrics that should be generalized
- Sales or marketing data — conversion rates, campaign performance, audience demographics can inform AI-assisted analysis, but strip client names, deal sizes tied to specific accounts, and any data covered by an NDA
- Code that contains business logic — if you need AI help debugging or refactoring, remove hardcoded credentials, environment variables, internal hostnames, and anything that reveals your infrastructure topology
Scrubbing takes discipline. It is tempting to skip it when you are in a hurry. That is exactly the moment the policy needs to hold. Build the habit of a 60-second review before pasting: scan for names, numbers, emails, and anything you would not want a competitor to see.
Category 3: Never Send
This is information that should never enter a third-party LLM under any circumstances, regardless of what the provider's terms say today. The consequences of exposure are too severe, the data is too sensitive, and the risk is not worth any productivity gain.
- Personally identifiable information (PII) tied to customers or employees — full names paired with Social Security numbers, dates of birth, financial account numbers, health information, or government-issued IDs
- Protected health information (PHI) — anything covered under HIPAA or equivalent healthcare privacy regulations in your jurisdiction
- Payment card data — card numbers, CVVs, expiration dates, or any data subject to PCI-DSS requirements
- Credentials and secrets — passwords, API keys, tokens, private certificates, database connection strings, SSH keys
- Legal communications — attorney-client privileged documents, active litigation materials, settlement terms
- Contractual obligations — data you have agreed, by contract with a client or vendor, not to share with third parties
- Trade secrets and core IP — proprietary algorithms, unreleased product designs, formulas, or competitive intelligence that defines your market position
There is no scrubbing step that makes Category 3 data acceptable to send. If the information falls here, the answer is always no — find another way to accomplish the task.
Building a Policy That Actually Gets Followed
The framework above is only useful if your team applies it consistently. A policy that lives in a shared drive and gets referenced once during onboarding will not protect you. Here is what makes an AI usage policy for employees hold up in practice.
Keep It Short
One page. Three categories. Examples drawn from your actual workflows — not abstract descriptions of data types, but the specific tools and tasks your people use every day. A support rep needs to know what to do with a Zendesk ticket before pasting it. A marketing coordinator needs to know whether a campaign report with client names can go into an LLM for analysis. Make the guidance concrete enough that someone can apply it without calling a manager.
Make the Default Restrictive
When someone is unsure which category applies, the default should be "do not send." This is not about creating fear. It is about designing a system where the cost of being cautious is low — you lose a few minutes — and the cost of being wrong is high. Restrictive defaults protect you during the gray areas, which is where most real decisions happen.
Designate Approved Tools and Tiers
Not all LLM access points are equal. The free consumer tier of ChatGPT has different data handling terms than the API or an enterprise agreement. Some providers offer contractual commitments that your data will not be used for training. If your team is going to use AI tools, specify which tools, which account tiers, and which configurations are approved. A team member using a personal free-tier account to process business data is a different risk profile than someone using an enterprise API with a signed data processing agreement.
Review It Quarterly
AI capabilities and provider policies shift frequently. A quarterly review — even a 30-minute check-in — keeps the policy current and gives your team a chance to surface edge cases they have encountered. Those edge cases are where the real learning happens.
Where Self-Hosted and Private AI Changes the Equation
The three-category framework assumes you are sending data to a third-party service. But for businesses that handle significant volumes of sensitive information, there is another path: keeping the AI inside your own infrastructure.
Self-hosted models, retrieval-augmented generation (RAG) systems grounded in your own knowledge bases, and private AI pipelines change the calculus fundamentally. When the model runs on infrastructure you control — with no data leaving your environment — Category 2 and even some Category 3 data can be processed by AI without the third-party risk.
This is not a theoretical distinction. At FigTree Development, we run our own content workflows — blog topic generation, drafting, review, and social distribution — on self-hosted infrastructure with human approval steps built into the pipeline. The data stays within systems we architect and operate. That is a deliberate design decision, not a convenience.
Building private AI infrastructure requires real engineering: ingestion pipelines, embedding models, inference endpoints, monitoring, and access controls all have to be designed with production rigor. It is not a weekend project. But for businesses where data privacy is a non-negotiable requirement — healthcare, financial services, legal, or any firm whose clients demand contractual data protection — it is often the only path that lets you use AI at scale without accepting uncontrolled risk.
The Cost of Getting This Wrong
The consequences of sending the wrong data to a third-party LLM are not always dramatic. Sometimes nothing visible happens. But the exposure is still real, and the potential costs are concrete:
- Regulatory penalties — HIPAA violations can carry fines from $100 to $50,000 per incident, with annual maximums reaching $1.5 million per violation category. State privacy laws add their own penalty structures.
- Contractual liability — if a client's data ends up in a third-party system and your contract prohibits that, you are in breach regardless of whether actual harm occurred.
- Reputational damage — for small businesses, trust is the foundation of every client relationship. A data handling incident, even a minor one, can erode years of earned credibility.
- Loss of trade secrets — once proprietary information enters a third-party training pipeline, you cannot retrieve it, and you may have no way to know how it gets used downstream.
None of these outcomes require a malicious actor. They result from normal people doing normal work without a clear framework to guide them.
Related service: AI automation and workflow services in Tampa Bay — what we build, how we work, and what it costs.
Start With the Soil Work
Getting AI data privacy right for your small business is not about avoiding AI. It is about building the foundation so your team can use these tools confidently, knowing the boundaries are clear and the risks are managed.
The work is not glamorous. It is policy writing, data classification, tool selection, and infrastructure decisions. It is the soil work that lets everything above it grow without collapsing.
If you are not sure where your current AI usage falls on the risk spectrum — or if you suspect your team is already sending data to third-party models without a clear framework — that is the right time to get grounded.
FigTree Development is a Florida-licensed technology firm based in the Tampa Bay area, and we work with local and remote clients to map the highest-value automation opportunities and build the guardrails that make AI safe to scale. We start every engagement with a Discovery and Strategy process — not a sales pitch, but a clear-eyed look at where you are, what you need, and what to build first.
Book a free 20-minute discovery call and we will help you figure out what belongs in an LLM, what needs to stay inside your walls, and where automation can compound your team's effort without compromising what you have built.