Enterprise AI Hub

Der Bereich Enterprise AI Hub richtet sich an Instanz-Admins und umfasst die systemweite Verwaltung, die über einzelne Mandanten hinausgeht. Hier werden KI-Modelle gepflegt (Modellwartung) und Mandanten auf Plattform-Ebene angelegt und verwaltet.

Dieser Bereich ist nur in Enterprise-Installationen sichtbar. In der gehosteten SaaS-Variante übernimmt diese Aufgaben der Betreiber, für Mandanten-Admins ist er nicht sichtbar.

KI-Modelle

Im Bereich KI-Modelle werden die verfügbaren KI-Modelle für die gesamte Plattform konfiguriert. Modelle werden in drei Kategorien unterteilt:

• Chat-Modelle: Für die Konversation und Antwortgenerierung in Agents.
• Embedding-Modelle: Für die Umwandlung von Texten in Vektoren (verwendet bei der Wissensverarbeitung).
• Speech-to-Text-Modelle: Für die Transkription von Spracheingaben.

Modell erstellen

Beim Erstellen eines Modells werden folgende Felder konfiguriert:

Basisinformationen

• Modelltyp: Chat, Embedding oder Speech-to-Text.
• Anzeigename: Der Name, der in der Benutzeroberfläche angezeigt wird (z. B. „GPT-4o", „text-embedding-3-large").
• Ist Aktiv: Inaktive Modelle stehen nicht für neue Aufgaben oder Zuweisungen zur Verfügung.

Typspezifische Felder

Chat-Modelle:

Chat-Modelle bringen einige Einstellungen mit. Das Formular gruppiert sie in die Abschnitte Reasoning, Antwortverhalten, Tool-Nodes und Erweitert. Alle Werte gelten global, wo das Modell läuft, solange eine Flow-Node sie nicht überschreibt.

Embedding-Modelle:

• Modellabmessungen: Die Größe der erzeugten Vektoren (z. B. 1536). Werte über 2.000 können die Datenbankperformance beeinträchtigen.
• Dynamische Abmessungen: Ob das Modell verschiedene Vektordimensionen unterstützt.

Speech-to-Text-Modelle:

• Antwortformat: json (Standard), text oder verbose_json (segmentbasierte Filterung, nur Whisper).

Reasoning

Modelle nehmen Einstellungen zum Nachdenken unterschiedlich entgegen: Manche erwarten ein Level, andere wiederum einen An/Aus Schalter im Chat-Template, und wieder andere lassen sich gar nicht steuern. Welche Form ein Modell versteht, wird hier gepflegt. Davon hängt ab, was eine Flow-Node später anbieten kann.

• Reasoning-Steuerung: Wie die Einstellung an den Endpoint geht.
  • Effort-Level: Das Modell nimmt mit jeder Anfrage ein Level entgegen (reasoning_effort, auf der Responses-API reasoning.effort).
  • Thinking on/off: Das Modell schaltet das Nachdenken über ein Flag in chat_template_kwargs an und ab. Es gibt keine Level.
  • Keine Steuerung: AI-Hub sendet nichts. Das Modell bleibt bei dem, was sein Endpoint von sich aus tut, und Flow-Nodes können daran nichts ändern.
• Template-Key (nur bei Thinking on/off): Der Schlüssel, den das Chat-Template liest — bei selbst gehosteten Modellen meist enable_thinking.
• Verfügbare Level (nur bei Effort-Level): Die Level, die dieser Endpoint akzeptiert. Nur aus dieser Auswahl können Flow-Nodes später wählen.
• Standard-Reasoning-Effort bzw. Vor dem Antworten nachdenken: Der Wert, mit dem das Modell läuft, solange keine Flow-Node etwas anderes setzt.
• Reasoning-Effort sperren bzw. Nachdenken sperren: Verhindert, dass Flow-Nodes den Standardwert überschreiben.

Level je Endpoint

Welche Level ein Endpoint kennt, unterscheidet sich je Anbieter: OpenAI reicht beispielsweise von minimal bis xhigh, GLM kennt low, high und max, andere Modelle kennen nur an und aus.

Antwortverhalten

• Standard-Temperatur: Wie fokussiert oder kreativ die Antworten ausfallen (0–2). Leer lassen, um den Standard des Anbieters zu verwenden.
• Standard-Timeout: Wie lange eine einzelne Anfrage dauern darf, bevor sie abgebrochen wird.

Tool-Nodes

• Reflexions-Tool: Ob Agents zwischen Toolaufrufen innehalten dürfen, um die Ergebnisse zu bewerten. Jede Reflexion kostet eine zusätzliche Modellanfrage. Die Einstellung wirkt nur dort, wo das Modell in einer Tool-Node läuft.

Zusätzliche Request-Parameter

