Practical Privacy Controls for AI Chat Tools: Configurations, Logging, and SLA Clauses

Why the Perplexity “Incognito” Lawsuit Matters for Every Team Using Consumer AI Chat

The recent lawsuit alleging that Perplexity’s “incognito” chats may not be as private as users were led to believe is not just a product controversy; it is a procurement warning for any organization allowing employees to use consumer AI chat tools with sensitive business data. In practice, the issue is not whether a provider uses the word “private” in the UI. The issue is what happens to prompts, attachments, telemetry, logs, and derived data after a user clicks send, and whether that behavior is contractually guaranteed. If your team is evaluating AI chat privacy controls, treat this moment the same way you would treat a cloud vendor review: insist on hard technical settings, explicit service agreements, and audit-ready evidence, not marketing claims. For a broader governance lens on third-party platforms, see our guide to identity and access for governed industry AI platforms and the practical framework in trust but verify for LLM-generated metadata.

Organizations often underestimate the scope of third-party AI risk because chat tools feel lightweight and ephemeral. In reality, a single prompt can contain source code, incident details, customer PII, regulated health information, financial data, or unreleased product strategy. Once that data enters a consumer AI service, the organization inherits a chain of questions about retention, machine learning training, operator access, legal holds, backups, subprocessors, and cross-border transfer. That is why privacy controls cannot be limited to an acceptable-use policy; they need to be embedded in the technical configuration and in the SLA. If your team already cares about operational reliability in vendors, the same discipline used in reliability-focused vendor selection should now be applied to AI chat platforms.

Start With the Data Classification Rule: What Can Never Go Into Consumer AI Chat

Define “never prompt” data categories before you touch settings

The most effective privacy control is a data rule, not a UI toggle. Before debating encryption or retention, your organization should define what is prohibited from entering any consumer AI chat service: secrets, private keys, credentials, regulated PII, PHI, payment data, legal privileged material, security incident details, and unreleased source code. This rule should be explicit enough that employees can apply it without legal interpretation at 10 p.m. during a production incident. A useful way to think about it is to distinguish between low-risk brainstorming content and data that creates downstream compliance or breach exposure. For teams building internal AI programs, the same discipline appears in AI adoption and change-management programs.

Map prompts to business impact, not just data labels

Data classification is stronger when it is tied to impact. A prompt containing a customer support transcript may not look sensitive at first glance, but if that transcript includes a name, ticket ID, and account status, it may become regulated personal data in context. Likewise, a paste of a configuration snippet can reveal internal hostnames, environment architecture, and security controls even if it does not contain obvious secrets. That means your acceptable-use policy should describe examples in plain language, not only abstract categories. If your teams regularly compare vendors, the mindset used in defensible financial models applies here: define assumptions clearly, document exceptions, and preserve reviewability.

Use workflow gates for sensitive use cases

For higher-risk use cases, require a gated path rather than a free-form consumer chat experience. That can mean a private enterprise tenant, an internal approved model gateway, or a redaction workflow that strips identifiers before prompts leave the organization. Engineering teams can automate this at the browser, proxy, or API layer, while legal and privacy teams define the approval matrix. The point is to reduce discretionary behavior, because “I only pasted a little bit” is exactly how third-party AI risk becomes a reportable incident. If you need a practical model for handling sensitive data flows, the controls discussed in thin-slice prototyping for EHR projects are a useful template for minimizing blast radius.

Retention Settings: The First Control You Should Demand

Ask whether chats are retained, and for how long

When a vendor markets “incognito” or “temporary” chat, do not assume the technical behavior matches the user expectation. The contract and the admin console should specify whether prompts, outputs, attachments, metadata, and diagnostic logs are retained, and if so, for what purpose and duration. The most important distinction is between user-visible chat history and backend retention for abuse monitoring, debugging, billing, legal compliance, and security investigation. A service can hide conversation history from the end user while still keeping the content in operational logs or archived backups. For this reason, retention settings must be reviewed as a system design issue, not a UX issue. The same skepticism applies when you evaluate consumer-grade claims in other categories, as shown in privacy-aware consumer guidance.

Require explicit no-training defaults for business data

One of the most important contractual demands is that organizational content is not used to train foundation models, fine-tune shared models, or improve products unless the customer explicitly opts in. “No training by default” should be written clearly, with no ambiguity about whether de-identified or aggregated data is included. If the provider reserves broad rights to use data for “service improvement,” that language needs to be narrowed or rejected. Procurement teams should ask for a written statement covering prompts, outputs, uploaded files, feedback thumbs-up/down signals, and logs derived from the conversation. If your organization cares about truthful vendor claims more broadly, the transparency principles in trustworthy sustainability claims are a useful analogue: vague claims are not enough.

