[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-opentelemetry-ki-stack-dsgvo-konforme-llm-observability":3},"\u003Cp>Am 21. Mai 2026 hat die Cloud Native Computing Foundation \u003Ca href=\"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2026\u002F05\u002F21\u002Fcloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">die Graduation von OpenTelemetry bestätigt\u003C\u002Fa>. OTel ist damit, nach Kubernetes, eines der am schnellsten gereiften CNCF-Projekte — und ein herstellerunabhängiger Standard für Metriken, Logs und Traces. Für Unternehmen, die KI-Stacks selbst oder in regionalen Rechenzentren betreiben wollen, ist das ein guter Moment, sich anzuschauen, was OTel speziell für KI-Stacks bedeutet und wie man es so einrichtet, dass Audit-Trails, Datenschutz und Betrieb nicht nachträglich zusammengeflickt werden müssen.\u003C\u002Fp>\n\n\u003Cp>Dieser Artikel zeigt das Ganze End-to-End als Referenzarchitektur. Von der vLLM-Inferenz-Schicht über LiteLLM als Proxy, MCP-Agenten in Multi-Agent-Workflows, Qdrant als Vektordatenbank bis hin zur Frage, welche Metriken eine Compliance-Stelle für die HRAIS-Vorbereitung sehen will. Die Codebeispiele sind bewusst als Vorlage geschrieben: nah genug an realen Deployments, aber so neutral, dass sie auf unterschiedliche Betriebsmodelle passen.\u003C\u002Fp>\n\n\u003Cp>Bevor wir tief einsteigen, ein kurzer Absatz für alle, die nicht jeden Tag in YAML-Configs leben: Wenn du einen LLM-Stack aufbauen willst, der von Anfang an OTel-instrumentiert ist und DSGVO-Audit-Trails sauber vorbereitet, \u003Ca href=\"\u002Fde-at\u002Fcontact\">beraten wir gerne\u003C\u002Fa>. Der Modell-Stack kann in einem regionalen Rechenzentrum laufen, ohne dass du selbst Hardware beschaffen musst — wichtig ist nur, dass Datenflüsse, Rollen, Retention und Zugriffsschutz vor dem produktiven Betrieb sauber definiert sind.\u003C\u002Fp>\n\n\u003Ch2>Warum OpenTelemetry der richtige Standard für KI-Stacks ist\u003C\u002Fh2>\n\u003Cp>OpenTelemetry hat 2026 zwei Dinge geschafft, die andere Observability-Standards bisher nicht hingekriegt haben. Erstens: einen wirklich herstellerunabhängigen Wire-Format-Standard für Traces, Metriken und Logs. OTLP (OpenTelemetry Protocol) ist eine simple gRPC\u002FHTTP-Schnittstelle, die jedes ernstzunehmende Observability-Backend mittlerweile entgegennimmt — Grafana Tempo, Jaeger, ClickHouse-basierte Stacks wie SigNoz, Elastic, Dynatrace, Datadog, Honeycomb, der CNCF-Newcomer OpenObserve. Wer OTel-instrumentiert, ist nicht mehr an einen Vendor gebunden, sondern wechselt das Backend mit einer Config-Änderung.\u003C\u002Fp>\n\u003Cp>Zweitens: Mit den \u003Cstrong>OpenTelemetry GenAI Semantic Conventions\u003C\u002Fstrong> gibt es seit 2024 einen offiziellen, aktiv gepflegten Standard speziell für KI-Workloads. \u003Ca href=\"https:\u002F\u002Fopentelemetry.io\u002Fblog\u002F2026\u002Fgenai-observability\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Die SIG hat im April 2024 angefangen\u003C\u002Fa>, und Stand Anfang 2026 deckt sie vier Bereiche ab: LLM-Client-Spans (jeder Modell-Aufruf), Agent-Spans (komplette Agent-Iterationen mit Tool-Calls), Events (Prompt- und Completion-Inhalte) und Metriken (Token-Verbrauch, Latenz, Fehlerquoten). Die Conventions sind teilweise noch im Experimental-Status, aber die Kern-Attribute (Modellname, Token-Counts, Tool-Calls) sind stabil und werden von immer mehr Frameworks ausgeliefert.\u003C\u002Fp>\n\u003Cp>Für DACH-Unternehmen ist der dritte Punkt der entscheidende: \u003Cstrong>Mit OTel hast du einen offenen, auditierbaren Trace-Pfad, der viele technische HRAIS-Vorbereitungen strukturiert abbildbar macht\u003C\u002Fstrong>. OTel ersetzt keine juristische Bewertung und keine AI-Governance, aber Logging, Traceability, Aufbewahrungslogik und Versionsbezüge für Modell-Aufrufe lassen sich damit deutlich sauberer modellieren als mit verstreuten Applikationslogs.\u003C\u002Fp>\n\n\u003Ch2>Das Zielbild: eine OTel-instrumentierte Referenzarchitektur\u003C\u002Fh2>\n\u003Cp>Damit klar ist, worüber wir reden, hier ein Stack-Layout, das sich für selbst betriebene Setups und für den Betrieb in einem regionalen Rechenzentrum eignet:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Inferenz-Layer:\u003C\u002Fstrong> vLLM als Inferenzschicht, mit getrennten Modell-Lanes für Reasoning, Generation und Routing. Welche Modelle und welche Beschleuniger sinnvoll sind, hängt vom Use Case, Datenschutzprofil, Budget und Verfügbarkeitsziel ab.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Proxy-Layer:\u003C\u002Fstrong> LiteLLM 1.86 als zentrale Routing-Schicht zwischen Anwendungen und Modellen, mit Cost-Tracking, Rate-Limits und einheitlicher OpenAI-kompatibler API.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Agent-Layer:\u003C\u002Fstrong> Mehrere spezialisierte Agents (Research, Code, Customer-Support) über Model Context Protocol (MCP) an Tools angebunden, orchestriert über LangChain Deep Agents oder Windmill als Skript-Engine.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Vektordatenbank:\u003C\u002Fstrong> Qdrant als Vektordatenbank für RAG-Pipelines, je nach Betriebsmodell selbst oder regional gehostet, mit Payload-Filtering für tenant-isolierte Suchen.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Storage:\u003C\u002Fstrong> Europäisch oder regional kontrollierte Storage-Komponenten für Dokumente, Modelle und Checkpoints. Jurisdiktion, Unterauftragnehmer und Datenflüsse werden vorab dokumentiert statt nur pauschal versprochen.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Frontend:\u003C\u002Fstrong> OpenWebUI als eines von mehreren Frontends — daneben fahren wir eigene UIs für strukturierte Prozesse, die mit OpenWebUI nur schwer abzubilden wären.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Auf allen Schichten läuft ein OTel-Collector im DaemonSet-Modus, der OTLP-Daten entgegennimmt, pseudonymisiert oder filtert und an ein zentrales Backend weiterleitet. Ob dahinter Grafana Tempo\u002FMimir\u002FLoki, Jaeger, ClickHouse\u002FSigNoz oder ein anderes Backend liegt, ist austauschbar — genau das ist der Charme von OTel.\u003C\u002Fp>\n\u003Cp>Wer das Setup nicht selbst betreiben will, kann ein solches Stack-Layout auch in einem regionalen Rechenzentrum betreiben lassen. Der Vorteil: Der Modell-Stack läuft nah an den Datenanforderungen, ohne dass du selbst Hardware beschaffen musst. Die konkreten Datenflüsse und Auftragsverarbeitungsrollen werden dabei nicht behauptet, sondern vorab vertraglich und technisch festgelegt. Mehr dazu über \u003Ca href=\"\u002Fde-at\u002Fcontact\">unsere Kontaktseite\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2>Schritt 1: vLLM-Inferenz instrumentieren\u003C\u002Fh2>\n\u003Cp>vLLM bringt seit Version 0.18 \u003Ca href=\"https:\u002F\u002Fdocs.vllm.ai\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">native OTel-Unterstützung\u003C\u002Fa> für Traces und Metriken mit. Die Aktivierung ist eine Sache von wenigen Environment-Variablen. Beispiel-Konfiguration für ein Deployment, das gegen einen lokalen OTel-Collector spricht:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\"># vLLM Inferenz-Container\nexport OTEL_EXPORTER_OTLP_ENDPOINT=http:\u002F\u002Fotel-collector:4317\nexport OTEL_EXPORTER_OTLP_PROTOCOL=grpc\nexport OTEL_SERVICE_NAME=vllm-reasoning\nexport OTEL_RESOURCE_ATTRIBUTES=\"deployment.environment=prod,model.lane=reasoning\"\nexport VLLM_OTLP_TRACES_ENDPOINT=$OTEL_EXPORTER_OTLP_ENDPOINT\nexport VLLM_OTLP_METRICS_EXPORT_INTERVAL_MS=10000\n\nvllm serve your-org\u002Fyour-model \\\n  --otlp-traces-endpoint $VLLM_OTLP_TRACES_ENDPOINT \\\n  --max-model-len 65536 \\\n  --tensor-parallel-size 4\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Was vLLM jetzt liefert, sind drei Klassen von Telemetrie. \u003Cstrong>Spans pro Request\u003C\u002Fstrong> mit Modellname, Input-Token-Count, Output-Token-Count, Time-to-First-Token, Total-Latenz und HTTP-Status. \u003Cstrong>Metriken\u003C\u002Fstrong> wie \u003Ccode>vllm_request_success_total\u003C\u002Fcode>, \u003Ccode>vllm_time_to_first_token_seconds\u003C\u002Fcode>, \u003Ccode>vllm_e2e_request_latency_seconds\u003C\u002Fcode>, \u003Ccode>vllm_gpu_kv_cache_usage_perc\u003C\u002Fcode>, alle als OTel-Metriken mit Histogram- und Gauge-Semantik. \u003Cstrong>Logs\u003C\u002Fstrong> über das normale stdout\u002Fstderr, das vom OTel-Collector mit dem \u003Ccode>filelog\u003C\u002Fcode> Receiver eingesammelt wird.\u003C\u002Fp>\n\u003Cp>Wichtig: Defaults loggen Prompt-Inhalte \u003Cstrong>nicht\u003C\u002Fstrong> mit. Das ist ein sinnvoller Datenschutz-Default — der Prompt-Inhalt kann personenbezogene Daten enthalten, und blind alles in den Trace zu schreiben, ist ein unnötiges Datenschutzrisiko. Wer Prompt-Bodies für Debugging braucht, sollte sie über ein separates, restriktiv zugangsgeschütztes Logging-Profil aktivieren und mit strengem Retention-Schedule (z.B. 7 Tage, dann harter Delete) versehen.\u003C\u002Fp>\n\n\u003Ch2>Schritt 2: LiteLLM-Proxy mit OTel-Tracing\u003C\u002Fh2>\n\u003Cp>LiteLLM ist die zentrale Stelle, an der alle Anwendungen ihre LLM-Aufrufe hindurchschicken — und damit auch der natürlichste Punkt für die Audit-Trail-Aufzeichnung. Die \u003Ca href=\"https:\u002F\u002Fdocs.litellm.ai\u002Fdocs\u002Fobservability\u002Fopentelemetry_integration\" target=\"_blank\" rel=\"noopener noreferrer\">OTel-Integration ist in LiteLLM seit 1.74 stable\u003C\u002Fa> und wird über die Proxy-Config aktiviert:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\"># litellm-config.yaml\nlitellm_settings:\n  success_callback: [\"otel\"]\n  failure_callback: [\"otel\"]\n  cache: true\n  cache_params:\n    type: redis\n    host: redis.internal\n    port: 6379\n\ngeneral_settings:\n  master_key: env\u002FLITELLM_MASTER_KEY\n  database_url: env\u002FDATABASE_URL\n\nenvironment_variables:\n  OTEL_EXPORTER: \"otlp_grpc\"\n  OTEL_ENDPOINT: \"http:\u002F\u002Fotel-collector:4317\"\n  OTEL_SERVICE_NAME: \"litellm-proxy\"\n  OTEL_TRACES_EXPORTER_HEADERS: \"x-tenant-id=internal\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>LiteLLM erzeugt damit pro Aufruf einen Span mit den GenAI-Semantic-Convention-Attributen — \u003Ccode>gen_ai.system\u003C\u002Fcode> (z.B. \"anthropic\"), \u003Ccode>gen_ai.request.model\u003C\u002Fcode>, \u003Ccode>gen_ai.response.model\u003C\u002Fcode>, \u003Ccode>gen_ai.usage.input_tokens\u003C\u002Fcode>, \u003Ccode>gen_ai.usage.output_tokens\u003C\u002Fcode>. Das ist die richtige Granularität, um Token-Verbrauch pro Modell, pro Tenant und pro Workflow zentral zu tracken — und gleichzeitig eine belastbare Grundlage für spätere Audit- und Logging-Anforderungen.\u003C\u002Fp>\n\u003Cp>Die wichtigste Empfehlung an dieser Stelle: \u003Cstrong>W3C Trace Context\u003C\u002Fstrong> durchgängig propagieren. Wenn deine Web-App eine Anfrage stellt, soll der Trace-Context als HTTP-Header (\u003Ccode>traceparent\u003C\u002Fcode>) bis zur LLM-Antwort durchgereicht werden. Dann hast du am Ende einen Trace-Tree, der von der UI über LiteLLM bis zur vLLM-Inferenz hin durchgeht — und kannst ein einzelnes \"warum war diese Antwort so langsam\" mit drei Klicks beantworten.\u003C\u002Fp>\n\n\u003Ch2>Schritt 3: MCP-Agenten und Tool-Calls instrumentieren\u003C\u002Fh2>\n\u003Cp>Hier wird es spannend. Multi-Agent-Workflows mit MCP-Servern sind die Schicht, an der die meisten Standard-Observability-Setups scheitern, weil ein Agent-Run aus zig Schritten besteht — Tool-Calls, Reasoning-Steps, Sub-Agent-Aufrufe — und ohne saubere Trace-Hierarchie kein Mensch mehr rekonstruiert, was passiert ist.\u003C\u002Fp>\n\u003Cp>Die GenAI-Semantic-Conventions definieren dafür \u003Cstrong>Agent-Spans\u003C\u002Fstrong> als übergeordnete Klammer um die LLM-Client-Spans. Praktisch bedeutet das: Jeder Agent-Run bekommt einen Root-Span (\u003Ccode>gen_ai.agent.run\u003C\u002Fcode>), unter dem sich die einzelnen LLM-Aufrufe und Tool-Calls als Child-Spans anordnen. Mit LangChain Deep Agents ist die Instrumentierung minimal:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-python\">from opentelemetry import trace\nfrom opentelemetry.instrumentation.langchain import LangChainInstrumentor\nfrom langchain.agents import create_deep_agent\n\n# Auto-Instrumentation aktivieren\nLangChainInstrumentor().instrument()\n\ntracer = trace.get_tracer(\"research-agent\")\n\nwith tracer.start_as_current_span(\"research-agent.run\") as span:\n    span.set_attribute(\"gen_ai.agent.name\", \"research-agent\")\n    span.set_attribute(\"gen_ai.agent.id\", run_id)\n    span.set_attribute(\"tenant.id\", current_tenant)\n\n    agent = create_deep_agent(\n        tools=[mcp_filesystem, mcp_gitlab, mcp_qdrant_search],\n        model=\"litellm\u002Flocal-reasoning-model\",\n    )\n    result = agent.invoke({\"task\": user_task})\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Auf der MCP-Server-Seite empfehlen wir dringend, eigene Spans zu erzeugen, die mit dem Trace-Context aus dem Agent-Call verbunden sind. Ein MCP-Server, der eine SQL-Query gegen die Kundendatenbank ausführt, sollte das im Trace zeigen — sonst ist die Audit-Frage \"welcher Agent hat im Zeitfenster X welche Kundendaten gelesen\" unbeantwortbar. Für die wichtigsten MCP-Server-Implementierungen (Python, TypeScript) ist die OTel-Instrumentierung zwei bis fünf Zeilen Code.\u003C\u002Fp>\n\u003Cp>Ein wichtiger Punkt für die DSGVO-Compliance: \u003Cstrong>Tool-Call-Argumente können in Spans landen\u003C\u002Fstrong>. Wenn ein Agent ein Tool mit \"find_customer_by_email(email=...)\" aufruft, darf die E-Mail nicht ungeprüft im Trace-Backend landen. Lösung: Im MCP-Server eine Hash- oder Redaction-Schicht einbauen, die personenbezogene Argumente vor dem Trace-Export pseudonymisiert. Das geht entweder über einen OTel-Span-Processor im Collector oder direkt in der Tool-Implementierung. In vielen Setups ist die Server-Seite besser, weil dort der Kontext klar ist, was personenbezogene Daten sind und was nicht.\u003C\u002Fp>\n\n\u003Ch2>Schritt 4: Qdrant und RAG-Pipelines\u003C\u002Fh2>\n\u003Cp>Qdrant ist seit der Version 1.10 nativ OTel-instrumentiert. Die Aktivierung ist ein Eintrag in \u003Ccode>config.yaml\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">service:\n  telemetry_disabled: false\n  enable_tls: false\n\ntelemetry:\n  otlp:\n    endpoint: \"http:\u002F\u002Fotel-collector:4317\"\n    protocol: \"grpc\"\n    service_name: \"qdrant-prod\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Damit bekommst du Spans für Collection-Operationen, Such-Latenzen pro Collection, Index-Build-Zeiten und Storage-Metriken. Für RAG-Pipelines ist das entscheidend, weil du sonst nicht siehst, wo die Latenz wirklich entsteht: ist es die Vektor-Suche, das LLM, das Re-Ranking, der Tool-Call? Mit durchgängigem OTel-Trace-Context ist die Antwort eine einzige Trace-Ansicht — und nicht mehr ein Bash-Skript, das vier verschiedene Log-Files mit Timestamps korreliert.\u003C\u002Fp>\n\u003Cp>In typischen RAG-Pipelines findet OTel genau die Engpässe, die in klassischen Logs leicht untergehen: Embedding-Generierung auf einem überlasteten CPU-Pool, langsames Re-Ranking, zu große Kontextfenster oder Tool-Calls mit unklarer Latenz. Sichtbar wird das, weil ein Span wie \"embedding.generate\" plötzlich Sekunden statt Millisekunden braucht — im Backend-Log wäre das oft unauffällig, weil es nicht als Fehler zählt.\u003C\u002Fp>\n\n\u003Ch2>Schritt 5: Audit-Trail und Retention-Strategie\u003C\u002Fh2>\n\u003Cp>Für Hochrisiko-Systeme verlangt \u003Ca href=\"https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002Foj\" target=\"_blank\" rel=\"noopener noreferrer\">Artikel 12 des AI-Acts\u003C\u002Fa> je nach Ausgestaltung Logging-Fähigkeiten, die Ereignisse über den Systembetrieb nachvollziehbar machen. Das klingt groß, ist aber in der Praxis mit OTel sauber vorbereitbar — wenn man drei Dinge berücksichtigt.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Erstens: Span-Inhalte separat von Telemetry-Daten speichern.\u003C\u002Fstrong> Trace-Daten sollten nicht das Audit-Log sein — sie sind zu volatil (Sampling), zu kurz aufbewahrt (typisch 7-30 Tage) und enthalten gegebenenfalls PII. Das Audit-Log dagegen ist Append-Only, langzeit-archiviert (typisch 2-7 Jahre, je nach Regulator) und enthält nur die Audit-relevanten Felder.\u003C\u002Fp>\n\u003Cp>Die pragmatische Lösung: Im OTel-Collector einen \u003Cstrong>Routing-Processor\u003C\u002Fstrong> konfigurieren, der bestimmte Spans (z.B. alle mit Attribute \u003Ccode>audit.relevant=true\u003C\u002Fcode>) zusätzlich in einen Audit-Log-Receiver schiebt. Der Audit-Receiver schreibt nach NDJSON, das tagespartitioniert auf ein WORM-Storage (Write-Once-Read-Many) landet — je nach Setup etwa auf ein S3-kompatibles MinIO mit Compliance-Lock oder ein anderes revisionssicheres Archiv.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Zweitens: Retention-Strategie schriftlich definieren und automatisieren.\u003C\u002Fstrong> Die Frage \"wie lange behalten wir was\" muss vor dem ersten produktiven Trace beantwortet sein. Ein plausibles Muster: 14 Tage Traces, 90 Tage Metriken, längere Aufbewahrung nur für dedizierte Audit-Logs im Object-Lock-Storage. Ein geplanter Cleanup-Job räumt täglich auf, was über die Retention-Grenze gerutscht ist. Das ist deutlich entspannter, als am Tag der Audit-Anfrage plötzlich festzustellen, dass Logs zu lange oder zu kurz vorgehalten wurden.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Drittens: PII-Redaction als Default.\u003C\u002Fstrong> Ein OTel-Collector-Processor (\u003Ccode>attributes\u003C\u002Fcode>-Processor mit Regex-Matchern oder ein eigener \u003Ccode>transform\u003C\u002Fcode>-Processor) kann definiert sein, der bekannte PII-Felder pseudonymisiert oder hasht, bevor sie an das Backend gehen. Beispiel: E-Mail-Adressen werden zu deterministischen SHA-256-Hashes — eindeutig für Korrelation, aber nicht rückführbar. Das funktioniert allerdings nur, wenn die Anwendungsschicht die PII-Felder konsistent benennt (also \u003Ccode>customer.email\u003C\u002Fcode> statt einer wilden Mischung aus \u003Ccode>email\u003C\u002Fcode>, \u003Ccode>user_email\u003C\u002Fcode>, \u003Ccode>mailaddress\u003C\u002Fcode>).\u003C\u002Fp>\n\n\u003Ch2>Was OTel nicht löst — und was du zusätzlich brauchst\u003C\u002Fh2>\n\u003Cp>Ehrliches Wort: OTel ist kein Allheilmittel. Drei Dinge muss man parallel auf der Rechnung haben.\u003C\u002Fp>\n\u003Cp>OTel löst \u003Cstrong>nicht das Thema Prompt- und Output-Inhalte\u003C\u002Fstrong>. Wenn nachvollziehbar sein muss, was ein Modell gesagt hat, brauchst du eine separate Speicherschicht für Prompts und Completions — gehasht oder volltext, je nach Rechtsmeinung und Datenschutzkonzept. Ein praxistaugliches Muster ist eine eigene Postgres-Tabelle mit tenant-bezogener Verschlüsselung, die per Foreign-Key auf die Trace-ID des entsprechenden Spans verweist.\u003C\u002Fp>\n\u003Cp>OTel löst \u003Cstrong>nicht die Modell-Versionierung\u003C\u002Fstrong>. Du musst zusätzlich tracken, welches Modell-Gewicht zu welchem Zeitpunkt aktiv war (Modell-Hash, Datenstand des Trainings, verwendeter Datensatz). Bei vLLM ist das Modell-Tag im Span gespeichert (\u003Ccode>model.name\u003C\u002Fcode>), aber das ist nur ein Label — die Mapping-Tabelle \"Tag → konkreter Hash → Trainings-Run\" musst du separat führen. Häufig reicht dafür eine schlanke Datenbanktabelle plus Modell-Registry, etwa über MLflow oder ein vergleichbares internes Register.\u003C\u002Fp>\n\u003Cp>OTel löst \u003Cstrong>nicht die Compliance-Bewertung selbst\u003C\u002Fstrong>. Du hast nach der Instrumentierung exzellente Daten — aber die Bewertung \"ist das ein hochriskantes System nach Annex III oder nicht\" ist immer noch eine juristische und organisatorische Frage. Die Daten sind nur die Grundlage.\u003C\u002Fp>\n\n\u003Ch2>Fazit — OpenTelemetry als Compliance-Multiplier\u003C\u002Fh2>\n\u003Cp>OpenTelemetry hat mit der CNCF-Graduation am 21. Mai 2026 den letzten formalen Schritt getan, um als reifer, herstellerunabhängiger Standard für Observability zu gelten. Für KI-Stacks ist das ein doppelter Gewinn: Du bekommst nicht nur die klassischen Observability-Vorteile (eine Datenebene, ein Wire-Format, austauschbare Backends), sondern eine ehrliche Grundlage für Audit-Trails, die DSGVO- und HRAIS-Vorbereitung deutlich strukturierter macht.\u003C\u002Fp>\n\u003Cp>Wer einen selbst betriebenen oder regional gehosteten LLM-Stack mit vLLM, LiteLLM, MCP-Agenten und Qdrant aufbaut, kann mit überschaubarem Aufwand End-to-End-Traceability schaffen — und damit gleichzeitig die Frage \"warum ist das langsam\" und \"wer hat im Zeitfenster X welche Daten verarbeitet\" besser beantworten. Die größeren Stolpersteine liegen nicht in der Instrumentierung, sondern in den begleitenden Themen: PII-Redaction, Retention-Strategie, separate Speicherung sensibler Inhalte. Aber das sind klar lösbare Probleme, sobald die OTel-Schicht da ist.\u003C\u002Fp>\n\u003Cp>Eine AI-OpenStack-Architektur sollte diese Instrumentierung ab Tag eins mitbringen: vLLM, LiteLLM, MCP-Server, Qdrant und der Orchestrator-Layer werden OTel-instrumentiert, PII-Redaction und Retention werden dokumentiert statt später nachgerüstet. Wenn du das in deinem Unternehmen aufbauen willst oder den Modell-Stack in einem regionalen Rechenzentrum betreiben lassen möchtest, \u003Ca href=\"\u002Fde-at\u002Fcontact\">beraten wir gerne\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Cp>Vertiefender Kontext zu den umliegenden Architektur-Themen findest du in unseren Pillars zu \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fmulti-agent-systeme-mcp-dsgvo-konform-aufbauen\">Multi-Agent-Systemen mit MCP\u003C\u002Fa>, \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fmcp-server-selbst-hosten-dsgvo-konformes-setup\">MCP-Server selbst hosten\u003C\u002Fa> und \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fagentic-engineering-2026-dsgvo-mistral-vllm-cline\">Agentic Engineering 2026 mit Mistral, vLLM und Cline\u003C\u002Fa>.\u003C\u002Fp>\n"]