Partnership Jul 29, 2026

Data Security in AI Chatbots: Enterprise Guide 2026

Discover what data security in AI chatbots means for enterprises. Learn key risks and immediate mitigations to protect sensitive data.

TL;DR:

Data security in AI chatbots involves comprehensive controls across input, inference, storage, and training stages to protect sensitive data. Proper vendor management, technical safeguards, and user policies are essential to prevent risks like data leakage, prompt injection, and cross-tenant exposure. Implementing layered security, contractual protections, and ongoing audits reduces enterprise exposure effectively.

Data security in AI chatbots is the set of technical, operational, and contractual controls that keep user and enterprise data confidential, integral, and available across every stage of the chatbot lifecycle — from the moment a user types an input through inference, storage, and any downstream training or retention. For security and product leaders, the practical priority is this: assume your chatbot is already processing sensitive data, and act accordingly.

Top 3 risks to address first:

Data leakage and training misuse — Most widely used chatbots train on user conversations by default; enterprise or API tiers are generally the exception.
Prompt injection — attackers craft inputs that override system instructions, exfiltrate context, or manipulate downstream actions.
Unauthorized access and cross-tenant leakage — inadequate access controls expose one tenant’s conversation history to another.

Immediate mitigations: Enable PII redaction at the input layer before data reaches the LLM, and switch to an enterprise API tier or negotiate a Zero Data Retention (ZDR) agreement with your provider today. Then work through the 30/90/180-day checklist below to build a full program.

What does “data security” actually mean for AI chatbots?
What are the biggest security risks specific to AI chatbots?
Which technical controls actually protect chatbot data?
How do deployment models and vendor choices affect your security posture?
Which U.S. regulations apply to your chatbot deployment?
How do you test chatbot security and respond to AI-specific incidents?
Why governance and user training matter as much as technical controls
What does a realistic implementation timeline and budget look like?
Your 30/90/180-day chatbot security checklist
How Monobot approaches data security for voice and chat agents
Key Takeaways
The trade-offs security leaders actually face
Monobot gives your AI agents a security-first foundation
Useful sources and references
FAQ

What does “data security” actually mean for AI chatbots?

Data security in AI chatbots covers the full lifecycle of information: input collection, inference processing, storage, and any training or retention that follows. Each stage introduces distinct risks, and protecting data means applying controls at every point, not just at the front door.

A typical enterprise chatbot architecture moves data through several layers. A user’s message travels from the client app through an API gateway, hits a pre-processing layer (where redaction and filtering should happen), then reaches the LLM provider for inference. The response returns through the same path, while logs, transcripts, and analytics land in storage and observability systems. Integration APIs connect the chatbot to CRMs, ticketing systems, and databases, each of which can become a secondary exposure point.

The assets you need to protect at each stage:

Asset	Where it lives	Primary risk
PII (names, emails, SSNs, health data)	User inputs, transcripts, logs	Leakage, training misuse, breach
Credentials and tokens	Integration configs, session context	Exfiltration via prompt injection
Conversation logs and transcripts	Storage, analytics pipelines	Unauthorized access, eDiscovery exposure
Model artifacts and fine-tuning data	LLM provider, private instances	Model inversion, data poisoning
Integration API keys and secrets	Middleware, environment configs	Lateral movement, unauthorized actions
System prompts and policy configs	Pre-processing layer	Prompt extraction, policy bypass

Vendor terms deserve specific attention here. Most consumer-tier chatbots, including the default tiers of widely used platforms like OpenAI’s ChatGPT, retain conversation data and may use it to improve models unless you explicitly opt out or upgrade to an enterprise agreement. Proofpoint’s security guidance similarly emphasizes that data shared with third-party AI services is governed by the provider’s terms, not yours, until you negotiate otherwise. Treat every third-party chatbot service as a vendor that requires formal approval and contractual protections, not just a productivity tool.

What are the biggest security risks specific to AI chatbots?

The risks that cause the most business damage are data leakage, prompt injection, training and retention misuse, model inversion, unauthorized access, and cross-tenant leakage. Egnyte’s analysis of LLM-based chatbot vulnerabilities confirms these as the primary attack surfaces, and the OWASP Top 10 for LLMs provides the standard testing baseline for each.

