Technical and Organisational Measures

1. Scope and principle

This document describes the technical and organisational measures ("TOMs") that LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, NIP PL7252266190 (the "Operator") applies when operating reactive.chat (the "Service"). It forms Annex B of the Data Processing Agreement ("DPA") and serves the documentation required by Article 32 GDPR. Terms defined in the DPA ("Customer", "Visitor", "Customer Data") have the same meaning here.

Principle. Every measure described here is implemented. Where a measure has a limit, the limit is stated next to it rather than left out, so that the Customer can judge whether the level of protection is appropriate for the data it entrusts to the Service. Risks that remain after these measures are assessed in the Operator's data protection impact assessment; the processing operations themselves are listed in its records of processing activities. Both are not published; the Operator makes them available to the supervisory authority and, on request, to Customers.

Setting. The Service is run by the owner of the Operator personally. It is hosted on one server owned by the Operator (a Raspberry Pi 5) in the Operator's premises in Łódź, Poland. The Service runs in a production installation that is separate from its development installation on the same machine (section 2.4). The same machine also hosts other services of the Operator. The language models run on separate machines of the Operator ("AI nodes") in the same local network. A daily encrypted copy of the server is held off-site with Google Cloud Storage in Warsaw (section 5.1). The organisational measures are sized for a one-person operation: there is no separate security team and no separation of duties between development, operation and review.

The measures are arranged by the categories of Article 32 GDPR: confidentiality (sections 2 and 3), integrity (section 4), availability and resilience (section 5), the ability to restore (section 6), procedures for regular review (section 7), control of processing on behalf (section 8) and measures specific to the AI functions (section 9).

2. Confidentiality – access

2.1 Physical access control

• The server and the AI nodes are hardware owned by the Operator and are located in the Operator's premises in Łódź, Poland. No third-party data centre or hosting provider is involved in running the Service. Internet connectivity is provided by Toya Sp. z o.o., Łódź, as a mere network operator without access to stored data.
• The premises are locked; access is held by the Operator only (statement of the Operator).
• The storage of the server is not encrypted at disk level. Protection of data at rest against theft of the hardware therefore rests on the physical measures. Backups transferred off-site are encrypted (section 5.1); a local copy of the most recent backups on a drive attached to the server is not encrypted (section 5.1).

2.2 System access control (authentication)

Customer accounts

• Passwords are stored only as bcrypt hashes with a cost factor of 12 and are re-hashed automatically when the algorithm changes. A password must have at least 10 characters; common passwords and passwords built from the user's own name or address are rejected.
• The sign-in takes the same time whether or not an account exists, so that it cannot be used to find out which e-mail addresses are registered. Registration is protected in the same way.
• After 5 failed sign-in attempts an account is locked for 15 minutes. Independently of that, sign-in attempts are limited per IP address (30 per 15 minutes), as are registrations (10 per hour per IP address), password-reset requests (10 per 15 minutes) and support requests.
• Google reCAPTCHA v3 checks the sign-in, registration, password-reset and support forms for automated abuse (see the Sub-processors page, section 3). It is not used in the chat widget. If Google cannot be reached or no key is configured, the forms are accepted without the check; a sign-in without a reCAPTCHA token is also accepted, because the account lock and the per-address limits apply to it.
• Two-factor authentication with a time-based one-time password (TOTP, RFC 6238) is available to every user, with protection against reuse of a code and with one-time recovery codes stored as hashes; the shared secret is stored encrypted (section 3.2). For Customer accounts it is optional; a workspace cannot currently make it mandatory. For the operator administration area it is mandatory (see Server administration).
• On the Agency plan, sign-in through the Customer's own identity provider (single sign-on, OpenID Connect) can be set up and can be made mandatory for the workspace.
• Sessions exist only on the server. The session identifier has 256 bits of randomness; since 17 October 2026 the database holds only its SHA-256 hash (also in the reference of the "stay signed in" token), the cookie carries the random value, and a copy of the database contains no usable session. A session expires after 14 days without use, a "stay signed in" token after 60 days. Expired sessions and tokens are deleted by a daily run one day after their expiry. Session cookies are HttpOnly, SameSite=Lax and Secure. Users see their active devices and can sign out everywhere; a password reset ends all sessions, a password change ends all other sessions.
• Links for password reset and e-mail confirmation are stored only as hashes, are valid for 60 minutes and can be used once.