Verify deletion mechanics, not just deletion promises

Deletion is only meaningful if the provider can describe what is deleted, when, and from which storage systems. You want clarity on primary databases, search indexes, analytics pipelines, object storage, backups, disaster recovery copies, and cached content. Many vendors can delete a visible conversation, but retain fragments in operational logs or immutable backup sets for a defined period. That may be acceptable if it is disclosed and contractually bounded, but it must be understood before sensitive usage begins. Teams that routinely evaluate post-sale support should recognize the pattern from long-term ownership and parts support: promises are cheap, lifecycle execution is what matters.

Encryption at Rest and in Transit: Necessary, But Not Sufficient

Demand strong transport security and certificate discipline

At a minimum, all traffic should use modern TLS with strong certificate validation, and session handling should avoid exposing prompts through insecure intermediaries. That includes browser-to-service traffic, API calls, webhook callbacks, file transfer channels, and any embedded media processing path. Encryption in transit protects against network interception, but it does not solve insider access, backend log exposure, or retention issues. It is still foundational, though, because weak transport security can turn a privacy concern into an outright confidentiality failure. Teams planning secure integrations should also understand how architecture choices impact data flows, much like the systems thinking in cross-platform companion app development.

Ask exactly how encryption at rest is implemented

“Encryption at rest” is often presented as a binary yes/no, but the practical details matter. The key questions are whether the provider uses envelope encryption, whether keys are managed by the vendor or customer, whether hardware security modules are used, and whether customer data is logically separated by tenant. For particularly sensitive use cases, organizations should ask about customer-managed keys, key rotation intervals, and revocation behavior. You also want to know how encryption covers indexes, caches, logs, backups, and file previews, since these often escape the headline answer. The same careful inspection you would use when buying hardware from a comparison guide such as hardware upgrade advice should apply to encryption claims.

Insist on key ownership and segregation questions in the SLA

Encryption without clear key governance can create a false sense of control. If the provider can decrypt everything internally without customer visibility, then encryption is mainly a breach-mitigation tool, not a meaningful access boundary. Ask whether keys are segregated per tenant, whether support personnel can access decrypted content, and whether customer data is ever transferred into lower-trust environments for debugging. If your business depends on strong privacy assurances, state in the SLA that key access events must be logged, reviewable, and subject to role-based approval. In situations where the organization already thinks about trusted ownership and provenance, the logic resembles provenance-based verification: you are not just buying a claim, you are validating a chain of custody.

Logging Policies: The Hidden Privacy Surface Most Teams Miss

Separate product telemetry from user content logs

Logging is where “incognito” claims often become least intuitive. A vendor may disable chat history in the UI but still keep prompt text, attachments, error traces, moderation flags, and session metadata in support logs. Your requirements should distinguish between operational telemetry needed for reliability and content logging that can expose sensitive material. Ask for explicit categories: authentication logs, prompt logs, response logs, file-upload logs, moderation logs, model-inference logs, and admin audit logs. The goal is not to eliminate all logging, because that would hurt security and incident response, but to minimize content capture and control access tightly. Teams building rich monitoring stacks can borrow the same policy discipline seen in reliable mobile alerting systems.

Require redaction and tokenization where possible

Good logging policy means sensitive material is redacted before storage whenever feasible. If the provider claims to support abuse detection or debugging, ask whether logs are tokenized, hashed, partially redacted, or full-text stored. For internal enterprise gateways, you may also want to redact secrets and identifiers at the proxy layer before the request is sent upstream. This can significantly reduce the risk that logs become a second copy of regulated content. In organizations that need strong trust frameworks, the same mindset used in governed AI identity controls should be extended to logs themselves.

Demand audit logs for admin actions and data access

Privacy controls are incomplete without forensic visibility. You should be able to see who changed retention settings, exported data, altered access roles, disabled safeguards, or approved a support escalation involving user content. Audit logs should be immutable or at least tamper-evident, exportable to your SIEM, and retained long enough to support investigations and compliance evidence. This is especially important for multi-admin environments where the risk is not only external attackers but also over-privileged internal users. For organizations that think in terms of defensible review processes, the rigor in LLM output verification maps well to audit review.

Access Controls: Preventing Casual Exposure and Overbroad Support Access

