Sub-processors

1. The short answer

LW IT Solutions Company Lukas Wójcik, Łódź, Poland (the "Operator") runs reactive.chat (the "Service") on its own server in its premises in Łódź. The language models run on the Operator's own machines in the same local network; no third-party AI service is involved. This page forms part of the Data Processing Agreement ("DPA", clause 8) and of the Technical and Organisational Measures. "Customer", "Visitor" and "Customer Data" have the meaning given in the DPA.

Two providers process Customer Data on the Operator's behalf and are sub-processors within the meaning of Article 28(4) GDPR:

• Google Cloud Storage holds the daily off-site copy of the server, encrypted before transfer, in Warsaw (section 2.1).
• Namecheap provides DNS and e-mail for the Operator; e-mails sent by the Service can contain Visitor data (section 2.2).

One further provider will become a sub-processor only if a function that is currently not switched on is enabled (section 2.3).

Section 3 lists providers that the Operator uses for its own purposes as controller (payments, form protection); they do not receive Customer Data under the DPA. Section 4 explains which recipients and parts of the infrastructure are not sub-processors and why. Section 5 lists the channels and integrations that the Customer can switch on with its own accounts.

Correction made with this version. Up to version 1.1 this page said that the list was complete and that no hyperscaler was used. That was not correct: the server-wide backup has been transferred to Google since 20 August 2026 – until 4 September 2026 to Google Drive, since 5 September 2026 to Google Cloud Storage – and contains the Service's data. Version 2.0 lists it.

2. Sub-processors

2.1 Off-site backup copy – Google Cloud Storage

• Entity: Google Cloud EMEA Limited, 70 Sir John Rogerson's Quay, Dublin 2, Ireland.
• Purpose: storage of the daily off-site copy of the server, so that the Service can be restored after a loss of the server.
• Data: a complete copy of all databases on the server and of the web directories, including all Customer Data (conversations, Visitor data, account data, file attachments, knowledge-base files). The copy is encrypted on the Operator's server before transfer (rclone crypt), including file and directory names; the keys remain on the Operator's server. Google holds blocks without readable content. Encryption is a technical measure; it does not change Google's role as sub-processor.
• Place of processing: bucket in region europe-central2 (Warsaw, Poland, EU).
• Retention: daily copies 7 days, weekly copies (Sunday) 364 days; from day 10 in a colder storage class.
• Contract and transfer safeguard: Google Cloud Data Processing Addendum. The data is stored in the EU; where Google accesses it from outside the EEA, for example for support or maintenance, the standard contractual clauses of the European Commission contained in that addendum apply.
• In use since: 5 September 2026 (listed on this page since 11 October 2026). From 20 August to 4 September 2026 the same encrypted copy was transferred to Google Drive; the automatic expiry described above does not cover these copies.

2.2 DNS and e-mail – Namecheap

• Entity: Namecheap, Inc., 4600 East Washington Street, Suite 305, Phoenix, AZ 85034, USA.
• Purpose: (a) authoritative DNS for reactive.chat; (b) forwarding of e-mail addressed to @reactive.chat addresses; (c) the Operator's mailbox contact@lukaswojcik.com (Namecheap Private Email), to which requests, objections and deletion requests are sent; (d) delivery of e-mails sent by the Service.
• Data: for (b) and (c) the sender, recipient and content of e-mails that reach the Operator, which may include Visitor data that a Customer or Visitor sends to the Operator. For (d) the recipient's e-mail address and name and the content of the e-mail: for users of the Customer's account confirmations, password resets, invitations and notifications about conversations; for Visitors the transcript of a conversation that the Visitor requests by e-mail, and replies in the e-mail channel where the Customer has not entered its own outgoing mail server. In that case the reply is sent from no-reply@reactive.chat in the name "[project] via reactive.chat" with the Customer's address as reply address, and the provider receives the Visitor's e-mail address and name, the subject, the text of the reply and the message references of the thread. This category of Visitor data arises only where a Customer uses the e-mail channel without its own mail server.
• Provider for (d): e-mails of the Service are sent through the Operator's e-mail service. Namecheap is the provider intended for it and the one in use for the Operator's mailbox. If another provider is chosen for outgoing e-mail, it will be announced under section 6 before it is used.
• Place of processing: USA.
• Transfer safeguard: standard contractual clauses of the European Commission, as part of Namecheap's data processing addendum.
• Listed since: 2 September 2026.

2.3 Only if switched on: click-to-call – Twilio

