Systemarchitektur und Datenschutz
Wie Ephraim technisch aufgebaut ist und welche Maßnahmen den Datenschutz im schulischen Betrieb absichern. Ephraim ist die KI- und Projektplattform des Lessing-Gymnasiums Karlsruhe.
1. Was ist das System?
Ephraim ist eine schulische Webplattform für KI-gestütztes Lernen, Chat, Dateiablage, Projektarbeit und Wissensquellen. Sie besteht aus zwei klar getrennten Teilen:
- Webserver (Ephraim-Anwendung): Anmeldung, Chat-Oberfläche, Verwaltung, verschlüsselte Speicherung, Projekte und das Einbinden von Basiswissen aus konfigurierten Quellen — einschließlich Abrufe per URL, die nur der Webserver durchführt.
- Ephraim Spark: Dedizierte KI-Hardware im isolierten LAN. Sie führt Sprachmodell, Embedding-Dienst, Text-zu-Sprache (TTS), Runtime und Supervisor aus.
2. Physische und logische Infrastruktur
Die relationale Datenbank läuft in Produktion auf MySQL auf dem Webserver. Zusätzlich kann auf demselben Host ein Redis/Valkey-kompatibler Speed-Layer laufen. Er ist nur maschinenintern erreichbar und dient nicht als dauerhafte Datenbank. Nutzerinnen und Nutzer greifen von zu Hause oder aus dem Unterricht per Browser auf den Webserver zu; dieser ist der einzige Teil von Ephraim, der nach außen sichtbar ist. E-Mails (Zugangsdaten, Sicherheitshinweise) versendet der Webserver über den separaten Mailserver im Schulnetz.
3. Aufbau der Ephraim-Anwendung
| Bereich | Aufgabe |
|---|---|
| Benutzeroberfläche | Chat, Dateien, Projekte, Einstellungen, Hilfe |
| Anwendungslogik | Anmeldung, Rollen, Vault, Chat-Verarbeitung, Projekte, Uploads |
| Datenbank (MySQL) | Konten, Metadaten, verschlüsselte Chat-Inhalte, Projekte |
| Redis/Valkey-Speed-Layer | Kurzlebige verschlüsselte Stream-Puffer und Worker-Wakeups auf demselben Host |
| Dateispeicher | Verschlüsselte persönliche Dateien außerhalb des öffentlich erreichbaren Webroots |
| Basiswissen | Schulische Quellen und freigegebene externe URLs — Abruf und Aufbereitung durch den Webserver |
4. Ephraim Spark
Die Spark ist die schuleigene KI-Hardware. Für Version 1 von Ephraim laufen dort das zentrale Sprachmodell GPT-OSS-120B (OpenAI-kompatibles 120-Milliarden-Parameter-Modell, lokal gehostet) sowie ein TTS-Dienst für das Vorlesen von Chat-Antworten.
Das Sprachmodell ist dabei als Inferenzprofil betrieben, nicht als fest in die Oberfläche eingebauter Bestandteil. Ephraim spricht den lokalen Inferenzdienst über denselben OpenAI-kompatiblen Endpunkt an. Der aktuelle produktive und dokumentierte Stand nutzt GPT-OSS-120B. Externe Modellanbieter und externe Modellproxys gehören nicht zur freigegebenen V1-Konfiguration; jede Abweichung vom dokumentierten GPT-OSS-120B-Pfad wäre neu zu bewerten und zu dokumentieren.
| Komponente | Funktion in V1 |
|---|---|
| Inference | Erzeugt Chat-Antworten mit GPT-OSS-120B |
| Embeddings | Berechnet Vektoren für semantische Suche, Projektmaterial und Basiswissen-Retrieval |
| TTS | Wandelt ausgewählten Chat-Text in gesprochene Sprache um (Vorlesen-Funktion) |
| Runtime | Technisches Monitoring und administrierte Betriebsaktionen |
| Supervisor | Geplante Updates, Job-Status, Audit-Export für Super-Admins |
Embeddings und Retrieval in der Webanwendung
Der Retrieval-Pfad von Version 1 liegt in der Webanwendung. Ephraim extrahiert Text, zerlegt ihn in kurze Abschnitte, prüft Rechte, verschlüsselt Abschnittstext und Vektor und speichert beides in MySQL.
Für die reine Vektorberechnung ruft die Webanwendung den konfigurierten
OpenAI-kompatiblen /embeddings-Endpunkt auf. Im lokalen Spark-Stack ist
dieser Endpunkt der lokale SGLang-Embedding-Dienst
school-ui-embedding. Ephraim nutzt ihn aktuell direkt für Datei-RAG,
Projektmaterial-RAG und Basiswissen-RAG.
Der Embedding-Endpunkt erzeugt keine Antworttexte, sondern Zahlenlisten: Ein
Klartext-Chunk und eine Suchfrage werden in denselben mathematischen Raum übersetzt.
Ähnliche Inhalte liegen dort näher beieinander als unähnliche Inhalte. Die Spark speichert
diese Klartexte, Suchfragen und Vektoren dabei nicht dauerhaft.
Bei einer späteren Frage erzeugt der Webserver einen Fragevektor und vergleicht ihn mit den gespeicherten Vektoren. Bewertet werden nur Abschnitte, die für diese Person, Rolle und Situation zugelassen und entschlüsselbar sind. Auswahl, Zugriffskontrolle, Entschlüsselung, Cosinus-Vergleich und Kontextaufbau passieren in Ephraim auf dem Webserver.
Beim Vorlesen sendet der Webserver den markierten Text verschlüsselt an den TTS-Dienst auf der Spark und gibt die erzeugte Sprachausgabe an den Browser weiter. Der Browser spricht den Text nicht an externe Cloud-Dienste.
5. Datenfluss: Vorlesen mit Spark-TTS
Die Vorlesefunktion ist in der Architektur ein eigener Spark-Pfad. Sie benutzt nicht das Chatmodell, sondern einen internen Text-zu-Sprache-Dienst auf der Spark. Der Browser kennt weder die interne TTS-Adresse noch den Authentifizierungstoken; beides bleibt auf dem Webserver.
| Schritt | Schutzmaßnahme |
|---|---|
| Browser sendet Vorlesewunsch | Nur angemeldete Sitzungen; mutierende Anfrage mit CSRF-Token. |
| Webserver prüft Text | Roh-Request-, Text- und Audio-Größenlimits; Sitzungs-, Nutzer- und IP-Rate-Limits; Parallelitätsgrenzen, unterstützte Sprachen, begrenzte Geschwindigkeit, kein Markup. |
| Webserver ruft Spark-TTS auf | Interne URL aus der Serverkonfiguration, Bearer-Token serverseitig, kurzer Verbindungs- und Gesamttimeout. |
| Spark erzeugt Audio | Antwortformat WAV; keine Text-/Audio-, Access- oder Syntheselogs im Normalbetrieb; Fehler wie Warteschlange, falsche Konfiguration oder unerreichbarer Dienst werden abgefangen. |
| Browser spielt Audio ab | Antwort mit Cache-Control: no-store; Waveform-Peaks werden lokal berechnet und nicht gespeichert. |
Wenn der interne TTS-Dienst nicht konfiguriert ist, bleibt die Vorlesefunktion deaktiviert. Die Oberfläche nutzt keine lokale Web-Speech-Funktion des Browsers als Ersatz. Die Architektur von Ephraim sieht für den schulisch kontrollierten Betrieb ausschließlich den Spark-TTS-Pfad vor.
6. Datenfluss: typischer KI-Chat
- Die angemeldete Person sendet eine Nachricht über den Browser.
- Der Webserver prüft Sitzung, Berechtigung und ob der persönliche Vault entsperrt ist.
- Personalisierte Einstellungen, Projekt-Kontext und optional Basiswissen werden zusammengestellt.
- Die Anfrage geht verschlüsselt per HTTPS an die Spark; GPT-OSS-120B erzeugt die Antwort.
- Die Antwort wird zurückgestreamt und der Verlauf verschlüsselt in MySQL abgelegt.
7. MySQL und Redis/Valkey
MySQL und Redis/Valkey erfüllen in Ephraim unterschiedliche Aufgaben. MySQL ist die dauerhafte Datenbank. Dort liegen Konten, Projekte, Einstellungen, Jobzustände, verschlüsselte Chatdaten, verschlüsselte Stream-Fallbacks, verschlüsselte Chunks und verschlüsselte Embedding-Vektoren. Redis/Valkey ist dagegen ein schneller Kurzzeitpuffer für laufende Arbeit.
| Komponente | Rolle | Datenschutzgrenze |
|---|---|---|
| MySQL | Dauerhafte Wahrheit des Systems | Private Inhalte liegen verschlüsselt; Rechte und Schlüssel entscheiden, wer etwas nutzen kann. |
| Redis/Valkey | Maschineninterner Speed-Layer für laufende Streams und Worker-Wakeups | Keine Klartext-Chats, Dateien, Vault-Schlüssel, Passwörter, Nutzerprofile, Sessions oder RAG-Klartexte. |
| Datenbank-Fallback | MySQL kann Stream-Puffer auch ohne Redis/Valkey tragen | Redis/Valkey beschleunigt, ersetzt aber nicht die dauerhafte Speicherung. |
Für Nutzer ist das am besten mit einem Schreibtisch vergleichbar: MySQL ist der verschlossene Aktenschrank. Redis/Valkey ist der kleine Zettel auf dem Tisch, der nur während einer laufenden Antwort hilft, den nächsten Schritt schnell zu finden. Auf diesem Zettel steht nicht der Chat im Klartext, sondern nur kurzlebige verschlüsselte Arbeitsdaten und technische Signale.
8. Basiswissen und Internetzugriff
Ephraim kann schulisches Basiswissen in Chats einbeziehen — zum Beispiel freigegebene Dokumente, Kalender, Wetter oder Wikipedia. Diese Quellen werden vom Webserver abgerufen, geprüft und aufbereitet.
- Der Webserver darf konfigurierte URLs und Dienste ansprechen.
- Die Spark hat keinen eigenen Internet-Browser und ruft keine URLs selbst ab.
- Das Sprachmodell erhält nur den Kontext, den die Anwendung bewusst freigibt.
Private Kalender sind dabei kein zentrales Schulwissen. Sie gehören fachlich zum privaten Konto, sind an den persönlichen Vault gebunden und werden nur im normalen Chat dieses Kontos sowie in „Mein Ephraim“ berücksichtigt. Projektbuilder, Projektchats und andere Nutzer erhalten diesen privaten Kalenderkontext nicht.
Das unterscheidet Ephraim von einem öffentlichen Chatbot mit freiem Webzugang: Externe Inhalte fließen nur über festgelegte, schulisch kontrollierte Wege ein.
9. Hintergrundjobs, Datenlebenszyklus und Chat-Limit
Ephraim arbeitet nicht nur während eines Seitenaufrufs. Neben Browser, Webserver und Spark gibt es eine Wartungsschicht für Aufgaben, die geplant, begrenzt und kontrollierbar laufen müssen. Diese Schicht ist für den Datenschutz wichtig, weil sie Aufbewahrung, Aufräumen und technische Pflege erzwingt, ohne private Vaults im Hintergrund zu öffnen.
| Bereich | Was passiert | Grenze |
|---|---|---|
| Cron | Bereinigt Rate-Limits, abgelaufene KI-Jobs, temporäre Exporte, verwaiste Dateien, alte Sicherheitsereignisse und archivierte Projekte. | Cron besitzt keinen User-DEK und öffnet keine persönlichen Vaults. |
| Knowledge-Refresh | Aktualisiert freigegebene globale Quellen und Wetterdaten serverseitig. | Private Kalender werden nicht massenhaft im Cron entschlüsselt; sie brauchen den entsperrten Vault des Besitzers. |
| KI-Jobs und Streams | Verwalten Antwortgenerierung, Wiederaufnahme, Artefakte, MySQL-Fallback und optional Redis/Valkey als schnellen Stream-Puffer. | Technische Puffer sind kein langfristiges Inhaltsarchiv; Redis/Valkey enthält keine Klartextinhalte. |
| Drittanbieter-Komponenten | Werden lokal inventarisiert, geprüft und über Adminfreigaben kontrolliert. | Die Manuals und die App-Oberfläche brauchen keine externen CDN-Ressourcen für den normalen Betrieb. |
Für gespeicherte Chats kann die Schule ein Chat-Aufbewahrungslimit pro Konto setzen. Ist dieses Limit erreicht, legt Ephraim keinen weiteren gespeicherten Chat an. Bestehende Chats bleiben lesbar, fortsetzbar, exportierbar, umbenennbar und löschbar. Die Nutzerin oder der Nutzer entscheidet im Aufräumdialog, welcher nicht mehr benötigte Chat gelöscht wird; Ephraim löscht alte Chats nicht heimlich im Hintergrund.
10. Verschlüsselung: der persönliche Vault
| Situation | Was ist lesbar? |
|---|---|
| Nur Datenbank- oder Speicher-Backup | Verschlüsselte Inhalte, keine privaten Klartexte ohne Passwort |
| Angemeldete Person, Vault entsperrt | Eigene Chats, Dateien und Einstellungen |
| Lehrkraft im Projekt | Projektmaterial und Metadaten — keine privaten Schüler-Chats |
| Administrator | Konten, Rollen, Systemeinstellungen — kein Klartext fremder Vault-Inhalte |
| KI-Request auf der Spark | Prompt und freigegebener Kontext nur für diesen Request im Arbeitsspeicher |
Persönliche Dateien liegen verschlüsselt auf dem Webserver. Beim Download werden sie im Arbeitsspeicher entschlüsselt und direkt an den Browser gesendet — es entsteht keine dauerhafte Klartext-Kopie auf der Platte. Wird eine private Datei in ein Lehrerprojekt übernommen, entsteht eine getrennte Projektkopie; das private Original bleibt geschützt.
Onboarding, Passwortwechsel und Passwort-Recovery gehören deshalb zur Architektur: Wer sein Passwort kennt, kann den bestehenden Vault neu verpacken. Wer es vergessen hat, braucht eine vorbereitete datenerhaltende Recovery oder muss einen datenlöschenden Reset akzeptieren.
11. Rollen und Zugriffskontrolle
| Rolle | Typische Rechte | Datenschutzrelevant |
|---|---|---|
| Schüler:in | Chat, eigene Dateien, Einstellungen, Projektbeitritt | Sieht nur eigene Vault-Inhalte |
| Lehrkraft | Projekte anlegen, Materialien, Anweisungen für Projekte | Kein Zugriff auf private Schüler-Chats |
| Administrator | Nutzerverwaltung, Klassen, Quotas, Systemeinstellungen | Verwaltungsdaten, keine fremden Vault-Klartexte |
| Super-Admin | Technische Betriebsführung, Updates, Audit-Berichte | Administration mit redigierten Protokollen |
Anmeldung ist passwortgeschützt; optional mit Zwei-Faktor-Authentifizierung. Aktive Sitzungen können eingesehen und beendet werden.
Besonders wichtig ist die Projektgrenze: Eine Lehrkraft steuert Auftrag, Material, Teilnehmende und Abschlussregeln, aber sie öffnet keine privaten Schülerchats und keine Projektchat-Rohtexte. Sichtbar sind reduzierte Projektinformationen wie Teilnahme, Aktivität, Abschluss, Nachrichtenimpulse, Fazitstatus und die ausdrücklich aktivierten Fazit- oder Monitoring-Ergebnisse. Die Details stehen im Artikel Projekte: Datenschutz.
12. Wie Datenschutz technisch abgesichert wird
Organisatorisch und architektonisch
- Schulische Plattform — kein öffentlicher Massenmarkt-Chatbot.
- Keine Weitergabe von KI-Anfragen an externe Modellanbieter.
- Datenpfad nachvollziehbar: Schule → isoliertes LAN (getrennt vom Schulnetz) → Spark, nicht anonyme Cloud-Kette.
- Freiwillige Inhalte (Personalisierung, private Quellen) nur bei bewusster Nutzung.
Technische Schutzmaßnahmen
- HTTPS für Browser, für die Verbindung Webserver ↔ Spark (Chat und TTS) sowie für den Mailversand.
- Verschlüsselter persönlicher Vault für Chats und Dateien.
- Strikte Rollentrennung; Lehrkräfte sehen keine privaten Schüler-Chats.
- Geprüfte Datei-Uploads mit Typ-Whitelist und Virenscan.
- Kein werbebasiertes Tracking; datensparsame Sicherheitsprotokollierung.
- Lokale Auslieferung von App- und Handbuch-Ressourcen; Drittanbieter-Komponenten werden inventarisiert und kontrolliert.
- Datenexport und Löschung über „Meine Daten“ bzw. schulische Ansprechpersonen.
Logging
- Der Produktions-Webserver dient nicht als Inhaltsprotokoll: keine Request-Bodies, keine Chatnachrichten, keine Datei-Payloads, keine Cookies und keine Tokens als Diagnosequelle.
- Die Spark protokolliert keine fachlichen KI-Requests, Prompts, Modellantworten, TTS-Texte, Audiodaten oder Schlüsselmaterial.
- Erlaubt sind technische Metriken (z. B. Latenz, Tokenzählungen), gekürzte Statusmeldungen und redigierte Admin-Audits.
- Die Betriebsdetails stehen im Administratorartikel Logging.