Documento legal
Data Processing Addendum
Última atualização: . Escrito em inglês.
Adapted from the Basecamp open-source policies (https://github.com/basecamp/policies, commit 05fb1f9ddaaf604fc5816990fa66f3ffd7f0a462) / CC BY 4.0. Source file: privacy/regulations/dpa/Data_Processing_Addendum_current.pdf (37signals DPA, last updated 2023-04-20). See Changes from the template.
True today, and what applies to real clinics
No clinic has signed this addendum. The public demo uses fictional clinic and caller data; historical owner-authorized test records are separate from that demo. Until a clinic signs it and the applicable pre-pilot legal, provider and product gates are met, no real patient call may reach the Service. Section 7.3 and Annex II item 11 describe operator-access notices and a 12-month audit-log retention (the owner shortened it from 3 years on 3 November 2026; built in the source, not yet observed in Production). Both are built but not live: they need migration 0102_operator_reveal_notices applied and deployed, and a read-back of one reveal and one purge (work item ENG-065).
1. Parties and scope
This addendum forms part of the Terms of Service (the "Agreement") between the clinic named in the order form (the "Clinic") and Peraditus, Lda, NIF 515457558, Avenida da República, N.º 856, 1.º, Esq.º Frente, 4450-240 Matosinhos, Porto ("we", "us") (verified against the Certidão Permanente). If this addendum and the Agreement conflict on the processing of personal data, this addendum wins. If the Standard Contractual Clauses apply and conflict with this addendum, the Clauses win.
Terms such as "controller", "processor", "personal data", "processing", "data subject", "personal data breach" and "supervisory authority" have the meaning in Regulation (EU) 2016/679 (the "GDPR"). "Clinic Personal Data" means the personal data we process on the Clinic's behalf to provide the Service, as described in Annex I. "Subprocessor" means a processor we engage.
2. Roles
2.1 For Clinic Personal Data the Clinic is the controller and we are the processor (GDPR Art. 28).
2.2 For data about the Clinic's account, staff users and billing, we are a separate controller. The Privacy Policy covers that data, not this addendum.
3. The Clinic's obligations
The Clinic:
- gives instructions that comply with the GDPR and Portuguese law, including Lei n.º 58/2019
- is responsible for the accuracy of the clinic knowledge it publishes and for the lawfulness of the data it asks the Service to collect
- tells callers, before or at the start of each call, that an AI answers and whether the call is recorded, and publishes a patient privacy notice
- decides and records the lawful basis for each purpose, and the condition under GDPR Art. 9(2) for health data that callers mention (open item L19)
- decides whether calls are recorded (open item L18)
- answers data subject requests, with our help under section 6
4. Our obligations
4.1 Instructions. We process Clinic Personal Data only on the Clinic's documented instructions, including on transfers outside the EEA, unless EU or Portuguese law requires otherwise. In that case we tell the Clinic first, unless the law forbids it. The Agreement, this addendum and the Clinic's settings in the dashboard (clinic knowledge, practitioners, opening hours) are the Clinic's instructions. Other instructions must be agreed in writing.
4.2 Unlawful instructions. We tell the Clinic at once if we think an instruction breaks the GDPR or other data protection law.
4.3 No other use. We do not sell Clinic Personal Data. We do not use it to train AI models, to build profiles or for any purpose of our own. We do not combine it with data from other clinics. We do not try to re-identify data that has been masked.
4.4 Government requests. If an authority asks us for Clinic Personal Data, we tell the Clinic promptly, unless the law forbids it, and we disclose only what a valid legal order compels.
4.5 DPIA and prior consultation. We help the Clinic with its data protection impact assessment and any prior consultation with the CNPD, with the information we hold. A draft outline is in dpia-outline.md.
4.6 We cannot comply. We tell the Clinic at once if we can no longer meet this addendum.
5. Health data and other special categories
5.1 The Service does not ask callers for health information. Callers may still say it, for example when they describe pain to explain why they want an appointment. That data is special-category data under GDPR Art. 9. It may appear in a captured transcript and, when the call is recorded, in its audio.
5.2 For this data:
- the agent is instructed never to diagnose, prescribe or give health advice. These instructions are in code and the Clinic cannot edit them
- the booking sent to Cal.com carries the caller's name, phone number, time zone, language, treatment type, time and our internal booking id only. No clinical notes
- current patient call transcripts and recordings are kept 6 months in the source (section 9); production deletion has not been verified
- telemetry never contains transcripts or summaries (Security overview)
- access in the dashboard is limited to members of that Clinic
5.3 Whether these safeguards are enough, and whether health data may be stored outside the EEA, is a decision for the Clinic and its lawyer (open items L19 and L20).
6. Data subject requests
6.1 If a caller asks us, instead of the Clinic, to exercise a GDPR right, we pass the request to the Clinic within 1 working day and do not answer it ourselves unless the Clinic tells us to.
6.2 We help the Clinic answer requests. Today the dashboard lets staff view and export call records and transcripts (CSV or JSON), and play an available call recording. The dashboard has no recording download/export action. Other requests, such as erasure of one caller's data at every provider, need our help and are done by hand. We finish our part of the help within 5 working days of the Clinic's written request.
7. Confidentiality and our personnel
7.1 Only people who need it to run the Service have access to Clinic Personal Data. Today that is [PERSONNEL WITH ACCESS] (open item L34).
7.2 Each of them is bound by a written confidentiality obligation that survives the end of their engagement (open item L34).
7.3 Our personnel see Clinic Personal Data only through a read-only operator console, and only for support or a demo the Clinic asked for. In that console caller numbers are masked and call summaries and transcripts are hidden. Seeing one call's content needs a written reason, and every view and every reveal is recorded in a log that nobody can change, and that is deleted only when a row is 12 months old. The console cannot change Clinic data or act as a Clinic user. We tell the Clinic of every reveal within 24 hours, in its dashboard and by email. We keep each audit row for 12 months from its date, including after the Clinic leaves, then delete it.
8. Subprocessors
8.1 General authorisation. The Clinic authorises us to use the subprocessors listed in Subprocessors and summarised in Annex III.
8.2 Flow-down. We impose on each subprocessor data protection obligations no less protective than this addendum. Whether each provider's standard terms meet this has not been reviewed (open item L15).
8.3 Changes. We ask the Clinic 30 days before a new subprocessor processes Clinic Personal Data, as described in Policy updates.
8.4 Agreement. A new subprocessor needs the Clinic's written agreement. If the Clinic refuses, we do not use it for that Clinic, or either party may end the affected part of the Agreement without a charge, and we refund prepaid fees for the rest of the term pro rata. When an upstream provider announces a change, we forward the notice to the Clinic within 1 working day and ask for its answer within 5 calendar days.
8.5 We remain liable to the Clinic for our subprocessors' performance.
9. Retention
9.1 Current patient calls use the LiveKit runtime. Eligible call audio is captured through managed Egress into private Supabase Storage; call records and captured transcripts are held in the Supabase database. The application source keeps call rows and patient recording artifacts for 6 months after the call starts and then deletes them. A recording the caller refused is deleted at once. Historical conversations and recordings from the former ElevenLabs runtime are separate and may remain under their earlier provider retention settings.
9.2 The source includes a LiveKit-session maintenance route that attempts to remove expired recordings and associated private storage objects. Expiry also prevents current dashboard access after the deadline. The production invocation of this maintenance, physical removal of call rows and artifacts, and provider read-back on a real call have not been verified (open item L25). The source retention period must not be treated as proof of production deletion. Production retention enforcement remains unverified and must be resolved before a real-clinic pilot. Historical ElevenLabs cleanup follows its separate former-runtime path; removal of a real transcript and recording there has not been verified either (open item L25).
9.3 The owner decided on 3 November 2026 that every real record is kept at least 6 months. The source deletes the following after these periods, by daily scheduled jobs. They are built in the source, not yet observed in Production (open item L25):
- 6 months: call metadata, call idempotency receipts, voice session content, test call results, the notification outbox and SMS send reservations, website preparations that never became a clinic, and demo sessions.
- 12 months: messages, booking intents and changes (12 months after the slot), appointment requests, invitations (the plain address is cleared 7 days after expiry and the row is deleted 12 months after it ends), the team membership log and the operator audit log.
- 24 months: the AI usage ledger.
- While the Clinic exists: notification opt-outs and notification settings.
- The billing usage ledger is kept for the tax period our accountant confirms. No job deletes it.
Short-lived records keep shorter periods: sign-in attempts 24 hours, abandoned sign-ups 7 days, identity challenges 1 day after expiry, tool write attempts 24 hours, invite attempts 24 hours and invitation return intents 1 hour. Historical ElevenLabs conversations are unchanged.
10. Security
10.1 We maintain the technical and organisational measures in Annex II. We do not lower the overall level of security during the term.
10.2 The Clinic may take reasonable steps to stop processing that this addendum does not allow.
11. Personal data breaches
11.1 We tell the Clinic without undue delay, and within 24 hours, after we become aware of a personal data breach affecting Clinic Personal Data. We tell the Clinic by email and by phone to its named contact. The first notice may be incomplete. The Clinic then decides whether to notify the CNPD, which GDPR Art. 33 requires within 72 hours of the Clinic becoming aware, and whether to tell callers.
11.2 Our notice says what we know at the time: what happened, which categories and roughly how many people and records are affected, the likely consequences, what we have done, and who to contact. We add to it as we learn more.
11.3 Our internal steps are in the "Suspected data leak" runbook in operations-and-incidents.md.
12. Audits and information
12.1 On request we give the Clinic the information needed to show that we meet GDPR Art. 28, including this repository's security evidence listed in the Security overview. We hold no third-party certification or audit report.
12.2 The Clinic, or an auditor bound by confidentiality, may audit us. We give documents first, on request and free of charge. The Clinic may then audit us once a year, remotely or on site, with 30 days' written notice. An extra audit is allowed when there are indications of non-compliance, after a breach, or when the CNPD asks. Each party pays its own costs. Audit rights at each subprocessor depend on that provider's terms (open item L15).
13. Return and deletion
13.1 At the end of the Agreement the Clinic chooses whether we return Clinic Personal Data or delete it. The export formats, the provider-side deletion steps and the timelines are in Offboarding and data export.
13.2 We delete Clinic Personal Data from active systems within [DELETION DAYS] of the end, and from backups within [BACKUP RETENTION DAYS] (open items L16 and L17), unless EU or Portuguese law requires us to keep it. We send a written deletion confirmation.
14. International transfers
14.1 Some subprocessors store or process Clinic Personal Data outside the EEA. The current LiveKit Cloud project and Supabase project are configured in Frankfurt; this does not establish EU-only model or other provider processing. Historical artifacts from the former ElevenLabs runtime are stored in the United States under the earlier setup. Better Stack stores telemetry in the United States. Processing locations for current model and speech providers remain unverified. Other locations are listed in Subprocessors.
14.2 Each such transfer needs a mechanism under GDPR Chapter V, such as an adequacy decision (including the EU-US Data Privacy Framework where the provider is certified) or the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, Module 3 for our transfers to subprocessors). We have not confirmed the mechanism for any provider (open item L14). Until we do, this addendum makes no claim that the transfers are lawful.
15. Liability, term and law
15.1 Each party's liability under this addendum is subject to the limit for breaches of this addendum and of confidentiality in the Liability section of the Terms of Service: the greater of 3 times the general limit and EUR 50,000. That section also lists the liability that is never limited.
15.2 This addendum lasts as long as we process Clinic Personal Data.
15.3 This addendum follows the governing law of the Agreement, which is Portuguese law.
Annex I. Processing details
| Item | Details |
|---|---|
| Clinic (controller) | [CLINIC LEGAL NAME], NIF [CLINIC NIF], [CLINIC ADDRESS], contact [CLINIC PRIVACY CONTACT] |
| Processor | Peraditus, Lda, NIF 515457558, Avenida da República, N.º 856, 1.º, Esq.º Frente, 4450-240 Matosinhos, Porto, contact support@transversal.io (open items L1 and L2) |
| Subject matter | AI telephone reception for the Clinic |
| Duration | The term of the Agreement plus the offboarding period in section 13 |
| Nature | Receiving and answering calls, speech recognition and synthesis, generating replies with an LLM, checking availability and creating bookings in the Clinic's calendar, recording messages and change requests, storing call records for staff review |
| Purpose | Answer callers, book appointments, pass messages and requests to Clinic staff |
| Data subjects | People who phone the Clinic, mostly patients and prospective patients |
| Personal data | Phone number, the forwarding line's number carried in the Diversion header (the Clinic's own number), name, appointment details (practitioner, treatment, time), call audio when recording is on, transcript, call summary, messages, change requests |
| Special categories | Health information that callers say during the call. See section 5 |
| Frequency | Continuous, on every call |
| Retention | Current patient call records, transcripts and recordings, 6 months. Messages, booking intents and changes, and appointment requests, 12 months. Built in the source, not yet observed in Production (open item L25). See section 9 |
Annex II. Technical and organisational measures
This annex lists only measures that the repository shows are in place. Each has evidence in the Security overview, which also lists what is not in place.
- Tenant isolation. Every clinic table has Postgres row-level security with per-clinic policies. The clinic comes from the signed-in user's membership, or on a telephone call from the forwarding line's number in the
Diversionheader, never from the browser or the caller's number. - Signed webhooks. Post-call webhooks are checked with HMAC-SHA256 over the raw body and a 30-minute timestamp tolerance. A bad or missing signature is refused and nothing is stored.
- Signed tool calls. The agent's calls to our booking and message tools carry a per-clinic signature that our server checks.
- Secrets. Provider keys stay on the server. A secret scanner runs as part of
pnpm check. - Telemetry redaction. Secrets, transcripts, summaries, names and email addresses are removed from telemetry, and phone numbers are cut to their last three digits, before an event leaves the server.
- Masked caller numbers. Call records in the dashboard store the caller number masked.
- Forwarding header. The application reads the forwarding line's number from the
Diversionheader only to match the Clinic. It keeps the matched Clinic and a pass or fail result, never the raw header. - Sign-in. Dashboard sign-in is by one-time email code, and only for invited members. A simulated sign-in mode is refused in production.
- Transport. The web application sends HTTPS-only headers (HSTS).
- Call retention. Current patient call records and recording artifacts are kept 6 months in the source; the source maintenance path and production deletion/read-back gap are described in section 9. Former ElevenLabs artifacts use a separate legacy path.
- Operator access. Personnel access is read-only, masked and sealed by default, needs a written reason to reveal a call's content, and is recorded in an append-only audit log kept for 12 months (section 7.3). No multi-factor authentication yet (open item L36).
Annex III. Subprocessors
The full list, with data categories, location status and sources, is in Subprocessors.
| Subprocessor | Purpose | Storage location |
|---|---|---|
| LiveKit Cloud | Current voice runtime, media and Egress capture | EU (Frankfurt project setting) |
| Current model and speech providers | Recognition, reasoning and speech generation through Vercel AI Gateway | Provider-specific locations unverified |
| ElevenLabs | Former voice runtime; historical conversations and recordings only | US (verified) |
| Historical LLM vendor (Google Gemini, through former ElevenLabs runtime) | Reply generation for historical conversations | Unverified |
| Telnyx | Carrier for the shared assistant number and SIP connection to LiveKit | US default or Germany, setting unverified |
| Cal.com | Calendars and bookings | Unverified |
| Supabase | Database, sign-in and private patient call recordings | Frankfurt (configured) |
| Vercel | Hosting, web application and API routes; Vercel AI Gateway for recognition, reasoning and speech generation | Frankfurt functions (configured), logs and downstream speech processing locations unverified |
| Better Stack | Redacted telemetry | US (verified) |
Changes from the template
- Rewrote the 37signals DPA as a plain-language addendum between one clinic as controller and us as processor.
- Removed the CCPA and US state privacy law terms, the UK Addendum, the Swiss FADP terms, the Authorised Affiliates section and the processor-to-processor clauses (Module 3 from the Clinic), because they do not apply to a Portuguese clinic.
- Removed the Irish law, Irish courts and Irish DPC choices. Law is Portuguese and there is no forum clause, and the CNPD is named for breach notices.
- Added section 5 on health data (GDPR Art. 9) and the AI voice context.
- Replaced the reference to the 37signals security whitepaper with an annex of measures that this repository evidences.
- Added the retention section and the then-known gap in expiry deletion.
- Replaced fixed periods (10 business days to object) with the periods the owner accepted on 2 November 2026 without a lawyer (owner-decisions-2026-11-02.md). Other periods remain open items.
- Replaced the deemed signature of the Clauses with an open item, because no transfer mechanism is confirmed.
- Added the processing details, measures and subprocessor annexes from our own facts.
Provider identification
- Legal name
- Peraditus, Lda
- NIPC (tax number)
- 515457558
- Legal form
- Private limited company (sociedade por quotas)
- Share capital
- €5,000.00
- Registered office
- Avenida da República, N.º 856, 1.º, Esq.º Frente, 4450-240 Matosinhos, Porto
- Incorporated on
- 26 April 2019
- Activity codes (CAE Rev. 4)
- 62100 (principal), 62201, 71110, 85591
- How the company is bound
- The intervention of 1 manager (gerente)
- Contact
- support@transversal.io
- Source
- Certidão Permanente
Data from the official commercial registry certificate (Certidão Permanente), verified on 22 October 2026. The certificate is valid until 19 June 2027.
Adaptado das políticas open source da Basecamp, sob licença CC BY 4.0. Cada documento indica as alterações que fizemos.