KI absichern: die souveräne, datenschutzkonforme LiteLLM Plattform

Mit LiteLLM können Unternehmen mehrere KI-Modelle über eine zentrale API verwalten, Zugriffe und Budgets steuern und Datenschutz- sowie Compliance-Anforderungen zentral umsetzen. Die dkd zeigt aus eigener Praxiserfahrung, wie ein LiteLLM-Gateway für OpenAI, Anthropic, Mistral und weitere Modelle aufgebaut und sicher betrieben werden kann.

Ein Gateway vor die KI

LiteLLM schafft eine zentrale Schnittstelle, über die Unternehmen verschiedene LLMs und KI-Provider kontrolliert bereitstellen und verwalten können. 
Als bei dkd die ersten anfingen, ernsthaft mit LLMs zu arbeiten, war die Frage schnell da: wer bekommt einen Zugang? Ein Key für OpenAI, einer für Anthropic, pro Person oder pro Team, jeder mit eigener Abrechnung. Und ein Provider-Key, der einmal in einer IDE-Konfiguration oder einem Skript gelandet ist, holt man praktisch nicht mehr zurück.

Das funktioniert vielleicht noch bei drei Leuten, bei über dreißig Entwicklern ist das problematisch. Also haben wir ein Gateway aufgebaut.

Was LiteLLM macht

LiteLLM ist ein Open Source Proxy, der Modelle hinter einer OpenAI-kompatiblen API zusammenfasst. Anwendungen sprechen einen Endpunkt an, das Gateway übersetzt auf die native Schnittstelle des Zielmodells und kümmert sich um Authentifizierung, Routing und Kosten-Erfassung. Wir betreiben es seit 2025 auf eigener Server-Infrastruktur.

Der praktische Effekt ist, dass die Provider-Keys nur noch im Gateway liegen. An unsere Endnutzer werden stattdessen API Keys für LiteLLM ausgegeben, pro Person, Team oder Anwendung, mit eigenem Budget, eigener Modellauswahl und ggf. auch weiteren Einstellungen wie einem Ablaufdatum. Ein Key, der keinen Zugang mehr haben soll, wird im Gateway gelöscht, und das war es. Niemand muss bei einem Provider etwas rotieren.

Kontrolle der gesendeten Daten

Ein Gateway auf eigener Infrastruktur macht eine Anfrage an OpenAI nicht zu einer internen Anfrage. Der Prompt geht weiterhin zum Anbieter, und dessen Auftragsverarbeitung gilt weiterhin.

Was sich ändert, ist alles davor und danach. Authentifizierung, Schlüsselverwaltung und die Protokollierung liegen auf unseren Servern, nicht beim Anbieter. Wir sehen, welche Anwendung was angefragt hat, und können über Guardrails angreifen, bevor etwas gesendet wird, etwa personenbezogene Daten maskieren oder bestimmte Anfragen ganz abweisen.

Und für die Fälle, in denen Inhalte das Haus nicht verlassen dürfen, können am selben Endpunkt ein lokales Modell über Ollama oder vLLM, oder ein Azure-Deployment in einer EU-Region angeschlossen werden. Die Anwendung merkt davon nichts, für sie ist es ein anderer Modellname. Das ist der eigentliche Gewinn: die Entscheidung, wo eine Anfrage verarbeitet wird, ist eine Konfigurationszeile und keine Codeänderung.

Kontrolle der Kosten

Jeder Aufruf wird erfasst, pro Key, Nutzer und Team, und gegen ein Budget gerechnet. Ist das Limit für die gesetzte Periode erreicht, werden weitere Zugriffe blockiert. Dazu kommen Rate Limits um mit Lastspitzen umzugehen und Aliase, mit denen sich Anfragen zum Beispiel auf ein günstigeres Modell umlenken lassen, ohne dass eine Anwendung angefasst wird.

Was wir aus diesen Daten gemacht haben, steht in einem eigenen Beitrag: das dkd-KI-Nutzungs- und Kosten-Dashboard liest diese Zahlen live aus und zeigt den Mitarbeitenden individuell ihren Stand und ihre Nutzung graphisch aufbereitet.

Wenn ein Provider ausfällt

Das passiert, und meist zur Unzeit. Im LiteLLM Gateway lassen sich mehrere Deployments desselben Modells hinterlegen und Fallbacks definieren. Fällt ein Anbieter aus, läuft die Anfrage über den nächsten oder vielleicht sogar ein anderes Modell, und die Anwendung bekommt davon nichts mit.

LiteLLM bei der dkd

Rund sechzig Mitarbeitende nutzen das Gateway im Alltag. Als Chat-Oberfläche betreiben wir Open WebUI, daneben sind Coding-Agenten wie Claude Code, OpenCode und Pi in Nutzung, schließlich Plugins für die Entwicklungsumgebungen. Angebunden sind OpenAI, Anthropic und EU-Provider wie zum Beispiel TensorX oder Mistral.

Wir kennen dadurch auch die unangenehmen Stellen: welche Voreinstellungen man besser ändert, wo Prompt Caching wirklich Geld spart und wo nicht, wie man Tagging so aufsetzt, dass Kosten hinterher einem Projekt zuzuordnen sind. Für den letzten Punkt haben wir eigene Plugins für Coding Agenten gebaut, weil es von Haus aus nicht sauber oder nur kompliziert ging.

Was die dkd für Sie tun kann

Wir richten LiteLLM auf Ihrer Infrastruktur ein, dediziert, in der Cloud oder On-Premises, binden Ihre Provider an und konfigurieren Virtual Keys, Budgets und Guardrails so, dass sie zu Ihren Datenschutzanforderungen passen. Dazu gehört die Anbindung der Werkzeuge, mit denen Ihre Mitarbeitenden tatsächlich arbeiten: Chat-Oberfläche, Coding-Agenten, IDE-Plugins, bestehende Anwendungen.

Im Betrieb übernehmen wir Wartung und Updates, nehmen neue Modelle auf, bauen Guardrails für Ihre Compliance-Anforderungen, richten Monitoring und Alerting ein und schulen Ihre Teams. Wo Standardfunktionen nicht reichen, entwickeln wir die fehlenden Teile, so wie wir es für uns selbst getan haben.

Sie möchten wissen, wie so eine Plattform in Ihrem Unternehmen aussehen könnte?

LiteLLM-Beratung anfragen

Quellen & weiterführende Links

[1] KI-Transformation? Wir sind Ihre KI-Agentur
[2] Der Weg der dkd-KI-Transformation: Über Abenteurer, Stabilisierer, Balancierer
[3] Prompten, bitte!
[4] Starfruit AI