Risk	Attack vector	Business consequence	Detection signal
Data leakage	Sensitive data in inputs sent to external LLM	Regulatory breach, reputational damage	DLP alert on outbound API payload
Prompt injection	Crafted user input overrides system instructions	Data exfiltration, unauthorized actions	Anomalous output patterns, policy bypass logs
Training/retention misuse	Conversations used to train shared models	IP exposure, PII in model outputs	Vendor audit; opt-out confirmation failure
Model inversion	Repeated queries reconstruct training data	Exposure of proprietary or personal data	High-frequency similar queries from single source
Unauthorized access	Weak RBAC, stolen tokens	Cross-user or cross-tenant data exposure	Auth logs, session anomalies
Cross-tenant leakage	Shared inference infrastructure	One customer’s data visible to another	Context bleed in responses, audit log gaps

Real-world consequences are not hypothetical. Samsung’s 2023 internal incident, where engineers pasted proprietary source code into ChatGPT, illustrates how quickly sensitive data enters external training pipelines. In the healthcare space, peer-reviewed research published in PMC documents significant security and privacy gaps when medical chatbots handle patient data, particularly around session persistence and inadequate access controls. Stanford HAI has publicly warned that users routinely share more than they realize with AI chatbots, and that the downstream use of that data is rarely transparent.

The OWASP Top 10 for LLMs is the most practical starting point for prioritizing your testing backlog. Prompt injection (LLM01) and sensitive data exposure (LLM06) consistently rank as the highest-impact items for enterprise deployments.

Which technical controls actually protect chatbot data?

The single most effective pattern is defense-in-depth: input filtering and redaction at the pre-processing layer, least-privilege access controls throughout, and continuous monitoring of inputs, outputs, and provider configurations. No single control is sufficient on its own.

Implementation checklist

Input redaction and PII masking — deploy a dedicated redaction layer (tools like Alectura automate PII removal from text before it reaches the LLM) before any data touches the model.
Prompt filters and output sanitization — block known injection patterns at the API gateway; validate and sanitize model outputs before they reach users or downstream systems.
Tokenization — replace sensitive identifiers (SSNs, card numbers) with tokens in the pre-processing layer; never pass raw sensitive identifiers to the LLM.
TLS 1.3 in transit — enforce TLS 1.3 for all API calls between your application and the LLM provider; reject older protocol versions.
AES-256 at rest — apply AES-256 encryption to all stored transcripts, logs, and model artifacts.
HSM/KMS key management — manage encryption keys through a hardware security module or cloud KMS (AWS KMS, Azure Key Vault, Google Cloud KMS); rotate keys on a defined schedule.
RBAC and ABAC — enforce role-based and attribute-based access controls on who can query the chatbot, access transcripts, and modify system prompts.
Ephemeral session contexts — clear session memory at conversation end; do not persist user context across sessions unless explicitly required and controlled.
DLP integration — connect a data loss prevention tool to the API gateway to inspect and block sensitive payloads before they leave your perimeter.
Model isolation — for regulated workloads, run the LLM in a dedicated instance or private cloud rather than shared multi-tenant infrastructure.
Training opt-out and contract terms — confirm your provider’s training opt-out is active and documented; include contractual data-use restrictions in your vendor agreement.

Pro Tip: Audit your provider’s training and retention settings every quarter, not just at onboarding. Provider terms change, and a setting that was opted out at deployment may revert after a platform update. Build this check into your standard vendor review cycle.

For observability, log input hashes (not raw inputs), output classifications, session IDs, and access events. Never log raw PII or credentials. AWS prescriptive guidance recommends a deterministic broker or mediation layer between users and the LLM to sanitize inputs, enforce policy-based filtering, and prevent the model from directly accessing or modifying protected systems. That architectural pattern is one of the most effective structural controls available.

How do deployment models and vendor choices affect your security posture?

Your vendor model, retention policy, and contractual controls drive most of the residual risk in any chatbot deployment. Architectural choices made at procurement time are far harder to fix after go-live than technical controls applied in code.

Deployment model comparison:

