Datenschutzerklärung

Diese Erklärung beschreibt, welche personenbezogenen Daten Rekala verarbeitet, zu welchem Zweck, auf welcher Rechtsgrundlage, wer sonst beteiligt ist und wie Sie Ihre Rechte ausüben. Sie beschreibt, was die Software tatsächlich tut — nicht das, was bequem zu sagen wäre.

1. Verantwortlicher und Kontakt

Den Dienst Rekala (die Anwendung unter app.rekala.io und die Website rekala.io) betreibt Rekala Labs SpA, eine nach chilenischem Recht gegründete sociedad por acciones (SpA), Sitz: Moneda 812, Büro 601, Santiago, Región Metropolitana, Chile, chilenische Steuernummer (RUT) 78.500.869-3. Im Folgenden „Rekala" oder „wir".

Für alle datenschutzrechtlichen Anliegen, einschließlich der Ausübung Ihrer Rechte: privacy@rekala.io.

Datenschutzbeauftragter: nicht erforderlich. Vertreter in der Europäischen Union nach Art. 27 DSGVO: nicht erforderlich.

Sie können sich bei der zuständigen Aufsichtsbehörde beschweren: die chilenische Datenschutzbehörde (Agencia de Protección de Datos Personales).

2. Zwei getrennte Rollen: wann Verantwortlicher, wann Auftragsverarbeiter

Das ist die wichtigste Unterscheidung dieses Dokuments — sie entscheidet, an wen Sie sich wenden.

(a) Rekala als Verantwortlicher

Gegenüber unseren eigenen Nutzerinnen und Nutzern sowie den Besuchern von rekala.io entscheiden wir über Zweck und Mittel der Verarbeitung. Das betrifft Ihr Konto, Ihre Sitzung, die Abrechnung und die Protokolle des Webservers.

(b) Rekala als Auftragsverarbeiter

Für die Interessentendaten, die ein Kunde in seinen Arbeitsbereich hochlädt, ist der Kunde der Verantwortliche, nicht Rekala. Der Kunde entscheidet, wen er kontaktiert, warum und auf welcher Rechtsgrundlage; wir speichern und verarbeiten diese Daten ausschließlich nach seinen dokumentierten Weisungen, nie aus eigenem Antrieb, und teilen sie niemals zwischen Arbeitsbereichen.

Diese Rollenverteilung ist keine Absichtserklärung, sondern im Produkt verdrahtet. Jeder Kunde akzeptiert einen versionierten Auftragsverarbeitungsvertrag (AVV), und jede Erklärung, die er abgibt — Rechtsgrundlage eines Imports, Start einer Kampagne, Annahme des AVV — wird unveränderlich zusammen mit der exakten Version des Textes protokolliert, den er angenommen hat.

3. Wenn Sie eine mit Rekala versendete E-Mail erhalten haben

4. Daten, die wir als Verantwortlicher verarbeiten

Von den Personen, die die Anwendung nutzen:

• Konto: E-Mail-Adresse, Vor- und Nachname, Rolle im Arbeitsbereich, ob das Konto aktiv ist, und das Anlagedatum. Das Passwort selbst wird nicht gespeichert, sondern ein bcrypt-Hash, aus dem es sich nicht wiederherstellen lässt.
• Sitzung: eine Sitzungskennung und deren Ablauf. Auch die Kennung wird nicht im Klartext gespeichert — in der Datenbank liegt nur ihr SHA-256-Hash.
• Absenderprofil: Name, Funktion, Unternehmen, Signatur, Tonalität und Sprache, die die Textentwürfe verwenden sollen.
• Oberflächeneinstellungen (Sprache der Oberfläche, Anordnung einzelner Bereiche).
• Verbundenes Postfach (nur wenn Sie eines verbinden): die verifizierte Adresse des Postfachs und die Token, die den Versand autorisieren. Die Token werden mit AES-256-GCM verschlüsselt gespeichert.
• Aktivitätsnachweise: AVV-Annahmen, Erklärungen zur Rechtsgrundlage, wesentliche Änderungen und die Übernahme eines Kontos durch einen Administrator — jeweils mit Angabe, wer gehandelt hat.
• Rückmeldungen, die Sie über das Feedback-Formular in der Anwendung senden.

Von Besuchern der Website rekala.io: Der Webserver führt keine Zugriffsprotokolle; lediglich Betriebsfehler landen im Systemjournal, das automatisch rotiert. Die Website enthält kein JavaScript, keine Analyse-Werkzeuge und keine Cookies.

5. Daten, die wir als Auftragsverarbeiter verarbeiten

