{"slug": "distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator", "title": "Distributed Tracing Shows You What Happened. It Cannot Prove It to a Regulator.", "summary": "OpenTelemetry spans provide engineers with visibility into AI agent execution, but under the EU AI Act Articles 9 and 13, this self-reported telemetry is not considered sufficient evidence for regulatory compliance. The structural problem is that the entity being audited controls the evidence, making it mutable and lacking independence. To meet regulatory standards, teams need to implement tamper-proof logging and independent verification mechanisms.", "body_md": "OpenTelemetry spans give engineers visibility into AI agent execution. Under EU AI Act Articles 9 and 13, that visibility is not evidence. Here is what the gap looks like structurally and how to close it.\n\nEngineers instrumenting AI agents with OpenTelemetry make a reasonable assumption: if I can trace every tool call, model invocation, and decision branch, I have an audit trail. Regulators under EU AI Act will disagree. The distinction matters, and it is structural.\n\nA typical OpenTelemetry span for an AI agent call looks like this:\n\n```\n{\n  \"traceId\": \"4bf92f3577b34da6a3ce929d0e0e4736\",\n  \"spanId\": \"00f067aa0ba902b7\",\n  \"operationName\": \"llm.invoke\",\n  \"startTime\": 1721040000000,\n  \"duration\": 847,\n  \"tags\": {\n    \"model\": \"claude-opus-4-8\",\n    \"input_tokens\": 1247,\n    \"output_tokens\": 389,\n    \"tool_calls\": \"['search_database', 'send_email']\",\n    \"status\": \"success\"\n  }\n}\n```\n\nThis is genuinely useful. You can reconstruct execution order, measure latency, detect errors, correlate with downstream calls. OpenTelemetry, Datadog, Jaeger — these tools solve real engineering problems. The issue is not that they fail at observability. The issue is that observability and compliance proof are different things with different requirements.\n\nThe span above was written by your infrastructure, stored in your backend, and is queried through your tooling. From a regulatory standpoint, this is the system reporting on itself.\n\nArticle 9 requires \"a risk management system\" that is implemented \"throughout the entire lifecycle of the high-risk AI system.\" Article 13 requires that high-risk AI systems be designed \"in a way that enables deployers to understand and interpret the system's output and use it appropriately.\"\n\nNeither article says \"keep logs.\" The recitals clarify the intent: providers and deployers must be able to demonstrate that their systems behaved as governed. Demonstration implies evidence that is independent of the system being audited.\n\nThe legal threshold is: would a data protection authority or market surveillance authority accept this as proof? The answer for self-reported telemetry is consistently: it corroborates, it does not prove.\n\nConsider the analogy: a company under financial audit cannot submit records it created itself as primary evidence of compliance. An independent auditor verifies those records against external sources. AI Act enforcement follows the same logic — vendors cannot be the sole witness to their own behavior.\n\nThree failure modes emerge in practice:\n\n**Mutable telemetry.** Most observability backends allow post-hoc modification of spans. Even systems with append-only storage typically allow metadata updates. A regulator asking \"how do I know this trace was not altered?\" receives no satisfactory answer from an observability stack.\n\n**Vendor-controlled storage.** If your traces live in Datadog or New Relic, those vendors control the data. If you export to your own backend, your own infrastructure controls it. Either way, the entity being audited controls the primary record.\n\n**Context window gaps.** Agent calls often execute with context that is not serialized into spans: the full system prompt, the retrieved RAG chunks, the memory state at inference time. Traces capture events; they do not capture the epistemic state that produced the decision.\n\nTeams often respond to this gap by adding more instrumentation. Capture the full prompt. Hash the model version. Record every tool argument and response. Add timestamps at microsecond precision.\n\nThis is directionally right and operationally wrong. More granular self-reporting is still self-reporting.\n\nThe structural problem: the entity being audited (your system) is producing the evidence (your traces). No amount of instrumentation solves this because instrumentation is under the same control boundary as the system it instruments.\n\nEU AI Act Article 17 requires technical documentation demonstrating that the system was designed and tested to meet the requirements. Article 9 requires that risk management controls are \"continuously updated\" with evidence that they function. Both provisions imply an independent verification loop — someone other than the operator validating that governance actually operated.\n\nFor deployers building on third-party models (GPT-4, Claude, Mistral), this gap compounds. You cannot produce cryptographic proof that the model version you think you called is the model version that executed. The vendor's API response claims a model version. Your trace records that claim. Neither proves the claim.\n\nThe correct architecture keeps distributed tracing for what it does well — debugging, latency analysis, cost attribution, error correlation — and adds an independent witness layer for compliance.\n\nAn independent witness layer has three properties:\n\nA concrete pattern:\n\n```\n# Standard agent call\nresponse = client.messages.create(\n    model=\"claude-opus-4-8\",\n    messages=[{\"role\": \"user\", \"content\": prompt}],\n    tools=tools\n)\n\n# OTel span — for observability\nwith tracer.start_as_current_span(\"llm.invoke\") as span:\n    span.set_attribute(\"model\", response.model)\n    span.set_attribute(\"input_tokens\", response.usage.input_tokens)\n\n# Independent attestation — for compliance\nattestation = trust_layer.attest({\n    \"model\": response.model,\n    \"prompt_hash\": sha256(prompt),\n    \"output_hash\": sha256(response.content[0].text),\n    \"tool_calls\": [t.name for t in response.content if t.type == \"tool_use\"],\n    \"timestamp\": response.id  # model-issued, not infrastructure-issued\n})\n# Returns a signed receipt with a Merkle root — independent of your infrastructure\n```\n\nThe observability span and the attestation receipt are complementary records, not duplicates. When an auditor asks \"prove the agent behaved as governed on this date,\" you present the attestation. When an engineer asks \"why did the agent take 2.4 seconds on Tuesday,\" you query the traces.\n\nHigh-risk AI system requirements under EU AI Act apply from August 2, 2026. Systems in scope include AI that evaluates creditworthiness, makes employment decisions, powers biometric identification, or performs safety-critical functions under Annex III.\n\nMost engineering teams instrumenting agents today are building observability infrastructure. Almost none are building independent proof infrastructure. The gap will become visible when the first enforcement actions land, and retroactive proof generation is not possible — you cannot go back and independently attest decisions that already happened.\n\nThe practical preparation path:\n\nObservability solves the engineering problem. Compliance requires proof that observability cannot provide by design. Recognizing the distinction now costs an architecture review. Discovering it during audit costs considerably more.\n\n*Trust Layer provides cryptographic execution attestation for AI agents — independent of your infrastructure, designed to satisfy EU AI Act Articles 9 and 13 requirements. It complements your existing observability stack rather than replacing it. arkforge.tech*\n\n** Get a free API key** -- 10 scans/day, no credit card, no setup.\n\nOr install the MCP server: `npx @anthropic-ai/claude-code mcp add arkforge-eu-ai-act`", "url": "https://wpnews.pro/news/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator", "canonical_source": "https://dev.to/arkforge-ceo/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator-5h1k", "published_at": "2026-07-15 18:03:22+00:00", "updated_at": "2026-07-15 18:10:18.081950+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-ethics", "developer-tools"], "entities": ["OpenTelemetry", "EU AI Act", "Datadog", "New Relic", "Jaeger"], "alternates": {"html": "https://wpnews.pro/news/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator", "markdown": "https://wpnews.pro/news/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator.md", "text": "https://wpnews.pro/news/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator.txt", "jsonld": "https://wpnews.pro/news/distributed-tracing-shows-you-what-happened-it-cannot-prove-it-to-a-regulator.jsonld"}}