API and real-time access

• API keys are stored only as hashes. Each key belongs to exactly one workspace, carries scopes that limit what it may do, can be revoked at any time and is limited to 120 requests per 60 seconds. Repeated use of invalid keys from one IP address is blocked.
• An agent's connection to the real-time server requires a short-lived ticket issued by the application after the permission check; the permissions for the project are computed by the application and handed over with the ticket. A ticket for the live console on the Customer's website is valid for one conversation and 90 seconds.

Server administration

• The server is administered by the Operator over SSH; sign-in with a password is not disabled. A host firewall (UFW) is active. fail2ban is installed, but its SSH filter does not currently recognise failed sign-ins of the installed OpenSSH version, so repeated failed SSH sign-ins are not yet blocked automatically.
• The operator administration area of the Service is open only to accounts that the Operator has named in the server configuration; with an empty list nobody has access. Since 16 October 2026 these accounts receive operator rights only when two-factor authentication is set up and has been passed in the same session (a "stay signed in" token carries the confirmation over, for at most 60 days; single sign-on does not count); an account without it is sent to set it up. The requirement can be switched off only in the server configuration, as an emergency exit.

2.3 Data access control (authorisation)

• A single permission matrix defines what each role may do. The roles are owner, admin, member (agent) and viewer. A workspace can restrict the rights of members and viewers further but can never extend them. Access of a user can be limited to individual projects.
• Permissions are checked centrally on the server for every page and every action, not only in the user interface. An admin cannot remove or change the owner; the owner role cannot be assigned by invitation or role change.
• Switching on integrations that send data to third parties requires a separate right that only owners and admins have.
• The operator administration area is used for accounts, plans, operating switches and support. It does not display conversation content. As administrator of the server the Operator nevertheless has technical access to the database and the file system. That access is used only to operate the Service, to handle a support request of the Customer, to handle an incident or to comply with a legal obligation. It is not recorded by the application's logs (section 4.2).

2.4 Separation control

• Each workspace and each project is separated logically. In the dashboard the workspace is taken from the session and membership is checked on every switch; in the API the workspace is taken exclusively from the API key; conversation identifiers in API paths are always checked against that workspace.
• On the real-time server an agent reaches only the conversations of the site for which the ticket was issued; a Visitor reaches only his or her own conversations, proven by a random token that the server issued to that browser (visitor proof). Unknown or deactivated site keys are refused.
• File attachments are stored in a separate directory per workspace and conversation.
• The Service runs in a production installation (reactive.chat) that is separate from its development installation (dev.reactive.chat): own program directory, own database with its own database user that has no access to the development database, own Redis database and own service processes, including separate worker instances on the AI nodes with their own key. Changes to the code take effect in the development installation immediately; they reach the production installation only through a transfer of a fixed version (section 6). Both installations run on this machine and use the same AI nodes; they are separated by software, not by hardware. The development installation is protected by a password at the web server; its widget, API, real-time server and Smart Answer are exempt from it.

3. Confidentiality – minimisation, pseudonymisation and encryption

3.1 Pseudonymisation and data minimisation

