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.

Distributed Tracing Shows You What Happened. It Cannot Prove It to a Regulator.

Engineers 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.

What Distributed Tracing Actually Captures

A typical OpenTelemetry span for an AI agent call looks like this:

{
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7",
  "operationName": "llm.invoke",
  "startTime": 1721040000000,
  "duration": 847,
  "tags": {
    "model": "claude-opus-4-8",
    "input_tokens": 1247,
    "output_tokens": 389,
    "tool_calls": "['search_database', 'send_email']",
    "status": "success"
  }
}

This 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.

The 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.

What EU AI Act Articles 9 and 13 Actually Require

Article 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."

Neither 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.

The 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.

Consider 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.

Three failure modes emerge in practice:

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.

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.

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.

The Gap Is Structural, Not a Tooling Problem

Teams 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.

This is directionally right and operationally wrong. More granular self-reporting is still self-reporting.

The 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.

EU 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.

For 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.

What Proof Looks Like Alongside Traces

The 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.

An independent witness layer has three properties:

1. Cryptographic commitment at execution time, before the response is returned
2. Controlled by a third party outside the deployer's infrastructure boundary
3. Tamper-evident — mutation of the record is detectable

A concrete pattern:

# Standard agent call
response = client.messages.create(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": prompt}],
    tools=tools
)

# OTel span — for observability
with tracer.start_as_current_span("llm.invoke") as span:
    span.set_attribute("model", response.model)
    span.set_attribute("input_tokens", response.usage.input_tokens)

# Independent attestation — for compliance
attestation = trust_layer.attest({
    "model": response.model,
    "prompt_hash": sha256(prompt),
    "output_hash": sha256(response.content[0].text),
    "tool_calls": [t.name for t in response.content if t.type == "tool_use"],
    "timestamp": response.id  # model-issued, not infrastructure-issued
})
# Returns a signed receipt with a Merkle root — independent of your infrastructure

The 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.

The August 2026 Enforcement Cliff

High-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.

Most 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.

The practical preparation path:

• Audit your observability stack for the three failure modes above: mutable storage, controlled boundary, context gaps
• Identify which agent decisions fall under Annex III — not all agents are high-risk, but the analysis needs to happen before enforcement, not during
• Add independent attestation at execution time for any decision boundary that Article 9 requires you to govern

Observability 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.

---

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

---

Try it yourself

Get a free API key -- 10 scans/day, no credit card, no setup.

Or install the MCP server: npx @anthropic-ai/claude-code mcp add arkforge-eu-ai-act