AirMemo: Data Processing Addendum (DPA)

1. Applicability

This DPA applies whenever AirMemo (as Processor) processes Personal Data on behalf of Customer (as Controller) in the course of the Service, and supplements the AirMemo Terms of Service. It applies to all Personal Data processed by AirMemo in connection with Customer's use of the Service, including free and pilot use. Where Customer is an organization, the individuals authorized by Customer to use the Service (authorized users) and the agents enrolled by Customer are covered by this DPA as part of Customer's use. This DPA remains in effect for as long as AirMemo processes Personal Data on behalf of Customer, including during any post-termination retention, export, or erasure period under Section 6.

2. Roles and Scope

Customer is the Controller of Customer Data (including Personal Data contained in memos, audit records, receipts, and agent metadata); AirMemo is a Processor processing that data solely to provide the Service. AirMemo processes data only on documented instructions from Customer (which include the Terms, the Privacy Policy, the Acceptable Use Policy, and the product documentation), unless required otherwise by applicable law (in which case AirMemo will inform Customer, unless the law forbids it). Customer determines the means and purposes of processing to the extent described in this DPA; AirMemo implements those instructions using the Service's controls, including the role model that determines who may push memos and the scope and audience choices Customer selects. If AirMemo believes that an instruction from Customer infringes applicable data protection law, AirMemo will inform Customer without undue delay and may suspend the affected processing until Customer confirms or amends the instruction, to the extent permitted by law. Neither party will process Personal Data in a way that is incompatible with the documented instructions or with this DPA. The rails Customer enables define what AirMemo processes. Where Customer enables the gateway, a request transits AirMemo's gateway on its way to Customer's model vendor and AirMemo stores no request or response body. Where Customer deploys the browser sensor, a keyed digest of the page host a memo was delivered on, a device identifier, and a session identifier are processed as part of the delivery receipt.

3. Data Processing Details

• Categories of data processed: memo content and metadata (author, scope, priority, expiry); agent identifiers and platform type; delivery receipts (proof hashes, timestamps, injection points); audit events (actor, action, target, timestamp); account/billing data (email, org name, billing identifiers via Stripe); optional opt-in telemetry (OTel; off by default).
• Delivery-rail data: the rail that carried a memo; where the browser sensor delivered it, a keyed digest of the page host, a device identifier, and a session identifier; where the gateway carried it, the injection point and a proof hash; and, for a request refused in block mode, a payload digest, byte count, reason code, rail, protocol, and session id. No prompt content, response content, or page content is stored.
• Categories of data subjects: Customer's employees and contractors whose agents are enrolled, and whose AI chat surfaces carry the browser sensor where Customer deploys it.
• Purposes: providing the Service: queueing, scoping, delivery of memos into agent session context over the hook, gateway, and browser rails, receipt generation, audit, quota enforcement, billing, and support.
• Retention: per Section 6 of this DPA.
• Sub-processors: as listed in Section 7; Customer will be notified of any additions.

4. Controller Obligations

Customer will ensure it has lawful grounds for processing and that its instructions (including memo content pushed through the Service and scope/audience choices) comply with applicable law. Customer is responsible for authorizing "who-may-push" under its role model and for revoking agents promptly when personnel or hardware change hands. Where the DPA requires Customer choice, Customer must make the election. Customer represents and warrants that it has the right to submit the Personal Data it processes through the Service, including any data it publishes in memos or attaches as context, and that such data was collected and will be processed in compliance with applicable law.

5. Provider Obligations

AirMemo will: (a) process Personal Data only on documented instructions, as above; (b) ensure persons authorized to process are bound by confidentiality; (c) implement appropriate technical and organizational measures, including the controls described in Section 7C (Schedule 2: Technical and Organizational Measures) and the security and trust page; (d) not "sell" or share Personal Data, and not use it for advertising or profiling; (e) assist Customer with its obligations concerning data-subject rights and security, taking into account the nature of processing (deletion/rectification requests are implemented through memo revocation and offboarding/erasure flows); (f) maintain records of processing as required by law; and (g) make available to Customer, on request, information necessary to demonstrate compliance with this DPA, including the evidence described in Section 10. AirMemo will notify Customer without undue delay if it becomes aware of a breach of this DPA or of the data protection requirements applicable to it. AirMemo will not transfer Personal Data to a third country except as permitted by this DPA and applicable law.

6. Retention, Deletion, and Erasure (the AirMemo contract)