Enforce SSO, MFA, and least privilege from day one

Any AI chat service used by a company should integrate with SSO and MFA, and it should support least-privilege role design. Consumer-grade shared logins, personal accounts, and unmanaged OAuth grants are incompatible with a serious privacy posture. Separate admin, billing, audit, support, and user roles so that no single operator can casually access all conversation content. The best privacy incident is the one that never becomes an access-control exception in the first place. If your organization has already formalized identity governance in other systems, extend that discipline here instead of allowing a “shadow AI” exception.

Ask how support personnel access customer content

Support access is a common weak point because vendors often reserve broad rights to inspect customer data for troubleshooting. Your contract should define whether support access is enabled by default, whether it is ephemeral, whether customer approval is needed, and whether every access is logged and reviewable. For higher-sensitivity tenants, require a named approver workflow and a break-glass process with post-event notification. A vendor that cannot explain support access clearly is not ready for sensitive workloads. Teams buying other complex services will recognize the importance of serviceability from guides like red flags in service-provider comparisons.

Segment tenants, projects, and identities

If your organization runs multiple business units, do not allow one AI workspace to become a shared pool of everything. Segment by function, business unit, or data sensitivity so that a prompt from one team is not discoverable by another team’s admin. Where the service supports enterprise workspaces, define administrative boundaries and data boundaries separately. This matters because many privacy leaks are not deliberate breaches but accidental cross-team visibility. The broader principle is the same as in audience segmentation strategy: scale works better when boundaries are explicit.

Contractual SLA Clauses You Should Demand Before Approval

No training, limited retention, and disclosed subprocessors

Contract language should convert privacy promises into enforceable obligations. At minimum, demand clauses that state organizational content will not be used for model training or improvement without opt-in, retention periods are defined and limited, subprocessors are disclosed and subject to notice, and data transfers are governed by a documented legal mechanism. If the vendor relies on subprocessors for hosting, monitoring, analytics, or support, you need transparency into who handles data and where. A strong SLA also specifies notice periods for material changes to privacy practices, so you are not surprised by a policy shift after adoption. This is the same category of commercial rigor discussed in modern contracting changes.

Incident notification and cooperation timelines

Privacy incidents are not only security breaches; they can also be accidental disclosures, unauthorized support access, or unlawful retention. Your SLA should require prompt notice of any confirmed or reasonably suspected unauthorized access involving your content, plus cooperation on containment, investigation, and regulator/customer response. Be specific about timing, for example requiring notification within a defined number of hours after confirmation, not “without undue delay.” The contract should also address forensic preservation, log sharing, and evidence retention. For companies that manage operational resilience carefully, the same style of timely coordination seen in vendor reliability planning should be reflected here.

Audit rights, attestations, and change control

Ask for the right to review independent security attestations, privacy certifications, and penetration-test summaries where available. Where formal audits are not practical, require annual written attestations covering retention settings, access controls, encryption posture, and subprocessor changes. The SLA should also include change-control language for major product changes that affect data handling, such as changes to chat retention, logging, model routing, or data residency. Without change control, you may approve a safe configuration today and inherit a riskier one later. For teams that care about proving compliance rather than assuming it, the mindset is similar to building a defensible reporting process in financial model governance.

A Practical Control Matrix for AI Chat Privacy Reviews

The table below is a practical procurement and security checklist you can use when reviewing consumer or prosumer AI chat services. It emphasizes the controls that most directly reduce exposure when employees enter business data into chat tools. Use it during vendor evaluation, renewal review, and incident response planning. If a provider cannot answer these questions clearly, assume the privacy risk is higher than advertised.

How to Build an Approval Process That Actually Works

Create a red/yellow/green use-case model

Most organizations fail because they have a policy but no workflow. A simple red/yellow/green model is effective: green for low-risk brainstorming and non-sensitive drafting, yellow for internal but non-regulated business content, and red for secrets, PII, source code, or regulated data. Attach each class to a permitted tool, an approval level, and a logging expectation. This removes guesswork from employees and gives security a defensible standard when exceptions arise. If you are trying to operationalize decisioning at scale, the same staged thinking appears in trust workflows for AI-generated artifacts.

Deploy secure prompt hygiene and redaction

Users need examples of safe prompting, not just warnings. Show them how to strip customer names, replace secrets with placeholders, summarize logs instead of pasting them, and use synthetic examples for troubleshooting. For developers, provide code snippets or proxy rules that automatically redact common secret patterns and personally identifiable fields before the prompt leaves the browser or IDE. This is where privacy becomes practical rather than theoretical. Good enablement is similar to the way teams are coached in structured AI change management: policy plus habit formation.

