LLM Data Privacy and Security for Wisconsin Businesses

LLM data privacy comes down to one question: where does the information your team types into an AI tool go, and who can see it afterward? The safe answer is to decide in advance which data may go into which tool, use business-grade services with written data-handling terms, and enforce those rules with access controls, not good intentions. This guide covers how data gets exposed, how the main deployment options differ, what to check in a vendor contract, and which safeguards matter most for a small or mid-sized company.

TL;DR

Anything your staff paste into a public AI tool should be treated as released outside the company, according to the Cyber Readiness Institute's guidance for small and medium-sized businesses.
Data can leak through prompts, outputs, training data, system prompts, logs and retrieval of documents a user should never see.
Business-grade and private deployments reduce exposure, but only when contracts, retention terms and permissions back them up.
Start with a data classification policy, an AI acceptable use policy and clean file permissions. Tools come second.
Manufacturers, law firms, dental practices and financial firms carry the most regulated and confidential data, so they have the most to gain from getting this right early.

What data privacy and data security mean when you use an LLM
How sensitive data gets exposed
Public tools, enterprise services and self-hosted models
What to check before you sign with an AI provider
Safeguards that reduce the risk
Laws and rules that may apply
Our perspective
How Collett Systems helps
FAQ
Sources

What data privacy and data security mean when you use an LLM

The two terms overlap, but they are not the same job.

Data privacy is about what happens to personal and sensitive information. NIST's generative AI risk profile describes the risk as leakage, unauthorized use, disclosure or de-anonymization of biometric, health, location or other personally identifiable information. It also notes that most model developers do not disclose which data their models were trained on, so you often cannot know whether personal data was in the mix.

Data security is about who can reach the data and how it is protected: encryption, access control, monitoring and incident response. A tool can have strong security and still create a privacy problem if it keeps your data longer than you expected or uses it in ways you did not agree to.

For a business, both questions apply at four points: what goes into the prompt, what the model returns, what the provider stores, and what the model was trained on.

How sensitive data gets exposed

People tend to picture a hacker. In practice, most exposure is quieter. OWASP's LLM02:2025 entry on sensitive information disclosure lists what can leak: personal information, financial details, health records, confidential business data, security credentials, legal documents and proprietary source code.

A 2026 OWASP update adds that exposure is not limited to the chat window. It can also surface through tool-call arguments, retrieved document chunks, logs, telemetry and embeddings.

Here are the channels that matter most to a small or mid-sized business:

Channel	What happens	Example in a Wisconsin business
Prompts	Staff paste confidential content into a tool outside company control	An estimator pastes a customer's drawings and pricing into a public chatbot
Provider retention	The vendor stores prompts, files or logs longer than you assumed	A client contract is summarized in a tool that keeps uploads by default
Training data	A fine-tuned model reproduces content it was trained on	A model tuned on HR files repeats salary details to the wrong user
System prompt leakage	Adversarial prompts make the model reveal its own instructions or credentials	A support bot exposes internal scope rules or an embedded key
Retrieval boundary failure	An AI assistant searches documents the user is not authorized to see	A copilot answers a front-desk question with a partner's billing file

The last three channels in the table follow the pattern Drel describes: training data memorization, system prompt leakage and retrieval boundary failure. Drel also points out that the memorization risk is most concrete when an organization fine-tunes a model on its own internal data.

The retrieval problem is the one we see most often in small businesses, and it is not really an AI problem. It is a permissions problem that AI makes visible. An assistant that can read everything a user can read will surface every over-shared folder you have. We cover that in Before You Roll Out AI, Fix Your Permissions.

One more point from OWASP's 2026 guidance: once data has influenced a model's weights, embeddings or adapters, it can stay extractable even after you delete the source file. That makes erasure obligations under privacy laws harder to meet. So decide what goes in before it goes in.

Public tools, enterprise services and self-hosted models

Not every AI tool carries the same risk. The Cloud Security Alliance's zero trust guidance for LLMs frames it around who hosts the data and who is bound by what. With a software-as-a-service LLM, responsibility is shared and backed by contract. Without proper contractual terms, a supplier may use your enterprise data to train its models. When you host the model yourself, you control the data, but you also own the security work.

