Vertrauen

Sicherheit sollte sich überprüfen lassen.

Zuletzt aktualisiert: September 2026

Deshalb beschreiben wir hier konkret, wo Daten gespeichert und verarbeitet werden, welche Dienste Zugriff darauf erhalten und wie wir sie schützen.

Wir dokumentieren auch, was noch nicht umgesetzt ist. Denn eine Sicherheitsseite, auf der einfach alles als sicher bezeichnet wird, hilft bei einer ernsthaften Prüfung nicht weiter.

Wo deine Daten gespeichert werden

Die Anwendungsserver und die zentrale Datenbank von Acadex werden in Deutschland betrieben.

Auch unsere von uns verwalteten Backups werden in Deutschland gespeichert.

Welche weiteren Dienste Daten erhalten können, hängt davon ab, welche Funktionen und Modellanbieter für den jeweiligen Account beziehungsweise die jeweilige Institution freigeschaltet sind.

Die bloße technische Unterstützung eines Anbieters bedeutet nicht, dass dieser automatisch Daten jedes Acadex-Nutzers erhält.

Externe Dienste & Unterauftragsverarbeiter ansehen →

Wo KI-Anfragen verarbeitet werden

Acadex ist nicht an einen einzelnen Modellanbieter gebunden.

Je nach Konfiguration können unterschiedliche Sprachmodelle zur Verarbeitung einer Anfrage eingesetzt werden.

Für institutionelle Accounts kann verbindlich festgelegt werden, welche Anbieter verwendet werden dürfen.

Diese Einschränkung wird technisch durch Acadex durchgesetzt und kann nicht innerhalb eines einzelnen Gesprächs umgangen werden.

So können Institutionen beispielsweise Anforderungen an:

• zulässige Modellanbieter,
• geografische Verarbeitung,
• Datenaufbewahrung,
• oder bestimmte Provider-Funktionen

in ihrer Konfiguration berücksichtigen.

Nicht jedes von Acadex unterstützte Modell eignet sich automatisch für jede Datenschutzanforderung.

Welche Anbieter und Verarbeitungsprofile tatsächlich verfügbar sind und welche Bedingungen dafür gelten, dokumentieren wir separat.

Externe Dienste & Unterauftragsverarbeiter ansehen →

Was verschlüsselt ist – und was nicht.

Verbindungen zu Acadex werden per TLS verschlüsselt.

Gesprächsinhalte, gespeicherte Erinnerungen, Inhalte hochgeladener Dokumente, Chat-Titel und gespeicherte Anfrageinhalte werden in unserer Datenbank mit AES-256-GCM verschlüsselt.

Der zur Entschlüsselung erforderliche Schlüssel wird getrennt von der Datenbank aufbewahrt.

Eine Kopie der Datenbank allein reicht deshalb nicht aus, um diese Inhalte zu lesen.

Eine wichtige Ausnahme

Bestimmte Texte, die für die semantische Suche innerhalb gespeicherter Erinnerungen benötigt werden, müssen technisch durchsuchbar bleiben.

Dieser Teil wird deshalb derzeit nicht mit derselben feldweisen Verschlüsselung gespeichert.

Wir könnten diesen Unterschied weglassen und pauschal von „Verschlüsselung im Ruhezustand“ sprechen.

Für eine tatsächliche Bewertung ist es aber wichtiger zu wissen, wo die Grenze liegt.

Passwörter

Passwörter speichern wir nicht im Klartext.

Wir speichern ausschließlich mit Argon2id erzeugte Passwort-Hashes.

Was wir mit deinen Inhalten nicht tun.

Acadex verwendet deine:

• Gespräche,
• hochgeladenen Dokumente,
• gespeicherten Erinnerungen,
• Forschungsanfragen

nicht zum Training eigener KI-Modelle.

Wir verkaufen diese Inhalte nicht.

Wir verwenden sie nicht für Werbung.

Wir erstellen daraus keine Werbeprofile.

Wir setzen keine Werbenetzwerke und keine Session-Recording-Dienste ein.

Wenn für eine konkrete Anfrage ein externer Modellanbieter verwendet wird, erhält dieser nur die Informationen, die für diese Verarbeitung benötigt werden.

Dazu können beispielsweise gehören:

• deine aktuelle Eingabe,
• relevanter Gesprächskontext,
• abgerufene Erinnerungen,
• bibliografische Informationen,
• erforderliche Ausschnitte aus Dokumenten.

Die vollständige Datenhaltung deines Accounts wird einem Modellanbieter nicht pauschal zur Verfügung gestellt.

Wir messen Nutzung, ohne daraus ein Forschungsprofil zu machen.

Ganz ohne Produktmetriken würden wir Acadex im Blindflug weiterentwickeln.

