xAPI gegen SCORM: Wie Learning Analytics die DACH-Bildungs-Tech vor die DSGVO stellt

Wer die Geschichte der E-Learning-Standards erzähle, beginne sinnvollerweise in einer Behörde, die mit Bildung im engeren Sinn wenig zu tun hat: dem amerikanischen Verteidigungsministerium. Aus dessen Advanced Distributed Learning Initiative, im Jahr 1997 unter Präsident Clinton gegründet, ging im Januar 2000 die erste Version des Sharable Content Object Reference Model hervor, des Standards, der unter dem Akronym SCORM seit über zwei Jahrzehnten die Welt der Lern-Management-Systeme prägt. Dass ein militärisches Schulungs-Bedürfnis am Anfang stand, erkläre die Engführung des Standards bis heute: SCORM sollte Lerninhalte austauschbar machen — derselbe Kurs sollte auf unterschiedlichen LMS laufen und am Ende eine verlässliche Aussage liefern, ob die Soldatin den Kurs bestanden habe oder nicht. Das war 2001, als SCORM 1.2 als erste breit eingesetzte Version erschien, eine substantielle Leistung. Es ist 2026 als Standard zu eng geworden.

SCORM 1.2 und 2004: Die Engführung des Abschluss-Datums

SCORM steht in der Praxis für ein klar umrissenes Datenfluss-Modell. Ein Lerninhalt — ein Modul, ein Kurs, eine interaktive Übung — wird als „Sharable Content Object” verpackt, üblicherweise als ZIP-Archiv mit einem Manifest in XML. Dieses Paket lade die Lerner:in in einem SCORM-fähigen LMS, das per JavaScript-API die Kommunikation mit dem Inhalt aufrechterhalte. Was der Standard zu übermitteln erlaube, ist eng definiert: der Lernstatus (bestanden, nicht bestanden, abgeschlossen, unvollständig), ein Score-Wert, die aufgewendete Zeit, mitunter Antworten auf einzelne Aufgaben innerhalb des Moduls. Was zwischen Modul-Start und Modul-Ende geschah — welche Hyperlinks die Lerner:in klickte, an welcher Stelle sie das Modul pausierte, ob sie eine Aufgabe dreimal wiederholte, bevor sie sie löste — sah SCORM 1.2 und auch das 2004 veröffentlichte SCORM 2004 nur in rudimentärster Form vor.

Diese Engführung war kein Versehen. SCORM wurde in einer Phase entworfen, in der das LMS als zentrales Lehr-Werkzeug galt und Lerner:innen-Aktivität dort stattfinden sollte. Mobile Apps, gespielte Lernszenarien, simulationsbasierte Trainings am Schichtarbeits-Platz, Augmented-Reality-Trainings in der Werkstatt — alles, was in den 2010er-Jahren als Erweiterung der Lern-Welt jenseits des LMS-Browsers in den Blick rückte, lag ausserhalb des Standards. In der DACH-Hochschullandschaft, wo Moodle (im Einsatz seit 2002, mit einem Marktanteil von rund 75 Prozent an deutschen, österreichischen und schweizerischen Hochschulen) und ILIAS (deutsche Open-Source-Klassik seit 2000, stark verbreitet bei IHK und BIBB) den LMS-Markt dominieren, blieb SCORM dennoch lange der unbestrittene Standard, an dem sich Authoring-Tools wie Articulate Storyline (seit 2008) oder Adobe Captivate (seit 1999) ausrichteten.

Die xAPI-Welle 2013: Vom Modul zum Statement

Die Antwort auf die SCORM-Engführung kam aus demselben Umfeld, das SCORM ursprünglich hervorgebracht hatte. Die ADL-Initiative beauftragte 2010 das US-amerikanische Unternehmen Rustici Software, jenes Unternehmen, das seit 2002 als faktischer SCORM-Implementierungs-Experte galt, mit einer Nachfolger-Spezifikation. Das Resultat erschien im April 2013 unter dem Namen Experience API (xAPI), kommunikations-prägend auch als „Tin Can API” bekannt — der Projekt-Name in der Entwicklungs-Phase, der sich an die alte Vorstellung anlehnte, mit zwei Konservendosen und einer Schnur Informationen über Entfernungen zu übermitteln.