The European Data Protection Board describes three service models: LLM as a service through an API, where your data flows through the provider's systems; an off-the-shelf model you customize on a cloud platform; and a self-developed model on your own infrastructure, which gives full control but needs significant computing resources and expertise. The EDPB is a European body, so treat its guidance as a technical reference, not U.S. law.

In plain terms, here is how the options compare for a business:

Option	Where your data goes	Main strength	Main watch-out
Free or consumer chatbot	The provider's systems, under consumer terms	Easy and fast	Treat anything entered as public
Business or enterprise plan	The provider's systems, under business terms	Admin controls, written data-use commitments	Terms differ by vendor and must be read
Cloud-hosted private deployment	Your own cloud tenant	Strong control over data location and access	Needs configuration and monitoring
On-premises or local model	Your network	Data stays in your environment	You own patching, access control and monitoring

The Cyber Readiness Institute puts the line clearly: private GenAI tools give more data protection, but all your existing confidentiality and data protection policies still apply. A private tool does not replace policy.

Self-hosting also has a visibility cost. Palo Alto Networks notes that self-managed models give more control and lower compliance risk for regulated industries, but they also create blind spots, because any developer can run a model on a virtual machine without central monitoring. Put another way, an unmanaged local model can be a bigger problem than a well-managed cloud service.

What to check before you sign with an AI provider

Most privacy outcomes are set by the contract and the account settings, not the model. Before your team uses a tool with business data, get written answers to these questions. The checklist draws on Harvard's guidance on managing generative AI systems and Need to Know AI's vendor contract guide.

Is training on your content off by default? Or does it depend on a setting someone has to find and switch?
How does the contract treat different kinds of data? Customer content, usage data, telemetry, feedback and de-identified data can each carry different rules.
What is the retention period? Ask about uploaded files, derived outputs, logs and backups, not just chat history.
What does deletion actually mean? Find out the normal deletion period, how long backups persist, and what the vendor keeps for legal, security or billing reasons.
Can deletion be shown? Some vendors can provide an administrative report or audit record. OCR Direct calls retention one of the most overlooked procurement traps.
Is the business service separate from the consumer service? Staff often sign in to personal accounts by mistake, which lands the data under consumer terms.
What happens on exit? Confirm the off-boarding and data-deletion process, plus how incidents are reported to you.

Terms change often. One published comparison of API data handling shows that providers differ on retention windows and zero-data-retention options, so read the vendor's current terms instead of relying on a summary from last year, including this one.

Safeguards that reduce the risk

Good controls are mostly ordinary IT discipline applied to a new kind of tool. Harvard's guidance calls for data classification requirements, least-privilege access, limited context and memory, isolated trust boundaries, and an inventory with named owners. It also says to treat prompts, outputs, logs and retained context as organizational data. Here is how that translates to a company of 20 to 200 people.

Classify your data first

You cannot tell staff what is safe to paste if you have not defined what "sensitive" means. A simple scheme with three or four labels is enough: public, internal, confidential and regulated. Then state which labels may go into which tools. If you are building the scheme, this overview of data classification in an ISMS explains how the labels tie into a wider security program. Our own walkthrough is in Ship a Data Classification Policy.

Write an acceptable use policy people can follow

OWASP's governance checklist recommends publishing an acceptable use matrix for generative AI tools and enforcing data policies technically. A one-page matrix that lists approved tools, allowed data types and a named contact works better than a long document nobody reads. See our AI acceptable use policy guide for employers.

Fix permissions before connecting AI to your files

An AI assistant inherits the access of the person using it. Remove stale shares, tighten folders holding payroll, contracts, drawings and client files, and review who has admin rights. This is the single most useful step before any rollout.

Protect data in transit and at rest

AWS prescriptive guidance recommends that training sets, fine-tuning data and vector databases be encrypted and covered by fine-grained access controls, that AI data exchanges use TLS, and that PII and financial records be masked or tokenized. Those are sensible baselines whether you use AWS or not.

Scan and filter what goes in and out

