Enterprise-KI-Governance: die vier Fragen eines CIO
Jede Managementprüfung von KI-Ausgaben mündet in vier Fragen. Jede Antwort hier verweist auf einen ausgelieferten, überprüfbaren Mechanismus – nicht auf eine Roadmap.
Modellzugriff zu gewähren ist einfach, ihn zu steuern nicht. Die vier Fragen unten entscheiden, ob ein KI-Programm sein erstes Audit übersteht.
Wer nutzt welches Modell und wie viel?
Jede Anfrage trägt einen Schlüssel, eine Schlüsselgruppe und ein Modell. GateLLM zeichnet Input-, Output- und Cache-Treffer-Token je Anfrage in Minutenauflösung auf und liefert Tages- und Monatsreihen je Schlüssel, Gruppe und Modell. Welche Clients überhaupt verbinden dürfen, entscheidet die Zulassung anhand des Anfrage-Headers.
- •Nutzung und Kosten lassen sich nach Person, Schlüssel, Schlüsselgruppe und Modell aufteilen.
- •Client-Zulassung steuert per User-Agent über globale, Gruppen- und Schlüsselbereiche.
- •Anfragebezogene Datensätze erlauben die Ende-zu-Ende-Verfolgung eines Aufrufs.
Was kostet es und wer zahlt?
Ausgaben werden gegen eine Rate Card gemessen, die Ihnen gehört, nicht gegen Listenpreise. Fixieren Sie ausgehandelte Preise, taggen Sie Aufrufe für die Umlage, exportieren Sie Berichte je Zeitfenster und setzen Sie Tages- oder Monatsquoten, die Anfragen bei erschöpftem Budget ablehnen. GateLLM erhebt keinen Token-Aufschlag auf Anbieterpreise.
- •Zeitfenster-Snapshots der Rate Card halten alte Berichte reproduzierbar.
- •Tag-basierte Umlage macht KI-Ausgaben zu einem zuordenbaren Ledger.
- •Tages- und Monatsquoten liefern 429 bei Erreichen der Grenze – ein außer Kontrolle geratener Agent stoppt bei Ihrer Zahl.
Sind Daten aus dem Netz gegangen, und können wir das belegen?
Sie betreiben das Gateway, daher läuft Prompt- und Antwortverkehr nie über uns. Unter BYOK liegen Anbieterschlüssel nur im Gateway-Speicher. Anmeldedaten und PII werden im Anfragepfad erkannt und können je Bereich protokolliert, maskiert oder blockiert werden; gespeicherte Log-Inhalte sind an jedem Ausgangspunkt maskiert.
- •Anfragen gehen nur an die konfigurierten Modellendpunkte – auch selbst gehostete vLLM- oder Ollama-Upstreams.
- •Anfrage-Logs sind standardmäßig aus; Rohinhalte sehen nur Admins, auditiert.
- •SSO über OIDC oder SAML plus SCIM-Bereitstellung; Schlüssel und Quotas je Mandant.
Wenn ein Anbieter ausfällt oder wir Modelle wechseln – wie viel Code ändert sich?
Bei 5xx oder Timeout wird ohne Änderung am Anwendungscode ein anderer Anbieter versucht. Vier Chat-Protokollfamilien übersetzen in beide Richtungen, sodass ein Client sein SDK behält. Modellidentität wird im Gateway zugeordnet – per Zugriffsschlüssel, per Header oder über eine Catch-all-Regel – und Fähigkeitsmetadaten kommen aus einer Registry.
- •Anbieterübergreifender Fallback bei 5xx oder Timeout, ohne Client-Änderung.
- •Ingress-Allowlists und Catch-all-Zuordnungen halten einen Modellnamen stabil, während das Backend wechselt.
- •Fähigkeitsmetadaten kommen aus einer Registry – Modell-Drift braucht kein Release.