Das zentrale Konzept von xAPI ist ein einfaches: Jede Lern-Erfahrung lässt sich als Statement in der Tripel-Form „Actor — Verb — Object” erfassen, ergänzbar um optionale Kontext-Felder (Ergebnis, Zeit, Ort, Bewertung). Statt „Anna hat Modul X abgeschlossen” könne nun ein Statement-Strom in der Form „Anna — startete — Level 3 von Lernspiel X”, „Anna — versuchte — Aufgabe 7 zum dritten Mal”, „Anna — schloss ab — Level 3 von Lernspiel X — mit Score 87 % nach 12 Minuten” entstehen. Die Statements werden in einem Learning Record Store (LRS) abgelegt, einem Daten-Speicher, der über die xAPI-Spezifikation eine standardisierte REST-Schnittstelle exponiert und so von beliebigen Lern-Anwendungen befüllt werden kann.

Damit verschoben sich zwei Dinge. Erstens war Lern-Erfahrung nicht länger auf das LMS-Browser-Fenster beschränkt; eine VR-Trainings-Simulation auf einer Meta-Quest-Brille, ein Tablet-Lernspiel im Klassenzimmer, eine Schichtarbeits-Schulung mit QR-Code-Scans auf der Werkstatt-Halle — sie alle konnten Statements an einen LRS senden, ohne dass ein Browser dazwischen sein müsse. Zweitens entstand eine Daten-Dichte, die SCORM nie kannte: Lern-Pfad-Rekonstruktionen, Verweildauer-Analysen, Reihenfolge-Effekte, individualisierte Schwierigkeits-Anpassung auf Basis vorheriger Statement-Geschichten.

cmi5: Die Brücke zwischen den Welten

Die Adoption von xAPI verlief nicht reibungslos. Bestehende LMS-Welten waren auf SCORM-Imports kalibriert; HR-Compliance-Abteilungen erwarteten den klassischen „bestanden/nicht bestanden”-Bericht, den SCORM verlässlich lieferte; und die schiere Freiheit der xAPI-Statement-Definition — der Standard schreibt keine konkreten Verben oder Objekt-Typen vor, lediglich die syntaktische Struktur — führte in der Frühphase zu inkompatiblen Implementierungen zwischen Anbietern.

Als Antwort auf diese Probleme veröffentlichte die ADL-Initiative 2016 die Spezifikation cmi5. Sie definiert ein klares Profil über xAPI, das Begriffs- und Verlaufs-Konventionen aus der SCORM-Welt übernimmt: Es gibt eine Modul-Eröffnung, einen klar definierbaren Abschluss-Zustand, ein standardisiertes Vokabular für Lern-Verben („launched”, „initialized”, „completed”, „passed”, „failed”, „terminated”) und damit eine HR-taugliche Berichts-Logik. Gleichzeitig erbt cmi5 von xAPI die Flexibilität, beliebige zusätzliche Statements senden zu dürfen. In der DACH-Corporate-Learning-Welt der späten 2020er-Jahre ist cmi5 daher die de-facto-Brücke geworden, über die Unternehmen ihre alten SCORM-Kursbestände in Richtung xAPI-Telemetrie migrieren.

Learning Analytics und das Predictive-Modeling-Versprechen

Die unterliegende Welle, die xAPI in der Bildungs-Welt mit Bedeutung auflädt, heisst Learning Analytics. Der Begriff, in der akademischen Welt durch das Journal of Learning Analytics (seit 2014) und die jährliche Learning Analytics and Knowledge Conference (LAK, seit 2011) etabliert, bezeichnet die systematische Auswertung von Lerner:innen-Daten zum Zweck der Lehr-Lern-Optimierung. Im Kern stehen drei Anwendungs-Klassen: deskriptive Analyse (wie verteile sich Lern-Aktivität über die Lerner:innen-Klasse), diagnostische Analyse (welche Lerner:innen drohen ein Modul nicht abzuschliessen), und vor allem prädiktive Modellierung (welche Lerner:innen-Klasse benötige Intervention, bevor sie scheitere).

