Privacy Policy

The short version: we process call transcripts to generate structured sales intelligence. Talqo does not retain transcripts after analysis — processed then discarded; items awaiting processing are auto-purged within 30 days. We keep only the structured output. Our AI subprocessor Anthropic processes transcripts under a DPA and EU SCCs; transcripts are retained by Anthropic for up to 30 days (longer only if flagged for trust & safety review), never used for training. Stored data lives on EU servers. You can request export or deletion of your data at any time.

1. Who we are

Talqo is a sales intelligence platform operated by Chad Kalik, registered in Denmark (CVR: 39829630). We are the data controller for personal data collected through talqo.dk and the data processor for personal data submitted through the Talqo platform by our customers.

Contact: hello@talqo.dk

2. What data we collect and why

We collect different types of data depending on how you interact with Talqo.

If you submit a demo request on talqo.dk: We collect your name, company name, work email, and role. This is used solely to respond to your request. Legal basis: legitimate interest (Article 6(1)(f) GDPR).

If you use the Talqo platform:

Account data — your name, email address, and role within your organisation. Used to provide access and personalise your experience.
Call transcripts — submitted by you for analysis. Talqo does not retain transcripts after analysis — processed then discarded; items awaiting processing are auto-purged within 30 days. Processed by our AI subprocessor Anthropic under a DPA and EU SCCs; retained by Anthropic for up to 30 days (longer only if flagged for trust & safety review), never used for training. Legal basis: contract performance (Article 6(1)(b) GDPR).
Structured output — the call summary, scores, action items, and coaching notes generated from your transcript. This is the core output of the service and is retained in your account until you delete it or your account is closed.
Usage metadata — timestamps of logins and analyses. Used for security and service improvement.

3. Data we do not collect

We do not use cookies for tracking or advertising on talqo.dk
We do not collect payment card data directly (handled by payment processors if applicable)
We do not seek or intentionally collect special category data (health, religion, political views, etc.). Because transcripts are of real conversations, such details could in principle be mentioned in passing by a participant; if they are, we do not use them, and they are discarded with the rest of the transcript after analysis (never stored)
We do not sell, share, or use your data for marketing purposes

4. How we process call transcripts

When you submit a call transcript, it is transmitted via TLS encryption to our AI processing provider (Anthropic) under a DPA and EU Standard Contractual Clauses. It is used to generate structured output, then discarded; transcripts are retained by Anthropic for up to 30 days (longer only if flagged for trust & safety review), never used for training.

For customers who require full EU data residency, an Azure OpenAI option is available (opt-in per company): transcripts are processed by your own Azure OpenAI deployment — EU-region processing when configured as Regional-EU or EU Data Zone — and transit only Talqo's EU (Frankfurt) infrastructure. See our subprocessors page.

We do not read, review, or use the content of your transcripts for any purpose other than generating your structured output.

5. Where your data is stored

All stored data lives on servers in Frankfurt, Germany (EU); we use Render Inc. for hosting.

In the default configuration, transcripts are transmitted to our AI subprocessor Anthropic (US) for processing, then discarded — the one transfer outside the EEA. It is covered by a DPA and EU Standard Contractual Clauses; transcripts are retained by Anthropic for up to 30 days (longer only if flagged for trust & safety review), never used for training.

6. Subprocessors

