Privacy Policy

This privacy policy explains how LW IT Solutions Company Lukas Wójcik ("we", "us", the "operator") processes personal data in connection with reactive.chat. It has three parts, because we act in different roles:

• Part A (section 2): you visit the reactive.chat website. We are the controller.
• Part B (section 3): you are a Customer of reactive.chat or a member of a Customer's team and use the dashboard. We are the controller for your account data.
• Part C (section 4): you use the reactive.chat chat widget, Smart Answer in the search, a messaging channel, a call or the customer portal of one of our Customers. The Customer is the controller; we process your data on the Customer's behalf as processor.

Sections 5 to 12 apply to all three parts. Where this policy states a period, it is the period our systems actually enforce; where no system deletes something after a period, we say so.

Two further documents describe the same processing from the controller's side: our records of processing activities (Art. 30 GDPR) and our data protection impact assessment (Art. 35 GDPR). They are not published; we make them available to the supervisory authority and, on request, to Customers (contact@lukaswojcik.com).

1. Controller and contact

• LW IT Solutions Company Lukas Wójcik
• al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland
• VAT ID: PL7252266190
• E-mail: contact@lukaswojcik.com

For all questions about data protection, write to contact@lukaswojcik.com. Requests are handled by the owner personally. We have not designated a data protection officer.

1.1 Where the service runs

reactive.chat runs on a server owned and operated by us in our premises in Łódź, Poland. Our own AI runs self-hosted on separate machines of our own (our "inference nodes"), which stand in the same local network as that server. The address cdn.reactive.chat, from which the widget is loaded, is not an external content delivery network but a website on the same server. The server is connected to the internet by a network operator (Toya Sp. z o.o., Łódź), which transports encrypted data and has no access to its content.

The service runs in a production installation (reactive.chat) that is separate from its development installation (dev.reactive.chat): it has its own program directory, its own database with its own database user, its own Redis database and its own service processes. Changes to the code reach the production installation only through a deliberate transfer of a fixed version, after a backup of its program files and database. Both installations run on the same server and use the same AI nodes; the development installation is protected by a password. The same server also carries other projects of the operator; they are separated by directories, databases and database indexes on that machine, not by separate hardware.

Copies of the data leave this server in exactly one regular case: the encrypted backup described in section 7.1. All other recipients are listed in section 5.

2. Part A – Visitors of the reactive.chat website

2.1 Server access log and operating logs

When you open a page on reactive.chat, our web server records the request: date and time, the requested address, the HTTP status, the referring page, the browser type and version (user agent) and your full IP address. The same applies to requests to cdn.reactive.chat and to the real-time connection of the chat. We use the access log to operate the site securely, to detect attacks and errors and to keep the service stable. An automated blocking tool reads the logs and blocks addresses that attack the server for one to two hours.

• Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is the secure and stable operation of the website.
• Retention: log files are rotated daily; the current day's file and the 14 previous days are kept, older files are deleted (at most 15 days in total).
• In addition, the operating log of the server (system journal), which also receives messages of the chat server, can contain IP addresses. It is limited by size (500 MB), not by time: the oldest entries are removed when the limit is reached, so the period depends on the volume of messages. Error and work logs of individual components of reactive.chat are currently not rotated automatically; some of them can contain IP addresses.
• Recipients: none, apart from the encrypted backup (7.1).

2.2 Theme choice (localStorage)

If you switch between the light and dark theme, your choice is stored in your browser under the key rc_theme in localStorage. It is used only to display the site in the theme you chose and not for tracking. Storing this value is strictly necessary to provide a function you have explicitly requested (Art. 5(3) ePrivacy Directive, Polish Electronic Communications Law), so no consent is required. You can delete it at any time in your browser settings.

If you close a notice bar on the site, the key rc_leiste_zu: followed by the name of that notice is stored with the value 1 in localStorage, so that the notice is not shown again. It contains no identifier, has no expiry and is strictly necessary for the function you used; no consent is required. You can delete it at any time in your browser settings.

2.3 Language choice

The language of the site is part of the address (URL path). Nothing is stored in your browser for this purpose.

2.4 Support form

If you send us a message through the support form, we process the details you enter (such as your name, e-mail address and the text of your message), the page and language you wrote from and your full IP address, to answer your request.

• The form is protected by Google reCAPTCHA v3 (see 2.7). The script is loaded only when you open the support dialog.
• The form is rate-limited (at most 20 attempts in ten minutes and 10 messages per hour per IP address). Your IP address is stored with the request to detect and stop bulk or repeated submissions.
• When a request arrives, an internal notification is sent to us via Telegram. It consists of a fixed text and contains no personal data (see section 5.3).
• To answer you, we can have your message translated and a draft reply prepared. Both are done by a language model on our own inference nodes (1.1); no third-party AI service is used. The model receives the text of your message, the reason you selected, whether you have an account and the path of the page you wrote from; e-mail addresses, telephone numbers and digit sequences of six or more digits are replaced beforehand. Your IP address and your e-mail address do not reach it. A draft is never sent automatically: a person reads it, corrects it where needed and decides whether to send it. Our own reply can likewise be translated into your language before it is sent. The text prepared for the model and the result are stored with your request and deleted with it.
• Legal basis: Art. 6(1)(b) GDPR if your request relates to a contract or to entering into one; otherwise Art. 6(1)(f) GDPR, our legitimate interest in answering enquiries. reCAPTCHA, rate limiting and the stored IP address: Art. 6(1)(f) GDPR, protection against automated abuse.
• Retention: a request sent while signed in, or from an address confirmed for an account, is deleted when that account is deleted (3.7). A request sent without being signed in is deleted, including the IP address and the texts prepared for the language model, at the latest 365 days after it arrived or after we last worked on it; you can ask us at any time to delete it earlier.

2.5 E-mail contact

If you e-mail us at contact@lukaswojcik.com, we process your e-mail address and the content of your message to answer you. That mailbox is hosted by Namecheap (section 5). Legal basis as in 2.4. We keep e-mails as long as they are needed to handle your request and any follow-up questions and to document what was agreed; there is no automatic deletion.

2.6 No tracking

Apart from the items listed in this Part, the reactive.chat website stores nothing in your browser and loads no scripts, fonts or images from other providers. We do not use web analytics, advertising or tracking pixels. Links to other websites (for example consented.eu or mouseplayer.com) are ordinary links; nothing is transmitted to those websites until you follow them.

2.7 reCAPTCHA

On the login, registration, password-reset and support forms we use Google reCAPTCHA v3 to distinguish people from automated scripts. reCAPTCHA is never used inside the chat widget.

• When you start filling in the login, registration or password-reset form (first click or tab into the form) or open the support dialog, your browser loads the reCAPTCHA script from Google (www.google.com, www.gstatic.com). The script evaluates information about your device and your behaviour on the page; Google may set or read its own cookies for this. When you submit the form, our server sends the result token together with your IP address to Google for verification.
• Provider: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland. A transfer to Google LLC in the USA cannot be excluded (section 6).
• Legal basis: Art. 6(1)(f) GDPR, our legitimate interest in protecting accounts and the support form against automated attacks. Without this protection the sign-in and the support form would be open to automated attack.

2.8 Security cookie (rc_csrf)

When you open a page of the reactive.chat website, our server sets a cookie named rc_csrf in your browser if it is not there yet. This happens on every page, also if you are not signed in and do not fill in a form, because the support dialog can be opened from every page and a form only works if the cookie already exists when the page is loaded. The cookie contains a random value of 64 hexadecimal characters that our server generates and that contains no information about you. From this value – and, once you are signed in, from your session – the server calculates a token that is placed in each form of the website and the dashboard (for example sign-in, registration, password reset and support) and checked when you submit it. Another website cannot calculate this token and therefore cannot submit a form in your name (protection against cross-site request forgery, CSRF).

• The value is not stored on our server, not written to any log and not linked to your IP address, your account or other data; it is not used to recognise you or for tracking. Your browser sends it back with its requests to the website.
• Properties: HttpOnly (scripts cannot read it), Secure (sent only over encrypted connections), SameSite=Lax (not sent with requests that other websites trigger in the background). It applies only to the address of the website itself; cdn.reactive.chat does not set it, and the chat widget on Customers' websites does not use it (4.3).
• Purpose: protection of the forms of the website and the dashboard against forged requests.
• Legal basis: storing the cookie is strictly necessary to provide the forms of the website securely (Art. 5(3) ePrivacy Directive, Polish Electronic Communications Law; in Germany § 25(2) no. 2 TDDDG), so no consent is required. Where the value is personal data, Art. 6(1)(f) GDPR; our legitimate interest is protecting accounts and forms against forged requests.
• Retention: a session cookie without an expiry date; your browser deletes it when you close it (browsers that restore the previous session may keep it). You can delete it at any time in your browser settings; the next page you open sets a new value.

3. Part B – Customers and team members

reactive.chat is offered to businesses only. This Part applies to the person who registers a Customer account and to every team member (roles owner, admin, member – the agent role – and viewer) who is invited into a workspace. We are the controller for the account data described here. For the content you process with reactive.chat (conversations, knowledge base, data of visitors and of your end customers) you are the controller and we are your processor – see Part C and the data processing agreement.

3.1 Registration and account

• Data: display name, e-mail address, password (stored only as a hash), language; later, if you enter them, first and last name, company, address and VAT number; the workspaces you belong to and your role; an avatar address if you set one; if you enter one for click-to-call, your telephone number per workspace.
• Acceptance of the contract documents: registration requires ticking a box by which you accept the Terms of Service and conclude the data processing agreement. We store, for each document, the fingerprint (hash) and the full text of the version shown, the time, your full IP address and the user agent. Registration also requires ticking a second box by which you declare that you are registering for a business or as a trader and not as a consumer; we store this declaration in the same way: its wording (with the notice for sole traders shown beneath it) and fingerprint, the time, your full IP address and the user agent. These records prove which wording was accepted and declared. If you did not register your account yourself (for example through single sign-on) or we do not hold your acceptance of the current version, we ask for the same two tick boxes before you create a workspace of your own, take over a workspace or order a paid plan, and store the record in the same way, together with the occasion. They are deleted together with your account.
• E-mail confirmation: we send you a confirmation link (valid for 60 minutes). Confirming is not a prerequisite for signing in or using the service.
• Registration, login and password reset are protected by reCAPTCHA (2.7) and rate-limited per IP address.
• Purpose: creating and operating your account, securing it and tracing administrative actions within the workspace.
• Legal basis: Art. 6(1)(b) GDPR (performance of the contract); for the acceptance record, login history, audit log and abuse protection Art. 6(1)(f) GDPR, our legitimate interest in being able to prove the contract, in the security of the service and in the traceability of administrative actions.