1. Live retention: a memo carries an expiry set when the author creates it (7 days where the author sets none), after which the memo expires and any queued copy of it is deleted; memos are not archived, and delivered messages are not moved to archive tables. Receipts and audit events are insert-only by design (no UPDATE/DELETE) and AirMemo keeps them as permanent storage: they are not deleted on an age schedule, and no retention window expires them. The audit-visibility window a plan carries (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) governs how far back the console and the API will read, not how long the rows are stored. Rows leave storage only through erasure (an offboarding or erasure request, or deletion of the organization): the erasure path writes the export manifest in its own transaction, then deletes the rows in that same transaction after dropping the append-only trigger. A person-level erasure is a separate path and is not row deletion: it pseudonymizes that person's identity in place, with a placeholder address at a reserved, never-routable domain, name and password cleared, the SSO subject cleared so the identity provider cannot re-bind the person, sessions and enrollment tokens revoked, and org API tokens relabelled as created by an erased user, and it keeps the user row so receipts and audit events stay attributable. Rows written before authentication (sign-in and signup attempts) belong to no organization and no erasure request reaches them, so they are deleted after a fixed 90-day export-first window. The export path and the audit-anchor pass each read an org's full history when they run. Archive tables are pruned only after export; uploading an export to the write-once bucket is the deploy's job (governance runbook), and the on-host export is the copy the retention tooling writes. Exports are written as JSONL manifests plus the delivery-proof CSVs by the retention tooling (retention export-audit / export-org).
2. Offboarding / erasure (export-before-delete): within the offboarding flow, Customer may export its audit trail, receipts, and memo content at no charge during the first 30 days after termination. After export (or if Customer declines export), AirMemo will: revoke all agents; export audit/receipts to the Customer's own bucket where offered; and hard-delete org rows and queues within 30 days.
3. Append-only receipts/audit: receipts and audit events are insert-only by design (no UPDATE/DELETE). AirMemo keeps them as permanent storage; the rows are the governance record and are not deleted on an age schedule. What a plan sets is how far back the console and the API will read (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); it is not set at Customer direction during the pilot. On erasure they are included in the export and then deleted per the offboarding flow. Only rows written before authentication are deleted on a fixed 90-day export-first window, because they belong to no organization and no erasure request reaches them. AirMemo will not retain copies beyond the erasure window except where law requires or the Customer elects extended export retention.
4. Telemetry: spans/telemetry capture is opt-in per OTel convention and off by default; receipts (hash proofs) are the metric of record and are never derived from telemetry. Delivery-failure reports (a separate, content-free channel under the same org-level switch: payload digest, byte count, failure code, platform, timestamp, agent and session identifiers, and no memo content) are retained for 90 days and then deleted; disabling the switch stops collection and storage. Receipts and audit events remain insert-only, as described in Section 6. Refusal events (payload digest, byte count, reason code, rail, protocol, session id - no memo content) are retained for 90 days and then deleted.

7. Sub-processors

Customer authorizes the sub-processors listed below and any updates notified by AirMemo. AirMemo will impose data-protection terms on sub-processors equivalent to this DPA and remain liable for their acts. Customer's own model vendor is not a sub-processor of AirMemo: traffic the gateway forwards reaches that vendor under Customer's agreement and with Customer's credential, and AirMemo holds no vendor credential.

7A. Sub-processor objection right

AirMemo will notify Customer before engaging a new sub-processor or replacing an existing one, and will give Customer at least 30 days to object. Customer may object to a new or replacement sub-processor within 30 days of notice, on reasonable grounds relating to the protection of Personal Data (including where the proposed sub-processor is not subject to appropriate safeguards for international transfers). If Customer objects, the parties will discuss the objection in good faith. If the parties cannot resolve the objection within a reasonable period, AirMemo may either (i) cease using the objected-to sub-processor, or (ii) make reasonable changes to the Service or to this DPA (including, where appropriate, entering into the applicable transfer safeguards) to address the objection. If AirMemo is unable to resolve the objection through either of those options, Customer may suspend the affected processing or terminate the affected part of the Service without penalty, by written notice; termination will be treated as termination for convenience under the Terms, and Customer's export rights under Section 6 will apply. This Section 7A does not apply to sub-processors listed in the table above at the Effective Date, which Customer authorizes on acceptance of these Terms.

7B. Deidentified and aggregate data

Either party may use deidentified, aggregated data derived from processing under this DPA (for example, metrics of record and delivery statistics) for any purpose, including research and Service improvement, provided that the data is deidentified to the standard required by applicable law and cannot reasonably identify an individual. The party using such data will not attempt to reidentify it. Where AirMemo uses deidentified or aggregated data to improve the Service, it does so as the controller of that derived data, provided it remains deidentified as described above.

7C. Schedule 2: Technical and Organizational Measures (TOMs)

AirMemo maintains technical and organizational measures appropriate to the nature of the processing, including the following. These measures mirror the controls described in the security and trust page and are implemented by the Service's architecture and by the infrastructure providers identified in Section 7, using each provider's standard safeguards.