Das sind die Daten, die ein Kunde über die Personen und Unternehmen erfasst, die er ansprechen will. Wir listen sie genau auf, weil genau das ein Verantwortlicher braucht, um seine eigene Informationspflicht zu erfüllen:

Zur Kontaktperson

• Vor- und Nachname.
• E-Mail-Adresse (das einzige Pflichtfeld).
• Unternehmen und Funktion.
• Telefonnummer.
• LinkedIn-Profil.
• Land.
• Notizen und Schlagworte des Kunden sowie dem Kontakt zugeordnete Recherchenotizen.
• Die angegebene Herkunft des Kontakts und die Rechtsgrundlage, die der Kunde erklärt hat.

Zur Beziehung mit dieser Person

• Der vollständige Text der erzeugten E-Mails (Betreff und Inhalt von bis zu drei E-Mails je Sequenz), deren bearbeitete Fassungen und der Zeitpunkt, zu dem sie als versendet markiert wurden.
• Der wörtliche Text der Antworten, die der Kunde in die Anwendung einfügt, wenn der Interessent antwortet. Er kann alles enthalten, was diese Person geschrieben hat, und wird unverändert aufbewahrt.
• Das Gespräch zwischen Kunde und Assistent über diese E-Mails: Anweisungen, Korrekturen und Regeln.
• Versandereignisse und Status innerhalb der Kampagne.
• Ob die Adresse auf der Sperrliste steht, und aus welchem Grund.

Zum Unternehmen des Interessenten

• Name, Branche, Größe, Land, Website und Notizen.
• Die automatisch von der öffentlichen Website dieses Unternehmens extrahierten Informationen.

6. Woher die Interessentendaten stammen

Aus zwei Quellen — und nur aus zweien:

• Der Kunde bringt sie ein: durch Import einer CSV-Datei oder manuelles Anlegen des Kontakts. Dabei muss er erklären, auf welcher Rechtsgrundlage er sie hält; diese Erklärung wird protokolliert.
• Automatisierte Recherche der Unternehmenswebsite. Unser Server ruft die öffentliche Website des Unternehmens des Interessenten ab und extrahiert Informationen über das Unternehmen. Diese Recherche findet ausschließlich auf Unternehmensebene statt: wir recherchieren niemals zu Personen.

Findet dieser Abruf auf der Seite veröffentlichte E-Mail-Adressen, greifen zwei Filter, die konstruktiv fest eingebaut und nicht konfigurierbar sind:

1. Nur allgemeine Postfächer. Akzeptiert werden Adressen wie info@, kontakt@, contact@, vertrieb@ und ähnliche. Die Adresse einer identifizierbaren Person — etwa vorname.nachname@ — wird stets verworfen. Die Adresse einer einzelnen Person erfassen wir nie.
2. Nur dieselbe Domain. Akzeptiert wird nur eine Adresse der Domain der gerade abgerufenen Seite, niemals die eines Dritten, die dort auftaucht — etwa eine Agentur im Impressum, ein Dienstleister oder ein Partner.

Ebenso wenig wird eine Adresse „abgeleitet", die nicht buchstäblich auf der Seite stand.

7. Zwecke und Rechtsgrundlagen

Rekala nutzt die Interessentendaten eines Kunden für keinen eigenen Zweck und nicht, um den Dienst für andere Kunden zu verbessern. Das Lernen des Produkts ist je Arbeitsbereich isoliert: Nichts, was im Arbeitsbereich eines Kunden geschieht, wirkt sich auf den eines anderen aus.

8. Was genau an das KI-Modell geht — und was nicht

Zum Verfassen einer E-Mail wird der Inhalt des Prompts an Anthropic PBC übermittelt. Wir werden hier konkret, weil das die Frage ist, die jeder Systemadministrator stellt — und weil sie überprüfbar ist.

Was nicht übermittelt wird

Der Kontaktblock des Prompts enthält ausschließlich Name, Unternehmen, Funktion und Land des Interessenten. Die E-Mail-Adresse des Empfängers wird niemals an das Modell übermittelt. Ebenso wenig Telefonnummer oder LinkedIn-Profil. Die Adresse wird allein zur Zustellung im Moment des Versands verwendet, und dieser Versand läuft nicht über das Modell.

Das ist keine Absichtserklärung: Die acht Prompts, die das System zusammensetzt, sind Byte für Byte in einem automatisierten Test eingefroren, der bei jeder Änderung läuft — und sie enthalten keine E-Mail-Adresse, keine Telefonnummer und keinen Verweis auf LinkedIn.

Was übermittelt wird

