Technische und organisatorische Maßnahmen

Maßnahmen nach Art. 32 DSGVO, die LW IT Solutions Company Lukas Wójcik für Answely umsetzt. Dieses Dokument ist Anlage 2 zum Auftragsverarbeitungsvertrag und beschreibt zugleich die Maßnahmen für die Daten, für die der Betreiber selbst verantwortlich ist.

1. Geltungsbereich und Grundsatz

Die Maßnahmen gelten für alle Teile von Answely: die Website answely.com und das Kundenkonto, den Antwort-Dienst unter api.answely.com, das Skript answely.js, den Indexer, die Rechner mit Sprachmodell und Einbettungsmodell sowie Sicherungen und Überwachung.

Betreiber: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, USt-IdNr. PL7252266190.

Grundsatz: Was hier steht, ist umgesetzt und im Code oder in der Konfiguration belegt. Wo etwas vorbereitet, aber noch nicht in Betrieb ist oder bewusst fehlt, steht das ausdrücklich da, statt es zwischen den Zeilen anzudeuten. Die Zahlen in diesem Dokument gleicht eine automatische Prüfung bei jeder Änderung gegen Code und Konfiguration ab.

Die Maßnahmen beschreiben den Stand, mit dem Answely in Betrieb geht: geprüft in der Entwicklungsumgebung und in die Konfiguration der Produktion übernommen. Wo sich Entwicklung und Produktion unterscheiden, steht es dabei.

2. Vertraulichkeit

2.1 Zutrittskontrolle

Answely läuft auf eigener Hardware in Łódź, Polen. Ein Rechenzentrums-, Cloud- oder Hostinganbieter ist am Betrieb nicht beteiligt. Web, Konto-App, Antwort-Dienst, Datenbanken und Redis laufen auf einem eigenen Server hinter einem eigenen Router; das Sprachmodell – unsere eigene KI, selbst gehostet – läuft auf zwei eigenen Servern, das Einbettungsmodell ebenfalls auf eigenen Rechnern, alle im selben internen Netz und am selben Ort. Auf derselben Hardware betreibt der Betreiber weitere eigene Dienste (unter anderem MousePlayer und reactive.chat).

Die Server werden im Eigenbetrieb in geschlossenen Räumlichkeiten in Łódź betrieben. Zutritt hat ausschließlich der Inhaber selbst. Der Raum ist mit Schlüssel abgesperrt und videoüberwacht; weitere Personen – auch Vermieter oder Reinigungsdienste – haben keinen Zutritt. Die genaue Anschrift des Standorts wird bewusst nicht genannt.

2.2 Zugangskontrolle

