Implementierte Kontrollen, Kontrollen in Entwicklung und die regulatorische Einordnung je Anwendungsfall
Diese Seite beschreibt Kontrollen konkret, anstatt Compliance zu behaupten. Jede Kontrolle ist entweder als heute in der GENIE-Plattform implementiert oder als für das institutionelle Deployment in Entwicklung gekennzeichnet. Das endgültige Kontrolldesign, die regulatorische Einordnung und die Rechenschaftsstruktur werden vom einsetzenden Institut festgelegt.
Ein Mensch entscheidet. OmniGENIE erstellt Entwürfe und Empfehlungen. Jede schreibende oder transaktionale Aktion erfordert vor der Ausführung einen expliziten Freigabeschritt durch einen autorisierten Menschen.
Least Privilege. Der Assistent handelt innerhalb der Berechtigungen des anfragenden Nutzers und, im Zieldesign, innerhalb der je Institut gewährten Tool-Geltungsbereiche.
Von Grund auf überprüfbar. Quellen, Tool-Aufrufe, Freigaben und Ergebnisse werden als Vorgangsartefakte aufgezeichnet. Die interne Argumentation des Modells ist kein Audit-Artefakt.
Fail Closed, wo es darauf ankommt. Administrativer Zugriff ist deaktiviert, sofern keine Allowlist konfiguriert ist; der Freigabetoken-Mechanismus verweigert den Betrieb ohne sein Secret.
Keine regulierte Rolle wird übertragen. Verantwortlichkeiten für Registerführung, Verwahrung, Compliance, Beratung und Kredit verbleiben bei den lizenzierten oder rechenschaftspflichtigen Parteien.
Jede Anfrage ist an ein authentifiziertes Konto gebunden; die Anmeldung nutzt derzeit Google OAuth.
Verfügbar
Kohorten-Zugangskontrolle
Der Zugriff kann per Konfiguration auf eine genehmigte Kohorte beschränkt werden. Dies muss für jeden kontrollierten Piloten explizit konfiguriert werden; ohne Konfiguration ist der Zugriff offen.
Verfügbar
Administrative Allowlist
Die Administrationsoberfläche ist standardmäßig deaktiviert und wird nur für eine explizite, nicht leere Allowlist aktiviert; das Leeren der Liste deaktiviert sie sofort (manueller Notausschalter).
Verfügbar
Enterprise-Identitätsföderation
Anmeldung über den Identitätsanbieter des Instituts (OpenID Connect oder SAML) mit institutionellen Rollen.
In Entwicklung
Mandantentrennung auf Institutsebene
Isolation je Organisation zusätzlich zur kontobezogenen Abgrenzung.
Gedächtnis und Vorgangsdaten sind in jeder Abfrage auf das einzelne Konto abgegrenzt.
Verfügbar
Sensibilitätsstufen
Sensible Fakten erfordern vor dem Abruf eine höhere Relevanzschwelle; Tools tragen Sensibilitätsstufen.
Verfügbar
Verschlüsselte Tokens Dritter
Tokens für verbundene Workspace-Konten sind darauf ausgelegt, im Ruhezustand verschlüsselt gespeichert zu werden.
Verfügbar
Schwärzungstor für eingereichten Text
Ein zweistufiges Tor (Mustererkennung plus ein Modell-Prüfdurchlauf) durchsucht von Nutzern eingereichten Feedback-Text auf personenbezogene Identifikatoren. Es wird nicht auf jeden Gesprächsbeitrag angewendet.
Implementiert, nicht aktiviert
Pipeline-weite Data-Loss-Prevention
Erkennung und Behandlung personenbezogener Daten vor der Modellinferenz über alle Gesprächsbeiträge hinweg.
Eine dreistufige Kennzeichnung von Tools steuert den Aufruf.
Verfügbar
Abgestufte Routing-Ergebnisse
Eine Anfrage wird zu einem von: zulassen, mit Zusammenfassung zulassen, Freigabe erforderlich, blockieren, an einen Menschen eskalieren, geleitet.
Implementiert, nicht aktiviert
Einmal-Freigabetoken
Kurzlebiges Einmal-Token, gebunden an den Hash der exakten Payload; verweigert den Betrieb ohne sein Secret. Heute nur für bestimmte Änderungsabläufe genutzt.
Implementiert, nicht aktiviert
Deterministischer Vorfilter für Selbstmodell-Änderungen
Vorgeschlagene Änderungen am eigenen dauerhaften Profil des Assistenten durchlaufen vor einer menschlichen Prüfung einen regelbasierten Filter ohne jeden Modellaufruf; einige Kategorien können nie automatisch freigegeben werden.
Implementiert, nicht aktiviert
Aktionsstufen für Finanzoperationen
Beobachten, Entwerfen, Empfehlen, Ausführen mit Freigabe; automatische Ausführung für Finanzmarktaktionen deaktiviert.
In Entwicklung
Freigabe über OmniPersona
Menschliche Freigabe vorbereiteter Aktionen über den bestehenden Proof-of-Action-Ablauf.
Text Dritter und Antworten anderer Agenten werden an bestimmten Grenzen als Daten gerahmt, mit expliziten Anweisungen, eingebettete Autoritätsansprüche zu ignorieren.
Implementiert, nicht aktiviert
Sprach-Anbieter-Fallback
Automatischer Fallback zu einem sekundären Text-to-Speech-Anbieter.
Verfügbar
Feature-Schalter
Fähigkeiten sind einzeln per Konfiguration umschaltbar, was als manueller Notausschalter je Funktion dient.
Verfügbar
Automatischer Circuit Breaker
Automatischer Wechsel in den Nur-Lese-Modus bei anomalen Fehlerraten oder Tool-Aufrufmustern.
In Entwicklung
Sprachmodell-Anbieter-Fallback
Automatisches Failover zwischen Modellanbietern.
In Entwicklung
Evaluations- und Red-Teaming-Programm
Wiederkehrende Tests auf Prompt-Injection und Tool-Missbrauch mit dokumentierten Ergebnissen je Release.
Dieser Abschnitt ist eine Orientierung auf Dokumentationsebene, keine Rechtsberatung. Einordnung und Kontrolldesign hängen vom Verwendungszweck, den Daten, der Entscheidungswirkung, der Rolle des Betreibers und der Governance des einsetzenden Instituts ab.
EU-KI-Verordnung (AI Act). OmniGENIE wird als Gesamtprodukt keiner einzelnen Risikokategorie zugeordnet. Die Einordnung wird je Anwendungsfall und Verwendungszweck bewertet. Sprach- und Textschnittstellen sind darauf ausgelegt, die Transparenzpflicht zu unterstützen, wonach natürliche Personen darüber informiert werden, dass sie mit einem KI-System interagieren; die endgültige Compliance hängt von der Konfiguration und Offenlegungspraxis des Instituts ab. Ob ein Unterstützungs-Anwendungsfall unter eine Ausnahme für vorbereitende Tätigkeiten fällt, wird von der Rechts- und Compliance-Funktion des Instituts fallweise bewertet.
DORA. OmniGENIE stellt Protokolle, Rollen- und Berechtigungskontrollen sowie Monitoring-Hooks bereit, die Institute zur Unterstützung ihrer eigenen IKT-Risikomanagement- und Drittparteirisiko-Pflichten nutzen können. Ob OmniGENIE für ein gegebenes Institut ein kritischer oder wichtiger IKT-Dienst ist, wird durch die eigene Bewertung und das Register dieses Instituts bestimmt. OmniGENIE bescheinigt keine DORA-Konformität.
Auslagerung (MaRisk). Abhängig vom Hosting-Modell und dem Auslagerungsregister des Instituts kann die Nutzung extern gehosteter Inferenz für Auslagerungsbewertungen relevant sein; diese Feststellung trifft das Institut.
DSGVO. Personenbezogene Daten im Vorgangsgedächtnis werden nur für den definierten Vorgangszweck verarbeitet. Löschung wird unterstützt, vorbehaltlich gesetzlicher Aufbewahrungspflichten, die gegebenenfalls Vorrang haben; eine Legal-Hold-Überschreibung ist in Entwicklung und heute nicht implementiert.
Aufzeichnungspflichten. Wertpapierrechtliche Pflichten zur Anrufaufzeichnung verbleiben in der Verantwortung des einsetzenden Instituts und werden mit dessen eigener Aufzeichnungsinfrastruktur erfüllt.
Lizenzpflichtige Tätigkeiten. OmniGENIE führt keine Registrierung von Kryptowertpapieren oder Kryptoverwahrung durch. Diese Tätigkeiten werden ausschließlich von lizenzierten Partnern von ecrop durchgeführt.