Die DACH-Hochschullandschaft hat sich diesem Versprechen langsamer angenähert als die angloamerikanische Welt. Während Universitäten wie die Open University im Vereinigten Königreich seit den frühen 2010er-Jahren mit grossflächigen Predictive-Modellen arbeiten, blieben deutsche, österreichische und schweizerische Hochschulen lange zurückhaltend — aus drei Gründen. Erstens fehlte die Daten-Infrastruktur: Moodle-Standardlogs lieferten Klick-Daten, nicht die granularen Lern-Pfade, die ein Predictive-Modell brauche. Zweitens war die akademische Debatte über die ethischen Implikationen der Lerner:innen-Profilierung in DACH besonders ausgeprägt; das Gesellschaftsbild des autonom Lernenden vertrug sich schlecht mit einer Auswerte-Logik, die das Risiko der Lerner:in algorithmisch berechne. Drittens — und das ist der dominante Grund — wirkte die DSGVO als rechtlicher Filter, der die rohe Datenflut der xAPI-Welle in geordnete Bahnen lenkte.

DSGVO: Die Datenschutz-Klammer um die Telemetrie

Die Datenschutz-Grundverordnung, in Kraft seit dem 25. Mai 2018, regelt die Verarbeitung personenbezogener Daten in der gesamten Europäischen Union und ist damit für jeden Schul- und Hochschul-Träger im DACH-Raum bindend (in der Schweiz spiegelbildlich durch das revidierte Bundesgesetz über den Datenschutz, in Kraft seit 1. September 2023, das in den meisten relevanten Punkten der DSGVO entspricht). Für Learning Analytics auf Basis von xAPI-Statements bedeutet das in der Praxis drei zentrale Pflichten.

Erstens muss nach Artikel 6 DSGVO eine Rechtsgrundlage für die Verarbeitung vorliegen. Die Einwilligung der Schüler:in (Art. 6 Abs. 1 lit. a) trägt in der Schul-Welt selten, weil sie freiwillig sein müsse, was bei einem von der Lehrkraft angeordneten Lernspiel zweifelhaft sei. Die Erfüllung einer rechtlichen Verpflichtung (Art. 6 Abs. 1 lit. c) trägt für die Pflichtbereiche schulischer Aufgabenstellung, nicht jedoch für detaillierte Telemetrie-Analyse. Die berechtigten Interessen (Art. 6 Abs. 1 lit. f) sind in der schulischen Welt eingeschränkt anwendbar, weil sie eine Interessenabwägung gegen die schutzwürdigen Belange der Lerner:innen erfordern.

Zweitens verpflichten die Artikel 13 und 14 DSGVO die Verarbeitenden, Lerner:innen und ihre Erziehungsberechtigten transparent über die Datenverarbeitung zu informieren — welche Daten erhoben werden, zu welchem Zweck, wer sie sehe, wie lange sie gespeichert würden. Die Information muss in verständlicher Sprache, in einer alters-angemessenen Form erfolgen. Eine xAPI-Statement-Welle, die im LRS lande, ohne dass Lerner:innen die Art der Erhebung verstünden, sei rechtlich angreifbar.

Drittens räumt Artikel 17 DSGVO ein Recht auf Löschung ein. Lerner:innen können verlangen, dass ihre Daten gelöscht werden, wenn die Speicherung nicht mehr erforderlich ist oder die Einwilligung widerrufen wurde. In einem LRS, in dem Statements verschachtelt mit Verlaufs- und Beziehungs-Daten anderer Lerner:innen liegen, ist die Erfüllung dieser Pflicht nicht trivial.