Hosted consumer API (e.g., default ChatGPT tiers): Lowest cost, fastest deployment, highest risk. Data may be used for training; retention windows are set by the provider; audit rights are minimal. Acceptable only for non-sensitive, non-regulated use cases.
Enterprise API with Zero Data Retention: Provider contractually commits to not training on your data and deletes inputs/outputs after inference. This is the minimum acceptable tier for most enterprise use cases. Verify ZDR is active and documented — privacy research confirms that deletions do not always remove data from human-reviewed stores or backups, so contractual audit rights matter as much as the ZDR flag itself.
Private cloud deployment: Your data stays within your cloud tenant; you control retention, logging, and access. Higher cost and operational overhead, but significantly reduced third-party risk. Preferred for regulated industries.
On-premises or self-hosted LLM: Maximum control, maximum cost. Data never leaves your infrastructure. Required for the most sensitive regulated workloads (classified data, certain HIPAA scenarios). Model updates and security patches become your responsibility.

Vendor due-diligence checklist:

Data-use policy: does the vendor train on your data by default, and how do you opt out?
Retention windows: how long are inputs, outputs, and transcripts stored, and where?
Subprocessor list: which third parties receive your data, and under what terms?
Breach notification: what is the contractual SLA for notifying you of a breach?
Certifications: SOC 2 Type II, ISO 27001, HIPAA BAA availability, FedRAMP (if applicable).
Audit rights: can you request logs, certifications, and penetration test results?

Minimum contract clauses to negotiate: data segregation guarantees, training opt-out confirmation, retention limits with deletion verification, breach notification within 72 hours, and annual audit rights. For regulated data, a Business Associate Agreement (HIPAA) or Data Processing Agreement (CCPA/CPRA) is non-negotiable.

Which U.S. regulations apply to your chatbot deployment?

The applicable law depends on what data your chatbot processes and in what context. Data type plus use case determines regulatory exposure — there is no single universal framework.

Key U.S. regulatory touchpoints:

HIPAA — applies when your chatbot processes electronic protected health information (ePHI). You must execute a Business Associate Agreement with any LLM provider that handles ePHI. Healthcare chatbots introduce significant security and privacy risks that remain understudied in practice; peer-reviewed research in PMC documents gaps in how medical chatbots handle session persistence and access controls. Default consumer tiers are not HIPAA-eligible.
CCPA/CPRA — applies to California consumers’ personal information. Chatbots that collect, process, or share personal data trigger disclosure obligations, opt-out rights (for sale or sharing), and data minimization requirements. Your privacy policy must disclose AI-assisted data collection.
PCI DSS — if your chatbot touches cardholder data (card numbers, CVVs, expiration dates), PCI scope applies. The safest approach is to route payment data through a tokenization layer before it reaches the chatbot, keeping the LLM out of PCI scope entirely.
FERPA — applies to student education records. Chatbots deployed in educational institutions must not expose student data to unauthorized parties; vendor agreements must include FERPA-compliant data handling terms.
FTC Act (Section 5) — the FTC treats deceptive or unfair data security practices as violations. Chatbots that misrepresent how data is used, or that fail to implement reasonable security measures, create FTC enforcement exposure. Proofpoint’s security guidance aligns with FTC expectations: treat AI data handling as a security control, not just a product feature.

Compliance action items:

Classify all data your chatbot may encounter before deployment; map it to applicable regulations.
Execute BAAs and DPAs with all LLM providers before processing regulated data.
Set contractual retention limits and verify deletion procedures in writing.
Maintain logs sufficient for eDiscovery and regulatory subpoena response.
For consumer-facing chatbots processing regulated data, default to enterprise API tiers or private hosting.

This article is general information, not legal or compliance advice. Confirm current regulatory requirements with qualified legal counsel for your specific situation.

How do you test chatbot security and respond to AI-specific incidents?

Red teaming combined with prompt-injection tests and API authorization pen testing is the minimum viable testing program for any production chatbot. Unit tests alone miss the adversarial patterns that cause real breaches.

Testing plan

Scope and threat model — identify all data types the chatbot can access, all downstream systems it can write to, and all user roles that interact with it.
Prompt injection test cases — craft inputs designed to override system prompts, extract context, or trigger unauthorized actions. Use structured adversarial test cases in every QA and security cycle, not just at launch.
Context poisoning tests — inject malicious content into the chatbot’s knowledge base or retrieval context and verify it does not influence outputs.
Cross-tenant queries — in multi-tenant deployments, verify that one tenant’s session context cannot be accessed by another.
API authorization testing — confirm that all API endpoints enforce authentication and that privilege escalation is not possible through crafted requests.
Frequency and metrics — run prompt-injection tests with every major model or prompt update; run full pen tests at least annually. Track mean time to detect anomalous outputs and mean time to contain.

