Data Processing Agreement

This Data Processing Agreement ("DPA") is entered into between the clinic that holds a Perla account ("the Controller") and Vladyslav Kutsyn, Mladá Boleslav, Czechia ("the Processor", "we"), which operates the Perla service.

The Controller determines the purposes and means of processing personal data about its own patients. The Processor processes that data only on the Controller's behalf and on its instructions. With respect to the Controller's own account data — the email address used to sign up, billing details and support correspondence — the Processor acts as a controller in its own right, and that processing is described in the Privacy Policy rather than here.

This DPA forms part of, and is subject to, the Terms of Service. Where they conflict on the subject of personal data, this DPA prevails.

Subject matter: the operation of an AI assistant that answers patient enquiries on the Controller's website and in the Controller's messaging channels, collects appointment requests, and passes them to the Controller.

Nature of the processing: collection, storage, automated generation of replies by a large language model, transmission to the Controller by email and, where the Controller has connected it, by Telegram, and deletion.

Purpose: to answer patients and to deliver their appointment requests, cancellations and questions to the Controller. The Processor does not use the data for any other purpose, and specifically does not use it to train models, to profile patients, or for advertising.

Duration: for as long as the Controller holds an active account, plus the retention periods set out in clause 12.

Data subjects: the Controller's patients and prospective patients, and the Controller's own staff who use the dashboard.

Personal data: a patient's name and telephone number where they provide it; the text of their messages; the language and the page they wrote from; the time of the exchange; and, where the patient used the Telegram bot, their Telegram chat identifier and first name.

SPECIAL CATEGORY DATA. The Controller and the Processor both acknowledge that the free text a patient writes to a dental assistant routinely reveals data concerning health within the meaning of Article 9 — a described symptom, a named treatment, a request for a particular specialist. Neither party solicits it, and the assistant is instructed never to ask for medical history, insurance numbers or identity documents, but it arrives unprompted and it is processed. The measures in clause 6 are specified on the assumption that Article 9 data is present.

The Processor does not process payment card data, government identifiers or insurance numbers. No payment is taken in the chat.

The Processor processes personal data only on the documented instructions of the Controller. The configuration the Controller enters in the dashboard — its services and prices, its doctors, its opening hours, its escalation notes, its retention periods and its chosen notification channels — constitutes those instructions, together with this DPA and the Terms.

The Processor informs the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection law, and may suspend the affected processing until the instruction is withdrawn or confirmed.

The Processor ensures that any person authorised to process the Controller's data is subject to a duty of confidentiality and processes it only as necessary to operate and support the service.

Access to production data is limited to the operator of the service. Support access to a Controller's conversations is exercised only where necessary to diagnose a fault reported by that Controller.

The following measures are implemented today, not planned:

Encryption in transit. All traffic between patients, the Controller, the application and every sub-processor is carried over TLS.

Encryption at rest of message content. The text of every message is encrypted with AES-256-GCM before it is written to the database. The encryption key is held in the application's server environment and is never stored in the database that holds the encrypted rows, so a compromise of the database alone — a leaked database credential, an exported backup, a misconfigured access rule — does not disclose what any patient wrote. The cipher is authenticated, so a row altered in the database fails to decrypt rather than decrypting to a plausible but different value.

The limits of that encryption, stated plainly. This is not end-to-end encryption and must not be understood as such. The assistant's function requires a language model to read the patient's message, so plaintext necessarily exists in memory and is transmitted to the model provider. The Processor is therefore technically able to decrypt stored messages. What the measure achieves is that the stored form is not readable, and that is the claim made.

Tenant isolation. Every record carries the owning clinic's identifier and is protected by row-level security in the database, enforced by the database itself rather than by application code. Dashboard sessions read only their own clinic's rows. Server endpoints that act on patient data verify ownership before acting, rather than trusting an identifier supplied by the caller.

Data minimisation. No IP addresses, no browser fingerprints, no advertising or analytics trackers, and no payment data are collected. The assistant is instructed not to request medical history or identity documents.

Deletion. Retention periods are enforced automatically by a scheduled task (clause 12), and deletion is a hard delete, not a flag.

Access control. Administrative access to the server and to the database provider is protected by separate credentials; the service-role database credential exists only in the server environment and is never exposed to a browser.

Logging. Operational logs record the fact and outcome of an action, not the content of patient messages.

The Controller authorises the Processor to engage the sub-processors listed below. Each is engaged under a written contract imposing data protection obligations no less protective than those in this DPA, and the Processor remains liable to the Controller for their performance.

Supabase Inc. — database, authentication. Location: EU (AWS). Receives: account, clinic profile, conversations, requests.