Review vendor changes continuously

AI services change quickly, sometimes faster than procurement cycles. Re-review retention, logging, support access, and subprocessor disclosures whenever the vendor releases a major product update or policy revision. Set calendar reminders for quarterly checks and require reapproval if the service changes its “incognito” behavior, introduces memory features, or expands data-sharing language. If the vendor cannot provide a stable privacy baseline over time, the platform is too volatile for regulated workflows. That concern parallels the advice in rapid but trustworthy comparison workflows: speed is useful only if the underlying facts stay current.

Pro Tip: Treat every consumer AI chat platform as a data processor first and a productivity tool second. If you cannot answer who can see the prompt, how long it lives, whether it trains the model, and how to delete it, you do not yet have an approvable service.

What a Strong AI Chat SLA Clause Set Should Look Like

Clause themes to include in your paper

When legal or procurement reviews a consumer AI chat contract, the most important clauses are usually the least flashy. You want data-use limitations, retention commitments, subprocessor notice, support-access governance, breach notification, audit evidence, and deletion mechanics. You also want a clear statement of purpose limitation so the vendor cannot repurpose your data for unrelated product experiments. If the provider offers enterprise and consumer tiers, make sure the contract says the business account gets the enterprise privacy terms, not the consumer defaults. Strong clauses are the difference between a reassuring product demo and a durable control framework.

Negotiation levers for smaller organizations

Not every organization has the leverage to rewrite a vendor’s standard terms, but most can still ask pointed questions and choose among tiers. If a provider refuses customer-managed keys, detailed retention control, or strong no-training language, you can often compensate partially with technical controls or by restricting the data allowed into the service. The key is to document the residual risk explicitly and get stakeholder sign-off. If the business decides to accept consumer-grade privacy terms for convenience, that should be a conscious decision, not an accidental default. Teams comparing vendors cost-effectively may find the reasoning in reliability and partnership selection useful.

What to do if the vendor won’t commit

If a vendor will not commit to retention limits, support-access controls, or no-training terms, you have three choices: block sensitive usage, route only sanitized prompts, or choose a different service. There is no fourth option where risk disappears because the interface looks friendly. For regulated workloads, inability to contractually pin down privacy behavior is itself a disqualifying signal. This is especially true if the tool is marketed with terms like “incognito” or “temporary,” because marketing language is not a substitute for legal enforceability. The current lawsuit is a reminder that product framing can diverge from backend reality, so your procurement process should assume that divergence is possible until proven otherwise.

FAQ: Common Questions About AI Chat Privacy, Retention, and Contracts

Final Recommendation: Demand Verifiable Privacy, Not Friendly Language

The lesson from the Perplexity “incognito” controversy is straightforward: privacy claims in AI chat are only useful if they are backed by technical controls and contractual obligations you can inspect, test, and enforce. If your organization wants to use consumer AI chat services responsibly, the baseline package should include strict data-classification rules, explicit retention limits, no-training terms, encryption details, granular access controls, redacted logging, auditability, and incident-response commitments. Anything less leaves you dependent on vendor interpretation at the exact moment you need certainty. That is not a scalable privacy strategy.

For teams building a durable governance program, start by documenting your approved use cases, then map them to required settings and contract language. Next, verify those settings in the console, not just in the brochure, and re-check them after every major product update. Finally, establish a recurring review of vendors and alternatives so you are not locked into a service that cannot meet your privacy bar. If you need a broader vendor-risk frame for AI tools, revisit governed AI identity patterns, contract change control principles, and vendor reliability selection criteria as complementary controls.

Related Reading

• Identity and Access for Governed Industry AI Platforms: Lessons from a Private Energy AI Stack - A deeper look at role design and access boundaries for AI environments.
• Trust but Verify: How Engineers Should Vet LLM-Generated Table and Column Metadata from BigQuery - Practical validation patterns for AI outputs and data trust.
• The End of the Insertion Order: What CMOs and CFOs Must Know About Contracting in the New Ad Supply Chain - Useful contract lessons for negotiating modern digital services.
• Skilling & Change Management for AI Adoption: Practical Programs That Move the Needle - How to operationalize policy through user training and adoption.
• The Silent Alarm Dilemma: Ensuring Reliable Functionality in Mobile Apps - A controls-first approach to dependable product behavior.