Processor	Purpose	Company jurisdiction	Where data is processed
Render	Application hosting, database and disk	United States	EU — Frankfurt
Evidence & details — Render Legal entity Render Inc. What it does Application hosting, database and disk Company jurisdiction United States How we know Render Inc. is a US company (San Francisco, California). Stated from the vendor's own corporate identity and its DPA counterparty; there is no artifact in this repository that establishes it, and this field does not pretend otherwise. Where data is processed EU — Frankfurt, Germany How we know deploy-guide/DEPLOYMENT.md §2 instructs 'Region Frankfurt (EU) to match GDPR positioning', and the Postgres instance was CONFIRMED in the Render dashboard on 3 Aug 2026 (the security pack, §2). Postgres is the component that matters for residency because it is the only one that stores customer data. Verified on 2026-08-03 Transfer mechanism EU hosting — no transfer required Region (summary line) EU (Frankfurt) Evidence file deploy-guide/DEPLOYMENT.md Evidence pattern Render Why this entry is here The deployment target. Not a code path — hosting is where the code runs, so the deploy guide is the artifact that proves it.
Anthropic	AI analysis of call transcripts	United States	United States
Evidence & details — Anthropic Legal entity Anthropic PBC What it does AI processing of call transcripts Company jurisdiction United States How we know Anthropic PBC, a Delaware public benefit corporation. Vendor corporate identity; no repository artifact establishes it. Where data is processed United States How we know lib.js requestedGeo: every analysis request sends inference_geo 'global' (or 'us' for a company that asks for US residency), so routing is Anthropic's global routing and is not pinned to the EU by Talqo. Corrected 29 Sep 2026: this said the call sets NO region parameter, which was true of DATA_FLOWS.md flow #1 when written and stopped being true when the geo receipt shipped. This is the one transfer outside the EEA and it is covered by SCCs. Stated plainly rather than softened: there is no EU processing on this path. The EU alternative is the Azure OpenAI entry below, which is opt-in per company. Verified on 2026-09-29 Transfer mechanism Standard Contractual Clauses (EU SCCs) Region (summary line) US Evidence file lib.js Evidence pattern api\.anthropic\.com Why this entry is here The default analysis provider; the endpoint is called directly and receipted on every call.
Azure OpenAI	Alternative AI analysis, opt-in per company	United States	Customer-controlled
Evidence & details — Azure OpenAI Legal entity Microsoft Azure OpenAI What it does Alternative AI processing, opt-in per company and off by default Company jurisdiction United States How we know Microsoft Corporation, Redmond, Washington. Vendor corporate identity. Note that the EEA contracting entity for Microsoft Online Services is commonly Microsoft Ireland Operations Ltd; which entity Talqo contracts with has not been read from any agreement and is not asserted here. Where data is processed Customer-controlled — the customer's own Azure resource How we know lib.js 'ai_provider === 'azure'' routes to {company-resource}.openai.azure.com. Talqo owns no Azure resource, so the region is whichever one the customer created theirs in. EU IS ACHIEVABLE and is stated as a requirement at onboarding (Regional-EU or EU Data Zone), but a Global deployment can route outside the EU — so this row does NOT claim EU processing. It must be verified per configured endpoint hostname, by the customer, on their own tenant. Verified on 2026-08-19 Transfer mechanism Depends on the region you deploy in — EU deployment needs no transfer; a non-EU deployment is covered by SCCs Note on the transfer mechanism Corrected 19 Aug 2026. This cell said 'EU hosting — no transfer required' while THIS SAME ROW declines to claim EU processing, because the deployment is the customer's own Azure resource and a Global deployment can route outside the EU. So the cell asserted no transfer for a path the row itself says may transfer. It was written when the row read 'EU — customer-controlled deployment', and survived the split that made the row honest. Caught by a second review the same day, one row above a transfer_note complaining about exactly this pattern on Microsoft 365 — the note named the defect class and did not look next door. Region (summary line) Customer's own Azure resource Evidence file lib.js Evidence pattern ai_provider === 'azure' Why this entry is here Per-company opt-in. Talqo owns no Azure resource; the deployment is the customer's.
Microsoft 365	Inbound email to @talqo.dk addresses	United States	EU — Denmark
Evidence & details — Microsoft 365 Legal entity Microsoft Corporation — Exchange Online (Microsoft 365) What it does Inbound email for @talqo.dk, including hello@ — prospect enquiries and anything a prospect chooses to send us, which can include a call transcript Company jurisdiction United States How we know Microsoft Corporation, Redmond, Washington. Vendor corporate identity. As above, the EEA contracting entity may be Microsoft Ireland Operations Ltd; not read from any agreement, not asserted. Where data is processed EU — Denmark (Exchange Online, current geography); committed geography EU/EFTA How we know Read via the tenant admin’s authenticated session in the Microsoft 365 admin centre, 19 Aug 2026: Settings -> Org settings -> Organization profile -> Data location. Exchange Online shows CURRENT geography Denmark and CONFIRMED (committed) geography European Union / EFTA; Teams, SharePoint, OneDrive and Exchange Online Protection read the same. TWO FIELDS, TWO MEANINGS, and the row states both: 'current' is where the data sits today, 'committed' is what Microsoft undertakes to honour — the current location can move within the committed geography without notice, so the committed geography is the one a reviewer should rely on. EU/EFTA is broader than the EU: it also permits Norway, Iceland and Liechtenstein (EEA) and Switzerland (not EEA, but covered by an EU adequacy decision), so no Chapter V transfer arises anywhere inside it. GOES STALE IF: Microsoft migrates the tenant, or a different committed geography is requested. Re-read the same card to refresh. PROVENANCE, stated because this file has been burned by unattributed evidence: the reading is the operator's; no automated check can see an admin centre, and DNS cannot answer this question at all. Kind of evidence admin-center reading Verified on 2026-08-19 Transfer mechanism EU/EFTA hosting — no Chapter V transfer required Note on the transfer mechanism Correct again by decision rather than by luck. This cell read 'EU hosting — no transfer required' even while data_processing_location said NOT VERIFIED — asserting no transfer while declining to say where processing happened. It is now backed by the admin-centre reading. Note the company remains US-incorporated: Chapter V is about where data goes, not where the parent is domiciled, so US ownership alone does not create a transfer. Region (summary line) US company · EU (Denmark) processing Evidence kind dns Evidence record talqo.dk MX -> talqo-dk.mail.protection.outlook.com; apex SPF v=spf1 include:spf.protection.outlook.com -all Evidence checked on 2026-08-18 Why this entry is here THE ONLY ENTRY WITH NO CODE PATH, and it declares that rather than faking one. Talqo does not call Exchange Online; mail arrives there. Until 19 Aug 2026 this entry cited talqo-site/subprocessors.json — ITSELF — as its evidence_file, with a pattern that appears in this very note. It passed the reconcile guard tautologically: the one entry not backed by code was the one entry proving itself. evidence_kind 'dns' now says so out loud, and the guard refuses any entry that cites this file as its own evidence. NOTE THE TWO EVIDENCE KINDS, which answer two different questions: evidence_kind ('dns') labels evidence_record, the MX and SPF that prove Exchange Online RECEIVES our mail — that is what makes it a subprocessor at all. data_processing_location_evidence_kind ('admin-center reading') labels the separate residency evidence. Flipping the first to 'admin-center reading' was briefly done and was wrong: it relabelled the DNS record as something it is not. Verified against DNS on 18 Aug 2026. For INBOUND mail the MX record is not merely evidence of the integration, it IS the integration: mail addressed to talqo.dk is delivered there by the record itself.
Resend	Outbound transactional email	United States	EU — eu-west-1
Evidence & details — Resend Legal entity Resend What it does Transactional email — user invitations, password-reset messages, the demo/support relay notification, and the weekly audit export Company jurisdiction United States How we know Resend, Inc., a US company. Vendor corporate identity; transfers are covered by SCCs auto-incorporated in its terms. Where data is processed EU (eu-west-1, Ireland) for the sending path — see the stated limit How we know DNS, re-checked 19 Aug 2026: send.talqo.dk MX is feedback-smtp.eu-west-1.amazonses.com and its SPF is 'v=spf1 include:amazonses.com ~all'. Resend sends through Amazon SES, and the endpoint provisioned for this domain is in eu-west-1 (Ireland). THE LIMIT, stated because the evidence does not reach further: this establishes the SES sending and feedback region. It does NOT establish where Resend's own API and control plane process a message before handing it to SES, which DNS cannot show. Anyone needing that answer must get it from Resend rather than from this file. Verified on 2026-08-19 Transfer mechanism Standard Contractual Clauses (EU SCCs) Sending domain send.talqo.dk Region (summary line) EU (eu-west-1 sending infrastructure) Evidence kind runtime Evidence file lib/mailer.js Evidence pattern api\.resend\.com/emails Evidence record Production logs: 'mail_configured' at every boot, and 'mail_sent' events with provider message ids (17 and 19 Aug 2026). Plus DNS: send.talqo.dk feedback MX feedback-smtp.eu-west-1.amazonses.com and a DKIM key at resend._domainkey.talqo.dk Evidence checked on 2026-08-19 Why this entry is here RE-ADDED 19 Aug 2026, hours after being wrongly removed the same day, and the round trip is the lesson. The removal rested on the belief that MAIL_API_KEY was unset and no mail had ever been sent. It is set, and mail has been sent. The proof is in the application's own log vocabulary: server.js emits 'mail_configured' ONLY in the else-branch of isSandbox(), so that line is literally unreachable when the key is missing, and 'mail_sent' with a provider id can only come from a real 200 from api.resend.com. Independently confirmed without log access by probing production: POST /auth/forgot for an unknown address returns the non-sandbox body, and that branch is chosen by MAIL_API_KEY alone. THE STANDING RULE THIS ESTABLISHES: an environment-dependent fact may never be asserted from reading code. The code shows what CAN happen; only the running system shows what DOES. Resend receives recipient addresses, reset links, the free text of a support message, and the weekly export attachment containing access-log emails and IP addresses.

