KI-Software an Schulen: DSGVO-Fallen beim Lizenzkauf

Fehlt eines dieser Merkmale, ist die Plattform für personenbezogene Schülerdaten mindestens problematisch. Bei kostenlosen Standardkonten fehlen häufig zusätzlich die erforderlichen Vertragsgrundlagen.

Die technische Leistungsfähigkeit eines Systems ist damit nur ein Teil der Kaufentscheidung. Ein Modell kann niedrige Antwortlatenzen, hohe Verfügbarkeit und brauchbare Ergebnisse liefern. Wenn jedoch Prompts, Schülerarbeiten oder Bewertungsdaten ohne belastbaren Rechtsrahmen verarbeitet werden, entsteht kein moderner Schulbetrieb, sondern ein nicht dokumentierter Datenfluss.

Für die KI-Software-Schule-DSGVO-Konformität müssen deshalb zwei Ebenen getrennt evaluiert werden:

• Technische Eignung: Modellqualität, Antwortzeit, Token-Limit, Rollenverwaltung und Verfügbarkeit.
• Rechtliche und organisatorische Eignung: Auftragsverarbeitung, Datenflüsse, Löschfristen, Unterauftragnehmer und Schulungsprozesse.

Erst wenn beide Ebenen ausreichend belastbar sind, ist eine Implementierung vertretbar.

Der häufigste Fehler: Ein Konto wird mit einer Schullizenz verwechselt

Ein persönliches Konto bei einem bekannten KI-Dienst ist technisch schnell angelegt. Das sagt wenig über die Nutzbarkeit im Unterricht aus. Kostenlose Standardkonten und private Verbrauchertarife sind für die Verarbeitung personenbezogener Schülerdaten im Schulbetrieb nicht geeignet, wenn ein Auftragsverarbeitungsvertrag fehlt oder die Datenschutzbedingungen keine ausreichenden Garantien bieten.

Der entscheidende Unterschied liegt nicht im Namen des Produkts, sondern in der Vertrags- und Betriebsarchitektur. Eine sogenannte Bildungs- oder Teamlizenz kann geeigneter sein als ein Privatkonto. Sie ist aber nicht automatisch datenschutzkonform. Auch ein bezahlter Tarif kann ungeeignet sein, wenn der Anbieter:

• keinen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO anbietet,
• Eingaben für das Training des eigenen Modells verwendet,
• Daten an weitere Dienstleister ohne transparente Kontrolle übermittelt,
• keine belastbare Löschfunktion oder Löschfrist dokumentiert,
• Daten außerhalb der Europäischen Union verarbeitet,
• keine Rollen- und Berechtigungskonzepte für Schulen bereitstellt.

Der Lizenzpreis ist daher kein Datenschutzindikator. Er misst den Funktionsumfang. Nicht die rechtliche Verwertbarkeit im Schulbetrieb.

Eine Schullizenz ist erst dann belastbar, wenn der Datenfluss vertraglich und technisch nachvollziehbar ist. Ein Schul-Logo im Vertriebsmaterial reicht nicht.

Was ein Auftragsverarbeitungsvertrag tatsächlich leisten muss

Für den rechtssicheren Einsatz von KI-Software an Schulen ist ein Auftragsverarbeitungsvertrag zwischen Schule beziehungsweise Schulträger und Anbieter erforderlich. Die Grundlage ist Art. 28 DSGVO. Der Vertrag muss nicht nur formal vorhanden sein. Er muss den konkreten Betrieb abbilden.

Zu prüfen sind mindestens diese Punkte:

• Gegenstand der Verarbeitung: Welche Funktionen werden genutzt? Textgenerierung, Korrekturhilfe, Bildanalyse oder Dokumentenverarbeitung haben unterschiedliche Datenrisiken.
• Kategorien personenbezogener Daten: Werden Namen, E-Mail-Adressen, Leistungsdaten, Förderbedarfe oder freie Texte verarbeitet?
• Zweckbindung: Darf der Anbieter die Daten ausschließlich zur Bereitstellung des Dienstes verwenden?
• Unterauftragnehmer: Welche weiteren Unternehmen betreiben Rechenzentren, Support, Sicherheitsdienste oder Modellkomponenten?
• Löschung und Rückgabe: Was geschieht mit Eingaben, Ausgaben, Protokollen und Sicherungskopien nach Vertragsende?
• Technische und organisatorische Maßnahmen: Verschlüsselung, Zugriffskontrolle, Protokollierung und Berechtigungssysteme müssen beschrieben sein.
• Meldewege bei Sicherheitsvorfällen: Die Schule braucht klare Fristen und Ansprechpartner.

