Langfuse self-hosted: LLM-Observability und KI-Logging für den EU AI Act

Langfuse für nachvollziehbare KI-Anwendungen nutzen, ohne es selbst zu betreiben?

Wir übernehmen Hosting und Betrieb für Langfuse in Deutschland, ab 99,90 € netto je Workload und Monat. Soll zusätzlich laufend jemand Qualität, Kosten und Retrieval Ihrer KI-Anwendung auswerten, gibt es Managed LLMOps ab 1.990 € netto im Monat.

Langfuse betreiben lassen · Kostenlosen Termin vereinbaren

Wer KI in produktive Geschäftsprozesse bringt, steht schnell vor einer unbequemen Frage: Was passiert da eigentlich genau? Welcher Prompt ging an welches Modell, warum kam diese Antwort zustande, was hat der Aufruf gekostet und an welcher Stelle einer mehrstufigen Agenten-Kette ist etwas schiefgelaufen? Ohne Observability ist eine LLM-Anwendung eine Blackbox. Und eine Blackbox lässt sich weder zuverlässig verbessern noch sauber dokumentieren.

Genau diese Lücke schließt Langfuse: die derzeit verbreitetste quelloffene Plattform für LLM-Observability. Sie erfasst jeden Modell-Aufruf als nachvollziehbaren Trace, ermöglicht systematische Qualitätsauswertungen und lässt sich vollständig self-hosted betreiben. Das macht sie zu einem zentralen Baustein für Unternehmen, die KI nicht nur ausprobieren, sondern verantwortungsvoll und nachvollziehbar betreiben wollen - gerade mit Blick auf den EU AI Act.

Dieser Beitrag ordnet ein, was LLM-Observability leistet, was der EU AI Act beim Thema Logging wirklich fordert (und was nicht), und warum Langfuse self-hosted für souveränitätsbewusste Unternehmen die naheliegende Wahl ist.

Inhaltsverzeichnis

• Was LLM-Observability ist und warum KI-Logging anders funktioniert
• Was der EU AI Act wirklich verlangt
• Der neue Zeitplan: Digital Omnibus in Kraft
• Langfuse im Überblick
• Self-Hosting: Architektur und Betrieb
• Langfuse vs. LangSmith, Helicone und Phoenix
• Observability als Hebel für Compliance und Kosten
• Sicherheit und Updates nicht vergessen
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Quellen

Was LLM-Observability ist und warum KI-Logging anders funktioniert

Klassisches Application-Monitoring fragt: Läuft der Dienst, wie ist die Latenz, wie viele Fehler gibt es? Bei KI-Anwendungen reicht das nicht. Eine LLM-Antwort kann technisch erfolgreich (HTTP 200) und inhaltlich trotzdem falsch, irreführend oder teuer sein. Der eigentliche Wert steckt im Inhalt des Aufrufs, nicht nur in seinem Statuscode.

LLM-Observability erfasst deshalb die fachliche Ebene jedes Aufrufs als Trace:

• Welcher Prompt wurde gesendet, mit welchem System-Prompt und welchem Kontext?
• Welches Modell und welche Version haben geantwortet?
• Wie viele Tokens wurden verbraucht und was kostete der Aufruf?
• Wie lange dauerte die Verarbeitung?
• Bei mehrstufigen Ketten und Agenten: welcher Schritt hat was getan, und wo ist es gekippt?

Aus diesen Traces lassen sich Auswertungen (Evals) bauen, etwa um die Antwortqualität über die Zeit zu messen, Regressionen nach einem Modellwechsel zu erkennen oder Kosten pro Team und Feature zuzuordnen. Damit wird aus dem diffusen Gefühl "die KI ist irgendwie schlechter geworden" eine belegbare Aussage. Genau diese Nachvollziehbarkeit ist nicht nur ein Qualitätsthema, sondern zunehmend auch ein regulatorisches.