1. Access control: per-agent credentials for enrolled agents; a role model that determines who may push memos; revocation of agents on personnel or hardware change; no shared superuser credentials across the Service.
2. Transmission encryption: all traffic to and from the Service is encrypted in transit (TLS) and memo payloads are signed (Ed25519) and HMAC-protected between the hook and the control plane.
3. Storage encryption: data at rest is encrypted by the underlying providers (Neon Postgres at us-east-1, Railway compute at us-west2) as part of their standard safeguards; the hook client reads only what it must and is read-only with respect to memo content.
4. Confidentiality: personnel authorized to process Personal Data are bound by confidentiality obligations; access to production data is limited to what is necessary. Where an operator searches the install's roster by employee email or email domain, that search is necessary for support and incident response under this Section; the console's view stays metadata-scoped (it returns no message content and no per-person address list), and the operator's own audit rows are the access record for it.
5. Availability and resilience: the Service relies on the infrastructure providers' standard availability and recovery measures; backups and recovery are provided by the database provider's standard safeguards. During pilot, no uptime or recovery-time commitment is made (see the Terms).
6. Testing and monitoring: security testing is performed as part of the product lifecycle; the Service's delivery path is exercised continuously through automated tests; security events and anomalies are monitored and reviewed.
7. Separation: each org's data is isolated through the Service's org model; per-org rate limits and scoping controls apply; the live database never scans archived history.
8. Auditability: delivery receipts and audit events are append-only with proof hashes; the records form the compliance evidence described in Section 10. These measures are updated as the Service evolves; material changes will be reflected in this DPA or the Security and trust page.

8. Transfers

Where Personal Data is transferred across borders, the parties will implement appropriate safeguards, including EU Standard Contractual Clauses (SCCs) and the UK International Data Transfer Addendum (IDTA) where applicable. Until such safeguards are in place, AirMemo will not transfer Personal Data to a third country without lawful basis. For transfers subject to the EU SCCs, the applicable modules are Module Two (controller to processor) for transfers where Customer is the controller and AirMemo the processor, and Module Three (processor to processor) for any onward transfers to sub-processors. The EU SCCs, where applicable, are incorporated by reference into this DPA and, in the event of any conflict between the SCCs and this DPA, the SCCs prevail with respect to the transfers they govern. Where the UK GDPR applies to a transfer, the IDTA, or the SCCs as recognized under the UK regime, will govern such transfers as applicable. The parties may execute the relevant annexes to the SCCs or IDTA by signature; for pilot use, electronic acceptance of this DPA under the Terms satisfies the requirement to conclude the applicable transfer safeguards. A copy of the executed annexes will be made available on request.

9. Security Incident Notification

AirMemo will notify Customer without undue delay after becoming aware of a security incident affecting Customer Personal Data, providing available details and a reasonable timeline for updates; will take steps to mitigate; and will cooperate with Customer's investigation. Notification is not an admission of liability.

10. Audits and Compliance Evidence

During the pilot, AirMemo's append-only audit trail, receipts, and status page are the compliance evidence, made available to Customer on request. Customer may exercise audit rights through documented requests; on-site audits are not offered during pilot. A SOC 2 report will be made available when the audit is obtained; it is not currently available. Subject to the foregoing: (a) audits will be conducted no more than once per 12 months per Customer, unless a regulator or a data-protection incident requires otherwise; (b) audits will be at Customer's cost, unless the audit reveals substantial non-compliance by AirMemo, in which case AirMemo will bear the reasonable cost; (c) Customer will give reasonable notice (at least 30 days, except where a regulator or incident requires urgency); (d) audits and requests for evidence will be scoped to Customer's data and processing under this DPA; (e) audits will be conducted under confidentiality obligations, and any third-party auditor must be reasonably acceptable to AirMemo; and (f) the outcomes of the audit or the evidence provided will be shared with Customer. Nothing in this Section 10 obliges AirMemo to disclose information that would compromise the security of the Service or the data of other customers, or that is subject to confidentiality obligations to third parties.

11. Data Subject Rights

AirMemo will reasonably assist Customer in fulfilling data-subject requests (access, correction, erasure, restriction) using the Service's tooling (revocation, offboarding/erasure, export). If AirMemo receives a request directly, it will advise the requester to contact Customer and may inform Customer.

12. Liability

The liability section of the Terms applies to this DPA, including the cap. Each party's aggregate liability under the Terms and DPA together will not exceed the cap in the Terms §21.

13. Term

This DPA applies as of the Effective Date of the Terms and continues until all Personal Data is deleted or returned per Section 6, whichever is later. The obligations in §§5(e)–(g), 6, 9 survive termination.

14. Governing Law and Changes

This DPA is governed by the laws of the State of Missouri. The parties will keep this DPA consistent with the data protection obligations applicable to the processing. AirMemo may update this DPA from time to time to reflect changes in the Service or applicable law; material changes will be notified to Customer as provided in the Terms, and the version stamp at the top of this page records the current version and effective date. Continued use of the Service after a material change takes effect constitutes acceptance of the updated DPA, and the Terms' provisions on changes apply.

15. Conflicts and Contact

In case of conflict between the Terms and this DPA, the DPA governs with respect to data processing. Customer Data is processed only under this DPA. Questions about this DPA, including sub-processor objections and requests for the SCC/IDTA annexes, should be directed to AirMemo Corporation at hello@airmemo.com.