Architektur & Datensouveränität

Die eledia.ai Suite erweitert Moodle um mehrere KI-Workflows, ohne die Plattform durch ein separates Lernportal zu ersetzen. Das gemeinsame Architekturprinzip lautet: Fachfunktion im passenden Moodle-Kontext, Providerzugriff über zentrale Infrastruktur und bewusste Kontrolle vor einer Veröffentlichung oder Kursänderung.

Komponenten und Verantwortlichkeiten

Fachplugins

Aktivitäten, Fragetypen, Filter und lokale Plugins stellen die sichtbaren Workflows bereit. Sie entscheiden, welche Daten benötigt, welche Ergebnisse gespeichert und welche Moodle-Rechte geprüft werden. Beispiele sind mod_aifeedback, qtype_aitext, local_elediaai_h5pauthor und filter_eledia_translate.

KI-Suite

local_elediaai_core registriert Werkzeuge, gruppiert sie nach Zielgruppe und stellt gemeinsame Navigation sowie Audit-Funktionen bereit. Sichtbarkeit und Startpunkt einer Karte hängen von Installation, Status, Feature-Schalter, Kontext und Berechtigungen ab.

Moodle-KI-Subsystem

Plugins verwenden für zentrale Textaktionen Moodles core_ai. Dieses Subsystem verbindet eine Aktion wie Texterzeugung, Zusammenfassung oder Erklärung mit einem konfigurierten Provider. Es führt außerdem technische Aktionsdaten, die im KI Audit ausgewertet werden können.

Provider und Gateway

Der Provider aiprovider_eledia liest Gateway-URL, installationsspezifischen Virtual Key und erlaubte Modell-Aliase zur Laufzeit aus dem Customer Portal. Die Anfrage geht anschließend als OpenAI-kompatibler Chat-Completion-Aufruf an das eLeDia.ai LiteLLM-Gateway. Das Provider-Plugin speichert diese Zugangsdaten nicht selbst.

Andere Moodle-AI-Provider können grundsätzlich parallel konfiguriert werden. Ob ein Suite-Workflow mit ihnen funktioniert, hängt von den benötigten core_ai-Aktionen und der lokalen Freigabe ab.

Typischer Datenfluss

Ein Textworkflow durchläuft normalerweise folgende Stationen:

1. Eine berechtigte Person startet eine Aktion in einem Moodle-Kontext.
2. Das Fachplugin sammelt die für diese Aktion freigegebenen Eingaben, etwa einen Prompt, Kursinhalt oder eine Abgabe.
3. Das Plugin baut eine fachliche Anweisung und ruft eine core_ai-Aktion auf.
4. Moodle ergänzt technische Kontextdaten und übergibt die Anfrage an den konfigurierten Provider.
5. Der Provider authentifiziert sich am Gateway und ruft das freigegebene Modell auf.
6. Die Antwort kehrt über Provider und core_ai zum Fachplugin zurück.
7. Das Plugin validiert, zeigt oder speichert das Ergebnis entsprechend seinem Workflow.
8. Eine Person prüft den Entwurf, bevor er importiert, freigegeben oder in einen Kurs geschrieben wird.

Nicht jeder Workflow speichert dieselben Daten. KI Aktivitätensuche hält beispielsweise keine eigene Suchhistorie, während KI Feedback Entwürfe und Freigabestatus in Moodle persistiert. Maßgeblich ist daher immer das jeweilige Plugin-Handbuch.

Daten in Übertragung und Speicherung

Für eine Datenschutzbewertung sollten mindestens vier Datenklassen getrennt betrachtet werden:

• Fachliche Eingaben: Prompt, Ausgangstext, Kursinhalt, Antwort oder Abgabe.
• Kontext: Kurs, Aktivität, Rolle, System-Prompt und bisheriger Verlauf.
• KI-Ergebnis: generierter Text, Bewertung, Empfehlung oder strukturierter Vorschlag.
• Betriebsdaten: Person oder gehashte Kennung, Provider, Modell, Zeitpunkt, Status, Tokenangaben und Fehler.

Welche dieser Daten den Provider erreichen, in Moodle gespeichert oder im Audit sichtbar werden, ist je Funktion unterschiedlich. Anonymisierte Anzeigenamen schützen zudem nicht vor personenbezogenen Angaben in freien Textfeldern.

Provider- und Modellgovernance

Der zentrale Providerpfad verhindert, dass jedes Plugin eigene API-Schlüssel oder unkontrollierte Modelllisten führt. Beim eLeDia-Provider werden Verbindung und Modell-Aliase über das Customer Portal bereitgestellt. Dadurch lassen sich Vertrags-, Quota- und Modellentscheidungen installationsweit steuern.

