Guides

AI Tools Privacy & Security: What You Need to Know

Updated 2026-03-13

AI Tools Privacy & Security: What You Need to Know

Every time you type a prompt into an AI tool, you are sending data to a server owned by someone else. That data might include proprietary business information, personal details, confidential code, customer records, or sensitive strategic plans. What happens to that data after it leaves your device is one of the most important and least understood aspects of AI tool adoption.

This guide covers the privacy and security landscape of AI tools in concrete, practical terms. It explains data retention policies, training data usage, the differences between consumer and enterprise tiers, compliance certifications, on-premise alternatives, and how to audit your organization’s AI tool usage. No vague reassurances — just the specifics you need to make informed decisions.

Privacy policies and security practices change. The principles in this guide are durable, but verify specific vendor policies directly before making decisions based on them.

How AI Tools Handle Your Data

Understanding the data lifecycle of an AI tool is the starting point for any privacy assessment. When you send a prompt to an AI tool, the data passes through several stages, each with its own privacy implications.

The Data Lifecycle

Input transmission. Your prompt travels from your device to the vendor’s servers. During transit, data should be encrypted using TLS 1.2 or higher. This is standard practice and virtually all major AI tools implement it. The risk at this stage is minimal if the vendor uses modern encryption.

Processing. The AI model processes your input on the vendor’s infrastructure. During processing, your data exists in memory on the vendor’s servers. In most cases, multiple users’ requests are processed on shared infrastructure, though enterprise tiers may offer dedicated instances.

Output generation. The model generates a response, which is transmitted back to your device. The same TLS encryption protects the return trip.

Storage and logging. This is where the critical privacy questions arise. Most AI tools store your inputs and outputs for some period after the interaction. Reasons include safety monitoring, abuse prevention, debugging, quality improvement, and model training. The duration, purpose, and accessibility of this storage vary significantly by vendor and tier.

Model training. Some vendors use stored interactions to train future model versions. This is the most consequential privacy concern: if your data is used for training, fragments of your input could theoretically influence the model’s future outputs, potentially exposing information to other users. The probability is low for any single interaction, but the principle matters for organizations handling sensitive data.

The Training Data Question

The most important privacy question for most users is: Is my data used to train the model?

The answer depends on the vendor and your subscription tier.

Consumer / free tiers generally allow data to be used for training unless you explicitly opt out. Most vendors provide an opt-out mechanism, but it is not always easy to find or enable.

Business / enterprise tiers generally do not use customer data for training. This is a primary selling point of business plans and is typically documented in the data processing agreement (DPA).

API access varies by vendor. Some API tiers default to no training data usage; others require an explicit opt-out.

VendorConsumer Tier TrainingBusiness Tier TrainingAPI Training Default
OpenAI (ChatGPT)Yes, opt-out availableNoNo (by default)
Anthropic (Claude)Yes, opt-out availableNoNo
Google (Gemini)Yes, opt-out in some casesNoNo (with DPA)
Microsoft (Copilot)Varies by productNoNo (with DPA)
MidjourneyYes (images are public by default)Private mode in higher tiersN/A
Stability AIN/A (open-source models)N/AN/A

Practical implication: If you handle any data that should not be used for AI training — customer information, proprietary code, internal documents, financial data — either use a business tier with explicit no-training guarantees, use the API with training disabled, or run a local model.

Data Retention Policies

Even if your data is not used for training, it may still be stored by the vendor for safety monitoring, abuse prevention, or debugging purposes.

Retention Periods by Vendor

VendorConsumer RetentionBusiness RetentionZero-Retention Option
OpenAIUp to 30 days (API), longer for ChatGPTConfigurableAvailable via API
AnthropicUp to 30 daysConfigurableAvailable via API
GoogleVaries by productConfigurableAvailable for some services
MicrosoftVaries by productConfigurable with DPAAvailable in some configurations

