Der API-Key eines einzelnen Teams, geteilt über drei Services und in ein Notebook kopiert, ist der typische Ausgangspunkt für die meisten Modellkosten und die meiste Compliance-Exposition. Ein LLM-Gateway ist ein Proxy, den jede Anwendung anstelle des Providers direkt aufruft. Es verwaltet die Credentials, hängt jedem Request eine Identität an, erzwingt Kontingente und Policy und schreibt einen Audit-Trail. So bekommen Sie einen einzigen Ort, an dem Sie sehen und steuern, was das Haus verlässt.
Warum das im Finanzsektor mehr wiegt als in einem gewöhnlichen Softwarehaus: Was das Haus verlässt, sind oft Kundendaten, die zu einem Dritten gehen, und was zurückkommt, kann in einem Dokument landen, das ein Genehmiger unterschreibt. Beide Richtungen brauchen einen Nachweis. Ohne Gateway haben Sie weder den Nachweis noch die Kontrolle – und Sie erfahren die Form Ihrer Exposition erst, wenn die Finanzabteilung fragt, warum sich die Modellrechnung zum Quartalsende verdreifacht hat, oder wenn ein Prüfer wissen will, welche Requests Kontonummern enthielten.
Was zwischen Ihren Apps und den Providern sitzt
Das Gateway ist ein Reverse-Proxy, der auf der ausgehenden Seite die Provider-APIs spricht und auf der eingehenden Seite eine normalisierte API. Anwendungen authentifizieren sich dagegen mit ihren eigenen, kurzlebigen Credentials. Sie sehen die Provider-Keys nie. Die liegen in einem Secrets-Manager und rotieren nach einem Zeitplan, den die Anwendungen nicht kennen müssen.
Konkret trifft ein Request ein, und bevor er irgendwohin geht, durchläuft das Gateway eine feste Abfolge:
- Den Aufrufer zu einer Anwendungsidentität und einem Team auflösen, damit Kosten- und Zugriffsentscheidungen ein Subjekt haben.
- Den Request gegen die Policy prüfen: Darf diese App dieses Modell aufrufen, mit dieser Datenklasse, für diesen deklarierten Zweck?
- Kontingente und Rate-Limits auf Identitätsebene anwenden und bei erschöpftem Budget ablehnen oder in eine Queue stellen, statt den Aufruf durchzulassen.
- Den Request auf denjenigen Provider und das Modell umschreiben, das die Routing-Regeln auswählen, und die echte Credential injizieren.
- Die Response zurückstreamen und dabei den vollständigen Austausch sowie die vom Provider gelieferten Token-Zahlen protokollieren.
Provider-Abstraktion fällt bei diesem Design fast von selbst ab – und ist der am wenigsten interessante Vorteil. Niemand wechselt aus einer Laune heraus den Anbieter. Was die normalisierte API Ihnen bringt, ist ein einziger Ort, an dem Sie reagieren, wenn ein Provider ein Modell abkündigt, es über Nacht neu bepreist oder mitten in Ihrem geschäftigsten Abstimmungsfenster ausfällt. Sie ändern eine Routing-Regel, statt jeden Service zu editieren und neu auszurollen. Failover von einem Primärmodell auf ein Fallback wird zu einer Konfigurationsänderung mit einem klaren Audit-Datensatz darüber, wann sie erfolgte und warum.
Kostenkontrollen, die greifen, bevor die Rechnung kommt
Modellkosten sind ungewöhnlich, weil eine einzige falsch konfigurierte Schleife über Nacht eine fünfstellige Rechnung erzeugen kann – und nichts sie stoppt, bis die Kreditkarte es tut. Das Gateway ist der Ort, an den Sie die Bremse setzen, denn es ist die einzige Komponente, die jeden Aufruf sieht und jeden davon zuordnen kann.
Die Gesamtkosten sind die falsche Kennzahl. Was Sie messen, sind Kosten pro Identität pro Zeiteinheit. Das Gateway zählt Tokens so, wie sie abgerechnet werden, taggt jeden Aufruf mit Anwendung, Team und Zweck und erzwingt Budgets auf dieser Granularität. Ein Batch-Job zur Entitätsauflösung, der normalerweise zehntausend Datensätze verarbeitet, bekommt eine Obergrenze; wenn eine fehlerhafte Query ihn auf zehn Millionen aufbläht, erreicht der Job sein Budget und stoppt, statt zu laufen, bis es jemandem auffällt.
- Harte Kontingente pro Identität, damit ein Team nicht den Spielraum eines anderen Teams verbraucht.
- Weiche Alerts vor dem harten Limit, geroutet an das verantwortliche Team, nicht an einen generischen Ops-Kanal, den niemand liest.
- Zuordnung pro Zweck, damit die Finanzabteilung sieht, dass Dokumentenerstellung das eine gekostet hat und Transaktionsüberwachung das andere, und die interne Verrechnung entsprechend bepreisen kann.
- Modell-Tier-Policy, damit eine Zusammenfassungs-Aufgabe nicht stillschweigend auf das teuerste Modell zeigt, weil ein Entwickler ein Snippet kopiert hat.
Die Zuordnung ist das, was Kosten von einer monatlichen Überraschung in eine Position verwandelt, für die jemand verantwortlich ist. Sie speist außerdem die Kapazitätsplanung, weil Sie jetzt echten Bedarf pro Workload haben statt einer einzigen undurchsichtigen Provider-Rechnung.
Der Audit-Trail und die Policy-Schicht
Für einen regulierten Nutzer ist das Logging überhaupt der Grund, weshalb das Gateway existiert. Jeder Request und jede Response wird protokolliert – mit der Identität, dem deklarierten Zweck, dem Modell, den Token-Zahlen und einer Klassifizierung der Daten, die ausgegangen sind. Die Aufbewahrung greift schon beim Schreiben gemäß der Datenklasse, sodass ein Request mit personenbezogenen Daten der Regel für diese Klasse unterliegt und nicht irgendeinem Default, den der Log-Speicher zufällig mitbringt.
Genau das macht die Drittparteien-Frage beantwortbar. Kundendaten an ein externes Modell zu schicken ist eine Auftragsverarbeiter-Beziehung, und unter DORA ist der Provider ein IKT-Drittdienstleister, den Sie überwachen und aus dem Sie aussteigen können müssen. Das Gateway gibt Ihnen die Überwachungsfläche: was zu wem ging, wann, und ob es das durfte. Wenn Sie einen Provider abschneiden müssen, tun Sie das am Gateway, und die Aufrufe stoppen überall auf einmal.
Die Policy sitzt am selben Engpass. Weil jeder Aufruf hindurchläuft, können Sie Regeln erzwingen, die man keiner einzelnen Anwendung zutrauen darf, für sich selbst durchzusetzen:
- Requests blockieren oder redigieren, deren Datenklassifizierung übersteigt, was ein gegebener Provider vertraglich empfangen darf.
- Modelle oder Regionen ablehnen, die eine Residency-Anforderung verletzen, bevor der Request Ihr Netzwerk verlässt.
- Ein Purpose-Tag auf jedem Aufruf verlangen und ungetaggten Traffic ablehnen, damit niemand Daten an ein Modell schicken kann, ohne zu sagen, warum.
- Auf jedem geloggten Aufruf eine Policy-Version festhalten, damit ein Prüfer sehen kann, welche Regeln in Kraft waren, als eine Entscheidung getroffen wurde.
Nichts davon nimmt Ihnen die Notwendigkeit sorgfältigen Anwendungsdesigns ab. Ein Gateway weiß nicht, ob der Output eines Modells eine falsche Zahl enthält. Was es Ihnen gibt, ist der eine Ort, an dem Zugriff, Kosten und Nachweis gemeinsam kontrolliert werden – sodass die Antwort, wenn jemand fragt, was Ihre Systeme an welches Modell geschickt haben und was es gekostet hat, eine Abfrage gegen Ihre eigenen Datensätze ist statt einer Anfrage an den Support-Desk eines Anbieters.
Häufige Fragen
Brauchen wir ein Gateway, wenn wir heute nur einen Provider nutzen?
Ja, denn der Großteil des Nutzens liegt in Zugriffskontrolle, Logging und Kontingenten – nicht im Provider-Wechsel. Gerade im Single-Provider-Fall richtet ein geleakter Key oder ein unbegrenzter Batch-Job den größten Schaden an, weil niemand die direkten SDK-Aufrufe im Blick hat.
Bringt ein Gateway Latenz mit, die Streaming-Anwendungen ausbremst?
Ein schlanker Proxy fügt wenige Millisekunden hinzu und streamt Tokens direkt durch. Die Kosten-Checks und Policy-Lookups laufen vor dem ersten Token und nach dem letzten, die interaktive Latenz bleibt also unverändert. Halten Sie synchrones Scanning aus dem Token-Pfad heraus.
Wie hilft das Gateway zum Zeitpunkt eines Audits?
Jeder Aufruf trägt eine Anwendungsidentität, ein Purpose-Tag sowie einen vollständigen Request- und Response-Datensatz mit Aufbewahrungsregeln, die schon beim Schreiben greifen. Wenn ein Prüfer fragt, wer an einem bestimmten Datum welche Kundendaten an welches Modell geschickt hat, ist das eine Abfrage – und keine forensische Suche quer durch die Anwendungslogs.