Was der EU AI Act wirklich verlangt

Hier ist Präzision wichtig, denn beim Thema KI-Logging kursieren viele verkürzte Aussagen. Die Verordnung (EU) 2024/1689, der EU AI Act, verlangt für Hochrisiko-KI-Systeme nach Anhang III konkrete Pflichten zur Nachvollziehbarkeit:

• Artikel 12 verpflichtet zur automatischen Aufzeichnung von Ereignissen (Logs) über den gesamten Lebenszyklus des Systems. Ziel ist die Rückverfolgbarkeit in einem dem Verwendungszweck angemessenen Umfang (Art. 12).
• Artikel 13 verlangt, dass der Betrieb hinreichend transparent ist, damit Betreiber die Ergebnisse interpretieren und korrekt nutzen können (Art. 13).
• Artikel 19 schreibt vor, dass Anbieter die automatisch erzeugten Logs aufbewahren, und zwar für einen dem Zweck angemessenen Zeitraum von mindestens sechs Monaten, sofern kein anderes Recht etwas anderes vorsieht (Art. 19).

Die Bußgelder sind erheblich: bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes für verbotene Praktiken, bis zu 15 Millionen Euro oder 3 Prozent für Verstöße gegen die übrigen Pflichten, zu denen auch die Hochrisiko-Anforderungen zählen (Art. 99).

Wichtig ist eine ehrliche Einordnung: Diese Pflichten betreffen das Hochrisiko-System des Anbieters, nicht automatisch jede einzelne Interaktion mit einem Sprachmodell. Ein LLM ist nicht per se Hochrisiko. Erst wenn es in einem Anwendungsfall nach Anhang III eingesetzt wird, etwa in der Personalauswahl oder Kreditwürdigkeitsprüfung, greifen die Logging-Pflichten. LLM-Observability ist damit ein praktisches Werkzeug, um Artikel 12 und 19 umzusetzen, aber kein Gesetz, das ein bestimmtes Trace-Format pro API-Aufruf vorschreibt. Wer das sauber kommuniziert, bleibt glaubwürdig.

Der neue Zeitplan: Digital Omnibus in Kraft

Der EU AI Act sah ursprünglich vor, dass die Hochrisiko-Anforderungen für Anhang-III-Systeme ab dem 2. August 2026 anwendbar werden. Dieser Stichtag ist inzwischen verschoben.

Die EU-Kommission hatte im November 2025 den sogenannten Digital Omnibus vorgelegt, ein Vereinfachungspaket mit einer Verschiebung der Hochrisiko-Fristen. Nach der politischen Einigung von Rat und Parlament am 7. Mai 2026 (Rat der EU, 07.05.2026) ist der Omnibus als Verordnung (EU) 2026/1744 im Amtsblatt veröffentlicht worden und am 27. Juli 2026 in Kraft getreten (Verordnung (EU) 2026/1744). Die Hochrisiko-Pflichten gelten damit:

• für Anhang-III-Systeme (etwa Personalauswahl, Kreditwürdigkeitsprüfung) ab dem 2. Dezember 2027,
• für in Produkte eingebettete Hochrisiko-KI nach Anhang I ab dem 2. August 2028.

Was bereits gilt: Die Pflichten für General-Purpose-KI-Modelle sind seit dem 2. August 2025 in Kraft, und die Durchsetzungsbefugnisse der Kommission greifen seit dem 2. August 2026.

Für Unternehmen heißt das nicht "abwarten", sondern das Gegenteil: Der Stichtag hat sich verschoben, die Pflichten selbst verschwinden nicht. Wer die Nachvollziehbarkeit seiner KI-Systeme jetzt technisch aufbaut, ist unabhängig vom finalen Datum vorbereitet. Eine ausführliche Einordnung der Hochrisiko-Pflichten liefert unser Beitrag zum EU AI Act ab August 2026.

Langfuse im Überblick