What “zero retention” means. Some vendors offer zero-retention API options where your data is not stored after the response is generated. This is the strongest privacy guarantee short of running a model locally. However, verify that zero retention applies to all data processing stages, not just the final storage — some implementations still briefly log data for safety filtering before deletion.

What retention does not mean. Data that is “retained for 30 days” is typically retained for safety monitoring and abuse prevention, not for browsing by vendor employees. Access is usually restricted and logged. However, the data does exist on the vendor’s servers during the retention period, which matters for compliance and risk assessment.

Conversation History and Memory

Some AI tools maintain conversation history and memory features that persist across sessions. These are convenient but have privacy implications.

ChatGPT Memory stores facts about you across conversations to personalize responses. This data persists until you delete it. While convenient, it means the system accumulates a profile of your interests, preferences, and potentially sensitive information over time.

Claude Projects store uploaded documents and conversation context within a project. This data persists as long as the project exists.

Practical guidance: Regularly review and clear conversation history, memory, and stored files. Do not rely on AI tool memory for sensitive information — treat these features as convenience rather than secure storage.

Consumer vs. Enterprise: The Privacy Gap

The privacy difference between consumer and enterprise AI tiers is substantial. Understanding this gap is essential for any business use of AI tools.

What Consumer Tiers Provide

  • Basic encryption in transit and at rest
  • Opt-out from training (if you find and enable it)
  • Standard data retention (often 30-90 days)
  • No admin controls or audit logging
  • No SOC 2 or compliance certifications
  • No data processing agreement
  • No data residency guarantees
  • No dedicated infrastructure

What Enterprise Tiers Provide

  • All consumer protections plus:
  • No training on customer data (contractual guarantee)
  • Configurable data retention (including zero retention)
  • SSO integration with your identity provider
  • Admin controls (usage policies, content filters, user management)
  • Audit logging (who used what, when)
  • SOC 2 Type II certification
  • GDPR compliance with DPA
  • Data residency options (choose processing region)
  • Dedicated or isolated infrastructure (in some cases)
  • BAA for HIPAA compliance (from select vendors)
  • Custom content moderation policies
  • SLA with uptime guarantees

The Mid-Tier Gap

Many small and mid-size businesses fall into a gap: they need better privacy than consumer tiers provide, but enterprise plans are priced for large organizations with hundreds of users. Some vendors address this with “Business” or “Team” plans that provide core privacy features (no training, SOC 2, basic admin controls) at moderate price points.

Plan TypeTypical PriceNo-Training GuaranteeSOC 2Admin ControlsDPA
Consumer/Free$0-20/monthOpt-out availableNoNoNo
Team/Business$25-60/month per userYesOftenBasicUsually
EnterpriseCustom (often $100+/user/month)YesYesFullYes

Recommendation for small businesses: At minimum, use a Team or Business tier for any work involving customer data, proprietary information, or regulated content. The incremental cost over consumer plans is modest compared to the privacy improvement.

Compliance and Certifications

Compliance certifications provide independent verification of a vendor’s security and privacy practices. Understanding what each certification means helps you assess vendor claims.

SOC 2 Type II

What it is: An audit by an independent accounting firm that verifies the vendor has implemented and maintained security controls over a sustained period (typically 6-12 months).

What it covers: Security, availability, processing integrity, confidentiality, and privacy controls.

Why it matters: SOC 2 Type II is the most widely recognized security certification for SaaS companies. It provides reasonable assurance that the vendor takes security seriously and has formal processes in place.

What it does not mean: SOC 2 certification does not guarantee that a specific product or feature is secure. It certifies the organization’s overall control environment. A company can be SOC 2 certified while still having vulnerabilities in specific products.

GDPR Compliance

What it is: The European Union’s General Data Protection Regulation sets rules for how organizations collect, process, and store personal data of EU residents.

Key requirements for AI tools:

  • Lawful basis for processing data
  • Data minimization (collect only what is necessary)
  • Right to access, rectify, and delete personal data
  • Data processing agreements (DPAs) with sub-processors
  • Data breach notification within 72 hours
  • Data protection impact assessments for high-risk processing

