Data Processing Agreement (DPA)

Effective Date: 19 March 2026

This Data Processing Agreement (“DPA”) is concluded pursuant to Art. 28 of the General Data Protection Regulation (EU) 2016/679 (GDPR). It supplements, and is incorporated into, the API Terms of Service (“Agreement”) governing the use of the Tontaube API. It is entered into by and between the registered user acting as an Entrepreneur under § 14 BGB (“Customer” or “Data Controller”) and Cremer & Cremer Technologies UG (haftungsbeschränkt), Herderstraße 22, 12163 Berlin, Germany (“Provider” or “Data Processor”).

Capitalized terms not defined in this DPA have the meanings provided in the Agreement. By accepting the Agreement, creating an account, or using the API, the Customer agrees to this DPA.

1. Details and Scope

1.1 Scope and Roles. As part of providing the API to the Customer, the Provider may Process Personal Data on behalf of the Customer. The Customer acts as the Data Controller, and the Provider acts as the Data Processor. This DPA governs such Processing.
1.2 Details of Processing. The Provider will only Process Customer Data for the purposes of delivering the API services pursuant to the Agreement and this DPA. Details regarding the nature, duration, types of Customer Data, and categories of Data Subjects are set out in Schedule 1.

2. Provider Obligations

2.1 Customer Instructions. The Provider will process Customer Data only in accordance with the Customer’s documented instructions, which include the Agreement, this DPA, and API requests made by the Customer.
2.2 Notices to Customer. The Provider will promptly inform the Customer if, in the Provider’s opinion, a Customer instruction violates the GDPR or other EU Data Protection Laws. The Provider will, to the extent legally permitted, inform the Customer if it receives a legally binding request for disclosure of Customer Data by a law enforcement authority.
2.3 Confidentiality. The Provider will ensure that all personnel authorized to process Customer Data are bound by appropriate confidentiality obligations.
2.4 Data Subject Requests. If the Provider receives a request from a Data Subject to exercise their rights (e.g., access, deletion) regarding Customer Data, the Provider will not respond directly without the Customer’s prior authorization, except to redirect the Data Subject to the Customer. The Provider will reasonably assist the Customer in fulfilling these requests.
2.5 Security. The Provider will implement and maintain reasonable technical and organizational measures (TOMs) to protect Customer Data, as outlined in Schedule 2.
2.6 Assistance to Customer. Taking into account the nature of the processing, the Provider will provide reasonable assistance to the Customer with data protection impact assessments (DPIAs) and prior consultations with supervisory authorities, if required.
2.7 Personal Data Breaches. The Provider will notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of any Personal Data Breach affecting Customer Data. The notification will include, to the extent available, the nature of the breach, the categories and approximate number of Data Subjects affected, and the measures taken or proposed to address it. The Provider will provide reasonable assistance to mitigate the breach.
2.8 Assessing Compliance (Audits). On the Customer’s reasonable written request (no more than once per year), the Provider will provide information necessary to demonstrate compliance with this DPA. Physical audits or inspections by the Customer are only permitted if strictly required by mandatory law, must be conducted during regular business hours with 30 days’ notice, at the Customer’s expense, and must be minimally disruptive. The Provider may satisfy audit requests by providing recent, independent security certifications or audit reports.
2.9 Engagement of Sub-processors. The Customer hereby grants the Provider general written authorization to engage the Sub-processors listed in Schedule 3. The Provider will notify the Customer (e.g., via email or website update) at least 30 days before adding or replacing a Sub-processor. The Customer may object to the change within 14 days for legitimate data protection reasons. If the objection cannot be resolved, either party may terminate the Agreement.
2.10 Sub-processor Obligations. The Provider will enter into written agreements with Sub-processors imposing data protection obligations comparable to those in this DPA.
2.11 Deletion or Return of Data. Upon termination of the Agreement, the Customer may request the return of Customer Data in a standard, machine-readable format within 14 days of termination. The Provider will delete all Customer Data (including Voice Samples and generated Output retained on its servers) within 30 days of termination or within 30 days of completing the data return, whichever is later, unless EU or Member State law requires further storage.
2.12 Ad-hoc Deletion. During the term of the Agreement, the Customer may request the deletion of specific Voice Samples and derived voice profiles at any time by contacting the Provider. The Provider will process such requests without undue delay.

3. Customer Obligations

3.1 Lawfulness of Processing. The Customer warrants that it has a valid legal basis under GDPR Article 6 (and Articles 7 and 9, where applicable) to process the Customer Data and transmit it to the Provider.
3.2 Voice Cloning Consent. Where the Customer utilizes the API to process Voice Samples for Voice Cloning, the Customer warrants that it has obtained and documented the explicit, informed consent of the respective speaker.
3.3 Configurations. The Customer is responsible for securely configuring their API integration and ensuring that the data transmitted to the API complies with the Acceptable Use Policy in the Agreement.
3.4 Processing of Special Categories of Data. If the Customer utilizes the API to process special categories of personal data (Art. 9 GDPR), the Customer bears the sole responsibility for ensuring that a valid exception under Art. 9(2) GDPR applies (e.g., explicit consent of the Data Subject). The Customer must ensure that their API implementation strictly limits the transmission of such sensitive data to what is absolutely necessary for their specific use case.

4. International Data Transfers