• Zugang zum Konto nur mit persönlichem Benutzerkonto und Passwort. Passwörter werden nur als gesalzener Hash mit dem Standardverfahren von PHP gespeichert, nie im Klartext.
• Nach mehreren Fehlversuchen wird die Anmeldung von derselben Adresse vorübergehend gesperrt (Vorgabe: 8 Fehlversuche in 15 Minuten, im Administrationsbereich einstellbar). Eine erfolgreiche Anmeldung setzt den Zähler der Fehlversuche zurück. Zusätzlich reserviert jeder Anmeldeversuch vor der Passwortprüfung atomar einen Versuch je Konto (Vorgabe 8 in 15 Minuten, auch erfolgreiche Versuche, ohne Rücksetzung) und je IP-Adresse (das Zehnfache, mindestens 80); Zwei-Faktor-Codes sind auf 10 Versuche je Konto in 15 Minuten begrenzt. Diese Begrenzung speichert nur HMAC-Schlüssel, keine E-Mail- oder IP-Adresse im Klartext. Registrierungen haben ein eigenes Fenster je IP-Adresse mit denselben Grenzen. Ist der Speicher der Begrenzung nicht verfügbar, wird die Anmeldung abgelehnt (HTTP 503), nicht ungebremst zugelassen.
• Die öffentlichen Formulare (Anmeldung, Registrierung, „Passwort vergessen?“, „Neues Passwort wählen“, Support, Schnellcheck) prüft zusätzlich der eigene Formularschutz formconfirmed: Rechennachweis im Browser, einmal verwendbares Prüfzeichen, Falle für Programme, Browser-Signale, Abgleich mit Rechenzentrumsnetzen, Prüfung der E-Mail-Domain, beim Support ein Spam-Vorfilter mit Sprachmodell auf eigenen KI-Rechnern in der EU und eine websiteübergreifende Kampagnenerkennung mit nicht umkehrbaren Fingerabdrücken (30 Tage). Abgelehnt wird bei „sperren“; bei „markieren“ nur nach einer zweiten Stufe (Bestätigen-Knopf, aufwendigere Aufgabe, erneute Prüfung muss „zulassen“ ergeben). Ist formconfirmed nicht erreichbar oder die Antwort unklar, wird die Einsendung abgelehnt und kann wiederholt werden; ein stilles Durchlassen gibt es nicht. Die übrigen Sperren gelten weiter.
• „Passwort vergessen?“: höchstens 3 Rücksetzlinks je Adresse und Stunde und 10 je Tag (pseudonymisierte Zähler, gelten auch bei Ausfall von formconfirmed) und ein Beleg je Absendung, damit eine Wiederholung keinen zweiten Link auslöst.
• Zwei-Faktor-Anmeldung (TOTP) steht jedem Konto zur Verfügung. Für den Administrationsbereich ist sie Pflicht; Wiederherstellungscodes werden nur als Hash gespeichert. Abschalten lässt sich die Pflicht nur in der Serverkonfiguration, nicht über die Anwendung.
• Sitzungscookies sind HttpOnly, Secure und SameSite=Lax; die Sitzungskennung wird bei der Anmeldung neu vergeben. Kunden sehen ihre Sitzungen in den Einstellungen und können sie beenden.
• Jede schreibende Aktion im Konto trägt ein CSRF-Merkmal. Ausgenommen ist nur das Abmelden, das über einen einfachen Link ohne Merkmal läuft.
• Die Serververwaltung erfolgt per SSH, nur durch den Inhaber oder in seinem Auftrag. Es gibt keine gemeinsam genutzten Konten. Von außen ist am SSH-Zugang des Servers nur die Anmeldung mit Schlüssel möglich; mit Passwort nur aus privaten Netzen wie dem eigenen lokalen Netz (seit 16.10.2026).
• Die Entwicklungsumgebung ist nur hinter einem Vorschauschutz erreichbar; ohne Zugang antwortet sie mit „nicht berechtigt“.
• Geheimnisse (Datenbank, Redis, Token, Schlüssel) liegen in Konfigurationsdateien mit eingeschränkten Rechten außerhalb des öffentlich erreichbaren Bereichs, nie im Quellcode. Ein Abruf dieser Dateien über das Web wird abgewiesen.

2.3 Zugriffskontrolle

