Data processing agreement

1. Who is who

Controller: the shop using VIBBLIN. It decides why and how its visitors' data is processed.

Processor: Numen di Rasman Francesco, which processes that data only to run the service, and only on the controller's instructions.

For the shop owner's account data — shop name, email, password, business details, access records, sign-up and subscription — the controller is instead Numen di Rasman Francesco: that processing is described in the privacy notice and falls outside this agreement.

Paddle, which sells the subscription, processes the shop owner's purchase data as an independent controller. It is not a sub-processor under this agreement and receives no visitor data.

2. Subject matter, nature and purpose

Subject matter: the processing of the personal data that the shop's visitors leave in the chat and in forms, as needed to provide the service described in the Terms.

Nature: collection, recording, organisation, storage, consultation, disclosure to the main language-model provider and, only when that one does not respond, to the backup provider, for generating the replies and for translations, disclosure of the replies to the backup provider for checking them automatically before they are sent, together, in shops with custom instructions, with the visitor's message they answer, erasure.

Purpose: answering visitors' requests, letting the shop read the conversations again and be contacted back, sending the shop the notifications it enabled, producing the statistics the dashboard shows.

No other use. In particular: none of the shop's data is used to train models, for advertising profiling, or for Numen di Rasman Francesco's own purposes.

3. Types of data and categories of data subjects

Data subjects: visitors of the shop's site who open the chat or fill in a form, and people the shop names in the content it uploads.

The conversation is a free-text field: it may also contain data the visitor chooses to write, including the data covered by section 4.

4. Special categories of data and professional activities

4.1 The service is not designed to collect special categories of data (Art. 9 GDPR: health, ethnic origin, beliefs, genetic and biometric data, sex life) nor criminal-records data (Art. 10). The controller does not set up forms, fields or instructions that ask for them.

4.2 A chat, however, remains a free-text field. Visitors may, on their own initiative, write data about their health or other special category data, and this happens especially with healthcare businesses (medical and dental practices, physiotherapy, pharmacies, psychologists) and with legal and financial ones. That data becomes part of the conversation and we process it like the rest: on behalf of the controller, only for the purposes in section 2, with the measures in section 7.

4.3 It is the controller who decides:

• on which legal basis, and under which of the conditions of Art. 9 §2, the processing is lawful;
• what to tell visitors, in its privacy notice and, if it wishes, in the chat's welcome message (for example, not to write health data that the request does not need);
• how long to keep it, including by deleting a conversation before it expires;
• whether an impact assessment (Art. 35) is needed, in which we assist it (section 11).

4.4 Automatic masking (section 7) recognises emails, phone numbers, IBANs, card numbers, tax codes, VAT numbers, postal addresses and IP addresses, in every message sent to the language-model providers, including the one the visitor has just written; order numbers are not masked. It does not recognise health data, which reaches the language-model providers as it was written. The controller takes this into account in its decisions.

4.5 If the controller is bound by professional secrecy, it is for the controller to assess whether and how to use the chat with its clients; we are in any case bound by the confidentiality in section 6.

5. Documented instructions

Numen di Rasman Francesco processes the data only on documented instructions from the controller. The instructions are: the Terms, this agreement, and the configuration the shop owner sets in the dashboard (which forms, which fields, which notifications, which notice to show).

If an instruction would breach the GDPR, we say so and do not carry it out.

If a law obliges us to process data otherwise, we inform the controller first, unless that same law forbids it.

6. Confidentiality

Anyone processing this data on our behalf is bound to confidentiality by contract or by law, and accesses only what their task requires.

Access to a shop's data from the administration console is read-only, expires after thirty minutes and leaves a record in the log: who entered, when, and on which shop.

7. Security measures (Art. 32)

These are the measures that actually exist, not a list of good intentions. If a measure is not there, this document does not name it.

• Encrypted transport: TLS between browser and server; the application talks to the database over a local network.
• Passwords: stored as scrypt hashes; a password change invalidates every open session.
• Access: progressive lockout of failed attempts, tied to the account+address pair, so that a stranger cannot lock a shop owner out; rate limits on all public endpoints.
• Separation between shops: every read and every write is bound to the shop that asks for it, checked on each request; form attachments download only through an authenticated route.
• Pseudonymisation towards the model providers: recognised emails, phone numbers, IBANs, card numbers, tax codes, VAT numbers, postal addresses and IP addresses are replaced with placeholders, encrypted with a dedicated key, before being sent to the language-model providers, in every message: the one the visitor has just written, the earlier messages of the conversation, and the reply and the message sent to the check of the replies. Order numbers stay in clear. The real data stay on the processor's servers: there the reply gets them back before it reaches the visitor, and there contacts, requests and estimates are put together from the original text.
• Checking the replies: every reply from the model goes through an automatic check before it reaches the visitor.
• IP addresses: kept only as a keyed fingerprint, never in the clear in the shop's data.
• Content written by the shop owner: sanitised against an allow-list of tags before it is stored and shown.
• Backups: every day a copy of the database, kept on the server for 14 days, and every week a copy of the whole server, kept by the hosting provider separately from the server. Restoring from a copy has actually been tested.
• Continuity: an external service raises the alarm if the system stops showing signs of life; errors are recorded and shown on a status page.
• Automatic erasure: conversations and contacts past the plan's period are deleted every night.