Vor einer Freigabe sollten Organisationen dokumentieren:

• Anbieter, Gateway und Verarbeitungsregion,
• Vertrags- und Auftragsverarbeitungsgrundlage,
• erlaubte Modelle und Aktionen,
• zulässige Datenarten und ausgeschlossene Inhalte,
• Quoten, Kostenkontrolle und Verhalten bei erschöpftem Guthaben,
• Verantwortliche für Konfiguration und Freigabe.

Ein lokales oder europäisch betriebenes Gateway kann Datenwege beeinflussen, ist aber allein noch kein vollständiges Datenschutzkonzept. Entscheidend sind der tatsächlich aufgerufene Modellendpunkt und dessen Betriebsbedingungen.

Rechte und Sichtbarkeit

Die Suite ersetzt Moodles Rechteprüfung nicht. Ein sinnvoller Zugriff besteht aus mehreren Ebenen:

1. Das Plugin und seine Abhängigkeiten sind installiert.
2. Die Funktion ist administrativ sichtbar und freigegeben.
3. Die Person besitzt die benötigte Capability im konkreten Kontext.
4. Der erforderliche Provider und die passende KI-Aktion sind verfügbar.
5. Für schreibende Aktionen bestehen zusätzlich Rechte an Kurs, Aktivität, Fragenpool, Inhaltsspeicher oder Kompetenzrahmen.

Direkte URLs dürfen diese Prüfungen nicht umgehen. Wenn zwei Personen unterschiedliche Karten oder Ergebnisse sehen, müssen deshalb sowohl globale Schalter als auch ihre konkreten Kontextrechte verglichen werden.

Audit und Nachvollziehbarkeit

KI Audit liest technische Aktionen des Moodle-KI-Subsystems und kann nach Zeitraum, Person, Kontext, Aktion, Provider, Modell und Status filtern. Die Administration entscheidet, ob Prompt-, Antwort-, Fehler- und Tokenfelder sichtbar oder exportierbar sind.

Audit beantwortet vor allem Betriebsfragen: Wurde ein Provider erreicht? Welche Aktion ist fehlgeschlagen? Welche Modelle und Tokenwerte wurden gemeldet? Es beantwortet nicht automatisch, ob eine Antwort fachlich richtig, didaktisch sinnvoll oder rechtlich zulässig war.

Sicherheits- und Robustheitsprinzipien

• Zugangsdaten werden zentral verwaltet und nicht in einzelnen Fachworkflows abgefragt.
• Serverseitige Berechtigungsprüfungen gelten auch für Ajax-, Download- und Hintergrundaktionen.
• Strukturierte KI-Ausgaben werden vor schreibenden Operationen validiert.
• Review und endgültige Freigabe sind bei kritischen Workflows getrennte Schritte.
• Rate-Limits, Quoten und verständliche Fehlerpfade begrenzen unkontrollierte Aufrufe.
• Backup, Restore, Privacy-API und Kurs-Reset werden pro speicherndem Plugin dokumentiert.

Verantwortungsmatrix

Bereich	Administration	Lehrende/Redaktion	Datenschutz/Governance
Provider und Modelle	konfigurieren und testen	freigegebene Wege verwenden	Vertrag und Datenarten prüfen
Rollen und Rechte	Rollenmodell umsetzen	nur berechtigte Kontexte nutzen	Minimalzugriff kontrollieren
Prompts und Quellen	Standards bereitstellen	fachlich formulieren und prüfen	sensible Inhalte begrenzen
KI-Ergebnisse	technische Verfügbarkeit	fachliche Freigabe	Transparenz und Verfahren definieren
Audit und Aufbewahrung	Zugriff und Fristen konfigurieren	Auffälligkeiten melden	Zweck und Einsicht begründen

Prüffragen vor dem Einsatz

• Welches Fachplugin verarbeitet welche Daten?
• Welcher Provider und welches Modell erhalten die Anfrage tatsächlich?
• Welche Daten bleiben in Moodle, welche verlassen die Plattform?
• Wer darf den Workflow starten, Ergebnisse sehen und endgültig freigeben?
• Was geschieht bei Providerfehlern, ungültiger Ausgabe oder fehlendem Cron?
• Wie werden Lernende informiert und wie können Daten exportiert oder gelöscht werden?

Die Antworten sollten für jedes aktivierte Plugin anhand seines öffentlichen Handbuchs und der lokalen Konfiguration dokumentiert werden.