For financial services, the FS-ISAC's guide recommends role-based or attribute-based access checks, output filtering, encryption, and prompt and response scanning to prevent leakage. The same ideas apply to any firm putting an AI assistant in front of client records.

Monitor, test and review

An AI deployment is not a one-time setup. OWASP's checklist recommends third-party audits and penetration testing for third-party providers, both at the start and on an ongoing basis. Keep an inventory of which AI tools are in use, who owns each, and what data each touches. Our AI risk assessment framework gives a practical way to score each use case.

Laws and rules that may apply

There is no single U.S. AI privacy statute. Existing rules apply to AI use just as they apply to any other handling of data. The FTC has said plainly that there is no AI exception to the law. In its Rite Aid matter, it said the company would have to stop using facial recognition technology if it could not control the risks to consumers.

What that means depends on your industry:

Law firms hold privileged and confidential client material. Pasting it into a consumer tool is a confidentiality problem before it is a technology problem. See our law firm cybersecurity guide and legal IT services.
Dental and healthcare practices handle health information. Whatever tool touches patient data needs the right agreements and settings in place before staff use it. Confirm requirements with your compliance advisor.
Financial firms face safeguarding duties for customer information. Ask your compliance counsel how your obligations apply to any AI tool that sees client records.
Manufacturers often hold customer designs, pricing, export-controlled or contract-restricted data. Customer agreements can restrict what you may share with outside tools even when no law does. Our AI adoption guide for Wisconsin manufacturers goes deeper.
Businesses with California customers should note that, per Wiley's analysis, the CCPA's new automated decision-making regulations take effect January 1, 2027. They require pre-use notices and opt-out rights for certain chatbot uses.

We are an IT provider, not a law firm. Use this as a map of where to ask questions, and have counsel confirm which rules reach your business.

Our perspective

Most of the AI privacy problems we hear about are not exotic. A well-meaning employee pastes something into the wrong tool, or an assistant finds a folder that was shared too widely years ago. Both are management problems, and both are fixable.

Our approach is to treat AI as part of your infrastructure, not a side project. That means the same fixed, documented standard you would expect for email or backups: data classified, permissions cleaned up, approved tools named, and monitoring that runs around the clock. Because our managed IT services are built on a standardized, fully loaded stack at a fixed cost per user, security and compliance documentation are part of the service, not an add-on you negotiate later.

For manufacturers in particular, we pair that with AI strategy and governance, so you can use AI on the shop floor and in the office without handing your designs, pricing or customer data to a tool you cannot account for. The goal is simple: you get the benefit, and you still know where your data is.

Dustin Collett

How Collett Systems helps

If you want a clear picture of where your data stands before you approve any AI tool, start with our IT & Security Assessment. It gives you a documented view of your environment, so decisions about AI rest on facts. If you want ongoing coverage, our managed IT services include 24/7 monitoring, proactive support and security management for businesses across Southeastern Wisconsin, and our team handles AI strategy and governance for Wisconsin manufacturers.

Book the IT & Security Assessment or get a quick read on your exposure with the free IT risk score.

FAQ

Is it safe to put customer data into ChatGPT or other AI chatbots?

Not into a public or consumer tool. The Cyber Readiness Institute says information entered into public GenAI tools can be stored, processed or reused by third parties, and equates it with publicly releasing it. If your business wants AI on sensitive data, use a business-grade or private deployment with written data-handling terms, and set the rules in your acceptable use policy.

Does an enterprise AI plan fully solve the privacy problem?

It reduces it, but it does not remove it. Enterprise plans typically add administrative controls and clearer commitments on training and retention, but you still need to read the contract, confirm settings, and clean up the permissions the tool inherits. Existing confidentiality policies still apply to private tools.

Does self-hosting an LLM keep data private?

It keeps data under your control, but only if you secure it. A self-hosted setup can still send document chunks or queries to an outside service through a plugin, an embedding service or a backup job. You also take on monitoring and patching, so the model has to be inventoried and managed like any other server.

What should we do first?

Classify your data, publish a one-page list of approved AI tools and allowed data types, and review file permissions. Those three steps close most of the exposure for small and mid-sized businesses. After that, review vendor contracts and set up monitoring.