Über die Felder oben hinaus unterstützen manche Anbieter weitere Parameter, für die AI-Hub keine eigene Einstellung hat — Sampling-Werte wie top_p, aber auch anbieterspezifische Schalter. Das Feld Zusätzliche Request-Parameter im Abschnitt Erweitert nimmt sie als JSON-Objekt auf und sendet sie unverändert mit jeder Anfrage.

Nur Parameter eintragen, die der Anbieter dokumentiert

Ein Parameter, den der Endpoint nicht kennt, lässt jede Anfrage an dieses Modell fehlschlagen — Azure und OpenAI antworten dann mit 400 Unknown parameter. Die Parameter unterscheiden sich je Anbieter: top_k etwa weisen Azure und OpenAI ab, während selbst gehostete Deployments ihn erwarten. Nach einer Änderung eine Anfrage an das Modell testen.

Parameter, die AI-Hub selbst setzt (model, messages, stream, tools, temperature, max_tokens, reasoning_effort und weitere), werden beim Speichern abgelehnt — die Felder oben bleiben so die einzige Stelle, an der Temperatur, Token-Limits und das Nachdenken eingestellt werden.

Das Nachdenken selbst gehört deshalb nicht mehr hierher, sondern in den Abschnitt Reasoning. Braucht ein Modell neben dem Thinking-Flag weitere Template-Argumente, können sie hier stehen: AI-Hub führt sie mit dem Flag aus dem Reasoning-Abschnitt zusammen.

Modellkonfiguration

• Modellname: Eindeutiger, kleingeschriebener Bezeichner für interne und API-Referenzen.
• Schema: Das Kommunikationsmuster mit der API — Azure oder OpenAI.
• Responses API (nur bei Chat-Modellen): Aktivieren, wenn der Endpoint /responses statt /chat/completions bedient. Die Level im Abschnitt Reasoning bleiben dieselben, nur der Schlüssel im Request folgt der Schnittstelle. Passt die Einstellung nicht zum Endpoint, schlägt jede Anfrage an das Modell mit 400 fehl.
• Instanz: Der Instanzname oder die Endpoint-URL des Modells.
• API-Version: Die API-Version, die für Anfragen verwendet wird.
• API-Schlüssel: Der Authentifizierungsschlüssel. Wird sicher gespeichert und nach dem Speichern nicht mehr angezeigt.

tipp

Im Bearbeitungsmodus kann die Verbindung über die Schaltfläche Verbindung testen überprüft werden.

Eigene Modelle (BYOM)

Die Integration kundeneigener oder lokal betriebener Modelle (Bring Your Own Model) ist in Planung. Lokale Modelle sollen künftig in der UI als eigene Kategorie neben Cloud-Modellen erscheinen und pro Mandant isoliert verwaltet werden können.

Standard-Modelle

Für jede Komplexitätsstufe muss genau ein Standard-Modell zugewiesen werden:

Komplexitätsstufe	Verwendung
Einfach	Für einfache, unkomplizierte Aufgaben
Komplex	Für anspruchsvolle, komplexe Aufgaben

Nur aktive Modelle können als Standard zugewiesen werden. Beim Deaktivieren oder Löschen eines Standard-Modells muss zuerst eine Alternative gewählt werden.

Mandanten

Im Bereich Mandanten können auf Plattform-Ebene neue Mandanten (Organisationen) erstellt und verwaltet werden.

• Name: Der Name des Mandanten.

Die detaillierte Konfiguration eines Mandanten (Branding, Nutzungsbedingungen, Workspaces, Benutzer) erfolgt über die Mandanten-Verwaltung.

Die Übersicht zeigt zusätzlich den Status und das Erstellungsdatum jedes Mandanten an und lässt sich über die Suche und den Filter einschränken — beim Status stehen die Werte Aktiv, Wird angelegt, Wird gelöscht und Archiviert zur Auswahl.

Plan

Jeder Mandant hat einen Plan. Der Plan legt fest, welche Funktionen dem Mandanten überhaupt zur Verfügung stehen — unabhängig davon, welche Berechtigungen die einzelnen Benutzer haben. Damit eine Person eine Funktion nutzen kann, müssen beide Bedingungen erfüllt sein: die Funktion ist im Plan des Mandanten enthalten und die Person hat die passende Berechtigung.

Welche Pläne es gibt, wie sie heißen und welche Funktionen sie enthalten, wird pro Installation festgelegt. Es kann also je Installation zwei, drei oder mehr Pläne geben — welche für einen Mandanten in Frage kommen, weiß der Betreiber der Installation.

Über Pläne gesteuert werden typischerweise Funktionen wie API-Schlüssel, Widgets und Automationen, also die Nutzung des AI Hub außerhalb der Admin-Oberfläche. Funktionen, die in der Installation nicht über Pläne gesteuert werden (z. B. Chat, Agents oder Wissensquellen), stehen jedem Mandanten unabhängig vom Plan zur Verfügung.

