Green dashboards, frustrated customers
During my banking work, customers sometimes could not see their current information even though the systems appeared available. That was a useful correction to how I read a service dashboard. For an AI workflow, I want to see whether a request reached the right source, used the right records and returned something the user could rely on. Endpoint availability is only one part of that picture.
AI inference has the same trap. A model endpoint can stay available while users receive poor answers, and it can look slow because an upstream application is delayed rather than because inference is overloaded. Observability has to cover the whole journey: authorization, retrieval, model execution, tool calls, validation and presentation. Otherwise you cannot tell capacity problems from data, integration or product problems.
Decide what questions telemetry must answer
Start with a short list. Did the request complete? Did the result pass the application's checks? Where did time accumulate? Which configuration ran? Did the user correct or escalate? These questions are a stronger design basis than collecting every available metric and hoping a useful dashboard emerges.
For interactive generation, time to first visible response and time to completion are different experiences; people tolerate a longer answer if something useful arrives quickly. Serving systems such as vLLM expose production metrics that support this analysis. Measure queueing and dependency time separately too. An order assistant may spend most of its time waiting on an ERP query, and no amount of inference capacity fixes that.
Record which configuration served each request: model revision, prompt version, retrieval settings and tool versions. When quality shifts, the first question is always what changed. Without configuration identifiers in the trace, teams end up correlating timestamps against release notes by hand, which is slow during an incident and unconvincing afterward to an audit committee or a regulator asking for evidence.
Tie quality signals to business meaning
Track validation outcomes that correspond to real requirements: unsupported citations, invalid units, missing required fields, answers produced without enough source evidence. Keep them separate from technical exceptions. A request can complete without a stack trace and still fail the business contract. In wealth management or private banking, an answer with a stale position is worse than a timeout, because the advisor may act on it.
Treat user feedback as a pointer, not a verdict. A thumbs-down may reflect a confusing interface, an unavailable source or a correct refusal to disclose restricted information. A thumbs-up does not prove accuracy. Use feedback to select cases for review, then examine them with the business owner. Turning satisfaction into a correctness claim is how an AI program loses credibility with its audit committee.
Keep sensitive content out of routine telemetry
Routine telemetry should favor identifiers, timings, configuration references and structured outcome categories. Full prompts and results can contain personal information, protected health information under HIPAA, account details or confidential business content. If an investigation needs content capture, define the authorized scope, access and retention separately. Do not make unrestricted capture the default because it is convenient in the first weeks.
Review metric labels as carefully as logs. Customer names, document titles or free-text inputs can leak information and explode label cardinality. Use a controlled vocabulary and correlation identifiers that link events without exposing the underlying material. Observability is itself a data product. It needs data governance like any other, and your CISO should be able to describe exactly what it holds.
Turn signals into an operating response
Every important alert should name a likely owner and a next step. A rise in source timeouts belongs to the integration team; a quality regression after a model change may require rollback. Set thresholds around user impact and expected traffic, because an alert that keeps firing on harmless variation will be ignored during a real incident.
Run a simulated incident using only the telemetry the service actually collects. Can an operator identify the affected requests, distinguish a source problem from an inference problem and explain the impact to the business owner? Close the gaps that exercise reveals. Remove fields with no defined operational use, especially sensitive content collected simply because logging it was easy.