From 191aac4a8545d3ce76f77256616aafbd88ca9615 Mon Sep 17 00:00:00 2001 From: foefl Date: Wed, 5 Aug 2026 11:48:31 +0200 Subject: [PATCH] Offene Punkte: O1 - Entscheidungsvorlage Moodle-Integration --- ...ungsvorlage Moodle-Integration - Extern.md | 156 +++++++ ...ungsvorlage Moodle-Integration - Intern.md | 384 ++++++++++++++++++ 2 files changed, 540 insertions(+) create mode 100644 02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Extern.md create mode 100644 02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Intern.md diff --git a/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Extern.md b/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Extern.md new file mode 100644 index 0000000..1c3a9f8 --- /dev/null +++ b/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Extern.md @@ -0,0 +1,156 @@ +# Sovereign RAG Tutor – Integrationsarchitektur gegenüber mastersolution ONE + +**Entscheidungsvorlage** + +**Bezug:** Konzeptdokument Sovereign RAG Tutor, Abschnitt 6.4, Punkt 1 + +| | | +| ----------------- | --------------------------------------------------------------- | +| erstellt durch: | d-opt GmbH
Oberneumarker Str. 59
08496 Neumark (Sachsen) | +| erstellt von: | Florian Förster | +| Erstellungsdatum: | 05.08.2026 | +| geändert von: | Florian Förster | +| Änderungsdatum: | 05.08.2026 | +| Dokumentversion: | V0.1 | + +--- + +## 1. Die Entscheidung auf einen Blick + +### Worum es geht + +Der Sovereign RAG Tutor muss mit mastersolution ONE zusammenarbeiten. Moodle bringt seit Version 4.5 ein eigenes KI-Subsystem mit. Zu entscheiden ist, ob der Tutor als Bestandteil dieses Subsystems gebaut wird oder als eigenständiges System, das an mastersolution ONE angebunden wird. + +### Empfehlung von d-opt + +**Der Tutor wird als eigenständiges, mandantenfähiges System gebaut und über etablierte Standardverfahren an mastersolution ONE angebunden.** Die Anbindung nutzt Mechanismen, die in Moodle seit Jahren stabil verfügbar sind und über alle bei Endkunden anzutreffenden Versionsstände hinweg gleich funktionieren. + +### Die drei tragenden Gründe + +**1. Betreibbarkeit über die reale Kundenlandschaft.** Die Endkunden von mastersolution betreiben unterschiedliche Moodle-Versionen und unterschiedlich stark angepasste Installationen. Das KI-Subsystem hat sich seit seiner Einführung in jeder Moodle-Version verändert – im Halbjahrestakt. Ein Produkt, das darauf aufsetzt, müsste dauerhaft in mehreren Ausprägungen gleichzeitig gepflegt und getestet werden. Der empfohlene Weg entkoppelt die Produktentwicklung vom Moodle-Releasezyklus: Der Tutor wird einmal weiterentwickelt und funktioniert über die gesamte erwartbare Versionsspanne der Endkunden hinweg, weitgehend unabhängig von deren Upgrade-Tempo. Das ist der Unterschied zwischen einer einmaligen Entwicklungsleistung und einer dauerhaften Wartungslast, die über die gesamte Produktlebensdauer mitläuft. + +**2. Die Kernfunktion lässt sich im Subsystem nicht abbilden.** Das Moodle-Subsystem kennt einen festen Satz von KI-Funktionen: Text erzeugen, Bild erzeugen, zusammenfassen, erklären. Die zentrale Leistung des Tutors – eine Antwort mit Quellenbeleg, Verweis auf den Dokumentabschnitt oder Video-Zeitpunkt und Angabe des Betriebsmodus – ist keine davon. Sie müsste in ein Format gepresst werden, das dafür nicht vorgesehen ist. Damit ginge genau das Merkmal verloren, das mastersolution in den gemeinsamen Gesprächen als erste Anforderung formuliert hat: dass jede Aussage und jede Empfehlung des Systems begründbar ist. + +**3. Schutz des finanzierten Produktkerns.** Moodle-Erweiterungen unterliegen nach verbreiteter Lesart der GPLv3: Wer Kernlogik in ein Moodle-Plugin legt, muss diese bei Auslieferung offenlegen. Da mastersolution die Entwicklung maßgeblich finanziert, entstünde so die Situation, dass ein wesentlicher Teil des Investments öffentlich verfügbar wäre – einschließlich für die Wettbewerber im Moodle-Ökosystem, die im Konzept als Marktdruck beschrieben sind. Der empfohlene Weg hält den Produktkern proprietär; ein etwaiges moodleseitiges Verbindungsstück enthält keine Kernlogik und ist damit unkritisch. Die lizenzrechtliche Einordnung im Detail wird im Rahmen der ohnehin vorgesehenen juristischen Begleitung bestätigt; die empfohlene Architektur ist so gewählt, dass sie unter jeder Auslegung Bestand hat. + +### Was diese Entscheidung _nicht_ festlegt + +Wie tief der Tutor später in die Moodle-Oberfläche eingebettet wird – als eigene Ansicht, als Kursbaustein oder tiefer –, bleibt **offen**. Der empfohlene Weg wird bewusst so gebaut, dass eine engere Einbettung später nachgerüstet werden kann, ohne die Architektur zu verändern. Diese Frage lässt sich nach den Erfahrungen aus den Stufen 1 und 2 beantworten, wenn echte Nutzungsdaten vorliegen – und sie ist eine Produktentscheidung von mastersolution, keine technische Vorfestlegung. + +Entschieden wird heute also das Fundament, nicht das Erscheinungsbild. + +### Was mastersolution beiträgt + +Die moodleseitigen Bestandteile der Anbindung – Registrierung der Schnittstelle, Konfiguration der Zugriffsrechte, Abbildung des Rollenmodells – liegen bei mastersolution. Dort ist die Moodle-Kompetenz vorhanden, dort ist die Kenntnis der kundenspezifischen Anpassungen, und dort ist die GPL-Frage unproblematisch, weil es sich um Konfiguration und schmale Verbindungsstücke handelt. d-opt liefert den souveränen Dienst. + +### Zeitpunkt + +Die Entscheidung ist Voraussetzung für die Grobplanung von Stufe 1 – sie bestimmt Auslieferungsform und Aufwandsstruktur. Solange sie offen ist, lässt sich die Planung nur unter Vorbehalt erstellen. + +--- + +## 2. Das KI-Subsystem von Moodle + +Seit Moodle 4.5 (Oktober 2024) enthält Moodle einen eigenen Rahmen für KI-Funktionen. Er besteht aus drei Arten von Bausteinen: **Anbieter** (die Anbindung an ein Sprachmodell, im Standard OpenAI, Azure, seit Version 5.2 auch Google Gemini und Amazon Bedrock), **Einsatzorte** (die Stellen in der Oberfläche, an denen Nutzer KI verwenden – Texteditor und Kurs-Assistent) sowie einen **Vermittler**, der beides verbindet und jede Nutzung protokolliert. + +Der Rahmen ist durchdacht gestaltet und bringt Eigenschaften mit, die für ein regelkonformes KI-Angebot wichtig sind: eine Zustimmungspflicht zur KI-Nutzung am Ort der Nutzung, Steuerung über das Moodle-Rollenmodell, seit Version 5.1 zusätzlich Schalter auf Kurs- und Aktivitätsebene, und eine zentrale Protokollierung. Diese Ausstattung ist der stärkste Grund, eine Integration überhaupt zu erwägen – und sie ist in der Bewertung entsprechend berücksichtigt worden. + +Drei Eigenschaften stehen dem Vorhaben jedoch entgegen: + +- Der Katalog der KI-Funktionen ist fest im Moodle-Kern verankert. Eine neue Funktionsart hinzuzufügen bedeutet praktisch, einen Beitrag zum Moodle-Kern zu leisten – mit dem Zeitplan und den Prioritäten von Moodle HQ. +- Der Rahmen ist auf einzelne, kurze Aktionen ausgelegt. Die Erschließung von Videobeständen und der Aufbau des Wissensgraphen sind Stapelverarbeitungen mit völlig anderem Laufzeitprofil. +- Der Rahmen wird je Moodle-Installation konfiguriert. Ein Betreibermodell mit mehreren getrennten Mandanten ist darin nicht vorgesehen. Dass diese Lücke real ist, zeigt der Markt: Mehrere verbreitete KI-Plugins setzen auf ein zusätzliches Fremdplugin auf, das genau diese Mandantenverwaltung nachrüstet. + +--- + +## 3. Die geprüften Wege + +| |Weg|Bewertung| +|---|---|---| +|**A**|Tutor vollständig als Moodle-Erweiterung im KI-Subsystem|Ausgeschlossen. Kernfunktion nicht abbildbar; Produktkern offenlegungspflichtig; die ab Stufe 2 nötige Rechenkomponente für das Sprachmodell lässt sich nicht in einer Moodle-Installation betreiben.| +|**B**|Eigenständiger Dienst, Bedienoberfläche als Moodle-Erweiterung im KI-Subsystem|Nicht empfohlen. Das Antwortformat wäre durch den festen Moodle-Funktionskatalog vorgegeben; Belege und Video-Zeitpunkte ließen sich nicht sauber darstellen. Zudem dauerhafte Pflege über alle Kundenversionsstände und angepassten Oberflächen hinweg.| +|**C**|Eigenständiger Dienst mit standardbasierter Anbindung|**Empfohlen.** Entkoppelt vom Moodle-Releasezyklus; volle Kontrolle über Antwortformat und Oberfläche; Produktkern geschützt; mandantenfähig.| +|**D**|Weg C, ausgelegt für spätere engere Einbettung|**Empfohlene Ausprägung.** Kein nennenswerter Mehraufwand, hält die Gestaltungsfreiheit offen.| + +**Faire Einordnung zu Weg B:** Bei einer einheitlichen, durchgängig aktuellen Moodle-Landschaft wäre dieser Weg ernsthaft erwägenswert – vor allem wegen der in Kapitel 2 beschriebenen Governance-Ausstattung. Der Ausschluss folgt aus der konkreten Kundenlandschaft von mastersolution, nicht aus einer generellen Schwäche des Moodle-Subsystems. + +--- + +## 4. Zielarchitektur + +```mermaid +flowchart LR + subgraph MS["mastersolution ONE (Moodle)"] + KURS[Kurse, Materialien, Videos] + ROLLEN[Rollen und Berechtigungen] + UI[Aufruf aus dem Kurs] + end + + subgraph TUTOR["Sovereign RAG Tutor (eigenständiger Dienst)"] + VAULT[Knowledge Vault] + LLM[Souveränes Sprachmodell] + GOV[Mandanten- und Governance-Schicht] + end + + KURS -->|Materialübernahme| VAULT + ROLLEN -->|Identität und Berechtigungen| TUTOR + UI -->|Aufruf per Standardschnittstelle| TUTOR + TUTOR -.->|Antwort mit Beleg und Rücksprung ins Material| MS +``` + +Der Tutor läuft On-Premise beim Endkunden oder in einem deutschen Rechenzentrum – die Souveränitätszusage bleibt in beiden Betriebsformen unverändert. Die Anbindung erfolgt über LTI (ein seit Jahren etablierter Standard für die Anbindung externer Lernwerkzeuge an Lernplattformen, in Moodle seit Version 3.8 verfügbar) sowie über die regulären Moodle-Schnittstellen für Inhalte und Lernereignisse. + +--- + +## 5. Was der empfohlene Weg zusätzlich verlangt + +Zwei Punkte sollen offen benannt werden, weil sie in die Planung gehören: + +**Die Governance-Ausstattung entsteht als Bestandteil des Tutors.** Zustimmungspflicht, Protokollierung und Rechtefeinsteuerung kommen bei diesem Weg nicht aus dem Moodle-Kern, sondern werden im Tutor selbst umgesetzt. Der Aufwand ist real. Er relativiert sich aus zwei Gründen: Erstens fällt er ohnehin an, weil das Betreibermodell mit getrennten Mandanten und das Regulatorik-Paket der Stufe 3 Anforderungen stellen, die der Moodle-Kern nicht erfüllt. Zweitens gilt eine eigene Lösung einheitlich über alle Endkunden hinweg statt in mehreren Ausprägungen je Moodle-Version – und sie wird Teil der mitgelieferten Compliance-Ausstattung, die im Konzept als Verkaufsargument gegenüber den Endkunden vorgesehen ist. + +**Die Oberflächen-Einbettung ist zunächst weniger nahtlos.** Der Rücksprung aus einer Antwort in das Kursmaterial oder zum Video-Zeitpunkt ist Kernfunktion und wird umgesetzt; er läuft aber über Verweise statt über eine native Moodle-Komponente. Wie weit die Einbettung später gehen soll, ist genau der in Abschnitt 1 beschriebene offene Freiheitsgrad. + +--- + +## 6. Auswirkung auf die Ausbaustufen + +**Stufe 1 (Souveräne Suche)** berührt das KI-Subsystem gar nicht – es kommt kein Sprachmodell zum Einsatz. Zu klären sind hier die Materialübernahme und die Übergabe von Identität und Berechtigungen. Diese Stufe eignet sich zugleich als Erprobung des Anbindungsverfahrens. + +**Stufe 2 (Nachschlage-Assistent)** bringt die Rechenkomponente für das Sprachmodell mit eigenem Betriebsprofil – ein weiterer Grund für die Trennung. Mit dem ersten Kontakt der Nutzer zum Sprachmodell wird die Basis-Governance fällig: Zustimmung und Protokollierung. Sie fügt sich zeitlich in die ohnehin gegen Ende dieser Stufe beginnende juristische Begleitung. + +**Stufe 3 (Kompetenzmodell und Tracking)** benötigt Zugriff auf die Lernereignisse aus dem LMS und baut die Governance zur vollen Regulatorik-Ausstattung aus. + +**Stufe 4 (Adaptive Didaktik)** bringt erstmals schreibende Vorgänge im LMS mit sich, etwa die Einschreibung in generierte Lernpfade. Es bleibt bei der im Konzept festgelegten Logik: Das System stößt an, entscheidet aber nicht. + +--- + +## 7. Offene Fragen an mastersolution + +Vier Punkte werden für die verbindliche Planung benötigt: + +1. **Rolle der nativen Moodle-App.** Wird sie bei den Endkunden relevant genutzt? Die Antwort beeinflusst die Gestaltung der Nutzerschnittstelle. +2. **Mandantenzuschnitt.** Entspricht ein Endkunde jeweils einer eigenen Moodle-Installation, oder gibt es Installationen mit mehreren Mandanten? Das beeinflusst die Berechtigungsarchitektur. +3. **Zugriff auf die Systeme.** Zusage, dass der Tutor über die regulären Moodle-Schnittstellen auf Materialien, Rollen und Lernereignisse zugreifen kann. +4. **Übernahme der moodleseitigen Bestandteile** der Anbindung durch mastersolution. + +--- + +## 8. Wann die Entscheidung zu überprüfen ist + +Die Empfehlung ist auf Dauer angelegt, aber nicht auf Ewigkeit. Drei Entwicklungen würden eine erneute Prüfung auslösen: + +- **Moodle erweitert sein KI-Subsystem substanziell** – etwa um dialogfähige, quellenbasierte Funktionsarten _und_ eine Mandantenverwaltung. Dann würde eine engere Einbettung attraktiv. Die empfohlene Architektur bliebe gültig, weil der Kern eigenständig bleibt; zu prüfen wäre dann der Ausbaupfad, nicht die Grundsatzentscheidung. Genau dafür ist Weg D ausgelegt. +- **Die Versionslandschaft der Endkunden vereinheitlicht sich** auf einen aktuellen Stand. Der Wartungsvorteil würde kleiner; die Empfehlung bliebe wegen der Funktionsdeckung und der Lizenzfrage bestehen. +- **Die Antworten auf die Fragen 1 und 2 aus Kapitel 7** weichen von den derzeitigen Annahmen ab. Betroffen wären die Anbindungsdetails, nicht die Grundsatzentscheidung. + +--- + +## Anhang: Ergänzung zum Glossar + +**KI-Subsystem (AI Subsystem):** Der seit Moodle 4.5 im Moodle-Kern enthaltene Rahmen für KI-Funktionen, bestehend aus Anbietern, Einsatzorten und einem vermittelnden Kern. + +**LTI (Learning Tools Interoperability):** Etablierter offener Standard für die Anbindung externer Lernwerkzeuge an Lernplattformen. Er regelt den Aufruf aus dem Kurs heraus, die Anmeldung des Nutzers sowie die Übergabe von Kurs- und Rolleninformationen. In Moodle seit Version 3.8 verfügbar. + +**GPLv3:** Die Open-Source-Lizenz, unter der Moodle steht. Nach verbreiteter Auslegung erstreckt sie sich auch auf Moodle-Erweiterungen und verpflichtet dann dazu, deren Quellcode bei Weitergabe offenzulegen. Die Einordnung im Einzelfall ist Gegenstand der vorgesehenen juristischen Begleitung. + +**Mandantenfähigkeit:** Die Eigenschaft eines Systems, mehrere Endkunden mit getrennten Daten, Konfigurationen und Berechtigungen auf einer gemeinsamen Produktbasis zu betreiben. diff --git a/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Intern.md b/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Intern.md new file mode 100644 index 0000000..a7d4eae --- /dev/null +++ b/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Intern.md @@ -0,0 +1,384 @@ +# Entscheidungsvorlage: Integrationsarchitektur gegenüber Moodle (O1) + +**Vertraulichkeit:** intern + +**Führendes Dokument** – die Fassung für mastersolution wird als gefilterte Teilmenge hieraus abgeleitet. + +**Abgeleitetes Dokument:** "O1 - Entscheidungsvorlage Moodle-Integration - Extern" (v0.1, abgeleitet aus diesem Dokument in v0.3). Änderungen werden zuerst hier nachgezogen und anschließend dorthin propagiert, nie umgekehrt; die Versionszuordnung ist bei jeder Propagation hier fortzuschreiben. + +**Bezug:** Internes Konzeptdokument v0.5, Abschnitt 4.3 (L4), Abschnitt 7.3, Abschnitt 8.1 (O1, O8) + +| | | +| ----------------- | --------------------------------------------------------------- | +| erstellt durch: | d-opt GmbH
Oberneumarker Str. 59
08496 Neumark (Sachsen) | +| erstellt von: | Florian Förster | +| Erstellungsdatum: | 05.08.2026 | +| geändert von: | Florian Förster | +| Änderungsdatum: | 05.08.2026 | +| Dokumentversion: | V0.3 | + +--- + +## 1. Entscheidungsgegenstand, Tragweite und Zeitpunkt + +### 1.1 Gegenstand + +Zu entscheiden ist, in welcher Architektur der Sovereign RAG Tutor gegenüber mastersolution ONE (Moodle-Basis) integriert wird. Die Frage wurde im Konzeptdokument als offener Punkt O1 geführt und dort in der Kurzform „Plugin im AI-Subsystem (Moodle 4.5) vs. eigenständiger Dienst" formuliert. + +Diese Vorlage erweitert die Fragestellung bewusst. Die Untersuchung des Moodle-AI-Subsystems (Kapitel 2) hat ergeben, dass die binäre Formulierung den tatsächlichen Optionsraum verfehlt: Die relevante Achse ist nicht „innen oder außen", sondern **wie tief die Kopplung reicht und über welche Mechanismen sie hergestellt wird**. Kapitel 5 arbeitet deshalb mit vier Optionen statt zwei. + +### 1.2 Tragweite + +Die Entscheidung prägt vier Dinge dauerhaft: + +1. **Den Auslieferungs- und Update-Weg der gesamten Produktlinie.** Sie bestimmt, ob das Produkt an den Moodle-Releasezyklus gekoppelt ist oder unabhängig davon versioniert werden kann. +2. **Die Betriebsfähigkeit über heterogene Kundenstände hinweg.** mastersolution betreut mehrere Großkunden mit unterschiedlichen Moodle-Versionen und unterschiedlich stark angepassten Installationen. +3. **Den Schutz des geistigen Eigentums.** Moodle-Plugins unterliegen nach verbreiteter Lesart der GPLv3; die Lage des Kerns entscheidet über die Offenlegungspflicht. Die lizenzrechtliche Einordnung im Detail ist im Rahmen der juristischen Begleitung (O3) zu bestätigen. +4. **Die Leistungsabgrenzung zwischen d-opt und mastersolution (O8).** Der technische Schnitt bestimmt maßgeblich den kommerziellen. + +Eine spätere Korrektur ist teuer: Sie beträfe nicht ein Subsystem, sondern die Auslieferungsform aller vier Ausbaustufen. + +### 1.3 Zeitpunkt + +Die Entscheidung ist vor Implementierungsbeginn von Stufe 1 zu treffen. Sie ist Voraussetzung für die Grobplanung Stufe 1 und beeinflusst deren Aufwandsschätzung spürbar in beide Richtungen. Sie ist ebenfalls Voraussetzung für eine belastbare Verhandlung zu O8. + +--- + +## 2. Architektur des Moodle-AI-Subsystems + +Dieses Kapitel ist der Faktenteil. Es beschreibt den Stand des Subsystems, wie er sich aus der Moodle-Entwicklerdokumentation und den Release-Informationen bis Version 5.2 ergibt (Quellen in Anhang B). + +### 2.1 Die vier Bausteine + +Das AI-Subsystem ist kein Funktionsmerkmal, sondern ein Vermittlungsrahmen zwischen Nutzeroberfläche und KI-Dienst. Es besteht aus vier Bausteinen: + +```mermaid +flowchart LR + U[Nutzer] + P1["Placement
(UI-Plugin)"] + M["Manager
(Core)"] + A(["Action
(Core-Klasse)"]) + PR["Provider
(Plugin)"] + EXT[Externer KI-Dienst] + + U --> P1 + P1 -->|erzeugt| A + A --> M + M --> PR + PR --> EXT + EXT -.Response.-> PR -.-> M -.-> P1 +``` + +**Placements** sind die Orte, an denen Nutzer mit KI interagieren – die UI-Komponenten samt zugehörigem Arbeitsablauf. Sie sind eigenständige Plugins und implementieren eine oder mehrere Aktionen. Im Core existieren derzeit zwei: der Course Assistant und der HTML-Texteditor. + +**Actions** sind die Verben – das, was ein Nutzer mit der KI tun kann. Sie haben keine Oberfläche, sondern sind Klassen mit einer festgelegten Schnittstelle. In Moodle 4.5 waren dies `generate_text`, `generate_image` und `summarise_text`; ab 5.1 kam `explain_text` hinzu. + +**Providers** sind die Anbindung an das eigentliche Modell. Sie sind ausdrücklich als dünner Adapter um eine externe API konzipiert: Sie sollen keine Daten speichern und keine eigene Oberfläche mitbringen, abgesehen von ihren Konfigurationsmasken. Im Core enthalten sind OpenAI und Azure, seit Version 5.2 zusätzlich Google Gemini und Amazon Bedrock. Souveräne Anbindungen (Ollama, LocalAI, LiteLLM) stammen aus dem Plugin-Ökosystem, nicht aus dem Core. + +**Der Manager** ist der Controller dazwischen und Kern des Entwurfs. Es gilt die Regel, dass Placements keine Provider kennen und Provider keine Placements – der gesamte Verkehr läuft über den Manager, der die Aktion an einen unterstützenden Provider übergibt und jedes Ergebnis protokolliert. + +### 2.2 Entwicklungsstand und -tempo + +Das Subsystem wurde mit Moodle 4.5 (Oktober 2024) eingeführt und hat sich seither in jedem Release verändert: Erweiterungen in 5.0, in 5.1 die Aktion `explain_text` sowie Schalter auf Kurs- und Aktivitätsebene, in 5.2 (April 2026) die beiden zusätzlichen Provider. Für die Bewertung ist weniger der jeweilige Funktionszuwachs relevant als das Muster: **Das Subsystem ist ein Bewegungsziel im Halbjahrestakt.** + +### 2.3 Governance-Eigenschaften + +Für unser Regulatorik-Paket (Konzept 5.5, 5.6) sind drei Eigenschaften bemerkenswert, weil wir sie bei einer Entkopplung selbst erbringen müssen: + +- **Nutzungsrichtlinie am Ort der Nutzung.** Nutzer müssen vor der ersten Verwendung einer KI-Aktion eine gesonderte AI-User-Policy akzeptieren – getrennt von der Site-Policy, weil die aufkommende Gesetzgebung eine Zustimmung am Nutzungsort nahelegt. Die Zustimmung wird protokolliert. +- **Rechtesteuerung über Capabilities.** Zugriff auf Placements und einzelne Aktionen wird über das Moodle-Rollen- und Rechtemodell gesteuert; seit 5.1 zusätzlich pro Kurs und pro Aktivität durch Lehrende schaltbar. +- **Protokollierung im Manager.** Jeder Aktionsaufruf wird zentral gespeichert. + +Diese Bausteine sind qualitativ genau das, was ein AI-Act- und BetrVG-tauglicher Betrieb braucht. Ihre Existenz ist das stärkste Argument _für_ eine Integration ins Subsystem und muss in der Abwägung fair gewichtet werden. + +### 2.4 Grenzen des Subsystems bezogen auf unser Vorhaben + +Vier Grenzen sind für die Entscheidung ausschlaggebend: + +**G1 – Für unsere Kernfunktion existiert kein passender Aktionstyp.** Eine belegte Antwort mit Quellenabschnitt, Video-Timestamp und Modusangabe ist keine Zusammenfassung und keine Texterzeugung. Aktionen sind Core-Klassen mit eigener Antwortklasse und eigenem Datenbankschema; ein neuer Aktionstyp ist damit praktisch ein Core-Beitrag an Moodle HQ, mit deren Releasezyklus und deren Prioritätensetzung. Der pragmatische Ausweg – unsere Antwort in einen bestehenden Aktionstyp pressen – kostet genau die Struktur, die unser Nachvollziehbarkeitsversprechen trägt. + +**G2 – Die Provider-Rolle passt nicht zu unserem System.** Ein Provider ist definitionsgemäß ein dünner Adapter ohne eigene Datenhaltung. Der Knowledge Vault, die Graph-Schicht, das Lernermodell und die Evaluationsschicht sind das Gegenteil davon. + +**G3 – Das Subsystem kennt keine Mandantenfähigkeit.** Die Konfiguration erfolgt je Moodle-Site. Unser Betreibermodell (Konzept 5.5) setzt Mandantentrennung voraus. Dass diese Lücke real ist, zeigt das Ökosystem: Es existiert ein Drittanbieter-Infrastrukturplugin (`local_ai_manager`), auf dem mehrere Chat-Plugins aufsetzen, gerade weil mandantenfähige KI-Governance im Core fehlt und dort auf absehbare Zeit auch nicht erwartet wird. + +**G4 – Das Subsystem ist auf synchrone, kurze Einzelaktionen ausgelegt.** Unsere Batch-Prozesse (Video-Ingestion, Graph-Extraktion mit Belegpflicht) haben ein völlig anderes Laufzeit- und Ressourcenprofil. + +--- + +## 3. Randbedingungen und Annahmen + +### 3.1 Aus dem Lösungskonzept + +| |Randbedingung|Quelle| +|---|---|---| +|R1|Souveränität: Betrieb On-Premise **und** im deutschen Rechenzentrum muss möglich sein|Konzept 3, 5.5| +|R2|Nachvollziehbarkeit: Belege, Timestamps, Begründungen sind Pflichtbestandteil der Antwort|Konzept 5.6, 6.7| +|R3|Betreibermodell: Mandantenfähigkeit, Rollenteilung mastersolution/Endkunde, Update-Gate|Konzept 5.5| +|R4|Stufenlogik: jede Stufe eigenständig produktiv und verkaufbar|Konzept 5.1| +|R5|GPU-Komponente ab Stufe 2 mit eigenem Sizing- und Betriebsprofil|Konzept 5.1, O2| + +### 3.2 Aus der Kundensituation + +**R6 – Versionsheterogenität.** mastersolution betreut mehrere Großkunden, die voraussichtlich auf unterschiedlichen Moodle-Versionen betrieben werden. Diese Randbedingung ist eine konservative Setzung und als Annahme A1 (3.4) geführt; dort ist auch die Wirkung einer etwaigen Widerlegung dokumentiert. Änderungen an dieser Einschätzung sind ausschließlich in A1 nachzuziehen. + +**R7 – Hoher Anpassungsgrad.** Die Installationen sind je Kunde unterschiedlich stark angepasst, insbesondere im Erscheinungsbild. Jede Lösung, die sich in die Moodle-Oberfläche einwebt, muss über diese Varianz hinweg funktionieren und getestet werden. + +**R8 – Datenbankhoheit.** Die Postgres-Datenbank wird von mastersolution verwaltet. Ein direkter Lesezugriff wäre organisatorisch also möglich – technisch koppelt er uns jedoch an ein Schema, das über die Versionsstände variiert (siehe Anhang A, K1). + +### 3.3 Aus unserer Position _(Filterung je Punkt – siehe Hinweis am Ende des Abschnitts)_ + +**R9 – Kompetenzlage.** d-opt verfügt über keine Moodle- und keine nennenswerte PHP-Erfahrung. Ein Aufbau wäre erheblich aufwändig und müsste anschließend über die gesamte Produktlebensdauer gehalten werden – für eine Technologie, die außerhalb dieses Projekts keinen Beitrag zu unserem Portfolio leistet. + +**R10 – Lizenzposition.** Eine Offenlegung der Kernlogik unter GPLv3 wird abgelehnt. Ein schmaler, quelloffener Adapter, der eine proprietäre Kernlogik über eine Netzwerkschnittstelle anspricht, ist unproblematisch. Es ist davon auszugehen, dass mastersolution als maßgeblicher Finanzier der Entwicklung dieselbe Position vertritt; dies ist jedoch zu verifizieren und nicht zu unterstellen. Die zugrunde liegende lizenzrechtliche Einordnung (wann eine Moodle-Erweiterung als abgeleitetes Werk gilt) ist juristisch nicht trivial und im Rahmen der juristischen Begleitung (O3) zu bestätigen; die Architekturempfehlung ist so gewählt, dass sie unter jeder Auslegung Bestand hat. + +**R11 – Wiederverwendbarkeit.** Das entstehende System soll für uns auch außerhalb dieses Kundenverhältnisses anschlussfähig bleiben. Dieser Punkt wird gegenüber mastersolution **nicht** hervorgehoben. Er ist auch nicht argumentationstragend: Die Empfehlung in Kapitel 6 hält ohne ihn. + +_Hinweis zur Ableitung der Kundenfassung – Filterung je Punkt:_ + +- _R9 (Kompetenzlage) entfällt in expliziter Form. Die sachlich gültige Teilmenge wird über das Argument der kompetenzorientierten Arbeitsteilung (Kapitel 8) transportiert._ +- _R10 (Lizenzposition) **wird aufgenommen**, jedoch umformuliert: nicht als unsere Position, sondern als gemeinsames Interesse am Schutz des von mastersolution maßgeblich finanzierten Produktkerns – einschließlich des Hinweises auf die Wettbewerber im Moodle-Ökosystem, die das Konzept ohnehin als Marktdruck beschreibt. Begründung der Aufnahme: Die GPL-Frage betrifft mastersolution unmittelbar; würde sie in der Vorlage fehlen und später von deren Technikern selbst entdeckt, beschädigte das die Vorlage rückwirkend. Unsere eigene Positionierung dazu (Ablehnung der Offenlegung) bleibt intern._ +- _R11 (Wiederverwendbarkeit) entfällt vollständig und wird auch nicht angedeutet. Der Punkt ist nicht argumentationstragend._ + +### 3.4 Annahmen + +|Nr.|Annahme|Status|Wirkung bei Widerlegung| +|---|---|---|---| +|A1|Endkunden betreiben unterschiedliche Moodle-Versionen ohne zeitnahes Major-Upgrade|konservativ gesetzt|Bei einheitlichem, aktuellem Stand verlöre B an Nachteil – die Empfehlung bliebe dennoch bestehen (G1, R10)| +|A2|Die native Moodle-App spielt bei Unternehmenskunden eine untergeordnete Rolle|**zu verifizieren**|Bei hoher App-Relevanz verschiebt sich die Bewertung von K3 (Anhang A); betrifft alle Optionen ähnlich| +|A3|mastersolution gewährt Web-Service-Zugriff in ausreichendem Umfang|plausibel|Ohne ausreichenden Zugriff wird K1/K2 zum Engpass; Rückfall auf Export-Wege| +|A4|Ein Mandant entspricht einer Moodle-Instanz|**zu verifizieren**|Multi-Tenant-Instanzen ändern die Berechtigungsarchitektur spürbar und stellen die Governance-Bewertung von Option B (5.3) infrage| + +A2 und A4 sind vor Fertigstellung bei mastersolution abzufragen. + +--- + +## 4. Bewertungskriterien + +Die Bewertung erfolgt qualitativ und argumentativ. Auf eine gewichtete Nutzwertanalyse wird bewusst verzichtet: Sie würde eine Präzision suggerieren, die bei Kriterien wie „Lizenzrisiko" oder „Kompetenzaufbau" nicht besteht, und die eigentliche Argumentation hinter Zahlen verstecken. + +|Nr.|Kriterium|Leitfrage| +|---|---|---| +|B1|Release-Kopplung|Wie stark bindet die Option unsere Auslieferung an den Moodle-Releasezyklus?| +|B2|Update-Weg über heterogene Stände|Wie viele Moodle-Nebenlinien müssen gleichzeitig lauffähig, getestet und gepflegt werden?| +|B3|Mandantenfähigkeit|Trägt die Option das Betreibermodell aus Konzept 5.5?| +|B4|Aufwand und Kompetenzbedarf|Welche Kompetenzen setzt die Option voraus, und wo liegen sie heute?| +|B5|Lizenz und geistiges Eigentum|Welcher Anteil des Systems unterläge einer Offenlegungspflicht?| +|B6|Funktionsdeckung|Lässt sich die Kernfunktion in ihrer geforderten Form überhaupt abbilden?| +|B7|Governance-Wiederverwendung|Wie viel der in 2.3 beschriebenen Ausstattung können wir nutzen statt selbst bauen?| + +B6 ist als K.-o.-Kriterium zu behandeln: Eine Option, die die Kernfunktion nur in verstümmelter Form trägt, ist unabhängig von allen anderen Kriterien nicht wählbar. B5 ist unter R10 ebenfalls K.-o.-tauglich. + +--- + +## 5. Optionen und Bewertung + +### 5.1 Der Optionsraum + +```mermaid +flowchart TD + A["A – Vollintegration
Kern als Placement im AI-Subsystem"] + B["B – Geteilte Integration
Externer Kern, Oberfläche als Placement"] + C["C – Eigenständiger Dienst
Standardbasierte Anbindung (LTI, Web Services)"] + D["D – Gestufte Integrationstiefe
C als Fundament, native Einbettung als Ausbaupfad"] + C -.->|Ausbaupfad| D +``` + +### 5.2 Option A – Vollintegration + +Die Kernfunktion wird als Placement-Plugin im AI-Subsystem realisiert; Retrieval, Kontextaufbereitung und Antwortlogik laufen innerhalb der Moodle-Installation, das Sprachmodell wird über einen Provider angebunden. + +**Bewertung:** Scheitert an B6 und B5. Die Kernfunktion hat keinen passenden Aktionstyp (G1); ein neuer Typ ist faktisch ein Core-Beitrag. Der Kern läge vollständig im GPL-Bereich (R10). Hinzu kommen B2 (Pflege über alle Kundenstände hinweg), B4 (Kompetenz nicht vorhanden, R9) und B3 (keine Mandantenfähigkeit, G3). Die GPU-Komponente aus Stufe 2 ließe sich ohnehin nicht in eine Moodle-Installation legen (G4, R5) – Option A ist spätestens ab Stufe 2 auch technisch nicht durchhaltbar. + +**Ergebnis: ausgeschlossen.** + +### 5.3 Option B – Geteilte Integration + +Kernlogik und Modell laufen als eigenständiger Dienst; die Nutzeroberfläche wird als Placement-Plugin im AI-Subsystem realisiert, das über einen Provider oder direkt auf unseren Dienst zugreift. + +**Bewertung:** B5 und B3 wären lösbar – der Kern bliebe proprietär und mandantenfähig. B7 wäre die Stärke dieser Option: Nutzungsrichtlinie, Capabilities und Protokollierung kämen aus dem Core. Diese Stärke gilt allerdings nur unter Annahme A4 (ein Mandant = eine Moodle-Instanz), denn die Core-Governance ist je Site konfiguriert; bei Multi-Tenant-Instanzen wäre auch sie neu zu bewerten. + +Sie scheitert jedoch an der Kombination aus B6, B2 und B4: + +- **B6:** Das Antwortformat wird durch die Antwortklassen der Core-Aktionen bestimmt. Belege, Timestamps und Modusanzeige – die Träger unseres Nachvollziehbarkeitsversprechens – müssten in Strukturen gepresst werden, die dafür nicht gedacht sind. +- **B2:** Ein Placement-Plugin muss über alle bei Endkunden vorhandenen Moodle-Nebenlinien lauffähig sein (R6) und über stark angepasste Oberflächen hinweg funktionieren (R7). Das Subsystem selbst ist dabei ein Bewegungsziel im Halbjahrestakt (2.2). +- **B4:** Diese Pflegelast träfe ein Team ohne Moodle- und PHP-Erfahrung (R9). + +Die drei Punkte sind einzeln beherrschbar und in Summe nicht. Der Ausschlussgrund ist also nicht die Idee, sondern ihre Betriebsrealität unter unseren Randbedingungen. + +**Ergebnis: nicht empfohlen.** + +### 5.4 Option C – Eigenständiger Dienst mit standardbasierter Anbindung + +Der Sovereign RAG Tutor läuft als eigenständiger, mandantenfähiger Dienst – On-Premise beim Endkunden oder im Rechenzentrum. Die Kopplung an Moodle erfolgt über etablierte Standardmechanismen (Aufruf und Rollenübergabe per LTI 1.3, Inhalts- und Ereigniszugriff über Moodle-Web-Services). Das AI-Subsystem wird nicht genutzt. + +**Bewertung:** + +- **B1/B2 – die Stärke.** Die Kopplung ruht auf Mechanismen, die seit Moodle 3.8 stabil verfügbar sind. Über die erwartbare Versionsspanne der Endkunden hinweg gilt dasselbe Verfahren. Unsere Auslieferung wird vom Moodle-Releasezyklus entkoppelt. +- **B3 – erfüllt.** Mandantenfähigkeit ist eine Eigenschaft unseres Dienstes, nicht der Moodle-Instanz. +- **B4 – erfüllt.** Der moodleseitige Anteil ist überwiegend Konfiguration, kein Code. Wo Code nötig ist, liegt er bei mastersolution (Kapitel 8). +- **B5 – erfüllt.** Der Kern bleibt proprietär; ein etwaiges schmales Moodle-Artefakt enthält keine Kernlogik. +- **B6 – erfüllt.** Wir bestimmen Antwortformat und Oberfläche vollständig selbst. +- **B7 – die Schwäche.** Nutzungsrichtlinie, Rechtefeinsteuerung und Protokollierung müssen wir selbst erbringen. + +**Zur Schwäche B7 im Detail:** Der Aufwand ist real und darf nicht kleingeredet werden; er beginnt zudem früh, denn die Basis-Governance (Zustimmung am Nutzungsort, Aktionsprotokollierung) wird mit dem ersten LLM-Kontakt in Stufe 2 fällig (8.1, 8.3). Er relativiert sich jedoch aus zwei Gründen. Erstens fällt er ohnehin an: Das Betreibermodell (5.5) und das Regulatorik-Paket (Stufe 3) verlangen Mandantentrennung, Begründungsprotokolle und Update-Gates in einer Form, die das Core-Modell nicht liefert. Zweitens ist ein eigenes Modell dem Core-Modell in genau dem Punkt überlegen, auf den es bei uns ankommt – Mandantentrennung –, und es gilt einheitlich über alle Kundenstände hinweg statt in vier Ausprägungen. + +**Grenze der Option:** Die Einbettung in die Moodle-Oberfläche bleibt weniger nahtlos als bei B. Der Absprung ins Material (Konzept 6.7: Kernfunktion, kein Nice-to-have) ist über direkte URL-Verweise in die Moodle-Kursstruktur lösbar, erfordert aber sorgfältige Spezifikation. (Bewusst nicht gemeint ist das LTI-Merkmal „Deep Linking" – dieses bezeichnet die Gegenrichtung, das Platzieren von Tool-Inhalten im LMS durch Lehrende.) + +**Ergebnis: tragfähig.** + +### 5.5 Option D – Gestufte Integrationstiefe + +Option C als Fundament, ergänzt um die bewusste Auslegung, dass eine tiefere Einbettung – Block-Plugin, später ggf. ein Placement im AI-Subsystem – als optionaler Ausbaupfad möglich bleibt, ohne die Architektur zu verändern. Voraussetzung ist, dass die Dienstschnittstelle von Beginn an oberflächenneutral geschnitten wird und keine Annahme über den aufrufenden Kanal trifft. + +**Bewertung:** Erbt alle Eigenschaften von C. Der Zusatzaufwand beschränkt sich auf Disziplin beim Schnittstellenschnitt, nicht auf zusätzliche Implementierung. Der Gewinn ist strategisch: Die Entscheidung über die Tiefe der Oberflächenintegration muss heute nicht getroffen werden und bleibt für mastersolution offen. + +**Ergebnis: empfohlen.** + +--- + +## 6. Richtungsempfehlung + +**Empfehlung: Option C, ausgelegt als Option D.** + +Der Sovereign RAG Tutor wird als eigenständiger, mandantenfähiger Dienst gebaut und über etablierte Standardmechanismen an mastersolution ONE gekoppelt. Die Dienstschnittstelle wird oberflächenneutral geschnitten, sodass eine tiefere Einbettung später ohne Architekturänderung nachrüstbar ist. + +**Die drei tragenden Gründe, in dieser Reihenfolge:** + +1. **Funktionsdeckung (B6).** Das AI-Subsystem hat für unsere Kernfunktion keinen passenden Aktionstyp. Eine Integration würde die Struktur kosten, die das Nachvollziehbarkeitsversprechen trägt – also genau das Merkmal, wegen dessen der Kunde das System kauft. +2. **Betriebsrealität über heterogene Kundenstände (B1/B2).** Eine Kopplung an ein Subsystem, das sich halbjährlich verändert, bei Endkunden mit unterschiedlichen Versionsständen und stark angepassten Installationen, erzeugt eine dauerhafte Pflegelast ohne funktionalen Gegenwert. +3. **Kompetenz- und Lizenzlage (B4/B5).** Der moodleseitige Anteil soll dort liegen, wo Moodle-Kompetenz vorhanden ist; der Produktkern soll nicht offenlegungspflichtig werden. + +_Hinweis zur Ableitung der Kundenfassung: Dort wird Grund 2 vorangestellt – die Entkopplung vom Moodle-Releasezyklus als Schutz der Investition von mastersolution über heterogene Kundenstände hinweg ist das gegenüber dem Kunden stärkste Argument. Grund 1 folgt an zweiter Stelle. Grund 3 wird aufgeteilt: die Lizenzfrage als eigenständiger dritter Grund im Sinne von R10 (Schutz des finanzierten Produktkerns), die Kompetenzlage nur in Gestalt der Arbeitsteilung aus Kapitel 8. An der Sachlage ändert die Umstellung nichts; sie ist hier dokumentiert, damit zwischen den beiden Fassungen keine stille Abweichung entsteht._ + +### 6.1 Der bewusst offen gelassene Freiheitsgrad + +Die Empfehlung legt **nicht** fest, wie tief die Oberflächenintegration am Ende reicht. Diese Frage bleibt für mastersolution offen und kann nach den Erfahrungen aus Stufe 1 und 2 entschieden werden – zu einem Zeitpunkt, an dem echte Nutzungsdaten vorliegen statt Vermutungen. Die Architektur trägt beide Ausgänge. + +Damit ist die Vorlage eine Richtungsvorgabe aus technischer Verantwortung, keine Vorwegnahme einer Produktentscheidung, die mastersolution zusteht. + +--- + +## 7. Verworfene Optionen und ihre Begründung + +Dieses Kapitel ist ausdrücklich nicht als Abwertung angelegt. Die Frage „warum nicht ins native Subsystem?" ist berechtigt und wird von mastersolution kommen; die Antwort muss belastbar sein und darf nicht nach Bequemlichkeit klingen. + +|Verworfen|Kernbegründung|Nachrangige Gründe| +|---|---|---| +|**A – Kern als Placement**|Kein passender Aktionstyp; Kern wäre offenlegungspflichtig|Pflegelast, Kompetenzbedarf, keine Mandantenfähigkeit, GPU-Profil| +|**B – Oberfläche als Placement**|Antwortformat durch Core-Aktionsklassen bestimmt; Belege/Timestamps nicht sauber abbildbar|Pflege über alle Nebenlinien und angepasste Oberflächen; Kompetenzbedarf| +|**Provider-Plugin als Träger**|Provider ist definitionsgemäß dünner Adapter ohne Datenhaltung; unser System ist das Gegenteil|–| +|**Direkter Datenbankzugriff für Ingestion**|Koppelt an ein Schema, das über die Versionsstände variiert – erzeugt genau das Risiko, das die Architektur vermeiden soll|Wartungslast bei Moodle-Upgrades der Endkunden| + +**Wichtige Klarstellung zu A und B:** Beide wären bei einer homogenen, aktuellen Moodle-Landschaft und vorhandener Moodle-Kompetenz ernsthaft erwägenswert – insbesondere B, wegen der Governance-Ausstattung (2.3). Der Ausschluss folgt aus unseren konkreten Randbedingungen, nicht aus einer generellen Schwäche des Subsystems. + +--- + +## 8. Konsequenzen + +### 8.1 Je Ausbaustufe + +**Stufe 1 (Souveräne Suche).** Berührt das AI-Subsystem konzeptionell gar nicht – es gibt kein Sprachmodell. Zu klären sind hier Inhaltszugriff für die Ingestion und Identitäts-/Berechtigungsübergabe. Beides über Standardmechanismen. Das ist die einfachste Stufe im Sinne dieser Entscheidung und eignet sich als Erprobung des Kopplungsverfahrens. + +**Stufe 2 (Nachschlage-Assistent).** Hier fällt die GPU-Komponente an; die Entscheidung bestätigt sich hier selbst, denn eine Modellkomponente mit eigenem Sizing-Profil lässt sich in keiner Moodle-Installation sinnvoll unterbringen. Zugleich wird hier die in 5.4 benannte Schwäche B7 erstmals wirksam: Mit dem ersten LLM-Kontakt der Nutzer braucht der Dienst die **Basis-Governance** – Zustimmung am Ort der Nutzung und Protokollierung der Aktionsaufrufe (die Bausteine aus 2.3, die das Subsystem geliefert hätte). Sie ist Bestandteil von Stufe 2, nicht Vorarbeit für Stufe 3, und fügt sich zeitlich in die ohnehin gegen Ende Stufe 2 beginnende juristische Begleitung. + +**Stufe 3 (Kompetenzmodell und Tracking).** Hier wird der Zugriff auf explizite Lernereignisse relevant. Die Basis-Governance aus Stufe 2 wird zur **vollen Regulatorik-Ausstattung** ausgebaut: Begründungsprotokolle, Rechtefeinsteuerung, konfigurierbare Vier-Augen-Freigaben. Diese muss stehen, bevor Stufe 3 produktiv geht, und ist als Teil des Regulatorik-Pakets zu planen, nicht als Zusatz. + +**Stufe 4 (Adaptive Didaktik).** Erstmals schreibende Aktionen im LMS (Einschreibung in generierte Lernpfade). Diese sind über Standardmechanismen abzubilden und unterliegen der Freigabelogik aus Konzept 5.3.3 – das System stößt an, entscheidet aber nicht. + +### 8.2 Wirkung auf O8 (Leistungsabgrenzung) + +Die Empfehlung impliziert eine Arbeitsteilung, die technischen und kommerziellen Schnitt zur Deckung bringt: + +- **d-opt** liefert den souveränen Dienst mit allen Komponenten aus Konzept 6.2–6.9. +- **mastersolution** liefert die moodleseitigen Artefakte: LTI-Registrierung, Web-Service-Konfiguration und Rollen, sowie – falls die Oberflächenintegration später vertieft wird – das zugehörige Moodle-Artefakt. + +Das ist sachlich begründet: Dort liegt die Moodle- und PHP-Kompetenz, dort liegt die Kenntnis der kundenspezifischen Anpassungen, und dort ist eine GPL-Offenlegung unproblematisch, weil das Artefakt keine Kernlogik enthält. + +_Intern:_ Diese Abgrenzung ist zugleich unsere Verhandlungsposition zu O8. Sie hält unseren Leistungsanteil scharf konturiert und vermeidet, dass wir in eine Betriebsverantwortung für fremde Moodle-Installationen hineinwachsen. + +### 8.3 Was zusätzlich zu leisten ist + +|Leistung|Stufe|Anmerkung| +|---|---|---| +|Basis-Governance: Zustimmung am Nutzungsort, Aktionsprotokollierung|2|Ersatz für die Core-Governance (2.3); mit erstem LLM-Kontakt erforderlich| +|Volle Regulatorik-Ausstattung: Begründungsprotokolle, Rechtefeinsteuerung, Vier-Augen-Freigaben|3|Ausbau der Basis-Governance; Teil des Regulatorik-Pakets| +|Rollen- und Berechtigungsabbildung Moodle → Dienst|1|Standardisierbar als Teil der Mandanten-Einführung| +|Absprungmechanik in Materialien|1|Kernfunktion laut Konzept 6.7; sorgfältig zu spezifizieren| +|Oberflächenneutraler Schnittstellenschnitt|1|Voraussetzung für den Ausbaupfad aus Option D| + +--- + +## 9. Revisionspunkte + +Die Entscheidung ist zu überprüfen, wenn eine der folgenden Bedingungen eintritt: + +**V1 – Moodle HQ erweitert das Subsystem substanziell.** Kämen chat- oder retrievaltaugliche Aktionstypen _und_ ein Mandantenmodell in den Core, würde ein optionales Placement attraktiv. Die Architektur bliebe gültig, weil der Kern extern liegt – genau dafür ist Option D ausgelegt. Der Ausbaupfad ist dann zu prüfen, nicht die Grundsatzentscheidung. + +**V2 – Die Versionslandschaft homogenisiert sich.** Sollte mastersolution eine einheitliche, aktuelle Moodle-Basis über alle Endkunden durchsetzen, entfiele der Nachteil B2. Die Empfehlung bliebe dennoch bestehen, getragen von B6 und B5. + +**V3 – Annahme A2 oder A4 erweist sich als falsch.** Hohe Relevanz der nativen Moodle-App oder Multi-Tenant-Moodle-Instanzen erfordern eine erneute Prüfung der Kopplungsmechanismen (Anhang A), nicht der Grundsatzentscheidung. + +**V4 – Die Lizenzposition ändert sich.** Sollte mastersolution eine Offenlegung des Kerns wünschen oder fordern, ist die Entscheidung vollständig neu zu führen – dann fiele das Kriterium B5 weg, und Option B rückte in Reichweite. + +_Hinweis zur Ableitung der Kundenfassung: V1–V3 werden übernommen; **V4 entfällt dort bewusst**. Begründung: V4 beschreibt das Szenario einer geänderten Offenlegungsposition – eine vertragliche und positionelle Frage, kein technischer Revisionsauslöser wie V1–V3, und in einer Entscheidungsvorlage nicht aktiv als Denkmöglichkeit anzubieten. Sollte mastersolution die Frage von sich aus stellen, gilt die Antwort aus V4._ + +--- + +## 10. Eintrag für das Entscheidungsregister + +Vorschlag zur Aufnahme in Konzeptdokument 8.2 (_Nummer bei Einpflege gegen den aktuellen Registerstand prüfen_): + +|Nr.|Entscheidung|Begründung (Kurzform)|Datum|Abschnitt| +|---|---|---|---|---| +|E-neu|Eigenständiger Dienst mit standardbasierter Moodle-Anbindung; AI-Subsystem nicht genutzt; tiefere Einbettung als offener Ausbaupfad|Kein passender Aktionstyp für die Kernfunktion; Entkopplung vom Moodle-Releasezyklus bei heterogenen Kundenständen; Kompetenz- und Lizenzlage|_Datum der gemeinsamen Entscheidung mit mastersolution, bei Einpflege einzutragen_|Diese Vorlage| + +Zugleich ist O1 in 8.1 als geschlossen zu kennzeichnen, mit Verweis auf diese Vorlage und die Revisionspunkte aus Kapitel 9. O8 ist um den Hinweis auf 8.2 dieser Vorlage zu ergänzen. + +--- + +## Anhang A – Kopplungsmatrix (intern) + +> **Nicht Bestandteil der Kundenfassung.** Dieser Anhang dokumentiert die technische Detailebene, aus der die Empfehlung abgeleitet ist. Er dient der späteren Spezifikationsarbeit. Die Diskussion mit mastersolution wird bewusst auf Optionsebene geführt. + +Die Grundsatzentscheidung zerfällt bei der Spezifikation in fünf getrennt zu beantwortende Kopplungspunkte: + +|Nr.|Kopplungspunkt|Ab Stufe|Optionen|Tendenz| +|---|---|---|---|---| +|K1|Inhaltszugriff (Ingestion)|1|Moodle Web Services · direkter Postgres-/Dateizugriff · Export-/Backup-Weg|Web Services; DB-Zugriff verworfen (Schemakopplung, R8)| +|K2|Identität und Berechtigungen|1|LTI 1.3 mit Rollenübergabe · OAuth2-SSO plus Web Services · Kombination|Kombination: LTI für Aufruf und Grobrolle, Web Services für die feingranulare Berechtigungsprüfung| +|K3|Oberfläche|1|External-Tool-Aktivität · Block-Plugin · Placement · eigene Weboberfläche|External Tool als Einstieg; Block/Placement als Ausbaupfad (Option D)| +|K4|Lernereignisse|3|Web Services · Events/Completion-API|Nach Stufe-2-Erfahrung zu entscheiden| +|K5|Schreibende Aktionen|4|Web Services schreibend|Mit Freigabelogik aus Konzept 5.3.3| + +**Zu K2 im Detail.** LTI 1.3 samt der Advantage-Dienste ist in Moodle seit Version 3.8 verfügbar; die Rollen- und Einschreibungsinformationen eines Kurses lassen sich darüber abrufen. Das ist der Grund, warum diese Kopplung über die erwartbare Versionsspanne trägt – und warum sie überwiegend Konfiguration statt Code ist. Die Grenze: Das LTI-Rollenvokabular ist grob (Instructor, Learner, …). Unsere Berechtigungsfilterung auf Index-Einheiten-Ebene (Konzept 6.2) braucht mehr Auflösung; deshalb die Kombination mit Web Services. + +**Zu K3 im Detail.** Der Absprung in Materialien und Video-Timestamps (Konzept 6.7) ist der kritische Punkt. Er ist über direkte URL-Verweise in die Moodle-Kursstruktur lösbar (Kurs-, Abschnitts- und Aktivitäts-URLs, bei Video ergänzt um Timestamp-Parameter), muss aber gegen die kundenspezifisch angepassten Oberflächen (R7) getestet werden. Terminologische Abgrenzung: LTI Deep Linking bezeichnet die Gegenrichtung – Lehrende platzieren Tool-Inhalte im LMS. Es ist für den Ausbaupfad in K3 relevant (Einbettung unserer Oberfläche als Aktivität), nicht für den Material-Absprung. + +**Offene Detailfragen für die Spezifikationsphase:** Verhalten bei Materialänderungen im laufenden Betrieb (Reindizierung, Differenzvorschläge nach Konzept 5.3.2); Umgang mit Kursen, die nach der Indizierung neu berechtigt werden; Latenzbudget der Berechtigungsprüfung pro Suchanfrage. + +--- + +## Anhang B – Quellen + +**Moodle-Entwicklerdokumentation (Primärquellen für Kapitel 2):** + +- AI Subsystem, Version 4.5: https://moodledev.io/docs/4.5/apis/subsystems/ai — Architektur der vier Bausteine, Aktionsklassen (`generate_text`, `generate_image`, `summarise_text`), AI-User-Policy-Mechanik +- AI Plugins (Provider- und Placement-Typen), Version 5.0: https://moodledev.io/docs/5.0/apis/plugintypes/ai — Core-Provider und Core-Placements, Trennung der Plugintypen +- Provider-Entwicklung, Version 4.5: https://moodledev.io/docs/4.5/apis/plugintypes/ai/provider — „Thin-Wrapper"-Charakter der Provider, keine eigene Datenhaltung +- Placement-Entwicklung, Version 4.5: https://moodledev.io/docs/4.5/apis/plugintypes/ai/placement — Zugriffssteuerung durch Placements, Manager-Workflow + +**Moodle-Nutzerdokumentation:** + +- AI subsystem (4.5): https://docs.moodle.org/405/en/AI_subsystem — Struktur Placements/Actions/Providers, Administrationszugang +- AI placements (5.1): https://docs.moodle.org/501/en/AI_placements — Summarise/Explain, Kurs- und Aktivitätsschalter, Capabilities +- AI tools (5.2): https://docs.moodle.org/502/en/AI_tools — Aktionsübersicht nach Rollen und Kontext +- New features (5.2): https://docs.moodle.org/502/en/New_features — Gemini- und Bedrock-Provider im Core +- Publish as LTI tool (5.2): https://docs.moodle.org/502/en/Publish_as_LTI_tool — LTI 1.3 / LTI Advantage (AGS, NRPS, Deep Linking) + +**Sekundärquellen (Marktbeobachtung, Plugin-Ökosystem):** + +- Accipio: „Moodle AI: What it Does, How it Works" — https://www.accipio.com/blog/leveraging-the-power-of-moodle-ai/ — Provider-Landschaft inkl. Ollama/LiteLLM/LocalAI, Manager-Rolle +- AI Tutor Blog: „Best AI Moodle Plugins" — https://ai-tutor.ai/blog/best-ai-moodle-plugins/ — `local_ai_manager` als Mandanten-Infrastruktur, Einschätzung zur Core-Roadmap, App-Limitierungen bei Chat-Plugins +- eLeDia: „New in Moodle 5.2" — https://eledia.de/en/neu-in-moodle-5-2/ — keine strukturellen AI-Änderungen in 5.2 gegenüber 5.0/5.1 + +_Abrufstand: August 2026. Da sich das Subsystem im Halbjahrestakt verändert, ist der Faktenteil (Kapitel 2) vor jeder Wiedervorlage gegen den dann aktuellen Stand zu prüfen; die Entwicklerdokumentation ist versioniert und erlaubt den Abgleich je Moodle-Version._