Operating and improving
Launch is the beginning. This module covers how AI products are monitored, improved and governed over their lifetime.
Learning objectives
- Define monitoring signals for AI features
- Run an improvement loop driven by failures
- Prepare for AI incidents
- Treat responsible AI as a product requirement
6.1 Launch is the start
After launch, real users find cases your evals missed, data shifts, and model providers update or retire models. Plan for continuous operation from day one — see LLMOps for the technical side.
6.2 What to monitor
| Area | Signals |
|---|---|
| Quality | Sampled human reviews, automated eval scores on live traffic, groundedness |
| User behaviour | Acceptance, edits, regenerations, abandonment, feedback reasons |
| Safety & risk | Flagged outputs, complaints, escalations, injection attempts |
| Operations | Latency, errors, cost per request and per user |
| Fairness | Quality and outcomes across user groups and languages |
6.3 The improvement loop
Turn production into a learning engine: collect failures → add them to the eval set → fix with the improvement ladder → re-run evals → release. Over time this creates a data flywheel: more usage produces more examples, which improve the product, which attracts more usage. Respect privacy and consent when using customer data to improve the product.
6.4 Handling incidents
- Define what counts as an AI incident (harmful output, data leak, systematic error)
- Have a kill switch or fallback for every AI feature
- Know who decides, who communicates and who fixes
- Record incidents and lessons learned; feed them into evals and design
- Report serious incidents as regulations require — see AI Governance
6.5 Responsible AI is a product requirement
Fairness, transparency, privacy and safety belong in the backlog alongside features — with owners, acceptance criteria and evidence. Run a responsible AI review at key stages (framing, pre-launch, major changes), and keep a model or system card describing purpose, data, evaluation results, limitations and owner. See Responsible AI.
6.6 Planning when models change fast
New models arrive every few months. Keep your evals model-agnostic so you can test new models quickly; revisit ideas you rejected as infeasible; and avoid building features that the next general-purpose model will make obsolete. Your durable advantage is your understanding of users, your data and your evals — not a particular model.
Bring it together: a one-page product brief for your AI feature covering problem framing, automate/augment decision, error experience, eval plan and launch criteria, rollout plan, monitoring signals, and responsible AI considerations.
See a worked example
Headings to use: Problem & users · AI's role and human oversight · Experience and error handling · Eval set and launch thresholds (including must-nevers) · Rollout stages and kill-switch triggers · Monitoring dashboard · Cost per active user · Risks, fairness checks and owner.
Key takeaways
- Monitor quality, behaviour, safety, operations and fairness.
- Failures → evals → fixes → re-test → release.
- Every AI feature needs a kill switch and incident plan.
- Responsible AI work belongs in the backlog with owners.
- Your durable advantage is users, data and evals — not one model.