• Arbeitsbereiche haben Mitglieder mit Rollen; was ein Mitglied sehen und ändern darf, prüft der Server, nicht nur die Oberfläche. Löscht ein Eigentümer sein Konto, gehen Arbeitsbereiche mit weiteren Mitgliedern vorrangig an den am längsten beteiligten Administrator, sonst an das am längsten beteiligte Mitglied über.
• Jede Abfrage im Konto ist an den Arbeitsbereich des anfragenden Kontos gebunden; eine fremde Site ist auch mit bekanntem Schlüssel nicht verwaltbar.
• Die Verwaltungsschnittstelle des Antwort-Dienstes ist nur über die lokale Schleife des Servers erreichbar, nie über den vorgeschalteten Webserver. Für den Abgleich mit reactive.chat kann sie zusätzlich an eine Adresse im verschlüsselten internen Netz (WireGuard) gebunden werden und nimmt dort nur Verbindungen von einer festen Liste von Adressen an. In jedem Fall ist ein Token nötig, das zeitkonstant verglichen wird; ohne ein ausreichend langes Token bleibt sie aus.
• Push-Token werden beim Betreiber nur als SHA-256-Hash gespeichert und zeitkonstant geprüft; sie gelten nur für ihre Site und nur für Adressen auf Hosts mit nachgewiesener Inhaberschaft.
• Die Rechner mit den KI-Modellen erhalten Aufträge nur über signierte Abrufe (HMAC-SHA256 mit einem Geheimnis von mindestens 32 Zeichen, Zeitstempel, der höchstens fünf Minuten von der Uhr des Servers abweichen darf). Unsignierte oder falsch signierte Abrufe werden abgewiesen, bevor ein Auftrag herausgegeben wird.
• Antwort-Dienst und Indexer laufen unter einem eigenen Systemnutzer ohne Anmeldemöglichkeit (answely-dienst) und mit gehärteten Einstellungen (kein Rechtegewinn, privates Temp-Verzeichnis, schreibgeschütztes System, kein Zugriff auf Home-Verzeichnisse). Für die Produktion sind eigene Nutzer vorbereitet – answely-dienst-live für den Dienst und answely-web für die Konto-App in einem eigenen PHP-Pool –, aber noch nicht eingerichtet. In der Entwicklungsumgebung läuft die Konto-App im gemeinsamen PHP-Pool des Webservers.
• Für die Konto-App der Produktion ist vorbereitet, dass sie nur ihren eigenen Programmbaum, ihr Arbeitsverzeichnis und ihren Datenordner lesen darf (open_basedir); die Dateien anderer Dienste auf demselben Server, einschließlich ihrer Konfiguration, wären für sie dann nicht erreichbar. In der Entwicklungsumgebung gilt diese Grenze nicht.
• Redis: Answely nutzt einen eigenen ACL-Nutzer, der nur Schlüssel mit dem Präfix seiner Umgebung sieht (in der Entwicklung zusätzlich das Präfix der Prüfstände) und keine gefährlichen Befehle ausführen darf (etwa alles löschen oder die Konfiguration ändern). Das Passwort des Standardnutzers erhält der Dienst nicht.
• Datenbanken: getrennte Datenbanken für Konto-App und Antwort-Dienst mit getrennten Nutzern, die nur lokal auf dem Server zugelassen sind; Answely verbindet sich zu Datenbank und Redis nur über die lokale Schleife. Datenbankserver und Redis lauschen zusätzlich auf der Adresse des Servers im internen Netz, weil andere Dienste desselben Betreibers sie nutzen; die Firewall des Servers lässt dort nur einen der KI-Rechner zur Datenbank durch und niemanden zu Redis. Auch der Verwaltungsnutzer der Datenbank mit Rechten auf alle Datenbanken ist nur lokal auf dem Server zugelassen.

2.4 Trennungskontrolle

• Jede Site hat einen eigenen Schlüssel, eigene Einstellungen und einen eigenen Index. Antworten entstehen nur aus dem Index der Site, auf der gefragt wird; die Trennung je Mandant ist durch Prüfungen mit echter Datenbank belegt.
• Die Antwortbox antwortet nur für Hosts, deren Inhaberschaft der Kunde nachgewiesen hat (CORS je Site). Schlägt der Nachweis dauerhaft fehl, schaltet sich die Box für diese Site ab.
• Kandidat und vorheriger Index einer Indexfreigabe haben interne, aus dem Schlüssel der Site abgeleitete Kennungen und sind keine öffentlich ansprechbaren Sites.
• Entwicklung und Produktion laufen in getrennten Installationen mit getrennten Datenbanken, getrennten Redis-Präfixen und getrennten Systemnutzern. Die Entwicklung arbeitet mit eigenen Demo- und Testdaten, nicht mit Kundendaten.
• Die Rechner mit den KI-Modellen dienen auch weiteren eigenen Diensten des Betreibers (unter anderem reactive.chat, Stats4U und MousePlayer). Aufträge von Answely holt ein eigener Worker mit eigenem Geheimnis ab; Answely sendet den Sprachmodellen nur Text, obwohl der Bildteil der Modellsoftware eingeschaltet ist.
• Die Dateien der Firmenlogos liegen außerhalb des Programmbaums und jedes öffentlichen Verzeichnisses.

3. Pseudonymisierung und Datenminimierung