Ein PDF mit allgemeinen Datenschutzbedingungen ersetzt diese Prüfung nicht. Entscheidend ist, ob der Anbieter als Auftragsverarbeiter tatsächlich vertraglich gebunden wird. Allgemeine Formulierungen wie eine mögliche Nutzung zur Verbesserung der Dienste sind im schulischen Kontext ein Warnsignal. Besonders dann, wenn sie nicht ausdrücklich auf die Eingaben der Bildungseinrichtung begrenzt werden.

Datenfluss statt Produktbeschreibung prüfen

Anbieter beschreiben KI-Produkte häufig über Modelle, Funktionen und Integrationen. Für die Schule ist zunächst eine andere Frage relevant: Welche Daten verlassen das eigene Verwaltungs- oder Lernsystem?

Ein typischer Ablauf kann mehrere Stationen enthalten:

1. Eine Lehrkraft meldet sich über ein Schulkonto an.

2. Der eingegebene Text wird an die Plattform übertragen.

3. Die Plattform leitet die Anfrage an ein Sprachmodell weiter.

4. Protokolldaten werden für Sicherheit, Abrechnung oder Fehleranalyse gespeichert.

5. Ein Unterauftragnehmer verarbeitet technische Metadaten.

6. Sicherungskopien bleiben für einen weiteren Zeitraum verfügbar.

Jede dieser Stationen muss in der Datenschutzbewertung auftauchen. Die Oberfläche der Anwendung zeigt davon meist nichts. Ein grünes Schloss im Browser bestätigt lediglich die Transportverschlüsselung. Es beantwortet nicht die Frage, ob der Anbieter die Eingabe speichert, analysiert oder zum Modelltraining verwendet.

Die vier Kernkriterien für schulische KI-Plattformen

Diese vier Punkte sind kein vollständiges Datenschutzkonzept. Sie bilden aber einen effizienten ersten Filter. Ein Produkt, das bereits bei Serverstandort, Training oder Löschung keine klare Antwort liefert, sollte nicht in einen regulären Schülerbetrieb gelangen.

Personenbezogene Daten beginnen nicht erst beim Namen

In der Praxis wird der Datenschutz häufig auf Namen und E-Mail-Adressen reduziert. Das ist für KI-Systeme zu kurz gegriffen. Auch ein anonym wirkender Schülertext kann personenbezogene Informationen enthalten. Schreibstil, Ereignisse, familiäre Situationen, medizinische Hinweise oder seltene Kombinationen von Merkmalen können eine Person identifizierbar machen.

Für die Bewertung genügt daher nicht die Frage, ob ein Nutzer seinen Namen in das Eingabefeld schreibt. Relevant ist der gesamte Inhalt des Prompts und der hochgeladenen Dateien.

Besonders sensibel sind:

• individuelle Förderpläne und Unterstützungsbedarfe,
• Zeugnisentwürfe und Leistungsbewertungen,
• Konflikt- und Disziplinardokumentationen,
• Gesundheitsinformationen,
• psychologische oder soziale Einschätzungen,
• Bewerbungsunterlagen von Schülern,
• Audio- und Videodateien,
• frei formulierte Texte mit persönlichen Erlebnissen.

Eine Anweisung wie „Bewerte diesen Aufsatz anonym“ beseitigt das Risiko nicht automatisch. Wenn der Aufsatz konkrete Lebensumstände enthält, bleibt eine Verarbeitung personenbezogener Daten möglich.

Pseudonymisierung ist kein Freifahrtschein

Pseudonymisierung kann den Schutz verbessern. Sie ersetzt aber keine Prüfung des Anbieters. Wird der Name durch eine Kennung ersetzt, können andere Textbestandteile weiterhin eine Zuordnung ermöglichen. Außerdem entstehen zusätzliche organisatorische Fragen: Wer hält die Zuordnungsliste? Wer darf sie nutzen? Wie lange bleibt sie gespeichert?

