Handbuch

Warum Ephraim nötig wurde

Ephraim wurde nicht gebaut, weil Schulen noch ein weiteres Chatfenster brauchen. Der Grund ist grundsätzlicher: KI wird im Unterricht erst dann wirklich nützlich, wenn sie mit echtem schulischem Kontext arbeiten darf. Dieser Kontext enthält schnell personenbezogene Daten. Ephraim ist der Versuch, diese Verarbeitung lokal, zweckgebunden, verschlüsselt und schulisch kontrollierbar zu machen.

· Stand: Juni 2026

1. Die kurze Antwort

Wir mussten Ephraim bauen, weil eine ernsthafte schulische KI-Plattform nicht dauerhaft so tun kann, als kämen im Unterricht keine personenbezogenen Daten vor. Sobald KI mehr leisten soll als allgemeine Beispieltexte, berührt sie Namen, Rollen, Klassen, Projekte, Arbeitsstände, Dateien, Termine, Interessen, Lernwege und Rückmeldungen.

Die Alternative wäre ein künstlich entkernter KI-Einsatz: Man dürfte nur abstrakte Fragen stellen, keine echten Materialien nutzen, keine persönlichen Arbeitsstände fortführen und keine Projektkontexte einbeziehen. Das wäre datenschutzrechtlich einfacher, pädagogisch aber deutlich schwächer.

Kernsatz: Ephraim entsteht aus der Einsicht, dass schulische KI nur dann sinnvoll wird, wenn personenbezogene Verarbeitung nicht verdrängt, sondern sauber begrenzt, geschützt und erklärt wird.

2. Warum Schule fast immer personenbezogen wird

Personenbezogene Daten sind nicht nur Noten oder Adressen. Im Schulalltag reicht oft schon ein Zusammenhang zu einer identifizierbaren Person. Ein Chat über ein eigenes Projekt, eine hochgeladene Datei, eine Frage zum Kalender, eine Reflexion über den Lernstand oder ein Lehrerfeedback kann personenbezogen sein, auch wenn niemand etwas besonders Sensibles eingeben wollte.

Schulischer Vorgang Warum Personenbezug entsteht
Persönlicher Chat Der Verlauf gehört zu einem Konto und kann Interessen, Fragen oder Schwierigkeiten zeigen.
Projektarbeit Teilnahme, Arbeitsstand, Materialien und Abschluss hängen an konkreten Schülerinnen und Schülern.
Dateien Arbeitsblätter, Entwürfe, Fotos, Protokolle oder Texte können Namen, Leistungen oder persönliche Bezüge enthalten.
Personalisierung Eine hilfreiche Begrüßung, Erinnerungen oder Interessen setzen voraus, dass das System etwas über die Person behält.
Fazit und Monitoring Auch reduzierte Projektmetadaten sagen etwas über Teilnahme, Aktivität und Abschlussstatus aus.

Genau deshalb ist „Wir geben einfach keine personenbezogenen Daten ein“ keine tragfähige Grundlage für eine schulweite Plattform. Es kann als Vorsichtsregel für einzelne Experimente funktionieren. Für Unterricht, Projekte, Dateiablage, persönliche Arbeitsräume und langfristige Nutzung reicht es nicht.

3. Warum anonyme KI pädagogisch schnell an Grenzen kommt

Eine KI ohne echten Kontext kann allgemeine Erklärungen liefern. Sie kann eine Formel erklären, einen Beispieltext verbessern oder ein Diagramm beschreiben. Das ist nützlich, aber es bleibt vom konkreten Unterricht getrennt. Schule arbeitet dagegen mit Aufgaben, Materialien, Klassen, Lernständen, Rückfragen und Projekten, die über mehrere Tage oder Wochen laufen.

Wenn KI dabei helfen soll, muss sie wissen, woran gerade gearbeitet wird. Sie muss ein Projektmaterial kennen, eine frühere Frage wiederfinden, eine Datei einordnen oder einen Auftrag der Lehrkraft berücksichtigen. In diesem Moment entsteht Verantwortung: Wer entscheidet, welcher Kontext zugeschaltet wird? Wer darf ihn sehen? Wie lange bleibt er gespeichert? Wer kann ihn löschen? Welche Auswertung sieht die Lehrkraft?

Praktische Folge: Pädagogisch sinnvolle KI braucht Kontext. Datenschutz bedeutet deshalb nicht Kontextverbot, sondern kontrollierte Kontextverarbeitung.

4. Rechtlich möglich ist nicht automatisch praktisch beherrschbar

Dieser Artikel behauptet nicht, dass Schulen niemals externe KI-Dienste einsetzen dürfen. Je nach Dienst, Vertrag, Konfiguration, Schulträger, Rechtsgrundlage, Datenkategorie und Einsatzkonzept kann eine externe Verarbeitung rechtlich prüfbar sein. Genau diese Einzelfallprüfung bleibt wichtig.

Das praktische Problem liegt woanders: Eine Schule muss die Verarbeitung erklären und verantworten können. Dazu gehören Zweckbindung, Datenminimierung, Speicherfristen, technische und organisatorische Maßnahmen, Auftragsverarbeitung, Unterauftragnehmer, mögliche Drittlandbezüge, Supportzugriffe, Protokollierung, Löschung, Rollenrechte und die Frage, ob sich das Produktverhalten später ändert.

Für Ephraims Zielbild war diese Lage zu eng. Wir wollten nicht nur eine rechtlich vertretbare Chatlösung, sondern eine Plattform, die mit echten Schulkontexten arbeitet und trotzdem nachvollziehbar bleibt. Dafür ist eine eigene, lokale Architektur der belastbarere Weg.

5. Der technische Kern: KI muss Klartext sehen