Monobot’s AI behavior regression testing playbook provides a practical framework for structuring these test cycles within a CI/CD pipeline.

Incident response playbook

Containment: revoke API keys immediately; isolate affected model instances; disable the chatbot endpoint if data exfiltration is confirmed or suspected.
Evidence capture: preserve raw logs, session transcripts, and API call records before any remediation that could overwrite them.
Notification timeline: assess regulatory reporting triggers (HIPAA 60-day breach notification, state breach laws, FTC); notify legal counsel within 24 hours of confirmed incident.
Post-incident root-cause analysis: determine whether the breach originated from a prompt injection, a misconfigured access control, a vendor-side retention failure, or a training data exposure.

Run tabletop exercises that include your chatbot as an attack vector at least twice a year. Most enterprise IR runbooks were written before LLMs were in the stack; update them explicitly to cover prompt injection, context leakage, and model manipulation scenarios.

Why governance and user training matter as much as technical controls

People are the weakest link. UCI Information Security documents this directly: users routinely paste sensitive data into chatbots to get accurate outputs, and technical controls are necessary precisely because human behavior is difficult to change through training alone. Governance without enforced technical guardrails is not a security program.

Policy checklist:

Acceptable use policy: define which data classifications are permitted in chatbot inputs (e.g., public and internal only; never confidential or restricted).
Data classification and labeling: label all enterprise data before it reaches users who interact with chatbots.
Vendor approval process: require security review and legal sign-off before any new AI chatbot tool is deployed.
Auditing cadence: review chatbot usage logs and access controls quarterly.

Training guidance:

Use short, scenario-based modules (10 minutes or less) rather than annual compliance marathons.
Show concrete banned-content examples: “Do not paste customer SSNs, health records, or internal source code into any AI chatbot.”
Add in-app warnings at the chatbot UI level that remind users of data classification rules before they type.
Provide role-specific rules: developers need guidance on system prompt security; support staff need guidance on what customer data they can reference.

Pro Tip: Build technical guardrails that make the right behavior the default. A redaction layer that automatically strips PII from inputs is more reliable than a policy that asks users to remember not to paste it. Instrument the system; don’t rely on memory.

Only a small minority of organizations had fully embedded AI governance while a large majority used AI in some capacity. That gap is where most enterprise chatbot breaches originate.

What does a realistic implementation timeline and budget look like?

A full enterprise chatbot security program typically phases across 30, 90, and 180 days, moving from quick risk reduction to structural controls. The timeline depends on your starting point, but most organizations can achieve meaningful risk reduction in the first 30 days with minimal budget.

Timeline and cost drivers:

30-day triage: Enable input redaction, activate provider opt-outs, conduct short vendor due diligence on your top chatbot vendors. Cost: primarily staff time; redaction tools range from open-source libraries to commercial services.
90-day fixes: Implement RBAC and ABAC, integrate DLP and KMS, begin red-team prompt injection testing, update contracts (BAA/DPA) as needed. Cost: DLP and KMS licensing, red-team contractor fees if done externally.
180-day program: Deploy model isolation or private instances for regulated use cases, establish continuous monitoring and anomaly detection, schedule periodic third-party audits. Cost: highest tier; private cloud or on-prem hosting adds significant infrastructure cost but reduces residual risk proportionally.

Primary cost drivers:

Vendor tier: enterprise API or private hosting costs more than consumer tiers but is often the only compliant option for regulated data.
Integration complexity: connecting DLP, KMS, and SIEM to the chatbot pipeline requires engineering time.
Data classification effort: classifying existing data before deployment is often underestimated.
Red-team and testing frequency: monthly adversarial testing costs more than quarterly but catches issues faster.
Legal and contract work: BAA and DPA negotiation, vendor due diligence, and policy drafting require legal resources.

For a practical perspective on scoping AI security investments, the B2B AI SaaS guide from SwarmStack offers useful framing for business leaders evaluating vendor tiers and governance costs.

Your 30/90/180-day chatbot security checklist

Start with input redaction and provider opt-out. These two actions reduce the highest-impact risks (training misuse and PII leakage) with the least implementation effort, making them the right first move regardless of your current maturity level.

30-day actions (triage and quick wins)