• Die Identität des Interessenten: Name, Unternehmen, Funktion und Land.
• Recherchenotizen, die der Nutzer geschrieben hat.
• Die von der öffentlichen Unternehmenswebsite extrahierten Informationen.
• Der Text der eingefügten Antworten, wenn ein Follow-up verfasst wird, das auf das Gesagte eingehen soll.
• Das Material des Anbieters: Angebot, Argumente, Unternehmenswissen und hochgeladene Dokumente. Lässt sich ein PDF lokal nicht auslesen, wird die Datei base64-codiert übermittelt, damit das Modell sie lesen kann.

Daraus folgt praktisch etwas Wichtiges, und das gehört klar gesagt: Schreibt ein Nutzer personenbezogene Daten in die Notizen oder lädt er ein Dokument hoch, das solche enthält, gelangen diese Daten an das Modell. Die Kontrolle darüber liegt bei demjenigen, der schreibt.

Anthropic verarbeitet diese Daten als Unterauftragsverarbeiter, vertraglich gebunden, ausschließlich zur Rückgabe der Antwort. Nach den kommerziellen Bedingungen von Anthropic werden über die API übermittelte Daten nicht zum Training der Modelle verwendet.

9. Unterauftragsverarbeiter und Drittlandtransfers

Die Liste ist bewusst kurz und abschließend. Jeder Beteiligte wirkt nur an dem Teil des Dienstes mit, der ihn betrifft, auf Grundlage eines schriftlichen Vertrags mit Datenschutzpflichten, die den unseren entsprechen.

Zu Ihrem eigenen E-Mail-Anbieter

Verbindet ein Nutzer sein Gmail- oder Microsoft-Postfach, wird die Nachricht über die API dieses Anbieters mit der vom Nutzer selbst erteilten Berechtigung zugestellt und geht aus seinem Konto hinaus. Dieser Anbieter ist unabhängig von Rekala bereits der E-Mail-Anbieter des Kunden. Die Berechtigung lässt sich jederzeit in den Sicherheitseinstellungen des Google- oder Microsoft-Kontos widerrufen oder durch Trennen des Postfachs in Rekala.

Die Websites der Interessenten

Während der Recherche stellt unser Server eine HTTP-Anfrage an die öffentliche Website des Unternehmens des Interessenten. Diese Website erhält dabei — wie bei jedem Besuch — die IP-Adresse unseres Servers, nicht die eines Nutzers oder eines Interessenten. Es handelt sich nicht um einen Unterauftragsverarbeiter, wir weisen aber darauf hin, weil es ein Datenfluss an einen Dritten ist.

Änderungen der Liste

Bevor wir einen Unterauftragsverarbeiter aufnehmen oder ersetzen, der Kundendaten verarbeiten wird, kündigen wir dies mindestens 30 Tage im Voraus an, indem wir diese Seite aktualisieren und in der Anwendung informieren. Ein Kunde mit einem begründeten datenschutzrechtlichen Einwand kann diesen innerhalb dieser Frist erheben.

10. Speicherdauer, Sicherungskopien und Löschung

Wir sind lieber genau — einschließlich der Grenzen.

• Interessentendaten: bleiben gespeichert, solange der Kunde sie in seinem Arbeitsbereich behält. Rekala löscht keine Daten nach Zeitablauf. Das Produkt markiert Kontakte zur Prüfung, mit denen es seit rund 36 Monaten keinen Austausch gab, zeigt sie aber lediglich an: Die Entscheidung über Aufbewahrung oder Löschung trifft immer der Kunde. Eine automatische Fristlöschung gibt es nicht.
• Sperrliste: wird bewusst unbefristet aufbewahrt. Ein Widerspruch gegen Kontaktaufnahme läuft nicht ab. Wird ein Kontakt auf sein Verlangen gelöscht, wird zuerst der Sperreintrag erzeugt und anschließend die Klartextadresse auf NULL gesetzt, sodass nur ein unumkehrbarer Hash verbleibt, der jede erneute Kontaktaufnahme weiterhin blockiert.
• Compliance-Nachweise (AVV-Annahmen, Erklärungen zur Rechtsgrundlage): nur anfügbar und als Beweis aufbewahrt, ohne E-Mail-Inhalte.
• Nutzerkonto: solange das Konto aktiv ist, und danach 30 Tage.
• Sicherungskopien: Einmal täglich wird eine vollständige Kopie der Datenbank erstellt; aufbewahrt werden die sieben jüngsten, ältere werden automatisch gelöscht. Aus dem Livesystem gelöschte Daten können daher noch bis zu etwa sieben Tage in einer Sicherungskopie vorhanden sein, bis diese aus der Rotation fällt.
• Bekannte Einschränkung: Abgelaufene Sitzungsdatensätze werden nicht automatisch bereinigt. Eine abgelaufene Sitzung ermöglicht keinen Zugang — sie wird abgewiesen —, ihr Datensatz bleibt aber in der Datenbank, bis eine Abmeldung erfolgt oder ein Administrator sie entzieht.

