- Erste Schritte
- Datensicherheit und Compliance
- Organisationen
- Authentifizierung und Sicherheit
- Lizenzierung
- Über die Lizenzierung
- Einheitliche Preise: Lizenzierungsplan-Framework
- Aktivieren Ihrer Enterprise-Lizenz
- Migrieren von Test Suite zu Test Cloud
- Lizenzmigration
- Zuweisen von Lizenzen zu Mandanten
- Zuweisen von Benutzerlizenzen
- Freigegeben von Benutzerlizenzen
- Überwachung der Lizenzzuweisung
- Lizenzüberzuweisung
- Lizenzierungsbenachrichtigungen
- Benutzerlizenzverwaltung
- Mandanten und Dienste
- Konten und Rollen
- AI Trust Layer
- Über AI Trust Layer
- Überprüfung der Nutzungszusammenfassung
- Anzeigen von Überwachungsprotokollen
- Verwalten von AI Trust Layer-Richtlinien
- PII-Maskierung
- Verwalten von Autopilot for Everyone
- Konfigurieren von LLMs
- Einschränken von LLM-Aufrufen auf Ihre eigenen Modelle
- Konfigurieren von OpenTelemetry
- Steuern von kontextbezogenen Daten für GenAI-Funktionen
- Externe Anwendungen
- Benachrichtigungen
- Protokollierung
- Datenexport
- Tests in Ihrer Organisation
- Fehlersuche und ‑behebung
- Migration zur Test Cloud
Zentrale AI Trust Layer-Ansicht der LLM-Nutzung über UiPath-Produkte hinweg, mit Modellstatus, Routing und Ersatzsteuerelementen pro Mandant.
Model Hub ist ein spezieller Bereich innerhalb des AI Trust Layer , in dem Administratoren und Compliance-Teams nachvollziehen können, wie LLMs in UiPath-Produkten in einem Mandanten oder einer Organisation verwendet werden.
Damit können Sie an einem einzigen Ort sehen, welche Modelle vorhanden sind und wo sie ausgeführt werden, ihren Status verstehen, das Routing konfigurieren, wo sie unterstützt werden, und Modelle durch Ihr eigenes Abonnement oder Modell ersetzen. Der Modellhub stellt den effektiven Status der Governance auf Mandantenebene dar, die durch AI Trust Layer und Automation Ops-Richtlinien definiert ist; identitätsspezifische Richtlinienzuweisungen für Benutzer und Gruppen bleiben in Automation Ops.
Vorteile des Model Hub
| Nutzen | Was es ermöglicht |
|---|---|
| Zentralisierte Modellvorgänge | Arbeiten Sie mit Modellnutzung, Status und Routing über Produkte und Funktionen hinweg an einem Ort. |
| Schnellere Compliance-Sicherheit | Validieren Sie, welche Anbieter und Modelle verwendet werden und wie der Datenverkehr weitergeleitet wird. |
| Geringeres Betriebsrisiko | Blockierte und veraltete Modelle frühzeitig anzeigen. |
| Kontrolliertes Änderungsmanagement | Verfolgen Sie Konfigurationsänderungen und ob ein System oder ein Benutzer sie initiiert hat. |
| Self-Service-Benutzerdefinierte LLM-Konfigurationen | Ersetzen Sie unterstützte Modelle durch Ihr eigenes Abonnement (BYOS), oder fügen Sie Ihr eigenes Modell (BYOM) hinzu. |
Organisations- vs. Mandantenansicht
Der Modellhub ist als Registerkarte in der AI Trust Layer-Verwaltungsumgebung verfügbar und ist auf Organisationsebene und auf Mandantenebene zugänglich. Die Ebene bestimmt, was Sie sehen und ändern können.
| Aspekt | Organisationsansicht | Mandantenansicht |
|---|---|---|
| Zweck | Eine einfache Übersicht und ein Launchpad für die Mandantenebene. | Der Hauptkonfigurationsbereich für die Modelle eines Mandanten. |
| Informationen werden angezeigt | Eine Karte pro Mandant mit der Anzahl der Modelle, der Mandantenregion und der Statusanzahl wie Aktiv, Benutzerdefiniert oder Demnächst veraltet. | Ein Raster der verwendeten Modelle pro Produkt und Funktion. |
| Verfügbare Aktionen | Durchsuchen von Mandanten und deren Status auf hoher Ebene, Öffnen eines Mandanten mit Details anzeigen und Starten eines benutzerdefinierten Modells mit Benutzerdefiniertes Modell hinzufügen. | Konfigurieren von Routing, Ersetzen von Modellen und Überprüfen des Konfigurationsverlaufs. |
| Einschränkungen | Keine Konfiguration pro Funktion, Routingänderungen oder Residency-Einstellungen. | Zeigt nur den effektiven Status auf Mandantenebene an. |
Informationen zum Aktualisieren mit den Modellen in einem Mandanten finden Sie unter Verwalten von Modellen im Modellhub.
Mandantenraster
Das Mandantenraster listet pro Funktion und Modell eine Zeile mit den folgenden Standardspalten auf, gruppiert nach Produkt.
| Spalte | Was angezeigt wird | Warum es wichtig ist |
|---|---|---|
| Produkt | Produktnamen wie Agents fungieren als Gruppenheader; Die Zeilen darunter identifizieren die einzelne Funktion oder Fähigkeit, die das Modell verwendet. | Ein Produkt kann je nach Funktion mehrere Modelle verwenden. |
| Modell | Das verwendete Modell. | Identifiziert, was in der Praxis ausgeführt wird. |
| Anbieter | Der Modellanbieter. | Erforderlich für die Governance und Compliance von Anbietern. |
| Verwaltet von | UiPath oder Benutzerdefiniert für benutzerdefinierte LLM-Konfigurationen (BYOS oder BYOM). | Klärt Eigentum und Verantwortung. |
| Modell-Routing | Die Routingregion, falls zutreffend. | Unterstützt Residency- und Continuity-Argumentation. |
| Modellstatus | Aktiv, Blockiert, Bald veraltet | Betriebsbereitschaft und Compliance. |
Statuskarten wie Aktiv, Benutzerdefiniert, Bald veraltet und Blockierte Funktionen fassen den Mandanten zusammen und filtern das Raster, wenn es ausgewählt ist. Das Spaltensteuerelement fügt optionale Spalten hinzu, wie z . B. Standardmodell, und Suche und Filter grenzen die Liste ein.
Produkt- und Funktionssichtbarkeit
Das Raster zeigt nur die Produkte und Funktionen an, die für Ihren Mandanten aktiviert sind. Wenn ein Produkt nicht aktiviert ist, z. B. Autopilot oder eine bestimmte Agent-Funktion, werden seine Zeilen nicht angezeigt.
Document Understanding wird im Modellhub noch nicht unterstützt. Die Modelle werden nicht im Raster angezeigt und können nicht über Modellhub verwaltet werden.
Wie sich Richtlinien im Model Hub widerspiegeln
Der Modellhub spiegelt die AI Trust Layer-Richtlinien und die damit verbundene Automation Ops-Governance wider, die für jeden Mandanten gelten.
In der Mandantenansicht zeigt das Banner für die Datenaufbewahrung an, ob eine Richtlinie für den Mandanten gilt, und ermöglicht es Ihnen, darauf zu reagieren. Wenn eine Richtlinie angewendet wird, wird sie anhand des Namens identifiziert, und Sie können sie an derselben Stelle ändern oder entfernen. Wenn der Mandant noch keine Richtlinie hat, werden Sie vom Model Hub zum Erstellen einer Richtlinie aufgefordert, als Ausgangspunkt für die Steuerung, wo Modelle ausgeführt werden und welche Modelle verfügbar sind.
Richtlinien decken mehr als nur dieRessourcen ab. Eine AI Trust Layer-Richtlinie kann:
- Erzwingen der Datenresidenz und zulässiger Regionen, konfiguriert auf der Registerkarte Regionen der Richtlinie – siehe Datenresidenz.
- Blockieren Sie bestimmte Modelle oder Anbieter, z. B. alle OpenAI-Modelle.
- Blockieren Sie den LLM-Datenverkehr eines Produkts, z. B. Autopilot.
Wenn eine Richtlinie etwas blockiert, spiegelt das Raster dies wie folgt wider:
- Blockierte Modelle oder Anbieter werden mit dem Status Blockiert angezeigt und auf der Statuskarte Blockierte Funktionen gezählt.
- Wenn der LLM-Datenverkehr eines Produkts blockiert ist, werden die diesem Produkt zugeordneten Modelle und seine Funktionen auch als Blockiert angezeigt.
Richtlinien können auf Mandanten-, Gruppen- oder Benutzerebene angewendet werden, aber das Raster zeigt nur die effektive Situation auf Mandantenebene. Ein Modell, das nur für einen bestimmten Benutzer oder eine bestimmte Gruppe blockiert ist, wird möglicherweise nicht im Raster als blockiert angezeigt. Richtlinienzuweisungen und effektive Einstellungen pro Identität sind in Automation Ops verfügbar.
| Richtlinien-Scope | Im Mandantenraster widergespiegelt? | Wo validiert werden soll |
|---|---|---|
| Mandant | Ja | Modell-Hub |
| „Gruppieren“ (Group) | Nicht angezeigt (nur Mandantenansicht) | Automation Ops |
| Benutzer | Nicht angezeigt (nur Mandantenansicht) | Automation Ops |
Datenaufbewahrung
Die in Model Hub angezeigten Informationen zur Datenresidenz spiegeln die in den AI Trust Layer-Richtlinien definierte Konfiguration wider. Die Durchsetzung der Residency für den von UiPath verwalteten Datenverkehr wird auf der Registerkarte Regionen der Richtlinie konfiguriert, wo Sie definieren, durch welche Regionen der LLM-Datenverkehr weitergeleitet werden darf.
Standardmäßig priorisiert UiPath die Produktkontinuität: Produkte sollen auch dann weiter funktionieren, wenn ein Modell in der bevorzugten Region des Mandanten nicht verfügbar ist, sodass der Datenverkehr durch die nächstgelegene verfügbare Region weitergeleitet werden kann. Wenn beispielsweise ein Modell in Australien nicht verfügbar ist, kann der Datenverkehr an die nächstgelegene unterstützte Region weitergeleitet werden, damit das Produkt betriebsbereit ist.
Wenn Sie die Residenz erzwingen, kann der LLM-Datenverkehr nur durch die von Ihnen zugelassenen Regionen weitergeleitet werden. Wenn der Datenverkehr nicht durch eine zulässige Region weitergeleitet werden kann, schlägt die Anforderung fehl und die abhängige Produktfunktion kann damit fehlschlagen. Dies ist ein beabsichtigter Kompromiss: Strikte Compliance hat Vorrang vor Kontinuität.
Benutzerdefinierte LLM-Konfigurationen
Der Modellhub zeigt kundengesteuerte Einträge mit Verwaltet von auf Benutzerdefiniert an. Eine benutzerdefinierte LLM-Konfiguration hat eine von zwei Formen:
- Bring Your Own Subscription (BYOS): Das gleiche unterstützte Modell, das in Ihrem eigenen Abonnement ausgeführt wird.
- Bring Your Own Model (BYOM): Ein Modell außerhalb der vordefinierten Liste für das Produkt.
Da benutzerdefinierte Einträge kundengesteuert sind, gelten Aufbewahrung, Richtlinien und Veraltung unterschiedlich für sie:
- Die Spalte Modellweiterleitung ist für benutzerdefinierte Einträge leer. Dies wird erwartet: UiPath leitet das Routing nicht ab oder konfiguriert Ihre benutzerdefinierten Modellendpunkte.
- Residency-Richtlinien steuern, wohin UiPath nur von UiPath verwalteten Datenverkehr weiterleitet. Ein benutzerdefinierter Eintrag wird nicht blockiert, wenn ein von UiPath verwaltetes Modell in einer zulässigen Region nicht verfügbar ist, da das Routing für benutzerdefinierte Modelle vollständig durch Ihre Endpunktkonfiguration bestimmt wird. Die Erfüllung Ihrer Residenzanforderungen hängt vom Hosting und der Konfiguration Ihrer Endpunkte in konformen Regionen ab.
- Sie besitzen den Lebenszyklus jeder benutzerdefinierten LLM-Konfiguration. Wenn ein Modell, das Sie über eines verwenden, veraltet ist, benachrichtigt UiPath Sie und Ihre Administratoren sind dafür verantwortlich, vor dem Datum der Einstellung zu einem Ersatz zu migrieren. Die Migrationsschritte werden unter Verwalten von Modellen in Model Hub beschrieben.
Wenn eine benutzerdefinierte Konfiguration fehlt, veraltet oder falsch konfiguriert ist, funktioniert sie möglicherweise nicht mehr. In diesem Fall kehrt das System automatisch zu einem von UiPath verwalteten LLM zurück, um die Kontinuität aufrechtzuerhalten, es sei denn, von UiPath verwaltete LLMs werden über eine Automation Ops-Richtlinie deaktiviert – dann schlagen die Anforderungen fehl und die Funktionen, die auf dem Modell basieren, funktionieren nicht mehr.
Die Einrichtungs- und Ersetzungsverfahren werden unter Konfigurieren von LLMs und Verwalten von Modellen im Modellhub beschrieben.
Modellstatus und Veraltung
Die Spalte Status zeigt, wo sich jedes Modell in seinem Lebenszyklus befindet.
| Status | Bedeutung |
|---|---|
| Aktiv | Das Modell ist zur Verwendung verfügbar. |
| Wird bald eingestellt | Das Modell wird an einem bekannten Datum eingestellt, das in den Statusdetails zusammen mit dem Ersatzmodell angezeigt wird. Tests und Migration werden empfohlen. |
| Vorschau | Das Modell bietet begrenzte Unterstützung, einschließlich für Residency. |
| Blockiert | Das Modell oder sein Datenverkehr wird durch eine Richtlinie blockiert. |
Weitere Informationen zum Modelllebenszyklus finden Sie unter: