The questions you were going to ask anyway.

How accurate is it, and how do you know?

98.2% accuracy — 214 of 218 checks across 50 deliberately difficult sales conversations, scored against answer keys written in advance. Measured on 23 August 2026.

The whole approach is on the accuracy page, alongside a complete difficult call beside Talqo’s unedited output. The right answers were written down before the test was run; two were corrected on review, when re-reading showed the product was right and the sheet was wrong, and the ledger names both. The test runs the product rather than a raw model, as it stood on the day of the run. If the number moves, the page moves.

The design bias is deliberate and testable: Talqo would rather say too little than too much. Across all 50 conversations it never once recorded a commitment the buyer had not made. Full methodology and test data are available for review on request.

What do you keep, and for how long?

Transcripts are not kept. A call is analysed and the transcript is discarded — it is not stored as a record. A transcript waiting in the queue is auto-purged within 30 days if it is never processed.

What is stored is the structured output: the summary, the qualification scores, the action items, the deal facts and the quotes that evidence them. That is the product — it is what you are paying to keep — and it is deletable on request, per call or per person.

Our AI subprocessor retains API content for up to 30 days (longer only if flagged for trust & safety review) and never uses it for training. If the analysis must stay in the EU, it can run on your company’s own Azure OpenAI resource instead, in the EU region you choose; we connect it with you.

Who else touches the data?

Five subprocessors, listed in full with roles, locations and transfer mechanisms on the subprocessors page. Each is given as company jurisdiction → where data is actually processed, because those are different questions and collapsing them lets a row read as “EU” on the strength of whichever half is friendlier:

• Render — Application hosting, database and disk. United States company → EU — Frankfurt. None required.
  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 company → United States. EU SCCs.
  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 company → Customer-controlled. Depends on your region.
  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 company → EU — Denmark. None required.
  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 company → EU — eu-west-1. EU SCCs.
  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 moves in both directions, and the two providers are different. What you send us is received by Exchange Online. What we send you goes out through Resend. A reply to an enquiry is still written by a person — Resend carries the notification that your message arrived, not the answer.

Can we get our data out?

Yes, without asking us. Any user can export their own record from My profile — account details plus their calls with summaries, scores, action items, next steps, concerns and every piece of coaching on them, including the 1-1 preparation their manager sees, as JSON. An admin can export any user in their company for an Article 15 request, which additionally includes deals, cadences, coaching snapshots and deleted calls.

Can we get it deleted?

Yes, at three levels. A single call can be removed from the product. A person can be erased for an Article 17 request — that reaches their calls including ones already soft-deleted, which we fixed after an erasure walk found the gap rather than after a customer did. And a third party named in a call — someone who never used Talqo and never agreed to anything — can be redacted by name across the stored analysis.

Erasure has a dry run that changes nothing, so you can see the blast radius before you commit.

What happens if we want to stop?

Your notice period and term are whatever your signed pilot or subscription agreement says, and we will state them plainly in writing before you sign anything — we are not going to summarise a contract you have not read on a marketing page.

What we will commit to here: no per-call fees and no usage meters (a fair-use limit per hour protects the service), so leaving is not made expensive by making staying cheap; seats belong to the company, not to a named person; and renew on time and your price is locked. Export works without our involvement, so getting your data out is not a thing you have to negotiate on your way out of the door.

Who owns what?

You own your data. We own the platform. We process your data solely to provide the service to you. We do not sell it, we do not use it to train models, and we do not use one customer’s calls to improve what another customer sees.

The analysis produced from your calls is your data too — it is a description of your conversations. You can export it at any time from inside the product.

What happens to our data — and our contract — if Talqo stops operating?

The honest framing first: we are a young company, and this is a real risk you are right to price in. Nothing below is a guarantee dressed up as one, because a guarantee from a company that has ceased to exist is worth nothing — which is exactly why the answer has to be about what you can do without us.

Your data is exportable today, by you, without asking. That is the part that actually protects you, and it is the part you should test early rather than take on trust: any user can export their own record from My profile, and an admin can export any user in the company. Export does not depend on our goodwill, our availability, or a support ticket. If you want a standing copy, take one on a schedule — we would rather you did.

What is stored is deliberately portable. The output is structured data — summaries, scores, action items, deal facts and the quotes evidencing them — as JSON, not a proprietary artefact that only means something inside Talqo. What Talqo adds is the reading, and the reading is written down in a form you keep.

What we will commit to, in writing, in the agreement: a defined notice period before service ends, and a data-export window inside it. If we wind down deliberately, you get notice and a window to take everything out. Ask for both to be written into your contract — and if a vendor will not put that in writing, that is worth knowing about any vendor, including us.

What we cannot promise, and will not pretend to: that an abrupt failure — insolvency, a founder under a bus — comes with an orderly wind-down. No small vendor can promise that honestly. There is no escrow arrangement today and we are not going to imply one exists. The mitigations that are real are the ones above: export early, export often, and hold a copy you control. Talqo also does not keep your transcripts (one still waiting in the queue is purged within 30 days), so the worst case is the loss of an analysis layer over conversations you still own — not the loss of the record itself.

What don’t you have?

No SOC 2 and no ISO 27001. We are a young company and certification is a roadmap item, not a claim. No single sign-on, no SCIM provisioning and no second login factor yet, and no tenant-wide audit log yet. The security page has a “What we do not have yet” section that stays current, because the fastest way to lose a security reviewer is to have them find the gap themselves.

If a certification is a hard requirement for you today, we would rather tell you now than six weeks into a procurement process.