ZanaAI & Data
How Zana uses AI and data.
Zana can use local processing, Zana-hosted infrastructure, and approved external providers. We only describe processing as local when that path is technically proven, and provider capability never by itself authorizes Zana to expose data or take action.
Last updated: September 15, 2026
Zana is still in pilot and beta development and is not yet authorized for general live-private-data production use. Exact processors, retention behavior, deletion propagation, and isolation controls must be verified for an enabled feature before Zana makes stronger claims about that feature.
1. Current Product Status
Zana is being tested and hardened before broader production use with live private user data. Public pages, demos, synthetic testing, and bounded pilot workflows do not by themselves mean that every private-data workflow is production-approved.
Features that handle private or sensitive context remain subject to the security, privacy, provider, retention, deletion, and isolation evidence required for that processing path.
2. Local, Hosted, And External Processing
A Zana feature may use device-local or browser-local processing, Zana-hosted infrastructure, or an approved external service. Which path is used depends on what the feature needs, the device and deployment available, and the privacy and safety requirements that apply.
Zana calls processing local only when the relevant work is actually proven to stay on the device or browser path being described. A cloud, hosted, or external path is not described as local simply because it has strong privacy controls.
3. Private Context And Cloud AI
Private or sensitive context is not automatically eligible for external AI processing. When an external reasoning path is used, the context released should be limited to what the task requires, and the exact deployment must satisfy the applicable privacy, data-use, retention, region, and provider-access requirements.
Zana therefore does not promise that every request stays local. It also does not treat a provider's technical ability to process data as permission to send that data there.
4. Models, Providers, And Training
Zana may use different qualified mechanisms for different tasks. No model or provider is a permanent default merely because it is available, popular, or inexpensive, and provider availability does not establish that a deployment is approved for a particular private-data use.
Zana policy does not authorize private customer or pilot content to train a public or shared Zana model. Product improvement should use synthetic, public, de-identified, or otherwise appropriately authorized material unless a separate approved program establishes a different lawful basis and product boundary.
5. Connected Services And Actions
Optional connections such as email or calendar should use the permissions needed for the feature you choose. Reading information from a connected service does not by itself authorize Zana to send, schedule, delete, publish, or otherwise change something in that service.
Consequential external actions require the applicable user or delegated authority, the provider capability needed to perform the action, protection against duplicate execution, and verification of the result.
6. Retention, Correction, And Deletion
Zana does not currently publish one universal deletion deadline across application databases, backups, logs, connectors, and every processor. Retention and deletion depend on the data source and processing path.
Zana's product rules require corrections and deletions to be respected rather than silently resurrecting stale information. Stronger end-to-end timing guarantees should be published only after the relevant storage, backup, connector, and processor behavior is verified.
7. Security And Sensitive Information
Zana uses safeguards appropriate to the feature, including authentication, scoped access, restricted credentials, role and purpose boundaries, and encrypted network transport where implemented. Credentials such as API keys and OAuth tokens are treated as secrets rather than ordinary memory or model context.
Do not use ordinary Zana text, memory, or AI fields as a password vault, and do not place private keys, authentication secrets, or payment-card data there. No software or cloud system can honestly guarantee that compromise or unauthorized disclosure is impossible.
8. What Zana Will Claim
Zana's public claims should be supported by deployed controls, current provider terms, or a written agreement. If a pilot or customer needs specific commitments about subprocessors, retention, deletion, regional processing, security controls, or incident response, those commitments should be documented explicitly rather than inferred from marketing language.
Read the Privacy notice and Terms for the broader rules that apply to Zana use.
Trust Rule
Claim only what the evidence supports.
Zana should prefer a narrower accurate claim over a broader privacy or security promise that the live product has not yet proved.