Alle Modelle. Ein Kontrollpunkt.
AI Gateway · AWS eu-central-1
Claude, GPT, Gemini & Co. im Unternehmen nutzen — ohne dass jeder Account zum eigenen Compliance-Fall wird. Das Honeyfield AI Gateway bündelt alle LLM-Zugriffe hinter einem zentralen, auditierbaren Kontrollpunkt in der EU.
Das Problem
Jeder LLM-Anbieter ist ein Lieferant in Ihrem Compliance-Register
Ob ChatGPT-Account im Marketing, Claude-API im Entwicklungsteam oder KI-Feature im SaaS-Tool: Aus Sicht von DSGVO, NIS2 und DORA ist jeder dieser Zugänge ein eigener IKT-Lieferant — mit eigenem Risiko-Assessment, eigenem Vertrag, eigener Überwachungspflicht.
Ohne Gateway — gewachsene KI-Nutzung
Mit Gateway — ein Kontrollpunkt
Drei Regulierungen, ein Grundproblem
DSGVO: Personenbezug ohne Kontrolle
Mitarbeiter kopieren Kundendaten in frei gewählte KI-Tools. Ohne zentralen Zugriffspunkt gibt es weder ein Verarbeitungsverzeichnis, das stimmt, noch einen AVV, der alles abdeckt.
NIS2 Art. 21: Lieferkette nicht nachweisbar
Die Lieferketten-Sicherheit verlangt pro KI-Anbieter Risiko-Assessment, Vertragsklauseln und laufendes Monitoring. Bei zehn Schatten-Tools ist das faktisch nicht leistbar.
DORA Art. 28–30: Register unvollständig
Finanzunternehmen müssen jeden IKT-Dienstleister inkl. Sub-Outsourcing-Kette im Informationsregister führen. Unkontrollierte LLM-Nutzung macht das Register angreifbar.
Die Lösung
Alle Modelle. Ein auditierbarer Weg.
Das Honeyfield AI Gateway sitzt zwischen Ihren Teams und den KI-Anbietern: Authentifizierung, Modell-Routing, Budgets und lückenloses Audit-Logging — betrieben in der EU auf AWS eu-central-1 (Frankfurt).
jede anfrage: authentifiziert → geroutet → geloggt → belegbar
Was das Gateway konkret abdeckt
Kein Häkchen-Marketing: Hier steht, welches Artefakt das Gateway für welche Anforderung liefert — und was in Ihrer Verantwortung bleibt.
Datenschutz (DSGVO)
Ein Vertragspartner statt vieler Einzel-Accounts — mit sauberer Auftragsverarbeitung.
- AVV mit Honeyfield als zentralem Auftragsverarbeiter
- Verarbeitung und Logging in der EU (AWS Frankfurt)
- Konfigurierbare Log-Aufbewahrung & Löschkonzept
- Basis für Ihr Verarbeitungsverzeichnis (Art. 30)
Lieferketten-Sicherheit (NIS2 Art. 21)
Aus n unkontrollierten KI-Lieferanten wird ein dokumentierter — mit Nachweis-Paket.
- Ein Risiko-Assessment statt eines pro Tool
- Vertragsklauseln: Incident-Notification, Audit-Rechte, SLA
- Laufendes Monitoring der Provider-Verfügbarkeit
- Incident-Response-Plan inkl. Modell-Fallbacks
IKT-Drittparteien-Register (DORA Art. 28–30)
Für Finanzunternehmen und deren Dienstleister: registerfertige Dokumentation.
- Registerauszug: Dienst, Funktion, Kritikalität, Datenort
- Sub-Outsourcing-Kette dokumentiert (Provider → Cloud)
- Vertragsinhalte nach Art.-30-Anforderungen vorbereitet
- Exit-Strategie: Modellwechsel ohne Code-Änderung
Die Kontrollschicht im Detail
Multi-Modell-Routing
Claude, GPT, Gemini und Bedrock-Modelle über einen einheitlichen, OpenAI-kompatiblen Endpunkt — Modellwechsel per Konfiguration, nicht per Code-Änderung.
Lückenloses Audit-Log
Wer hat wann mit welchem Modell was verarbeitet: jede Anfrage wird protokolliert und ist für interne Revision und externe Prüfungen exportierbar.
SSO & Team-Verwaltung
Anbindung an Ihr Identity-Management, Rollen und Berechtigungen pro Team — kein API-Key-Wildwuchs in Chat-Verläufen und Config-Dateien.
Kosten & Budgets
Ausgabenlimits pro Team, Projekt oder Anwendung mit Echtzeit-Verbrauch — KI-Kosten werden planbar statt überraschend.
Fallbacks & Verfügbarkeit
Fällt ein Provider aus, routet das Gateway automatisch auf ein definiertes Ausweichmodell — Ihr Incident-Response-Plan für den KI-Lieferantenausfall.
Richtlinien technisch durchsetzen
Erlaubte Modelle, blockierte Datentypen, Prompt-Richtlinien: Ihre KI-Richtlinie wird am Gateway durchgesetzt statt nur im Intranet dokumentiert.
Von einem Team, das reguliert arbeitet
Betrieb & Hintergrund
Häufige Fragen
FAQ