Für viele Unterrichtsszenarien ist die robusteste Lösung deshalb nicht die nachträgliche Anonymisierung eines sensiblen Dokuments, sondern die Begrenzung des Anwendungsfalls. Statt einen echten Zeugnisentwurf hochzuladen, kann die Lehrkraft mit synthetischen Beispielen arbeiten. Statt individuelle Förderdaten zu übertragen, lässt sich eine allgemeine Textstruktur analysieren.

Das reduziert den Informationswert für das Modell. Es reduziert aber auch die Angriffsfläche. Datenschutz ist hier kein Schalter, sondern eine Frage der Systemarchitektur.

Modelltraining: Der unterschätzte Vertragsparameter

Viele KI-Dienste verbessern ihre Modelle mit Nutzereingaben. Für allgemeine Verbraucherprodukte kann das Bestandteil des Geschäftsmodells sein. Für Schulen ist es ein kritischer Vertragsparameter.

Schulische Eingaben können geistige Leistungen, persönliche Informationen und interne Dokumente enthalten. Werden diese Daten für das Training eines Anbietermodells verwendet, verliert die Schule die Kontrolle über Zweck, Reichweite und spätere Verwendung. Eine nachträgliche Löschung aus einem bereits trainierten Modell ist technisch nicht ohne Weiteres gleichbedeutend mit der Löschung eines Datensatzes aus einer Datenbank.

Daher muss der Ausschluss der Trainingsnutzung vertraglich nachvollziehbar sein. Eine bloße Einstellung in der Benutzeroberfläche reicht für einen institutionellen Betrieb nicht aus. Einstellungen können geändert, übersehen oder durch neue Produktversionen ersetzt werden. Die Rechtsgrundlage darf nicht von einem unscheinbaren Schalter abhängen.

Bei der Evaluation sollte die Schule zwischen diesen Aussagen unterscheiden:

• Starke Aussage: Eingaben der Bildungseinrichtung werden nicht zum Training allgemeiner oder kundenspezifischer Modelle verwendet.
• Schwache Aussage: Der Anbieter verwendet Daten nicht standardmäßig für Trainingszwecke.
• Unklare Aussage: Daten können zur Verbesserung des Dienstes verarbeitet werden.

Nur die erste Formulierung schafft eine brauchbare Grundlage. Die zweite verlangt zusätzliche Prüfung. Die dritte ist für personenbezogene Schülerdaten nicht ausreichend präzise.

Das Opt-out in der Oberfläche ist kein Ersatz für eine belastbare Vertragsklausel. Institutionelle Daten brauchen institutionelle Kontrolle.

EU AI Act: Nicht jedes Klassenzimmer-Tool ist Hochrisiko-KI

Neben der DSGVO greifen schrittweise die Anforderungen des EU AI Acts. Die Verordnung ist am 1. August 2024 in Kraft getreten. Erste Regelungen gelten seit dem 2. Februar 2025. Für Bildungseinrichtungen sind dabei zwei Punkte besonders relevant: KI-Kompetenz und die Einstufung bestimmter Systeme als Hochrisiko-Anwendungen.

Artikel 4 verpflichtet Anbieter und Betreiber, Maßnahmen für eine ausreichende KI-Kompetenz des Personals zu ergreifen. Das bedeutet nicht, dass jede Lehrkraft ein Modell trainieren oder eine API administrieren muss. Es bedeutet aber, dass das Personal die Grenzen des eingesetzten Systems verstehen muss.

Dazu gehören mindestens:

• typische Fehlerbilder und Halluzinationen,
• Umgang mit vertraulichen Informationen,
• Grenzen automatisierter Bewertung,
• Kennzeichnung und Einordnung erzeugter Inhalte,
• Meldewege bei Fehlentscheidungen,
• zulässige und unzulässige Eingabedaten,
• Zuständigkeiten bei Datenschutz- und Sicherheitsvorfällen.