• Visitors are distinguished by random identifiers. Without a consent signal from the Customer's consent tool the widget creates no persistent visitor identifier, only a session identifier, and keeps its state in sessionStorage, which is cleared when the tab closes. With consent the state moves to localStorage. The widget sets no cookies. A single bit "do not track again" is written to localStorage after a Visitor has deleted his or her data, also without consent.
• The Visitor's IP address is used to establish the connection, to derive the country from a local database on the server (no request to a third party; only the country code is read, and the address is not stored for this purpose; this country is stored with the session and, since 16 October 2026, also used by the live functions that depend on the country – country information sent by the browser is not used, and where no country can be derived, consent is required) and to defend against abuse. The conversation record stores the country, not the IP address. Full IP addresses are stored where they serve evidence or security: in the record of a Visitor's consent decision, in temporary blocks for their duration, in the security log of the real-time server (the latest 500 entries), in the web server's access logs and the system journal (section 4.2) and, for users of the Customer's account, in the sign-in log. The counter of Smart Answer keeps the IP address only shortened (section 3.4).
• Messages from Visitors and agents are scrubbed on the server before they are stored. E-mail addresses, payment card numbers (Luhn check), IBANs (ISO 7064 check), telephone numbers written with a leading + or 0, German tax numbers, tax identification numbers and identity card numbers, and secrets such as passwords or keys are replaced by a placeholder; the type and number of replacements are recorded with the message. Telephone numbers without a leading + or 0 and Polish tax and personal identification numbers (NIP, PESEL) are not recognised. Scrubbing applies to the widget and to the connected channels. It does not apply to messages that the Customer writes into a conversation directly through the REST API, nor to the values of form replies, which the Customer deliberately collects in a form; these are stored as submitted.
• Before a conversation is passed to the language model for a reply draft, a summary or a rewording for an agent, e-mail addresses, telephone numbers and digit sequences of six or more digits are additionally replaced and links lose their parameters and anchors. Names of agents, visitor identifiers and page addresses are not passed on.
• Images that the AI assistant is to look at are scaled down to 768 pixels and re-encoded before they reach the model; embedded metadata such as EXIF location data is removed. Only one image is passed per request.
• Campaigns in the widget keep counters per Visitor only under a one-way hash of the visitor or session identifier, for periods tied to the campaign (without an end date at most 90 days after the last contact); the returning-visitor marker is a hash as well. After a WhatsApp opt-out followed by a deletion request, only a keyed hash of the number remains as a blocking note.
• The live visitor list is built only from data the session already carries. It never shows IP addresses, the raw browser identification, advertising click identifiers or names, shows the full line for Visitors from the GDPR area and of unknown country only with consent, and is held in memory for at most 90 seconds.
• Through the MCP server, without the additional permission for Visitor data, names are reduced to initials, e-mail addresses masked, telephone numbers shortened to the last two digits and texts scrubbed; IP addresses of Visitors are never passed on.
• Evaluations can show agents under pseudonyms. The AI verdict of quality assurance is never attributed to an agent; its input passes the PII scrubber and known names are replaced.

3.2 Encryption

• In transit: see section 4.1.
• Access credentials that the Customer stores for integrations, channels, single sign-on, bot actions, identity verification and its own AI node are encrypted with AES-256-GCM, bound to their purpose by additional authenticated data. The key is held in the server configuration, outside the database; it protects against a copy of the database, not against a compromise of the server itself.
• The shared secret of two-factor authentication is encrypted with AES-256-GCM, using a key of its own derived from the same server key and bound to the account. Secrets stored in clear text before 16 October 2026 are encrypted at the next successful code and the clear text is removed. Like the key above, this protects against a copy of the database, not against a compromise of the server itself.
• Order data imported from the Customer's shop for answers in the chat is stored encrypted and expires after 90 days.
• Passwords, API keys, session identifiers (since 17 October 2026), recovery codes and one-time links are stored only as hashes (section 2.2).
• Backups leave the server only in encrypted form (section 5.1).
• Data in the database and in the file system is otherwise not encrypted at rest (section 2.1).

3.3 File attachments

