Data processing agreement

Of the one part, the professional or the practice that owns the account —“the Controller”—. Of the other, Raúl Ríos Beiro (VinculAI), with address at Avenida Hermanos Machado 135, 46025 Valencia, España and contact at privacidad@vinculai.com —“the Processor”—.

The Controller determines the purposes and the means of the processing of its patients’ data —“the Patient Data”—. The Processor processes them solely on the Controller’s behalf and pursues no purpose of its own over them.

The processing of the Controller’s account data and that of its users falls outside this agreement; in respect of those, the Processor acts as controller under its privacy policy.

The Processor will never use the Patient Data for its own purposes —product statistics, commercial improvement, marketing or model training—. Doing so would make it a controller under article 28.10 GDPR and article 33.2 of Spanish Organic Act 3/2018 (LOPDGDD).

The Processor declares that it provides the sufficient guarantees required by article 28.1 GDPR to implement appropriate technical and organisational measures, and sets them out in Annex III.

The processing engagement is ancillary and instrumental to the service agreement. Its full description —subject matter, nature, purposes, categories of data subjects and types of data— is in Annex II.

The engagement lasts as long as the service agreement, plus the hand-back period under section 12.

This agreement is entered into in writing in electronic form, a form admitted by article 28.9 GDPR. The Processor keeps a record of the version accepted, the date and the user who accepted it, and provides it to the Controller on request.

The Processor processes the Patient Data only on documented instructions from the Controller, including with regard to international transfers. The following, and nothing else, count as such instructions:

1. this agreement and its annexes;
2. the terms and conditions and the published functional documentation, which describe what the platform does;
3. the features the Controller switches on or off from its dashboard —Google Calendar synchronisation, payment gateways, video consultation, artificial intelligence features, voice transcription, public website and analytics—, which are logged with date and user;
4. any further instructions the Controller sends in writing to privacidad@vinculai.com from an account with an owner or administrator role.

If a further instruction goes beyond the scope of the service contracted, the Processor will say so within ten working days, stating the terms and the timescale; until the Controller accepts them there is no obligation to carry it out.

If Union or Spanish law required the Processor to carry out processing that has not been instructed, it will notify the Controller before doing so, unless that law prohibits such notification on important grounds of public interest. Requests from authorities or from courts concerning Patient Data will be communicated without delay and, where legally possible, before they are complied with.

In accordance with the final paragraph of article 28.3, the Processor will immediately inform the Controller if, in its opinion, an instruction infringes data protection law, and may suspend that particular instruction until the matter is clarified.

Artificial intelligence. The artificial intelligence features are processing carried out on the Controller’s behalf and run only when the Controller switches them on, over the data it or its professionals send with each request. The Processor guarantees that those data are not used to train models, that the outputs are drafts subject to review by the professional —who keeps the authorship of and the responsibility for the clinical record—, that there is no automated decision-making within the meaning of article 22 GDPR, and that the audio of a dictation is never persisted at any point.

The Processor will not process the Patient Data for purposes other than those in Annex II. In particular, and because this is a clinical record within the meaning of article 16.1 of Spanish Act 41/2002 on patient autonomy, using its content for product statistics, service improvement, profiling, marketing or model training is expressly prohibited.

Every person with access to Patient Data has, before being given that access, signed an express confidentiality undertaking of indefinite duration which survives the end of their relationship with the Processor. Article 5 of Spanish Organic Act 3/2018 (LOPDGDD) requires as much, framing that duty as complementary to professional secrecy.

Access is granted on a least-privilege basis, is logged and is revoked without delay once it is no longer necessary. On request, the Processor will provide the Controller with the list of internal roles that hold technical access.

The real extent of technical access, put plainly. Clinical notes, messages and file names are encrypted with AES-256-GCM before being stored, so the database provider cannot read them. But the encryption key is held by the Processor alongside the application, so its administration staff do have the technical ability to access the content. The Processor undertakes that such access will take place only (i) at the Controller’s specific written request in order to resolve an incident, leaving a record of it, or (ii) under a legal requirement. Never routinely, and never for its own purposes.

The Processor’s staff are not healthcare staff, perform no act of care, and neither produce nor validate clinical content.

The Processor applies the technical and organisational measures in Annex III, appropriate to the risk involved in processing data concerning health.

It may update them provided that the resulting level of security is no lower. Any material change will be notified to the Controller thirty days in advance.

The Controller gives general written authorisation for the Processor to engage the sub-processors listed in Annex IV, which is kept published and up to date on this same page.

The Processor will give notice, by email and in the dashboard, of the addition or replacement of any sub-processor thirty (30) calendar days in advance, stating its identity, the service, the location of the processing and the basis for any international transfers.

