AI observability.
Silent failures.

Quality in a production AI system degrades without an event. The corpus grows and retrieval precision falls. Users start asking a new kind of question the system was never good at. A provider updates a model within a version. Each is gradual and none produces an error.

Three mechanisms catch it. A continuously running evaluation set — the same regression suite that gated the deploy, re-run on a schedule against production configuration, so a change in the model or the corpus shows up as a score movement. Input drift monitoring — tracking the distribution of incoming questions, so a shift toward unfamiliar territory is visible before the complaints arrive. And sampled human review, which remains the only method that catches failure modes nobody anticipated.

The last one is the one teams skip and the one that pays. A small number of outputs reviewed weekly by someone who knows what good looks like will find things no automated metric was built to detect, and it is how you discover the failure category you did not think to write a check for.

We instrument with OpenTelemetry so traces land in whatever backend you already run, rather than introducing a separate observability product for the AI part of the system. Where a dedicated LLM tracing tool adds value it is for prompt and output inspection, and it should complement your existing stack rather than fork it.

Everything is sampled deliberately: full traces on errors and on a percentage of normal traffic, metadata on everything. Storing every full trace including prompts and outputs is expensive and, where those contain personal data, creates a retention obligation you may not want (check with your DPO). That is a decision to make consciously and to write down.