• Kein Cookie, keine Kennung: Das Skript answely.js setzt keine Cookies, erzeugt keine Besucherkennung und lädt keine Schriften, Bilder oder Skripte von Dritten. Es sendet nur Frage, Sprache und die Adressen der aktuellen und der verweisenden Seite, beide ohne Parameter und Anker; der Server schneidet Parameter und Anker zusätzlich ab.
• „Antwort-Cache erlauben“ aus als Vorgabe: In der Grundeinstellung neuer Websites werden Fragen und Antworten nicht gespeichert („Antwort-Cache erlauben“ aus). Alle zuschaltbaren Funktionen sind für neue Sites ausgeschaltet.
• Einwilligungsmodus: Steht data-consent="required" im Einbettungscode, sendet der Browser vor der Zustimmung des Besuchers keine Anfrage an Answely, nicht einmal für die Einstellungen der Box. Schaltet der Kunde den Modus nur im Konto ein, lädt die Box vorher ihre Einstellungen und wartet erst mit der Frage.
• Gekürzte IP-Adressen: Zähler, Zugriffsprotokoll des Webservers und Seitenstatistik speichern IP-Adressen nur gekürzt: IPv4 ohne letztes Oktett, IPv6 auf /48. Das Zugriffsprotokoll enthält zusätzlich weder Parameter noch Browser noch verweisende Seite.
• Missbrauchsschutz ohne IP-Adresse: Er arbeitet mit einem Hash aus IP-Adresse und einem täglich wechselnden Zufallswert. Der Hash lebt höchstens 2 Minuten, der Zufallswert höchstens 2 Tage; die IP-Adresse selbst wird dafür nicht gespeichert.
• Formularschutz pseudonym: formconfirmed speichert keine IP-Adresse, sondern nur einen Hash des gekürzten Adressbereichs mit täglich wechselndem Schlüssel (höchstens 1 Stunde), von der E-Mail-Adresse nur das Ergebnis zur Domain (höchstens 7 Tage); Nachrichtentexte werden nur im Arbeitsspeicher geprüft. Das Passwort geht nie an formconfirmed.
• Keine Inhalte in Protokollen: Frage und Antwort erscheinen in keinem Protokoll des Antwort-Dienstes, des Indexers, der KI-Worker oder des Webservers; protokolliert werden nur Arten, Codes und Zahlen. Die KI-Modelle laufen ohne Protokollierung von Anfragen.
• Frageanalyse maskiert: Ist sie eingeschaltet, werden E-Mail-Adressen, Telefonnummern, IBAN-ähnliche Ziffernfolgen, Links und lange Zahlen vor dem Speichern unkenntlich gemacht; gespeichert wird ohne IP-Adresse, ohne Kennung und mit Kalendertag statt Uhrzeit.
• Nur Gruppen: Die Frageanalyse zeigt dem Kunden nur Gruppen ab zwei Fragen.
• Geschützte Bereiche (vorbereitet): Zugriffstoken werden lokal geprüft; ihre Angaben werden weder gespeichert noch an das Sprachmodell gegeben.
• Belege statt Kennungen: Erfolgsmeldungen und A/B-Vergleich arbeiten mit zufälligen Antwortkennungen und signierten Belegen, nicht mit Besucherprofilen.
• Lokale Ableitung des Landes: Das Land in der Seitenstatistik wird aus einer lokalen Datenbankdatei abgeleitet; an einen Geodienst geht keine IP-Adresse.

4. Integrität

4.1 Transportkontrolle

• Alle öffentlichen Endpunkte sind nur über TLS erreichbar; die Website sendet HSTS. Zertifikate stellt Let's Encrypt aus; sie werden automatisch erneuert.
• Die Rechner mit den KI-Modellen werden vom Server nie angerufen. Ein Worker auf diesen Rechnern holt Aufträge über TLS ab (Long-Poll), jeder Abruf mit HMAC signiert, und liefert das Ergebnis auf demselben Weg zurück – beim Sprachmodell in Teilen, damit die Antwort im Browser fließt. Der Server und alle KI-Rechner stehen im selben internen Netz am selben Ort.
• Der Antwort-Dienst startet nur, wenn jeder eingetragene KI-Endpunkt auf einer Freigabeliste von Servern in der EU steht. Damit läuft die KI ausschließlich auf Servern in der EU; ein Endpunkt außerhalb der Liste verhindert den Start.
• Answely spricht Datenbank und Redis nur über die lokale Schleife des Servers an (zu den Netzadressen beider siehe Abschnitt 2.3).
• Ausgelagerte Kopien werden vor der Übertragung auf dem eigenen Server verschlüsselt (Abschnitt 5.1).

4.2 Eingabekontrolle