Eine einstündige Produktvorführung erfüllt diese Aufgabe nicht. KI-Kompetenz muss in die Betriebsprozesse integriert werden. Dazu gehören Nutzungsrichtlinien, Schulungen, Beispielprompts und regelmäßige Aktualisierungen, wenn sich Modell oder Plattform verändern.

Wann Bildungs-KI als Hochrisiko-System gilt

KI-Systeme im Bildungswesen können nach Anhang III Nr. 3 des EU AI Acts als Hochrisiko-Systeme eingestuft werden, wenn sie automatisiert über Bildungszugänge, Notenvergaben oder Schulformzuweisungen entscheiden. Das betrifft nicht automatisch jedes Werkzeug, das Texte formuliert, Aufgabenideen erstellt oder Lernmaterial zusammenfasst.

Der entscheidende Faktor ist die Funktion im Entscheidungsprozess. Ein Assistenzsystem, dessen Vorschläge von einer Lehrkraft geprüft und eigenständig verworfen oder angepasst werden können, ist anders zu bewerten als ein System, das eine Bewertung automatisiert festlegt und diese in die Schulverwaltung überträgt.

Der Mensch-in-der-Entscheidungsschleife muss dabei praktisch wirksam sein. Eine Lehrkraft, die lediglich auf eine automatisch erzeugte Note klicken kann, hat nicht zwingend eine echte Entscheidungshoheit. Für eine belastbare Kontrolle braucht sie:

• ausreichende Informationen über die Entstehung des Vorschlags,
• Zugriff auf die zugrunde liegenden Daten,
• Zeit zur Prüfung,
• Möglichkeit zur Korrektur,
• keine organisatorische Vorgabe, die Systementscheidung ungeprüft zu übernehmen.

Das ist ein technisches und organisatorisches Problem. Ein Kontrollkästchen mit der Bezeichnung „manuell bestätigt“ erzeugt noch keine menschliche Aufsicht.

Plagiatsprüfung und KI-Detektoren: Hohe Unsicherheit bei scheinbarer Präzision

KI-Detektoren wirken im Schulbetrieb attraktiv. Sie versprechen eine Kennzahl, die anzeigt, ob ein Text wahrscheinlich maschinell erzeugt wurde. Für Disziplinar- oder Bewertungsentscheidungen ist diese Zahl jedoch kein belastbarer Beweis.

Die Systeme analysieren meist sprachliche Muster, Vorhersagbarkeit und statistische Merkmale. Daraus entsteht eine Wahrscheinlichkeit oder Klassifikation. Diese kann durch Textsorte, Sprachkompetenz, Überarbeitung, Übersetzung oder kurze Textlänge beeinflusst werden. Besonders problematisch sind Fehlklassifikationen bei Schülern, die in einer Zweitsprache schreiben oder einen stark standardisierten Stil verwenden.

Ein KI-Detektor darf daher nicht die Rolle eines automatischen Schuldnachweises übernehmen. Wenn ein System einen Text als wahrscheinlich maschinell erzeugt einstuft, ist das zunächst ein Prüfhinweis. Die weitere Bewertung muss auf nachvollziehbaren Arbeitsprozessen beruhen:

1. Entstehung des Textes dokumentieren.

2. Entwürfe, Notizen oder Versionsverläufe einbeziehen.

3. Inhaltliche Rückfragen stellen.

4. Keine Sanktion ausschließlich aus dem Detektorwert ableiten.

5. Entscheidung und Begründung transparent festhalten.

Auch beim Urheberrecht entstehen Risiken. Eine KI kann beim Formulieren unterstützen, aber die Schule muss klären, wie mit geschützten Unterrichtsmaterialien, eingescannten Texten und hochgeladenen Verlagsinhalten umgegangen wird. Die Lizenz für die KI-Plattform umfasst nicht automatisch die Rechte an allen Dokumenten, die in sie übertragen werden.

Von der Produktdemo zur belastbaren Beschaffung

Eine Schule sollte KI-Software nicht direkt aus einer Produktvorführung heraus lizenzieren. Der sinnvolle Prozess ähnelt eher einer technischen Abnahme als einem klassischen Softwarekauf.

1. Anwendungsfall eingrenzen

