Pexon Consulting | 9 Min. Lesezeit | 27.04.2026
TL;DR
LLM Observability umfasst Tracing, Evaluation und Guardrails für produktive KI-Anwendungen und ist mit dem EU AI Act ab Dezember 2027 Pflicht für Hochrisiko-Systeme nach Anhang III. Pexon Consulting implementiert Langfuse als Microsoft Partner mit 80 Mitarbeitern aus Deutschland DSGVO-konform self-hosted. Unternehmen sparen 40-60 Prozent Modellkosten und erhalten vollständige Auditierbarkeit für Compliance-Anforderungen.
Warum Logs nicht reichen
Klassisches Application-Logging erfasst Request, Response, Status und Latenz. Für traditionelle Anwendungen reicht das. Für LLM-Systeme nicht — und wer das zu spät merkt, hat ein Compliance-Problem.
Eine LLM-Anfrage ist kein Request-Response-Paar. Sie ist eine verschachtelte Operation: Prompt-Template wird gefüllt, Retrieval-Schritte werden ausgeführt, Tool-Calls starten weitere LLM-Aufrufe, eventuell wird die Antwort von einem zweiten Modell geprüft. Am Ende steht eine einzige Antwort — aber dazwischen liegen zehn bis dreißig Einzelschritte.
Ein normales Log sieht davon nur den Eingang und den Ausgang. Wenn die Antwort falsch ist, lässt sich nicht rekonstruieren: Welcher Prompt wurde am Modell angekommen? Welche Dokumente wurden abgerufen? Hat ein Tool versagt? Wie hoch waren die Token-Kosten pro Schritt?
Genau diese Fragen beantwortet Tracing. Und genau diese Fragen stellt ein Auditor, wenn ein Hochrisiko-KI-System unter den EU AI Act fällt.
Warum der AI Act Tracing zur Pflicht macht
Der EU AI Act ist seit August 2024 in Kraft, die Pflichten für Hochrisiko-Systeme nach Anhang III greifen nach der Änderungsverordnung (EU) 2026/1744 ab 2. Dezember 2027. Für KI-Anwendungen in Versicherung, Banking, kritischer Infrastruktur und Personalwesen bedeutet das: Logging, Transparenz und menschliche Aufsicht sind keine Best Practice mehr, sondern regulatorische Anforderung.
Konkret verlangt Artikel 12 des AI Act „automatische Aufzeichnung von Ereignissen (Logs)“ über die gesamte Lebensdauer des Systems. Artikel 13 fordert Transparenz gegenüber den Nutzern. Artikel 14 verlangt menschliche Aufsicht mit der Möglichkeit, Entscheidungen nachzuvollziehen und rückgängig zu machen.
In der Praxis heißt das: Ein Versicherungsunternehmen, das einen KI-Assistenten für Schadensfallbearbeitung einsetzt, muss für jede Entscheidung dokumentieren können, welche Daten einflossen, welches Modell verwendet wurde und warum das Ergebnis so ausfiel. Ohne Tracing ist das technisch nicht leistbar.
Gartner prognostiziert, dass bis 2026 über 70 Prozent aller Enterprise-GenAI-Initiativen strukturierte Retrieval- und Observability-Pipelines brauchen, um Compliance- und Halluzinationsrisiken zu beherrschen. Gleichzeitig warnt Gartner, dass 40 Prozent der agentischen KI-Projekte an genau solchen Governance-Lücken scheitern.
Langfuse vs. LangSmith: Die Enterprise-Entscheidung
Die zwei dominanten Optionen am Markt sind Langfuse und LangSmith. Wir werden in Kundenprojekten regelmäßig gefragt, welche der beiden wir empfehlen. Die Antwort hängt an zwei Dimensionen: Data Residency und Framework-Bindung.
Langfuse ist Open Source (MIT-Lizenz), lässt sich vollständig self-hosted in EU-Rechenzentren oder on-premise betreiben und ist OpenTelemetry-kompatibel — also framework-agnostisch. Im Februar 2026 liegt das Projekt bei über 21.000 GitHub Stars. LangSmith ist ein proprietäres SaaS-Produkt von LangChain, das primär auf LangChain- und LangGraph-Projekte optimiert ist und bis vor kurzem ausschließlich als Cloud-Service verfügbar war.
Unsere klare Empfehlung für DSGVO-relevante Branchen: Langfuse. Wir haben in den letzten zwölf Monaten acht Implementierungen bei Versicherungen, Energieversorgern und im Finanzsektor begleitet — in allen Fällen war die Self-Hosting-Option ausschlaggebend. Ein Self-Hosted Setup in Azure Deutschland mit Private Endpoints und Azure AD-Integration ist in zwei bis drei Wochen produktionsreif.
LangSmith empfehlen wir bewusst, wenn das Team bereits tief in LangChain investiert ist und die Daten das Unternehmen verlassen dürfen. Das ist in B2C-Szenarien ohne Personendaten manchmal der Fall — bei Hochrisiko-Anwendungen nach AI Act fast nie.
Wie ein Langfuse-Trace konkret aussieht
Die Integration ist schlank genug, dass sie kein eigenes Projekt wird. In Python reicht ein Dekorator oder ein Callback-Handler, um die komplette Trace-Hierarchie zu erfassen:
from langfuse import Langfuse
from langfuse.decorators import observe
langfuse = Langfuse(
host="https://langfuse.firma-intern.de",
public_key=os.getenv("LF_PUBLIC_KEY"),
secret_key=os.getenv("LF_SECRET_KEY"),
)
@observe()
def beantworte_kundenfrage(frage: str, kunden_id: str):
# Metadaten fuer Audit und Kostenattribution
langfuse.update_current_trace(
user_id=kunden_id,
tags=["schadensfall", "versicherung"],
metadata={"risikoklasse": "hoch"},
)
dokumente = retrieve_dokumente(frage) # Span automatisch
evidenz = pruefe_evidenz(frage, dokumente) # Span automatisch
if not evidenz.ausreichend:
return unsicherheits_antwort(evidenz.fehlend)
return generiere_antwort(frage, dokumente)Was dabei entsteht, ist ein hierarchischer Trace mit allen Sub-Operationen, Token-Verbräuchen, Latenzen und Modell-IDs. Jeder Trace ist über die User-ID dem Vorgang zuordenbar, über die Tags filterbar und über die Metadaten audit-konform annotiert.
Ein typischer Trace in der Versicherungs-Schadensfallbearbeitung produziert 15 bis 25 Spans. Bei 50.000 Vorgängen pro Monat sprechen wir von rund einer Million Spans — ein Langfuse-Deployment auf einer einzelnen virtuellen Maschine packt das problemlos, die größeren Installationen bei unseren Kunden verarbeiten zehn- bis zwanzigmal so viel.
Guardrails: Drei Patterns die wir immer einbauen
Tracing allein verhindert keine Probleme — es macht sie nur sichtbar. Für produktive Systeme brauchen Sie Guardrails, die Probleme verhindern, bevor sie entstehen. Drei Patterns sind in jedem unserer Projekte drin:
Evidence Gate. Bei jeder Antwort prüft ein separater Agent, ob die gefundenen Belege die Frage fachlich tragen. Ohne ausreichende Evidenz gibt das System keine Antwort, sondern zeigt die Informationslücke. Das senkt Halluzinationen in unseren Messungen von 12 auf 2 Prozent.
Schema Validation. Strukturierte Outputs (JSON für API-Calls, bestimmte Feldtypen für Weiterverarbeitung) werden gegen ein Schema validiert, bevor sie das System verlassen. Fehlerhafte Outputs werden neu generiert, nicht weitergegeben. Pydantic oder JSON Schema reichen hier.
Budget Gate. Jede Anfrage hat ein Ausführungsbudget (z.B. maximal 0,20 EUR oder 10 Sekunden). Agentische Systeme können sich sonst in Schleifen verfangen. Das Budget ist keine optionale Einstellung — es ist die Versicherung gegen unbegrenzte Kosten bei einzelnen Anfragen.
Was wir bewusst nicht als Guardrail verkaufen: Content-Filter gegen „toxische“ Antworten in Enterprise-Anwendungen. Die Modelle sind inzwischen gut genug, dass dieser Filter mehr False Positives produziert, als er Probleme verhindert. Bei Kinderprodukten oder öffentlich zugänglichen Chatbots sieht die Abwägung anders aus.
Die ersten drei Monate Betrieb
Die interessanten Erkenntnisse kommen nicht aus dem Rollout, sondern aus den drei Monaten danach. Was wir bei unseren Kunden regelmäßig sehen:
- Modellkosten sinken in den ersten vier Wochen um 40 bis 60 Prozent, einfach weil Kostenattribution zeigt, welche Features teuer sind und welche Prompts zu lang gebaut wurden
- Die Halluzinationsrate fällt nicht gleichmäßig, sondern clustert bei bestimmten Fragetypen — die Eval-Dashboards machen das sichtbar und führen zu gezielten Prompt-Updates
- Die erste Produktions-Regression passiert spätestens bei Modell-Update drei, und ohne Eval-Set wäre sie drei bis sechs Wochen unentdeckt geblieben
Ein Versicherungsunternehmen aus unserem Kundenkreis hat nach zwölf Wochen Produktion folgende Zahlen gemeldet: Halluzinationsrate von 8% auf 2% gesenkt, Modellkosten von 14.000 auf 7.000 EUR monatlich, mittlere Fehlersuchzeit von 3 Stunden auf 10 Minuten. Die Langfuse-Einführung war innerhalb des ersten Monats amortisiert.
DSGVO-konformer Betrieb: Die drei kritischen Entscheidungen
Bei DSGVO-relevanten Anwendungen (und bei Finanzdienstleistern erst recht) gibt es drei Entscheidungen, die am Anfang getroffen werden müssen, weil sie später nur mit Schmerzen rückgängig zu machen sind.
Erstens: Wo liegt das Deployment? Wir setzen Langfuse in der Regel auf Azure Deutschland (West Central Germany) oder on-premise im Kunden-Rechenzentrum auf. Azure OpenAI Deutschland als LLM-Backend schließt den Kreis. AWS Frankfurt ist die Alternative, wenn das Unternehmen bereits AWS-zentriert ist.
Zweitens: Welche Daten werden getraced? Die Versuchung ist groß, alles zu loggen. In regulierten Kontexten ist das falsch. Wir trennen Trace-Metadaten (immer gespeichert) von Payload-Daten (nur pseudonymisiert oder komplett ausgeklammert). Bei Versicherungskunden zum Beispiel speichern wir Trace-Strukturen und Token-Kosten, aber nie den Schadensbericht im Klartext.
Drittens: Wie lange werden Traces aufbewahrt? Der AI Act verlangt Aufbewahrung „für die Lebensdauer des Systems“, praktisch heißt das zwischen sechs Monaten und mehreren Jahren je nach Anwendungsfall. Wir empfehlen eine Tier-Strategie: Detailtraces für 90 Tage, aggregierte Metadaten für mehrere Jahre. Das spart Storage-Kosten ohne Compliance-Einbußen.
Für die vollständige Umsetzung in Versicherung und Banking verweisen wir auf unsere Branchen-Spezialisten — Details dazu in Private KI-Infrastruktur und Versicherung.
Häufig gestellte Fragen
Was kostet LLM Observability mit Langfuse?
Langfuse selbst ist Open Source und lizenzkostenfrei. Ein DSGVO-konformes Self-Hosted Setup kostet als einmaliges Projekt 15.000 bis 35.000 EUR abhängig vom Umfang (Single-Anwendung bis Multi-Team-Plattform). Laufende Infrastrukturkosten liegen zwischen 200 und 2.000 EUR pro Monat je nach Trace-Volumen.
Langfuse vs LangSmith — welches für Enterprise?
Für DSGVO-relevante Anwendungen und Branchen unter AI Act empfehlen wir Langfuse, weil es self-hosted in EU-Rechenzentren betrieben werden kann und OpenTelemetry-kompatibel ist. LangSmith ist sinnvoll, wenn das Team tief in LangChain investiert ist und die Daten in US-Cloud liegen dürfen — das ist bei Hochrisiko-Anwendungen fast nie der Fall.
Ist Langfuse AI-Act-konform?
Langfuse erfüllt die technischen Anforderungen aus Artikel 12 (automatisches Logging) und Artikel 14 (Transparenz der Entscheidungen). Die AI-Act-Konformität hängt aber nicht nur am Tool, sondern an Betriebsführung, Dokumentation und Risikoklassifizierung. Pexon Consulting begleitet diese Themen im Rahmen unserer AI-Governance-Beratung.
Reicht Observability bei Standard-RAG oder braucht es Agentic RAG?
Observability ist bei beiden Architekturen Pflicht. Bei Standard-RAG reicht Tracing, um Nutzerfeedback mit Retrieval-Treffern zu verknüpfen. Bei Agentic RAG wird Tracing noch wichtiger, weil mehrere Agenten interagieren — ohne Trace ist bei Fehlern nicht identifizierbar, welcher Agent versagt hat.
Können bestehende Anwendungen nachträglich instrumentiert werden?
Ja. Die SDK-Integration ist nicht-invasiv und in der Regel in wenigen Tagen pro Anwendung umgesetzt. Bei größeren Landschaften bündeln wir das zu einem Observability-Rollout, der drei bis fünf Anwendungen parallel anbindet. Details dazu in einem ersten AI Readiness Assessment.
Nächster Schritt
Wenn Sie produktive LLM-Anwendungen ohne systematisches Tracing betreiben oder einen AI-Act-Compliance-Check vor sich haben: In einem AI Readiness Assessment analysieren wir Ihre bestehenden KI-Systeme gegen Observability-, Governance- und AI-Act-Anforderungen und liefern eine priorisierte Umsetzungsempfehlung.
