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), internen Broker, Observer, Runtime, Supervisor und Logrotation aus.
2. Physische und logische Infrastruktur
Optional kann auf dem Webserver ein Redis/Valkey-kompatibler Speed-Layer eingerichtet werden. Er dient als flüchtige, verschlüsselte Beschleunigung und ersetzt nicht die dauerhafte Datenbank. Nutzerinnen und Nutzer greifen per Browser über HTTPS auf die Webanwendung zu. E-Mails versendet die Webanwendung über den eingerichteten Mailserver. Auch die Verbindung vom Webserver zur Spark ist im Produktivbetrieb ausschließlich HTTPS. Die Entwicklung kann einen getrennten Tailscaleweg verwenden.
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 schuleigene NVIDIA DGX Spark besitzt einen GB10-Chip und 128 GB gemeinsamen Arbeitsspeicher für CPU und GPU. Auf dem aktuellen Backend laufen acht getrennte Dienste. GPT-OSS-120B erzeugt Chatantworten mit vLLM, SGLang berechnet separat Embeddings und ein nativer S2-Pro-Dienst erzeugt die Sprachausgabe. Die Dienste teilen sich die Hardware. Getrennte Container schaffen deshalb keine voneinander unabhängigen GPU- oder Speicherreserven.
Das Sprachmodell ist als geprüftes Inferenzprofil eingerichtet. Die Chatengine ist derzeit auf höchstens 32 gleichzeitige Modellvorgänge und 32.768 Tokens je Kontext begrenzt. Der Webserver entscheidet weiterhin über Anmeldung, erlaubten Kontext, Aufnahme und Warteschlangen. SGLang bleibt die Grundlage des getrennten Embedding-Dienstes. Andere vorbereitete Modellprofile sind keine automatische Freigabe für den regulären V1-Chatpfad. Gemessene Kapazität und Wartezeiten stehen im Handbuch Inferenz-Benchmarks.
| Komponente | Funktion in V1 |
|---|---|
| Inference | Erzeugt Chatantworten mit GPT-OSS-120B über vLLM |
| Embeddings | Berechnet mit SGLang Vektoren für semantische Suche, Projektmaterial und Basiswissen |
| TTS | Wandelt ausgewählten Chattext mit dem nativen S2-Pro-Dienst in gesprochene Sprache um |
| Runtime | Technisches Monitoring und administrierte Betriebsaktionen |
| Interner Broker | Begrenzt Docker-Lesezugriffe auf fest freigegebene Dienste und technische Zustände |
| Observer | Liefert der Runtime über lokale Unix-Sockets begrenzte Zustände und technische Logstreams vom Broker, ohne eigenen Docker-Socket oder Netzwerkport |
| Supervisor | Geprüfte Updates, Jobstatus und geschützter Export technischer Sitzungsmetadaten mit redigierten Vorschauen für Super-Admins |
| Logrotate | Rotiert technische Spark-Logdateien täglich und erscheint als eigener überwachter Container im Admin-Status |
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 getrennten lokalen SGLang-Embedding-Dienst auf. Ephraim nutzt ihn für freigegebene Dateien, Projektmaterial und Basiswissen. Aus einem Textabschnitt und einer Suchfrage entstehen vergleichbare Zahlenlisten. Die Spark speichert diese Anfragetexte und Vektoren nicht dauerhaft. Auswahl, Rechteprüfung und verschlüsselte Speicherung bleiben beim Webserver.
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 ausschließlich den ausgewählten Text an S2-Pro. Im Produktivbetrieb erfolgt auch dieser private Backendabruf ausschließlich per HTTPS. Der Webserver gibt den Audiostream an den Browser weiter. Die Stimmenliste und die Synthese verlangen den serverseitigen Bearer-Token. Nur die technische Healthabfrage des Sprachdienstes bleibt ohne diesen Token erreichbar. Eine solche Healthantwort beweist allein noch keine funktionsfähige authentifizierte Sprachausgabe.
5. Datenfluss: Vorlesen mit Spark-TTS
Die Vorlesefunktion verwendet den nativen S2-Pro-Dienst auf der Spark und ist vom Chatmodell getrennt. Der Webserver fordert die gewählte Stimme an, S2-Pro erkennt die Textsprache selbst. Die interne Adresse und der Authentifizierungstoken bleiben auf dem Webserver. Der Browser erhält gestreamte Audioteile zur Wiedergabe, keine Zugangsdaten zum Backend.
| Schritt | Schutzmaßnahme |
|---|---|
| Browser sendet Vorlesewunsch | Nur angemeldete Sitzungen; mutierende Anfrage mit CSRF-Token. |
| Webserver prüft Text | Anmeldung und CSRF-Schutz, Text- und Audiogrößenlimits, Aufnahmegrenzen je Sitzung und Nutzer sowie übergreifende Parallelitätsgrenzen. Die Stimme wird geprüft, Sprache und Sprechtempo werden nicht als Syntheseparameter vorgegeben. |
| Webserver ruft Spark-TTS auf | Privater Backendweg, im Produktivbetrieb ausschließlich HTTPS, serverseitiger Bearer-Token sowie feste Verbindungs- und Laufzeitgrenzen. |
| Spark erzeugt Audio | Streamt rohe PCM-Audioteile an den Webserver. Der Webserver reicht sie in begrenzten Teilen an den Browser weiter und legt keine Audiodatei an. Auslastung, falsche Konfiguration und Übertragungsfehler 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 gelangt im Produktivbetrieb ausschließlich per HTTPS über den privaten Backendweg 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 bleibt der dauerhafte Stream- und Jobpfad | Redis/Valkey beschleunigt, speichert aber nichts persistent und ersetzt 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 Redis/Valkey als schnellen flüchtigen 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 und im Produktivbetrieb sämtliche Verbindungen zur Spark, einschließlich Chat, Embeddings, TTS und Betriebsdiensten. Der Mailversand wird gesondert abgesichert.
- 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.
- Runtime, Observer und interner Broker bilden eine begrenzte Lesekette. In dieser Lesekette besitzt nur der Broker den Docker-Socket. Der gesonderte Supervisor benötigt eigene Betriebsrechte. Broker und Observer haben keinen Netzwerkport und erlauben keine Containeränderungen oder frei wählbaren Befehle.
school-ui-logrotaterotiert Dateien unter/logstäglich mit 30 Rotationen. Docker-Stdout ist je Container auf ungefähr 50 MiB begrenzt. Abgeschlossene Supervisor-Jobs werden grundsätzlich nach 90 Tagen bereinigt. Für den aktuellen Stand, den Rückfallstand oder eine Wiederaufnahme benötigte Jobbelege bleiben geschützt.- Die Betriebsdetails stehen im Administratorartikel Logging.