CH14-05: Monitoring, Cost, Operations, and Change Management
Goal
Explain how AI systems are monitored, operated, and changed after they move beyond a demo.
The previous section covered identity, authorization, safety, and evaluation. This section turns those controls into day-to-day operations. Production AI systems need the same operational seriousness as other cloud workloads, plus a few signals that are specific to model-powered behavior.
The Short Version
AI operations must track behavior, quality, safety, usage, cost, and change because model-powered systems can drift in both output and demand.
An AI system can be healthy at the infrastructure level and still fail the user. The app may return fast responses that are ungrounded, unsafe, too expensive, or subtly worse after a prompt change. Operations must therefore monitor both system health and behavior quality.
What to Monitor
Start with the normal application signals, then add AI-specific signals.
| Signal | What It Tells You | Typical Owner Response |
|---|---|---|
| Requests and active users | Adoption and demand | Scale capacity, manage quotas, forecast cost. |
| Latency | User experience and dependency health | Tune retrieval, model choice, streaming, caching, or timeouts. |
| Errors and throttling | Reliability and quota pressure | Add retries, request quota, reduce concurrency, or degrade gracefully. |
| Token usage | Prompt size, response size, and model cost | Shorten prompts, improve retrieval, set limits, or choose a different model. |
| Model usage by feature | Which workloads drive consumption | Allocate cost, optimize high-use flows, set budgets. |
| Retrieval quality | Whether context is relevant and grounded | Improve chunking, metadata, ranking, freshness, or filters. |
| Tool calls | Which actions are requested and executed | Detect misuse, failures, approval bottlenecks, or risky patterns. |
| Safety events | Blocked, flagged, or escalated interactions | Review policy, adjust controls, investigate abuse or edge cases. |
| User feedback | Perceived usefulness and trust | Prioritize fixes, collect evaluation examples, improve UX. |
| Business outcomes | Whether the system helps the process | Confirm value, not only technical usage. |
Azure Monitor, Application Insights, Foundry observability features, tracing, evaluation results, and application logs can all contribute to this view. The exact tooling may vary, but the responsibility remains: make the AI workflow observable from user request to retrieval, model call, tool action, response, and cost.
Tracing Agent Behavior
Agentic workflows need tracing because the path may involve multiple model calls, retrieval steps, tool calls, retries, and decisions.
A useful trace answers:
What did the user ask?
Which prompt or agent version handled the request?
Which retrieval sources were queried?
Which documents or chunks were used?
Which model deployment was called?
Which tools were requested, approved, executed, or denied?
What errors, retries, or fallbacks occurred?
What response was returned?
Tracing is not only for debugging code. It helps teams understand behavior. When an agent takes the wrong path, the trace shows whether the issue came from ambiguous intent, poor retrieval, a prompt regression, tool schema confusion, authorization failure, or model behavior.
Cost Drivers
AI cost is often easy to underestimate because the early demo has low usage and small prompts. Production usage changes the shape.
Common cost drivers include:
| Cost Driver | Why It Grows |
|---|---|
| Model calls | More users, more features, retries, and multi-step agents increase calls. |
| Input and output tokens | Long prompts, long context, verbose answers, and large tool definitions increase token use. |
| Embeddings | Content ingestion and re-indexing generate embedding costs. |
| Search or vector storage | Retrieval indexes need storage, compute, and operational capacity. |
| Evaluation runs | Quality, safety, and regression tests may call models repeatedly. |
| Logging and tracing | Detailed telemetry increases storage and processing cost. |
| Tool calls | Downstream APIs, workflow systems, and data services may have their own costs. |
| Reserved or provisioned capacity | Predictable throughput can improve reliability, but unused capacity is still paid for. |
Cost control is not only a finance activity. It is an architecture activity. Prompt length, retrieval strategy, model choice, response limits, caching, evaluation frequency, and agent autonomy all affect cost.
Change Management
AI applications change in more ways than traditional applications. A team might change the prompt, model version, retrieval index, chunking strategy, tool schema, authorization rule, safety policy, evaluation set, or workflow routing.
Each change can affect behavior.
Treat these as release-managed assets:
System prompts and prompt templates.
Model deployments and model versions.
Retrieval indexes, embeddings, chunking, and metadata.
Tool schemas and API contracts.
Authorization and approval rules.
Safety policies and filters.
Evaluation datasets and quality thresholds.
Monitoring dashboards and alert thresholds.
A prompt change is not just a text edit if production users rely on the answer. A tool schema change is not just an API cleanup if an agent uses that schema to decide what to call. A retrieval-index change is not just a search improvement if it changes which evidence the model sees.
Incident Response
AI incident response should cover more than outages.
Possible incidents include:
The system gives wrong or unsupported answers.
The system retrieves data the user should not see.
A prompt-injection attempt changes behavior.
A tool call creates or modifies something incorrectly.
Cost spikes after usage growth or a prompt regression.
Quality drops after a model, prompt, or retrieval change.
Safety controls block legitimate use too aggressively.
For each incident type, define the owner, triage path, rollback option, communication plan, evidence needed, and prevention follow-up. A mature team can disable a risky tool, roll back a prompt, switch model deployment, pause an agent, tighten retrieval filters, or lower usage limits without improvising under pressure.
Example: Prompt Change Regression
A product team updates the support assistant prompt to make answers friendlier. The release seems harmless because no application code changed.
After testing, the team notices two problems:
The assistant now produces longer answers, increasing token use by 35 percent.
Policy-summary evaluation scores drop because the model adds extra conversational text that weakens source-grounded precision.
Because the team has evaluation and monitoring in place, the issue is caught before broad rollout. The team shortens the prompt, adds clearer citation rules, sets a response-length target, and reruns the evaluation suite.
That is AI operations working properly. The system treats behavior, cost, and quality as release concerns.
Common Mistakes
Monitoring infrastructure health but not answer quality. A fast, available system can still give bad AI responses.
Treating prompt changes as harmless. Prompts shape behavior and should go through review, evaluation, and rollback planning.
Ignoring token and retrieval costs until usage spikes. Cost should be visible per feature, model, and workflow.
Logging without traceability. Logs are less useful if they cannot connect user request, retrieval, model call, tool call, response, and version.
Having no named owner for AI behavior. Someone must own quality, safety, prompts, tools, cost, and incidents.
If Someone Asks You
An AI application is operable when the team can monitor requests, latency, errors, token use, retrieval quality, tool calls, safety events, feedback, cost, and business outcomes. It also needs controlled change management for prompts, models, retrieval, tools, safety policies, and evaluation suites.
What to Remember
AI operations track system health, behavior quality, safety, cost, and controlled change.
Questions to Check Understanding
Which signals show AI behavior quality rather than only infrastructure health?
Which AI cost drivers can grow quickly as adoption increases?
Why should prompt, model, retrieval, and tool changes go through review and evaluation?