Your employees are already using AI tools at work. Some you approved, some you didn’t. Either way, data is leaving your environment, and if you run a business that handles sensitive client information, controlled unclassified information (CUI), or anything regulated, that matters more than most owners realize.
The Core Problem: AI Tools Consume Data to Function
Large language models and AI assistants don’t just answer questions in a vacuum. When someone pastes a contract into ChatGPT to get a summary, or drops a client email into an AI writing tool to clean it up, that text goes somewhere. It travels to a third-party server, gets processed, and depending on the service’s terms, may be used to improve the model, stored for a period of time, or accessible to vendor staff under certain conditions.
That’s not a conspiracy theory. It’s how most consumer-grade AI products work by default. The question isn’t whether this is happening. The question is whether your organization has any visibility or control over it.
Consumer Tier vs. Enterprise Tier: The Distinction That Actually Matters
Most AI vendors offer two very different products under the same brand name. The free or low-cost consumer version typically has broad data use rights. The enterprise version, usually sold with a data processing agreement (DPA), typically includes commitments that your data won’t be used for model training, that it’s encrypted in transit and at rest, and that retention is limited.
Microsoft 365 Copilot, for example, operates under Microsoft’s existing enterprise data protection commitments when deployed through a licensed Microsoft 365 tenant. That’s a meaningfully different posture than a free browser-based AI tool with no DPA in place.
If your team is using the free version of anything, you almost certainly don’t have a DPA. That means you have no contractual basis for claiming your data is protected.
What This Means for CMMC and NIST 800-171 Contractors
If your organization handles CUI as part of a Department of Defense contract, this isn’t just a privacy concern. It’s a compliance problem.
NIST SP 800-171 requires you to control access to CUI, limit where it flows, and protect it in transit and at rest. CMMC Level 2 maps directly to those controls. If an employee pastes CUI into an AI tool that has no DPA, no access controls, and no documented security posture, you have likely violated multiple controls, including those covering system and communications protection and configuration management.
A C3PAO assessor reviewing your environment will ask about third-party tools and data flows. “We didn’t know employees were using it” is not a finding you want to hand them.
The Shadow AI Problem
Shadow IT has existed for years. Shadow AI is the same problem with higher stakes. The tools are free, frictionless, and genuinely useful, so adoption happens fast and quietly. Someone on your team figures out that an AI tool cuts their report-writing time in half, tells a colleague, and within a month half the department is using it.
You won’t catch this with a firewall rule alone. You need a combination of:
- An acceptable use policy that explicitly addresses AI tools (most existing policies predate this problem)
- Endpoint or network visibility that can surface traffic to known AI service endpoints
- A process for employees to request and get approved AI tools quickly, so the approved path is easier than the workaround
The goal isn’t to ban AI tools. It’s to make sure the ones in use have appropriate controls and that you know what’s being used.
What a Privacy and Compliance Review of AI Tools Should Cover
Before any AI tool gets used with business data, someone in your organization should be able to answer these questions:
- Does the vendor have a signed DPA with your organization?
- What data does the tool collect, and where is it stored?
- Is the tool’s security posture documented (SOC 2 report, ISO 27001 certification, or equivalent)?
- Does the tool’s use create any obligations under applicable regulations (HIPAA, CMMC, state privacy laws)?
- Is there an audit log of what data was submitted?
If you can’t answer those questions, the tool isn’t ready for business use, regardless of how useful it is.
Practical Steps for Non-Technical Owners
You don’t need to become a data privacy attorney to manage this. You need a process.
First, take inventory. Ask your IT team or MSP to identify what AI tools are currently in use across your organization. This includes browser extensions, standalone apps, and features built into existing software.
Second, classify your data. Know what information your business handles that is sensitive, regulated, or contractually protected. That classification drives every decision about which tools are acceptable.
Third, establish a short approval checklist. Any AI tool that will touch business data needs a DPA review before deployment. Make this a standard step, not an afterthought.
Fourth, update your acceptable use policy. Name AI tools specifically. Define what categories of data cannot be entered into any external AI service without explicit approval.
Fifth, train your team. People aren’t trying to cause a breach. They’re trying to do their jobs faster. If they understand why the guardrails exist, they’re far more likely to follow them.
The Bottom Line
AI tools are not going away, and you shouldn’t want them to. The productivity value is real. But the data handling risks are also real, and they don’t require a sophisticated attack to materialize. An employee pasting the wrong document into the wrong tool is enough.
Owning the problem means knowing what tools are in use, having contracts that protect your data, and making sure your compliance posture reflects how your team actually works, not how you assumed they work.
Common Questions About AI Tools and Your Data
How do I ensure AI tools used by my team comply with our security and compliance obligations?
Start with inventory, not policy. Ask your IT team or MSP to list every AI tool currently touching business data, including browser extensions and features built into software you already own. Then run each one against the same short checklist you would apply to any vendor: a signed DPA, a documented storage location, current third-party attestation, and an audit log of what was submitted. A tool that cannot clear that checklist is not compliant, no matter how much time it saves.
What happens when a commercial AI tool interacts with our business data?
The text does not stay on the employee’s machine. It travels to a third-party server, gets processed there, and depending on the vendor’s terms may be used to improve the model, retained for some period, or accessible to vendor staff under defined conditions. That is default behavior for most consumer-grade AI products, not an edge case. Whether it is acceptable depends entirely on the contract you have in place, and for a free tool that is usually no contract at all.
Why is deleting a chat in a commercial AI tool not the same as deleting the data?
Deleting a conversation removes it from your view of the product. It does not necessarily remove the copy that was already processed, retained under the vendor’s stated retention window, or used for model improvement before you hit delete. Enterprise tiers sold with a data processing agreement typically commit to limited retention and no training use. Consumer tiers typically do not, and without a DPA you have no contractual basis for claiming the data is gone.
Can an AI email writer cause a security breach?
Yes, and it rarely requires an attack. An employee who pastes a client email or a contract into an AI writing tool to clean up the wording has already sent that content to a third party, and if it contained regulated or contractually protected information, the exposure happened at the paste. That is the realistic failure mode for most small businesses: not a sophisticated compromise of the AI vendor, but ordinary staff moving sensitive text into a tool nobody reviewed.
What questions should I ask to evaluate an artificial intelligence company or vendor?
Five, and you should have answers before the tool touches business data. Does the vendor have a signed DPA with your organization? What data does the tool collect, and where is it stored? Is its security posture documented through a SOC 2 report, ISO 27001 certification, or equivalent? Does using it create obligations under HIPAA, CMMC, or applicable state privacy law? Is there an audit log of what was submitted? A vendor who answers those vaguely has given you an answer.
We need an AI security approach that non-technical staff can actually manage. Where do we start?
You do not need a data privacy attorney on staff. You need a repeatable process: inventory what is in use, classify which of your data is sensitive or regulated, add a short DPA review before any AI tool gets deployed, name AI tools explicitly in your acceptable use policy, and train your team on why the guardrails exist. In our experience the approved path has to be genuinely faster than the workaround, or people route around it and you are back to shadow AI within a quarter.