Die KMK reagierte 2021 mit einer „Empfehlung zur Datenschutz-konformen Nutzung digitaler Lern- und Schul-Infrastrukturen”, die unter anderem das Prinzip der Daten-Sparsamkeit betonte: Es seien nur die Daten zu erheben, die für den konkreten Lern-Zweck unmittelbar erforderlich seien. Predictive-Modeling-Anwendungen, die im Sinne der Risiko-Erkennung möglichst viele Daten verarbeiten wollen, geraten damit in einen strukturellen Konflikt mit der KMK-Linie.

Schrems II und der Konflikt mit US-Anbietern

Eine zweite, mit der DSGVO verschränkte Welle prägt die Bildungs-Tech-Welt seit dem 16. Juli 2020, dem Tag des Schrems-II-Urteils des Europäischen Gerichtshofs. Das Gericht kippte mit der Entscheidung den EU-US-Privacy-Shield als gültiges Übermittlungs-Instrument für personenbezogene Daten in die USA und unterstellte alle US-Anbieter dem Verdacht, durch US-Überwachungs-Gesetze (insbesondere FISA Section 702 und Executive Order 12333) keinen angemessenen Schutz personenbezogener Daten gewährleisten zu können. Für die Lern-Welt war das eine harte Welle: Canvas (von Instructure, seit 2011, im DACH-Hochschul-Bereich mit wachsender Marktpräsenz), Blackboard (im DACH zurückgehend, aber noch in einzelnen Hochschulen im Einsatz), Google Workspace for Education (in vielen Schul-Pilotprojekten, später wegen DSGVO-Bedenken zurückgenommen) und Microsoft 365 Education (mit grosser Verbreitung in deutschen Schulen seit der Pandemie) standen über Nacht unter rechtlichem Druck.

Die Reaktionen unterschieden sich. Einige Bundesländer (Hessen, Baden-Württemberg, Berlin) erliessen Aufsichts-Empfehlungen oder Verbote gegen Microsoft 365 in Schulen; andere Länder (Bayern, Nordrhein-Westfalen) suchten Verträge mit Microsoft, die zusätzliche Garantien einbauten. Der EU-US-Data-Privacy-Framework-Beschluss vom 10. Juli 2023 entschärfte die Lage, ohne sie zu beseitigen — denn ob das neue Abkommen einer dritten Schrems-Klage standhalten werde, ist Stand 2026 weiter offen.

Für die xAPI-Welt bedeute Schrems II ganz konkret: Wer einen Learning Record Store bei einem US-Anbieter betreibe, sammle Statements deutscher Schüler:innen auf US-Servern, mit allen rechtlichen Folgen. Eine Welle der LRS-Selbsthostung in europäischen Rechenzentren ist die strukturelle Antwort; in der DACH-Hochschul-Welt sind Open-Source-LRS wie „Learning Locker” (von HT2 Labs, mittlerweile Learning Pool) in selbst-gehosteten Instanzen die häufigste Wahl.

Ausblick: Welche Daten brauchen wir wirklich?

Die DACH-Diskussion um xAPI, SCORM und Learning Analytics werde sich in den kommenden Jahren weniger an Standards-Versionen entscheiden — die Standards seien definiert — als an der Antwort auf eine pädagogische Frage: Welche Telemetrie brauche eine Lehrkraft tatsächlich, um besser zu unterrichten? Wer diese Frage konservativ beantworte, lande bei einer überschaubaren Daten-Menge, die in einem DSGVO-konformen Rahmen erfasst werden könne. Wer sie maximalistisch beantworte und auf prädiktive Risiko-Erkennung setze, gerate in einen Konflikt mit der KMK-Linie der Daten-Sparsamkeit und mit der schutzwürdigen Position der Schüler:innen.

In der Mitte zwischen den beiden Polen formiert sich eine Praxis, die mit aggregierten Statement-Klassen arbeitet, individuelle Lerner:innen-Pfade pseudonymisiere und Predictive-Modellierung nur in akademischen Forschungs-Kontexten mit expliziter Einwilligung anwende. Ob diese Praxis tragfähig sei, werde sich an einem Punkt entscheiden, an dem die Standards nichts mehr beitragen können: an dem Vertrauen, das Schul-Familien, Lehrkräfte und Träger:innen-Behörden zueinander aufbauen.