Practical impact: If your organization handles data of EU residents, your AI tools must be GDPR-compliant. This typically requires a business or enterprise tier with a DPA.

HIPAA Compliance

What it is: The Health Insurance Portability and Accountability Act sets rules for handling protected health information (PHI) in the United States.

Key requirement for AI tools: A Business Associate Agreement (BAA) between your organization and the AI vendor. Without a BAA, you cannot process PHI through the AI tool.

Which AI vendors offer BAAs: As of early 2026, a limited number of AI providers offer BAAs, typically only on their enterprise tiers. OpenAI, Anthropic, Google, and Microsoft offer BAAs for specific products and tiers.

Practical impact: Healthcare organizations and their business associates should only use AI tools that offer signed BAAs. Consumer-tier AI tools are categorically inappropriate for PHI processing.

ISO 27001

What it is: An international standard for information security management systems (ISMS).

Why it matters: ISO 27001 certification indicates that the vendor has a systematic approach to managing information security risks.

CCPA/CPRA Compliance

What it is: California’s consumer privacy laws giving residents rights over their personal information.

Practical impact: Similar to GDPR but specific to California residents. Relevant for any AI tool handling data of California-based users or customers.

On-Premise and Self-Hosted Alternatives

The strongest privacy guarantee is keeping your data on your own infrastructure. Open-source AI models make this feasible for many use cases.

Why Self-Host

  • Zero data exposure: Your prompts and outputs never leave your network
  • No training on your data: Guaranteed, by architecture rather than by policy
  • No vendor dependency: You control updates, availability, and configuration
  • Regulatory compliance: Simplifies compliance for data residency, HIPAA, and government requirements
  • Cost at scale: No per-token charges once infrastructure is in place

Self-Hosting Options

Ollama runs open-source models locally on Mac, Windows, and Linux. It requires no cloud infrastructure and operates entirely on your hardware. Combined with models like Llama 3 (8B or 70B), it provides a private, free AI assistant.

vLLM is a high-performance inference server for deploying open-source models in production. It supports batching, streaming, and multi-GPU deployment.

Text Generation WebUI provides a feature-rich web interface for running and chatting with open-source models locally.

LocalAI is an open-source drop-in replacement for OpenAI’s API that runs models locally. It allows you to use existing OpenAI-compatible tools and integrations with local models instead of cloud APIs.

Hardware Requirements for Self-Hosting

Model SizeRAM (CPU Inference)GPU VRAMUse Case
7-8B parameters8-16GB6-8GBBasic tasks, fast responses
13B parameters16-24GB10-16GBBalanced performance
34B parameters32-48GB24GB+Strong performance
70B parameters64-128GB40-48GB+Near-commercial quality
Image generation (SDXL)16GB+8-12GBStable Diffusion

Cost comparison: A capable local AI setup (desktop with an RTX 4090 GPU) costs roughly $2,000-3,000 as a one-time investment. At enterprise API pricing of $15 per million input tokens, a team generating 500,000 tokens per day would spend roughly $225/month on API costs, meaning the hardware investment pays for itself in 9-13 months. For lighter usage, the payback period is longer, and cloud-based tools may be more economical.

For details on running models locally, read our Complete Guide to AI Models.

Auditing Your Organization’s AI Usage

Many organizations discover that employees are using AI tools without authorization or awareness of the privacy implications. Conducting an AI audit is an essential step in managing risk.

Step 1: Inventory AI Tool Usage

Survey your organization to identify every AI tool in use, including:

  • Officially sanctioned tools (with organizational accounts)
  • Tools accessed with personal accounts for work purposes
  • Browser extensions with AI capabilities
  • AI features embedded in existing software (Notion AI, Grammarly, etc.)
  • API integrations built by your development team

You will likely find tools you did not know about. This is normal and not necessarily a problem — the goal is visibility, not punishment.