The Controller may object, on reasoned data protection grounds, within the following fifteen (15) days. While the objection is pending, the Processor will not engage that sub-processor for the data of the objecting Controller. If no alternative is reached, the Controller may terminate the affected part of the service without penalty, with a refund of the unused proportion.

The Processor imposes on each sub-processor, by written contract, the same data protection obligations as it assumes under this agreement, and remains fully liable to the Controller for their performance (article 28.4 GDPR).

On request and at no cost, the Processor will provide information about its contracts with its sub-processors —it may redact confidential commercial information— and about any further sub-processors that process Patient Data.

In the event of the Processor’s dissolution, cessation of business or insolvency, the Controller may approach the sub-processors directly to require them to erase or return the Patient Data.

The Processor does not deal itself with patients’ requests. If it receives one, it will pass it to the Controller within seventy-two hours at the latest, will tell the data subject to contact the Controller, and will disclose no data on its own initiative.

Within the service and at no extra cost, the Processor makes available to the Controller the features needed to deal with the rights of access and portability —viewing and exporting the complete record in a structured format—, rectification, erasure and restriction.

For anything those features do not cover, the Processor will provide reasonable assistance within a timescale that allows the Controller to respond within the month allowed by article 12.3 GDPR, and in any event within ten working days.

Access to the clinical record is also governed by article 18 of Act 41/2002. The Processor confines itself to technical support and does not assess whether a request is well founded or whether the statutory exceptions apply —the professional’s subjective annotations, third-party rights, deceased patients—, which are exclusively for the Controller.

Breaches. The Processor will notify the Controller of any breach of the security of the Patient Data within twenty-four (24) hours of becoming aware of it, by email and with a notice in the dashboard. The deadline is deliberately short: the Controller only has seventy-two hours in which to notify the Spanish Data Protection Agency (AEPD).

The notification will include, at least:

• the nature of the breach and, where possible, the categories and approximate number of data subjects and of records concerned;
• a contact point for further information;
• the likely consequences;
• the measures taken or proposed to address it and mitigate its effects.

Whatever is not available will be supplied in phases and without undue delay. The Processor will not itself notify the AEPD or the data subjects, unless the Controller instructs it to do so in writing.

The Processor assists the Controller in ensuring compliance with articles 35 and 36 GDPR by providing free of charge the technical information it needs for its impact assessment and, where applicable, for prior consultation: a description of the data flows, the sub-processors, the locations, the security measures and a sheet on the artificial intelligence features.

The Controller should know this: it is very likely to have to carry out an impact assessment, because several of the criteria on the list the AEPD publishes under article 35.4 usually apply —special category data, use of new technologies, vulnerable subjects—. That assessment is the Controller’s own and it must document it; the Processor supplies the technical material but neither signs it nor stands in its place.

The Processor maintains the record of processing activities under article 30.2 GDPR and makes it available to the Controller and to the supervisory authority on request.

The Processor makes available to the Controller all information necessary to demonstrate compliance with article 28: the up-to-date Annex III, the article 30.2 record, the list of sub-processors and any security review reports it holds.

The Controller may audit, itself or through an independent auditor it appoints who is not a competitor of the Processor and who is bound by confidentiality, on thirty days’ notice, during working hours and without interrupting the service, no more than once a year. That limit does not apply where there has been a security breach, where a supervisory authority requires it, or where a non-compliance is on record; in those cases the notice period is reduced to five days.

The audit may include the inspection of the Processor’s premises. As regards those of its sub-processors, the Processor will arrange access in accordance with its contracts with them and, if that is not possible, will provide their certifications and audit reports.

The Controller bears the costs, unless a material non-compliance by the Processor is found, in which case the Processor bears them together with a remediation plan with milestones and deadlines.

The Processor will cooperate with the Spanish Data Protection Agency (AEPD) and make available to it whatever information and audit results it requires.

The parties acknowledge that the Patient Data include data concerning health (article 9.1 GDPR). It is exclusively for the Controller to determine and document which of the circumstances in article 9.2 lifts the prohibition —usually letter h), read together with article 9.3— and to demonstrate that it meets the qualification and professional registration requirements applicable to it.

The Processor and its staff are bound by the duty of confidentiality under article 5 of Spanish Organic Act 3/2018 (LOPDGDD) and by the duty of secrecy that article 16.6 of Act 41/2002 imposes on anyone who accesses clinical record data in the course of their duties, indefinitely and without prejudice to the professional secrecy binding the Controller’s healthcare staff.

The clinical record and the care documentation are created, signed and kept under the responsibility of the Controller’s healthcare professional.