Langfuse ist eine Plattform für Observability, Tracing und Evaluierung von LLM-Anwendungen. Sie integriert sich in gängige Frameworks und LLM-Gateways und sammelt jeden Aufruf als strukturierten Trace. Der Funktionsumfang umfasst Tracing, Prompt-Management, Datasets, ein Playground und systematische Evaluierungen.

Der entscheidende Punkt für Unternehmen ist das Lizenzmodell. Der Kern von Langfuse steht unter MIT-Lizenz und lässt sich ohne Nutzungslimits self-hosten. Tracing, Evals, Prompt-Management, Playground und Datasets sind frei nutzbar, ebenso Basis-Single-Sign-On über SAML oder OIDC (Langfuse-Lizenz). Kommerziell lizenziert sind laut Self-Hosting-Preisübersicht (Stand Oktober 2026) SCIM-User-Provisioning, projektbezogene RBAC-Rollen, Audit-Logs, Data-Retention-Policies und serverseitiges Data-Masking. Wer also die Plattform betreiben und Traces auswerten will, braucht keine kommerzielle Lizenz.

Eine Nachricht hat im Markt für Aufmerksamkeit gesorgt: ClickHouse hat Langfuse am 16. Januar 2026 übernommen, im Rahmen einer Series-D-Finanzierung (Langfuse-Blog). Laut offizieller Mitteilung ändert sich an Lizenz, Preismodell und Self-Hosting-Option nichts. Das ist plausibel, weil ClickHouse ohnehin die analytische Datenbank ist, auf der Langfuse seine Trace-Auswertung aufbaut. Für Self-Hoster hat sich durch die Übernahme bis Oktober 2026 nichts geändert, der MIT-Kern bleibt.

Ein Detail für souveränitätsbewusste Unternehmen: Die gehostete Langfuse-Cloud bietet zwar eine EU-Region, diese liegt jedoch in Irland (AWS eu-west-1), nicht in Deutschland. Wer volle Datenhoheit will, kommt am Self-Hosting nicht vorbei - was ohnehin der Kern unserer Empfehlung ist.

Self-Hosting: Architektur und Betrieb

Langfuse self-hosted ist kein Ein-Container-Projekt. Auch die aktuelle Version 4 besteht aus mehreren Diensten (Self-Hosting-Doku):

Diese Architektur ist leistungsfähig, aber sie will sauber betrieben werden. ClickHouse ist der Haupt-Kostentreiber und braucht durchdachtes Storage- und Backup-Design. Zur Versionsplanung (Stand Oktober 2026): Version 4 ist seit dem 29. Juli 2026 self-hostbar und bringt unter anderem Volltextsuche, Monitore mit Alerts sowie die schnelleren Observations- und Metrics-APIs v2 mit (Release v4.0.0). Aktuell ist v4.56.0. Version 3 erhält Sicherheitspatches nur noch bis Ende Januar 2027, der Umstieg gehört also in die Planung.

Der offizielle Upgrade-Pfad hat drei Schritte (Upgrade-Guide v3 auf v4):

1. Infrastruktur anheben: mindestens ClickHouse 25.12 (empfohlen 26.4), PostgreSQL 15 (empfohlen 16) und Redis 7.0 (empfohlen 7.2).
2. Langfuse v4 im Modus legacy oder dual ausrollen, der das v3-Verhalten beibehält.
3. Auf das neue Datenmodell umstellen (SDKs, APIs, Evaluatoren, Exporte) und erst dann in den Modus events_only wechseln.

Der dritte Schritt ist der eigentliche Bruch: Im Modus events_only werden alte SDKs (Python bis v2, JS/TS bis v3) bei der Annahme abgelehnt, die Legacy-Ingestion- und Lese-APIs entfallen, und Trace-basierte LLM-as-a-Judge-Evaluatoren laufen nicht mehr. Wer Langfuse aus mehreren Anwendungen und einem Gateway beliefert, sollte die SDK-Stände vorher inventarisieren.