Verschlüsselung ist zentral, aber sie löst nicht jede Frage. Ein Sprachmodell kann eine Antwort nur berechnen, wenn es die konkrete Frage und den erlaubten Kontext im Klartext verarbeitet. Ende-zu-Ende-Verschlüsselung gegenüber der Stelle, die die Antwort berechnet, ist bei normaler KI-Inferenz deshalb kein einfacher Schalter.

Transportverschlüsselung schützt den Weg. Verschlüsselung auf Platte schützt gespeicherte Daten. Beides ist wichtig. Aber irgendwo muss der Text für die Antworterzeugung entschlüsselt im Arbeitsspeicher liegen. Bei einem externen KI-Dienst liegt dieser Klartextmoment in der Infrastruktur dieses Dienstes. Bei Ephraim liegt er auf der schuleigenen Spark im isolierten Netzsegment.

Das ist der entscheidende technische und rechtlich-praktische Unterschied. Ephraim behauptet nicht, dass andere Anbieter keine Schutzmaßnahmen hätten. Ephraim entscheidet aber, dass der unvermeidbare Klartextmoment nicht in einer fremden KI-Cloud stattfinden soll, sondern auf einer lokalen Maschine unter schulischer Kontrolle.

Merksatz: KI braucht für die Antwort kurz Klartext. Ephraim verlegt diesen Klartextmoment in die eigene Infrastruktur und reduziert die dauerhafte Ablage wieder auf verschlüsselte Daten.

6. Warum Ephraim lokal rechnet

Ephraim trennt die sichtbare Webanwendung und die KI-Rechnung. Nutzerinnen und Nutzer arbeiten im Browser mit dem Webserver. Die eigentliche Antworterzeugung, Embeddings und das Vorlesen laufen auf der Ephraim Spark. Die Spark ist kein öffentlicher Webdienst, nutzt keinen freien Internetzugang für Antworten und speichert Anfragen nicht dauerhaft.

Diese Architektur passt zum schulischen Problem: Der Webserver prüft Anmeldung, Rollen, Projekte, Vault, Dateien und freigegebenes Basiswissen. Erst danach wird ein begrenztes Kontextpaket an die Spark geschickt. Die Spark berechnet daraus die Antwort und gibt sie zurück. Danach liegt der Verlauf wieder verschlüsselt im persönlichen Datenraum oder im jeweils vorgesehenen Projektkontext.

7. Die gemeinsame Herausforderung aller Anbieter

Jeder Anbieter einer schulischen KI-Lösung muss im Kern dieselben Fragen beantworten: Welche Daten darf das Modell sehen? Wo entsteht der unvermeidbare Klartextmoment? Wer betreibt die Infrastruktur? Welche Protokolle entstehen? Welche Unterauftragnehmer sind beteiligt? Wie funktionieren Löschung, Export, Rollenrechte, Supportzugriffe und spätere Produktänderungen?

Externe Dienste können darauf je nach Vertrag, Konfiguration, Betriebsmodell und Produktstand gute Antworten geben. Dieser Artikel bewertet solche Lösungen nicht pauschal. Für eine Schule bleibt aber die praktische Aufgabe, diese Antworten dauerhaft zu verstehen, zu prüfen und gegenüber Schulleitung, Schulträger, Eltern, Kollegium und Datenschutz zu vertreten.

Die Entscheidung für Ephraim verdichtet diese Herausforderungen in einem eigenen System. Statt sie auf viele Vertrags-, Produkt- und Cloud-Ebenen zu verteilen, macht Ephraim sie sichtbar: lokale Spark für den unvermeidbaren Klartextmoment, Vault für private Ablage, Rollenmodell für Zuständigkeiten, Projektgrenzen, sparsame Logs, Export und Löschung. Die Verantwortung verschwindet dadurch nicht. Sie wird konkreter und prüfbarer.

8. Was Ephraim dadurch ermöglicht

Der Eigenbau ist kein Selbstzweck. Er ermöglicht Funktionen, die in einer rein anonymen oder externen, für die Schule weniger unmittelbar kontrollierbaren KI-Nutzung nicht dieselbe Qualität hätten.

9. Was trotzdem Verantwortung bleibt

Lokale Verarbeitung macht Datenschutz nicht automatisch erledigt. Auch Ephraim braucht klare Rollen, gute Passwörter, kontrollierte Adminrechte, sichere Updates, sparsame Logs, Löschregeln, Backups, Schulungen und eine ehrliche Bewertung der verbleibenden Risiken. Der Unterschied ist: Diese Verantwortung liegt nicht versteckt in einer entfernten Produktkette, sondern wird im System sichtbar.

Deshalb dokumentiert Ephraim die Systemarchitektur, die Kryptoarchitektur, die Logging-Grenzen, die Dateiverarbeitung und den Entwicklungsprozess ausführlich. Wer die Plattform beurteilt, soll nicht nur eine Datenschutzbehauptung lesen, sondern die tatsächlichen Grenzen verstehen können.

10. Die eigentliche Antwort auf „Warum?“

Ephraim wurde gebaut, weil Schule KI nicht nur ausprobieren, sondern verantwortbar nutzen will. Das geht nur, wenn personenbezogene Daten nicht tabuisiert, sondern geschützt verarbeitet werden. Genau dafür kombiniert Ephraim lokale KI-Rechnung, persönliche Verschlüsselung, Rollen, Projekte, begrenzte Auswertungen und transparente Dokumentation.

Die Frage lautet deshalb nicht: „Warum baut eine Schule eine eigene KI?“ Die präzisere Frage lautet: „Wie soll eine Schule ernsthaft mit KI arbeiten, wenn sie echten Unterricht und personenbezogene Daten dauerhaft ausblenden muss?“ Ephraim ist die Antwort auf diese Spannung.