Step 2: Classify Data Sensitivity

For each AI tool identified, determine what types of data are being sent to it:

Sensitivity LevelExamplesAI Tool Requirements
PublicMarketing copy, published contentAny tool acceptable
InternalMeeting notes, project plans, internal docsBusiness tier minimum, no-training guarantee
ConfidentialCustomer data, financial records, proprietary codeEnterprise tier, DPA, SOC 2, specific retention policies
RegulatedPHI (HIPAA), financial data (SOX), EU personal data (GDPR)Enterprise tier with specific compliance certifications, BAA if HIPAA
RestrictedTrade secrets, M&A information, legal strategySelf-hosted only, or enterprise tier with zero retention and dedicated infrastructure

Step 3: Gap Analysis

Compare actual usage against your requirements:

  • Are employees using consumer tiers for confidential data?
  • Are regulated data types being processed through non-compliant tools?
  • Are there tools with no DPA in place?
  • Is conversation history accumulating sensitive information?
  • Are browser extensions processing data without awareness?

Step 4: Establish an AI Usage Policy

Based on your audit findings, create a clear policy that specifies:

  • Which AI tools are approved for each data sensitivity level
  • What types of data may not be submitted to any external AI tool
  • Who is responsible for reviewing and approving new AI tools
  • How to handle AI tool outputs that may contain inaccurate information
  • Incident response procedures if sensitive data is inadvertently submitted

Step 5: Implement Controls

Technical controls are more reliable than policy alone:

  • Network-level controls: Block unauthorized AI tool domains at the firewall or proxy level
  • DLP integration: Configure data loss prevention tools to detect sensitive data being sent to AI endpoints
  • Approved tool provisioning: Provide pre-configured, approved AI tool accounts to all employees so they have no incentive to use personal accounts
  • Browser extension management: Control which browser extensions can be installed on company devices
  • API key management: Centralize API key storage and monitor usage patterns

Practical Privacy Decisions by Use Case

Different use cases require different privacy postures. Here is a practical guide for common scenarios.

Content Creation (Blog Posts, Marketing Copy)

Risk level: Low. The data submitted is typically not sensitive — it consists of topic descriptions, outlines, and brand guidelines that are not confidential.

Recommended approach: Consumer or business tier of any major AI provider. No special privacy precautions needed unless the content involves unreleased product information or confidential strategy.

Code Development

Risk level: Medium to High. Source code may contain proprietary algorithms, security logic, API keys (accidentally), and architectural patterns that competitors could exploit.

Recommended approach: Business tier with no-training guarantee. Review prompts before submission to ensure no credentials or secrets are included. For highly sensitive codebases, use a self-hosted model or a tool with zero-retention API access.

Specific risk: Code completion tools (Copilot, Codeium, etc.) continuously send code context to their servers. Ensure you understand what code is being transmitted and that your plan provides adequate privacy protections.

Customer Data Analysis

Risk level: High. Customer data is subject to privacy regulations (GDPR, CCPA) and breach notification requirements.

Recommended approach: Enterprise tier with DPA, SOC 2 certification, and configurable data retention. Anonymize or pseudonymize data before submission when possible. Never submit raw customer PII (names, emails, phone numbers) to a consumer-tier AI tool.

Risk level: Very High. Legal documents contain confidential information protected by attorney-client privilege and work product doctrine.

Recommended approach: Enterprise tier with zero retention, or self-hosted model. Consult with your legal team about whether submitting documents to an external AI tool constitutes a waiver of privilege.

Healthcare (PHI Processing)

Risk level: Regulated. HIPAA violations carry substantial penalties.

Recommended approach: Enterprise tier with signed BAA only. Verify that the specific AI features you intend to use are covered by the BAA (some vendors cover only certain products). Self-hosted models eliminate the compliance complexity entirely.

Financial Data

Risk level: High to Regulated. Financial data may be subject to SOX, PCI-DSS, or industry-specific regulations.

