An AI feature that convinces in testing can quietly degrade in production. The provider updates the model, documents in the knowledge base change, users ask different questions than expected. Classic monitoring then shows green lights: the API responds, no errors, normal response times. That the answers are getting worse is invisible there. AI observability closes this gap.
What to log
For every model request it pays to write a structured entry: feature, workspace, model and version, prompt version, input and output tokens, time to first and last token, outcome and, if applicable, error type. For features with retrieval, add the documents found and their relevance scores. This data answers the question of what exactly happened when something goes wrong, and underpins cost analysis.
Traces across multi-step flows
Many AI features consist of several steps: a request is rephrased, a search runs, results are reranked, an answer is generated, the result is checked. Agents add tool calls. A trace links all steps of one user request into a single flow, showing where time is lost, where costs arise and where a wrong result originated. Without traces, debugging multi-step systems often ends in guesswork.
Established standards for distributed tracing can be used for AI flows too. What matters is that every step carries the identifier of the original request.
Operational metrics
Beyond classic values such as error rate and availability, some metrics matter especially for AI features. Time to first visible token determines how fast a feature feels. Tokens per request show whether context is growing unnoticed. The share of answers that fail a check — invalid format or missing source — is an early sign of quality problems. And users aborting during generation say a lot about the patience a feature demands.
Quality signals in production
Quality cannot be measured directly in production, but it can be approximated through signals. Explicit feedback such as a rating is valuable but rare. Implicit signals are more frequent: does the user accept the result, edit it heavily, regenerate it, abandon it? A rising regeneration rate for a feature is often the first sign that something is off.
A regular sample of real requests checked against the evaluation set's criteria complements this — automatically by a judge model and, on a small scale, by people.
Detecting drift
Drift means the conditions under which a feature operates are changing. Input drift arises when users bring new topics, languages or formats. Data drift arises when documents in a knowledge base change. Model drift arises when the provider updates a model or retires one you use. Pinned model versions instead of «always the latest» and an evaluation run before every version change are the most effective protection against unnoticed model drift.
Privacy in the logs
Prompts and answers often contain personal data. Logs must therefore follow the same rules as the data itself: purpose limitation, limited retention, restricted access. A proven approach is to keep metadata such as token counts and response times long-term, but full content only briefly and pseudonymised. External observability services belong on the sub-processor list, with their storage location checked.
Alerts that help
Alerts should react to changes, not single events: a clearly higher share of failed checks, a jump in tokens per request, a longer time to first token, unusual consumption by individual workspaces. Too many alerts get ignored; a few well-chosen ones are taken seriously.
How we approach it
Innopulse sets up structured logs, traces and a small number of meaningful alerts for AI features from the start and connects them with the evaluation set. That way a decline shows up on the dashboard before it shows up in support tickets.