4.1 Transfers outside the EEA. To the extent the Provider or its Sub-processors transfer Customer Data outside the European Economic Area (EEA) to a country not recognized by the European Commission as providing an adequate level of protection, such transfers shall be governed by the Standard Contractual Clauses (SCCs) as set out in Commission Implementing Decision (EU) 2021/914, Module 2 (Controller to Processor), which are hereby incorporated by reference.
4.2 Supplementary Measures. In accordance with the CJEU’s judgment in Schrems II (Case C-311/18), the Provider implements the following supplementary measures for international transfers: (a) encryption of Customer Data in transit (TLS 1.2+) and at rest (AES-256); (b) strict access controls limiting access to authorized personnel; (c) contractual commitments from Sub-processors to resist unlawful government access requests and to notify the Provider where legally permitted.
4.3 Processing Locations. Customer Data is primarily processed within the EU/EEA. For the purpose of low-latency service delivery, Customer Data may also be processed in the United States by authorized Sub-processors operating under SCCs and the supplementary measures described in Section 4.2. The Provider maintains a current list of Sub-processor locations in Schedule 3.

5. Definitions

• ”Customer Data” means Personal Data processed by the Provider on behalf of the Customer via the API.
• ”Data Protection Laws” means the General Data Protection Regulation (EU) 2016/679 (GDPR) and the German Federal Data Protection Act (BDSG).
• ”Personal Data,” “Data Subject,” “Processing,” “Controller,” and ”Processor” have the meanings given to them in the GDPR.
• ”Personal Data Breach” has the meaning given to it in Art. 4(12) GDPR.
• ”Sub-processor” means any third party engaged by the Provider to process Customer Data on behalf of the Customer.

Schedule 1: Details of Processing

1. Nature and Purpose:
Conversion of text to synthetic audio via the Provider’s text-to-speech API, and the processing of audio recordings to create custom synthetic voice profiles (Voice Cloning).

2. Duration:
The duration of processing depends on the type of Customer Data and the specific API operation:

• Standard (Synchronous) TTS Requests: Input text and generated Output audio are processed ephemerally in memory. Data is held only for the duration required to generate and return the audio response, after which it is immediately discarded and not written to persistent storage.

• Asynchronous / Long-Form TTS Requests: To facilitate processing of long-form content, Input text and the resulting Output may be temporarily cached in secure, encrypted storage. This cached data is automatically and permanently deleted via a Time-To-Live (TTL) mechanism no later than 14 days after generation.

• Voice Cloning (Voice Samples & Profiles): Retained for the duration of the Customer’s active API account to maintain the custom voice profile, plus the period required for final data deletion pursuant to Section 2.11 (up to 30 days following termination, or up to 30 days after completion of any Customer-requested data return, whichever is later), unless the Customer requests earlier ad-hoc deletion pursuant to Section 2.12.

3. Categories of Customer Data:

• Unstructured text data submitted to the API (which may inadvertently contain names, contact details, or other PII).
• Voice recordings/audio files (Voice Samples) submitted for the purpose of Voice Cloning.

4. Categories of Data Subjects:
The Customer’s end-users, employees, customers, or any third party whose text or voice is submitted to the API by the Customer.

5. Sensitive Data:
Given the nature of the API’s use cases (e.g., powering customer care agents), the Customer may transmit unstructured text Input that contains special categories of personal data as defined in Art. 9 GDPR (such as health data, racial or ethnic origin, or religious beliefs). Furthermore, Voice Samples used to create biometric voice profiles constitute sensitive biometric data. The Provider applies strict, elevated technical and organizational measures (TOMs) to protect this data and strictly prohibits the use of any Customer Data for cross-customer AI model training.

Schedule 2: Technical and Organizational Measures (TOMs)

The Provider implements the following measures to ensure the security of Customer Data:

• Encryption: All data in transit is encrypted using TLS 1.2 or higher. Data at rest is encrypted using industry-standard algorithms (e.g., AES-256).
• Access Control: Access to production servers and databases is strictly limited to authorized personnel via role-based access control (RBAC), multi-factor authentication (MFA), and secure VPNs.
• Separation of Data: Customer Data is logically segregated within the Provider’s multi-tenant database infrastructure.
• Availability: Regular automated backups are performed to protect against accidental loss or destruction of data.
• Logging & Monitoring: Access to Customer Data, including Voice Samples and voice profiles, is logged. Logs are reviewed to detect unauthorized access or anomalies.
• Incident Response: The Provider maintains a documented security incident response procedure covering identification, containment, eradication, and notification.
• Employee Training: Personnel with access to Customer Data receive regular training on data protection and information security.
• Security Testing: The Provider conducts periodic vulnerability assessments of its infrastructure. Critical vulnerabilities are remediated promptly.
• Pseudonymization: Where technically feasible, voice profiles and associated Customer Data are stored using pseudonymized identifiers.
• Network Security: Backend services operate within an isolated private network (VPN/VPC) hosted on Google Cloud Platform. The Provider utilizes the underlying cloud provider’s default routing controls, firewalls, and baseline infrastructure protections.
• Data Minimization & Ephemeral Processing: The Provider employs ephemeral processing for standard, synchronous API requests, ensuring payload data (Input and Output) is held in volatile memory only for the duration of the transaction and is not written to persistent storage. Where temporary caching is technically required for asynchronous processing, data is subjected to strict, automated Time-To-Live (TTL) deletion protocols as described in Schedule 1.

Schedule 3: Authorized Sub-processors

The Customer authorizes the following Sub-processors. A current version of this list is also available at [SUB-PROCESSOR LIST URL].

Governing Law & Jurisdiction: This DPA is governed by the laws of the Federal Republic of Germany. The exclusive place of jurisdiction is Berlin.