Patient-facing surfaces. The booking widget, the patient portal, the emails and the video consultation room display the Controller’s identity visibly, so that the patient can see that the Processor acts on the Controller’s behalf and not in its own name. The Processor makes available to the Controller a patient privacy notice which the Controller may adopt as its own, without that shifting to the Processor the duty to inform, which is the Controller’s.

Minors. The Controller warrants that it has obtained the consent or the legal representation required when it processes data of minors.

Several practices. Where a professional belongs to more than one practice, each one is a separate controller and their data are not shared between them. Switching the active practice does not enable cross access.

Once the agreement ends for any reason, the Controller will choose in writing between:

1. the return of all the Patient Data;
2. their delivery to the new processor it appoints;
3. their erasure.

Once the chosen option has been carried out, the Processor deletes the Patient Data and the existing copies, including those held by its sub-processors, save as provided in section 13.

For the thirty (30) calendar days following the end of the agreement, the Controller keeps the ability to export all the information itself. If that period passes with no instruction, the Processor will ask the Controller in writing and allow a further fifteen days; failing a reply, it will proceed to erasure, having first sent a complete export.

The return or delivery will be free of charge, in a structured, commonly used and machine-readable format, and will cover: the patient record, the appointment diary and appointment history, session notes, background history, free-form notes, signed documents, invoices and receipts, and messages.

Who keeps the clinical record: the Controller. The obligation to keep it —for at least five years from the discharge of each episode of care, under article 17.1 of Act 41/2002, plus any longer periods laid down by the rules of the relevant autonomous region— falls exclusively on the Controller in its capacity as a healthcare facility or healthcare professional, and not on the Processor. Accordingly: the Processor will not keep the Patient Data on its own account once the chosen option has been carried out, nor may it invoke Act 41/2002 in order to retain them; and the Controller undertakes to exercise option a) or b) before instructing erasure, or to declare that it already holds a complete copy allowing it to meet its statutory retention periods.

Once erasure has been carried out, the Processor will issue a written certificate stating the date, the scope, the systems and sub-processors concerned and how the backups were handled; these are overwritten in line with their rotation cycle and, in the meantime, remain encrypted and inaccessible.

Until the Patient Data have been returned, delivered or erased, this agreement continues to apply in full.

Once the data have been handed back, the Processor may keep blocked —under articles 32 and 33.4 of Spanish Organic Act 3/2018 (LOPDGDD), and for the limitation period of the liabilities arising from the relationship— only the service billing records and the access and audit logs needed to demonstrate compliance.

Blocked data are available exclusively to judges and courts, the Public Prosecution Service and the competent authorities. The Processor will not keep blocked the content of the clinical notes or the care documentation.

Each party is liable in accordance with article 82 GDPR. No agreement between them can be relied on against the patient, nor does it affect the penalties under article 83, which fall personally on whoever infringes.

The Processor may amend this agreement on thirty days’ notice; if the change is to the Controller’s detriment, the Controller may terminate without penalty before it takes effect. Each version is published with its number and its date.

This agreement is governed by Spanish law.

Controller: the professional or the practice that owns the account, whose identifying details appear in its account profile and on the invoices issued. Contact: the email address of the owner user.

Processor: Raúl Ríos Beiro (VinculAI), Avenida Hermanos Machado 135, 46025 Valencia, España. Contact for data protection matters: privacidad@vinculai.com. No data protection officer has been appointed for the time being.

Signature: electronic acceptance when the service is taken out, with a record of version, date and user (article 28.9 GDPR).

Subject matter

Provision to the Controller of the VinculAI software service for running its practice, which involves processing on its behalf the data of its patients and of those who request an appointment on its public surfaces.

Nature of the processing

Collection, recording, structuring, alteration, storage, retrieval, consultation, disclosure by transmission to the recipients the Controller instructs, restriction, erasure and destruction, backup and restore, by automated means on the infrastructure of the Processor and of its sub-processors. There is no profiling with legal effects, no disclosure to third parties other than those in Annex IV, and no model training.

Purposes

1. Running the diary and the appointments, including booking from public surfaces.
2. Sending reminders and notices to the patient by email, notification and messaging.
3. Maintaining the patient file and the documentary support of the clinical record: session notes, background history, free-form notes and signable documents, under the authorship and control of the professional.
4. Structuring and formatting notes with artificial intelligence, subject to human review.
5. Video consultation in a private room, with no recording.
6. Handling payments and issuing invoices and receipts to the patient.
7. Communicating with the patient through messaging and the portal.
8. Optional synchronisation of appointments with the professional’s calendar.
9. Technical support, fixing incidents and backups.

Categories of data subjects

