Operating AI in production: observability, exceptions and change

Observe the product workflow, not only the model endpoint

An AI-enabled service can appear healthy while users are unable to complete their work. A model endpoint may return responses quickly, but retrieval may be stale, a permission check may fail, a tool action may be blocked or review queues may be accumulating. Start observability from the user workflow: request received, context retrieved, model or rule executed, output presented, reviewer action taken, downstream action completed and exception closed.

Choose a small number of signals for each stage. They might include completion, abandoned tasks, unavailable dependencies, review backlog, override rate, error class, latency, cost, unsafe-output reports or user feedback. The right signals are specific to the workflow. A dashboard with many model metrics but no way to identify the affected user journey is an engineering instrument, not yet an operating control.

Make configuration and provenance traceable

When a user reports an unexpected outcome, the team needs to know which system version produced it. Record the relevant version identifiers for the model or provider endpoint, prompt/instruction, retrieval source, policy/configuration, tool definitions and application release. Link these to a request or case reference while minimising sensitive content in logs. The amount retained should be proportionate to the purpose and data-protection obligations, not simply everything a platform can emit.

Provenance is also important for content and retrieval. Where a response depends on source material, consider what a reviewer needs to see to assess whether the material was relevant and current. Where a system takes an action, retain the authorisation and confirmation route. These records make it possible to distinguish a model issue from a changed policy, stale source, unavailable dependency or user-input problem.

Plan for drift, supplier change and feature change

AI behaviour can change because the surrounding system changes: source content is updated, a provider adjusts a model, a tool schema evolves, user behaviour shifts or a product team changes instructions. Define which changes require a regression check, which can be released under an existing approval and which need a new evaluation or risk review. This does not need to be bureaucratic; it makes the degree of change and its evidence visible.

Set thresholds or review triggers that are meaningful for the use case: an increase in overrides, a fall in retrieval usefulness, a new harmful-output category, a broken tool contract, a sustained queue backlog or a cost/latency condition that affects user experience. The response should be specified: investigate, restrict a capability, roll back a configuration, route work to review, communicate a limitation or pause the feature.

Give operations a pause and recovery route

Every production workflow needs a way to reduce exposure when the normal path is not trustworthy. That may be a feature flag, a read-only mode, a manual fallback, a restricted cohort, disabled tool actions or a switch to a known configuration. Document who can use it, what evidence is required, how users are informed and how the service is re-enabled. A pause control with no owner or recovery checklist can create a second incident.

The operating record should join product, security and support evidence without turning monitoring into surveillance of individual staff. Use it to understand service health, customer impact, process completion and control effectiveness. For decisions with a material effect on people, ensure the relevant human review, privacy and sector requirements are considered alongside technical telemetry.

A working check before committing the next stage.

• 01

  Trace the user workflow through context, output, review and downstream action.

• 02

  Record configuration versions and proportionate request provenance.

• 03

  Create owned queues for material exceptions and user challenges.

• 04

  Choose meaningful health, quality, safety, cost and latency signals.

• 05

  Define change categories and regression/review requirements.

• 06

  Maintain a tested pause, fallback and recovery route.