Your AI logs the tokens. Not the decision.
Open your observability dashboard and look at what an AI call actually records. Model name. Input tokens. Output tokens. Duration. Finish reason. That is an itemised bill with timestamps. It tells you what the call cost and whether it fell over. It does not tell you what the model was told, or what it said back. So when someone asks, six months from now, why an AI-assisted decision went the way it did, that dashboard has no answer. It never had one, because nobody chose to keep the part that would.
This is not an oversight. It is a deliberate default, set for defensible reasons, by people who were not thinking about your obligations.
What is actually happening
OpenTelemetry graduated from the Cloud Native Computing Foundation on 21 May 2026, announced at the Observability Summit in Minneapolis. The numbers are not decoration: over 12,000 contributors from more than 2,800 companies, the second-highest project velocity of the the second-highest project velocity among the 240-plus projects in the cloud native ecosystem, after Kubernetes after Kubernetes, an independent third-party security audit and a formal governance review. This is the shared language a large part of the monitoring ecosystem now speaks, with Bloomberg, Capital One and eBay among the named users.
Alongside the core project, the GenAI semantic conventions define spans for the things AI systems actually do: inference calls, embeddings, retrieval, memory operations, tool execution. A common vocabulary, so that a trace emitted by one framework is meant to mean the same thing as a trace emitted by another. That is real progress and worth having.
Now read the part everyone skips. Every content attribute in those conventions is marked Opt-In, tool call arguments and retrieval documents included. Input messages. Output messages. System instructions. Memory records. The input and output message attributes carry the warning verbatim: "This attribute is likely to contain sensitive information including user/PII data." The others are flagged as attributes that may contain sensitive information.: "This attribute is likely to contain sensitive information including user/PII data." The instruction to implementers is explicit. Instrumentations should not capture the attribute by default, and capture should be gated behind an explicit user opt-in. The project's own blog says it in one line: "By default, no prompt content or tool arguments are captured with GenAI telemetry, as these can contain sensitive data. Only metadata like model names, token counts, and durations are included."
So the industry now has a shared vocabulary for AI telemetry, and the half of it that would constitute a record ships switched off.
What it actually means: two records hiding under one word
Here is the trap. "We have LLM observability" sounds like one thing. It is two, and only one of them is installed.
The metadata trace is what you have now. It reconstructs your bill and your uptime. Which model, how many tokens, how long, did it error. Cheap, low-risk, genuinely useful, and it will not answer a single question that starts with "why".
The content trace is what you do not have. What the model was told, what it was given, what it said. This is the only record that reconstructs a decision.
<!-- style: split -->
The default is a privacy default. It is not an audit default. The two pull in opposite directions, and nobody has told you that you are standing between them.
Because here is what "turning it on" actually does. It is not a logging change. It converts your observability backend into a personal-information repository, hosted by a third party, containing every prompt your staff typed and every document your retrieval layer pulled. The claim reference someone pasted in without de-identifying it is now in your monitoring stack. So is the candidate's employment history. And nobody frames the decision that way, because it presents as an environment variable in a deployment config, approved in a pull request, by an engineer who was asked to improve debugging.
An opt-in switch exists. The specification offers a name for it, but explicitly as an example rather than a standard, and real switch names vary by instrumentation. The one verified in the wild belongs to GitHub Copilot Chat: github.copilot.chat.otel.captureContent, described simply as "Capture full prompt/response content". Four words that quietly move your privacy posture.
It is worth drawing two boundaries here, because adjacent disciplines get conflated with this one.
This is not evaluation drift. A standing eval harness asks whether the system is still good in aggregate, measured against a fixed test set over time. A trace asks why this one request went this way, on this day. Evals are a test harness. Traces are evidence. You need both, and neither substitutes for the other.
Nor is it agent memory governance. The conventions do define spans for memory operations, which makes the distinction worth stating plainly: tracing memory is not governing memory. The memory store is context the model reads and acts on. The trace is exhaust the model never reads, written for operators. Governing one tells you nothing about the other.
Who should care, and why it is probably not them
The uncomfortable part is that the person holding this decision is almost never the person who owns the consequence.
Governance and risk teams rely on traces as the evidence base for control-effectiveness assertions. You cannot assert that a human-in-the-loop control operated if you cannot show what the model recommended and what the human did with it.
Claims and workers compensation practitioners face reconstruction after the fact. If an AI-assisted assessment on a claim is challenged months later, the metadata trace tells you a model was called. It does not tell you what it was asked. And the mirror risk applies: if content capture is on and staff have pasted un-de-identified claim data into a tool, that data now lives in the observability stack too, well outside the systems you told the regulator it lives in.
HR teams carry the same exposure on hiring and performance decisions, where "why did the system rank it that way" is a question with legal weight.
Platform and engineering owners hold the flag. They are competent, careful, and have never been asked the question, because it was never framed as a question about obligations. It was framed as debugging.
So the only person who can answer "why did the model say that" is someone who set a default months ago, for reasons that had nothing to do with your regulatory position.
The Australian angle: a 72-hour clock and a destruction duty
For Australian regulated work, this stops being architectural preference and becomes a vice with two jaws.
APRA's CPS 230 commenced on 1 July 2025. Paragraph 32 requires that operational risk incidents and near misses are "identified, escalated, recorded and addressed in a timely manner", and taken into account in the entity's assessment of "its operational risk profile and control effectiveness". Paragraph 33 sets the clock: notify APRA "as soon as possible, and not later than 72 hours, after becoming aware of an operational risk incident" assessed as likely to have a material financial impact or a material impact on critical operations.
Read that against a metadata trace. You cannot assess the materiality of an AI failure from token counts. You cannot tell whether the model leaked something, hallucinated a figure into a customer letter, or simply cost more than usual, because the content is not there. The 72-hour clock is the forcing function, and you cannot start it from token counts.
<!-- style: data-halo -->
Then the other jaw closes. APP 11.1 requires an entity to take such steps as are reasonable in the circumstances to protect the personal information it holds from misuse, interference and loss, as well as unauthorised access, modification or disclosure. The word doing the work is "holds": an entity holds personal information if it has "possession or control of a record" containing it. That reaches your third-party observability vendor. And APP 11.2 requires destruction or de-identification once the information is no longer needed for any purpose for which it may be used or disclosed, subject to the Commonwealth-record and legal-retention exceptions.
Keep too little and you cannot answer APRA. Keep too much, indefinitely, and you are sitting on a personal-information store you cannot justify holding. Trace retention is not a cost setting. It is a privacy control, and almost nobody has set it as one.
The hype check
Three things are being oversold, and the primary sources do not support any of them.
"OpenTelemetry graduated, so AI observability is standardised now." Graduation certified the core project: the Collector, the SDKs, governance, the security audit. The GenAI conventions carry Status: Development, every content attribute is Development, and they were split out into their own repository, which signals ongoing churn rather than settling. The strongest evidence is an absence. The project's own graduation post does not mention AI at all. The AI framing lives in press-release quotes, where "GenAI systems are distributed systems" and observability as "the foundation of trust in AI agents" are positioning, not technical findings.
"We have LLM observability, so we have an audit trail." Covered above. You have a bill.
"Turn content capture on and you have the full record." Three qualifiers, all verifiable. Content is "likely to be large" and may exceed backend limits for telemetry envelopes or attribute values, and instrumentation may offer truncation, so a truncated trace is a partial record. Structured attributes may not yet be supported on spans in a given language, so content often lands as a serialised JSON blob. And if your team enabled ratio sampling for cost, the trace of the one request that went wrong may never have been kept.
That last one deserves correcting properly, because practitioners have it backwards. Sampling is not on by default. The SDK default is parentbasedalwayson, which keeps everything. Ratio sampling is something someone chose. That choice, made against a cloud bill, silently decided which of your AI decisions remain reconstructable.
The honest picture: cost, latency and error telemetry is nearly free on a genuinely maturing shared vocabulary. Decision reconstruction requires three deliberate choices that nobody is currently being asked to make.
What to do this week
<!-- style: process-flow -->
1. Ask one question about one system. Is content capture on or off, and who decided? Not a project. One message to the platform owner. The answer is almost always "off, and nobody decided", which is the finding.
2. Run the reconstruction test. Write down the exact question you would face in an incident. For an illustrative case: "On 3 March, the assistant recommended rejecting [CLAIMREFERENCE]. What was it given, and what did it say?" Now check whether your telemetry can answer it. If it cannot, you have a metadata trace, not a record, and you should say so out loud before someone else discovers it for you.
3. If you turn it on, do all three parts, not one. Content capture without redaction and retention is worse than leaving it off, because it manufactures a liability while feeling like diligence.
The redaction part has an architectural detail worth knowing, and it is the one thing here you will not get from a vendor blog. The conventions say instrumentations may support user-defined in-process hooks for handling content upload, and that the hook "SHOULD operate independently of the opt-in flags" that control content capture, and that instrumentations "SHOULD invoke it regardless of the span sampling decision". The hook can also "enrich and modify" the span and message objects before they leave the process.
Read that carefully. Every other control you might reach for sits downstream and is conditional. Backend-side scrubbing only sees what already left your process. A sampling rule can drop the span entirely, taking your redaction logic with it. Where an instrumentation implements the hook, the specification says it should run regardless of the opt-in flags and regardless of the sampling decision, in-process. That makes it the only place redaction is specified to run unconditionally, and it makes "does our instrumentation support the hook" the first question to ask. Put it there, not in a dashboard rule you will forget you wrote.
Then set trace retention deliberately against APP 11.2, rather than inheriting whatever your vendor ships. Ask what period you can actually justify, given the incidents you would need to reconstruct and the obligation to destroy what you no longer need. Write the number down and record why.
None of this is exotic engineering. It is three decisions, made once, in the open, by people who know what the organisation is on the hook for. The alternative is what most teams have now: a default set by a stranger, discovered during an incident, at the worst possible moment to learn what your logs do not contain.
References
- OpenTelemetry, Semantic conventions for generative client AI spans (status: Development, as at 17 July 2026)
- OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry
- CNCF, Cloud Native Computing Foundation Announces OpenTelemetry's Graduation, 21 May 2026
- OpenTelemetry, SDK environment variable specification
- APRA, Prudential Standard CPS 230 Operational Risk Management (July 2025)
- OAIC, APP Guidelines Chapter 11: Security of personal information
TheAICommand. Intelligence, At Your Command.
