Zhipu MaaS Launches “No Data Retention”

Zhipu Starts Turning “Whether Data Is Retained” into a Switch

On September 20, Zhipu MaaS announced the recent launch of a “data content non-retention” mechanism. Enterprises and developers can submit an application through the MaaS console. Once the platform confirms that it has taken effect, the inputs and outputs generated by standard model calls will no longer be statically stored, and the data will be used only to complete that particular model call. (openai-hub.com)

This is not the vague claim that “we will not use your data to train models.” Instead, it takes the data lifecycle one step further: in principle, the model service platform will no longer retain the original requests submitted by users or the content returned by the model over the long term.

That said, the boundaries need to be made clear first: this mechanism is not automatically enabled by default for all accounts, nor does it mean that data will never be retained under any circumstances. Users must apply first, and the specific effective date and scope of application are subject to the confirmation provided by the Zhipu platform.

The Key Is Not “No Training,” but “No Persistence”

In the past, when enterprises integrated large models, the question they asked most often was: Will the platform use business data to train its models? This is an important question, but it is not the whole question.

After a request leaves an application, it may pass through an API gateway, request logs, scheduling systems, caches, monitoring platforms, troubleshooting backends, and object storage. Even if the platform promises not to use it for model training, the original content may still remain in these systems for a period of time.

For developers, “no training” and “no retention” address two different layers of the problem:

• No training: The platform does not use user data for model training, fine-tuning, or capability improvements.
• No retention: The platform attempts to shorten the lifecycle of request content and does not save inputs and outputs as static data that can be accessed over the long term.
• No logging: This is stricter, meaning that the request body, response body, and related debugging information should not be stored in plaintext over the long term.

What Zhipu’s announcement clearly specifies is the second layer: inputs and outputs will “not be statically stored.” In other words, standard synchronous calls are closer to “process and move on” than to “the platform retains a copy of the business data after the call is completed.”

However, the information Zhipu has publicly disclosed does not yet cover every technical implementation detail. For example, it remains necessary for enterprises to confirm with the platform before activation whether short-term caching exists, how abnormal requests are handled, whether disaster-recovery systems retain copies, whether operations and troubleshooting personnel can access the original content, and whether the same rules apply across different models and regions.

The Batch API and File API Are Out of Scope

The most easily misunderstood aspect of this update is interpreting “no retention” to mean that “none of the interfaces retain data.” In reality, Zhipu has explicitly excluded certain features that inherently depend on persistence capabilities.

1. Batch API

The Batch API typically works by submitting tasks asynchronously. The platform first receives the requests, then queues them for execution, after which users query task statuses or retrieve results in batches. The tasks themselves, execution statuses, and results all need to be stored on the platform side for a period of time; otherwise, users would not be able to retrieve the results later.

Therefore, the Batch API cannot simply be treated as subject to the same “no retention” logic as standard synchronous calls. Enterprises that use batch processing for large volumes of text, code, or customer data need to separately confirm the retention period, access permissions, and deletion mechanisms for task data.

2. File API

The File API is more straightforward. Once a user uploads a file to the platform, the platform needs to retain it until the call is completed so that subsequent tasks can read, parse, or reuse it. Once contracts, source code, financial statements, customer service records, or other files enter the File API, the associated data risk is no longer limited to that of a single request; it becomes a persistent file asset.

Zhipu’s announcement states that features such as the Batch API and File API, which require tasks or files to be persistently stored on the platform side, are not covered by the data content non-retention mechanism. (openai-hub.com)

3. Legal and Abuse Investigation Scenarios

If laws and regulations require data to be retained, or if the platform needs to investigate suspected violations, attacks, or abuse, the relevant data may still be stored for 30 days or longer.

This is not unexpected. No cloud service provider can use a “privacy switch” to override statutory retention obligations, nor can it completely give up its ability to investigate when a security incident occurs. Enterprises need to incorporate these exceptions into their own vendor security assessments and data-processing agreements, rather than focusing only on the words “no retention.”

Why This Timing Matters

This update was released after discussions about data security were triggered by ZCode, an AI programming product under Zhipu.

On September 18, in response to community discussions about code repository uploads, Zhipu apologized to affected users through official channels and said that it had completed a self-inspection and remediation. Zhipu explained that the issue was related to ZCode’s “code repository indexing” feature, which was originally intended to support capabilities such as historical version recovery, version rollback, and Repo Wiki. When generating Wiki pages, the feature could trigger repository data uploads in certain scenarios. The company also stated that uploaded data would be destroyed immediately after the Wiki was generated in the cloud, and that it planned to open-source the codebase and introduce third-party reviews. (ithome.com)

From a timing perspective, MaaS’s data non-retention mechanism came shortly before and after the ZCode incident, making it difficult not to associate the two with product trust concerns. However, publicly available information does not establish a direct causal relationship between them. A more accurate assessment is that the ZCode controversy prompted developers to reconsider what AI tools actually read, upload, and retain, while this MaaS update brings similar questions to the enterprise model-calling layer.