OpenAI Ireland Ltd. — generating chat replies. Location: EU / USA. Receives: patient messages and the clinic profile sent as context.

Resend, Inc. — sending notification email to the clinic. Location: USA. Receives: patient name, phone, reason for the visit.

Telegram FZ-LLC — clinic notifications and the patient bot — only if the clinic connects it. Location: UAE. Receives: patient name, phone, and their messages.

netcup GmbH — server hosting. Location: Nuremberg, Germany. Receives: everything in transit; no patient data stored on disk.

Zoho Corporation — mailbox for hello@getperla.eu. Location: EU (Zoho EU data centre). Receives: correspondence sent to us, including data subject requests.

The Processor will give the Controller at least thirty days' notice before adding or replacing a sub-processor that processes patient data. The Controller may object on reasonable data protection grounds, in which case the parties will discuss a resolution in good faith; if none is found, the Controller may terminate the affected part of the service.

Telegram is engaged only where the Controller chooses to connect it. A Controller that does not connect Telegram has no patient data processed by it.

The database and the application server are located in the European Union. Two sub-processors involve a transfer outside it, and the Controller should be aware of both before relying on the service.

United States. The model provider and the email provider process data in the United States. Transfers are made on the basis of the European Commission's Standard Contractual Clauses and, where the recipient is certified, the EU–US Data Privacy Framework.

United Arab Emirates. Telegram is operated from the UAE, for which no adequacy decision exists. Where the Controller connects Telegram, the patient's name, telephone number and message text are transmitted there. Transfers rely on Standard Contractual Clauses to the extent the provider accepts them; the Controller is advised to consider whether this channel is appropriate for its patients, and may use email notifications alone instead.

Supplementary measures applied to all transfers: transport encryption, minimisation of the content sent, and — for stored message text — encryption at rest with a key held outside the database.

The Processor provides the Controller with the means to answer a data subject's request directly and without waiting for the Processor. From the dashboard, the Controller can search for a patient by telephone number or name, download a complete copy of everything held about them in a machine-readable format, and erase it permanently, including the message history.

Where a patient contacts the Processor instead of the Controller, the Processor does not act on the request itself. It forwards the request to the Controller, as the controller of that data, and informs the patient that it has done so.

Where the Controller nonetheless needs assistance, the Processor provides it without undue delay and at no charge for requests of ordinary scope.

The Processor notifies the Controller without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting the Controller's data.

The notification states, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a point of contact. Information that is not available at the time is provided in phases as it is established.

Notification to a supervisory authority or to data subjects under Articles 33 and 34 is the Controller's decision and responsibility as controller; the Processor supplies the information needed to make it.

Processing health data by automated means at scale is likely to require a data protection impact assessment under Article 35. The Processor maintains its own assessment of the service and makes it available to the Controller on request, together with the record of processing activities it keeps under Article 30, so that the Controller does not have to reconstruct the technical description itself.

The Controller sets the retention periods in the dashboard. In the absence of a choice, conversations and their messages are deleted 90 days after the last message, and appointment requests 365 days after they were created. Deletion is performed automatically by a scheduled task and is irreversible.

On termination of the account, the Processor deletes the Controller's data, including conversations, messages, requests and clinic configuration, without undue delay. Where the Controller wants a copy first, it may export it from the dashboard before terminating, or request one from the Processor before deletion.

Backups are retained for no longer than is necessary for continuity and are subject to the same deletion.

On reasonable request, and no more than once a year unless a breach or a supervisory authority requires otherwise, the Processor makes available the information necessary to demonstrate compliance with this DPA: the record of processing activities, the description of security measures, the sub-processor list, and the impact assessment.

Where that is not sufficient for the Controller's own obligations, the parties will agree a proportionate audit, conducted with reasonable notice, during business hours, and without access to other controllers' data.

This DPA prevails over the Terms of Service on the subject of personal data. Where the European Commission's Standard Contractual Clauses apply to a transfer, those clauses prevail over this DPA to the extent of any conflict.

Liability is as set out in the Terms of Service, save that nothing in this DPA limits a data subject's rights or either party's liability under the GDPR.

This DPA is governed by the law of the Processor's place of establishment, without prejudice to the mandatory application of the GDPR and of the Controller's own national data protection law.

This text is published in English. Where a translation is provided for convenience, the English text governs.

A Controller that requires a countersigned copy should request one. The Processor will return an executed copy naming the Controller, the date, and the registered details of both parties.

PENDING REGISTRATION. The Processor currently operates as Vladyslav Kutsyn. A registration number and registered address will be inserted here, and in clause 1, once the legal entity is registered; until then this document should be treated as the Processor's binding statement of its obligations rather than as a counter-signable contract.