Genau an dieser Stelle entscheidet sich, ob Self-Hosting Entlastung oder Dauerbaustelle wird. Vier Datendienste, Backups, Updates und Monitoring sind kein Nebenbei-Projekt für einen halben Admin. Wir betreiben solche Stacks im Rahmen unserer Managed-KI-Services und auf LLM-Hosting-Infrastruktur in deutschen Rechenzentren.

Langfuse vs. LangSmith, Helicone und Phoenix

LLM-Observability ist ein junger, aber umkämpfter Markt. Die wichtigste Unterscheidung für Unternehmen mit Souveränitätsanspruch ist nicht der Funktionsumfang, sondern die Lizenz und die Self-Hosting-Fähigkeit.

Zwei Punkte sind hier entscheidend. LangSmith von LangChain ist proprietär; Self-Hosting gibt es nur im Enterprise-Plan. Das LangChain-Framework selbst ist quelloffen, aber das ist nicht zu verwechseln mit der Observability-Plattform LangSmith. Und Arize Phoenix steht unter der Elastic License v2, die zwar einsehbar ist, aber keine OSI-anerkannte Open-Source-Lizenz darstellt und das Anbieten als gehosteter Dienst einschränkt. Wer echte Lizenzfreiheit und vollständige Datenkontrolle will, landet bei Langfuse (MIT) oder Helicone (Apache 2.0).

Observability als Hebel für Compliance und Kosten

Der EU-AI-Act-Aspekt ist nur eine Seite. In der Praxis zahlt sich Observability doppelt aus.

Kostenkontrolle. Sobald mehrere Teams gegen mehrere Modelle arbeiten, wird die monatliche Token-Rechnung schnell unübersichtlich. In Kombination mit einem LLM-Gateway wie LiteLLM lassen sich Kosten pro Team, pro Feature und pro Modell genau zuordnen. Das ist die Grundlage für Budgets, Rate-Limiting und fundierte Modellentscheidungen, etwa wann ein kleineres lokales Modell ein teures Cloud-Modell ersetzen kann.

Qualität und Nachweis. Evals machen die Antwortqualität messbar, statt sie zu erahnen. Und die Traces selbst sind die Datenbasis, die eine Nachvollziehbarkeit nach Artikel 12 überhaupt erst praktisch umsetzbar macht. Wer ohnehin eine DSGVO-konforme KI-Beratung anstrebt, baut mit Tracing und Logging die technische Grundlage dafür.

Besonders stark wird der Ansatz im Zusammenspiel: lokales Modell über Ollama oder vLLM, davor ein LiteLLM-Gateway, daneben Langfuse für Observability. Wenn dazu eine RAG-Wissensdatenbank kommt, entsteht ein vollständig souveräner KI-Stack auf eigener Infrastruktur, bei dem keine Daten das Haus verlassen.

Sicherheit und Updates nicht vergessen

Self-Hosting heißt auch Verantwortung. Langfuse ist davon nicht ausgenommen: Im Frühjahr 2026 wurde die Schwachstelle CVE-2026-41487 (GHSA-2524-j966-gfgh) bekannt, bei der ein Nutzer mit eingeschränkter Mitglieds-Rolle unter bestimmten Bedingungen einen gespeicherten LLM-Provider-API-Key auslesen konnte. Die Lücke wurde als niedrige Schwere eingestuft und ist in der 3.x-Linie ab 3.167.0 behoben.

Das ist kein Argument gegen Langfuse, sondern für diszipliniertes Update-Management. Genau hier liegt der Unterschied zwischen "schnell aufgesetzt" und "sauber betrieben". Wer eine LLM-Plattform produktiv führt, braucht ein laufendes CVE-Monitoring und einen klaren Patch-Prozess. Dasselbe Muster zeigt sich quer durch den Self-Hosted-KI-Stack, wie etwa die Ollama-Schwachstelle Bleeding Llama gezeigt hat.

