Eine KI-Plattform für die Hochschule bauen

Ein eigener Zugang zu Sprachmodellen für eine Hochschule verlangt zuerst Antworten auf die Betriebsfragen — welche Daten eingegeben werden dürfen, wer wofür freigeschaltet ist, was bei dreißig gleichzeitigen Nutzern passiert und wie sich Kosten begrenzen lassen, ohne die Nutzung einzuschränken. Bei den kommerziellen Anbietern sind diese Funktionen im Produkt enthalten.

Den Anlass gab die vorhandene Praxis: Mitarbeitende arbeiteten mit einzeln abgeschlossenen Konten bei verschiedenen Anbietern. Solche Konten lassen sich zentral nicht freischalten und nicht begrenzen, und die Kosten fallen an verschiedenen Stellen an.

Was die Plattform von einem Chatzugang unterscheidet

Die Plattform ist auf mehr als einen Chatdienst angelegt: Sie liegt als eigene Schicht zwischen Organisation, Nutzern, Modellen und Werkzeugen. Darunter lassen sich Modelle, Werkzeuge und spätere Anwendungen anschließen, ohne die Verwaltung erneut zu bauen.

Praktisch heißt das: Die Hochschule legt fest, wer Modelle nutzen darf, welche Modelle je Nutzergruppe verfügbar sind, welche Funktionen freigegeben sind, welche Budgets gelten und welche Nutzungsdaten ausgewertet werden. Der Modellanbieter bleibt dabei austauschbar.

Der Rahmenvertrag kommt zuerst

Vor der Technik stand die Beschaffung. Die NBS bezieht ihre Cloud-Ressourcen über den europäischen Rahmenvertrag OCRE24, der Hochschulen erlaubt, solche Ressourcen unter Einhaltung der für sie geltenden Datenschutz- und Vergabevorschriften zu nutzen. Nach unserer Kenntnis ist die NBS die erste Hochschule, die diesen Vertrag umgesetzt hat; seither fragen andere Hochschulen danach.

Das ist der Grund, warum der Aufbau auf Amazon Bedrock steht. Damit liegt die Verarbeitung im europäischen Rechtsraum, und die Auswahl an Modellen bleibt offen.

Zwei fremde Bausteine, und warum es zwei sind

Die Oberfläche kommt aus einem quelloffenen Projekt: ein Chatfenster, das dem ähnelt, was die kommerziellen Anbieter im Browser zeigen, mit einer Anschlussleiste für Werkzeuge und Skills. Eine Nutzerverwaltung bringt es nicht mit — keine Selbstregistrierung, keine Rollen — und keine Abrechnung.

Der zweite Baustein ist eine Vermittlungsschicht, ebenfalls quelloffen. Sie reicht Anfragen an die Modelle weiter, führt Schlüssel und rechnet ab. Ohne sie bräuchte jeder Angemeldete einen eigenen Zugangsberechtigten beim Modellanbieter, was sich für eine Hochschule nicht führen lässt. Stattdessen vergibt sie virtuelle Schlüssel.

Rollen und Modellfreigabe

Einen festen Modellkatalog führt die Plattform nicht. Welche Modelle technisch vorhanden sind, ergibt sich aus der Einrichtung der Vermittlungsschicht; welche davon eine Nutzergruppe verwenden darf, ist eine Entscheidung der Hochschule. Ein neues Modell wird einmal technisch eingerichtet und danach je Rolle freigegeben; die Oberfläche bleibt dabei unverändert.

Neben den Modellen beim Anbieter lässt sich ein selbst betriebenes Modell anschließen, das auf der eigenen Infrastruktur läuft. Es steht im selben Katalog, unterliegt derselben Freigabe je Rolle und erscheint in der Oberfläche als weitere Auswahl im Modellmenü.

Rollen sind als Stammdaten angelegt. Eine Rolle legt fest, welche Funktionen und Modelle offen sind, welche Budgetart gilt, welche Auswertung vorgesehen ist und ob die Anmeldung in zwei Schritten verpflichtend ist. Studierende haben beispielsweise keinen Zugang zu den teuersten Modellklassen. Neue Anforderungen werden als neue Rolle angelegt; bestehende Rollen behalten ihre Bedeutung.

Was die Verwaltung leisten muss

Der eigene Anteil liegt fast vollständig zwischen den fremden Bausteinen. Er umfasst rund 20.000 Zeilen und dazu ein Testprogramm, das 162 Punkte zwischen Front- und Backend prüft.

• Organisationen als Kostenstellen, darunter Rollen, darunter Nutzer
• Budgets in drei Formen: monatlich erneuernd, einmalig auslaufend, unbegrenzt
• Warnung bei 80 Prozent, Sperre bei 100 Prozent, automatische Rückstellung am Stichtag
• Einladung, Passwortrücksetzung, Sperre nach fünf Fehlanmeldungen, Zwei-Faktor-Pflicht je Rolle
• Auditprotokoll über alle Vorgänge
• Modellfreigabe je Rolle
• Auswertung nach Tag, Organisation, Rolle und Modell
• Ausgabe je Nutzer und Modell für den laufenden und den Vormonat, damit sich die Kosten nach Organisation weiterberechnen lassen