Mail in both directions. Messages you send us arrive at Exchange Online. Messages we send you — a password reset, or our notification that your enquiry landed — go out through Resend from the send.talqo.dk subdomain. A reply to an enquiry is still written by a person.

Our full subprocessor list, with transfer mechanisms, is on our subprocessors page. An Azure OpenAI option is available for customers requiring full EU data residency — contact hello@talqo.dk to enable it.

7. Data retention

Data type	Retention period
Raw call transcripts	Not retained after analysis — processed then discarded; items awaiting processing auto-purged within 30 days. Retained by Anthropic for up to 30 days (longer only if flagged for trust & safety review), never used for training
Structured call output	Retained until you delete it or your account is closed
Account data	Retained for the account lifetime plus 12 months
Demo request submissions	Deleted within 12 months if no commercial relationship follows
Usage metadata	Retained for 90 days for security purposes

Under GDPR Articles 15–22, you have the following rights:

Right of access — you can request a copy of all personal data we hold about you
Right to rectification — you can ask us to correct inaccurate data
Right to erasure — you can ask us to delete your data
Right to data portability — you can request your data in a structured, machine-readable format
Right to restriction — you can ask us to restrict processing in certain circumstances
Right to object — you can object to processing based on legitimate interests

To exercise any of these rights, contact hello@talqo.dk. We respond within one month. There is no charge for reasonable requests. If you use Talqo through your employer, your employer is the data controller — we forward your request to them and assist per our data processing agreement.

You also have the right to lodge a complaint with the Danish Data Protection Authority (Datatilsynet) at datatilsynet.dk.

9. Security

We implement appropriate technical and organisational measures to protect your data, including TLS encryption in transit, access controls and role-based permissions, and secure session tokens with session expiry. All staff with data access are bound by confidentiality obligations.

10. Changes to this policy

We may update this policy from time to time. When we do, we update the date at the top of this page — which is the notice. We used to add "for significant changes, we will notify active users by email". We send transactional email — password resets and the like — but we have never built a way to notify every active user of a policy change, so that sentence promised a capability that does not exist. We would rather remove it than keep a line that reads well and has nothing behind it. If you want to be told directly, write to hello@talqo.dk.

11. Contact

For any privacy-related questions, data subject requests, or to request our Data Processing Agreement, contact:

Chad Kalik — Talqo
hello@talqo.dk
talqo.dk