Trust

Data Privacy & Visibility

A practical view of what ELAV sees, what should stay private, and how source-backed memory is meant to behave.

Last updated: June 2, 2026

This page summarizes ELAV's product-level data handling design. Customer-specific deployments, subprocessors, retention commitments, and enterprise controls can be documented during procurement.

1. What ELAV is designed to see

  • Source artifacts from connected systems, such as emails, Slack messages, calendar events, meeting notes, CRM records, files, and related metadata.
  • Derived memory, such as decisions, commitments, blockers, preferences, risks, and follow-ups extracted from source context.
  • Approval state, such as whether a proposed draft or action is pending, approved, rejected, or executed.
  • Operational metadata needed to keep sources fresh, debug failures, and show where evidence came from.

2. Visibility and tenant boundaries

ELAV is designed around workspace and tenant isolation. Source-backed answers should respect the connected source and the workspace context where the memory was created. If ELAV cannot prove that a user should see a source-derived fact, the safer behavior is to withhold it rather than leak it.

3. Raw source data vs. memory

Raw source content and derived memory are different. A transcript, email, or chat message may contain sensitive detail. ELAV should use only the source context needed to answer a question, cite the evidence where possible, and distinguish current facts from stale or superseded ones.

4. AI model processing

ELAV routes AI work through a controlled LLM layer rather than letting features call model providers directly. Retrieved context may be sent to AI providers to generate answers, summaries, memory candidates, or drafts. Customer source content is not used to train generalized AI models unless explicitly agreed in writing.

5. Approvals before action

ELAV may prepare a follow-up, brief, reminder, or other proposed action. The default product principle is that consequential external actions need user approval. The Brain proposes, the user decides.

6. Retention and deletion

  • Plan limits may affect how far back ELAV reads or retains source-backed history.
  • Disconnecting a source should stop new source-backed reads from that source.
  • Customers can request deletion or export of workspace data by contacting ELAV.
  • Some logs, billing records, security records, and backups may be retained for legitimate operational or legal reasons.

7. Representative systems

ELAV may use systems in these categories to operate the product. A customer-specific subprocessor list should be confirmed during procurement or in a data processing addendum.

Hosting and data storesApplication hosting, databases, object storage, and deployment infrastructure.
AuthenticationIdentity, sign-in, and workspace access controls.
Source connectionsOAuth, provider APIs, source sync, and connection readiness checks.
AI processingModel providers used to generate answers, summaries, memory, and drafts.
Email and analyticsTransactional email, demo notifications, usage analytics, and diagnostics.

8. Questions and related policies

Data privacy questions can be sent to founders@elav.ai.

Privacy PolicyPersonal information collection and use.TermsBaseline usage terms for ELAV.Security DocsSource access, evidence, and approval guidance.