Dealink — Privacy Policy

⚠️ DRAFT SKELETON — not in force until approved by counsel

These words are Jonathan's and counsel's to finalize, not an agent's. Before this file existed there was no privacy policy at all — not even a draft — for a product that stores call recordings, transcripts, contact lists and data-room documents, and sends them to third-party AI models (§9.3 of docs/plans/launch-readiness-20260910.md).

This is a skeleton: the structure a real policy needs, with every factual claim left as a TODO rather than guessed. An invented privacy policy is worse than none — it is a public promise about handling personal data that nobody has verified we keep. Do not remove this banner, and do not let anyone fill a TODO from memory: each one needs a person who actually knows the answer.

• Last updated: 2026-09-11 · Status: DRAFT SKELETON, unreviewed
• Companion: terms.md (also a draft) and the reviewer notes in TERMS-OF-SERVICE.md
• Blocking decision: the Terms take the position that we are a processor / service provider for customer content and a controller only for account and billing data. That single choice determines most of this document, and whether a separate Data Processing Addendum (sub-processor list, SCCs, breach-notice timelines) is required. Counsel decides it; it is TODO #1.

1. Who we are

TODO (Jon + counsel): the contracting entity — [LEGAL ENTITY NAME], a [STATE/COUNTRY] [ENTITY TYPE], registered address, and whether "Dealink" / "Deal Machine" is the legal name or a trade name. This must match §1 of the Terms exactly.

TODO: a privacy contact address. There is currently no support or privacy contact path in the product at all (§9.5 of the launch-readiness audit) — {{support_email}} is used in two workflow templates with no configured value anywhere.

2. Scope — whose data this covers

This policy should distinguish three populations, because our role differs for each:

• Customers — the people who hold accounts and workspaces. We are a controller for their account, profile and billing data.
• Customer content subjects — the investors, guests and contacts whose data a customer uploads or captures (contact lists, interview recordings, data-room visitors). We are a processor acting on the customer's instructions. (Position taken by the Terms; TODO for counsel to confirm.)
• Website visitors — people who visit the marketing site or a published page without an account.

TODO: confirm this three-way split and write the "who is responsible to you" sentence for each. A data subject in group 2 who wants their data deleted has to be told to ask the customer, not us — and that sentence has to be accurate.

3. What we collect

TODO (engineering, then counsel): an honest inventory. The categories the product demonstrably touches, each needing confirmation of exactly what is stored and where:

• Account and profile data (name, email, role, workspace membership, hashed credentials — auth is Supabase).
• Workspace / company profile data.
• Call and interview recordings, and their transcripts. (TODO: retention, and whether transcripts are stored separately from media.)
• Data-room documents uploaded by customers, and the derived text chunks and embeddings used for retrieval.
• Contacts imported or synced by customers, including phone numbers and message history.
• Usage, analytics and diagnostic data. (TODO: name every analytics and error-tracking tool actually enabled — see §7.)
• Cookies and similar technologies. (TODO: a cookie table, and whether a consent banner is legally required for our audience.)

4. How we use it

TODO: purposes, and a lawful basis for each where GDPR/UK GDPR applies. State plainly whether customer content is ever used to train or improve models — the answer must be verified against every AI vendor's terms before it is written here, not assumed.

5. AI processing

The product sends customer content to third-party AI models. This section has to say so in plain language: which content, to which vendors, for what, and what those vendors may do with it.

TODO (engineering): the definitive vendor list and, for each, the data-handling terms we are actually on. Candidates visible in the codebase include Google / Gemini, Anthropic, ElevenLabs, and the transcription path — but "visible in the codebase" is not the same as "enabled in production", and this list must be the production one.

6. Recordings and consent

Interviews and calls are recorded. The Terms put the legal duty to obtain consent on the customer (the host), with the platform providing notice.

TODO (counsel): confirm that allocation holds in all-party-consent jurisdictions (California, Illinois, most of the EU), and decide whether the product must enforce an in-room consent click. Product note carried over from the Terms draft: there is no in-room consent gate today. Do not describe one here.

7. Sub-processors and third parties

TODO: the published sub-processor list — hosting, database, email, telephony, AI, and analytics vendors, each with its role and processing location. This list is referenced by the DPA and has to be maintained, not written once.

8. International transfers

TODO (counsel): transfer mechanism (SCCs / UK IDTA / adequacy) and where data rests.

9. Retention

TODO: how long each category in §3 is kept, and what happens on account closure. The Terms' §15 ("Term, suspension, termination, and what happens to your data") is the companion section — the two must not contradict each other.

10. Security

TODO: an accurate description of technical and organisational measures. Write nothing here that has not been verified. Two facts from the launch-readiness audit that bear directly on any claim made in this section: there are no automated database backups (§8.1), and development and production share one database (§8.3). Fix or disclose — do not paper over.

11. Your rights

TODO (counsel): access, correction, deletion, portability, objection, and withdrawal of consent — scoped by the controller/processor split in §2 — plus the actual mechanism for exercising them and our response time. A right with no working request path is a false statement, so this section cannot ship before the mechanism exists.

12. Children

TODO: age floor, aligned with the Terms' eligibility section.

13. Changes to this policy

TODO: how changes are notified and when they take effect.

14. Contact

TODO: privacy contact address, postal address, and (if required) an EU/UK representative or a DPO.