Recommended approach: Enterprise tier with relevant compliance certifications. For payment card data (PCI), self-hosted models are strongly preferred.

Building a Privacy-First AI Policy

Organizations that want to use AI tools responsibly need a formal AI usage policy. Here is a framework for building one.

Policy Components

Scope and applicability. Define which employees, contractors, and teams the policy covers. Specify whether it applies to all AI tool usage or only to tools used with company data.

Approved tools list. Maintain a curated list of AI tools approved for use, organized by data sensitivity level. Update this list quarterly as new tools emerge and existing tools change their policies.

Data classification matrix. Define which types of data may be submitted to which types of AI tools. A simple three-tier system works for most organizations:

Data ClassificationApproved AI Tool TiersExamples
PublicAny tool, any tierPublished content, public marketing materials, general knowledge questions
InternalBusiness tier with no-training guaranteeInternal reports, meeting notes, project plans, non-sensitive code
Confidential/RegulatedEnterprise tier with zero retention, or self-hosted onlyCustomer PII, financial records, proprietary algorithms, legal documents, PHI

Prohibited uses. Explicitly list what employees should never submit to external AI tools: passwords, API keys, customer social security numbers, medical records (without BAA), attorney-client privileged communications, material non-public information.

Incident response. Define what employees should do if they accidentally submit sensitive data to an unapproved AI tool. The response should include notifying IT/security, documenting the incident, and assessing the potential impact.

Training requirements. Require AI privacy training for all employees who use AI tools as part of their work. Update the training when policies or tools change.

Sample Policy Language

Here is example language you can adapt for your organization’s AI policy:

“Employees may use AI tools approved by the IT department for work-related tasks. Before submitting any data to an AI tool, employees must verify that the tool is approved for the data’s classification level. Customer personal information, financial data subject to regulatory requirements, and information covered by confidentiality agreements must not be submitted to any AI tool without prior approval from the data protection officer. All AI tool usage involving company data must use business or enterprise tier accounts provisioned by the IT department. Personal AI tool accounts must not be used for work purposes.”

Policy Enforcement

Policies without enforcement mechanisms are suggestions. Consider implementing:

  • Technical controls: Browser extensions or proxy rules that block unauthorized AI tool domains
  • Monitoring: Log analysis to detect data submissions to unapproved AI endpoints
  • Regular audits: Quarterly reviews of AI tool usage patterns
  • Accountability: Clear consequences for policy violations, scaled to severity

Vendor Security Assessment Checklist

When evaluating a new AI vendor’s security posture, use this checklist to structure your assessment.

Infrastructure Security

  • Does the vendor use a recognized cloud provider (AWS, Azure, GCP) with established security certifications?
  • Is data encrypted at rest and in transit?
  • What encryption standards are used? (AES-256 for data at rest, TLS 1.2+ for transit are current minimums)
  • Does the vendor offer dedicated (single-tenant) infrastructure, or is everything shared (multi-tenant)?
  • Where are the vendor’s data centers located? Can you choose a specific region?

Access Controls

  • Does the vendor implement role-based access control internally?
  • How many vendor employees can access customer data?
  • Under what circumstances can vendor employees view customer conversations or data?
  • Is internal access logged and audited?
  • Does the vendor perform background checks on employees with data access?

Incident Response

  • Does the vendor have a documented incident response plan?
  • What is the breach notification timeline? (GDPR requires 72 hours; your requirements may be stricter)
  • Has the vendor experienced any security incidents? If so, how were they handled?
  • Does the vendor carry cyber insurance?
  • Is there a public security contact or bug bounty program?

Third-Party Risk

  • Does the vendor use sub-processors that handle your data?
  • Who are the sub-processors, and what are their security certifications?
  • Does the vendor notify you when sub-processors change?
  • Can you opt out of specific sub-processors?

Business Continuity

  • What is the vendor’s uptime SLA?
  • What happens to your data if the vendor goes out of business?
  • Can you export all your data at any time?
  • Does the vendor provide data portability in standard formats?

