Define normal operation before trying to monitor it
Production AI needs a broader operating contract than conventional software. Availability, latency, and error rates still matter, but a healthy endpoint can produce an unusable answer. Teams also need to know whether responses are grounded, citations support the claims, refusals occur in the right situations, and automated actions respect business rules. Quality can drift even when the application has no visible outage because documents, user behavior, prompts, retrieval settings, and connected systems keep changing.
At launch, define the workflows the system supports, the sources it may use, the actions that require approval, the cases that must go to a person, and the owner who can judge business correctness. Build a durable evaluation set from real tasks rather than generic demonstration questions. For each case, record required answer elements, acceptable sources, prohibited content, and the expected behavior when information is missing. This becomes the monthly baseline; without it, teams end up debating whether an answer merely sounds better.
Review quality, data, integrations, and risk together
A monthly review should not require people to read every conversation, but provider usage charts are not enough. Monitoring should identify suspicious groups of events, while targeted sampling supplies context. The operating team should regularly cover the following areas:
- Response quality:Rerun the stable evaluation set and sample common requests, low-rated conversations, human escalations, and abandoned tasks. Classify failures as factual errors, misunderstood instructions, missing evidence, unsupported citations, inappropriate tone, unsafe compliance, or unnecessary refusal. This prevents every problem from being labeled a model problem.
- RAG and knowledge health:Confirm that new material reached the index, superseded documents stopped appearing, and source permissions carried through correctly. Inspect whether chunking, titles, metadata, filters, and ranking retrieve the passages a knowledgeable employee would expect. Generation cannot repair evidence that was never retrieved.
- Application integrations:Check LINE, ERP, CRM, identity services, and internal APIs for schema, permission, or workflow changes. Pay particular attention to duplicate writes after retries, inconsistent state after timeouts, and downstream APIs that return success before the business transaction is actually complete.
- Security and auditability:Look for sensitive data in prompts, logs, retrieved context, and generated responses. Revalidate service-account privileges and review administrative actions, exports, and high-risk tool calls. Logs need enough context for investigation without becoming a second, poorly governed store of confidential data.
- Cost and capacity:Separate model inference, embeddings, search, cloud compute, network transfer, and third-party API costs. An increase may reflect legitimate adoption, but it can also expose expanding prompts, repeated failures, wasteful retries, or conversations retaining far more context than the task requires.
- User behavior:Identify where users abandon a flow, repeatedly rephrase, switch to a human, or bypass the assistant. Low adoption does not automatically mean low demand; login friction, latency, poor source visibility, or lack of trust may be the real constraint.
Each signal needs an owner and an escalation rule. Infrastructure engineers can diagnose latency but may not know whether a procurement answer is correct. A process owner can recognize a bad answer but may not distinguish a stale index from a permissions failure. The monthly operating process is where these views are combined into one prioritized problem map.
Diagnose the failing layer before changing the model
Replacing the model after a bad answer is an expensive first reaction and often leaves the actual defect untouched. Trace the failure through the stack: Is the source material correct? Was the index refreshed? Did retrieval filters exclude the relevant document? Are instructions conflicting? Did a tool return incomplete data? Only then ask whether the model lacks the required capability. An outdated answer, for example, may come from an old document that was never retired rather than weak reasoning.
Version every behavior-changing component: system prompts, models and parameters, retrieval configuration, knowledge indexes, tool contracts, and safety policies. Before a release, run the baseline evaluation set and add a reproducible case for the newly observed failure. Afterward, verify both the intended improvement and possible regressions elsewhere. If the team changes the model, prompt, and chunking strategy at once, it cannot confidently attribute the result or perform a narrow rollback.
A new release is not a required outcome of every monthly cycle. When evidence is thin, impact is limited, or a proposed fix threatens a more important workflow, improved monitoring and a clear human fallback may be the safer decision. Operations is the discipline of making recorded trade-offs among quality, cost, speed, privacy, and reversibility—not continuously chasing the newest model.
Finish the monthly review with decisions and owners
The meeting should begin with prepared evidence, not a tour of dashboards. Engineering can assemble evaluation results, failure categories, integration health, cost drivers, and open incidents before business, data, security, and system owners meet. During the review, separate urgent risk remediation from normal improvements and from observations that need more evidence.
- One-page operating summary:State current service health, material risks, notable quality movement, and the causes behind cost changes.
- Problem and incident register:Preserve the symptom, affected workflow, root cause, containment, permanent correction, owner, and verification status.
- Change decision log:Record why the team changed—or deliberately did not change—the model, prompt, knowledge source, integration, or workflow, including rollback conditions.
- Next-cycle validation plan:List new evaluation cases, monitoring gaps, source updates, experiments, and approved release items.
A mature process makes every production change explainable, testable, and reversible. When an AI service spans models, cloud infrastructure, enterprise data, and several existing platforms, its operating ownership must cross those same boundaries. An integration team can help establish that shared discipline, but the final business-quality decisions still need named owners inside the organization.