• Entity: Twilio Ireland Limited, Dublin, Ireland; Twilio Inc., San Francisco, USA.
• Purpose: the "call me" function, in which the Service calls an agent and connects the agent with a Visitor by telephone through the Operator's own Twilio account.
• Data: telephone numbers of the Visitor and of the agent, time and duration of the call.
• Status: this function is not switched on; the Operator's Twilio account is not set up. Before it is used for the first time, the Operator will announce it under section 6. Text messages (SMS) that the Customer sends through its own Twilio account are not covered here but in section 5.

3. Providers used for the Operator's own purposes

The following providers process personal data for purposes that the Operator determines itself, as controller. They do not process Customer Data on the Customer's behalf and are therefore not sub-processors under the DPA. They are listed here for transparency; details are in the Privacy Policy.

3.1 Payments and invoices – Stripe

• Entity: Stripe Payments Europe, Ltd., 1 Grand Canal Street Lower, Dublin 2, Ireland; onward transfer to Stripe, Inc., South San Francisco, USA.
• Purpose: payment of subscriptions, invoices, tax calculation and verification of VAT identification numbers.
• Data: e-mail address, name or company name, billing address, VAT identification number, the Operator's internal account and workspace identifiers and the chosen plan. Payment card and account data is entered on Stripe's pages and never reaches the Operator. Stripe receives no Visitor data from the Operator's payment process.
• Role: Stripe acts partly as processor for the Operator and partly as an independent controller (for example for fraud prevention and its own legal obligations).
• Place of processing: Ireland (EU) and USA.
• Transfer safeguard: EU-US Data Privacy Framework and standard contractual clauses of the European Commission.
• Listed since: 2 September 2026.

3.2 Protection of the account and support forms – Google reCAPTCHA

• Entity: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland; Google LLC, Mountain View, USA.
• Purpose: protection of the sign-in, registration, password-reset and support forms against automated abuse (reCAPTCHA v3).
• Data: the script runs in the browser of the person using the form and collects browser signals; the server sends the resulting token together with that person's IP address to Google for verification. reCAPTCHA is not used in the chat widget and never concerns Visitors of Customer websites.
• Place of processing: EU and USA.
• Transfer safeguard: EU-US Data Privacy Framework and standard contractual clauses of the European Commission.
• Listed since: 2 September 2026.

4. Recipients and infrastructure that are not sub-processors

4.1 Server, AI nodes and network

• Server. The Service runs on a server owned by the Operator in its premises in Łódź, Poland. No hosting provider or data centre operator is involved.
• AI nodes. The language models run on machines owned by the Operator in the same local network. Only nodes entered in the Operator's register receive AI jobs. No third-party AI service, also not as a fallback, receives Customer Data.
• Internet connectivity. Toya Sp. z o.o., Łódź, Poland, provides the internet connection. It is a mere conduit: it transports encrypted connections and has no access to stored data. It is therefore not a sub-processor.
• cdn.reactive.chat. The widget script is delivered from a web host on the same server. No external content delivery network is used.
• Geolocation. The country of a Visitor is derived from a local database file (MaxMind GeoLite2) on the server and stored with the session. No IP address is sent to any provider. Since 16 October 2026 the real-time server also uses this database for the live functions that depend on the country (visitor list, campaigns, consent requirement for the GDPR area): it derives only the country code from the Visitor's IP address, without storing the address for this purpose, and ignores country information sent by the browser; where no country can be derived, the Visitor is treated as being in the GDPR area.

4.2 Push notifications to agents

• If an agent subscribes to push notifications in the browser, the Service sends them through the push service of that browser's manufacturer: Google (Firebase Cloud Messaging), Mozilla, Apple or Microsoft.
• The content is encrypted end to end for the agent's browser (RFC 8291); the push service cannot read it. It consists only of the kind of event (new conversation, new message, handover, call-back request), the project name, identifiers of the project and the conversation and a link into the desk, never the text of a message. The push service sees the subscription address, the time, size, urgency and lifetime of the message, the identifier of the conversation (used to replace an older notification of the same conversation) and the server's IP address.
• The push service is determined by the agent's browser, not chosen by the Operator, and processes no content on the Operator's behalf. It is therefore listed here as a recipient of these metadata, not as a sub-processor. Push notifications are optional and can be switched off by each agent.

4.3 Notifications to the Operator – Telegram

• Entity: Telegram FZ-LLC, Dubai, United Arab Emirates.
• The Operator receives notifications through a Telegram bot: that a new support request or new customer feedback has arrived, and operating alerts (state of components, reachability of AI nodes, load, error counts).
• The notifications contain fixed texts and operating figures only: no names, e-mail addresses, IP addresses or message content. Telegram sees the server's IP address. As no personal data of Customers or Visitors is transferred, Telegram is not a sub-processor.