Zuerst wird festgelegt, was das System tatsächlich tun soll. Ein Werkzeug für Unterrichtsentwürfe stellt andere Anforderungen als eine Plattform für individuelle Lernstandsanalysen. Je konkreter der Anwendungsfall, desto besser lassen sich Datenminimierung und Zugriffskontrolle implementieren.

Geeignete erste Szenarien sind häufig:

• Erzeugung variierter Aufgabenstellungen ohne Schülerdaten,
• sprachliche Überarbeitung eigener Unterrichtsmaterialien,
• Zusammenfassung öffentlich verfügbarer Texte,
• Unterstützung bei der Planung von Differenzierungsangeboten,
• Simulation von Prüfungsgesprächen mit synthetischen Beispielen.

Weniger geeignet für einen frühen Pilotbetrieb sind personenbezogene Leistungsdaten, Förderinformationen und automatisierte Notenvorschläge.

2. Datenklassen definieren

Für jede Funktion muss feststehen, welche Eingaben erlaubt sind. Eine einfache interne Klassifikation kann aus drei Stufen bestehen:

• Öffentliche Daten: frei zugängliche Texte oder selbst erstellte, nicht personenbezogene Materialien.
• Interne Schuldaten: nicht öffentliche Organisationsinformationen ohne besondere personenbezogene Inhalte.
• Personenbezogene oder besonders schützenswerte Daten: Schülerarbeiten mit identifizierbaren Angaben, Leistungsdaten, Gesundheits- und Förderinformationen.

Die letzte Kategorie gehört nicht in ein System, dessen Vertrags- und Speicherarchitektur ungeklärt ist. Diese Regel muss technisch unterstützt werden. Eine Richtlinie, die niemand im Arbeitsablauf umsetzen kann, ist keine Kontrolle.

3. Anbieterunterlagen anfordern

Vor dem Vertrag sollten mindestens folgende Dokumente vorliegen:

• Auftragsverarbeitungsvertrag nach Art. 28 DSGVO,
• Verzeichnis der Unterauftragnehmer,
• Beschreibung der Speicher- und Verarbeitungsorte,
• Regelung zur Nutzung von Eingaben für Modelltraining,
• Löschkonzept,
• Sicherheitsmaßnahmen,
• Rollen- und Berechtigungskonzept,
• Angaben zu Protokollierung und Supportzugriffen,
• Informationen zu Export und Vertragsende.

Fehlt eine dieser Grundlagen, sollte der Anbieter nicht mit allgemeinen Marketingaussagen antworten. Die Antwort muss technisch und vertraglich überprüfbar sein.

4. Pilotbetrieb messbar machen

Ein Pilotprojekt braucht definierte Messpunkte. Sonst wird es zur verlängerten Produktdemo. Sinnvolle Metriken sind:

• Antwortlatenz unter typischer Last,
• Verfügbarkeit im vorgesehenen Nutzungsfenster,
• Fehlerquote bei standardisierten Aufgaben,
• Rate sachlicher Halluzinationen,
• Anteil unbrauchbarer oder nachbearbeitungsintensiver Ergebnisse,
• Aufwand für Rollenverwaltung und Support,
• Zeitaufwand für Löschung und Nutzerverwaltung,
• Anzahl der Fälle, in denen sensible Eingaben verhindert wurden.

Die Halluzinationsrate sollte nicht pauschal für das gesamte System behauptet werden. Sie hängt von Aufgabe, Modell, Sprache und Eingabequalität ab. Für eine Schule ist deshalb ein eigener Testsatz mit typischen Unterrichtsaufgaben aussagekräftiger als ein allgemeiner Anbieter-Benchmark.

Was in der Praxis häufig schiefgeht

Vier Fehlmuster treten bei der Einführung von KI-Software besonders regelmäßig auf.

Freie Konten werden als Pilot eingesetzt

Ein kostenloses Konto ist technisch bequem. Es erzeugt aber oft keine institutionelle Kontrolle über Daten, Berechtigungen und Löschung. Wenn Lehrkräfte und Schüler damit personenbezogene Inhalte verarbeiten, wird der Pilot bereits zum Regelbetrieb ohne belastbare Governance.

Der Datenschutz wird an die Lehrkraft delegiert