3.2 Team members

The owner or an admin of a workspace invites team members by e-mail. We process the invited person's e-mail address and role to send the invitation (valid for 7 days) and, after acceptance, to operate the account. A workspace can also be offered for transfer to another member (offer valid for 7 days). Team members can ask the workspace owner or us to correct or delete their data – see Access and deletion.

3.3 Billing

Paid plans are billed through Stripe (section 5). When you start a paid plan we transmit to Stripe your e-mail address, your name or company name, your address where it is complete, and internal identifiers of your account and workspace as reference; in the checkout Stripe collects the billing address, an optional VAT number and the payment method itself. Card data is processed only by Stripe; we never receive card numbers.

• We store the Stripe customer and subscription identifiers, plan, billing cycle and status, invoices with number, amounts, VAT number and country, and the notifications Stripe sends us about payments (which usually contain e-mail, name and billing address).
• Legal basis: Art. 6(1)(b) GDPR (contract) and Art. 6(1)(c) GDPR (accounting and tax obligations).
• Retention: Polish tax law requires us to keep invoices for five years from the end of the calendar year in which the tax obligation arose. Invoice records and payment notifications are currently not deleted automatically after that period, and they remain when an account or workspace is deleted. A free plan without billing data exists.

3.4 E-mail

We send e-mails about registration, e-mail confirmation, password reset, invitations and notifications (for example about unanswered conversations) through our e-mail service. The same service is used for e-mails to visitors that a Customer's chat triggers – a copy of the conversation that a visitor requests, and replies in the e-mail channel where the Customer has not entered a mail server of its own (4.6). The provider currently used is named in the sub-processors list; see section 5. If e-mail sending is not available, outgoing messages are kept as files on our server and deleted after 30 days. Legal basis: Art. 6(1)(b) GDPR; for visitor e-mails, the Customer's instruction (Part C).

3.5 Support, feedback and status

Support requests from Customers are handled as described in 2.4 and 2.5. The feedback button in the dashboard stores your text, the page and the user agent with your account; we receive a notification via Telegram without its content (5.3). The public status page shows only measurements of our own systems.

3.6 Channels and integrations you connect

You may connect channels (e-mail via your own IMAP/SMTP server, WhatsApp, Facebook Messenger, Instagram, Telegram, SMS) and integrations (for example Slack, Microsoft Teams, Discord, HubSpot, Pipedrive, Zendesk, Freshdesk, Jira, Linear, GitHub, Shopify, Shopware, WooCommerce, WordPress, Stripe, Google Analytics 4, Plausible, Matomo, Sentry, Notion, Confluence, Google Drive, Cal.com, Zapier, Make, n8n, webhooks) and import data from Intercom, Crisp, Tidio, Zendesk or Answely. You use your own accounts and credentials for this; we store the credentials encrypted and use them only to operate the connection on your instruction. The providers of these services are your own recipients or processors, not our sub-processors. You are responsible for the lawfulness of the data exchange with them. The Google Drive connection uses an OAuth application registered by us; Google therefore sees that you authorise that application, while the documents are read from your Drive on your instruction. What reaches those providers is described in 4.6.

3.7 Retention of account data, end of contract and deletion

• Account data is kept as long as the account exists. Ending a paid subscription does not end the account: the workspace falls back to the free plan, and nothing is deleted automatically.
• Deleting an account: you can delete your account in the settings. Access ends at once; the account is deleted 30 days later, and you can cancel the deletion until then. The deletion includes sessions, tokens, memberships, acceptance records, push subscriptions, feedback, SSO links, the audit log entries without a workspace and support requests linked to the account. A line recording that an account was deleted, without a name, remains.
• Deleting a workspace: the owner can delete a workspace; it is deleted after 30 days and can be restored until then. As long as a paid subscription is running, the workspace is not deleted: the request is refused, and on the deletion date the workspace is skipped until the subscription has been cancelled; please cancel it first under Billing. A project can be archived by the Customer; deleting a project is done by us on request.
• What remains after a deletion: invoices and payment notifications (3.3); support requests that are not linked to an account, until their period ends (2.4); entries "workspace deleted" and "account deleted" without content; for 400 days, the entry in the deletion journal that records which deletion was carried out (7.1); and, until they expire, the copies in backups (7.1) and logs (2.1).
• Your own data download: in the settings ("My account data") you can download, as a JSON file, your account, memberships and workspaces, invitations and transfers, feedback, support requests, acceptance records, sessions and logins, invoices, SSO links, push subscriptions, your call settings and calls, your evaluations and pseudonym, the content you created (messages, versions, test questions, knowledge-base entries), activity and read-log entries.

3.8 Read log (Agency plan)

In workspaces on the Agency plan – with an active subscription, including a trial period, or under an individual contract – the Service records which team member opened which conversation and when. The owner and the admins of the workspace see this read log for the projects they have access to; members and viewers do not.

• Data: the team member's account, the conversation, the time and the route – the dashboard, the live console on the Customer's website, or the detail view of a conversation in the AI log. No IP address, no device, no duration and no content. If the same person opens the same conversation by the same route again within ten minutes, no further entry is made. Not recorded individually: the preview lines of the conversation list, search results in the dashboard, the list view of the AI log, access through the API with an API key, and access by us. Exports of a whole project are recorded in the audit log (3.11) and are shown next to the read log.
• Only with the plan: without the Agency plan no entry is made, and a workspace that books the plan sees no entries from the time before.
• Roles and legal basis: the read log documents how the Customer's team handles the Customer's conversations. The Customer is the controller for it and determines the legal basis, for example its legitimate interest in being able to trace access to conversations (Art. 6(1)(f) GDPR) or a provision of national law on employee data (Art. 88 GDPR); we process the entries on the Customer's behalf under the data processing agreement. The Customer informs its team members. Where a works council or another employee representation exists, its rights may have to be observed before the read log is used; that too is the Customer's responsibility.
• Retention: each entry is deleted after at most 731 days, and earlier together with the conversation, the project or the workspace. If a team member's account is deleted, the entries remain without a reference to that account. Team members find the entries about themselves in their own data download (Access and deletion).

3.9 Sign-in, sessions, two-factor authentication and SSO

• Sessions: when you sign in, we store a session with its time, your full IP address and the user agent and, once you have confirmed a second factor in it, the time of that confirmation, so that you can see your devices and sign out everywhere. Since 17 October 2026 the database holds only a SHA-256 hash of the session identifier; the cookie carries the random value. A session ends after 14 days without use; with "stay signed in", after 60 days. Expired sessions and tokens are deleted by a daily run at the latest one day after their expiry.
• Last login: your account stores the time and the full IP address of your last successful login and the number of failed attempts. After five failed attempts the account is locked for 15 minutes.
• Cookies in the dashboard: the dashboard uses cookies that are strictly necessary for signing in and for protection against cross-site request forgery (HttpOnly, SameSite=Lax, Secure over HTTPS). They contain random values, no personal details. The security cookie rc_csrf is already set on the website (2.8). No consent is required for them (Art. 5(3) ePrivacy Directive, exception for strictly necessary storage).
• Browser storage in the dashboard: the dashboard keeps preferences in localStorage – theme (rc_theme), sound and notification wishes, collapsed panels, your agent id and project key in the live console (rcd_ keys) and, only if you enter one by hand, an access token for the live console (rcd_token) – and in sessionStorage the open tab and unsaved drafts of the editor. These values serve only the dashboard functions you use.
• Two-factor authentication (TOTP) is voluntary. If you switch it on, we store the shared secret of your authenticator app encrypted (AES-256-GCM, with a key kept in our server configuration and bound to your account), the recovery codes in hashed form, and the last time step used, to prevent a code from being used twice.
• Single sign-on (OIDC, Agency plan and individual contracts): the owner of a workspace can connect the workspace's own identity provider (for example Microsoft Entra ID, Google Workspace, Okta, Keycloak); that provider is a service of the Customer. When you sign in through it, we pass the e-mail address you entered to it as a sign-in hint and receive from it your e-mail address, a stable identifier of your account there, whether the address is verified, how you authenticated (for example with a second factor) and, where the Customer maps groups to roles (Okta), your groups; your name and language only when your account is created through SSO. We store only the link between your account and the provider's identifier, with the times of the first and the last sign-in; the identity token, the groups and the authentication details are not stored. A team member who signs in through SSO for the first time is created as an account with the member role automatically, unless the owner has switched this off. Each SSO sign-in is recorded in the workspace's audit log with your full IP address; it is not shown to the Customer (3.11). Sign-in data of an SSO process in progress is deleted after one hour.
• Legal basis: Art. 6(1)(b) and (f) GDPR (security of the account).

3.10 Web push notifications