Die Kosten stammen aus den Rückmeldungen des Modellprotokolls; dieser Rückkanal ist in die Abrechnung eingebaut.

Betrieben wird das Ganze auf einer eigenen Maschine, inzwischen in sechzehn Containern; ein Kaltstart dauert drei Minuten. Der Aufbau lässt sich auch in ein eigenes Rechenzentrum stellen.

Die Suche zeigt ihre Quellen

Websuche gehört zu den Funktionen, nach denen zuerst gefragt wird. Dahinter liegt eine selbst betriebene Metasuchmaschine, die über zweihundert Suchmaschinen ansprechen kann und mit achtzig eingerichtet ist, und ein Crawler mit mindestens zehn Arbeitsprozessen, der aus den Treffern die Inhalte nachlädt. Beides ist quelloffen und läuft auf der eigenen Maschine.

Google erkennt die Anfragen einer solchen Metasuche und weist sie ab. Welche Suchmaschinen abgefragt werden, ist zentral eingestellt; bevorzugen lassen sich europäische Anbieter wie Qwant.

Dateien in Office-Formaten erzeugt das Modell, indem es ein kleines Programm schreibt, das eine passende Bibliothek benutzt, und es ausführt.

Was im Haus bleibt

Die Frage, welche Daten das Haus verlassen, steht in Gesprächen mit anderen Hochschulen an erster Stelle. Bei staatlichen Häusern entscheidet sie darüber, ob ein Zugang überhaupt eingeführt werden kann.

An den Modellanbieter geht allein, was die einzelne Anfrage braucht: die Frage, den erforderlichen Kontext und die ausdrücklich beigefügten Dateien. Über den Rahmenvertrag OCRE24 liegt diese Verarbeitung im europäischen Rechtsraum.

Mit einem selbst betriebenen Modell entfällt auch dieser Weg nach außen: Frage, Kontext und Dateien bleiben auf der eigenen Infrastruktur. Weil beide Betriebsarten im selben Katalog stehen, lässt sich je Rolle festlegen, für welche Nutzergruppen ausschließlich das eigene Modell zur Verfügung steht.

Auf der Modellseite lassen sich zusätzlich Inhaltsfilter, gesperrte Themen und die Erkennung personenbezogener Daten zuschalten. Die Architektur unterstützt damit einen DSGVO-gerechten Betrieb. Ob eine Hochschule insgesamt rechtskonform arbeitet, hängt zusätzlich von ihren Prozessen, Verträgen, Verarbeitungszwecken und Einstellungen ab.

Wiederverwenden und anschließen

Prompts, Agenten und angeschlossene Werkzeuge sind teilbare Gegenstände. Die Freigabe läuft über das Rechtemodell — für einzelne Personen, Gruppen oder Rollen, mit abgestuften Rechten vom Ansehen über das Bearbeiten bis zur vollen Kontrolle. Eine Personensuche in den Freigabedialogen erlaubt es, einen Baustein gezielt zuzuordnen, statt ihn für alle sichtbar zu schalten.

Was ein Zugang leisten kann, hängt daran, worauf er zugreifen darf: auf Wissensbestände, Dateiablagen, Fachsysteme. Angeschlossen werden sie über das Model Context Protocol (MCP), über REST-Schnittstellen oder über eigene Dienste. Ein Werkzeug erhält dabei die Rechte, die sein Zweck verlangt; seine Nutzung wird protokolliert.

Was stabil bleibt und was ausgetauscht wird

Stabil gehalten wird die organisatorische Seite: Nutzer, Rollen, Budgets, Auswertung, Auditprotokoll. Modelle, Anbieter und Werkzeuge lassen sich austauschen, ohne diese Seite zu ändern.

Die fremden Bausteine bleiben dabei möglichst unverändert. Wo eine Anpassung nötig ist, soll sie klein, abgegrenzt und dokumentiert sein, damit sich die Bausteine weiter aktualisieren lassen.

Wie es weitergeht

Im Herbst geht die Plattform in den Prototypbetrieb, zunächst mit wenigen Nutzern an zwei Hochschulen. Für die Hochschulen und für KIWIT ist die Nutzung kostenfrei. Verwaltet werden soll sie gemeinsam von den beteiligten Häusern, mit verteilten Administrationsrechten.

Der nächste Schritt verbindet die Plattform mit der übrigen Projektarbeit: Die Wissensbasis zur KI-Regulierung soll als Werkzeug angeschlossen werden. Fragen zur Regulierung lassen sich dann gegen diesen Bestand beantworten.