Inventory all chatbot tools in use across the organization, including shadow IT deployments.
Identify high-risk use cases: any chatbot that touches PII, health data, financial data, or credentials.
Enable PII redaction at the input layer for all production chatbots.
Activate provider training opt-outs or upgrade to enterprise/ZDR tiers for all high-risk deployments.
Conduct short vendor due diligence on your top three chatbot vendors: data-use policy, retention windows, certifications.

Minimum success criteria: every high-risk chatbot has redaction enabled and a confirmed opt-out or ZDR agreement in place.

90-day actions (structural controls)

Implement RBAC and ABAC across all chatbot access points and admin interfaces.
Integrate DLP tooling with the API gateway to inspect and block sensitive payloads.
Deploy KMS-backed key management for all stored transcripts and logs.
Launch red-team prompt injection testing; document findings and remediation timelines.
Update or execute BAAs and DPAs with all vendors processing regulated data.

Minimum success criteria: access controls are enforced programmatically; at least one full red-team cycle is complete.

180-day actions (full program)

Deploy model isolation or private instances for all regulated use cases (HIPAA, PCI, FERPA).
Establish continuous monitoring and anomaly detection on chatbot inputs, outputs, and API calls.
Schedule periodic third-party security audits (at least annually).
Integrate chatbot-specific threat scenarios into enterprise IR runbooks and tabletop exercises.
Establish a quarterly review cycle for provider training settings, retention policies, and contract terms.

Minimum success criteria: regulated workloads run on isolated or private infrastructure; chatbot incidents are covered in the enterprise IR plan.

How Monobot approaches data security for voice and chat agents

Monobot’s platform is built with a defense-in-depth posture that maps directly to the controls described throughout this guide. For enterprises deploying AI voice and chat agents across customer service, IT helpdesk, HR, and other workflows, Monobot provides the architectural controls and observability needed to manage data security without sacrificing deployment speed.

Platform security features that align with this guide’s controls:

Input redaction and PII handling: Monobot’s agent architecture supports pre-processing controls that prevent sensitive data from being passed unfiltered to downstream LLM providers.
Real-time analytics and observability: Monobot’s voice analytics capabilities give security teams granular visibility into conversation patterns, enabling anomaly detection and audit trail generation.
RBAC and access controls: Role-based access controls govern who can build, modify, and review agents and their conversation data.
Enterprise SLA and data-use commitments: Monobot’s enterprise tier provides contractual data-use commitments aligned with the BAA and DPA requirements described in the compliance section.
Integrations with enterprise security tooling: Monobot connects with third-party tools including CRMs, ticketing systems, and analytics platforms, with integration permissions managed at the agent level.

A practical example: an IT helpdesk deployment using Monobot’s IT helpdesk automation can be configured to handle password reset requests and ticket routing without ever exposing raw credentials to the LLM. The agent collects the user’s identity, verifies it through an integrated identity provider, and triggers the reset action through a controlled API call, keeping sensitive credential data out of the conversation transcript entirely.

Pro Tip: When evaluating any AI agent platform for a regulated use case, request the vendor’s SOC 2 Type II report and a sample BAA before procurement. Monobot’s enterprise team can provide both.

Key Takeaways

Data security in AI chatbots requires layered technical controls, contractual protections, and continuous auditing of provider settings — no single measure is sufficient on its own.

Point	Details
Training opt-out is not set-and-forget	Most widely used chatbots train on conversations by default; verify opt-out or ZDR status regularly.
Redaction is the highest-ROI first step	Enable PII redaction at the input layer before any other control; it reduces leakage and training misuse simultaneously.
Governance gaps are widespread	Only 7% of organizations had fully embedded AI governance; close that gap with enforced technical guardrails, not training alone.
U.S. regulations are use-case specific	HIPAA, CCPA/CPRA, PCI, and FERPA each apply based on data type and context; classify data before deployment to determine which frameworks apply.
Monobot for secure agent deployment	Monobot’s enterprise tier provides RBAC, observability, and contractual data-use commitments for regulated voice and chat deployments.

The trade-offs security leaders actually face

Most chatbot security guidance reads as if the choice is between “secure” and “insecure.” The real trade-off is between speed and control, and between user experience and legal risk. Every enterprise I’ve seen move fast on chatbot deployment has eventually had to retrofit controls that should have been in the architecture from day one — and retrofitting is always more expensive than building it right.