• The Controller’s patients, current and past, including minors.
• People who request an appointment or information without becoming patients.
• Legal representatives, guardians and contact persons.
• Third parties mentioned incidentally in the clinical notes —family members, partners, people close to the patient—. In psychotherapy this is unavoidable and it is better to acknowledge it.

Types of data

• Identifying: first name and surnames, DNI or NIE (Spanish national identity or foreigner’s number), date of birth, telephone, email, address, profile photograph.
• Of the care relationship: appointments, attendance and non-attendance, service, treating professional, in-person or online format.
• Special category data, health data (article 9.1 GDPR): session notes, background history, reason for the consultation, progress, the content of messages with the professional and signed clinical documents. They may incidentally include data on sex life or sexual orientation, beliefs or ethnic origin when the patient recounts them in therapy.
• Financial and tax: amounts, payment method, transaction identifier and the tax details of the recipient of the invoice.
• Technical metadata: session identifiers, access timestamps, IP address.

Additional safeguards for sensitive data

Strict purpose limitation; access to session notes restricted to the treating professional by a control in the database itself; isolation between practices; encryption in transit and at application level; exclusion of health data from the technical logs; a ban on their use for model training; no recording whatsoever of the video consultation; and staff bound by express and indefinite confidentiality.

Duration

For as long as the service agreement is in force, plus the hand-back period under section 12, without prejudice to the blocking under section 13.

Described specifically, as the rules require, and not in generic formulas. They reflect the state of the service as at the date of this version.

• Encryption in transit: TLS on every surface —website, API and MCP server—, with enforced redirection.
• Encryption at rest: volume encryption by the database provider and, in addition, application-level encryption with AES-256-GCM over session notes, background history, the body of messages, file names and signed documents. The key is held by the Processor, so the database provider cannot read that content.
• Isolation between practices: row-level security in PostgreSQL, with mandatory filtering by practice on every table containing Patient Data. The policies are checked by automated tests on every deployment.
• Clinical notes: accessible only to the treating professional, by means of a database function and not an application filter.
• Access control: passwords of at least eight characters with upper case, lower case and numbers, validated on the client and on the server; sign-in with Google; sessions that expire; and owner, administration, reception and staff roles, combined with whether the person is a professional.
• Files: stored in private containers, with opaque paths and short-lived signed URLs —ten minutes for what is displayed on screen, two minutes for what is downloaded—.
• Technical logs: they contain no health data and no direct patient identifiers.
• Video consultation: a private room per appointment, access by ephemeral credential and no recording: there is no recording feature and nowhere to store a recording.
• External calendar: the optional synchronisation writes only the patient’s initials and the time, with no description and no guests.
• Public surface: a content security policy, headers against content-type sniffing and control over referrer information; rate limits against automated abuse.
• External assistants: client registration on the MCP server only accepts expressly authorised origins.
• Backups: the database —which holds the patient record, the diary, the encrypted notes and background history, the invoicing and the signed documents— is backed up automatically and daily by the database provider, with the copies hosted in the European Union (Paris). Point-in-time recovery is not switched on, so the restore point is the last daily backup and the maximum data loss in a disaster would be up to twenty-four hours.
• The limit of the backups, said expressly: the database backups do not include attached files —documents uploaded to the patient record, chat attachments and photographs—, which are kept in the object storage service and of which the database keeps only the reference. Those files have the redundancy inherent in that service, but they cannot be restored to an earlier date. For that reason the Processor makes available to the Controller the complete export under section 15 —which does include those files— and recommends carrying it out regularly and keeping it under its own control, in compliance with its obligation to keep the clinical documentation.
• Application servers: they do not store personal data persistently —the containers mount no data volumes— and are rebuilt in full from the deployment image, so they need no backup of their own.
• Development lifecycle: separate environments; the development and test environments contain no real patient data; type checking, static analysis and a suite of automated tests before every deployment, plus end-to-end tests against the deployed service.
• Regular evaluation: a documented review of these measures at least once a year and whenever a new processing operation is added, in accordance with article 32.1.d) GDPR.

The list over which the general authorisation in section 7 is given. It is the same one that appears in the privacy policy: both are published from a single source so that they cannot diverge.

Providers with no access to Patient Data

• Europe PMC (EMBL-EBI, United Kingdom). Scientific literature search. Only abstract clinical terms are sent, never patient identifiers. The United Kingdom benefits from a European Commission adequacy decision, renewed on 19 December 2025. It is not a sub-processor and is declared for transparency only.

If the Controller connects an external assistant through the MCP server, that decision is its own and the assistant’s provider is not a sub-processor of the Processor: it processes the data under the relationship the Controller has itself established with it.