Buyer’s Checklist for Trusted AI

Security teams evaluating AI frequently encounter “no data retention” or “zero data retention (ZDR)” claims from enterprise APIs. Those claims can be useful, but they are not synonymous with end-to-end confidentiality assurance. The practical risk is driven by custody and control: what is logged for safety/abuse monitoring, which features persist state, what operational access exists, and what can be compelled under legal process. The additional, structural issue is verifiability: if key controls are implemented and enforced inside a third party’s environment, customers often cannot independently prove non-persistence and non-access across all subsystems—creating both known residual risk and unknown risk (opaque or changing internal systems, exception paths, and incident handling).

Imbrulo is designed to minimize these failure modes by reducing third-party custody and narrowing the blast radius through dedicated-tenant and on-premise deployment models, paired with explicit security and governance controls.

What “zero data retention” does and does not mean

Across major providers, “no retention/ZDR” is commonly conditional and can vary by endpoint, feature, configuration, and legal requirements.

• OpenAI documents that abuse monitoring logs may contain prompts/responses and derived metadata (e.g., classifier outputs) and are retained up to 30 days by default, unless legally required longer. (OpenAI Platform)
• Google documents that achieving Vertex AI zero data retention depends on specific actions and that customer data is retained under certain scenarios/conditions. (Google Cloud Documentation)
• Anthropic documents that, under ZDR agreements, the scope may be limited to the Anthropic API (and products using a commercial org API key), and that ZDR does not apply to certain products unless explicitly agreed. (Claude Privacy Center)

The risk assessment takeaway: “ZDR” is not a universal property of a vendor. It is a specific, testable configuration for a specific set of surfaces—and it can be undermined by adjacent features (files, caching, connectors, grounding/browsing) and by exception paths.

High-risk failure modes (and how to mitigate them)

Feature carve-outs create storage
Disable or strictly govern features that persist state (file APIs, prompt caching, stored outputs, grounding/browsing). Enforce endpoint allow-lists at the network and application gateway.

Tool/browsing egress
Disable web/tool egress for confidential workflows, or route through a controlled proxy with strict allow-lists and DLP. (Tool use is a separate trust boundary; ZDR does not prevent external egress.)

Support workflow leakage
Prohibit pasting sensitive client data into tickets. Use redaction workflows. Require least-privilege support access with auditability and exportable logs.

Legal hold / compelled disclosure
Prefer architectures that minimize third-party custody. For highest-sensitivity matters, on-prem deployment and strict retention minimization reduce exposure to third-party legal process and preservation orders.

Verifiability gap (known + unknown exposure)
Even with strong written policies, third-party environments often prevent customers from independently validating: complete deletion across backups/replicas, the full content of safety logs, the true scope of internal access, and the behavior of evolving features. This creates measurable residual risk plus uncertainty-driven risk (“unknown unknowns”) that is difficult to justify under strict confidentiality obligations.

Due diligence checklist (questions to ask any AI provider)

• Exactly which products/endpoints are covered by “ZDR/no retention” and which are not?
• Are prompts/outputs or derived metadata logged for abuse monitoring? For how long? Can it be disabled per tenant/project?
• Which features persist state (prompt caching, stored outputs, file reuse, connectors, grounding/browsing) and what are their retention behaviors?
• Who can access customer data (support/ops/contractors)? Under what approvals? Is access audited and exportable?
• How are encryption keys managed? Who can decrypt and under what circumstances?
• How are deletions handled in backups/replication? Is verified deletion available?
• What is the vendor’s process for responding to legal demands? What notification commitments exist?
• What are the subprocessors and what change-control commitments exist?

Why the lowest-risk path is Imbrulo

In regulated settings, the material risk is not limited to whether a vendor claims “no retention,” but whether you can verify and govern data handling across all exception paths (safety logging, feature persistence, support access, backups, and legal compulsion). Third-party enterprise APIs inherently concentrate critical controls inside environments you do not operate, producing both known residual exposure and irreducible uncertainty. Imbrulo’s dedicated-tenant and on-prem deployment options are structured to reduce third-party custody, narrow the blast radius, and support stronger isolation, auditability, and customer-controlled governance—making Imbrulo the lowest-risk path for high-sensitivity regulated workflows. Many alternative “ZDR” enterprise API approaches can present risk profiles that are difficult to substantiate under audit and, for certain confidentiality and privilege requirements, may be untenable.