Deshalb erfassen wir auf unserer eigenen Infrastruktur einige bewusst begrenzte Nutzungs- und Geschäftskennzahlen.

Dazu können beispielsweise gehören:

• aggregierte Aufrufe unserer Homepage,
• Aufrufe der Pricing- oder Institutions-Seite,
• Registrierungen,
• erstmalige erfolgreiche Nutzung einer zentralen Produktfunktion,
• Wechsel von Explore zu Researcher,
• Kündigungen,
• aktive kostenpflichtige Accounts,
• aggregierter Creditverbrauch,
• MRR und ARR.

Dafür verwenden wir keine externen Analytics-Dienste.

Wir setzen keine zusätzlichen Analytics-Cookies, Tracking-Pixel oder dauerhaften Besucher-IDs ein.

Wir zeichnen keinen vollständigen Klickverlauf auf.

Und vor allem verwenden wir dafür nicht:

• Gesprächsinhalte,
• Dokumentinhalte,
• gespeicherte Erinnerungen,
• Forschungsinteressen,
• bibliografische Suchanfragen.

Wir wollen wissen, ob Acadex genutzt wird – nicht, was einzelne Menschen darin erforschen.

Website-Statistiken bleiben auf unserer Infrastruktur.

Auf unserer Website zählen wir serverseitig, wie häufig bestimmte Seiten aufgerufen werden.

Dabei interessieren uns beispielsweise aggregierte Werte wie:

Wie häufig wurde /plans diese Woche aufgerufen?

Nicht:

Welche einzelne Person hat sich wann welche Seiten angesehen?

Für unsere langfristige Website-Statistik benötigen wir deshalb insbesondere keine:

• dauerhaften Besucherkennungen,
• Browser-Fingerprints,
• vollständigen IP-Adressen,
• URL-Queryparameter,
• Suchbegriffe,
• vollständigen Referrer-URLs.

Technische Serverlogs und langfristige Nutzungsstatistiken behandeln wir als getrennte Systeme und Zwecke.

Du kannst deine Daten selbst löschen.

Gespräche, einzelne Erinnerungen und hochgeladene Dokumente kannst du direkt in Acadex löschen.

Dafür ist keine Anfrage an unseren Support erforderlich.

Auch dein gesamter Account kann gelöscht werden.

Bei einer Accountlöschung werden die damit verbundenen personenbezogenen Nutzerdaten aus den aktiven Systemen entfernt.

Löschung ist Teil der Datenbankstruktur.

Wir verlassen uns nicht darauf, dass Anwendungscode bei einer Accountlöschung an jede einzelne Tabelle denkt.

Die Beziehungen in unserer Datenbank sind so aufgebaut, dass zugehörige Nutzerdaten automatisch in den Löschprozess einbezogen werden.

Zusätzlich prüft ein automatisierter Test das Datenbankschema.

Enthält eine Tabelle Nutzerdaten, die nicht von der vorgesehenen Löschlogik erfasst werden, kann dieser Test darauf aufmerksam machen.

Auch abgeleitete Nutzerdaten in unseren Such- und Vektorsystemen werden berücksichtigt.

Denn:

„Wir löschen deine Daten“ ist schnell geschrieben. Entscheidend ist, ob das System es tatsächlich tut.

Was nach einer Löschung mit Statistiken passiert

Accountbezogene Product-Metric-Daten werden grundsätzlich gemeinsam mit dem Account gelöscht, soweit keine andere gesetzliche Aufbewahrungspflicht besteht.

Bereits anonymisierte und aggregierte Statistiken bleiben davon unberührt.

Wenn beispielsweise bereits feststeht, dass es an einem bestimmten Tag insgesamt 120 Registrierungen gab, lässt sich diese Zahl später nicht mehr auf einen bestimmten Account zurückführen.

Eine Accountlöschung verändert solche anonymisierten Gesamtstatistiken deshalb nicht.

Backups und Löschung

Gelöschte Daten können bis zum Ablauf der jeweiligen Backup-Rotation noch in bestehenden Sicherungskopien enthalten sein.

Diese Backups werden nicht für den regulären Produktivbetrieb verwendet.

Sie werden nach Ablauf ihrer jeweiligen Aufbewahrungsdauer ersetzt beziehungsweise gelöscht.

Wenn eine ältere Sicherungskopie wiederhergestellt werden muss, sollen zuvor wirksam gelöschte Daten nicht dauerhaft wieder in den laufenden Produktivbestand übernommen werden.

Administrative Zugriffe sind begrenzt.

Administrativer Zugriff auf unsere Produktionssysteme ist auf Personen beschränkt, die diesen Zugriff für Betrieb, Wartung oder Sicherheit tatsächlich benötigen.

Derzeit liegt der technische Produktionszugriff beim technischen Betreiber von Acadex.