The governance gap is the most underestimated risk. Technical controls get attention because they are measurable. Policies and vendor contracts get deferred because they require legal and procurement cycles that slow down product teams. But the Samsung incident and similar cases show that the fastest path to a breach is a productive employee with good intentions and no guardrails. The 30/90/180 checklist in this guide is designed to give security teams a defensible starting point that does not require a full program before you can reduce risk.

One more thing: involve legal, product, and infrastructure in the first 30 days, not after the first incident. The decisions that determine your regulatory exposure — which vendor tier, which data types, which retention window — are made at procurement, not at remediation. Get those stakeholders in the room early, and use the vendor due-diligence checklist above as the agenda.

Monobot gives your AI agents a security-first foundation

Securing a chatbot deployment is not just about locking down the LLM. It requires the right architecture, the right vendor commitments, and the right observability to catch problems before they become incidents. Monobot’s platform gives enterprise teams all three, with AI voice and chat agents that are built for regulated industries and production-grade security requirements.

With Monobot, you get granular RBAC, real-time conversation analytics, and enterprise data-use commitments out of the box. The AI agent builder lets your team configure agents with controlled integration permissions, keeping sensitive data out of the LLM context where it does not belong. For security teams evaluating platforms, Monobot’s enterprise tier includes the contractual protections — BAAs, DPAs, audit rights — that regulated deployments require.

Ready to see how Monobot handles security for your specific use case? Request a demo and bring your security requirements to the conversation.

Useful sources and references

These sources were selected for their prescriptive guidance, regulatory authority, and research depth. Use them directly in vendor due diligence conversations and technical remediation planning.

Source	Why it matters
EDPB: AI Privacy Risks and Mitigations in LLMs	European Data Protection Board’s technical analysis of LLM privacy risks; useful for understanding data minimization and retention principles applicable globally.
Stanford HAI: Be Careful What You Tell Your AI Chatbot	Policy-level warning from Stanford HAI on user behavior and data transparency; useful for governance and training program design.
PMC: Security Implications of AI Chatbots in Health Care	Peer-reviewed research on healthcare chatbot security gaps; essential reading for HIPAA compliance planning.
AI Chatbot Privacy Report	Documents default training practices across the 10 most-used chatbots; use to benchmark your vendor’s training opt-out status.
Egnyte: AI Chatbot Security Risks and Testing Best Practices	Practical risk taxonomy and OWASP Top 10 for LLMs alignment; use as a testing checklist baseline.
AWS Prescriptive Guidance: Security for Agentic AI	Architectural controls for agentic LLM systems including the deterministic broker pattern; use for infrastructure design reviews.
Glean: Best Practices for Securing AI Chatbot Integrations	Enterprise-focused control recommendations including DLP, RBAC, and KMS guidance; use for implementation planning.
UCI Information Security: Use AI Chatbots Securely	University-level guidance on user behavior risk and vendor approval processes; useful for policy and training program templates.

FAQ

What is data security in AI chatbots?

Data security in AI chatbots is the set of technical, operational, and contractual controls that protect user and enterprise data across the full chatbot lifecycle: input, inference, storage, and any training or retention that follows. The core goal is to maintain confidentiality, integrity, and availability of data at every stage.

Do AI chatbots store your data?

Most consumer-tier chatbots do store conversation data, and 9 of the 10 most-used chatbots train on user conversations by default. Enterprise API tiers with Zero Data Retention agreements are the standard exception; even then, deletion does not always remove data from human-reviewed stores or backups.

Should you be careful what you tell ChatGPT?

Yes. OpenAI’s default consumer tiers may use conversation data to improve models unless you opt out or use an enterprise agreement with explicit data-use restrictions. Avoid sharing PII, credentials, proprietary code, or regulated data (health, financial, student records) in any consumer-tier chatbot.

Does ChatGPT keep your data private?

ChatGPT’s privacy behavior depends on which tier you use. The consumer tier retains conversations and may use them for training by default; the ChatGPT Enterprise and API tiers with Zero Data Retention provide stronger protections, but you must verify those settings are active and documented in your contract.

What U.S. regulations apply to AI chatbot data security?

The applicable regulations depend on what data your chatbot processes. HIPAA applies when health data is involved; CCPA/CPRA applies to California consumer personal information; PCI DSS applies if cardholder data is in scope; FERPA applies to student records. The FTC’s Section 5 authority covers deceptive or unreasonable data security practices across all sectors.