Der Plan wirkt für alle Rollen — auch für Instanz-Admins. Fehlt eine Funktion im Plan, verschwinden die zugehörigen Menüpunkte für alle Benutzer des Mandanten.

Plan setzen

Den Plan setzt der Instanz-Admin in der Mandanten-Verwaltung unter Basisdaten im Feld Plan. Zur Auswahl stehen die Pläne der Installation; gespeichert wird über den Speichern-Button der Seite. Mandanten-Admins sehen dasselbe Feld, können es aber nicht ändern.

Der Plan lässt sich nur aus dem Mandanten heraus setzen, zu dem er gehört — dazu also zuerst in den Mandanten wechseln. Eine mandantenübergreifende Plan-Übersicht gibt es bewusst nicht.

Auswirkung einer Umstellung

Wird ein Mandant auf einen Plan umgestellt, der eine bisher genutzte Funktion nicht enthält, wirkt das sofort — auch auf bereits eingerichtete Integrationen. Zum Beispiel:

• Bestehende API-Schlüssel werden nicht mehr akzeptiert; Aufrufe der REST-API scheitern an der Authentifizierung.
• Eingebettete Widgets antworten nicht mehr.
• Gestartete Automationen werden mit einem entsprechenden Hinweis als fehlgeschlagen abgebrochen.

Konfiguration und Schlüssel bleiben dabei erhalten und sind nach einem Wechsel auf einen Plan mit den entsprechenden Funktionen wieder nutzbar.

info

Pläne werden über die Umgebungsvariable PLANS der Installation definiert; angezeigt und ausgewählt wird jeweils der technische Schlüssel des Plans. Bei der Einführung der Pläne wurden bestehende Mandanten so eingestuft, dass sich für sie nichts ändert.

Mandant archivieren

Ein Mandant kann über das Kontextmenü in der Mandanten-Übersicht archiviert werden, ohne ihn löschen zu müssen. Ein archivierter Mandant:

• ist in der Mandanten-Auswahl (rechts oben) nicht mehr sichtbar,
• ist für seine Benutzer nicht mehr zugänglich — auch der Zugriff über API-Schlüssel (z. B. eingebettete Chats) ist deaktiviert,
• bleibt mit allen Daten erhalten (z. B. für die Verrechnung) und wird weiterhin in der Mandanten-Übersicht mit dem Status Archiviert angezeigt,
• verbraucht keine Tokens und keine Rechenzeit mehr: Hintergrund-Prozesse wie Wissens-Synchronisierungen und Automatisierungen werden gestoppt.

Über das Kontextmenü kann ein archivierter Mandant jederzeit reaktiviert werden. Die Benutzer erhalten dann wieder Zugriff, die Hintergrund-Prozesse laufen ab der nächsten planmäßigen Ausführung wieder an.

In einen archivierten Mandanten wechseln

Damit die Verrechnung auch nach dem Archivieren möglich bleibt, kann ein Instance Administrator über Zu Mandant wechseln im Kontextmenü der Mandanten-Übersicht weiterhin in einen archivierten Mandanten einsteigen. Dort stehen nur noch die Analyse, die Mandanten-Verwaltung (Einstellungen, Workspaces, Benutzer, Nutzungsbedingungen) und die Mandanten-Übersicht zur Verfügung. Alle Bereiche, in denen Tokens verbraucht werden – Chats, Playground, Agenten, Wissen und Automatisierung – bleiben gesperrt.

Der archivierte Mandant wird dabei in der Mandanten-Auswahl und in der Bereichsanzeige mit dem Zusatz (archiviert) gekennzeichnet. Er wird nicht als zuletzt gewählter Mandant gespeichert: beim nächsten Start landet man wieder in einem aktiven Mandanten.

Cron Jobs

Unter Instanz-Verwaltung → Cron Jobs listet eine vom Framework bereitgestellte Seite die zeitgesteuerten Hintergrundjobs der Instanz auf. Sie ist für den Betrieb der Plattform gedacht — etwa um zu prüfen, ob eine planmäßige Verarbeitung tatsächlich stattgefunden hat.

Die Übersicht zeigt pro Job Name, Zeitplan, Status (Aktiv oder Pausiert) und Letzter Job Run (bzw. Niemals, wenn der Job noch nie gelaufen ist).

Pro Job stehen zwei Aktionen zur Verfügung:

• Job-Ausführungen anzeigen: Öffnet die Liste der bisherigen Ausführungen mit Status und Laufzeit. Über Logs anzeigen ist die Ausgabe einer einzelnen Ausführung einsehbar — sofern die Instanz Logs vorhält.
• Job jetzt starten: Löst den Job außerhalb des Zeitplans aus. Die Aktion wird über einen Dialog bestätigt.

info

Die Synchronisation von Verknüpftem Wissen wird nicht hier gesteuert, sondern pro Wissensquelle über deren Synchronisationsfrequenz.