Technische und organisatorische Maßnahmen

Diese Übersetzung wird zur besseren Verständlichkeit bereitgestellt. Verbindlich ist ausschließlich die englische Fassung unter /p/technical-and-organisational-measures.

1. Geltungsbereich und Grundsatz

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen („TOM"), die LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, NIP PL7252266190 (der „Betreiber") beim Betrieb von reactive.chat (der „Dienst") anwendet. Es bildet Anlage B des Auftragsverarbeitungsvertrags („AVV") und dient der nach Art. 32 DSGVO erforderlichen Dokumentation. Im AVV definierte Begriffe („Kunde", „Besucher", „Kundendaten") haben hier dieselbe Bedeutung.

Grundsatz. Jede hier beschriebene Maßnahme ist umgesetzt. Wo eine Maßnahme eine Grenze hat, steht die Grenze neben ihr, statt weggelassen zu werden, damit der Kunde beurteilen kann, ob das Schutzniveau für die Daten angemessen ist, die er dem Dienst anvertraut. Die nach diesen Maßnahmen verbleibenden Risiken sind in der Datenschutz-Folgenabschätzung des Betreibers bewertet; die Verarbeitungen selbst sind in seinem Verzeichnis von Verarbeitungstätigkeiten aufgeführt. Beide werden nicht veröffentlicht; der Betreiber stellt sie der Aufsichtsbehörde und auf Anfrage Kunden zur Verfügung.

Rahmen. Der Dienst wird vom Inhaber des Betreibers persönlich betrieben. Er läuft auf einem Server im Eigentum des Betreibers (einem Raspberry Pi 5) in den Räumen des Betreibers in Łódź, Polen. Der Dienst läuft in einer Produktionsinstallation, die von seiner Entwicklungsinstallation auf derselben Maschine getrennt ist (Abschnitt 2.4). Dieselbe Maschine trägt auch andere Dienste des Betreibers. Die Sprachmodelle laufen auf eigenen Rechnern des Betreibers („KI-Knoten") im selben lokalen Netz. Eine tägliche verschlüsselte Kopie des Servers liegt außer Haus bei Google Cloud Storage in Warschau (Abschnitt 5.1). Die organisatorischen Maßnahmen sind auf einen Ein-Personen-Betrieb zugeschnitten: Es gibt kein eigenes Sicherheitsteam und keine Funktionstrennung zwischen Entwicklung, Betrieb und Prüfung.

Die Maßnahmen sind nach den Kategorien des Art. 32 DSGVO geordnet: Vertraulichkeit (Abschnitte 2 und 3), Integrität (Abschnitt 4), Verfügbarkeit und Belastbarkeit (Abschnitt 5), Wiederherstellbarkeit (Abschnitt 6), Verfahren zur regelmäßigen Überprüfung (Abschnitt 7), Kontrolle der Auftragsverarbeitung (Abschnitt 8) und Maßnahmen für die KI-Funktionen (Abschnitt 9).

2. Vertraulichkeit – Zutritt, Zugang, Zugriff, Trennung

2.1 Zutrittskontrolle

• Server und KI-Knoten sind Hardware im Eigentum des Betreibers und stehen in den Räumen des Betreibers in Łódź, Polen. Am Betrieb des Dienstes ist kein fremdes Rechenzentrum und kein Hosting-Anbieter beteiligt. Den Internetanschluss stellt Toya Sp. z o.o., Łódź, als reiner Netzbetreiber ohne Zugriff auf gespeicherte Daten.
• Die Räume sind verschlossen; Zutritt hat nur der Betreiber (Angabe des Betreibers).
• Der Speicher des Servers ist nicht auf Datenträgerebene verschlüsselt. Der Schutz ruhender Daten gegen Diebstahl der Hardware beruht daher auf den physischen Maßnahmen. Sicherungen, die den Server verlassen, sind verschlüsselt (Abschnitt 5.1); eine lokale Kopie der jüngsten Sicherungen auf einem am Server angeschlossenen Laufwerk ist nicht verschlüsselt (Abschnitt 5.1).

2.2 Zugangskontrolle (Authentifizierung)

Kundenkonten

• Passwörter werden nur als bcrypt-Hash mit Kostenfaktor 12 gespeichert und bei einem Algorithmuswechsel automatisch neu gehasht. Ein Passwort muss mindestens 10 Zeichen haben; häufige Passwörter und Passwörter aus dem eigenen Namen oder der eigenen Anschrift werden abgelehnt.
• Die Anmeldung dauert gleich lang, ob ein Konto existiert oder nicht, damit sich nicht ermitteln lässt, welche E-Mail-Adressen registriert sind. Die Registrierung ist ebenso geschützt.
• Nach 5 Fehlversuchen wird ein Konto für 15 Minuten gesperrt. Unabhängig davon sind Anmeldeversuche je IP-Adresse begrenzt (30 je 15 Minuten), ebenso Registrierungen (10 je Stunde und IP-Adresse), Anfragen zum Zurücksetzen des Passworts (10 je 15 Minuten) und Supportanfragen.
• Google reCAPTCHA v3 prüft die Formulare für Anmeldung, Registrierung, Passwort-Zurücksetzen und Support auf automatisierten Missbrauch (siehe Unterauftragsverarbeiter, Abschnitt 3). Im Chat-Widget wird es nicht eingesetzt. Ist Google nicht erreichbar oder kein Schlüssel eingerichtet, werden die Formulare ohne die Prüfung angenommen; eine Anmeldung ohne reCAPTCHA-Token wird ebenfalls angenommen, weil für sie die Kontosperre und die Grenzen je Adresse gelten.
• Zwei-Faktor-Authentifizierung mit zeitbasiertem Einmalpasswort (TOTP, RFC 6238) steht jedem Nutzer zur Verfügung, mit Schutz gegen die Wiederverwendung eines Codes und mit Einmal-Wiederherstellungscodes, die als Hash gespeichert sind; das gemeinsame Geheimnis wird verschlüsselt gespeichert (Abschnitt 3.2). Für Kundenkonten ist sie freiwillig; ein Workspace kann sie derzeit nicht vorschreiben. Für den Betreiber-Verwaltungsbereich ist sie Pflicht (siehe Serververwaltung).
• Im Agency-Tarif kann die Anmeldung über den eigenen Identitätsanbieter des Kunden (Single Sign-on, OpenID Connect) eingerichtet und für den Workspace verpflichtend gemacht werden.
• Sitzungen existieren nur auf dem Server. Die Sitzungskennung hat 256 Bit Zufall; in der Datenbank steht seit dem 17. Oktober 2026 nur ihr SHA-256-Hash (auch im Verweis des „Angemeldet bleiben“-Tokens), das Cookie trägt den Zufallswert, und eine Kopie der Datenbank enthält keine verwendbare Sitzung. Eine Sitzung läuft nach 14 Tagen ohne Nutzung ab, ein „Angemeldet bleiben"-Token nach 60 Tagen. Abgelaufene Sitzungen und Token löscht ein täglicher Lauf einen Tag nach ihrem Ablauf. Sitzungs-Cookies sind HttpOnly, SameSite=Lax und Secure. Nutzer sehen ihre aktiven Geräte und können sich überall abmelden; das Zurücksetzen des Passworts beendet alle Sitzungen, eine Passwortänderung alle anderen.
• Links zum Zurücksetzen des Passworts und zur Bestätigung der E-Mail-Adresse werden nur als Hash gespeichert, gelten 60 Minuten und sind einmal verwendbar.

API und Echtzeitzugang

• API-Schlüssel werden nur als Hash gespeichert. Jeder Schlüssel gehört zu genau einem Workspace, trägt Berechtigungsbereiche (Scopes), die begrenzen, was er darf, ist jederzeit widerrufbar und auf 120 Anfragen je 60 Sekunden begrenzt. Wiederholte Versuche mit ungültigen Schlüsseln von einer IP-Adresse werden gesperrt.
• Die Verbindung eines Agenten zum Echtzeitserver erfordert ein kurzlebiges Ticket, das die Anwendung nach der Rechteprüfung ausstellt; die Rechte für das Projekt berechnet die Anwendung und gibt sie mit dem Ticket mit. Ein Ticket für die Live-Konsole auf der Website des Kunden gilt für ein Gespräch und 90 Sekunden.

Serververwaltung

• Der Server wird vom Betreiber über SSH verwaltet; die Anmeldung mit Passwort ist nicht abgeschaltet. Eine Host-Firewall (UFW) ist aktiv. fail2ban ist eingerichtet, sein SSH-Filter erkennt Fehlanmeldungen der installierten OpenSSH-Version derzeit aber nicht; wiederholte fehlgeschlagene SSH-Anmeldungen werden daher noch nicht automatisch gesperrt.
• Der Betreiber-Verwaltungsbereich des Dienstes ist nur für Konten offen, die der Betreiber in der Serverkonfiguration benannt hat; bei leerer Liste hat niemand Zugang. Seit dem 16. Oktober 2026 erhalten diese Konten die Betreiberrechte nur, wenn die Zwei-Faktor-Authentifizierung eingerichtet ist und in derselben Sitzung bestanden wurde (ein „Angemeldet bleiben“-Token trägt die Bestätigung weiter, höchstens 60 Tage; Single Sign-on zählt nicht); ein Konto ohne sie wird zur Einrichtung geleitet. Abschalten lässt sich die Pflicht nur in der Serverkonfiguration, als Notausgang.

2.3 Zugriffskontrolle (Berechtigung)

• Eine einzige Rechtematrix legt fest, was jede Rolle darf. Die Rollen sind owner, admin, member (Agent) und viewer. Ein Workspace kann die Rechte von member und viewer weiter einschränken, aber nie erweitern. Der Zugriff eines Nutzers kann auf einzelne Projekte beschränkt werden.
• Rechte werden für jede Seite und jede Aktion zentral auf dem Server geprüft, nicht nur in der Oberfläche. Ein admin kann den owner nicht entfernen oder ändern; die Rolle owner kann nicht per Einladung oder Rollenwechsel vergeben werden.
• Das Einschalten von Integrationen, die Daten an Dritte senden, erfordert ein eigenes Recht, das nur owner und admin haben.
• Der Betreiber-Verwaltungsbereich dient Konten, Tarifen, Betriebsschaltern und Support. Er zeigt keine Gesprächsinhalte an. Als Administrator des Servers hat der Betreiber dennoch technischen Zugriff auf Datenbank und Dateisystem. Dieser Zugriff wird nur genutzt, um den Dienst zu betreiben, eine Supportanfrage des Kunden zu bearbeiten, einen Vorfall zu behandeln oder eine gesetzliche Pflicht zu erfüllen. Er wird von den Protokollen der Anwendung nicht erfasst (Abschnitt 4.2).

2.4 Trennungskontrolle

• Jeder Workspace und jedes Projekt ist logisch getrennt. Im Dashboard wird der Workspace aus der Sitzung genommen und die Mitgliedschaft bei jedem Wechsel geprüft; in der API wird der Workspace ausschließlich aus dem API-Schlüssel genommen; Gesprächskennungen in API-Pfaden werden stets gegen diesen Workspace geprüft.
• Auf dem Echtzeitserver erreicht ein Agent nur die Gespräche der Website, für die das Ticket ausgestellt wurde; ein Besucher erreicht nur seine eigenen Gespräche, nachgewiesen durch ein Zufallstoken, das der Server diesem Browser ausgestellt hat (Besucherbeweis). Unbekannte oder deaktivierte Site-Keys werden abgewiesen.
• Datei-Anhänge werden in einem eigenen Verzeichnis je Workspace und Gespräch gespeichert.
• Der Dienst läuft in einer Produktionsinstallation (reactive.chat), die von seiner Entwicklungsinstallation (dev.reactive.chat) getrennt ist: eigenes Programmverzeichnis, eigene Datenbank mit eigenem Datenbanknutzer ohne Zugriff auf die Entwicklungsdatenbank, eigene Redis-Datenbank und eigene Dienstprozesse, einschließlich eigener Worker-Instanzen auf den KI-Knoten mit eigenem Schlüssel. Änderungen am Code werden in der Entwicklungsinstallation unmittelbar wirksam; in die Produktionsinstallation gelangen sie nur durch die Übertragung einer festen Fassung (Abschnitt 6). Beide Installationen laufen auf dieser Maschine und nutzen dieselben KI-Knoten; sie sind durch Software getrennt, nicht durch Hardware. Die Entwicklungsinstallation ist durch ein Passwort am Webserver geschützt; ausgenommen sind ihr Widget, ihre API, ihr Echtzeitserver und Smart Answer.

3. Vertraulichkeit – Minimierung, Pseudonymisierung und Verschlüsselung

3.1 Pseudonymisierung und Datenminimierung

• Besucher werden durch Zufallskennungen unterschieden. Ohne Einwilligungssignal aus dem Einwilligungswerkzeug des Kunden erzeugt das Widget keine dauerhafte Besucherkennung, nur eine Sitzungskennung, und hält seinen Zustand im sessionStorage, der beim Schließen des Tabs geleert wird. Mit Einwilligung wandert der Zustand in den localStorage. Das Widget setzt keine Cookies. Ein einzelnes Bit „nicht erneut erfassen" wird in den localStorage geschrieben, nachdem ein Besucher seine Daten gelöscht hat, auch ohne Einwilligung.
• Die IP-Adresse des Besuchers wird für den Verbindungsaufbau, für die Ableitung des Landes aus einer lokalen Datenbank auf dem Server (ohne Anfrage an Dritte; gelesen wird nur der Ländercode, die Adresse wird dafür nicht gespeichert; dieses Land wird mit der Sitzung gespeichert und seit dem 16. Oktober 2026 auch von den Live-Funktionen genutzt, die vom Land abhängen – Landesangaben des Browsers werden nicht verwendet, und lässt sich kein Land ableiten, ist eine Einwilligung nötig) und für die Missbrauchsabwehr verwendet. Der Gesprächsdatensatz speichert das Land, nicht die IP-Adresse. Volle IP-Adressen werden gespeichert, wo sie dem Nachweis oder der Sicherheit dienen: im Nachweis der Einwilligungsentscheidung eines Besuchers, in befristeten Sperren für deren Dauer, im Sicherheitsprotokoll des Echtzeitservers (die jüngsten 500 Einträge), in den Zugriffsprotokollen des Webservers und im Systemjournal (Abschnitt 4.2) und für Nutzer des Kundenkontos im Anmeldeprotokoll. Der Zähler von Smart Answer speichert die IP-Adresse nur gekürzt (Abschnitt 3.4).
• Nachrichten von Besuchern und Agenten werden vor der Speicherung auf dem Server bereinigt. E-Mail-Adressen, Zahlungskartennummern (Luhn-Prüfung), IBANs (Prüfung nach ISO 7064), Telefonnummern mit führendem + oder 0, deutsche Steuernummern, Steuer-Identifikationsnummern und Ausweisnummern sowie Geheimnisse wie Passwörter oder Schlüssel werden durch einen Platzhalter ersetzt; Art und Anzahl der Ersetzungen werden mit der Nachricht vermerkt. Telefonnummern ohne führendes + oder 0 sowie polnische Steuer- und Personenkennnummern (NIP, PESEL) werden nicht erkannt. Die Bereinigung gilt für das Widget und die angebundenen Kanäle. Sie gilt nicht für Nachrichten, die der Kunde über die REST-API direkt in ein Gespräch schreibt, und nicht für die Werte von Formularantworten, die der Kunde bewusst in einem Formular erhebt; diese werden wie übermittelt gespeichert.
• Bevor ein Gespräch für einen Antwortentwurf, eine Zusammenfassung oder eine Umformulierung für einen Agenten an das Sprachmodell geht, werden zusätzlich E-Mail-Adressen, Telefonnummern und Ziffernfolgen ab sechs Ziffern ersetzt, und Links verlieren Parameter und Anker. Namen von Agenten, Besucherkennungen und Seitenadressen werden nicht weitergegeben.
• Bilder, die der KI-Assistent ansehen soll, werden vor der Übergabe an das Modell auf 768 Pixel verkleinert und neu kodiert; eingebettete Metadaten wie EXIF-Standortdaten werden entfernt. Je Anfrage wird nur ein Bild übergeben.
• Kampagnen im Widget führen Zähler je Besucher nur unter einem Einweg-Hash der Besucher- oder Sitzungskennung, mit an die Kampagne gebundenen Fristen (ohne Enddatum höchstens 90 Tage nach der letzten Ansprache); auch der Wiederkehrer-Merker ist ein Hash. Nach einer WhatsApp-Abmeldung mit anschließendem Löschauftrag bleibt nur ein mit Schlüssel gebildeter Hash der Nummer als Sperrvermerk.
• Die Live-Besucherliste entsteht nur aus Daten, die die Sitzung ohnehin trägt. Sie zeigt nie IP-Adressen, die rohe Browserkennung, Klickkennungen von Werbenetzen oder Namen, zeigt die volle Zeile für Besucher aus dem DSGVO-Raum und mit unbekanntem Land nur mit Einwilligung und wird höchstens 90 Sekunden im Zwischenspeicher gehalten.
• Über den MCP-Server werden ohne die zusätzliche Berechtigung für Besucherdaten Namen auf Initialen gekürzt, E-Mail-Adressen maskiert, Telefonnummern auf die letzten zwei Ziffern verkürzt und Texte gefiltert; IP-Adressen von Besuchern werden nie weitergegeben.
• Auswertungen können Agenten unter Pseudonymen zeigen. Das KI-Urteil der Qualitätsprüfung wird nie einem Agenten zugerechnet; seine Eingabe durchläuft den PII-Filter, und bekannte Namen werden ersetzt.

3.2 Verschlüsselung

• Bei der Übertragung: siehe Abschnitt 4.1.
• Zugangsdaten, die der Kunde für Integrationen, Kanäle, Single Sign-on, Bot-Aktionen, Identitätsprüfung und seinen eigenen KI-Knoten hinterlegt, werden mit AES-256-GCM verschlüsselt und durch zusätzliche authentifizierte Daten an ihren Zweck gebunden. Der Schlüssel liegt in der Serverkonfiguration, außerhalb der Datenbank; er schützt gegen eine Kopie der Datenbank, nicht gegen eine Kompromittierung des Servers selbst.
• Das gemeinsame Geheimnis der Zwei-Faktor-Authentifizierung wird mit AES-256-GCM verschlüsselt, mit einem eigenen, aus demselben Serverschlüssel abgeleiteten Schlüssel und an das Konto gebunden. Vor dem 16. Oktober 2026 im Klartext gespeicherte Geheimnisse werden beim nächsten erfolgreichen Code verschlüsselt und der Klartext entfernt. Wie der Schlüssel oben schützt das gegen eine Kopie der Datenbank, nicht gegen eine Kompromittierung des Servers selbst.
• Bestelldaten, die aus dem Shop des Kunden für Antworten im Chat importiert werden, sind verschlüsselt gespeichert und verfallen nach 90 Tagen.
• Passwörter, API-Schlüssel, Sitzungskennungen (seit dem 17. Oktober 2026), Wiederherstellungscodes und Einmal-Links werden nur als Hash gespeichert (Abschnitt 2.2).
• Sicherungen verlassen den Server nur verschlüsselt (Abschnitt 5.1).
• Daten in der Datenbank und im Dateisystem sind im Übrigen im Ruhezustand nicht verschlüsselt (Abschnitt 2.1).

3.3 Datei-Anhänge

• Besucher und Agenten können im Chat Dateien anhängen. Angenommen werden Bilder (PNG, JPEG, WebP, HEIC/HEIF, SVG), PDF-, Text- und CSV-Dateien. Der Server prüft die ersten Bytes jeder Datei gegen den angegebenen Typ und weist Dateien ab, die nicht passen; SVG-Dateien werden vollständig geprüft.
• Ein Hochladen erfordert eine signierte, befristete Erlaubnis, die für genau ein Gespräch ausgestellt wird. Grenzen für Dateigröße und Gesamtspeicher gelten je Tarif (2 MB je Datei und 1 GB je Workspace im Free-Tarif, 15 MB und 50 GB in bezahlten Tarifen).
• Dateien werden außerhalb des Dokumentenverzeichnisses des Webservers gespeichert, in einem Verzeichnis je Workspace und Gespräch, mit Dateirechten, die andere Systemnutzer ausschließen. Sie werden nur über eine signierte, nicht erratbare Adresse ausgeliefert, unter einer Content Security Policy, die jeden aktiven Inhalt verbietet; Dateien, die keine Bilder sind, werden als Download angeboten.
• Dateien werden nicht auf Schadsoftware geprüft. Die Typprüfung verhindert getarnte Dateitypen, erkennt aber keinen schädlichen Inhalt innerhalb eines erlaubten Typs. Agenten sollten Anhänge mit derselben Sorgfalt behandeln wie E-Mail-Anhänge.
• Ein Textauszug aus PDF-, Text- und CSV-Dateien wird dem KI-Assistenten nur übergeben, wenn er auf die zugehörige Nachricht antwortet, höchstens 2.500 Zeichen je Nachricht und nach der Bereinigung. In Bildern erkannter Text (OCR) dient nur der Prüfung von Zahlen und der Erkennung von Bewerbungen (Abschnitt 9) und wird keinem Sprachmodell übergeben.
• Anhänge werden nach der Aufbewahrungsfrist des Tarifs des Kunden automatisch gelöscht (Free: 7 Tage, bezahlte Tarife: 90 Tage, Einzelverträge: die vereinbarte Frist) und früher zusammen mit ihrem Gespräch, Projekt oder Workspace. Die Löschung folgt nie symbolischen Verknüpfungen.

3.4 Smart Answer

• Smart Answer wird vom Answely-Dienst des Betreibers beantwortet, einem eigenen Dienst desselben Rechtsträgers auf demselben Server. Der Browser übermittelt Seitenadressen ohne Parameter und Anker; der Dienst sendet Fragen und Seitenadressen wie der Chat an die KI-Knoten. Hat der Kunde das Speichern eingeschaltet, hält er eine erzeugte Antwort (Text und Quellen, die Frage nur als Hash) 24 Stunden in einem Zwischenspeicher, um dieselbe Frage erneut zu beantworten.
• Die Frage wird auf höchstens 300 Zeichen gekürzt. Ist das Speichern ausgeschaltet, existieren Frage und Antwort nur während der Verarbeitung im Arbeitsspeicher, höchstens 180 Sekunden auf dem Weg zwischen dem Server und den KI-Knoten, und werden nicht gespeichert.
• Seine Protokolle enthalten weder Frage noch Antwort, und er schreibt keinen Eintrag ins KI-Protokoll. Jede Anfrage erzeugt einen Zählereintrag mit Zeit, gekürzter IP-Adresse (IPv4 ohne das letzte Oktett, IPv6 auf das /48-Netz), Website-Kennung, Länge der Frage und Ergebnis, der nach 7 Tagen automatisch gelöscht wird.
• Die öffentliche Schnittstelle gibt Antworten an Browser nur für die für das Projekt eingetragenen Domains frei (CORS) und begrenzt Anfragen je IP-Adresse und je Website.

4. Integrität

4.1 Weitergabekontrolle

• Alle Verbindungen zur Website, zum Dashboard, zum Widget, zur API und zum Echtzeitserver sind mit TLS 1.2 oder TLS 1.3 verschlüsselt; ältere Protokolle sind abgeschaltet. Die Zertifikate stellt Let's Encrypt aus; sie werden automatisch erneuert. HTTP Strict Transport Security wird für die Hosts der Website und des Dashboards gesendet.
• Die Anwendung sendet eine Content Security Policy mit einer zufälligen Nonce je Anfrage für Skripte, verbietet das Einbetten in Frames fremder Seiten und beschränkt Formularziele und Basisadressen. Sie sendet außerdem X-Content-Type-Options, eine Referrer-Policy und eine Permissions-Policy. Inline-Stylesheets in der Seite lässt die Richtlinie zu.
• Jede zustandsändernde Anfrage im Dashboard, im Verwaltungsbereich und auf den Anmeldeseiten ist durch ein an die Sitzung gebundenes CSRF-Token geschützt; Webhooks, Kanäle und die API werden stattdessen über eigene Signaturen oder Schlüssel authentisiert.
• Der Echtzeitserver nimmt Browserverbindungen je Projekt nur von den für dieses Projekt eingetragenen Domains an, sofern der Kunde Domains eingetragen hat. Ohne eingetragene Domains wird eine Verbindung von jeder Herkunft angenommen. Die Prüfung der Herkunft wirkt gegenüber Browsern, nicht gegenüber anderen Clients.
• Ausgehende Anfragen des Dienstes an Adressen, die ein Kunde wählt (Kanäle, Webhooks, Integrationen, Shop-Schnittstellen, Identitätsanbieter), sind gegen serverseitige Anfragefälschung (SSRF) geschützt: Der Name wird aufgelöst, jede sich ergebende Adresse muss öffentlich sein, und verbunden wird mit der geprüften Adresse. Push-Benachrichtigungen gehen nur an die Push-Dienste der Browserhersteller aus einer festen Liste von Hostnamen. Der Crawler für die Wissensbasis prüft jeden Host und jede Umleitung neu und beachtet robots.txt.
• Eigene Bot-Aktionen rufen nur HTTPS-Adressen auf Port 443 auf, deren aufgelöste Adressen alle öffentlich sind, mit festgenagelter geprüfter Adresse; Umleitungen werden nur bei lesenden Anfragen und höchstens zweimal gefolgt; die Zeitgrenze beträgt 5 Sekunden (2 Sekunden für den Verbindungsaufbau) und die Antwort höchstens 64 kB. Ihre Geheimnisse sind mit AES-256-GCM verschlüsselt. Aktionen, die etwas verändern, laufen erst nach dem Klick des Besuchers und nur einmal.
• Daten verlassen die Infrastruktur des Betreibers nur an die auf der Seite Unterauftragsverarbeiter aufgeführten Empfänger und an die Kanäle und Integrationen, die der Kunde einschaltet (Abschnitt 8).

4.2 Eingabekontrolle und Protokollierung

• Audit-Protokoll. Anmeldungen (auch über Single Sign-on), Fehlversuche, Kontoaktionen und jeder Aufruf eines MCP-Werkzeugs (ohne Inhalte) werden mit Nutzer, Workspace, Zeit, Aktion und voller IP-Adresse in ein Audit-Protokoll geschrieben. Owner und admins sehen die Änderungen ihres Workspace aus einer festen Liste, ohne IP-Adressen und ohne die Anmeldungen von Teammitgliedern, und können sie exportieren. Sie wählen seine Aufbewahrung (90, 180, 365 oder 730 Tage oder bis zur Löschung des Workspace, was die Vorgabe ist); die Frist gilt für alle Einträge des Workspace. Einträge ohne Workspace werden nach 90 Tagen gelöscht: Anmelde-, Zwei-Faktor-, Passwort- und Single-Sign-on-Ereignisse und Fehlversuche eines Kontos sowie alle Einträge, die zu keinem Konto gehören (etwa Fehlversuche mit einer E-Mail-Adresse, zu der kein Konto besteht, und Sperren von IP-Adressen), ausgenommen Löschvermerke und Handlungen des Betreibers; übrige Einträge eines Kontos bleiben bis zur Löschung des Kontos.
• Betreiberaktionen. Aktionen im Betreiber-Verwaltungsbereich (zum Beispiel Sperren, Entsperren oder Löschen von Nutzern, Ändern von Tarifen) werden protokolliert.
• Lesespur (Agency-Tarif). Sie hält fest, welcher Nutzer welches Gespräch wann und über welchen Weg (Desk, Live-Konsole, KI-Protokoll) geöffnet hat, ohne IP-Adresse und Inhalt, höchstens einmal je Nutzer, Gespräch und Weg innerhalb von zehn Minuten; Einträge werden nach 731 Tagen gelöscht. Zugriffe des Betreibers und Zugriffe über die API werden darin nicht erfasst.
• KI-Protokoll. Zu jeder KI-Antwort hält der Dienst fest, welche Quellen genutzt wurden, welche Prüfungen liefen und welches Modell und welcher Knoten geantwortet hat, ohne Kopie des Textes (Abschnitt 9).
• Änderungen an der Software. Quelltextänderungen werden in einer Versionsverwaltung geführt. Änderungen an der Entwicklungsinstallation werden direkt in deren Arbeitsverzeichnis vorgenommen und können dort wirksam sein, bevor sie eingecheckt sind. In die Produktionsinstallation werden nur eingecheckte Fassungen übertragen; das Übertragungsskript schreibt je Übertragung einen Bericht mit der Fassung, den Dateien und den Datenbankmigrationen und legt ihn bei der vor der Übertragung angelegten Sicherung ab (Abschnitt 6). Änderungen werden nicht von einer zweiten Person geprüft.
• Webserver-Protokolle. Zugriffsprotokolle enthalten IP-Adresse, Zeit, Anfrage, Referrer und Browserkennung. Sie werden täglich rotiert und höchstens 15 Tage aufbewahrt (14 Rotationen plus der laufende Tag).
• Systemjournal und Anwendungsprotokolle. Das Systemjournal enthält auch die Ausgaben des Echtzeitservers mit IP-Adressen; es ist nur nach Größe (500 MB) begrenzt, ohne Zeitfrist. Protokolle der Hintergrundprozesse des Dienstes werden derzeit nicht automatisch rotiert und haben keine Löschfrist; sie enthalten Betriebsmeldungen und in Einzelfällen IP-Adressen oder E-Mail-Adressen von Kontoinhabern.

5. Verfügbarkeit und Belastbarkeit

5.1 Sicherungen

Es gibt zwei Sicherungswege.

Serverweite Sicherung (außer Haus, verschlüsselt). Jeden Tag gegen 03:00 Uhr erstellt ein automatischer Lauf einen Abzug aller Datenbanken des Servers und ein Archiv der Webverzeichnisse, zu denen die Datei-Anhänge, Wissensbasis-Dateien und Firmenlogos des Dienstes gehören.

• Die Sicherung wird vor der Übertragung auf dem Server verschlüsselt (rclone crypt); auch Datei- und Verzeichnisnamen werden verschlüsselt. Die Schlüssel bleiben auf dem Server; der Speicheranbieter erhält nur verschlüsselte Blöcke.
• Sie wird zu Google Cloud Storage übertragen, Bucket in der Region europe-central2 (Warschau, Polen); Anbieter Google Cloud EMEA Limited, Dublin (siehe Unterauftragsverarbeiter, Abschnitt 2.1).
• Aufbewahrung: tägliche Kopien 7 Tage, die wöchentliche Kopie (Sonntag) 364 Tage. Ab Tag 10 werden die Kopien in eine kältere Speicherklasse verschoben.
• Dieselbe Sicherung liegt zusätzlich etwa 8 Tage auf einem am Server angeschlossenen Laufwerk. Diese lokale Kopie ist nicht verschlüsselt; sie ist durch die Dateirechte des Servers und die physischen Maßnahmen geschützt (Abschnitt 2.1).

Datenbanksicherung des Dienstes. Jeden Tag um 03:05 Uhr schreibt ein zweiter Lauf einen komprimierten Abzug der Datenbank des Dienstes auf die Systemplatte des Servers, nur für den Eigentümer lesbar, und bewahrt ihn 30 Tage auf. Er ist nicht verschlüsselt und enthält keine Dateien.

Folgen. Im Live-System gelöschte Daten bleiben in Sicherungen bis zu deren Ablauf: höchstens 364 Tage in den wöchentlichen Kopien außer Haus, höchstens 30 Tage in den lokalen Datenbankabzügen. Gezieltes Löschen innerhalb einer Sicherung findet nicht statt, weil jede Kopie ein versiegeltes Abbild eines Zeitpunkts ist. Sicherungen dienen nur der Wiederherstellung nach einem Verlust; sie werden nicht durchsucht, ausgewertet oder herausgegeben. Muss eine Sicherung eingespielt werden, wird der Betreiber die nach dem Datum der Kopie ausgeführten Löschungen erneut ausführen, bevor der Dienst in den Normalbetrieb zurückkehrt (Abschnitt 6).

5.2 Schutz vor Missbrauch und Überlastung

• Der Echtzeitserver begrenzt jede Verbindung: Rahmen höchstens 64 KiB, 120 Rahmen und 20 Nachrichten je 10 Sekunden, 3 Verbindungen je Sitzung, 1.000 Verbindungen insgesamt, 5 Sekunden zur Anmeldung nach dem Verbindungsaufbau; Nachrichten, die länger sind, als der Tarif erlaubt (1.000 Zeichen im Free-Tarif, sonst 4.000), werden abgewiesen. Er kann auffällige IP-Adressen und Besucherkennungen automatisch befristet sperren; der Betreiber führt manuelle Sperrlisten.
• Agenten können einen missbräuchlichen Besucher mit dem Befehl /ban im Desk für bis zu 365 Tage sperren (Vorgabe 24 Stunden). Die Sperre erfasst die Kennung und die IP-Adresse des Besuchers (bei IPv6 das ganze /64-Netz, das weitere Geräte desselben Anschlusses umfassen kann); die IP-Sperre gilt für den Echtzeitserver insgesamt, nicht nur für die Website des Kunden.
• Der KI-Assistent hat ein Budget je Website und Minute und eine Grenze je Gespräch und Tarif; darüber hinaus erhält der Besucher eine feste Nachricht statt einer KI-Antwort.
• Der Webserver begrenzt Größe und Lesezeit von Anfragen; fail2ban sperrt Adressen, die nach Geheimnissen suchen oder übergroße Anfragen senden, für eine Stunde.
• Der Betreiber kann die KI global oder je Projekt sofort abschalten (Not-Aus) und jede von 24 Funktionen je Projekt abschalten (zum Beispiel Uploads, Übersetzung, Anrufe, Kampagnen).

5.3 Überwachung

• Eine Zustandsprüfung läuft jede Minute für die Umgebung, in der der Dienst läuft. Sie prüft die Bestandteile des Dienstes, darunter die Website und die KI-Knoten, und alarmiert den Betreiber bei einem Zustandswechsel per Telegram. Alarme enthalten nur Komponentennamen und Betriebszahlen, keine personenbezogenen Daten.
• Betriebsalarme umfassen unter anderem nicht erreichbare KI-Knoten, einen hohen Anteil abgewiesener KI-Anfragen, den Not-Aus, die Zahl der Echtzeitverbindungen, Last und Speicher des Servers sowie die Zahl schwerer Fehler.
• Eine öffentliche Statusseite zeigt den gemessenen Zustand mit einem Verlauf von 90 Tagen.
• Die Prüfung läuft auf dem Server, den sie überwacht. Einen Totalausfall dieses Servers oder des Internetanschlusses kann sie nicht melden; solche Ausfälle bemerkt ein Mensch.

6. Wiederherstellbarkeit

• Systeme und Daten können aus den Sicherungen in Abschnitt 5.1 wiederhergestellt werden: die Datenbank aus dem täglichen Abzug (lokal oder außer Haus), Dateien aus der Kopie außer Haus. Verfahren für Wiederherstellung und Notfälle sind intern dokumentiert.
• Eine Übertragung in die Produktionsinstallation startet der Betreiber von Hand auf dem Server, unter einem anderen Benutzerkonto als dem des Webservers; der Webserver-Prozess selbst hat kein Schreibrecht auf die Programmdateien der Produktionsinstallation. Das Skript exportiert eine feste, eingecheckte Fassung (nicht das Arbeitsverzeichnis der Entwicklungsinstallation), sichert zuerst die Programmdateien, die Datenbank und die geplanten Aufgaben der Produktionsinstallation, wendet dann die Datenbankmigrationen an und kopiert eine feste Liste von Dateien; beim ersten Fehler bricht es ab. Die ersetzten Programmdateien lassen sich mit einem Befehl wiederherstellen; Änderungen an der Datenbank sind additiv und werden vorwärts korrigiert, die Datenbank selbst lässt sich aus der vor der Übertragung angelegten Sicherung wiederherstellen. Die frühere Übertragung per Auftrag im Betreiberbereich wird nicht mehr genutzt.
• Bevor der Dienst nach einer Wiederherstellung in den Normalbetrieb zurückkehrt, führt der Betreiber die nach dem Datum der eingespielten Kopie vorgenommenen Löschungen erneut aus, einschließlich der Löschwünsche von Besuchern sowie gelöschter Workspaces und Konten. Seit dem 16. Oktober 2026 wird dafür jede anlassbezogene Löschung – Löschwunsch oder Widerruf eines Besuchers, Löschung eines Workspace, Projekts oder Kontos – bei ihrer Ausführung in einem Löschjournal außerhalb der Datenbank festgehalten (Art, Kennungen, Modus und Zeitpunkt, ohne Inhalte, Adressen oder IP-Adressen; 400 Tage aufbewahrt), und ein Skript führt die festgehaltenen Löschungen mit denselben Funktionen erneut aus; Löschungen nach Fristen holen sich beim nächsten Lauf selbst ein. Nicht erfasst: nach dem Datum der Kopie beantragte Löschungen, deren Karenz von 30 Tagen noch lief, und, geht der Server selbst verloren, die Löschungen nach der letzten Sicherung des Journals (bis zu 24 Stunden).
• Eine Wiederherstellungszeit wird nicht zugesagt, und regelmäßige Wiederherstellungstests sind noch nicht dokumentiert.

7. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung

7.1 Überprüfung dieser Maßnahmen

• Der Betreiber überprüft diese TOM, wenn sich Infrastruktur, Unterauftragsverarbeiter oder Dienst wesentlich ändern, und mindestens einmal jährlich.
• Aktualisierungen senken das Schutzniveau nicht. Die aktuelle Fassung ist auf dieser Seite veröffentlicht; der AVV verweist auf die zum Zeitpunkt der Verarbeitung gültige Fassung.
• Der Quelltext enthält automatisierte Prüfstände, unter anderem für die Rechtematrix, die Zwei-Faktor-Authentifizierung und den Missbrauchsschutz.
• Dieses Dokument nimmt auf keine unabhängige Zertifizierung und keinen externen Penetrationstest Bezug. Wird künftig einer durchgeführt, wird er hier aufgeführt.

7.2 Verletzungen des Schutzes personenbezogener Daten

• Der Betreiber unterhält ein schriftliches Verfahren für Datenschutzverletzungen. Es umfasst Erkennung, Bewertung, Eindämmung, Meldung und Dokumentation und behandelt neben der Offenlegung auch Verlust und Veränderung von Daten als Verletzung.
• Eine Verletzung, die Kundendaten betrifft, wird dem Kunden unverzüglich und spätestens 48 Stunden, nachdem der Betreiber davon Kenntnis erlangt hat, gemeldet, damit der Kunde seine eigene 72-Stunden-Frist nach Art. 33 DSGVO einhalten kann. Die Meldung geht an die E-Mail-Adresse des Kontoinhabers (owner) und enthält, soweit bekannt, die in Art. 33 Abs. 3 DSGVO genannten Angaben; der Rest folgt schrittweise.
• Jede Verletzung und jede Bewertung, die zu dem Ergebnis kommt, dass keine vorlag, wird mit ihren Auswirkungen und den ergriffenen Maßnahmen dokumentiert.

7.3 Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen

• Ohne Einwilligungssignal läuft das Widget im Grundmodus (Abschnitt 3.1). Mit der Einwilligungsstufe „Pflicht" sendet das Widget Seitenkontext, Seitentext und die vom Kunden übergebenen Angaben erst nach der Einwilligung.
• Der Besucher kann seine Daten im Widget löschen („Ihre Daten", „Alles löschen"), seine Einwilligung widerrufen und schriftlich um Löschung bitten; der Server bearbeitet diese Anfragen innerhalb weniger Minuten.
• Für Gespräche ist keine automatische Löschfrist voreingestellt. Der Kunde legt sie je Projekt fest (0 bis 3.650 Tage, wobei 0 keine Grenze bedeutet) und wählt, ob abgelaufene Gespräche gelöscht oder anonymisiert werden. Der Betreiber kann eine Höchstfrist für alle Projekte festlegen.
• Die Bereinigung läuft automatisch vor der Speicherung auf dem Server; sie hängt nicht von Besuchern oder Agenten ab (mit den Ausnahmen in Abschnitt 3.1).

7.4 Organisation

• Die Verantwortung für Datenschutz und Informationssicherheit liegt beim Inhaber des Betreibers persönlich. Es gibt kein eigenes Sicherheitsteam und keine Funktionstrennung; der Betreiber sagt das, damit Kunden es berücksichtigen können.
• Personen, die zum Zugriff auf Kundendaten befugt sind, sind zur Vertraulichkeit verpflichtet.
• Verfahren für Verletzungen, Wiederherstellung, Notfälle und Auslieferung sind intern dokumentiert.
• Fragen zu diesen Maßnahmen und Meldungen von Sicherheitsproblemen: contact@lukaswojcik.com.

8. Kontrolle der Auftragsverarbeitung (Auftragskontrolle)

• Der Betreiber verarbeitet Kundendaten nur nach den Weisungen des Kunden, wie im AVV festgelegt; die Einstellungen, die der Kunde im Dashboard wählt, sind Teil dieser Weisungen.
• Der Betreiber setzt nur die auf der Seite Unterauftragsverarbeiter aufgeführten Unterauftragsverarbeiter ein. Jeder ist durch einen Vertrag mit Datenschutzpflichten nach Art. 28 Abs. 4 DSGVO gebunden. Änderungen werden 30 Tage im Voraus angekündigt; der Kunde kann widersprechen.
• Kanäle und Integrationen, die der Kunde mit eigenen Konten und Zugangsdaten einschaltet, senden Daten auf Weisung des Kunden an dessen eigene Anbieter. Nur owner und admins können sie einschalten. Sie liegen außerhalb der Unterauftragsverarbeiter-Kontrolle des Betreibers.
• Bindet der Kunde einen eigenen KI-Knoten an, gehen Gesprächsinhalte für KI-Anfragen an diesen Knoten und an das Modell, das der Kunde dort betreibt; dieser Knoten ist ein eigener Auftragsverarbeiter des Kunden.

9. Maßnahmen für die KI-Funktionen

• Nur eigene Modelle. Die Sprachmodelle der eigenen KI des Betreibers (ein Chatmodell auf den Knoten der zweiten Stufe und ein weiteres als Reserve auf dem Knoten der ersten Stufe, jeweils Instruktionsfassung, auf 4 Bit quantisiert) und ihr Einbettungsmodell sind offen lizenzierte Modelle, die selbst gehostet und unverändert auf den KI-Knoten des Betreibers im lokalen Netz laufen. Kein KI-Dienst eines Dritten erhält Kundendaten.
• Register der Knoten, im Zweifel geschlossen. Nur Knoten, die in einem Register eingetragen und aktiviert sind, erhalten KI-Aufträge. Ein nicht eingetragener Knoten wird abgewiesen; ist das Register nicht lesbar, erhält kein Knoten Arbeit.
• Kein Training. Kundendaten werden nicht zum Training oder Feinjustieren von Modellen verwendet. Einzelne Anfragen können intern verwendet werden, um Modellfassungen vor einer Aktualisierung zu vergleichen; sie werden nicht zum Training verwendet und nicht weitergegeben.
• Menschliche Aufsicht und Schalter. Der Kunde kann den KI-Assistenten je Projekt abschalten. Sobald ein Agent übernimmt, schweigt der Assistent. Findet der Assistent keine verlässliche Grundlage, übergibt er an einen Menschen. Der Betreiber hat einen globalen Not-Aus und einen je Projekt (Abschnitt 5.2).
• Kennzeichnung. Das Widget teilt Besuchern vor der ersten KI-Nachricht mit, dass sie mit einer KI-Assistenz chatten, und kennzeichnet jede KI-Nachricht mit dem Abzeichen „KI". Der Kunde darf diese Kennzeichnung nicht entfernen oder verdecken (AVV Ziffer 13).
• Prüfungen vor und nach dem Modell. Anfragen, die den Assistenten für fremde Aufgaben einsetzen wollen, werden vor dem Modellaufruf durch Regeln erkannt; Antworten werden auf Code und auf Aussagen geprüft, die den Quellen widersprechen (zum Beispiel Wochentage, Zahlen, „kostenlos"). Manche Funktionen nutzen gar kein Modell: Löschwünsche, Fragen zur Datenspeicherung und die Einrichtungsvorschläge werden nach festen Regeln beantwortet.
• Keine Verarbeitung von Bewerbungen. Bewerbungen werden vor jedem Modellaufruf anhand fester Muster in Text, Anhängen und Dateinamen erkannt – im Chat, in Smart Answer, im KI-Urteil der Qualitätsprüfung und der Testläufe, in den Entwürfen zu Wissenslücken und im Support-Assistenten; das Gespräch erhält dann keinen weiteren Modellauftrag außer der Übersetzung, ein KI-Urteil oder Antwortvorschlag wird nicht angefordert. Eine Anweisung am Anfang jedes Systemtextes, außer bei Übersetzungen, ist die zweite Schranke. Dateinamen werden unabhängig von Leerzeichen, Unterstrichen, Bindestrichen, Punkten, Groß- und Kleinschreibung, Großbuchstaben im Wortinneren und Akzenten an jeder Stelle des Namens erkannt („Lebenslauf Anna.pdf“, „AnnaLebenslauf.pdf“), auch wenn sie nur als Text geschrieben sind; kurze Wörter wie „CV“, „Resume“ oder „Zeugnis“ zählen nur als eigenes Wort, und in einem Text gelten das Wort mit der Dateiendung und bis zu vier Wörter davor als Dateiname. Die Erkennung kann Bewerbungen übersehen, deren Wortlaut oder Dateinamen sie nicht kennt; dann bleibt die Anweisung an das Modell als zweite Schranke. Einen Schalter gibt es nicht.
• Keine KI-Bewertung von Teammitgliedern. Das KI-Urteil der Qualitätsprüfung wird nur für Gespräche ohne menschliche Beteiligung abgegeben und nie einem Agenten zugerechnet; Auswertungen je Agent sind regelbasiert.
• Wissensbasis. Der Assistent antwortet aus der Wissensbasis, die der Kunde liefert, und kann, wo er dort nichts findet, aus Allgemeinwissen antworten. Inhalte der Wissensbasis und der Seiten des Kunden gehen so an das Modell, wie sie geliefert werden; der Dienst filtert sie nicht auf eingebettete Anweisungen. Der Kunde bestimmt, was sie enthält.
• Auftragsdatensätze. Der Datensatz eines KI-Auftrags enthält die Anweisung und den Gesprächstext. Er wird zusammen mit seinem Gespräch gelöscht; Datensätze ohne Gespräch werden nach 30 Tagen gelöscht. Aufträge mit Bestelldaten, Bot-Aktionen, Simulationen, der Routing-Einordnung, dem KI-Urteil der Qualitätsprüfung sowie Antwortentwürfe, Zusammenfassungen, Umformulierungen und Übersetzungen für Agenten sind als vertraulich markiert und werden geleert, sobald das Ergebnis geliefert ist, sonst nach etwa zehn Minuten. Das KI-Protokoll enthält keinen Text (Abschnitt 4.2).
• Einbettungen der Wissensbasis liegen 30 Tage im Zwischenspeicher des Servers und werden bei Änderungen der Wissensbasis neu aufgebaut.

10. Stand und Fassung

Dieses Dokument ist in englischer Sprache abgefasst. Übersetzungen ins Deutsche (/p/technische-und-organisatorische-massnahmen) und Polnische (/p/srodki-techniczne-i-organizacyjne) dienen der Verständlichkeit; die englische Fassung geht vor.

Fassung 2.0 ersetzt Fassung 1.4 vom 7. Oktober 2026. Geändert: Das Dokument ist nach den Kategorien des Art. 32 DSGVO neu gegliedert und um Zugang und Zugriff, Verschlüsselung, Überwachung, Wiederherstellung, Auftragskontrolle und KI-Maßnahmen erweitert; die Sicherung außer Haus bei Google Cloud Storage mit wöchentlichen Kopien bis 364 Tage ersetzt die Aussage „Sicherungen bis 30 Tage, kein Hyperscaler"; Aussagen, die nicht dem Betrieb entsprachen, wurden entfernt oder berichtigt (SSH nur mit benannten Schlüsseln, physisch getrennte Entwicklung und Produktion, verpflichtende E-Mail-Bestätigung, IP-Sperren durch Kunden im Dashboard, Löschung der Texte von KI-Aufträgen nach etwa zehn Minuten, Bereinigung ohne Ausnahmen, Bildverkleinerung vor dem Hochladen); Grenzen werden genannt (keine Datenträgerverschlüsselung, keine Virenprüfung, keine Funktionstrennung).

Fassung 2.1 ersetzt Fassung 2.0 vom 11. Oktober 2026. Geändert: Datenminimierung bei Kampagnen, Live-Besucherliste, MCP und Auswertungen (3.1); Grenzen für eigene Bot-Aktionen (4.1); Audit-Protokoll mit Single Sign-on und MCP-Aufrufen (4.2); Sperre für Bewerbungen und keine KI-Bewertung von Teammitgliedern (9).

Fassung 2.2 ersetzt Fassung 2.1 vom 11. Oktober 2026. Berichtigt: Eine getrennte Produktionsumgebung gibt es noch nicht, der Dienst läuft in seiner Entwicklungsinstallation (1, 2.4, 4.2, 5.3, 6); SSH mit Passwortanmeldung, fail2ban für SSH unwirksam (2.2); Grenzen von reCAPTCHA (2.2); Bereinigung von Telefonnummern und Kennungen, Systemjournal mit IP-Adressen (3.1, 4.2); OCR auch zur Erkennung von Bewerbungen (3.3); Smart Answer über Answely mit 24-Stunden-Zwischenspeicher für Antworten (3.4); Push-Dienste aus einer festen Hostliste (4.1); Audit-Einträge ohne Konto werden nicht gelöscht (4.2); /ban bei IPv6 je /64-Netz, fail2ban eine Stunde (5.2); vertrauliche Aufträge der KI-Werkzeuge für Agenten (9).

Fassung 2.3 ersetzt Fassung 2.2 vom 12. Oktober 2026. Berichtigt: Zähler von Smart Answer mit gekürzter IP-Adresse, Fragelänge und Höchstdauer unterwegs (3.1, 3.4); Chatmodelle der eigenen KI des Betreibers mit einem Reservemodell (9); Sperre für Bewerbungen auf allen Modellwegen außer der Übersetzung (9); Fristen vom 16. Oktober 2026: abgelaufene Sitzungen und Token gelöscht (2.2), Audit-Einträge ohne Workspace nach 90 Tagen gelöscht (4.2). Ergänzt am 16. Oktober 2026: Land für die Live-Funktionen aus der IP-Adresse abgeleitet (3.1); als Text geschriebene Dateinamen (9). Weiter ergänzt am 16. Oktober 2026: zweiter Faktor für den Betreiber-Verwaltungsbereich Pflicht (2.2); verschlüsseltes Geheimnis der Zwei-Faktor-Authentifizierung (2.2, 3.2); Löschjournal für die erneute Ausführung von Löschungen nach einer Wiederherstellung (6); Dateinamen unabhängig von Leerzeichen und anderen Trennzeichen, Schreibweise und Akzenten erkannt (9).

Fassung 2.4 ersetzt Fassung 2.3 vom 16. Oktober 2026. Geändert: Sitzungskennungen nur als SHA-256-Hash in der Datenbank (2.2, 3.2).

Fassung 2.5 ersetzt Fassung 2.4 vom 17. Oktober 2026. Geändert: Die KI wird einheitlich als eigene, selbst gehostete KI des Betreibers bezeichnet; Modell- und Softwarenamen entfernt, die Tatsachen sind unverändert (9).

Fassung 2.6 ersetzt Fassung 2.5 vom 17. Oktober 2026. Berichtigt: Eine Übertragung in die Produktionsinstanz sichert den ersetzten Stand nicht und spielt ihn nicht automatisch zurück; wie eine solche Übertragung beauftragt und ausgeführt wird und dass sie derzeit gesperrt ist (6).

Fassung 2.7 ersetzt Fassung 2.6 vom 18. Oktober 2026. Geändert: die getrennte Produktionsinstallation mit eigenem Datenbanknutzer, eigener Redis-Datenbank und eigenen KI-Worker-Instanzen (1, 2.4); Übertragungen in die Produktionsinstallation nur eingecheckter Fassungen, von Hand, mit vorheriger Sicherung und Wiederherstellung der Programmdateien (4.2, 6); das Verzeichnis von Verarbeitungstätigkeiten und die Datenschutz-Folgenabschätzung sind auf Anfrage erhältlich statt veröffentlicht (1).

Fassung 2.7 – gültig ab 19. Oktober 2026.