Deployment & Betriebsmodell
Aktuelle Deployment-Topologie, Anbieter, Konfigurationsschalter und institutionelle Verantwortlichkeiten
Deployment heute
Die GENIE-Plattform wird als selbst gehosteter, containerisierter Stack betrieben, der von einer einzelnen einsetzenden Partei betrieben wird. Deployment-Definitionen existieren als Docker-Compose-Dateien für Produktion und Staging sowie als Helm-Charts für Kubernetes.
| Komponente | Deployment | Status |
|---|---|---|
| Webanwendung und API | Container, Helm-Deployment | Verfügbar |
| Assistant-Laufzeitumgebung | Container, Helm-Deployment | Verfügbar |
| Hintergrund-Worker (Warteschlange, Graph-Projektion, geplante Jobs) | Separate Deployments und Cron-Jobs | Verfügbar |
| Medienserver und SIP-Gateway | Selbst gehostete Dienste (ein verwalteter Mediendienst wird ebenfalls unterstützt) | Verfügbar |
| PostgreSQL mit Vektorerweiterung, Redis | Zustandsbehaftete Dienste im Cluster | Verfügbar |
| Health-Endpunkte und Sitzungs-Lebenszyklus-Ereignisse | Eingebaut | Verfügbar |
Externe Anbieter
| Funktion | Anbieterklasse | Fallback |
|---|---|---|
| Sprachmodell | Cloud-Anbieter über ein Gateway mit konfigurierbarer Modell-Allowlist (eine Modellfamilie konfiguriert) | kein automatischer |
| Speech-to-Text | Cloud-Anbieter | kein automatischer |
| Text-to-Speech | Cloud-Anbieter | automatischer Fallback zu einem zweiten Anbieter |
| Speech-to-Speech (optionaler Modus) | Cloud-Anbieter | — |
| Telefonie | SIP-Trunk- und SMS-Anbieter | — |
| Web-Recherche (optional) | Suchanbieter, nur wenn konfiguriert | — |
| Anmeldung | Google OAuth | — |
Konfigurationsschalter
Fähigkeiten sind einzeln per Konfiguration umschaltbar. Schalter, die in der aktuellen Produktionskonfiguration ausgeschaltet sind, umfassen den Reflexionsdurchlauf, das abgestufte Agent-Routing, den Gruppenmodus, die Spracherkennung registrierter Personen und die sitzungsbezogene Tonmodulationsschicht. Schalter fungieren als manuelle Notausschalter je Funktion.
Zwei Konfigurationstatsachen sind für jeden kontrollierten Piloten wichtig: Die Kohorten-Zugangskontrolle muss explizit konfiguriert werden, da der Zugriff ohne Konfiguration offen ist; und die administrative Oberfläche wird nur für eine explizit konfigurierte Allowlist aktiviert.
In Entwicklung für das institutionelle Deployment
In Entwicklung| Option | Beschreibung |
|---|---|
| Dediziertes Private-Cloud-Deployment je Institut | Ein separater Stack je Institut, betrieben von ecrop oder einem Partner, in einer vereinbarten Region. |
| On-Premises- oder Kunden-VPC-Deployment | Installation innerhalb der eigenen Infrastruktur des Instituts. In Entwicklung; heute nicht verfügbar. |
| Enterprise-Identitätsföderation | Anmeldung über den Identitätsanbieter des Instituts. |
| Mandantentrennung auf Institutsebene | Isolation auf Organisationsebene zusätzlich zur kontobezogenen Abgrenzung. |
| Log-Export | Strukturierter Export von Vorgangsartefakten in das Logging und Monitoring des Instituts. |
| Anbieter-Region-Festlegung | Vertragliche und technische Regionsauswahl für Modell-, Sprach- und Telefonieanbieter. |
| Modellanbieter-Failover | Automatisches Failover zwischen Modellanbietern. |
Heute existiert kein paketiertes On-Premises-Produkt, kein kundenseitiger Deployment-Selektor und keine Multi-Tenant-Steuerungsebene.
Betriebsmodell und Verantwortlichkeiten
| Bereich | ecrop (Technologieanbieter) | Einsetzendes Institut |
|---|---|---|
| Software und Updates | Stellt Releases, Änderungsdokumentation und Evaluationsergebnisse bereit. | Genehmigt Änderungen gemäß eigenem Änderungsprozess. |
| Verwendungszweck und Anwendungsfälle | Dokumentiert Fähigkeiten, Grenzen und Statuslabel. | Definiert Verwendungszweck, Ausschlüsse und menschliche Entscheidungspunkte. |
| Regulatorische Einordnung | Stellt technische Fakten bereit. | Klassifiziert je Anwendungsfall (AI Act, DORA-Kritikalität, Auslagerung, Datenschutz). |
| Identität und Zugriff | Stellt Identitätsföderation (in Entwicklung) und Rollenzuordnung bereit. | Verwaltet Nutzer, Rollen und Freigaben. |
| Drittanbieter | Dokumentiert Anbieterklassen und Fallbacks. | Bewertet Anbieterabhängigkeit, Datenverarbeitung und Ausstiegsoptionen im eigenen Drittparteirisikoprozess. |
| Aufzeichnung und Aufbewahrung | Stellt Mechanismen für den Gedächtnis-Lebenszyklus bereit sowie, sobald gebaut, Legal Hold. | Definiert Aufbewahrungsklassen und erfüllt Aufzeichnungspflichten mit eigener Infrastruktur. |
| Vorfallbehandlung | Stellt Feature-Schalter, Protokolle und Support bereit. | Betreibt das Incident-Management und entscheidet über die Abschaltung. |
| Lizenzpflichtige Tätigkeiten | Keine. | Wird ausschließlich von lizenzierten Partnern durchgeführt. |
Testen und Änderungsmanagement
Die GENIE-Plattform verfügt über eine umfangreiche automatisierte Testsuite für die Assistant-Laufzeitumgebung und die Webanwendung, die vor dem Zusammenführen von Änderungen über ein dokumentiertes lokales Testskript ausgeführt wird. Automatisierte Continuous Integration bei jedem Commit ist im Repository heute nicht konfiguriert; dies wird hier offengelegt, anstatt anders behauptet zu werden. Für das institutionelle Deployment wird ein Release-Prozess mit Evaluationsberichten und Red-Teaming-Ergebnissen je Release in Entwicklung.
Auf dieser Seite werden keine Verfügbarkeitskennzahlen, Service-Level oder Kapazitätszahlen veröffentlicht. Service-Level werden je Deployment vereinbart.