4.4 TLS certificates – Let's Encrypt

• Entity: Internet Security Research Group (ISRG), San Francisco, USA.
• Let's Encrypt issues the TLS certificates of the Service and, where a Customer uses its own domain for the chat, the certificate for that domain. It receives only domain names, which are recorded in public certificate transparency logs. No Visitor data is transferred.

4.5 Calls

• Video and voice calls connect the Visitor's and the agent's browsers directly with each other. No relay server of a third party is used, and no public STUN server either, because such a server would see the IP address of every Visitor. If the Operator sets up a relay server (TURN) of its own, it forwards the encrypted stream without being able to read it; it is part of the Operator's own infrastructure. Without a relay server each side's IP address becomes known to the other side.
• Co-browsing and screen sharing run over the Service's own real-time connection and the direct browser connection respectively; no third party is involved. Co-browsing shows the agent the labels of buttons, links and headings of the page, not form fields or input.

4.6 MousePlayer and Answely

• MousePlayer (session replay) is operated by the same legal entity, LW IT Solutions Company Lukas Wójcik, and is therefore not a separate processor. It is a separate service with separate terms that the Customer activates itself.
• Answely, which answers Smart Answer requests, is likewise operated by the same legal entity on the same server and is therefore not a separate processor.

5. Channels and integrations switched on by the Customer

The Service lets the Customer connect channels and integrations. Each of them is switched on by an owner or admin of the Customer, with the Customer's own account and credentials at the respective provider, and exchanges data only on the Customer's instruction. The providers are the Customer's own recipients or processors, not sub-processors of the Operator. The Customer is responsible for a data-processing agreement with each provider and for the lawfulness of any transfer to a third country. Each channel or integration can be switched off in the dashboard at any time. Integrations send data only for the events the Customer selects (new conversation, new message, request for a human, rating, and for some integrations error reports).

Why these providers are not sub-processors. A sub-processor is engaged by the Operator to process Customer Data on the Operator's behalf. For the services in this section, the Customer chooses the provider, holds the contract and the account with it (its own Meta account, Telegram bot, Twilio account, mailbox, Google account, Cal.com and Stripe accounts, identity provider or AI tool), switches the connection on and decides which data flows; the Service carries out the exchange on the Customer's instruction (DPA clause 3). The Operator has no contract of its own with these providers for the Customer's data. That the Operator's OAuth application is used to connect Google Drive does not change this: Google provides the Drive to the Customer under the Customer's contract, and the Service reads from it on the Customer's instruction. Where, by contrast, the Service itself sends data through a provider chosen by the Operator – e-mail delivery when the Customer has no mail server of its own –, that provider is a sub-processor (section 2.2).

