AirMemo1. The landing site collects almost nothing
The marketing site (this page, /pricing, the demo pages) sets no cookies, runs no analytics SDK, and uses no advertising or tracking pixels. The site's "live fleet" counter fetches public aggregate counts (agents under management, memos served) from the control plane; those counts contain no personal data and identify no individual. The /talk pilot inquiry form sends your org name, team size, inquiry type, contact email, and note to AirMemo's control plane, where we store it (together with the submitting IP address and browser user agent, kept to rate-limit the form and prevent abuse) to answer your inquiry and schedule pilots. We use inquiry details only to respond to you, and we do not add them to a marketing list. Inquiry rows are deleted after 90 days. Aside from that form, we do not collect an email address, an IP address for profiling, or any device identifier from the marketing site. Visiting the marketing site is, for privacy purposes, still close to reading a document.
2. Cookies and tracking
The marketing site sets no cookies at all. The Service (the console) sets a session-authentication cookie, and equivalent local storage, that is strictly required for sign-in and account security. That cookie identifies your session to the Service so the console can distinguish you from other users; it does not identify you to any third party, and we do not use it to track you across sites. There are no advertising cookies, no analytics cookies, and no third-party trackers anywhere in the Service. Cookie use is function-essential, which falls under the ePrivacy cookie-consent exemption in the EU and UK; we do not operate a consent-management platform and do not display a cookie banner, because there is nothing to consent to. The session cookie is set by the Service's own domain and is httpOnly, so the page's JavaScript cannot read it; the session record it points to is stored in the Postgres database described in Section 5. The way to opt out is to log out, which ends the session, and the session cookie is cleared when the session ends. We do not use cookies, local storage, or fingerprints for cross-site tracking.
The composer also mirrors an unsent draft (the memo's title and body, i.e. memo content) to this browser's local storage for the account in use; the draft never leaves your browser, and it is cleared when the memo is sent or the composer is reset.
3. The Service (console) collects what it must
When you enroll an org and agents, AirMemo processes: account and billing data (email, org name, billing identifiers via Stripe); memo content and metadata (author, scope, priority, expiry); agent identifiers and platform type; delivery receipts (proof hashes, timestamps, injection points); and audit events (actor, action, target, timestamp). Memo content is processed to deliver memos into agent session context at the sanctioned lifecycle boundaries your org configured, and to enforce scopes and expiry. This data is processed solely to provide the Service: queueing, scoping, delivering memos into agent session context, receipt generation, audit, quota enforcement, billing, and support, and only on documented instructions from your org. We do not use memo content to train models, to build profiles, or for any purpose other than operating the Service. Full categories, roles, and retention are in the Data Processing Addendum.
3a. The delivery rails and what each one sees
The Service carries a memo over up to three rails. What AirMemo holds differs by rail, and by edition.
The hook client runs on your machine. It reads your org's queue for that agent, injects the memo at the agent's lifecycle boundary, and reports a receipt: the memo id, the proof hash, the injection point, the platform, the agent and session identifiers, and a timestamp.
The model-API gateway is an HTTP endpoint you point your AI client at. A request passes through AirMemo on its way to your model vendor: AirMemo prepends your org's in-force memos to the request, streams the vendor's response back untouched, and stores neither the request body nor the response body. The ledger row it writes carries the memo delivered, the person, the session, the injection point, a proof hash, and a timestamp; the gateway's own logs carry the request path, how many memos were carried, the policy state, and timing. Your model-vendor credential is forwarded exactly as your client sent it: we do not log it, do not store it, and hold no vendor credential of our own. A request refused in block mode is recorded as a refusal event carrying a digest of the payload, its byte count, a reason code, the protocol, the rail, the session id, and a timestamp, kept for 90 days, with no prompt content.
The browser sensor is a first-party extension we publish for the AI chat surfaces it supports. For the surface it is loaded into, the extension reads the page hostname, stores your org's memo for that surface locally in the extension, inserts the memo into the composer, and checks at send time that the memo is still present. It posts a delivery receipt carrying the memo id, a device identifier, a keyed digest of the page host, a session id, the injection point, a proof hash, a token count, and a timestamp. It does not send us the page URL or the text of the conversation: the composer is read only to insert the memo and to confirm it is still there, and the receipt carries a keyed digest of the host, not the page's address or its content. It sets no cookie and no cross-site identifier, and it reports no browsing history beyond a keyed digest of the host of a supported surface it was actually loaded into.
Receipts are the governance record on every rail, and they carry what Section 3 lists. On a self-hosted deployment all three rails run in Customer's own infrastructure: AirMemo never sees your traffic and receives only licensing and support data.
4. Legal bases for processing
We rely on the following bases under Article 6 of the GDPR, as applicable: contract performance (providing the Service you signed up for, including delivery, receipts, audit, and billing); legitimate interests (security, incident response, abuse prevention, and billing reconciliation); legal obligation (compliance with laws that apply to us, such as tax and accounting rules); and consent where we ask for it, such as the marketing use of your org's name and logo, which is consent-based with an opt-out per Terms §17, and telemetry, which is opt-in. Where we rely on legitimate interests, we balance them against your rights and interests and use them only where our interest is not overridden by yours. Data subjects in the EEA, the UK, and Switzerland may request details of the specific legal basis that applies to any processing of their personal data.
5. Storage and location
AirMemo's cloud runs on Railway compute and
Neon Postgres. As of this version, processing is split between US East
(us-east-1, Postgres) and US West (us-west2, compute); it is not
co-located, and selecting an eu region claim in the console records a
contractual commitment to migrate, not a current storage fact. Data stays in
the regions described here until any such migration completes; EU
data-residency processing is not offered today. See the security and trust
page for the exact posture and controls.
6. International transfers
The Service's cloud runs in the United States. Where personal data is transferred from the EEA, the UK, or Switzerland to the United States, we make the transfer under the EU Standard Contractual Clauses, as incorporated in the Data Processing Addendum at §8, together with supplementary measures as required. We do not claim adequacy decisions that do not apply to our processing. We will not transfer personal data outside the regions described in the DPA without a lawful transfer mechanism and the protections it requires.
7. Retention and erasure
Memos are live until the expiry set when they are authored (7 days where the author sets none), after which the memo expires and its queued copy is deleted, and memos are not archived; receipts and audit events are insert-only by design (no UPDATE/DELETE) and are the record of what was delivered, to whom, and when. AirMemo keeps those rows as permanent storage: they are not deleted on an age schedule, and no retention window expires them. Where your tier's console shows an audit-visibility window (Free 7 days; 365 days on paid Cloud or self-hosted subscription; 30 or 90 days on a subscription still renewing on the retired team or business plan; 90 days after a paid subscription is canceled or lapses for non-payment, or the plan's own window where it is shorter), that window governs how far back the console can read, not how long the rows are stored. Rows leave storage only through erasure (an offboarding or erasure request, or deletion of the organization), and only after the export manifest is written. The exception is rows written before authentication (sign-in and signup attempts): they belong to no organization, no erasure request can reach them, and so they are deleted after a fixed 90-day export-first window. On offboarding you can export your audit trail, receipts, and memo content, after which org rows and queues are hard-deleted within 30 days. Export-before-delete: we never delete without offering the export first, and deletion is hard deletion, not anonymization or tokenization. Details, including the deletion procedure, are in DPA §6.
Erasing one person from an organization
An organization is deleted whole; one person can also be erased on their own, and that path is pseudonymization, not deletion. We overwrite the address with a per-person placeholder at a reserved, never-routable domain, blank the display name and password, and clear the SSO subject, so that a later SSO login cannot re-bind the person and write the old address back. Live credentials are revoked, not deleted: sessions and enrollment tokens keep their rows with a revocation timestamp, because those rows are history. API tokens belong to the organization, not to the person, so they are relabelled as created by an erased user and left working. The pseudonymous row itself stays, carrying no credential, because memos that person authored, audience rows listing them as a recipient, receipts, and audit events point at it and those rows are permanent storage: the record of what was delivered stays intact and attributable to nobody. The mail log for the address is deleted, and this organization's claim on any suppression entry for it is dropped.
8. Telemetry
Telemetry capture is opt-in per OTel convention and off by default. Nothing is captured until an org administrator enables it, and it can be disabled at any time. Receipts (hash proofs) are the metric of record and are never derived from telemetry; telemetry exists to help us improve the product, and disabling it does not affect delivery, receipts, audit, or billing.
8a. Delivery-failure reports
Separate from OTel spans, and off by default under the same org-level switch, a hook may report that a delivery attempt failed. A report carries a digest of the payload, its byte count, a failure code, the platform, a timestamp, the agent id and the session id. It never carries a memo title, body, recipient, or excerpt, and no agent output. The report describes the failure, not the memo. An org's reports are deleted 90 days after receipt, and turning the switch off stops collection as well as storage: reports an agent is still holding are refused rather than banked.
9. What we do not do
We do not sell, rent, or share personal data. We do not use it for advertising, for cross-context behavioral advertising, or for profiling. We do not process personal data for any purpose other than providing the Service, except where law requires. We do not buy data about you from data brokers, and we do not enrich our records with data from third parties.
10. Third-party sharing and processors
We share personal data only with service providers necessary to operate the Service, and only on documented instructions: Railway (cloud hosting and compute), Neon (Postgres database), Cloudflare (CDN and edge), Stripe (billing), an email relay (operator-configured SMTP provider, or Resend when the host blocks outbound SMTP), and object storage (S3/R2-compatible). Each provider receives only the data its role requires, processes it only on our instructions, and is bound by the DPA. The complete list with each provider's role is in the sub-processor table in the Data Processing Addendum. We do not sell, rent, or share personal data with advertisers or any other third party for their own purposes, and engagement of any new sub-processor follows the notice and objection process in the DPA.
11. Security incidents
We notify affected orgs without undue delay after becoming aware of a security incident affecting their data, provide the available details of what happened and what data was involved to the extent known, and maintain a timeline for updates. We cooperate with affected orgs in the investigation and with law enforcement where required. Notification is not an admission of liability. We maintain the technical and organizational measures described in the security and trust page and the DPA, and we review them continuously.
12. Your rights and how to exercise them
Your org controls its data: who may push, which scopes, revocation of agents, export, and erasure, all through the Service's tooling. If you have a request the console cannot fulfill, contact hello@airmemo.com; we will verify that you are authorized to act for the org before processing org-level data. We respond to valid requests without undue delay, and in any event within one month of receipt, as required by applicable law. Our response is free for reasonable requests; a fee may apply where a request is manifestly unfounded or excessive, as permitted by law. You also have the right to lodge a complaint with the data-protection authority in your jurisdiction; raising it with us first typically gets the fastest resolution. If you wrote to us through the inquiry form and are not a Customer, the same rights apply to the request itself: email hello@airmemo.com from the address on the request and we will correct or delete it.
13. California residents
If you are a California resident, the CCPA and CPRA give you the right to know what personal information we collect about you, to delete it, to correct it, and to opt out of the sale or sharing of personal information. We do not sell personal information, and we do not share it for cross-context behavioral advertising, as those terms are defined in the CCPA. We do not use sensitive personal information for any purpose other than providing the Service, and we do not infer characteristics about consumers from it. We will not discriminate against you for exercising these rights. To exercise any of them, contact hello@airmemo.com; we will verify your request and respond within the time the CCPA requires.
14. Children's privacy
The Service is for organizations and professional use and is not directed at children under 16, or under the age of majority in Missouri. We do not knowingly collect personal data from children. If we learn that we have collected personal data from a child, we will delete it promptly and close any associated account.
15. Do Not Track and Global Privacy Control
The landing site sets no tracking signals of its own and no third-party trackers, and the Service does not track users across sites. We honor Global Privacy Control signals in the console where technically feasible, and Do Not Track where the browser sends it. Because we do not engage in cross-site tracking, honoring these signals does not change what we collect; there is no cross-site tracking to disable.
16. Changes
We will notify you by email or in-product before this policy changes in a material way, and we will state the effective date of the change. Continued use after notice constitutes acceptance; material changes to data handling follow the DPA process, including its notice and objection rights.
17. Contact
Questions about this policy or our data practices: AirMemo, hello@airmemo.com. We respond to privacy inquiries promptly and, where required, within the time frames set by applicable law.