Your observability stack is your AI audit trail

The next time a regulator, a customer, or an internal investigator asks you to explain why your AI system made a specific decision on a specific day, the answer will live in Datadog, New Relic, or Grafana. Not in a custom audit log you built for the AI.

That is the honest state of AI auditing right now. Observability platforms, designed to track latency, errors, and traces, have become the de facto evidence layer for AI behavior. Most teams haven't noticed because they are still treating audit as a separate product feature on the roadmap.

The audit feature is already deployed. The question is whether it captures what regulators will actually ask for.

What observability platforms get right, almost by accident: distributed tracing already follows a request through a model call, a tool invocation, and a downstream API. That is the chain of custody for an AI decision. Metrics retention covers months of behavior, which is what you need when someone asks why output drifted. Most platforms correlate logs to user-level identifiers, which is what you need to honor a data subject access request.

What they get wrong, by design: sampling. If you are sampling traces for cost reasons, you are sampling your audit trail. Regulators don't accept 'we didn't keep that one.' Schema drift. Prompt changes, model version changes, and tool definitions change underneath your traces. If you can't reconstruct the prompt-tool-model triplet on a specific date, you can't reconstruct the decision. Access controls. Observability data is usually open to engineering. Audit evidence usually needs legal hold, role-based redaction, and tamper-evidence.

For product counsel, the move isn't 'let's buy AI audit software.' It is 'let's walk our observability stack and figure out what it can already prove, and what gap we would have to close before the first real inquiry.'

Architecture determines governance. Your audit posture is whatever your observability config happens to allow today.