Serverzugriff

Administrativer SSH-Zugriff erfolgt ausschließlich über personenbezogene SSH-Schlüssel.

Passwortbasierte SSH-Anmeldung ist deaktiviert.

Mehrfaktor-Authentifizierung

Administrative Accounts bei:

• STRATO,
• Plesk,
• GitHub

werden mit Multi-Faktor-Authentifizierung geschützt.

Zukünftige Administratoren erhalten individuelle Accounts.

Gemeinsam genutzte Administrationsaccounts sind nicht vorgesehen.

Entwicklungs- und Produktionssysteme sind getrennt.

Entwicklungs- und Testumgebungen sind von der Produktionsumgebung getrennt.

Produktionsdaten werden nicht regulär in Entwicklungs- oder Testsysteme kopiert.

Acadex wird als containerisierte Anwendung entwickelt und betrieben.

Der Quellcode wird in Git verwaltet.

Änderungen erfolgen über Feature-Branches und Pull Requests und können durch automatisierte Tests sowie manuelle Reviews geprüft werden.

Produktivdeployments werden derzeit durch den technischen Betreiber von Acadex durchgeführt.

Secrets werden getrennt verwaltet.

Dauerhafte Zugangsdaten und Schlüssel werden in einem dafür vorgesehenen verschlüsselten Passwortmanager verwaltet.

Das Schlüsselmaterial für diesen Passwortmanager wird auf einem getrennten physischen Medium aufbewahrt und zusätzlich gesichert.

Zur Laufzeit werden benötigte Secrets als Umgebungsvariablen in die jeweiligen Systeme eingebracht.

Der Schlüssel für die Verschlüsselung von Anwendungsinhalten wird getrennt von der Anwendungsdatenbank gespeichert.

Secrets werden regelmäßig sowie bei konkretem Verdacht auf eine Kompromittierung ausgetauscht.

Logs enthalten keine Gesprächsinhalte.

Gesprächsinhalte werden nicht routinemäßig in operative Logs geschrieben.

Für technische Fehleranalysen können interne Nutzerkennungen protokolliert werden.

IP-Adressen werden unter anderem für technische Sicherheitsmaßnahmen wie Rate Limiting und Missbrauchsprävention verwendet.

Operative Logs bleiben grundsätzlich sieben Tage auf den Produktivsystemen.

Anschließend werden erforderliche Logs komprimiert und verschlüsselt auf einen getrennten Archivserver übertragen.

Dort werden sie höchstens drei Monate aufbewahrt und anschließend gelöscht.

Der Zugriff auf Logs ist auf entsprechend berechtigte Personen beschränkt.

Verfügbarkeit und Backups

Acadex wird derzeit auf einer einzelnen Anwendungsinstanz betrieben.

Die Architektur kann grundsätzlich auf mehrere Instanzen erweitert werden, eine Hochverfügbarkeitsarchitektur ist derzeit jedoch nicht produktiv eingerichtet.

Ein Ausfall dieser Instanz kann deshalb zu einer vorübergehenden Unterbrechung von Acadex führen.

Wir behaupten entsprechend keine Hochverfügbarkeit, die technisch noch nicht vorhanden ist.

Unterschiedliche Daten brauchen unterschiedliche Backups.

Nicht alle Acadex-Daten haben denselben Charakter.

Unsere zentrale PostgreSQL-Datenbank enthält insbesondere nicht ohne Weiteres rekonstruierbare Account- und Nutzerdaten.

Sie wird deshalb zusätzlich unabhängig vom vollständigen Forschungsdatenbestand gesichert.

Andere große Datenbestände können dagegen aus ihren jeweiligen Primärquellen erneut aufgebaut werden.

Dazu gehören insbesondere Teile unserer:

• bibliografischen Daten,
• Suchindizes,
• Vektordaten.

Diese Unterscheidung ermöglicht es uns, den Schutz nicht rekonstruierbarer Nutzerdaten gezielter zu behandeln.

Was wir derzeit nicht versprechen.

Sicherheitsdokumentation wird nicht besser, wenn jeder offene Punkt sprachlich versteckt wird.

Deshalb sagen wir ausdrücklich, welche Maßnahmen oder Nachweise derzeit noch fehlen.

Keine ISO-27001-Zertifizierung

Acadex ist derzeit nicht nach ISO/IEC 27001 zertifiziert.

Kein SOC-2-Bericht

Wir verfügen derzeit über keinen SOC-2-Prüfbericht.

Noch kein externer Penetrationstest

Acadex wurde bislang nicht durch einen unabhängigen Anbieter einem formalen externen Penetrationstest unterzogen.

Noch keine MFA für individuelle Acadex-Accounts

Administrative Systeme sind bereits mit MFA geschützt.

