Prompt and inference logging vs privacy: an ISO 27001 view for AI SaaS

Logs are how AI SaaS companies debug production failures, detect abuse, monitor latency, and improve product quality. That is a legitimate set of reasons to retain inference data. But when those logs contain verbatim customer prompts, the data inside them can include employee names, client references, medical information, financial transaction details, or legally privileged communications - whatever the customer chose to submit. The fact that the data arrived as a prompt rather than a database record does not change its classification or the obligations that apply to it.

ISO 27001 does not tell you whether to log prompts. It requires you to have made a deliberate decision, documented that decision, classified the data appropriately, and put controls in place that are consistent with what your information security policy and your data processing agreements say you do.

The problem with default logging behaviour

The default behaviour in many AI product stacks is to log everything that might be useful later. That is understandable - inference pipelines fail in unexpected ways and having the full input-output pair in a log is invaluable for debugging. The problem is that "log everything" is not a documented retention policy, it is an absence of one.

When a buyer's security questionnaire asks "what data do you retain from customer interactions and for how long," the honest answer for many AI SaaS companies is "we log prompts and completions and we keep them for as long as our log aggregation platform retains data by default, which we have not explicitly configured." That answer fails on at least three fronts: it is inconsistent with most DPA commitments, it may conflict with sector-specific obligations the customer operates under, and it demonstrates no deliberate control.

An ISO 27001 auditor asking about information asset management will want to see that each significant category of data has a defined classification, a defined retention period, and a defined access control. Inference logs that contain customer inputs are a significant category of data.

Classifying what is in the log

Inference logs typically contain several distinct data elements with different classification profiles:

Verbatim customer prompts. If the product allows free-form input, these can contain anything. A HR platform's prompts may include employee details. A document review tool's prompts may include legally privileged material. A customer service AI's prompts may include payment card references or health conditions.

Inference outputs. The model's response. Usually lower sensitivity than the input, but can include generated content that incorporates or references the input's sensitive elements.

System prompts and retrieved context. For RAG-based products, the retrieved chunks sent to the model alongside the user's query may include content from documents the user uploaded or from the customer's integrated data sources.

Request metadata. Timestamps, user identifiers, session identifiers, API keys or tenant identifiers. Individually lower sensitivity, but linkable to the content log and to the customer's own data subjects.

Each element warrants its own classification decision. "Confidential" is an appropriate default for verbatim prompts that could contain personal data. The classification determines minimum access controls and retention limits.

Retention controls that survive audit

An auditor looking at retention controls for inference logs needs to see more than a stated retention period. The evidence required includes:

A documented retention policy that covers inference logs explicitly - not a generic "we keep logs for 90 days" statement that was written before the product existed.

Configured enforcement. If the policy says 30 days, the log aggregation platform should be configured to delete or archive at 30 days. A policy that exists on paper but is not enforced in configuration is a control that does not work. Auditors check both.

Consistency with DPA commitments. If the customer's DPA says data is retained for the duration of the contract only, the inference log retention period must be consistent with that. A mismatch between the DPA and the actual log retention is a gap an auditor will mark.

Deletion on request. If a customer exercises a right of erasure under GDPR or an equivalent obligation, the deletion must extend to inference logs. That requires the logs to be structured so that a specific customer's records can be identified and deleted, not just aged out in bulk.

Scope clarity. Does the retention policy cover only the primary database, or also the log aggregation platform, the monitoring tool, the LLM provider's retained copies (where those exist under the API terms), and any data warehouse or analytics pipeline that ingests production data?

Access controls on inference logs

Even if retention is correctly managed, inference logs can become a significant internal risk if access is broad. In many AI SaaS companies, the full inference log is accessible to anyone with developer access to the logging platform. That may include contractors, employees not involved in the customer's account, and sometimes third-party integrations for alerting or analytics.

ISO 27001 Annex A control A.8.3 on information access restriction applies. Access to inference logs should be:

• Limited to roles that have a legitimate need - typically platform reliability engineers, security operations, and specific debugging scenarios.
• Logged itself, so there is an audit trail of who accessed customer prompt data and when.
• Reviewed periodically, with the review documented as part of the broader access review cycle.

For products serving regulated sectors, access controls on inference logs may need to be tighter still. A legaltech product where the inference log contains client-matter prompts has a conflict-of-interest dimension that goes beyond standard information security - only personnel involved in the customer's account should be able to read those entries.

The DPA misalignment risk

Most AI SaaS vendor DPAs are written by a lawyer who focused on the primary data storage and processing architecture - the database, the file storage, the messaging queue. Inference logs are often an afterthought. As a result, the DPA may commit to data handling practices - retention limits, deletion rights, access restrictions - that the actual inference logging infrastructure does not implement.

This is not a theoretical problem. When a buyer's legal team reviews the DPA in detail and asks the vendor to confirm that the commitments extend to all data stores including inference logs, the vendor discovers the gap. The fix usually requires a combination of a DPA amendment, a technical change to enforce retention limits, and an access control review - none of which are fast.

Starting the readiness process with a data-flow mapping exercise that explicitly traces what ends up in which log, and then checking each log against the DPA commitments, is significantly more efficient than discovering the misalignment under buyer pressure.

Where Kellwick fits

Kellwick works with AI SaaS companies to map data flows through inference pipelines, align log retention controls with DPA commitments, and produce the evidence that enterprise buyers and auditors need. If you are building out your ISMS and want to make sure inference logging is handled correctly from the start, see how we support AI SaaS readiness.