• Visitors and agents can attach files in the chat. Accepted are images (PNG, JPEG, WebP, HEIC/HEIF, SVG), PDF, text and CSV files. The server checks the first bytes of each file against its declared type and rejects files that do not match; SVG files are checked in full.
• An upload requires a signed, time-limited permission issued for one specific conversation. Limits on file size and total storage apply per plan (2 MB per file and 1 GB per workspace on the free plan, 15 MB and 50 GB on paid plans).
• Files are stored outside the web server's document root, in a directory per workspace and conversation, with file permissions that exclude other system users. They are delivered only through a signed address that cannot be guessed, under a Content Security Policy that forbids any active content; files other than images are offered as a download.
• Files are not scanned for malware. The type check prevents disguised file types but does not detect harmful content inside a permitted type. Agents should treat attachments with the same care as e-mail attachments.
• A text extract of PDF, text and CSV files is passed to the AI assistant only when it answers the related message, at most 2,500 characters per message and after scrubbing. Text recognised in images (OCR) is used only to check figures and to recognise job applications (section 9) and is not passed to a language model.
• Attachments are deleted automatically after the retention period of the Customer's plan (free: 7 days, paid plans: 90 days, individual contracts: the agreed period), and earlier together with their conversation, project or workspace. The deletion never follows symbolic links.

3.4 Smart Answer

• Smart Answer is answered by the Operator's Answely service, a separate service of the same legal entity on the same server. The browser sends page addresses without parameters and anchors; the service sends questions and page addresses to the AI nodes like the chat. Where the Customer has storing switched on, it keeps a generated answer (text and sources, the question only as a hash) for 24 hours in a cache to answer the same question again.
• The question is cut to at most 300 characters. If storing is switched off, question and answer exist only in working memory while being processed, at most 180 seconds on the way between the server and the AI nodes, and are not stored.
• Its logs contain neither question nor answer, and it writes no AI log entry. Each request creates a counter entry with time, IP address shortened (IPv4 without the last octet, IPv6 to the /48 network), website identifier, length of the question and result, deleted automatically after 7 days.
• The public interface releases answers to browsers only for the domains registered for the project (CORS) and limits requests per IP address and per website.

4. Integrity

4.1 Transfer control

• All connections to the website, the dashboard, the widget, the API and the real-time server are encrypted with TLS 1.2 or TLS 1.3; older protocols are disabled. Certificates are issued by Let's Encrypt and renewed automatically. HTTP Strict Transport Security is sent for the hosts of the website and the dashboard.
• The application sends a Content Security Policy with a random nonce per request for scripts, forbids embedding in frames of other sites and restricts form targets and base addresses. It also sends X-Content-Type-Options, a Referrer-Policy and a Permissions-Policy. Stylesheets inline in the page are permitted by the policy.
• Every state-changing request in the dashboard, the administration area and the sign-in pages is protected by a CSRF token bound to the session; webhooks, channels and the API are authenticated by their own signatures or keys instead.
• The real-time server accepts browser connections per project only from the domains registered for that project, where the Customer has registered domains. Without registered domains a connection is accepted from any origin. The check of the origin is effective against browsers, not against other clients.
• Outgoing requests of the Service to addresses chosen by a Customer (channels, webhooks, integrations, shop interfaces, identity providers) are protected against server-side request forgery: the name is resolved, every resulting address must be public, and the connection is made to the checked address. Push notifications are sent only to the push services of the browser manufacturers on a fixed list of host names. The crawler for the knowledge base checks each host and each redirect anew and respects robots.txt.
• Custom bot actions call only HTTPS addresses on port 443 whose resolved addresses are all public, with the checked address pinned; redirects are followed only for read requests and at most twice; the time limit is 5 seconds (2 seconds to connect) and the response at most 64 kB. Their secrets are encrypted with AES-256-GCM. Actions that change something run only after the Visitor's click and only once.
• Data leaves the Operator's infrastructure only to the recipients listed on the Sub-processors page and to the channels and integrations that the Customer switches on (section 8).

4.2 Input control and logging

• Audit log. Sign-ins (including single sign-on), failed sign-ins, account actions and each call of an MCP tool (without content) are written to an audit log with user, workspace, time, action and full IP address. Owners and admins see the changes of their workspace from a fixed list, without IP addresses and without the sign-ins of team members, and can export them. They choose its retention (90, 180, 365 or 730 days, or until deletion of the workspace, which is the default); the period applies to all entries of the workspace. Entries without a workspace are deleted after 90 days: sign-ins, second-factor, password and single sign-on events and failed attempts of an account, and all entries that belong to no account (such as failed sign-ins with an e-mail address for which no account exists and blocks of IP addresses), except deletion markers and actions of the Operator; other entries of an account are kept until the account is deleted.
• Operator actions. Actions in the operator administration area (for example blocking, unblocking or deleting users, changing plans) are recorded.
• Read log (Agency plan). It records which user opened which conversation, when and by which route (desk, live console, AI log), without IP address and content, at most once per user, conversation and route within ten minutes; entries are deleted after 731 days. Access by the Operator and access through the API are not recorded in it.
• AI log. For each AI answer the Service records which sources were used, which checks ran and which model and node answered, without a copy of the text (section 9).
• Changes to the software. Source changes are tracked in version control. Changes to the development installation are made directly in its working tree and can be in use there before they are committed. Only committed versions are transferred to the production installation; the transfer script writes a report per transfer with the version, the files and the database migrations, and keeps it with the backup taken before the transfer (section 6). Changes are not reviewed by a second person.
• Web server logs. Access logs contain IP address, time, request, referrer and browser identification. They are rotated daily and kept for at most 15 days (14 rotations plus the current day).
• System journal and application logs. The system journal also contains the output of the real-time server, including IP addresses; it is limited only by size (500 MB), with no time limit. Logs of the Service's background processes currently have no automatic rotation and no deletion period; they contain operating messages and, in individual cases, IP addresses or e-mail addresses of account holders.

5. Availability and resilience

5.1 Backups

There are two backup routes.

Server-wide backup (off-site, encrypted). Every day at about 03:00 an automated job creates a dump of all databases of the server and an archive of the web directories, which include the Service's file attachments, knowledge-base files and company logos.

• The backup is encrypted on the server before it is transferred (rclone crypt); file and directory names are encrypted as well. The keys remain on the server; the storage provider receives only encrypted blocks.
• It is transferred to Google Cloud Storage, bucket in region europe-central2 (Warsaw, Poland); provider Google Cloud EMEA Limited, Dublin (see Sub-processors, section 2.1).
• Retention: daily copies for 7 days, the weekly copy (Sunday) for 364 days. From day 10 the copies are moved to a colder storage class.
• The same backup is additionally kept on a drive attached to the server for about 8 days. This local copy is not encrypted; it is protected by the file permissions of the server and by the physical measures (section 2.1).

Database backup of the Service. Every day at 03:05 a second job writes a compressed dump of the Service's database to the server's system disk, readable only by its owner, and keeps it for 30 days. It is not encrypted and does not contain files.

Consequences. Data deleted in the live system remains in backups until they expire: at most 364 days in the weekly off-site copies, at most 30 days in the local database dumps. Selective deletion inside a backup is not performed, because each copy is a sealed image of one point in time. Backups serve only to restore the system after a loss; they are not searched, analysed or disclosed. If a backup has to be restored, the Operator will re-apply the deletions that were carried out after the date of the copy before the Service returns to normal operation (section 6).

5.2 Protection against abuse and overload

• The real-time server limits each connection: frames of at most 64 KiB, 120 frames and 20 messages per 10 seconds, 3 connections per session, 1,000 connections in total, 5 seconds to identify after connecting; messages longer than the plan allows (1,000 characters on the free plan, 4,000 otherwise) are refused. It can block offending IP addresses and visitor identifiers automatically for a limited time; the Operator maintains manual block lists.
• Agents can block an abusive Visitor with the command /ban in the desk for up to 365 days (default 24 hours). The block covers the Visitor's identifier and IP address (for IPv6 the whole /64 network, which can include other devices of the same connection); the IP block applies to the real-time server as a whole, not only to the Customer's site.
• The AI assistant has a budget per website and minute and a limit per conversation and plan; beyond it the Visitor receives a fixed message instead of an AI answer.
• The web server limits the size of requests and the time to read them; fail2ban blocks addresses that probe for secrets or send oversized requests for one hour.
• The Operator can switch off the AI globally or per project at once (kill switch) and can switch off any of 24 functions per project (for example uploads, translation, calls, campaigns).

5.3 Monitoring

• A health check runs every minute for the environment in which the Service runs. It checks the components of the Service, among them the website and the AI nodes, and alerts the Operator by Telegram on a change of state. Alerts contain component names and operating figures only, no personal data.
• Operating alerts cover, among others, unreachable AI nodes, a high share of refused AI requests, the kill switch, the number of real-time connections, server load and memory, and the number of fatal errors.
• A public status page shows the measured state with a 90-day history.
• The check runs on the server it watches. It cannot report a total failure of that server or of the internet connection; such failures are noticed by a person.

6. Ability to restore

• Systems and data can be restored from the backups in section 5.1: the database from the daily dump (local or off-site), files from the off-site copy. Procedures for recovery and emergencies are documented internally.
• A transfer to the production installation is started by the Operator by hand on the server, under a different user account than the web server; the web server process itself has no write access to the program files of the production installation. The script exports a fixed, committed version (not the working tree of the development installation), first backs up the program files, the database and the scheduled tasks of the production installation, then applies the database migrations and copies a fixed list of files; it stops at the first error. The replaced program files can be restored with one command; database changes are additive and are corrected forwards, and the database itself can be restored from the backup taken before the transfer. The former transfer by order in the operator area is no longer used.
• Before the Service returns to normal operation after a restore, the Operator re-applies deletions made after the date of the restored copy, including Visitors' deletion requests and deleted workspaces and accounts. Since 16 October 2026 every deletion on occasion – a Visitor's deletion request or withdrawal, the deletion of a workspace, project or account – is recorded when it is carried out in a deletion journal kept outside the database (kind, identifiers, mode and time, without content, addresses or IP addresses; kept for 400 days), and a script re-runs the recorded deletions with the same functions; deletions by retention period catch up at their next run. Not covered: deletions requested after the date of the copy that were still in their 30-day grace period, and, if the server itself is lost, the deletions after the most recent backup of the journal (up to 24 hours).
• No recovery time objective is promised, and regular restore tests are not yet documented.

7. Procedures for regular review, assessment and evaluation

7.1 Review of these measures

• The Operator reviews these TOMs whenever the infrastructure, the sub-processors or the Service change materially, and at least once a year.
• Updates do not reduce the level of protection. The current version is published on this page; the DPA refers to the version in force at the time of processing.
• The code base contains automated test benches, among them checks of the permission matrix, of two-factor authentication and of the abuse protection.
• No independent certification or external penetration test is referred to in this document. If one is carried out in future, it will be listed here.

7.2 Personal data breaches

• The Operator maintains a written procedure for personal data breaches. It covers detection, assessment, containment, notification and documentation, and treats loss and alteration of data as breaches as well as disclosure.
• A breach concerning Customer Data is notified to the Customer without undue delay and at the latest within 48 hours of the Operator becoming aware of it, so that the Customer can meet its own 72-hour deadline under Article 33 GDPR. The notification is sent to the e-mail address of the account owner and contains the information listed in Article 33(3) GDPR as far as known; the rest follows in phases.
• Every breach and every assessment that concludes there was none is documented with its effects and the measures taken.

7.3 Data protection by design and by default

• Without a consent signal the widget runs in essential mode (section 3.1). With the consent level "required" the widget sends page context, page text and the details passed by the Customer only after consent.
• The Visitor can delete his or her data in the widget ("Your data", "Delete everything"), withdraw consent and ask in writing for deletion; these requests are processed by the server within a few minutes.
• No automatic deletion period for conversations is preset. The Customer sets it per project (0 to 3,650 days, where 0 means no limit) and chooses whether expired conversations are deleted or anonymised. The Operator can set a maximum for all projects.
• Scrubbing runs automatically on the server before storage; it does not depend on Visitors or agents (with the exceptions in section 3.1).

7.4 Organisation

• Responsibility for data protection and information security lies with the owner of the Operator personally. There is no separate security team and no separation of duties; the Operator states this so that Customers can take it into account.
• Persons authorised to access Customer Data are bound to confidentiality.
• Procedures for breaches, recovery, emergencies and deployment are documented internally.
• Questions about these measures and reports of security issues: contact@lukaswojcik.com.

8. Control of processing on behalf (order control)

• The Operator processes Customer Data only on the Customer's instructions as set out in the DPA; the settings the Customer chooses in the dashboard are part of these instructions.
• The Operator engages only the sub-processors listed on the Sub-processors page. Each is bound by a contract with data-protection obligations under Article 28(4) GDPR. Changes are announced 30 days in advance; the Customer may object.
• Channels and integrations that the Customer switches on with its own accounts and credentials send data on the Customer's instruction to the Customer's own providers. Only owners and admins can switch them on. They are outside the Operator's sub-processor control.
• If the Customer connects its own AI node, conversation content for AI requests goes to that node and to whatever model the Customer runs there; that node is the Customer's own processor.

9. Measures specific to the AI functions

• Own models only. The language models of the Operator's own AI (one chat model on the second-tier nodes and another as reserve on the first-tier node, each an instruction version, quantised to 4 bits) and its embedding model are openly licensed models that are self-hosted and run unchanged on the Operator's AI nodes in the local network. No third-party AI service receives Customer Data.
• Register of nodes, closed by default. Only nodes entered and activated in a register receive AI jobs. A node that is not registered is refused; if the register cannot be read, no node receives work.
• No training. Customer Data is not used to train or fine-tune models. Individual requests may be used internally to compare model versions before an update; they are not used for training and are not passed on.
• Human oversight and switches. The Customer can switch the AI assistant off per project. As soon as an agent takes over, the assistant stays silent. If the assistant finds no reliable basis, it hands over to a human. The Operator has a global and per-project kill switch (section 5.2).
• Labelling. The widget tells Visitors before the first AI message that they are chatting with an AI assistant and marks every AI message with an "AI" badge. The Customer may not remove or obscure this labelling (DPA clause 13).
• Checks before and after the model. Requests that try to use the assistant for unrelated tasks are recognised by rules before the model is called; answers are checked for code and for statements that contradict the sources (for example weekdays, figures, "free of charge"). Some functions use no model at all: requests for deletion, questions about data storage and the setup suggestions are answered by fixed rules.
• No processing of job applications. Applications are recognised by fixed patterns in text, attachments and file names before any model is called – in the chat, in Smart Answer, in the AI verdict of quality assurance and of test runs, in the knowledge-gap drafts and in the support assistant; the conversation then receives no further model job except translation, and no AI verdict or reply suggestion is requested. An instruction at the start of every system prompt, except for translations, is a second barrier. File names are recognised regardless of spaces, underscores, hyphens, dots, upper or lower case, capitals inside the name and accents, wherever the word stands in the name ("CV Anna.pdf", "AnnaLebenslauf.pdf"), also when they are written only as text; short words such as "CV", "resume" or "Zeugnis" count only as a word of their own, and in a text the word with the file extension and up to four words before it count as the file name. The detection can miss applications whose wording or file names it does not know; the instruction to the model then remains as the second barrier. There is no switch.
• No AI evaluation of Team Members. The AI verdict of quality assurance is given only for conversations without human participation and is never attributed to an agent; evaluations per agent are rule-based.
• Knowledge base. The assistant answers from the knowledge base that the Customer supplies and, where it finds nothing, may answer from general knowledge. Content of the knowledge base and of the Customer's pages is passed to the model as supplied; the Service does not filter it for embedded instructions. The Customer controls what it contains.
• Job records. The record of an AI job contains the instruction and the conversation text. It is deleted together with its conversation; records without a conversation are deleted after 30 days. Jobs with order data, bot actions, simulations, the routing classification, the AI verdict of quality assurance and reply drafts, summaries, rewording and translations for agents are marked confidential and emptied as soon as the result has been delivered, otherwise after about ten minutes. The AI log contains no text (section 4.2).
• Embeddings of the knowledge base are held in the server's cache for 30 days and rebuilt when the knowledge base changes.