Für individuelle Acadex-Nutzeraccounts steht MFA derzeit noch nicht zur Verfügung.

Noch kein institutionelles SSO

Shibboleth, DFN-AAI oder vergleichbare institutionelle Single-Sign-on-Lösungen sind derzeit noch nicht verfügbar.

Keine produktive Hochverfügbarkeitsarchitektur

Acadex läuft aktuell auf einer einzelnen Anwendungsinstanz.

Noch kein allgemeines SLA

Wir veröffentlichen derzeit keine allgemeine garantierte Verfügbarkeit.

Für institutionelle Vereinbarungen können konkrete Anforderungen separat besprochen werden.

Noch keine veröffentlichten RTO- oder RPO-Garantien

Wir definieren und testen unsere Wiederherstellungsprozesse weiter, bevor wir verbindliche Recovery-Time- oder Recovery-Point-Zusagen veröffentlichen.

Noch kein zertifiziertes ISMS

Wir dokumentieren konkrete Sicherheitsmaßnahmen und Prozesse, betreiben derzeit aber kein zertifiziertes Informationssicherheits-Managementsystem.

Monitoring

Der technische Betrieb wird derzeit administrativ überwacht.

Ein umfassendes externes Uptime- und Alerting-System befindet sich noch im Ausbau.

Wir veröffentlichen deshalb keine Aussage wie „24/7 überwacht“, solange diese technisch nicht der Realität entspricht.

Die Einführung eines systematischen Monitoring- und Alerting-Setups ist Teil unserer weiteren Infrastrukturentwicklung.

Sicherheitsvorfälle

Wenn ein möglicher Sicherheitsvorfall festgestellt wird, liegt die technische Reaktion beim technischen Betreiber von Acadex.

Dabei werden insbesondere:

• der Vorfall eingegrenzt,
• betroffene Zugänge und Schlüssel geprüft beziehungsweise gesperrt,
• relevante Logs gesichert,
• betroffene Systeme und Daten untersucht,
• Auswirkungen auf Personen und Kunden bewertet,
• notwendige technische Maßnahmen durchgeführt,
• sowie mögliche Informations- und Meldepflichten geprüft.

Für institutionelle Kunden gelten zusätzlich die im jeweiligen Auftragsverarbeitungsvertrag vereinbarten Informationspflichten.

Eine Schwachstelle gefunden?

Wenn du glaubst, eine Sicherheitslücke in Acadex gefunden zu haben, schreib uns bitte an:

info@acadex.io

Beschreibe das Problem möglichst so, dass wir es reproduzieren können.

Bitte:

• greife nicht auf Daten anderer Nutzer zu,
• verändere keine fremden Daten,
• vermeide Tests, die den Dienst für andere beeinträchtigen könnten.

Wir bestätigen den Eingang und informieren über die weitere Bearbeitung.

Sicherheitsproblem melden →

Was institutionelle Kunden zusätzlich festlegen können

Bei institutionellen Accounts kann die technische Konfiguration zusätzliche Vorgaben enthalten.

Dazu können insbesondere gehören:

• zulässige Modellanbieter,
• geografische Anforderungen an die Verarbeitung,
• Beschränkung bestimmter Providerprofile,
• persönliche Seats,
• Abrechnungs- und Vertragsvorgaben.

Welche Einstellungen für eine konkrete Institution gelten, wird in der jeweiligen Konfiguration und – soweit erforderlich – im Auftragsverarbeitungsvertrag dokumentiert.

Weitere Dokumente

Technische und organisatorische Maßnahmen

Unsere TOM beschreiben die konkreten technischen und organisatorischen Schutzmaßnahmen ausführlicher.

Technische und organisatorische Maßnahmen ansehen →

Externe Dienste & Unterauftragsverarbeiter

Welche externen Dienste Daten erhalten können, wofür sie eingesetzt werden und welche Providerprofile möglich sind.

Externe Dienste & Unterauftragsverarbeiter ansehen →

Auftragsverarbeitungsvertrag

Die vertragliche Grundlage für institutionelle Verarbeitung im Auftrag.

Auftragsverarbeitungsvertrag ansehen →

Datenschutzerklärung

Welche personenbezogenen Daten wir verarbeiten, zu welchen Zwecken und auf welcher Rechtsgrundlage.

Datenschutzerklärung ansehen →

Cookie Policy

Welche Informationen wir im Browser speichern und warum hierfür derzeit kein allgemeiner Consent-Banner erforderlich ist.

Cookie Policy ansehen →

Fragen?

Wenn etwas auf dieser Seite unklar ist oder eine institutionelle Anforderung hier nicht beantwortet wird, schreib uns.

Gerade bei Sicherheitsfragen ist uns eine konkrete Frage lieber als eine möglichst beruhigende Formulierung.

info@acadex.io