8. Sub-processors

The controller gives general authorisation to the sub-processors listed here. If we change or add one, we write to the account email address with thirty days' notice and update the /subprocessors page, which always carries the list in force: within that period the controller may object and, if the objection is well founded and we find no alternative, may withdraw without penalty.

Each sub-processor is bound by obligations no less strict than those of this agreement. We answer for their acts as for our own.

Telegram comes into play only if the controller switches on Telegram notifications: switching them on is an instruction from the controller, and with it the controller authorises that processing and the transfer it entails. OpenAI, the backup language-model provider, generates the replies only when the main provider does not respond; it always performs the automatic check of the replies before they are sent (section 7) and, in shops with custom instructions, also receives with each reply the visitor's message it answers.

The main language-model provider is Anthropic Ireland, Limited, which under Anthropic's commercial terms is the counterparty for those established in the European Economic Area. The data are processed in the United States, under the European Union's standard contractual clauses (modules 2 and 3) of its data processing agreement. Anthropic undertakes not to train its models on the data we send it and deletes questions and replies within thirty days, except when it must keep them longer to enforce its usage policy or to comply with the law. The backup provider, OpenAI, states that data sent to its API is not used to train or improve its models, absent an explicit opt-in that we have not given; its abuse-monitoring logs are kept for up to thirty days. Sources and dates of verification are shown in the table.

9. Data subject rights

Data subject requests are received by the controller. If they reach us, we forward them to the controller without answering on the merits.

We give the controller the tools to answer on its own: full export of the data in a readable format, portable export, deletion of a single conversation or contact, deletion of data older than a period, anonymisation of the statistics. These are dashboard items, not requests to open with us.

Where the tools are not enough, we assist the controller within a reasonable time and at no extra cost.

10. Personal data breaches

If we become aware of a breach affecting the controller's data, we notify it without undue delay and in any case within 48 hours of becoming aware, at the account's contact email address.

The notice says: what happened, which categories of data and how many data subjects are involved, the likely consequences and the measures taken. It is the controller who decides whether to notify the authority and the data subjects; we give it everything it needs to do so.

11. Assistance to the controller

Taking into account the nature of the processing and the information available to us, we assist the controller with: security of processing (Art. 32), breach notification (Art. 33 and 34), impact assessment and prior consultation (Art. 35 and 36).

12. What happens at the end

12.1 While the contract lasts, the controller can export the data or delete the account whenever it wants. Both are on the same page: Dashboard → Privacy & GDPR.

12.2 If the controller deletes the account, the deletion is immediate and final: the data is gone at once, there is no bin and no grace period. Whoever needs a copy must export it first.

12.3 If the contract ends in another way — cancellation, trial not continued, non-payment, closure for a breach — the widget stops and for 30 days the dashboard stays accessible read-only, for export. In the case of non-payment those days run from the suspension. 7 days before the end of that period we write to the controller; at the end we automatically delete all the data processed on its behalf.

12.4 Backups already taken (the daily ones of the database, kept for 14 days, and the weekly ones of the whole server, kept by the hosting provider) keep the data for no more than thirty days, then expire on their own; they are not restored except after an incident, and in that case the erasure is applied again right after the restore.

12.5 After deletion we keep no visitor data. What remains (the email fingerprint and the fingerprints of the domains of the trial sites) concerns the shop owner, not the visitors, and is described in the privacy notice.

13. Audits

On written request, and no more than once a year save after an incident, we make available to the controller the information needed to demonstrate compliance with this agreement, and allow an audit agreed with thirty days' notice.

The audit may not compromise the confidentiality of other shops' data nor the security of the service.

The cost of the audit is borne by the controller, unless the audit reveals a breach of this agreement: in that case we bear it.

14. Duration

This agreement applies from the first day of the trial, or from acceptance if we created the account, for as long as Numen di Rasman Francesco processes personal data on the controller's behalf: that is, until the deletion described in section 12.

Every version carries a number and a date. A new version requires a new acceptance at the next sign-in.