11. Sicherheit

• Passwörter werden mit bcrypt gespeichert; nie im Klartext und nie wiederherstellbar.
• Sitzungskennungen werden als SHA-256-Hash gespeichert. Wer eine Kopie der Datenbank erlangt, erhält Hashes, keine wiederverwendbaren Zugangsdaten.
• OAuth-Token des Postfachs werden mit AES-256-GCM verschlüsselt. Das System scheitert geschlossen: Fehlt der Schlüssel oder ist der Datensatz manipuliert, gilt das Postfach als unbrauchbar, statt unverschlüsselt weiterzuarbeiten.
• Links zur Vorschau und zum Download von Dateien nutzen Einmal-Token, gebunden an Datei und Arbeitsbereich, mit einer Gültigkeit von rund zwei Minuten — damit die Sitzungskennung nie in einer URL steht.
• Strikte Isolation je Arbeitsbereich, einschließlich des Lernens im Produkt: Kein Datum und kein Muster wechselt von einem Kunden zum anderen.
• Drei Zugriffsebenen: authentifizierter Nutzer, Administrator des Arbeitsbereichs und Plattformadministrator. Löschende Vorgänge und sensible Einstellungen sind Administratoren vorbehalten.
• Übernimmt ein Plattformadministrator ein fremdes Konto, wird protokolliert, wer das getan hat.
• Alle Datenbankabfragen laufen über eine globale Prüfung, die nicht-skalare Werte zurückweist, damit ein Wert aus einer Anfrage nicht mit einem unerwarteten Typ gespeichert wird.
• HTTP-Sicherheitsheader, eine Positivliste zulässiger Ursprünge, Ratenbegrenzungen und ein Schutz gegen Anfragen an interne Netze in den Funktionen, die externe Websites abrufen.

Keine Maßnahme beseitigt das Risiko vollständig. Wenn Sie ein Sicherheitsproblem entdecken, schreiben Sie an security@rekala.io.

12. Ihre Rechte — und wie Sie sie tatsächlich ausüben

Soweit die DSGVO oder eine gleichwertige Regelung auf Sie anwendbar ist, haben Sie das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Widerspruch und Datenübertragbarkeit. Ebenso können Sie eine Einwilligung widerrufen, soweit die Verarbeitung darauf beruht, und sich bei einer Aufsichtsbehörde beschweren.

Wenn Sie Rekala nutzen

Schreiben Sie an privacy@rekala.io. Wir sind der Verantwortliche und antworten unmittelbar.

Wenn Sie Interessent sind

Verantwortlich ist der Rekala-Kunde, der Sie kontaktiert hat; die Entscheidung liegt bei ihm. Erläutert in Abschnitt 3. Unsere Pflicht — der wir nachkommen — ist es, ihn zu unterstützen, damit er Ihnen antworten kann. Dafür verfügt das Produkt über echte Werkzeuge:

• Auskunftsexport: Ein Administrator des Arbeitsbereichs kann ein Bündel mit allem erzeugen, was die Plattform zu einem Kontakt vorhält: Identität, angegebene Herkunft und Rechtsgrundlage, Notizen, sämtliche Kampagnen, in denen er vorkommt, der vollständige Text der E-Mails, die Versandereignisse, das Gespräch mit dem Assistenten über diese E-Mails und der Status auf der Sperrliste.
• Löschung: Ein Administrator kann den Kontakt löschen. Der Vorgang legt zuerst den dauerhaften Sperreintrag an und löscht anschließend kaskadierend den Datensatz, seine Kampagnenzugehörigkeiten, die E-Mails, die Bearbeitungen und das zugehörige Gespräch. Das Protokoll hält nur Zählwerte fest, nie Inhalte.

Wir bearbeiten oder leiten jedes Anliegen innerhalb der gesetzlichen Frist weiter, unentgeltlich, es sei denn, es ist offenkundig unbegründet oder exzessiv.

13. Automatisierte Entscheidungen und Profiling