• Messaging channels: WhatsApp Business, Facebook Messenger and Instagram Direct, including WhatsApp campaigns, directly with Meta Platforms Ireland Limited, Dublin (Meta Graph API), with the Customer's own Meta account and without an intermediary – telephone number or profile identifier, name, message texts, attachments, message templates; Telegram through the Customer's own bot – chat identifier, first and last name or user name, messages, photos and documents; messages in groups and from other bots are discarded; Telegram FZ-LLC is located in the United Arab Emirates, a third country without an adequacy decision, so the Customer must assess that transfer; SMS through the Customer's own Twilio account – telephone number and text (the content of MMS is not retrieved); e-mail through the Customer's own IMAP and SMTP servers – addresses, names, subjects, messages (only the inbox is read).
• Team notifications: Slack (thread per conversation, replies from Slack), Microsoft Teams, Discord, Telegram, e-mail – message excerpts of up to 400 characters, Visitor name, agent name.
• Event delivery: webhooks to an address chosen by the Customer (signed), Zapier, Make, n8n – the event data of the selected events.
• Tickets and issues: Zendesk, Freshdesk, Jira, Linear – Visitor name and e-mail address, conversation transcript, agent, link back; GitHub – error reports from Visitors' browsers (message, file, browser, pages, stack trace).
• Context cards in the desk: HubSpot, Pipedrive, Shopify, Shopware, WooCommerce, WordPress, Stripe (the Customer's own account) – the Visitor's e-mail address is sent as a search key; the result is shown to the agent.
• Analytics and error context: Google Analytics 4, Plausible, Matomo, Sentry – page address, for Sentry a session reference.
• Knowledge sources (incoming): Notion, Confluence, Google Drive – the Customer's credentials go to the respective provider, content flows into the knowledge base. Google Drive is connected through an OAuth application registered by the Operator with read-only access (scope drive.readonly), which Google grants for the whole Drive of the signed-in account; the Service reads only the folders and files the Customer selects; the Customer signs in with its own Google account and grants access. The Service stores the access token encrypted and the e-mail address of the Google account, reads the selection about every six hours and keeps the extracted text, not the files.
• Appointments and bot actions: Cal.com (the Customer's account) – for free slots the event type and the period; for a booking the time, the event type and the Visitor's name, time zone and e-mail address (only an address signed by the Customer's website); Stripe (the Customer's account) – the confirmed user identifier of the Visitor as search key, never the e-mail address; the Customer's own HTTP endpoints – only the parameters defined in the action's schema and, where the Visitor's identity is confirmed, the user identifier.
• Sign-in of agents: single sign-on through the Customer's identity provider (for example Microsoft Entra ID, Google Workspace, Okta, Keycloak) – the e-mail address entered is sent as a sign-in hint; the provider returns an identity token with the agent's e-mail address, identifier and, where configured, groups; the Service stores only the issuer and the identifier.
• AI tools of the Customer (MCP): an AI tool or client that the Customer connects to the MCP server with its key – the conversation data, Visitor data and knowledge-base results it requests; without the additional permission for Visitor data in shortened and scrubbed form, never the Visitor's IP address. The Service sends nothing on its own initiative; what the tool passes on to its own AI provider is the Customer's responsibility.
• Migration (incoming): import from Intercom, Crisp and Tidio with the Customer's key, which goes to the former provider (Intercom and Tidio also from an export file), and from Zendesk only from an export file the Customer uploads – the conversations flow into the Service.
• Shop data: the Customer's own shop interface for order data of signed-in end customers – a signed customer identifier.
• Own AI node: a node operated by the Customer – AI requests with conversation content; the Customer decides which model the node uses, including models of third parties (for example Azure OpenAI).

6. Change procedure

1. The Operator announces any intended addition or replacement of a sub-processor in section 2 on this page and by e-mail to the e-mail address of the owner of every Customer account, at least 30 days before the change takes effect.
2. During those 30 days the Customer may object on reasonable data-protection grounds by e-mail to contact@lukaswojcik.com.
3. If the parties cannot find a solution, the Customer may terminate the contract for the Service with effect from the date the change takes effect, as set out in clause 8 of the DPA.
4. The removal of a sub-processor, and changes in sections 3 to 5 that do not concern Customer Data, are recorded on this page without a notice period.

7. Status and version

Questions about this list: contact@lukaswojcik.com. Further information: Privacy Policy, Imprint; our records of processing activities on request.

This document is drawn up in English. Translations into German (/de/p/unterauftragsverarbeiter) and Polish (/pl/p/podwykonawcy-przetwarzania) are provided for convenience; the English version prevails.

Version 2.0 replaces version 1.1 of 2 September 2026. Changed: Google Cloud Storage added as sub-processor for the encrypted backup copy; the statements "the list is complete" and "no hyperscaler is used" withdrawn; Namecheap described with DNS, e-mail forwarding, mailbox and the status of outgoing delivery, including Visitor data in e-mails; Stripe and reCAPTCHA reclassified as providers for the Operator's own purposes, reCAPTCHA with transfer to the USA; Twilio click-to-call listed as conditional; push services, Telegram (also operating alerts), Let's Encrypt, direct calls, network operator and local geolocation explained; WhatsApp, Messenger and Instagram run directly with Meta, not through Twilio; list of integrations completed.

Version 2.1 replaces version 2.0 of 11 October 2026. Changed: Namecheap with the Visitor data of replies sent without the Customer's own mail server (2.2); content of push notifications (4.2); no public STUN server, own relay server, co-browsing and screen sharing (4.5); reasons why the services of section 5 are not sub-processors; Telegram, SMS and e-mail in detail, Cal.com, Stripe and custom endpoints for bot actions, Google Drive, single sign-on and AI tools connected through MCP (5).

Version 2.2 replaces version 2.1 of 11 October 2026. Corrected: the backup has been transferred to Google since 20 August 2026, until 4 September to Google Drive (1, 2.1); content and metadata of push notifications (4.2); Answely (4.6); scope of the Google Drive access and sources of migration (5).

Version 2.3 replaces version 2.2 of 12 October 2026. Corrected: the live functions that depend on the country derive it from the IP address with the local database (4.1).

Version 2.4 replaces version 2.3 of 16 October 2026. Changed: the records of processing activities are available on request instead of being linked (end of the document). The list of sub-processors is unchanged.

Version 2.4 – effective 19 October 2026.