Team members can allow their browser to show notifications about new conversations, new messages, handovers and call-back requests. If you do, we store the subscription your browser gives us (an address at the push service of your browser's maker and two keys), at most 10 per account. A notification contains only the kind of event, the name of the project, the identifiers of the project and conversation with a link to open it, and the time – not the text of messages. Its content is encrypted end-to-end so that only your browser can read it; the push service (Google, Mozilla, Apple or Microsoft, depending on the browser) nevertheless learns the subscription address, the time and the size of each message and our server's IP address (section 5). A subscription is deleted when you switch notifications off, when it has not been seen for 60 days, when it no longer belongs to a valid session, or after ten failed deliveries. Legal basis: Art. 6(1)(b) GDPR, at your request.

3.11 Audit log, AutoQA and other evaluations of team work

• Audit log: we record security-relevant actions with the account, the workspace, the object and the full IP address – logins (including sign-ins through SSO), failed logins, password resets, invitations, role changes, changes of settings, keys and integrations, exports, deletions, each call of a tool through our MCP server (without content), and the actions we take in our administration area. The owner and the admins of a workspace see the changes made in it, from a fixed list of actions and without IP addresses; sign-ins of team members are not shown to them, except failed SSO sign-ins. The Customer chooses how long the workspace's entries are kept: 90, 180, 365 or 730 days, or – the default – until the workspace is deleted; the period applies to all entries of the workspace, including sign-ins. If a team member's account is deleted, the workspace's entries about that person's actions remain, with the account identifier and the IP address. Entries without a workspace are deleted after 90 days if they concern sign-ins and sign-outs, the second factor, passwords, SSO or failed attempts, and in the case of entries that belong to no account – such as failed logins with an unknown e-mail address and IP blocks – all of them; other entries of an account (for example registration, confirmation or change of the e-mail address) remain until the account is deleted. Entries recording that an account or a workspace was deleted, and the actions we take in our administration area, are kept without a time limit.
• AutoQA (optional, paid plans): the Customer can have finished conversations evaluated automatically by fixed signals and word lists. The result can include an evaluation per agent; it is calculated only from these rules, is visible only to the owner and the admins and can be switched off for the whole workspace, in which case the agent is not even stored with the rating. If the Customer also switches on the AI judgement, our language model rates only conversations in which no agent took part (conversations handled by the assistant alone); it receives their course (visitor and assistant, at most 6,000 characters) after PII scrubbing and with the names known from the conversation replaced. An AI judgement is never attributed to an agent; if an agent joins later, it is discarded. Evaluations are kept without a separate period and are deleted with the conversation; on anonymisation the AI's reason and the agent reference are emptied. Because the evaluation per agent assesses the work of employees, the Customer is responsible for the legal basis (for example Art. 88 GDPR and national employee data law), for informing the team and for any participation rights of an employee representation; see also AI Act information. We process these data on the Customer's behalf.
• Pseudonyms: the owner can set that reports, AutoQA and the read log show agents as stable pseudonyms ("Agent A", "Agent B") instead of names, or show no evaluation per agent at all; each person still sees their own name. The assignment of the pseudonyms is stored per workspace and can be reversed by the owner. It does not apply to the desk, the audit log, the messages of a conversation or the workspace export.
• Statistics, service targets and reports show the Customer's team figures per conversation and agent; they are calculated from the conversations and follow their retention.

4. Part C – Visitors of Customers' websites (chat widget and related functions)

4.1 Roles

The Customer embeds the reactive.chat widget on its website and decides whether, how and for what purpose it is used. The Customer is therefore the controller for your data (Art. 4(7) GDPR). We process the data on the Customer's behalf as processor under a data processing agreement pursuant to Art. 28 GDPR. Information about the specific purposes and legal bases must be provided by the Customer in its own privacy policy. Please address requests concerning your data to the Customer. If you contact us directly, we forward your request to the Customer and assist – see Access and deletion.

The same applies to Smart Answer (4.14), to messaging channels (4.6), to calls and call-back requests (4.17), to campaigns (4.16) and to the customer portal (4.18).

4.2 Data processed in the widget

The widget script is loaded from cdn.reactive.chat. When it loads and while you chat, the following data is processed:

• Chat content: your messages, attachments you upload (4.12), time stamps, quick-reply choices, answers to forms in the chat, CSAT ratings and comments, and the details you enter in a pre-chat or offline form (for example name, e-mail address or telephone number).
• Technical session data: a session id and – only with your consent to persistent storage (4.3) – a visitor id (random identifiers); the address and title of the page you are on and the last pages visited in this session; the referrer and campaign parameters (UTM); your browser language; the user agent; the screen or viewport class.
• IP address and country: your IP address is used to establish the connection and to protect the service (4.9). The country is derived from it by a database stored on our own server (MaxMind GeoLite2; no query leaves our server). The conversation record stores the country, not the IP address. The live functions that depend on your country – the live visitor list (4.5), campaigns (4.16) and the consent requirement for the GDPR area (4.10) – also use this database: when you connect, our real-time server derives from your IP address only the country code (no region, city or coordinates), without storing the IP address for this purpose; country information that your browser sends in the request headers is not used. Where no country can be derived, for example for private or unknown addresses, they treat you as a visitor from the GDPR area. Where the IP address is stored elsewhere, this is stated below in this section (consent record) and in 2.1, 4.5, 4.9 and 4.14.
• Page text: so that the AI assistant can take into account the page you are on, the widget transmits the visible text of that page. It is stored per address and text version together with the Customer's project, not with you or your conversation, and serves as part of the Customer's knowledge base. It has no deletion period of its own and is deleted with the project, or earlier where the Customer excludes the path. Where the Customer has the chat ask for consent first (4.10), this text and the page context are sent only after you have agreed.
• Optional traits: if the Customer passes them, your name, e-mail address, a user id and custom fields. The Customer decides whether this happens.
• Optional identification: the Customer may pass a user id together with an HMAC hash so that the widget can show a logged-in visitor's history across devices. The Customer can also sign your e-mail address together with the user id and an expiry time; only an e-mail address signed in this way is passed on as known to the AI assistant and used to book appointments (4.4). A Customer's agent can also link a conversation to a person in the Customer's own records; the link and who confirmed it are stored.
• Visitor proof: when the widget starts, our server issues a random token that is stored in your browser together with the visitor or session id. Only who holds it can continue, list or delete the conversations of that identifier. On the server it is kept for 400 days after its last use.
• Consent record: if the Customer has the chat ask you for your consent, we record each grant and each withdrawal – the wording that was shown to you, the address of the privacy policy linked with it, the language, the time, your full IP address and the user agent, and the session, visitor and conversation identifiers. Art. 7(1) GDPR requires the controller to be able to demonstrate that consent was given; see 4.11 for what happens to this record.

4.3 Storage in your browser

The widget sets no cookies – neither its own nor third-party cookies – and contains no advertising or tracking pixels. It uses the web storage of your browser for the website on which it is embedded. Which storage it uses depends on the consent signal of the Customer's consent management platform (an IAB TCF signal for storage on the device, the consented.eu signal, or a value the Customer passes):

• Without consent (also when no signal arrives): everything is kept in sessionStorage, which the browser clears when you close the tab. No visitor id is created, only a session id. One exception: after you have deleted your chat data, the key rc_dnt is written to localStorage – a single "do not track" bit without any identifier, so that the deletion is not undone by the next page view. It has no expiry.
• With consent: the widget moves its entries to localStorage so that your conversation can be continued on a later visit. Each entry carries its own expiry, which is checked when it is read: one day for the current conversation and the open tab, one year for preferences and the pre-chat details. If you withdraw consent, the widget moves its rc_ entries back to sessionStorage and removes them from localStorage; the mp_ entries remain (see below).

Keys used:

• rc_id – only without consent: session id and tab id. sessionStorage, until the tab is closed.
• rc_conv, rc_thr – current conversation and list of conversation threads. One day.
• rc_tab, rc_marke:<site key> – last tab opened in the widget, display marker of the website (colour, name, logo address; no personal reference). One day.
• rc_locale_wahl, rc_thema_wahl – language and theme you chose in the widget. One year.
• rc_prechat – the details you entered in the pre-chat form (for example name and e-mail address), so that you do not have to enter them again. One year.
• rc_ds, rc_dsst – your answer to the chat's own consent question and the consent level of the site. One year.
• rc_erst – time of your first visit; only with consent. One year.
• rc_vtok – visitor or session id and visitor proof (4.2). sessionStorage, or with consent localStorage without expiry; on the server 400 days after last use.
• rc_outbox_* – messages you have written but that could not be sent yet, including their text (at most 50 messages, 128 kB). 24 hours.
• rc_sig – throttle for behaviour signals and script-error reports (4.19): per kind of signal and page path the time of the last report, a counter and hash values of reported errors. Like the other entries; 30 minutes.
• rc_seen, rc_http – technical state of the connection (identifiers of recently received messages, time of the last fallback connection), sessionStorage, until the tab is closed; rc_http is used for 30 minutes. rc_leader – which tab holds the connection; only with consent and only in browsers without Web Locks, in localStorage, removed when that tab ends the connection.
• rc_offen, rc_seiten, rc_draft_* – always sessionStorage: whether the window is open, a page counter and the unsent draft of your message (text). Until the tab is closed. rc_nav, rc_ruht, rc_cb – sessionStorage: the last addresses within a single-page application (at most 50), a quiet period and a call-back form in progress. If you give consent while one of these entries (or rc_seen, rc_http) exists, it is moved to localStorage with the other entries and remains there without expiry until you withdraw consent or delete your chat data.
• rc_dnd – "do not disturb" for proactive messages. Without expiry in localStorage, or until the tab is closed. On our server the same choice is kept for your visitor id for 30 days.
• rc_dnt – see above.
• mp_session_data, mp_visitor_id (localStorage) and mp_tab_id (sessionStorage) – only with consent, whether or not the Customer uses MousePlayer: with consent the widget keeps its session id (used for 30 minutes), its visitor id and its tab id under these names, so that MousePlayer session replay, where the Customer uses it, works with the same identifiers (4.6). mp_visitor_id has no expiry. These entries are not removed when you withdraw consent; they are removed when you delete your chat data. If MousePlayer identifiers already exist in your browser, the widget reads them and uses them as its identifiers, also without consent.

The legal basis for browser storage is Art. 5(3) ePrivacy Directive as implemented by the Polish Electronic Communications Law and the law of the Customer's country: sessionStorage is strictly necessary to run the chat you requested; persistent storage requires your consent, which the Customer obtains. The rc_dnt bit stores your own deletion decision and is strictly necessary to respect it.

4.4 AI assistant

The Customer may enable an AI assistant (default name "Ada") that answers your questions.

• Where it runs: on our own inference nodes in the same local network as our server in Łódź (1.1). Only nodes entered in a register maintained by us receive work; if the register cannot be read, no node receives work. No third-party AI service (such as OpenAI, Anthropic or Google) is used to generate answers, not even as a fallback. Your messages do not leave our infrastructure for this purpose.
• Models: our own AI, self-hosted on our own hardware. One chat model (instruction-tuned, in a version quantised to 4 bits) runs on two nodes and another chat model (Instruct) on a third node, which serves as a reserve; texts are converted into search vectors with our own, likewise self-hosted embedding model. All of them are openly licensed models that we run unchanged on our own hardware. On the free plan, work goes only to the reserve node. On paid plans, it goes to the two other nodes; the reserve node takes it only if neither of them is available or neither has taken it within 3 seconds.
• No training: we do not train or fine-tune any model with your data or with the Customer's data. Individual requests may be used internally to compare model versions before an update; they are not used for training and not shared.
• What the model receives: your message, the course of the conversation (the recent messages and a summary of older ones), passages from the Customer's knowledge base, the situation on the page (name of the website, kind of page, time and language), the text extracted from an attachment (4.12) and, for questions about your orders, the order data released by the Customer (4.13).
• Knowledge base: the assistant answers from a knowledge base the Customer builds: a crawl of the Customer's own website (respecting robots.txt), documents the Customer uploads (PDF, DOCX, text, Markdown, CSV, HTML; kept until the Customer deletes them), product feeds, content from connected sources such as Google Drive, and the page text described in 4.2. For Google Drive, the Customer signs in with its own Google account and grants our OAuth application read-only access to the folders and files it selects; we store the access token encrypted and the e-mail address of the connected Google account, read the selected files about every six hours and keep their text in the knowledge base, not the original files; disconnecting Drive removes its content from the knowledge base. The Customer decides what goes into the knowledge base and is responsible for its content. Where the knowledge base contains nothing suitable, the assistant may answer general questions from the model's general knowledge, or it hands the conversation over to a human.
• Checking: before an answer that relies on sources is shown, our server checks it by fixed rules (for example days of the week, numbers and words such as "free of charge") against those sources; this check uses no further model. An internal AI log records for each answer the sources used, the result of the check, the model and node, and times – no copy of the text. The Customer can view it.
• Actions: on paid plans, if the Customer configures them, the assistant can look up an order status, show free appointment slots and book an appointment through the Customer's Cal.com account, look up a subscription in the Customer's Stripe account (by the confirmed user id, never by e-mail address) or call an interface of the Customer. For a booking, Cal.com receives the time, the event type, your name, your time zone and your e-mail address – only an address the Customer's website has confirmed by its signature (4.2), never one typed into the chat. An interface of the Customer receives only the values its form defines and, only if your identity is confirmed, your user id. An action that changes something is carried out only after you have clicked "Yes" on a confirmation of exactly that action (valid for 10 minutes). The result appears in the conversation as a message; the model receives only the fields the Customer has released. For these actions and for order data, the text given to the model is removed from our records as soon as the answer has been delivered. Cal.com, Stripe and the Customer's interfaces are services of the Customer, not our sub-processors.
• Proactive messages: if the Customer uses them, the model can write a short opening sentence that matches the page you are on; for this it receives the title and up to 1,200 characters of the page text, the bot name and the team's tone, not your messages.
• Routing classification: if the Customer switches it on (paid plans), the model reads your first message once – masked as for the agent tools (4.15) and shortened to 1,500 characters – and suggests topic labels from the Customer's list, an urgency flag and a mood value (positive, neutral, negative, angry). Independently of this, word lists in German, English and Polish estimate the mood of your messages; the less favourable of the two values counts. Labels and mood are used by the Customer's routing rules to assign the conversation to an agent; you are not informed of the assignment. They are kept in the working copy of the conversation (4.11), not as text in the AI log.
• Job applications: the assistant does not accept or assess job applications or CVs. If the chat recognises an application – in your message, in an attached file or in its name –, you receive a fixed answer pointing to the Customer's application channel, the conversation goes to a human, and for the rest of the conversation no language model is used, except to translate messages for the agents.
• Guided flows: if the Customer has built a guided flow, your answers to its questions (for example name, e-mail address or telephone number) are stored as ordinary messages of the conversation and are given to the assistant as context, at most 200 characters per answer.
• Labelling: the widget shows a notice before the first answer of the assistant and labels every answer with "AI", so that you can recognise that you are talking to an AI system (Art. 50 of the EU AI Act, Regulation (EU) 2024/1689). The assistant is instructed to say that it is an AI when asked. The Customer must not remove or obscure that label. The Customer decides on the assistant's name and whether it is used at all, and can disable it at any time; we can also switch it off for a project or as a whole.
• As soon as an agent takes over the conversation, the assistant stops answering.
• The assistant is not a high-risk AI system. It makes no decisions with legal effect on you. Details: AI Act information.
• We select, configure and operate the models. We do not warrant that AI answers are accurate, complete or fit for a purpose.
• Records: the work orders for the model contain the text given to the model, including your message. Orders that belong to a conversation are kept with it and deleted with it; if the Customer has deletion set to anonymisation, their text is emptied (4.11). Orders without a conversation are deleted 30 days after they were placed, once they are finished or rejected.

Several functions deliberately use no language model: recognising abuse and requests for deletion (4.11), the fixed answer to questions about what is stored, the frustration signals (4.19), the set-up suggestions in the dashboard and the rule-based part of AutoQA.

4.5 Human agents

The Customer's agents read and answer conversations in a web dashboard. Access is role-based (owner, admin, member, viewer) and limited to the Customer's own workspace and, where the Customer restricts it, to individual projects. Agents can assign, tag and close conversations, use prepared answers, send quick replies, cards, forms and attachments, ask for a CSAT rating, leave internal notes, transfer conversations, and see a live list of the visitors currently on the website and invite them to chat. Conversations can be routed and assigned automatically by rules and service targets. Proactive messages and product tours are configured by the Customer.

Live visitor list: it is built only from data your session already carries; nothing is collected for it. Without consent it shows only a random identifier, times, whether a conversation is running and that consent is missing. The full line – page without parameters, referring host, campaign parameters, device, browser and operating-system family, country (derived from your IP address, 4.2), language, whether you have visited before – is shown only where the Customer's project does not require consent or you have consented; for visitors from the GDPR area and wherever the country is unknown, only with your consent (4.10). The list never shows your IP address, the raw browser identification, advertising click identifiers or your name and e-mail address. It exists only in our memory store, renewed every 90 seconds at most – in practice every 30 seconds – and expires 90 seconds after the last renewal; you disappear from it 45 seconds after leaving the website and after 30 minutes without activity. An agent can invite you to chat from the list (at most once every 2 minutes per visitor), under the same consent rule. The Customer's systems can read the same list through our API (4.6).

An agent can block a visitor for up to 365 days (24 hours unless set otherwise). The block applies to the visitor id on that website and to the IP address of the connection; where the visitor connects directly to our server, a blocked IP address is blocked for the whole service, not only for that Customer's website. Agents can also use a language model to translate messages and to prepare reply drafts and summaries (4.15).

4.6 Channels, integrations and session replay activated by the Customer

The Customer may connect further channels and integrations. If it does, conversation data is exchanged with those providers on the Customer's instruction. Those providers are recipients or processors of the Customer, not our sub-processors.

• WhatsApp, Facebook Messenger and Instagram run directly through the interfaces of Meta Platforms Ireland Ltd. (Graph API) with the Customer's own Meta account; we process your telephone number or profile id, your display name and the messages. Telegram runs through the Customer's own Telegram bot; we receive your chat id, your first and last name or user name, and the texts, photos and documents you send. Messages in Telegram groups and from other bots are discarded. Telegram is operated from outside the EEA (Telegram FZ-LLC, Dubai). SMS runs through the Customer's own Twilio account; the content of picture messages (MMS) is not retrieved. E-mail runs through the Customer's own mailbox: we collect new e-mails from its inbox (IMAP) and mark them as read, and replies are sent through the Customer's own mail server; if the Customer has entered none, replies are sent through our e-mail service from our sender address in the name "[project] via reactive.chat" with the Customer's address as reply address, and our e-mail provider then processes your e-mail address, your name, the subject and the text (3.4, 5.1). For each e-mail thread we store your address and name, the subject and the message references, and the texts as messages of the conversation, not the original e-mail. Automatic replies, mailing-list messages, bounces, messages from no-reply addresses and messages marked as spam are ignored and not stored; at most 20 e-mails per sender and hour are accepted.
• What we store for channels: the link between your channel identity (telephone number, chat id, e-mail address) and the conversation, and the e-mail threads. There is no separate period; they are deleted with the project, and when all conversations of that channel session are deleted – at your request or under the Customer's retention period. The message numbers of the channels, which we keep to recognise duplicates and which can contain your telephone number, are deleted after 7 days. Files arriving through a channel are kept in an intermediate store for at most 24 hours.
• Ticket and help-desk tools (Zendesk, Freshdesk, Jira, Linear) receive your name, e-mail address and the course of the conversation when an agent creates a ticket. Team chat tools (Slack, Microsoft Teams, Discord, Telegram, e-mail) receive notifications with an extract of up to 400 characters, a name and the agent. CRM, shop and payment tools of the Customer (HubSpot, Pipedrive, Shopify, Shopware, WooCommerce, WordPress, Stripe) receive your e-mail address as a search key to show the agent a context card. Analytics and error tools (Google Analytics 4, Plausible, Matomo, Sentry) receive the page address and, for Sentry, a session reference. Webhook-type integrations (webhooks, Zapier, Make, n8n) receive the events "conversation created", "message created", "handover requested" and "rating submitted". GitHub receives error reports (4.19).
• If the Customer connects an AI server of its own, messages for AI functions go to that server and the model chosen there; that server is the Customer's processor.
• The Customer may also use session replay through MousePlayer, a separate service of the same operator with its own terms. The widget then shares the MousePlayer identifiers (4.3), and only with consent.
• Via our interface (API) and our MCP server, the Customer's systems and the AI tools the Customer chooses can read and write conversations, visitors, events and knowledge-base searches with a key the Customer creates. Through the MCP server, without the additional permission for visitor data, names are reduced to initials, e-mail addresses masked, telephone numbers shortened to their last two digits and texts passed through the PII scrubber (4.7); your IP address is never passed on. Events that the Customer's own systems send to us are returned through the interface as sent (at most 8 KiB each). Data the Customer retrieves in this way is in the Customer's own systems; we do not send it to anyone else.

4.7 PII scrubbing

Before a message from a visitor or an agent is stored, our server automatically replaces patterns that look like e-mail addresses, card numbers (checked with the Luhn algorithm), IBANs (checked with the ISO check digits), telephone numbers, tax identifiers and secrets such as access keys with a placeholder; the redactions are counted and marked in the message. Two exceptions: messages that a Customer's system writes through our API, and answers to forms in the chat, are stored as sent. This is a protective filter, not a guarantee; please do not enter payment data in a chat.

4.8 Content filters

We are not a party to the conversation and do not review messages editorially. We apply only automated filters: PII scrubbing, spam detection and abuse detection (including the detection of attempts to misuse the AI assistant for unrelated tasks), all by fixed rules. Illegal content can be reported to contact@lukaswojcik.com; see also Acceptable use and anti-abuse.

4.9 Abuse protection

The real-time server protects itself and the Customers against hammering, flooding and spam. It counts requests per connection and per IP address and limits the size and number of messages and the use of the AI assistant per website and per address. When limits are exceeded, it can block a connection, a visitor id or an IP address automatically and temporarily (24 hours unless set otherwise); blocks are kept in our server's memory store for their duration. Manual blocks are kept by us and by Customers (4.5). The latest 500 security events of this guard, with IP address, are kept in a rolling list without a time limit; older events are overwritten. Each connection can address only conversations of its own site (tenant isolation by site key). Within the Customer's processing this is a security measure under Art. 32 GDPR; as far as we protect our own service, our legal basis is Art. 6(1)(f) GDPR.

For the "Powered by reactive.chat" notice on the free plan we count displays and clicks; the IP address is used only as a shortened, one-way hashed value for ten minutes to avoid double counting, and the counters are kept for 40 days.

4.10 Legal bases

The Customer determines the legal bases. Typically these are Art. 6(1)(b) GDPR (answering a request you make before or during a contract), Art. 6(1)(f) GDPR (the Customer's legitimate interest in offering a chat and in protecting it against abuse) and your consent for persistent browser storage. The Customer can also set the chat to ask you for your consent before you can write; where the Customer does that, the legal basis for processing your messages is your consent (Art. 6(1)(a) GDPR), the chat shows you the wording you agree to, and no conversation is created and no page text is sent until you have agreed. That consent is a different one from the consent for persistent browser storage in 4.3, which covers only the storage on your device. The Customer's own privacy policy is decisive.

For visitors from the GDPR area – the member states of the EU, the EEA states Iceland, Liechtenstein and Norway, the United Kingdom and Switzerland – and whenever the country cannot be determined, three functions run only with your consent, whatever consent level the Customer has chosen: campaigns in the widget (4.16), the full line about you in the live visitor list, and invitations to chat from that list (4.5). The country is derived from your IP address with the country database described in 4.2 (country code only); country information sent by your browser is not used. Where no country can be derived – for example for private or unknown addresses –, consent is required.

4.11 Retention

No automatic period unless the Customer sets one. Conversations are kept until they are deleted. Our service does not delete them after a fixed period by default: the Customer, as controller, sets per project after how many days of inactivity conversations are deleted (from 0 = no limit up to 3,650 days). That figure can be capped by an upper limit we set and by a limit agreed in an individual contract; the lowest of the figures applies. A daily run removes conversations that have been inactive for longer. Where no figure is set anywhere – which is the default – no period applies and the conversation remains for as long as the Customer's project exists. The end of a paid subscription does not delete anything (3.7).

The following end a conversation:

• The retention period set by the Customer, as described above.
• Your own deletion in the chat window. Where the Customer leaves that button switched on, you can delete the conversation, its history and the identifiers of your visit yourself; where the Customer also asks you for consent, you can withdraw it there, which has the same effect. The deletion is carried out within a few minutes. Practical details: Access and deletion.
• A deletion you ask for in words. If you write in the chat that you want your data deleted – "please forget me", "delete all my data" and similar wordings in German, English or Polish – our server recognises that wording and answers you. The recognition compares your message against a fixed list of phrases; it does not use the AI assistant and therefore also works where the Customer has switched the assistant off. The Customer decides per project whether such a request is recognised at all and whether the chat asks you to confirm before deleting – which is what a project starts with – or deletes straight away. Before deleting, the chat tells you what it can delete here and that everything the Customer holds about you elsewhere has to be requested from the Customer. What is deleted is the same as under the previous point; there is only one deletion path.
• The deletion of the Customer's project or workspace (3.7), with a waiting period of 30 days for a workspace.

There is currently no function in the dashboard with which agents delete individual conversations. If you ask the Customer to delete your conversation, the Customer can use the means above or ask us for help.

The Customer chooses what deletion means: either the conversation is erased, or it is anonymised – the message texts are replaced by a placeholder, translations and form answers are removed, the conversation loses its visitor id and the CSAT comment, the session loses the user agent, the country and the attribution data, and the records of the AI processing of the conversation are emptied. The random session and visitor identifiers themselves remain, so that visitor counts do not change retroactively; after this they stand next to nothing that describes a person, and the conversation remains only as an anonymous entry (time, channel, status, rating) in the Customer's statistics. A question the Customer has adopted into its knowledge base stays there as the Customer's content. Attachments are deleted in both cases (4.12).

A deletion of your chat data also removes the counters kept about you for campaigns (4.16) and, for a WhatsApp conversation, the campaign contact with its deliveries, except a blocking note after an opt-out (4.16). On anonymisation, AutoQA ratings lose the AI's reason and the agent reference (3.11).

Our real-time server also keeps a working copy of each active conversation in its memory store: the latest messages (at most 200), the conversation header with any name, e-mail address or telephone number you have given, and the pages visited; it expires 30 days after the last activity and is cleared together with the conversation. The page context of a session expires after 30 minutes without activity.

The consent record described in 4.2 has no automatic deletion period. When you delete your chat data (in the window or in words), or when the conversations it belongs to are deleted under the Customer's retention period, it is not erased but depersonalised: the session, visitor and conversation identifiers, the IP address and the user agent are cleared and the row is marked as deleted. What is left carries no reference to you and documents only that consent to a particular wording was given, and withdrawn, on a particular day – the accountability that Art. 5(2) GDPR requires of a controller. When a Customer's project or workspace is deleted, these records are deleted with it.

Copies in backups are kept for up to 364 days (7.1).

4.12 File attachments

In the chat you can attach files: images (PNG, JPEG, WebP, HEIC/HEIF, SVG), PDF documents, and text and CSV files. We process the file itself, its file name, type and size, the time of upload and a checksum (SHA-256); for PDF, text and CSV files also a text extract taken from them.

• Purpose: the file is part of the conversation. The Customer's agents see it in the dashboard, and where the AI assistant answers your message, it can take the file's content into account.
• In your browser: before uploading, the widget scales down images whose longest side exceeds 2,560 pixels and re-encodes photos larger than 1.5 MB, where your browser can process them, and saves them anew as JPEG. Embedded metadata such as EXIF data (for example the place where a photo was taken) is not carried over. Smaller images are generally uploaded unchanged and may contain such metadata; SVG graphics are always uploaded unchanged.
• On the server: the server checks that the content of a file matches its declared type and rejects the file otherwise. It also rejects SVG graphics that contain scripts, embedded external content or references to external addresses. Files are not scanned for viruses. A single file may be at most 2 MB on the free plan and at most 15 MB on paid plans; all attachments of a Customer's workspace together at most 1 GB or 50 GB respectively. Individual contracts may set other limits. For images in HEIC/HEIF format, which many browsers cannot display, and for SVG graphics, the server creates a JPEG preview; it is stored with the file and deleted with it.
• Storage and access: the files are stored on our own server in Łódź, in a separate directory per workspace and conversation, and are included in the backup (7.1). They can be retrieved only through a signed address that cannot be guessed. This address appears in the chat, in the Customer's dashboard and in the Customer's data export; it does not expire, so anyone who has it can retrieve the file for as long as it is stored.
• AI assistant: from PDF, text and CSV files our server extracts the text (for PDF, from at most the first 20 pages) and stores it next to the file. Where the AI assistant (4.4) answers your message, it receives at most 2,500 characters of these extracts per message, after the same PII scrubbing as for messages (4.7). The same scrubbed extract also supplements the search in the Customer's knowledge base (4.4) for your message, so that the assistant can tell whether and how your file relates to the Customer's website; for this purpose it is embedded on the same inference nodes as your message (4.4) and never reaches a third-party AI service. Of an image, the assistant receives a version reduced to at most 768 pixels and re-encoded as JPEG without embedded metadata (for HEIC/HEIF and SVG, the JPEG preview): the first image of your most recent message with an image, for follow-up questions for up to 10 minutes, at most one image per answer. This version is created only when the assistant answers, goes only to our own inference nodes (4.4) and never to a third-party AI service, and it is not stored; we keep only a reference to the file. What can be seen or read in the image is not scrubbed (4.7). In addition, our server reads the text in images by optical character recognition – on our own server, without third parties – and stores the result next to the file. It goes to no language model: only the digit sequences recognised in it are given to the same own inference node that receives the image, so that it can check that a number in the answer is supported. In addition, our server uses the recognised text for the word search in the knowledge base (4.4), on our own server only: up to four words from it that also occur in the Customer's knowledge base (no numbers) supplement the word search for your message; where the image shows the title or a passage of a page of the Customer's website, the assistant receives that page as a source. Neither the recognised text nor these words are given to any language model or third party, and they are not passed on for embedding. The result is deleted after 24 to 48 hours, at the latest together with the file, and is not part of the data export.
• Retention: attachments are deleted 7 days after upload on the free plan and 90 days after upload on paid plans; under an individual contract, after the period agreed there. The Customer's current plan applies, and a daily run removes whatever is older. Attachments are deleted earlier together with the conversation – also where it is anonymised (4.11) – and with the Customer's project or workspace. The text extract and the file's details are deleted together with the file. Copies in backups follow 7.1.

4.13 Order and invoice data from the Customer's shop

If the Customer has enabled this feature on a paid plan, the AI assistant (4.4) can answer questions about your own orders – for example about order, shipping or payment status.

• Prerequisite: you are signed in with the Customer, and the Customer's server has confirmed your customer ID with a time-limited signature. Without this confirmation no order data is used. An order or invoice number that you mention in the chat does not by itself grant anything and is looked up only among your own orders.
• Data: only the fields the Customer has enabled, from this list: order number, order date, order status, total and currency, item name and quantity, carrier, tracking number and shipping status, only if explicitly enabled the city and postcode of the delivery address, invoice number, payment status and due date. Street and further address lines, names, e-mail address, phone number, bank and card data, date of birth, credentials and tax and ID numbers are never passed on; our server discards such data even if it is sent.
• Origin and storage: either our server fetches the data from the Customer for your message and does not store it (fetch; a temporary copy in memory expires after 30 seconds), or the Customer transmits it in advance (import); in that case we store it encrypted, with your customer ID only as a hash, and delete it at the latest 90 days after the last transmission, earlier on the Customer's instruction or together with the project.
• Processing: the data goes only to our own inference nodes or a node of the Customer (4.4), never to a third-party AI service, and not into the knowledge base. The text given to the model is removed from our records after delivery. The assistant's answer is part of the conversation (4.11).
• We process this data as the Customer's processor (4.1).

4.14 Smart Answer (AI answers in website search)

The Customer may add Smart Answer to the search on its website. If your search input is phrased as a question, a brief answer written by a language model, with links to its sources, then also appears above or below the results. Smart Answer is a separate service of the operator (the Answely service) on the same server; the roles are the same as for the chat widget: the Customer is the controller, and we process your data on the Customer's behalf (4.1).

• What leaves your browser: whether an input is sent is decided in your browser by the search script, which is loaded from cdn.reactive.chat – by default only if it looks like a question; the Customer can set every search input above a minimum length to be answered. The following is sent in encrypted form to our server, where applicable through an address the Customer has set up for this on its own domain: the question (at most 300 characters), the language, the address of the current page and the referring page, both without parameters and anchors – on search pages these often contain the search term –, and, if the chat widget is embedded on the same page, its visitor id (4.2). Our server also strips parameters and anchors on receipt. We use your IP address to limit requests and to protect against abuse (4.9). Like any request, it appears in our web server's access log, without question or answer; that log is deleted after at most 15 days (2.1).
• How the answer is produced: the question takes the same path as a message to the AI assistant (4.4): a search in the Customer's knowledge base and a language model on the same inference nodes; the answer is returned to your browser step by step. Smart Answer only answers if the Customer has switched the AI assistant on, and not if the Customer has the chat ask for consent before the first message (4.10). By default the answer is labelled as AI-generated. It may contain errors; the linked pages are authoritative.

What happens to question and answer is set by the Customer per project ("Store search queries"):

• Off: question and answer are not stored. They exist only in working memory while being processed, at most 180 seconds on the way between our servers and the inference nodes, and are deleted afterwards. No conversation is created, and neither question nor answer appears in a database, in the Customer's dashboard or in a log. A follow-up question in the chat starts a new, ordinary conversation with only the text you then enter; the original search question is not carried over.
• On (default): question and answer are stored as a conversation like a chat (channel "Site search"), which the Customer's agents see in the dashboard (4.5); the retention for conversations applies (4.11). A follow-up question in the chat continues this conversation. So that a repeated question is not computed again, the search script keeps the answer together with your question, the sources and the conversation identifier in your browser's sessionStorage and uses it for at most ten minutes. In addition, the Smart Answer service keeps a generated answer with its sources for 24 hours, so that the same question on the same website is not computed again; the question is kept in it only as a one-way hash, and nothing about you is kept in it.

In both cases:

• Counter: for each request the Smart Answer service stores an entry without content in its own database on our server: time, shortened IP address (IPv4 without the last octet, IPv6 shortened to the first 48 bits), identifier of the website, length of the question, result and duration. It serves to detect abusive numbers of requests and to troubleshoot, and is deleted after seven days. The Customer only sees daily figures from it, without IP addresses.
• Follow-up questions in the search box: if the Customer has set follow-up questions to be answered in the box, or no chat is embedded on the page, the follow-up question stays in the box. The up to three previous questions and answers of the box are sent with it to our server; of these, only the questions go to the language model. If storing is on, each follow-up question is stored together with these previous questions as a separate conversation.
• In the browser: Smart Answer sets no cookies. sessionStorage holds the search settings for five minutes and, only if storing is on, the answers mentioned above for ten minutes. The search script deletes expired entries as soon as it reads them or starts again on a page; if a tab stays open without a new page load, an expired entry remains there until the next page load or until you close the tab.
• Legal bases: the Customer determines them (4.10); typically Art. 6(1)(f) GDPR, the Customer's legitimate interest in answering questions on the basis of the content of its website. Where we use the counter to protect our own service against mass automated use, our legal basis is Art. 6(1)(f) GDPR.

4.15 AI tools for agents: translation, reply drafts, summaries

In the dashboard, the Customer's agents can use a language model to help them with a conversation. These tools are available whether or not the Customer uses the AI assistant (4.4). Reply drafts, summaries, rewording and the translation of replies can be used only by team members who may answer conversations.

• Translation: an agent can have messages translated into the language of the dashboard and can have their own reply translated into your language. If the Customer switches automatic translation on for its project – it is off unless the Customer changes this – or an agent switches it on for a conversation, incoming messages in another language are shown to the agent translated, and every reply is translated before it is sent. The model receives the text to be translated – your messages as they were stored after PII scrubbing (4.7), the agent's reply as the agent wrote it – and the names of the languages. A translation needs the complete text, so nothing further is replaced.
• Automatic translation of incoming messages and of every reply is available only for projects of a workspace on a paid plan (with an active subscription, including a trial period, or under an individual contract); on the free plan an agent can still have a single message translated on request. Where the Customer has set the chat to ask for your consent before you can write (4.10), automatic translation is used only while your consent is known to the chat; otherwise the agent sees your messages untranslated and the agent's replies are not translated automatically. The same consent rule applies to reply drafts, summaries and rewording.
• Reply draft, summary, rewording: an agent can have a draft of the next reply prepared, have the conversation summarised for a colleague, or have their own reply reworded. For a draft, the model receives up to the last 30 messages of the conversation (at most 5,000 characters), up to four passages from the Customer's knowledge base (4.4) with their title and address, the name of the Customer's project and any notes the agent has typed for the reply; for a summary, up to the last 60 messages including the agents' internal notes (at most 7,000 characters); for rewording, only the agent's own reply. Beforehand, in addition to the PII scrubbing (4.7), e-mail addresses, telephone numbers and digit sequences of six or more digits are replaced, and links in the conversation lose their parameters and anchors; for rewording, these parts are replaced by placeholders and put back afterwards, so that the model does not see them. The model does not receive the names of agents, your visitor or session id or your IP address; an attachment appears only as the word "[attachment]". The address of the page you are on is used only to prefer knowledge-base passages from that page.
• Handover note and conversation summary: when a conversation is handed over from the assistant to a person, the model can write a short internal note for the agent; for long conversations, it summarises older exchanges so that the assistant keeps the context. Both stay internal.
• Where it runs: on the same inference nodes as the AI assistant – our own nodes (1.1) or, where the Customer has connected one, a node of the Customer (4.4, 4.6) –, never at a third-party AI service, not even as a fallback.
• Nothing is sent automatically: the result appears only in the dashboard of the agent who asked for it. It becomes a message to you only when that agent sends it, under the agent's name; such a message carries no AI label. A translated reply is shown to the agent before it is sent; if the translation fails, nothing is sent unless the agent explicitly sends the original. A summary, if the agent sends it, is stored only as an internal note that you do not see.
• What is stored: a translation is stored with the message it belongs to; for a reply sent in translation, the agent's original wording is stored with it as well. Translations are additionally kept in the conversation's working copy (4.11) for up to 30 days. On anonymisation (4.11), the translations stored with the messages are removed together with the message texts. You receive only the message in your language; you see neither the agent's original nor a translation of your own messages. Drafts, summaries and rewordings are not stored in the conversation unless the agent sends them. The work orders for the model are marked confidential: the text sent to the model is removed from them as soon as the result has been delivered, and an order that is never delivered is emptied after about ten minutes, while the result remains – for translations, drafts, summaries and rewording alike. The result is kept with the conversation and emptied on anonymisation; orders without a conversation are deleted after 30 days.
• Legal bases: the Customer determines them (4.10). The tools serve the same purpose as the chat itself – answering your requests.

4.16 Campaigns

On paid plans the Customer can run campaigns: targeted messages in the widget and, through WhatsApp, messages to contacts who have agreed to receive them.

• In the widget: the Customer selects visitors by page or address, time on the page, referring site, campaign parameters, new or returning visitor, country (derived from the IP address, 4.2), language, device, whether signed in and fields of the Customer's customer data. For visitors from the GDPR area and where the country is unknown, campaigns run only with consent (4.10); for others, where the Customer's project does not require consent, typically on the basis of the Customer's legitimate interest. So that a campaign is not shown to you too often and its effect can be counted, we keep, under a one-way hash of your visitor or session id, a counter per campaign – until one day after the campaign ends (at most 400 days) or, for campaigns without an end date, 90 days after you were last addressed – and a repetition lock for the minimum interval the Customer sets between two messages (at most 90 days), and a marker of whether you have visited before (90 days after your last visit, itself a hash). Reach is counted in counters that cannot be read back individually (HyperLogLog), which are kept for up to 400 days. A deletion request removes your counters, lock and marker.
• WhatsApp campaigns: sent through the Customer's own Meta account, only with message templates approved by Meta and only to contacts with a recorded opt-in – either imported by the Customer, who must confirm the opt-in and describe its proof in at least 20 characters, or given by you yourself by sending the start word. Having chatted with the Customer does not count as an opt-in. For each contact we store the WhatsApp number, name, labels, language, the proof of the opt-in, an opt-out with its reason and the word used, and per campaign the delivery and read times. Deliveries are deleted 90 days after their last status; the campaign keeps only its totals. If you reply with a stop word (in German, English or Polish), you are excluded from further campaigns. If you have your chat data deleted, your contact and deliveries are deleted; if you had opted out, only a blocking note remains – a keyed hash of your number, without name or other details – so that a later import by the Customer cannot sign you up again; sending the start word yourself lifts it. Contacts have no separate period otherwise and are deleted with the project.
• Legal basis: the Customer determines it; for WhatsApp campaigns, typically your consent (Art. 6(1)(a) GDPR), which the Customer must be able to prove.

4.17 Call-back requests, voice and video calls, co-browsing

If the Customer and we have switched them on, the widget offers call-back requests, voice and video calls and co-browsing.

• Call-back: we store your telephone number, country, request, preferred time window, a note and the agent assigned. Completed requests are deleted after 30 days, open ones after 90 days.
• Voice and video calls in the browser are established between your browser and the agent's browser (WebRTC) only after you have accepted the call; camera and microphone are accessed only after your click. The audio and video stream is encrypted. No public STUN server is used. Unless we operate a relay server (TURN), which forwards the encrypted stream without being able to read it, the two browsers connect directly and therefore learn each other's IP address. Either side can share its screen; everything visible on a shared screen can be seen by the other side. We store a call log (agent, start, end, media type) for 365 days; we do not record calls.
• Co-browsing: after you have accepted, the agent sees a list of the buttons, links and headings of the page you are on – no form fields and nothing you type – and can highlight an element and scroll to it for you. The agent cannot click or type on your page. A banner shows that co-browsing is active, and you can end it at any time. Its content is not recorded.
• Click-to-call by telephone: if enabled, our server has the agent's telephone called through Twilio and connects it with your number; Twilio then receives both telephone numbers (section 5). This function is not currently enabled.
• Legal basis: the Customer determines it; a call takes place only at your request.

4.18 Customer portal

The Customer can give its end customers access to their cases in a customer portal. If you use it, we process the case, your contributions to it and a pseudonymous key of yours; your portal session is valid for one hour. Cases have no separate period and are deleted with the project.

4.19 Error reports, frustration signals and A/B tests

• Error reports: if the Customer uses this, the widget reports script errors on the Customer's website: the path, browser, operating system and error message, and – only where you have consented to session replay – a link to the recording. Reports are deleted after 90 days if nobody has looked at them; individual examples and links to conversations after 30 days.
• Frustration signals: the widget recognises behaviour such as repeated clicking without effect, without any language model. Only aggregated figures per path and day are stored (400 days); examples with a link to the session recording (only with consent) are kept for 8 days.
• A/B tests (beta): to count how many visitors saw which variant, your visitor id is added to counters that cannot be read back individually; daily counters are kept for 200 days, totals for 400 days. The results in the database have no separate period and are deleted with the project.

4.20 Test runs and versions of the assistant

The Customer can test its assistant with test questions before going live. It can write them itself or adopt questions that visitors actually asked and the assistant could not answer (knowledge gaps); before such a question is adopted, it passes through the PII scrubber (4.7), and if the scrubber is unavailable, nothing is adopted. Adopted questions (at most 500 characters) and the answers of the test runs are the Customer's content: they are not linked to you, are not removed by a deletion request and are deleted with the project. Test runs create no conversation. Each saved change of the assistant's settings is kept as a version with the person who saved it, without a time limit; of the guided flows, the latest 100 versions per project are kept.

5. Recipients and sub-processors

We use the following sub-processors and recipients. The current list with addresses and safeguards is published at Sub-processors.

5.1 Sub-processors

1. Google Cloud EMEA Limited, Dublin, Ireland (Google Cloud Storage) – storage of the encrypted daily backup of the whole server (7.1) in a storage location in Warsaw, Poland (region europe-central2). The backup is encrypted on our server before it is transferred, including file and directory names; the keys stay on our server, and Google cannot read the content. Affects all data described in this policy.
2. Stripe Payments Europe, Ltd., Dublin, Ireland – payment processing and invoicing for Customers (3.3). Stripe never receives visitor data from our billing.
3. Google Ireland Limited, Dublin, Ireland – reCAPTCHA on the login, registration, password-reset and support forms (2.7): IP address, device and behaviour signals. Never inside the chat widget.
4. E-mail – sending through our e-mail service; the provider currently used for each function (sending, the mailbox contact@lukaswojcik.com and the forwarding of e-mails to reactive.chat addresses) is named in the sub-processors list. At present this is Namecheap, Inc., Phoenix, USA, which also operates the name servers (DNS) of reactive.chat. E-mails can contain Customer data and, where a visitor requests a copy of a conversation or the e-mail channel is used without the Customer's own mail server, visitor data (3.4). In the latter case, replies to visitors are sent from our address no-reply@reactive.chat in the name "[project] via reactive.chat" with the Customer's address as reply address; the provider then receives the visitor's e-mail address and name, the subject and the text of the reply (4.6).
5. Push services of browser makers – Google (Firebase Cloud Messaging), Mozilla, Apple and Microsoft, depending on the browser of a team member who has switched on notifications (3.10): subscription address, time and size of each message; the content (kind of event and project name, no message text) is encrypted end-to-end. The push service is determined by the team member's browser; it receives no readable content.
6. Twilio Inc., USA – only if click-to-call by telephone is enabled (4.17): telephone numbers of visitor and agent. Not currently enabled.

5.2 Other recipients

• Let's Encrypt (Internet Security Research Group, USA) issues the TLS certificates for reactive.chat and for domains of Customers who serve the chat under their own domain. It receives only the domain names, which then appear in public certificate logs; no visitor data.
• Google – if a Customer connects Google Drive as a source, Google acts as the Customer's service: the Customer signs in with its own Google account. The connection uses an OAuth application registered by us, so Google learns that the Customer has authorised that application, and our server retrieves the selected files from Google on the Customer's instruction (3.6, 4.4).

5.3 Not recipients of personal data

• Telegram (Telegram FZ-LLC, Dubai, United Arab Emirates): we receive notifications about new support requests, new feedback and operating alarms (for example availability of components, load, AI nodes) through a Telegram bot. They consist of fixed texts and operating figures and contain no personal data – no names, e-mail addresses, IP addresses or message texts. Telegram sees only our server's IP address. Telegram is therefore not a sub-processor.
• Our network operator (1.1), which transports encrypted data only.
• Our own server and our own AI inference nodes (1.1), and MousePlayer, which is operated by the same legal entity.
• The country database MaxMind GeoLite2, which is used locally on our server; nothing is transmitted to MaxMind.
• Providers of channels and integrations that a Customer connects (3.6, 4.6) – including Meta, Telegram and Twilio for the channels, Cal.com, Stripe and the Customer's own interfaces for bot actions (4.4), the Customer's identity provider (3.9) and the AI tools the Customer connects to our MCP server (4.6) –, and an AI server connected by the Customer: they act for the Customer, not for us.

6. Transfers to third countries

Our server and the AI nodes are located in Poland; the backup is stored in Poland (Warsaw). Personal data is transferred to recipients outside the EEA, or can be accessed from there, in these cases:

• Stripe: Stripe Payments Europe may transfer Customer billing data to Stripe, Inc. (USA).
• Google: for reCAPTCHA and push messages, a transfer to Google LLC (USA) cannot be excluded. For the backup, Google cannot read the content, because it is encrypted with keys that only we hold.
• Namecheap (USA): e-mails and the e-mail addresses contained in them; operation of the name servers (DNS) of reactive.chat.
• Push services of Mozilla, Apple and Microsoft (USA): subscription address, time and size of notifications to team members.
• Twilio (USA): only if click-to-call is enabled.
• Let's Encrypt (USA): domain names only.

Safeguards: where the recipient is certified under the EU-US Data Privacy Framework, the adequacy decision of the European Commission (Art. 45 GDPR); otherwise the EU standard contractual clauses (Art. 46(2)(c) GDPR). Details per recipient are in the sub-processors list. The Telegram notifications contain no personal data, so no personal data is transferred to the United Arab Emirates. If a Customer connects a channel or integration whose provider is located outside the EEA, that transfer is the Customer's responsibility.

7. Retention overview

7.1 Backups

One period outlasts most others: the backup.

• Off-site backup: every night at about 03:00 a copy of all databases on our server and of all files of the websites on it – including chat attachments, knowledge-base documents and company logos – is made, encrypted on our server (content as well as file and directory names) and transferred to Google Cloud Storage in Warsaw (5.1). The keys never leave our server. Daily copies are kept for 7 days, the weekly copy made on Sundays for 364 days. A local copy of the same backup is additionally kept on a separate storage device at the server for about 8 days; it is not encrypted.
• Database copy of reactive.chat: every night at about 03:05 a compressed copy of the reactive.chat database is made on the server itself and kept for about 31 days; it is not encrypted.

Anything deleted in the live system therefore remains inside these copies until they expire – at most 364 days after the deletion. Nothing is selectively removed from a backup: a copy is an image of one point in time. Backups are used for nothing except restoring the system after a loss. If we ever have to restore one, we will re-apply the deletions carried out since that copy was made, in particular the deletion requests of visitors and the deletions of accounts and workspaces, before the system returns to service. Since 16 October 2026 every such deletion is recorded, when it is carried out, in a deletion journal on our server – the kind of deletion, the identifiers concerned, the mode and the time, without content, e-mail addresses or IP addresses –, kept for 400 days, and a script re-applies the recorded deletions after a restore; deletions by retention period catch up at their next run. Two limits remain: a deletion requested after the copy was made that was still in its 30-day waiting period is not in the journal and must be requested again; and if the server itself were lost, the journal is only as recent as the latest backup copy, so deletions of up to the last 24 hours could not be re-applied.

7.2 Periods by category

• Web server access log: the current day and the 14 previous days (2.1).
• System journal of the server: limited to 500 MB, no time limit; error and work logs of individual components: currently no automatic rotation (2.1).
• Support requests: with the account where linked to one; otherwise 365 days after arrival or last processing (2.4). E-mails to contact@lukaswojcik.com: as long as needed to handle the request (2.5).
• Customer account data: as long as the account exists; deletion 30 days after the account owner's deletion request (3.7). The end of a paid subscription deletes nothing.
• Acceptance record of the contract documents and declaration of registering as a business: with the account (3.1).
• Sessions: 14 days without use, 60 days with "stay signed in"; expired sessions are deleted one day after expiry (3.9).
• Audit log: per workspace 90, 180, 365 or 730 days or – default – until the workspace is deleted; entries without a workspace: logins, failed attempts and entries without an account 90 days, other entries of an account until the account is deleted, deletion records and our administrative actions without a period (3.11).
• Read log (Agency plan): at most 731 days (3.8).
• Push subscriptions: until switched off, at the latest 60 days without being seen (3.10).
• Invoices and payment notifications: at least 5 years under Polish tax law; currently no automatic deletion (3.3).
• Conversations, their messages, ratings, tags and AI records: no automatic period unless the Customer sets one per project (0–3,650 days); otherwise until the conversation, the project or the workspace is deleted (4.11).
• Working copy of conversations in the real-time server: 30 days after the last activity; page context of a session: 30 minutes (4.11).
• AI work orders without a conversation: 30 days (4.4).
• Translations of the AI tools for agents: with the message; in the working copy of the conversation up to 30 days (4.15).
• Consent records of visitors: no automatic period; depersonalised when the visitor deletes their chat data or the conversation is deleted under the retention period; deleted with the project or workspace (4.11).
• Chat attachments: 7 days (free plan) or 90 days (paid plans) after upload, or the period of an individual contract; text recognised in images 24 to 48 hours (4.12).
• Imported order and invoice data: at most 90 days after the Customer's last transmission; fetched data is not stored (4.13).
• Page text transmitted by the widget: no automatic period; with the project (4.2).
• Channel identities, e-mail threads, WhatsApp campaign contacts: no automatic period; with the project and on a deletion request (4.6, 4.16). Channel message numbers: 7 days. WhatsApp campaign deliveries: 90 days after the last status. Campaign counters per visitor: until one day after the campaign ends (at most 400 days) or 90 days after the last contact; repetition lock for the interval set by the Customer, at most 90 days; reach counters up to 400 days (4.16).
• Live visitor list: renewed every 30 seconds, expires after 90 seconds; nothing stored beyond that (4.5).
• Knowledge-base files uploaded by the Customer and texts from Google Drive: until the Customer deletes them or disconnects Drive, at the latest with the project (4.4).
• Versions of the assistant's settings: no automatic period; versions of guided flows: the latest 100 per project (4.20).
• Call-back requests: 30 days after completion, 90 days if open; call log 365 days (4.17).
• Visitor proof on the server: 400 days after last use (4.2).
• Smart Answer (4.14): counter entries with shortened IP address 7 days. Questions and answers not at all if storing is off (at most 180 seconds in transit), like conversations if it is on; answer cache (question only as a hash) 24 hours.
• Automatic blocks: for their duration (24 hours unless set otherwise); security events of the guard: the latest 500 (4.9).
• Error reports: 90 days, examples 30 days; frustration figures 400 days, examples 8 days; A/B counters 200 and 400 days (4.19).
• E-mails held when sending is not available: 30 days (3.4).
• Backups: daily copies 7 days, weekly copies 364 days, local copies about 8 and 31 days (7.1).
• Deletion journal: 400 days after the deletion it records (7.1).
• Security cookie rc_csrf of the website: until the browser is closed; nothing is stored on the server (2.8).
• Browser storage: see 4.3 – sessionStorage until you close the tab; localStorage entries one day or one year; rc_dnt, rc_dnd, rc_vtok and mp_visitor_id without expiry.

8. Your rights

Under Art. 15 to 22 GDPR you have the right of access, the right to rectification, erasure and restriction of processing, the right to data portability and the right to object to processing based on Art. 6(1)(f) GDPR. Where processing is based on consent, you may withdraw it at any time with effect for the future. To exercise your rights:

• Parts A and B: write to contact@lukaswojcik.com. We answer within one month. Customers and team members can download their own account data in the settings (3.7), and the Customer can export the data of a project as JSON or as a ZIP file with CSV tables and attachments. Practical details: Access and deletion and Data Act information.
• Part C: write to the Customer whose website you used. The Customer is the controller. If you write to us, we forward your request to the Customer and assist in answering it. Where the Customer has switched the buttons on, you can delete your chat data, and withdraw a consent you gave in the chat, yourself in the chat window – that reaches only the chat data, not what the Customer holds about you elsewhere, and it is done on the Customer's standing instruction, not on a decision of ours. Where the Customer has left the recognition of written deletion requests switched on, writing your request in the chat has the same effect: our server recognises the wording without the AI assistant and, depending on the Customer's setting, asks you to confirm before deleting or deletes straight away (4.11). A deletion does not reach copies in backups before they expire (7.1).

You have the right to lodge a complaint with a supervisory authority, in particular with the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO), ul. Stawki 2, 00-193 Warsaw, Poland, or with the authority of your habitual residence or place of work.

9. Automated decision-making and profiling

We do not make automated decisions that produce legal effects concerning you or similarly significantly affect you (Art. 22 GDPR). We do not profile anyone for advertising, and we do not combine data across Customers' websites.

• The automated abuse protection described in 4.9 may temporarily block a connection, a visitor id or an IP address; it has no legal effect and can be reviewed on request by contacting us or the Customer.
• The AI assistant answers questions; it does not decide about contracts, prices or claims. An action that changes something is carried out only after your confirmation (4.4).
• AutoQA (3.11) evaluates conversations. Its evaluation per agent is rule-based; the AI judgement applies only to conversations without an agent and is never attributed to a person. It is a tool of the Customer, who decides what follows from it; the Customer must make sure that no decision about an employee is based solely on it.
• The routing classification (4.4) only assigns conversations to agents by the Customer's rules; it decides nothing about you.

10. Security

We protect data with technical and organisational measures pursuant to Art. 32 GDPR, among them transport encryption (TLS 1.2 and 1.3), hashed passwords and tokens, optional two-factor authentication, role-based access control, tenant isolation, encryption of stored credentials for third-party services and of the secrets of two-factor authentication, PII scrubbing, rate limiting and automated abuse protection, and encrypted off-site backups. What the measures are, and where their limits lie, is described in the Technical and organisational measures; risks that remain are assessed in our data protection impact assessment, which we make available on request. The production installation is separate from the development installation; both run on the same server as other projects of the operator and are separated from them by directories and databases (1.1).

In the event of a personal data breach, our documented procedure provides for notifying affected Customers without undue delay and at the latest within 48 hours of becoming aware of it; where we are the controller, we notify the supervisory authority as required by Art. 33 GDPR.

11. Obligation to provide data

Providing registration and billing data is necessary to conclude and perform the contract; without it we cannot open an account. Using the chat widget on a Customer's website is voluntary; which details you enter in a chat is up to you.

12. Changes to this policy

We update this policy when the service, our sub-processors or the law change. The current version is always published at /p/privacy-policy. Customers are informed of material changes by e-mail or in the dashboard. The date below indicates the version in force; earlier versions and a summary of the changes are listed in the change log.

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

Version 2.6 replaces version 2.5 of 17 October 2026. Added: security cookie rc_csrf of the website, set on every page (2.8, 3.9, 7.2). Also changed on the same day: the separate production installation (1.1, 10); the records of processing activities and the data protection impact assessment are no longer published and are available on request (introduction, 10).

Version 2.5 replaces version 2.4 of 17 October 2026. Changed: the AI is described uniformly as our own, self-hosted AI; model names removed, the facts are unchanged (1.1, 4.4).

Version 2.4 replaces version 2.3 of 16 October 2026. Changed: acceptance of the current contract documents before ordering a paid plan (3.1); session identifier stored only as a hash (3.9).

Version 2.3 replaces version 2.2 of 12 October 2026. Corrected: language models and nodes (4.4); shortened IP address in the Smart Answer counter (4.14, 7.2); periods and deletion paths of 16 October 2026: support requests without an account (2.4), workspace deletion refused while a paid subscription is running and what remains after a deletion (3.7), expired sessions (3.9), audit-log entries without a workspace (3.11), consent records with the project or workspace (4.11), overview of periods (7.2). Supplemented on 16 October 2026: the live functions that depend on the country (live visitor list, campaigns, consent requirement for the GDPR area) derive it from the IP address with the local country database (4.2, 4.5, 4.10, 4.16). Further supplemented on 16 October 2026: declaration of registering as a business, not as a consumer (3.1, 7.2); encrypted secret of two-factor authentication and time of its confirmation in the session (3.9, 10); deletion journal and re-applying deletions after a restore (3.7, 7.1, 7.2); acceptance of the contract documents and the declaration before creating or taking over a workspace where it is missing for the current version (3.1).

Version 2.2 replaces version 2.1 of 11 October 2026. Corrected: no separate production environment (1.1, 10); notice bars of the website (2.2); loading of reCAPTCHA (2.7); telephone number for click-to-call (3.1); own data download (3.7); browser storage of the dashboard (3.9); content of push notifications (3.10); failed logins without an account (3.11); places where the IP address is stored (4.2); browser storage of the widget: rc_id, mp_ keys, rc_sig, rc_vtok and entries moved on consent (4.3); deletion of AI orders without a conversation (4.4); renewal of the live visitor list (4.5); deletion of channel identities (4.6); consent record under the retention period (4.11); re-encoding of photos (4.12); Answely, answer cache and access log for Smart Answer (4.14); translations on anonymisation (4.15); repetition lock of campaigns (4.16); local database copy (7.1); overview of periods (7.2).

Version 2.1 replaces version 2.0 of 11 October 2026. Changed: single sign-on, audit log and pseudonyms of agents (3.9, 3.11); content of push notifications (3.10); AutoQA with AI judgement only for conversations without an agent (3.11); signed e-mail address (4.2); knowledge-base files and Google Drive, bot actions with the Customer's Cal.com and Stripe, routing classification, job applications, guided flows (4.4); live visitor list (4.5); channels Telegram, SMS and e-mail in detail, API and MCP (4.6); consent requirement for visitors from the GDPR area (4.10); campaigns with new periods and the WhatsApp blocking note (4.16); calls, screen sharing and co-browsing (4.17); test runs and versions (4.20).

Version 2.6 – effective 19 October 2026.