Vorbereitungsphase · Dossier

Vorbereitungsphase September 2026: Executive Summary

Stand 23. September: Vor dem geförderten Projektstart wurden Anforderungen, Forschungsfragen, Vision Prototype, Governance und technische Grundlagen vorbereitet. Dieses Dossier fasst die wichtigsten fachlichen Erkenntnisse, offenen Hypothesen und nächsten Schritte für Projektteam, Beirat und Praxispartner zusammen.

9. September 2026 – 23. September 2026

Executive Summary

Der geförderte Projektzeitraum von IncluLearn.AI beginnt am 1. Oktober 2026. Die Arbeiten bis einschließlich 23. September sind deshalb keine vorgezogenen Projektergebnisse, sondern eine Vorbereitungsphase, in der zentrale Annahmen, Arbeitsweisen und technische Grundlagen so weit konkretisiert wurden, dass der Projektstart nicht bei null beginnt.

Für Projektteam und Beirat sind sechs Punkte besonders wichtig:

1. Das Praxisproblem ist größer als OCR. Öffentliche Prozessbeschreibungen von Medienzentren zeigen hohe manuelle Aufwände, lange Vorlaufzeiten, fachlich anspruchsvolle Transformationen und etablierte Wiederverwendung. Einzelne Einrichtungen nennen beispielsweise 20 Minuten bis eine Stunde pro Schulbuchseite, vier bis acht Wochen Vorlauf oder mindestens drei Monate Vorbereitung für zentrale Prüfungen. Diese Werte sind institutionsspezifisch, machen aber die Größenordnung und die Prozesskomplexität sichtbar.

2. Aus der Recherche wurden zwölf Bedarfshypothesen abgeleitet – noch keine validierten Anforderungen. Dazu gehören semantische Voraufbereitung, MINT-Diagrammverständnis, Expert Review, Multiformat-Ausgabe, Batch-Verarbeitung, Wiederverwendung, Auflagenvergleich, Prüfungsworkflows, Standards, Provenienz, individuelle Ausgabeprofile und inklusive Zusammenarbeit.

3. Der fachliche Kern wird als Semantic-first-Problem verstanden. Komplexe MINT-Artefakte sollen nicht nur beschrieben, sondern als Entitäten, Relationen, Werte und fachliche Struktur rekonstruiert werden. Aus einer geprüften semantischen Grundlage könnten anschließend unterschiedliche Repräsentationen entstehen – etwa strukturierter Text, Mathematikformate, Audio oder taktile Ausgaben.

4. Aktuelle KI-Benchmarks beantworten nur einen Teil der Qualitätsfrage. Gute Visual-Question-Answering-Werte bedeuten nicht automatisch vollständige und fachlich korrekte Rekonstruktion. IncluLearn.AI will deshalb technische Strukturmetriken, kritische Fehlerklassen, fachliche Äquivalenz, Accessibility, Reviewaufwand und spätere Nutzerleistung getrennt betrachten. Fine-Tuning bleibt eine mögliche Maßnahme, aber nicht der automatische erste Schritt.

5. Der Vision Prototype ist eine Produkt- und UX-Hypothese, keine fertige Plattform. Er zeigt bereits eine nach Nutzerzielen strukturierte, barrierearm angelegte DE/EN-Oberfläche für Materialien, Review und Freigaben. Die sichtbaren Inhalte sind jedoch synthetische Demo-Daten; produktive Persistenz, Authentifizierung und die vollständige Verarbeitungsarchitektur sind noch nicht integriert.

6. Governance und technische Architektur sollen menschliche Verantwortung sichtbar halten. KI darf vorbereiten, aber ihren eigenen Output nicht selbst als verifiziert oder freigegeben einstufen. Technische Dienste werden modular hinter stabilen Verträgen gedacht; TTS ist der erste konkrete Processing Service. Demo-Betrieb und späterer Produktivbetrieb werden bewusst getrennt.

Was im September vorbereitet wurde

Projekt- und Arbeitsstruktur