• Wichtige Vorgänge im Kundenkonto (Anmeldung, Änderung von Einstellungen, Löschungen) stehen im Prüfprotokoll mit Konto, Zeit und Handlung.
• Zustimmungen zu den Rechtstexten werden mit Fassung, Zeitpunkt, IP-Adresse und Browser festgehalten.
• Zahlungsereignisse von Stripe werden nur mit gültiger Signatur angenommen und je Ereignis genau einmal verarbeitet.

4.3 Weitergabekontrolle und Schutz der Ausgabe

• Das Skript sendet ausschließlich an die eigene Infrastruktur des Betreibers. Im normalen Betrieb wird kein Dritter kontaktiert.
• Antworten werden erst maskiert und dann mit Belegmarken versehen; Links nur mit https und nur auf Hosts der Website. Text von Nutzern geht im Browser nur als Text in die Seite, nie als HTML.
• Eigenes CSS des Kunden wird gesäubert; die KI-Kennzeichnung ist gegen Ausblenden geschützt.
• Der Indexer ruft nur Domains mit bestätigtem Inhaberschaftsnachweis ab, nur öffentliche Adressen – keine privaten, internen, Link-Local- oder reservierten Netze, auch nicht nach einer Weiterleitung –, nur per GET, ohne Cookies und Zugangsdaten, mit Zeit- und Größengrenzen und unter Beachtung von robots.txt.
• Live-Daten ruft der Server nur von höchstens zwei fest hinterlegten öffentlichen HTTPS-Endpunkten auf bestätigten Hosts ab, ohne Zugangsdaten, Parameter oder Daten des Besuchers.
• Die Texterkennung für PDF-Dateien läuft lokal mit begrenzten Ressourcen, Zeit und Seitenzahl in einem privaten temporären Ordner, der danach gelöscht wird; eine fremde Texterkennung wird nicht verwendet.
• Hochgeladene Firmenlogos werden geprüft und neu kodiert, bevor sie abgelegt werden; die Originaldatei wird nicht ausgeliefert.
• Die Website sendet Sicherheitsköpfe gegen Einbettung in fremde Seiten, gegen Typverwechslung, für sparsame Weitergabe der Herkunftsadresse und gegen den Zugriff auf Kamera, Mikrofon und Standort. Die Content-Security-Policy beschränkt Basisadresse, Objekte, Formularziele und Einbettung, nicht aber die Quellen von Skripten; das ist eine bekannte Lücke.

5. Verfügbarkeit und Belastbarkeit

5.1 Sicherung

• Jede Nacht sichert der Statuslauf die Datenbanken von Konto-App und Antwort-Dienst, prüft die Sicherung auf Vollständigkeit und räumt alte Stände auf. Die eigenen Sicherungen auf dem Server werden nach 30 Tagen gelöscht.
• Jeden Sonntag spielt eine Wiederherstellungsprobe die neueste Sicherung in eine Wegwerf-Datenbank ein, vergleicht sie und löscht die Probe wieder.
• Zusätzlich wird jede Nacht eine Kopie aller Datenbanken des Servers und des gesamten Webverzeichnisses ausgelagert, also auch des Index, der Frageanalyse, der Firmenlogos und der eigenen Sicherungen. Ziel ist ein nicht öffentlicher Speicher bei Google Cloud Storage in der Region europe-central2 (Warschau).
• Die ausgelagerte Kopie wird vor der Übertragung auf dem eigenen Server verschlüsselt (rclone crypt), einschließlich der Datei- und Verzeichnisnamen. Die Schlüssel liegen nur beim Betreiber; Google sieht nur Blöcke ohne erkennbare Bedeutung.
• Ausgelagerte Kopien werden so aufbewahrt: Tageskopien 7 Tage, Wochenkopien 364 Tage.
• Vor der Verschlüsselung entsteht die nächtliche Gesamtkopie (Abzüge aller Datenbanken des Servers und Dateikopie von /var/www samt Konfigurationsdateien) auf einem am Server angeschlossenen USB-Datenträger am selben Ort. Dort liegt sie unverschlüsselt und wird nach höchstens 8 Tagen gelöscht.
• Gelöschte Daten bleiben deshalb bis zum Ablauf dieser Kopien darin erhalten; eine gezielte Löschung innerhalb einer Kopie findet nicht statt. Kopien dienen nur der Wiederherstellung und werden nicht ausgewertet. Was bei einer Wiederherstellung mit zwischenzeitlich gelöschten Daten geschieht, regelt Abschnitt 12.3 des Auftragsverarbeitungsvertrags.