Lehrkräfte können keine Anbieterbedingungen kompensieren, die der Schulträger nicht geprüft hat. Sie können sensible Inhalte vermeiden und Vorgaben einhalten. Sie können aber keinen fehlenden AVV ersetzen und keinen unbekannten Unterauftragnehmer kontrollieren.

Die Schulverwaltung übernimmt die Modellentscheidung

Eine KI darf nicht unbemerkt zur Bewertungs- oder Zuweisungsinstanz werden. Sobald ein System über Zugänge, Noten oder Schulformen entscheidet, verändert sich die regulatorische Bewertung. Automatisierte Vorschläge müssen klar von verbindlichen Entscheidungen getrennt werden.

Löschung wird nur im Benutzerkonto getestet

Das Löschen eines Kontos beweist nicht, dass Prompts, Anhänge, Protokolle und Sicherungskopien ebenfalls gelöscht wurden. Ein professioneller Abnahmetest umfasst den gesamten Datenbestand. Dazu gehören auch Wiederherstellungsprozesse und Supportsysteme.

Zwischenfazit: Ein kleiner kontrollierter Einsatz ist meist der bessere Start

Für viele Schulen ist ein begrenzter Einsatz mit öffentlichen oder synthetischen Daten technisch und organisatorisch realistischer als die sofortige Verarbeitung vollständiger Schülerakten. Das senkt den pädagogischen Funktionsumfang. Es erhöht aber die Steuerbarkeit.

Eine tragfähige Einführung benötigt mindestens:

• einen klar abgegrenzten Anwendungsfall,
• eine geprüfte Schullizenz statt eines Privatkontos,
• einen AVV nach Art. 28 DSGVO,
• einen vertraglichen Ausschluss des Modelltrainings mit Nutzerdaten,
• transparente Speicherorte und Unterauftragnehmer,
• definierte Löschfristen,
• Rollen- und Berechtigungskonzepte,
• Schulungen zur KI-Kompetenz,
• dokumentierte menschliche Kontrolle bei relevanten Entscheidungen,
• einen Pilotbetrieb mit messbaren Qualitäts- und Sicherheitskriterien.

Die Umbenennung des länderübergreifend entwickelten schulischen KI-Werkzeugs „telli“ in „AIS.chat“ zum 20. Mai 2026 zeigt zudem einen praktischen Nebenaspekt: Produktnamen, Marken und Vertriebsauftritte können sich ändern. Beschaffungsentscheidungen sollten daher nicht auf Wiedererkennung oder Bekanntheit beruhen. Maßgeblich sind Vertrag, technische Architektur und nachweisbare Betriebsprozesse.

Machbarkeitsbewertung: Go oder No-Go?

Go ist die Beschaffung, wenn der Anbieter die vier Kernkriterien nachvollziehbar erfüllt, ein AVV vorliegt, Trainingsnutzung ausgeschlossen ist und die Schule den konkreten Anwendungsfall organisatorisch kontrollieren kann. Ein begrenzter Pilot mit nicht personenbezogenen Daten ist auch dann sinnvoll, wenn die Plattform zunächst nur als Assistenzwerkzeug eingesetzt wird.

No-Go ist der Regelbetrieb, wenn ein kostenloses oder privates Standardkonto verwendet werden soll, der AVV fehlt, der Anbieter die Trainingsnutzung offenlässt oder der Speicherort nicht geklärt ist. Ebenfalls No-Go ist die automatisierte Übernahme von Noten, Zugangsentscheidungen oder Schulformzuweisungen ohne belastbare menschliche Prüfung und regulatorische Bewertung.

Die nüchterne Schlussfolgerung lautet: Datenschutzkonforme KI-Plattformen für Schulen sind verfügbar, aber nicht durch einen Tarifnamen erkennbar. Die Schule muss den Dienst wie eine Infrastrukturkomponente behandeln. Datenfluss prüfen. Verträge evaluieren. Löschung testen. Berechtigungen begrenzen. Ergebnisse messen.

Erst dann wird aus KI-Software im Schulbetrieb ein implementierbares System. Vorher bleibt sie ein externes Rechenmodell mit unbekanntem Datenrisiko.