These two issues should not be conflated.

ZCode concerns an AI development tool’s access to, indexing of, and uploading of local code repositories. MaaS concerns how input and output content flows through and is stored in the cloud after an enterprise calls a model through an API. Fixing the former does not mean the latter is inherently secure; offering the latter as a non-retention option cannot replace clear explanations of local file permissions for development tools.

For Enterprises, the Value Is Real—but Still Incomplete

This feature has practical significance for the financial, healthcare, government, manufacturing, and large internet sectors.

When these industries use large models, the hardest issues are often not model capabilities, but whether data can leave a designated environment, who can access it, how long it is stored, and how incidents can be traced. A single customer service ticket may contain a name, phone number, order information, and complaint details; a code snippet may expose internal domains, database structures, and unreleased interfaces; and a contract may contain pricing, supplier, and intellectual property information.

In this context, if standard synchronous calls automatically retain complete requests and responses, enterprise security teams may find it difficult to reach a clear conclusion. Zhipu now at least provides a product option that can be applied for, confirmed, and incorporated into vendor management processes.

This is more actionable than simply stating in a privacy policy that “we will protect user data in accordance with the law.” Enterprises can include it in their integration checklists: which accounts have been enabled, which models are covered, which interfaces are excluded, when the mechanism takes effect, and how data should be retained under exceptional circumstances.

But it is not a “free pass.”

Looking at the actual enterprise data chain, the model platform is only one link. Much sensitive information is not exposed at the model service provider, but within the calling organization’s own systems:

• The gateway writes the full request body into access logs;
• APM and distributed tracing systems automatically collect request parameters;
• Error-monitoring platforms upload the complete exception context;
• Business teams save user inputs in local databases for debugging;
• Production data is copied into test environments without being anonymized;
• R&D personnel write API responses directly into tickets or chat tools.

If these links continue to store plaintext, non-retention on the MaaS platform can solve only part of the problem.

What Developers Should Do Now

For teams already using Zhipu MaaS in production, the following sequence is recommended:

1. Apply first, then confirm the scope. Do not interpret “available for application” as “effective immediately after submission.” Keep records of the console application, the platform’s confirmation, and the scope of applicable interfaces.
2. Evaluate synchronous calls and asynchronous capabilities separately. For standard synchronous calls such as text summarization, classification, structured extraction, and code explanation, teams can prioritize evaluating the non-retention mechanism. The Batch API and File API require separate data-retention assessments.
3. Anonymize data at the business gateway. ID numbers, phone numbers, email addresses, bank card numbers, customer names, internal keys, and production credentials should not be sent directly simply because the platform offers a non-retention option.
4. Disable default logging of request bodies. Retain necessary metadata such as request IDs, model names, status codes, latency, and token usage, but avoid storing complete inputs and outputs in logging systems whenever possible.
5. Use test data to verify the effective status. Teams can use test requests containing unique markers and cross-check the call chain against platform confirmation and enterprise-side logs, rather than relying solely on a switch displayed in the interface.
6. Set higher thresholds for highly sensitive data. For core trade secrets, unreleased source code, keys, health data, and large-scale personal information, teams should still prioritize local deployment, dedicated environments, or calls made only after rigorous anonymization.

For most teams, the more realistic combination is not “send all data to the cloud and trust a privacy switch,” but rather “business-side anonymization + MaaS non-retention + no plaintext logs across the call chain + keeping highly sensitive data within the designated environment.”

What This Zhipu Update Solves—and What It Does Not

The conclusion first: this is a valuable enterprise capability, but it cannot yet be called a complete data security solution.

What it solves is a key issue on the model-calling platform side—whether standard requests and responses need to be retained over the long term. For scenarios that require only a single synchronous inference, this option can reduce the risk of original business content remaining continuously exposed on the platform side, while also giving enterprises a clearer configuration basis during procurement and security reviews.

What it does not solve is the full provability of the data chain. Enterprises still need to know:

• Which models and regions are actually covered;
• Whether short-term caches and disaster-recovery copies exist;
• What the retention boundaries are for abnormal requests and security incidents;
• Whether platform personnel can access the original content;
• Under what conditions retention is triggered for violation investigations, and what the approval process is;
• Whether enterprises can obtain activation records, audit records, or third-party evidence;
• Whether the results of deletion or non-persistence can be verified.

This is also the real point of competition for “non-retention” products. The question is not who is first to claim “zero data retention,” but who can clearly explain the retention scope, exception conditions, technical boundaries, and audit evidence.

For developers, the most important change is not that they can now confidently send all data to models. It is that “how long will the data from this call remain on the platform?” can finally become a clearly defined engineering question rather than a vague compliance promise.

Zhipu MaaS’s update deserves recognition, but enterprises should treat it as one piece of the data governance puzzle, not as the final line of defense. A genuinely usable security solution still needs to begin with data classification, call-chain design, logging policies, and access controls.