Was es nicht gibt, ausdrücklich: Die Datenbanken, Redis, die eigenen Sicherungen und die Gesamtkopie auf dem USB-Datenträger liegen unverschlüsselt; der Datenträger des Servers ist nicht verschlüsselt, eine Verschlüsselung im Ruhezustand ist nicht eingerichtet. Auch die Datenträger der KI-Rechner sind nicht verschlüsselt; dort liegen aber keine Inhalte: Die Rechner holen Aufträge ab, verarbeiten sie im Arbeitsspeicher und schicken das Ergebnis zurück, ohne etwas davon bei sich zu speichern. Die eigenen Sicherungen liegen auf demselben Datenträger wie die Datenbanken; vor dem Ausfall dieses Datenträgers schützen erst die Kopie auf dem USB-Datenträger und die ausgelagerte Kopie. Eine Wiederherstellung des ganzen Servers aus der ausgelagerten Kopie ist bisher nicht erprobt. Angestrebte Wiederherstellungszeit: höchstens 24 Stunden. Weil täglich gesichert wird, beträgt der Datenverlust in der Regel höchstens einen Tag.

5.2 Belastbarkeit und Unterbrecher

• Drossel: höchstens 60 Abrufe je Minute und IP-Adresse über alle öffentlichen Endpunkte des Antwort-Dienstes; darüber antwortet er mit „zu viele Anfragen“.
• Zulassung: Der Dienst nimmt nur eine begrenzte Zahl gleichzeitiger Antworten an, insgesamt und je Site; darüber lehnt er sofort ab, statt Anfragen aufzustauen.
• Unterbrecher: Schlägt das Sprachmodell wiederholt fehl, nimmt der Dienst für eine Weile keine Anfragen an das Modell mehr an. Die Box verschwindet dann, und die normale Suche der Website des Kunden bleibt voll nutzbar.
• Mehrere KI-Rechner: Die Antworten erzeugen zwei Rechner; ist einer ausgelastet oder fällt er aus, übernimmt der andere. Arbeiten im Hintergrund wie die Einbettungen bei Indexläufen und die nächtliche Gruppierung laufen auf einem weiteren eigenen Rechner. Fallen beide Antwort-Rechner aus, gibt es keine Antworten; die Box verschwindet.
• KI-Aufträge haben Fristen: Holt kein Worker einen Auftrag ab oder meldet sich ein Worker nicht mehr, endet der Auftrag mit einem Fehler, statt zu hängen. Besucherfragen haben Vorrang vor Arbeiten des Indexers.
• Kontingente je Site und Monat begrenzen die Last; der Kunde wird bei 80 und 100 Prozent gewarnt.
• Die Verbindungen der Worker laufen über einen eigenen Weg am Webserver vorbei, mit Grenzen je Adresse und insgesamt, damit wartende Abrufe keine Plätze für Besucher belegen.

Grenze, ehrlich: Die Kapazität reicht nach der letzten Lastmessung nicht für hohe Spitzen; über der Grenze lehnt der Dienst ab, statt langsamer zu werden. Zusätzliche Kapazität bei einem KI-Anbieter in der EU ist vorbereitet, aber nicht in Betrieb und wäre erst nach den Bedingungen in Abschnitt 8.3 des Auftragsverarbeitungsvertrags zulässig.

5.3 Überwachung

• Ein Statuslauf prüft alle fünf Minuten Schnittstelle, Datenbank, freien Speicherplatz, TLS-Zertifikate, Antwort-Dienst, Bereitschaft der KI-Modelle und Antwortzeit und meldet einen Ausfall erst nach zwei Fehlmessungen in Folge, damit ein einzelner Neustart niemanden weckt. Die Prüfungen von Website und Indexer sind in der Produktion eingeschaltet; in der Entwicklungsumgebung sind sie abgeschaltet.
• Meldewege: ein Signal ohne Inhalt per Telegram und ein Eintrag mit Komponente, Fehler und Dauer in den dringenden Meldungen („Urgent Logs“) des Administrationsbereichs, der offen bleibt, bis ihn der Betreiber abhakt.
• Eine offene Löschung, die nach 12 Stunden noch nicht ausgeführt ist, schreibt einen Fehler in das Fehlerprotokoll des Betreibers. Ein aktiver Alarm (Telegram oder Eintrag in den Urgent Logs) folgt daraus nicht.