Privacy Implications of Specific AI Use Patterns

Beyond the general principles, certain common AI usage patterns carry specific privacy implications worth understanding.

RAG (Retrieval-Augmented Generation)

Many businesses upload documents to AI tools to create searchable knowledge bases. The documents are indexed, and the AI retrieves relevant passages to answer questions. This means the vendor processes and stores not just your queries but your entire document corpus.

Privacy implication: Every document you upload to a RAG system is processed, indexed, and stored by the vendor. Ensure your documents do not contain embedded sensitive information (metadata, tracked changes, hidden text) before uploading.

Fine-Tuning

Some vendors allow you to fine-tune models with your data. This creates a custom model that reflects your data’s patterns, terminology, and style.

Privacy implication: Fine-tuning embeds your data’s characteristics directly into a model. If the fine-tuned model is not properly isolated, there is a theoretical risk that your data patterns could leak. Ensure that fine-tuned models are strictly private and not shared with other customers.

Browser Extensions and Plugins

AI browser extensions (Grammarly, various writing assistants, AI summarizers) process page content in real time. This means the extension sees everything you see in your browser — including sensitive web applications, email content, and internal tools.

Privacy implication: A browser extension with broad permissions can capture passwords, financial data, and confidential business information from any page you visit. Audit the permissions of every AI browser extension and remove any that request more access than their function requires.

Embedded AI in Existing Tools

Many software vendors are adding AI features to existing products (Notion AI, Salesforce Einstein, Microsoft Copilot for 365). These features process data that already exists within the platform.

Privacy implication: When an existing tool adds AI features, it may send data to new third-party AI providers (sub-processors) that were not part of the original data processing agreement. Review updated terms of service and DPAs when your vendors announce AI features.

Emerging Privacy Concerns

Several AI privacy issues are evolving and worth monitoring.

Inference Attacks

Researchers have demonstrated that it is sometimes possible to extract training data from AI models through carefully crafted prompts. While major vendors implement safeguards against this, the risk is not zero. This reinforces the importance of no-training guarantees — if your data was never used for training, it cannot be extracted through inference attacks.

AI Agents and Tool Use

AI agents that can browse the web, execute code, and interact with external services create new privacy vectors. When an AI agent accesses a website on your behalf, that website sees a request from the AI provider’s infrastructure, not from you. When an agent executes code, it may process your data in ways you did not explicitly authorize.

Multimodal Privacy

As AI tools process images, audio, and video in addition to text, the privacy surface expands. A screenshot submitted for analysis may contain more sensitive information than the user realizes — email addresses, notification content, file names, and system information visible in the UI.

Cross-Tool Data Flows

When AI tools are connected via automation platforms (Zapier, Make), data flows between multiple vendors. Each hop adds another vendor to your data processing chain, each with its own privacy policies and retention practices. Audit these flows carefully.

Key Takeaways

  • The most consequential privacy decision is whether your data is used for AI model training. Consumer tiers generally allow it (with opt-out); business and enterprise tiers generally prohibit it by contract.
  • Data retention varies from zero retention (API options from some vendors) to indefinite storage (conversation history features). Understand your vendor’s retention policy and configure it appropriately for your data sensitivity.
  • The privacy gap between consumer and enterprise tiers is substantial. For any business use involving non-public data, a Team or Business tier is the minimum appropriate choice.
  • Self-hosted open-source models (Llama 3 via Ollama, for example) provide the strongest privacy guarantee by keeping all data on your own infrastructure, with no external data transmission at all.
  • Audit your organization’s AI tool usage regularly. Employees are likely using tools you are not aware of, potentially submitting sensitive data to consumer-tier services without appropriate privacy protections.

Next Steps


This content is for informational purposes only and reflects independently researched privacy and security principles. Vendor policies, certifications, and compliance status change — verify current details directly with vendors before making security decisions.