10. Status and version

This document is drawn up in English. Translations into German (/de/p/technische-und-organisatorische-massnahmen) and Polish (/pl/p/srodki-techniczne-i-organizacyjne) are provided for convenience; the English version prevails.

Version 2.0 replaces version 1.4 of 7 October 2026. Changed: the document is rearranged by the categories of Article 32 GDPR and extended by system and data access, encryption, monitoring, recovery, order control and AI measures; the off-site backup at Google Cloud Storage with weekly copies of up to 364 days replaces the statement "backups up to 30 days, no hyperscaler"; statements that did not match operation were removed or corrected (SSH with named keys only, physically separate development and production, mandatory e-mail verification, IP blocks by Customers in the dashboard, deletion of AI job texts after about ten minutes, scrubbing without exceptions, image downscaling before upload); limits are stated (no disk encryption, no malware scan, no separation of duties).

Version 2.1 replaces version 2.0 of 11 October 2026. Changed: minimisation for campaigns, the live visitor list, MCP and evaluations (3.1); limits for custom bot actions (4.1); audit log with single sign-on and MCP calls (4.2); block on job applications and no AI evaluation of Team Members (9).

Version 2.2 replaces version 2.1 of 11 October 2026. Corrected: there is no separate production environment yet, the Service runs in its development installation (1, 2.4, 4.2, 5.3, 6); SSH with password sign-in, fail2ban not effective for SSH (2.2); limits of reCAPTCHA (2.2); scrubbing of telephone numbers and identifiers, system journal with IP addresses (3.1, 4.2); OCR also for recognising job applications (3.3); Smart Answer through Answely with a 24-hour answer cache (3.4); push services on a fixed host list (4.1); audit-log entries without an account are not deleted (4.2); /ban per /64 network for IPv6, fail2ban one hour (5.2); confidential jobs of the AI tools for agents (9).

Version 2.3 replaces version 2.2 of 12 October 2026. Corrected: Smart Answer counter with a shortened IP address, question length and maximum time in transit (3.1, 3.4); chat models of the Operator's own AI with a reserve model (9); block on job applications on all model paths except translation (9); periods of 16 October 2026: expired sessions and tokens deleted (2.2), audit-log entries without a workspace deleted after 90 days (4.2). Supplemented on 16 October 2026: country for the live functions derived from the IP address (3.1); file names written as text (9). Further supplemented on 16 October 2026: second factor mandatory for the operator administration area (2.2); encrypted secret of two-factor authentication (2.2, 3.2); deletion journal for re-applying deletions after a restore (6); file names recognised regardless of spaces and other separators, spelling and accents (9).

Version 2.4 replaces version 2.3 of 16 October 2026. Changed: session identifiers stored in the database only as SHA-256 hashes (2.2, 3.2).

Version 2.5 replaces version 2.4 of 17 October 2026. Changed: the AI is described uniformly as the Operator's own, self-hosted AI; model and software names removed, the facts are unchanged (9).

Version 2.6 replaces version 2.5 of 17 October 2026. Corrected: a transfer to the production instance does not save the state it replaces and does not restore it automatically; how such a transfer is ordered and carried out, and that it is currently blocked (6).

Version 2.7 replaces version 2.6 of 18 October 2026. Changed: the separate production installation with its own database user, Redis database and AI worker instances (1, 2.4); transfers to the production installation only of committed versions, by hand, with a backup beforehand and restoration of the program files (4.2, 6); the records of processing activities and the data protection impact assessment are available on request instead of published (1).

Version 2.7 – effective 19 October 2026.