Grenze: Die Überwachung läuft auf dem Rechner, den sie überwacht, und kann dessen Totalausfall nicht selbst melden. Ein Herzschlag an einen äußeren Dienst ist im Code vorgesehen, aber nicht eingerichtet. Die Zustellung eines Alarms an einen realen Empfänger ist für Answely noch nicht erprobt. Ob die nächtliche Auslagerung gelungen ist, prüft der Wächter, den der Betreiber für diesen Server betreibt, jeden Tag automatisch; bleibt eine gelungene Sicherung aus, meldet er es dem Betreiber.

6. Verfahren zur regelmäßigen Überprüfung

• Jede Änderung am Code durchläuft automatische Prüfstände für Dienst, Konto-App und Skript, darunter Prüfungen der Trennung je Mandant, der Zugriffsrechte, der Signaturen, der Eingabeverarbeitung in allen Formularen, der Löschfristen mit vorgestellter Uhr und der Ausfallwege.
• Ein eigener Prüfstand gleicht die Zahlen und Zusagen der Rechtstexte gegen Code und Konfiguration ab – in beiden Richtungen: Ein Text darf keine andere Frist nennen als der Code, und die Pflichttexte müssen jede Frist nennen. Er prüft auch die Zusage, dass die KI ausschließlich in der EU läuft, gegen die Freigabeliste.
• Eine Messung über den ganzen Weg prüft, dass bei ausgeschaltetem „Antwort-Cache erlauben“ eine Markierung in einer Frage weder in Datenbanken noch in Redis, Journalen oder Protokollen auftaucht.
• Abhängigkeiten werden von Hand auf bekannte Schwachstellen geprüft, zuletzt am 09.10.2026 (npm- und Composer-Prüfung ohne offene Befunde); eine automatische Prüfung bei jeder Änderung gibt es nicht. Die Laufzeitumgebung wird auf unterstützten Versionen gehalten.
• Die Maßnahmen dieses Dokuments werden überprüft, wenn sich die Verarbeitung ändert – insbesondere vor jeder Änderung an KI-Anbieter, Ausweich-Endpunkt, Frageanalyse oder Push-Schnittstelle –, im Übrigen jährlich.

Externe Penetrationstests sind derzeit nicht beauftragt, und es bestehen keine Sicherheitszertifizierungen. Das steht hier ausdrücklich: Ein TOM-Dokument, das dazu schweigt, liest sich, als gäbe es solche Prüfungen.

7. Unterauftragsverarbeiter

Der Betreiber zieht Unterauftragsverarbeiter nur auf Grundlage der allgemeinen Genehmigung im Auftragsverarbeitungsvertrag hinzu, kündigt Änderungen 30 Tage vorher an und verpflichtet jeden vertraglich auf dieselben Pflichten. Die aktuelle Liste: Unterauftragsverarbeiter.

An der Beantwortung einer Frage ist kein Dritter beteiligt: Das Skript sendet ausschließlich an die eigene Infrastruktur, und das Sprachmodell läuft auf eigener Hardware. Die verschlüsselte ausgelagerte Kopie bei Google macht Google zum Unterauftragsverarbeiter, auch wenn Google den Inhalt nicht lesen kann – die Verschlüsselung ist eine Maßnahme, keine Änderung der Rolle. E-Mails an Kunden, darunter der optionale Wissenslücken-Bericht mit Gruppen maskierter Fragen, versendet der Betreiber über Namecheap Private Email (Namecheap, Inc., USA); die Übermittlung stützt sich auf die EU-Standardvertragsklauseln im Data Processing Addendum von Namecheap.

8. Aufbewahrung und Löschung

Die Löschung läuft automatisch; sie wird nicht von Hand angestoßen. Jede Frist ist durch eine Prüfung mit vorgestellter Uhr belegt.

8.1 Antwortbox (im Auftrag)

