KI-Tutor selbst bauen: die unterschätzten Herausforderungen
Ein System aufsetzen, das Fragen der Studierenden rund um die Uhr beantwortet, es an das eigene LMS anbinden, es durch die Klausurenphase stabil halten und danach Jahr für Jahr weiterentwickeln. Sobald eine Hochschule ernsthaft über einen eigenen KI-Tutor nachdenkt, steht früh eine Grundsatzfrage im Raum: selbst bauen oder eine fertige Lösung lizenzieren?
Diese Frage ist selten rein technisch. Sie entscheidet über Personal, Budget und darüber, wer die Verantwortung für den laufenden Betrieb trägt. Wir schreiben das als Anbieter und können hier nicht neutral sein. Trotzdem legen wir die Abwägung so sachlich wie möglich dar, inklusive der Fälle, in denen ein Eigenbau die richtige Entscheidung ist.
Der Maßstab und wann sich ein Eigenbau lohnt:
Build heißt: die Hochschule entwickelt den KI-Tutor selbst oder lässt ihn entwickeln, hostet ihn und betreibt ihn dauerhaft in eigener Verantwortung. Buy heißt: die Hochschule lizenziert eine bestehende Lösung und bezieht Betrieb, Wartung und Weiterentwicklung als Leistung des Anbieters. Beide Wege sollen zum selben sichtbaren Ergebnis führen, einem Tutor, den Studierende nutzen. Der Unterschied liegt darunter: bei wem Entwicklungskompetenz, Betriebslast und Kostenrisiko dauerhaft liegen.
In unsere Erfahrung ist folgender Punkt zentral zu verstehen: Eine Eigenentwicklung konkurriert nicht mit einem anderem spezialisierten Anbieter, sondern mit ChatGPT, Gemini und NotebookLM. Das ist der Erfahrungsstandard, den Studierende täglich nutzen und an dem sie jedes hauseigene Werkzeug messen. Ist die Eigenentwicklung auch nur ein wenig umständlicher oder schwächer, weichen Studierende auf diese Systeme aus, und die investierte Zeit ist verloren, weil das Werkzeug zwar existiert, aber nicht benutzt wird. Der Punkt ist: Der eigentliche Wettbewerb ist der um Nutzerfreundlichkeit, und er hört nicht auf.
Ein Eigenbau hat reale Vorteile: Er kann Anwendungsfälle abdecken, die am Markt nicht erhältlich sind, die gewünschte Datenhoheit erfüllen und baut KI- und Softwarekompetenz im eigenen Haus auf. Technisch ist praktisch jede Hürde überwindbar, und viele Hochschulen bringen die Kompetenz dafür mit. Damit sich der Weg lohnt, müssen aber mehrere Bedingungen gleichzeitig erfüllt sein: dauerhaft verfügbare KI- und Softwareentwicklungskompetenz, nicht nur für die Projektphase, und ein mehrjähriges Budget für Entwicklung und Betrieb.
Die entscheidende Bedingung ist strategisch, nicht technisch: ob ein eigener KI-Tutor für die Hochschule so wichtig ist, dass sie sich bewusst darüber differenzieren will. Diese Frage steht am Anfang der Überlegung, nicht am Ende. Gut, wenn klare strategische Differenzierung gewollt ist, Kompetenz und Budget dauerhaft bereitstehen und spezielle Anwendungsfälle den Markt übersteigen. Weniger gut, wenn der Tutor vor allem ein solides Standardwerkzeug sein soll und das Personal bereits ausgelastet ist.
Was in der Planung regelmäßig unterschätzt wird:
Der häufigste Planungsfehler ist, die Eigenentwicklung an der ersten funktionierenden Demo zu messen. Ein Prototyp, der in 80 Prozent der Fälle funktioniert, ist für den Produktivbetrieb noch nicht brauchbar, und die letzten 20 Prozent kosten deutlich mehr als die ersten 80. Vier Posten werden dabei fast immer zu niedrig angesetzt.
Modell-Updates: Sprachmodelle ändern sich laufend, mehrere größere Updates pro Jahr sind die Regel, und jedes macht erneute Regressionstests der eigenen Prompts nötig. Ein Teil der Kapazität geht so dauerhaft in das Nachziehen bestehender Funktionen.
Laufender Betrieb: Der größte Posten ist nicht die API-Rechnung, sondern die Zeit von Fachkräften für Betrieb, Monitoring und die Reaktion auf Störfälle. Die spürbaren Kosten sind Personalkosten, und sie fallen jedes Jahr an.
Datenschutz und Infrastruktur: Wer selbst hostet, übernimmt die volle Verantwortung für den Datenschutz, für die Anbindung an das Single-Sign-On der Hochschulföderation und für die LMS-Integration, etwa an Moodle über LTI 1.3, den offenen Integrationsstandard von 1EdTech. Zusammen ergibt das eine dauerhafte Betriebsaufgabe, keine einmalige Entwicklung.
Halluzinationskontrolle: In der Regel sollte ein KI-Tutor so konzipiert sein, dass er erfundene Antworten minimiert und seine Antworten an freigegebenen, kursbezogenen Inhalten verankert. Der etablierte Weg dafür ist RAG (Retrieval-Augmented Generation): Das System schlägt vor jeder Antwort in einer definierten Wissensbasis nach, etwa den hinterlegten Kursunterlagen, und stützt die Antwort auf das dort Gefundene, statt frei aus dem allgemeinen Modellwissen zu formulieren. Diese Wissensbasis über alle Kurse hinweg sauber zu pflegen, ist klassische Softwareingenieursarbeit.
KI-Tutoren werden saisonal genutzt. In der Klausurenphase steigt die Nachfrage schnell auf das 10- bis 20-fache des Normalbetriebs. Für dieses Lastprofil gibt es zwei Wege, und beide haben ihre Tücken. Auf eigener Hardware bedeutet es, GPU-Kapazität in eben diesem Vielfachen vorzuhalten, die den Rest des Jahres weitgehend brachliegt. In der Cloud ist die Skalierung technisch gelöst, dafür wird die Kostenplanung zum Problem, weil Funktionen wie Podcast-Generierung oder KI-Avatare ein Vielfaches an Tokens verbrauchen, teils das Zehnfache. Für die Hochschule heißt das: Verlässliche Betriebskostenprognosen sind bei einem Eigenbau schwer, unabhängig vom gewählten Weg. Bei einer lizenzierten Lösung liegt dieses Planungsrisiko beim Anbieter.
Produkt, Personal und die Entscheidung:
Ob eine Eigenentwicklung den Maßstab von ChatGPT und Co. dauerhaft trifft, entscheidet sich weniger an Tokens, GPUs und Datenhaltung als an der Produktarbeit dahinter. Der schwierigste Teil ist, etwas zu bauen, das Studierende tatsächlich nutzen wollen. Das erfordert kontinuierliche Arbeit: regelmäßige Nutzerinterviews, Umfragen und die Auswertung des realen Nutzungsverhaltens. Diese Arbeit endet nie und entscheidet darüber, ob Studierende das System am Ende wirklich verwenden.
Um ein System zu bauen, das den heutigen Fähigkeiten spezialisierter Lösungen nahekommt, braucht es nach unserer Erfahrung dauerhaft drei bis vier Personen in Vollzeit, etwa drei Entwickler und einen Product Manager. Dieser Punkt wird oft übersehen, weil unterstellt wird, vorhandenes Personal könne das nebenbei mitmachen. In der Praxis werden die Stellen entweder neu geschaffen oder aus anderen Aufgaben abgezogen, die dann liegen bleiben. Als Arbeitgeber liegen die Personalkosten grob bei 200.000 bis 300.000 Euro pro Jahr, zuzüglich Infrastruktur, GPU- beziehungsweise Cloud-Kosten und Skalierungsreserven.
Aber statt der reinen Gesamtsumme lohnt vor allem der Blick auf die Kostenstruktur. Beim Eigenbau bleibt das Kostenrisiko im Haus, inklusive der schwer planbaren Skalierungskosten. Eine lizenzierte Lösung verursacht wiederkehrende, planbare Lizenzkosten, während das Skalierungs- und Betriebsrisiko beim Anbieter liegt. Die Frage ist damit weniger, welcher Weg absolut günstiger ist, sondern wer das Kostenrisiko tragen soll.
Technisch machbar ist der Eigenbau. Die eigentliche Frage ist, ob eine Hochschule ihn Jahr für Jahr betreiben und als Produkt weiterentwickeln will. Für Häuser, die sich strategisch bewusst über einen eigenen KI-Tutor differenzieren wollen und Kompetenz wie Budget dauerhaft bereitstellen, kann das der richtige Weg sein. Für die meisten anderen ist eine lizenzierte Lösung schneller produktiv und im laufenden Betrieb risikoärmer. Dazwischen liegen Zwischenwege wie eine anpassbare Lösung oder eine befristete Pilotphase. Die ehrliche Vorarbeit besteht darin, diese Grundsatzfrage zu beantworten, bevor die erste Demo gebaut wird, nicht danach. Zur Orientierung fasst die folgende Matrix zusammen, welche Kriterien eher für Build und welche eher für Buy sprechen.