Für Aufgaben, verbindliche Entscheidungen, fachliche Dokumentation, offenen Austausch und öffentliche Kommunikation wurden getrennte Arbeitswege vorbereitet. Der zentrale Gedanke lautet: Diskussionen dürfen niedrigschwellig sein, handlungsrelevante Ergebnisse müssen anschließend aber in eine nachvollziehbare fachliche Quelle überführt werden.

Auch der Newsroom folgt diesem Prinzip: Interne Aktivität wird nicht automatisch als Fortschritt veröffentlicht. Beiträge sollen konkrete Ergebnisse, Evidenz, Unsicherheiten und offene Fragen erklären.

Bedarfs- und Anforderungsanalyse

Die öffentliche Recherche zu Medienzentren und Umsetzungsdiensten wurde von einer Sammlung einzelner Hinweise in eine nachvollziehbare Kette überführt:

Quelle/Evidenz → Zielgruppe → Bedarf → Use Case → Anforderung → Akzeptanzkriterium → Implementierung → Evaluation

Die zwölf Bedarfshypothesen und die daraus abgeleitete Dienstpriorisierung dienen als Gesprächs- und Planungsgrundlage. Sie müssen mit Medienzentren, Lehrenden, blinden und sehbehinderten Lernenden sowie weiteren Praxispartnern geprüft, verändert oder verworfen werden.

Forschungs- und Evaluationsstrategie

Der Forschungsstand wurde so strukturiert, dass unterschiedliche Evidenzarten sichtbar bleiben: Peer Review, Preprints, Standards, Projektinformationen und eigene Vorarbeiten werden nicht gleich behandelt.

Für die technische Evaluation wurde ein mehrstufiges Bild vorbereitet: syntaktische Korrektheit, semantische Rekonstruktion, fachliche Äquivalenz, Accessibility/Usability und tatsächliche Aufgabenleistung sind unterschiedliche Qualitätsdimensionen.

Vision Prototype und Plattformarchitektur

Der öffentliche Vision Prototype schafft bereits ein gemeinsames Objekt für Diskussionen über Navigation, Begriffe, Statusmodelle, Review und Barrierefreiheit.

Parallel wurde die Zielarchitektur so vorbereitet, dass Webplattform, Host-Infrastruktur und spezialisierte Processing Services getrennte Verantwortungsbereiche besitzen. Modelle und Engines sollen austauschbar bleiben, solange ihre fachlichen Verträge stabil sind.

Governance und Qualitätssicherung

KI-Beteiligung und menschlicher Prüfstatus werden als getrennte Dimensionen behandelt. Plausibilisierung, Verifikation und Freigabe haben unterschiedliche Zwecke und Prüftiefen.

Persönliche Accessibility- und Ausgabepräferenzen werden nicht als Berechtigungsrollen oder automatisch als medizinische Diagnosen modelliert. Datenklassifikation und Provenienz sollen später helfen, geeignete Verarbeitungswege und Reviewanforderungen auszuwählen.

Transfer und offene Anschlussfähigkeit

Mit MathML, EPUB Accessibility, DAISY Pipeline, Pandoc und PlantUML wurden erste offene Standards und Werkzeuge als Referenzpunkte eingeordnet. Dabei wurde bewusst noch keine endgültige Toolauswahl getroffen.

Die zentrale Transferfrage lautet vielmehr: Welche bestehenden Formate, Werkzeuge und Produktionssysteme können an eine geprüfte semantische Zwischenschicht anschließen, ohne parallele Inselworkflows zu schaffen?

Was wir fachlich bereits gelernt haben

Aus den bisherigen Vorarbeiten ergibt sich ein klareres Bild des eigentlichen Problems:

• Professionelle barrierefreie Medienaufbereitung ist ein Produktions- und Qualitätsprozess, kein einzelner Konvertierungsschritt.
• Alt-Text allein reicht für viele MINT-Artefakte nicht aus, weil Relationen, Werte, räumliche oder logische Strukturen und Aufgabenbezüge erhalten bleiben müssen.
• Wiederverwendung, Versionsvergleich und Provenienz sind fachlich relevante Funktionen und nicht nur technische Komfortmerkmale.
• Human Review muss gezielt unterstützt werden. Der Nutzen von KI hängt nicht nur von automatischer Genauigkeit ab, sondern auch davon, wie schnell Fachpersonen Unsicherheiten erkennen, korrigieren und freigeben können.
• Nutzerqualität und technische Modellqualität sind nicht identisch. Eine korrekte Datenstruktur ist noch nicht automatisch verständlich, effizient navigierbar oder didaktisch geeignet.
• Modularität ist ein Forschungs- und Transferfaktor. Modelle, TTS-Engines und einzelne Analysebausteine sollten austauschbar bleiben, während Semantik, Evaluationsdaten und Schnittstellen stabiler werden.

Was noch nicht validiert ist

Mehrere wichtige Punkte bleiben bewusst offen:

• Die zwölf Bedarfshypothesen wurden noch nicht durch eigene Interviews oder systematische Nutzertests bestätigt.
• Die Einteilung möglicher Dienste in P1/P2/P3 ist eine Lösungshypothese, keine freigegebene Produkt-Roadmap.
• Der Vision Prototype zeigt einen plausiblen Arbeitsablauf, aber noch keinen produktiven End-to-End-Betrieb mit realen Nutzerdaten.
• Der erste TTS-Dienst ist technisch konkreter geworden, aber noch nicht produktiv in die Plattform integriert oder auf der tatsächlichen Zielhardware vollständig qualifiziert.
• Aktuelle VLM- und Diagramm-Benchmarks müssen daraufhin geprüft werden, wie gut ihre Werte mit vollständiger Strukturrekonstruktion und tatsächlicher Zugänglichkeit zusammenhängen.
• Offen ist, welche Repräsentation für welche MINT-Artefaktklasse und Lernaufgabe am besten funktioniert.

Diese Unsicherheiten sind kein Mangel der Vorbereitung, sondern markieren die Fragen, die im geförderten Projekt systematisch beantwortet werden sollen.

Was erst ab 1. Oktober beginnt

Mit dem 1. Oktober beginnt der geförderte Projektzeitraum. Erst ab dann werden die vorbereiteten Hypothesen, Artefakte und technischen Grundlagen als reguläre Projektarbeit weitergeführt.

Zu den unmittelbar anstehenden Aufgaben gehören insbesondere:

• Bedarfe und Arbeitsabläufe mit Praxispartnern und Zielgruppen validieren,
• einen geeigneten Korpus und Referenzdaten für MINT-Artefakte aufbauen,
• Anforderungen und Akzeptanzkriterien auf Basis dieser Evidenz schärfen,
• Baselines für Dokument- und Diagrammverständnis vergleichbar evaluieren,
• den Vision Prototype schrittweise mit echten Backend- und Processing-Komponenten verbinden,
• Evaluations- und Reviewprozesse mit Blick auf Accessibility und fachliche Korrektheit erproben.

Die Vorbereitung soll dabei nicht nachträglich als bereits erreichtes Projektergebnis umetikettiert werden. Sie ist die Ausgangsbasis, gegen die spätere Fortschritte und Kurskorrekturen nachvollziehbar werden.

Was wir vom Beirat jetzt besonders brauchen

Besonders wertvoll sind Rückmeldungen dort, wo interne Projektannahmen auf reale Praxis treffen: bei tatsächlichen Engpässen in der Medienaufbereitung, der Priorisierung der zwölf Bedarfshypothesen, kritischen Fehlerarten, notwendigen Human-Review-Schritten, bestehenden Formaten und Schnittstellen sowie bei der Verständlichkeit des Vision Prototypes.

Der Newsroom bündelt solche Fragen zusätzlich auf der Seite „Beirat & Partner“ und verlinkt sie jeweils mit ihrem fachlichen Kontext.