• Fragen und Antworten in der Grundeinstellung: keine Speicherung.
• Zwischenspeicher der Antworten (nur bei eingeschaltetem „Antwort-Cache erlauben“): 24 Stunden; nach einer neuen Indexversion wird ein alter Eintrag nicht mehr verwendet und läuft mit dieser Frist ab.
• Zähler ohne Inhalt: 7 Tage.
• Missbrauchsschutz: Hash 2 Minuten.
• Zugriffsprotokoll des Webservers: 7 Tage.
• Frageanalyse (nur mit Opt-in des Kunden): 90 Tage, stündlich geprüft; sofort mit der Site oder auf Knopfdruck.
• Prüfberichte der Antworttests und technische Freigabeberichte: höchstens 30 Tage.
• Antwortdiagnose: nur im Arbeitsspeicher, höchstens 15 Minuten nach Abschluss.
• Index, Indexkopien und Einstellungen einer Site: bis zur Löschung der Site, dann binnen 24 Stunden. Eine Warteschlange holt Löschungen nach, die der Dienst nicht sofort annimmt, und schreibt nach 12 Stunden einen Fehler ins Protokoll. Ein Abgleich findet verwaiste Sites.

8.2 Kundenkonto und Website (Verantwortlicher)

• Seitenstatistik: 60 Tage.
• Prüfprotokoll: 365 Tage.
• Fehlerprotokoll: 90 Tage.
• Postausgang: 30 Tage.
• Anmeldeversuche: 7 Tage.
• Formularschutz formconfirmed: Hash des gekürzten Adressbereichs höchstens 1 Stunde, Prüfergebnisse 30 Tage, Ergebnis zur E-Mail-Domain höchstens 7 Tage.
• Belege bei „Passwort vergessen?“: 7 Tage; Zustandsangaben zum Formularschutz: 30 Tage.
• Kontodaten: bis zur Löschung des Kontos, dann sofort; Rechnungen 5 Jahre ab Ende des Kalenderjahres ihrer Entstehung nach polnischem Steuerrecht, dann automatisch gelöscht; Nachweis der Zustimmung zu den Rechtstexten nach der Löschung, sobald die Zustimmung 4 Jahre zurückliegt, also spätestens 4 Jahre nach der Löschung.
• Sitzungen: beendete oder nicht mehr genutzte 30 Tage nach dem Ende bzw. der letzten Nutzung.
• Supportanfragen samt KI-Entwürfen: 1095 Tage ab der letzten Antwort.
• Eigene Sicherungen: 30 Tage.
• Ausgelagerte verschlüsselte Kopien: Tageskopien 7 Tage, Wochenkopien 364 Tage.
• Unverschlüsselte Gesamtkopie auf dem USB-Datenträger am Server: höchstens 8 Tage.

9. Verletzungen des Schutzes personenbezogener Daten

Der Betreiber benachrichtigt den Kunden unverzüglich, spätestens 48 Stunden nachdem ihm eine Verletzung bekannt geworden ist, die Daten des Kunden betrifft. Die Meldung enthält die Angaben, die der Kunde für seine Pflichten nach Art. 33 und 34 DSGVO benötigt. Jede Verletzung wird mit Sachverhalt, Auswirkungen und Abhilfe dokumentiert.

Meldeadresse für Sicherheitsvorfälle: support@answely.com

10. Stand und Fassung

Fassung 1.0, Stand 18.10.2026 – erste veröffentlichte Fassung; Fassung 1.1, Stand 31.10.2026: Formularschutz formconfirmed ergänzt (2.2, 3, 8.2); Fassung 1.2, Stand 04.11.2026: Ausfallregel ohne stilles Durchlassen (2.2); Fassung 1.3, Stand 04.11.2026: Mengenlimit, Belege und Zustandsangaben (2.2, 8.2); Fassung 1.4, Stand 06.11.2026: zweite Stufe bei „markieren“ (2.2); Fassung 1.5, Stand 06.11.2026: Kampagnenerkennung und Sprachmodell (2.2). Nächste Überprüfung: jährlich.

Bei Abweichungen zwischen den Sprachfassungen ist die englische Fassung maßgeblich; die deutsche und die polnische Fassung sind Übersetzungen zur Information.

Version 1.5 – Stand 06.11.2026