Unser Vorgehen bei WZ-IT

Wir behandeln Observability nicht als Add-on, sondern als festen Teil eines verantwortungsvollen KI-Betriebs.

1. Architektur statt Bauchgefühl. Wir klären zuerst, ob ein Anwendungsfall überhaupt unter die Hochrisiko-Logik des EU AI Act fällt und welche Nachvollziehbarkeit fachlich und rechtlich nötig ist. Daraus leitet sich ab, wie viel Observability sinnvoll ist.

2. Souveräner Stack. Langfuse für Observability, ein LiteLLM-Gateway für Kostenkontrolle und Modell-Routing, lokale Modelle als Backend. Alles self-hosted auf Infrastruktur in deutschen Rechenzentren, ohne Datenabfluss an Dritte.

3. Sauberer Betrieb. Backups für PostgreSQL und ClickHouse, Monitoring, Update- und Patch-Management inklusive CVE-Tracking. Genau die Punkte, an denen self-gehostete Plattformen sonst zur Dauerbaustelle werden.

4. Compliance-fähig dokumentiert. Logging und Aufbewahrung so aufgesetzt, dass sie eine Nachvollziehbarkeit nach Artikel 12 und eine Aufbewahrung nach Artikel 19 technisch stützen, abgestimmt mit eurer Datenschutz- und Rechtsberatung.

Ob als reine LLM-Hosting-Infrastruktur oder als komplett betreuter Managed-KI-Betrieb: Der Stack steht auf europäischer Infrastruktur, der Betrieb bleibt in europäischer Hand.

Weiterführende Guides

• EU AI Act ab August 2026: Was Unternehmen mit Hochrisiko-KI tun müssen - der regulatorische Rahmen im Detail
• CVE-Monitoring für self-hosted Software - warum Patch-Management Pflicht ist
• Bleeding Llama: Ollama-Schwachstelle CVE-2026-7482 absichern - dasselbe Muster im KI-Stack
• Ollama vs. vLLM: Vergleich für Self-Hosted LLMs - die Modell-Ebene hinter dem Gateway
• Langfuse-Expertise bei WZ-IT - Beratung, Setup und Betrieb
• LLM-Hosting bei WZ-IT - souveräne KI-Infrastruktur

KI in Produktion, aber niemand schaut hin? Wir bauen euren souveränen LLM-Stack mit Observability, Gateway und lokalen Modellen - self-hosted, DSGVO-konform und sauber betrieben. Erstgespräch vereinbaren

Stand Oktober 2026. Der EU AI Act ist eine sich entwickelnde Regulierung, die im Beitrag genannten Fristen entsprechen der Verordnung (EU) 2026/1744. Dieser Beitrag ist kein Rechtsrat. Bei konkreten Compliance-Fragen Datenschutz- und Rechtsberatung hinzuziehen.

Quellen

• EU AI Act, Artikel 12 - Aufzeichnungspflichten (Logs)
• EU AI Act, Artikel 13 - Transparenz und Informationsbereitstellung
• EU AI Act, Artikel 19 - Aufbewahrung der automatisch erzeugten Logs
• EU AI Act, Artikel 99 - Sanktionen
• Rat der EU: Einigung zur Vereinfachung der KI-Regeln (07.05.2026)
• EU-Kommission: Digital Omnibus on AI
• Verordnung (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
• Langfuse: Open Source und Lizenzmodell
• Langfuse: Self-Hosting-Preisübersicht (OSS vs. Enterprise)
• Langfuse: Self-Hosting-Architektur
• Langfuse: Release v4.0.0
• Langfuse: Upgrade-Guide v3 auf v4
• Langfuse: Joining ClickHouse (16.01.2026)
• GitHub Security Advisory GHSA-2524-j966-gfgh (CVE-2026-41487)