Rekala trifft keine ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidungen, die rechtliche Wirkung gegenüber einer Person entfalten oder sie in ähnlicher Weise erheblich beeinträchtigen. Das System verfasst Texte und ordnet Vertriebsmaterial ein; die Entscheidung, wen man anschreibt und ob eine E-Mail hinausgeht, trifft stets ein Mensch — und das Produkt verlangt diese Freigabe.

14. Keine Cookies: lokale Speicherung im Browser

Die Anwendung verwendet keine Cookies. Die Authentifizierung erfolgt über ein Token, das im Header jeder Anfrage mitgesendet und vom Browser in localStorage abgelegt wird. Im selben Speicher liegen einige Oberflächeneinstellungen. Diese Daten bleiben auf Ihrem Gerät, werden nicht — wie ein Cookie — automatisch mit jeder Anfrage übertragen, und Sie können sie löschen, indem Sie die Websitedaten in Ihrem Browser leeren; damit werden Sie abgemeldet.

Die Website rekala.io enthält kein JavaScript, keine Analyse-Werkzeuge und keine Cookies — deshalb zeigt sie auch kein Cookie-Banner: Es gibt nichts einzuwilligen.

15. Externe Ressourcen auf dieser Website: keine

Wenn Sie eine Seite von rekala.io öffnen, kommuniziert Ihr Browser ausschließlich mit rekala.io. Es wird nichts von einem fremden Server geladen: keine Schriftarten, keine Bilder, keine Skripte, keine Symbole. Die Schriftarten werden zusammen mit dem übrigen Angebot von unserem eigenen Server ausgeliefert.

Wir erwähnen das, weil es bis zum 25. August 2026 anders war: Die Schriftarten wurden von fonts.googleapis.com und fonts.gstatic.com geladen, sodass Google die IP-Adresse jedes Besuchers allein zur Auslieferung einer Schrift erhielt — in Deutschland ein bekanntes Streitthema. Diese Abhängigkeit wurde entfernt.

16. Was wir nicht tun

Jede dieser Aussagen wurde am ausgelieferten Code geprüft, indem nach der Funktion gesucht und ihr Nichtvorhandensein bestätigt wurde:

• Wir verkaufen und übermitteln keine personenbezogenen Daten an Dritte und handeln nicht zu Werbezwecken damit.
• Wir setzen keine Zählpixel in E-Mails ein.
• Wir messen keine Öffnungen.
• Wir schreiben keine Links um und messen keine Klicks.
• Wir setzen keine Blindkopien (BCC) oder Kopien (CC) bei einem Versand.
• Wir lesen Ihren Gmail-Posteingang nicht. Die Anwendung fordert von Google ausschließlich gmail.send an, dazu die einfache Identifikation, um die verifizierte Absenderadresse zu kennen. Mit diesem Bereich ist das Lesen von E-Mails technisch ausgeschlossen. Ehrliche Einschränkung: Der alternative Microsoft-Weg, der umgesetzt ist, fordert sehr wohl Mail.ReadWrite an, weil der Versand innerhalb eines Threads über Graph das Anlegen eines Entwurfs vor dem Senden verlangt. Diese Berechtigung wird für nichts anderes genutzt.
• Unsere Nutzung von Google-Nutzerdaten ist begrenzt. Rekalas Verwendung von Informationen, die über Google-APIs empfangen werden, entspricht der Google API Services User Data Policy einschließlich der Limited-Use-Anforderungen.
• Wir verwenden keine Analyse-Werkzeuge Dritter, weder in der Anwendung noch auf der Website.
• Die Website lädt keinerlei Ressourcen Dritter. Ihr Browser kommuniziert ausschließlich mit rekala.io.
• Wir recherchieren nicht zu Personen. Die automatisierte Recherche findet stets auf Unternehmensebene statt.
• Wir erfassen keine Personenadressen von Webseiten, sondern nur allgemeine Postfächer derselben Domain.
• Wir vermischen keine Daten zwischen Kunden. Weder Daten noch Gelerntes verlassen den Arbeitsbereich, in dem sie entstanden sind.
• Wir versenden nichts aus eigenem Antrieb. Der automatische Versand ist umgesetzt, aber inaktiv: Er wird deaktiviert ausgeliefert, erfordert, dass der Betreiber den Versandweg scharf schaltet, dass der Kunde den AVV annimmt und einen Testversand besteht — und selbst dann gibt ein Mensch jede E-Mail frei.

17. Änderungen dieser Erklärung

Ändern wir diese Erklärung, aktualisieren wir das Datum und die Versionskennung am Anfang. Wesentliche Änderungen, die Kunden betreffen, teilen wir zusätzlich in der Anwendung mit. Maßgeblich ist stets die unter dieser Adresse veröffentlichte Fassung.