How should organisations evaluate no-log AI before using it for sensitive work?

Why This Matters for Security Teams

No-log claims are only useful if they are provable, scoped, and consistent with how the service actually handles prompts, outputs, attachments, and routing. Sensitive work often fails at the boundary between product copy and operational reality: a provider may avoid long-term chat history, but still retain telemetry, relay content to subprocessors, or use data for abuse detection. Security teams should treat this as a data-handling review, not a trust exercise.

The practical risk is that a “no-log” label can mask multiple storage paths. That includes server-side caches, human review queues, backups, support tooling, and downstream processors. The right reference point is documented control evidence, not a sales statement. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames expectations around data retention, auditability, and supplier oversight, while NHIMG’s The State of Secrets in AppSec shows how confidence in secret handling often outpaces actual control maturity. In that research, 43% of security professionals were concerned about AI systems learning and reproducing sensitive information patterns from codebases.

In practice, many security teams discover retention gaps only after sensitive prompts have already been processed through a service they assumed was ephemeral.

How It Works in Practice

Evaluation should start with a written retention model from the vendor and continue into contract, architecture, and operational testing. The key question is not only “does the model keep chat history?” but “what data is stored, where, for how long, and who can access it?” That includes prompts, outputs, file uploads, metadata, abuse-detection logs, support transcripts, analytics events, and any third-party processors. If the service forwards requests to another model host or cloud platform, those handling terms matter as much as the front-end privacy statement.

Security teams should confirm four controls before approving sensitive use:

• Explicit zero data retention language for prompts and outputs, with retention exceptions clearly listed.
• Disclosure of whether user content is used for training, fine-tuning, or human review.
• Clear explanation of whether chat history is stored locally, server-side, or both.
• Supplier and subprocessors list, including any routing, observability, or support vendors.

For higher-risk use cases, request evidence rather than assurances: data processing terms, retention schedules, deletion SLAs, and, where available, independent security attestations. Align the review with NIST SP 800-53 Rev 5 Security and Privacy Controls for retention, access restriction, and supplier management, and compare findings against the incident patterns described in DeepSeek breach to understand how hidden storage and exposure paths can turn a private interaction into a broader disclosure problem.

These controls tend to break down when the provider uses shared infrastructure with opaque subprocessors because the customer cannot independently verify where sensitive content is replicated.

Common Variations and Edge Cases

Tighter no-log requirements often increase procurement friction, requiring organisations to balance speed against evidence quality. There is no universal standard for “no-log” yet, so current guidance suggests treating the claim as a spectrum rather than a binary.

Some services truly minimize retention but still keep limited operational metadata. That may be acceptable for low-risk use, but it is often insufficient for regulated, legal, HR, clinical, or source-code workflows. Others offer enterprise controls that disable training but still retain content for short periods to support abuse investigation. That can be workable if the retention window is explicit, approved, and contractually bounded.

Edge cases also include local or private deployments, where “no-log” may mean the vendor does not store data centrally, but the customer still owns backups, endpoint logs, and admin access trails. Another common mismatch appears when users paste secrets, credentials, or customer records into a service that is technically private but still outside the organisation’s approved data perimeter. For those scenarios, pair the vendor review with internal data-loss controls and secrets hygiene from The State of Secrets in AppSec, because the control failure often starts before the AI call is made.

Where the workflow depends on uncontrolled plugins, browser extensions, or third-party connectors, no-log assurances usually stop at the model boundary and do not cover the full path of sensitive data.

Related resources from NHI Mgmt Group

• What should security teams evaluate before using compound AI systems in production?
• Should organisations evaluate AI agent security tools before or after identity controls are in place?
• What should organisations do before expanding AI access to sensitive records?
• Should organisations re-evaluate DSPM before scaling generative AI?