SkarpChapter 3 of 3
The Launch Is Only the Beginning
Students will be able to organize responsible AI deployment as a continuous cycle of mapping impacts, measuring performance, managing incidents, and reassessing whether use should continue.
1. Treat Deployment as a Loop
The operating loop
A responsible deployment cycle is: map the context, measure performance, manage risks, and reassess continuation. The loop repeats because data, users, models, and social conditions change after launch.
Why launch is not proof
A system can pass a laboratory test and still behave differently in daily use. NIST notes that real-world conditions, human behavior, and changing data can alter AI risks and performance.
2. Map the Context Before Measuring Success
The context map
Write down the system's purpose, users, affected non-users, decisions influenced, likely benefits, possible harms, and available safeguards. Include what happens when the system is wrong.
A practical question
Do not ask only, "Is the model accurate?" Ask, "Accurate for whom, in which setting, with what consequences, and compared with which alternative?"
3. Test the Whole Use Case Before Launch
Test the workflow
Test the model, interface, data pipeline, human review process, and downstream action together. A technically correct prediction can still create harm if the surrounding workflow turns it into an automatic decision.
Use failure-oriented tests
Include rare cases, ambiguous inputs, adversarial prompts, missing data, system outages, and cases involving people who may be especially affected. Document both the result and the limits of the test.
4. Choose Measures That Trigger Action
A dashboard is not governance
A metric becomes useful when it has an owner, a review schedule, a threshold, and a predefined response. Without those links, monitoring can become a display of numbers rather than risk control.
Measure outcomes and signals
Measure direct outcomes, such as incorrect decisions, and early warning signals, such as unusual overrides, complaint clusters, distribution shifts, or rising uncertainty.
5. Monitor After Release
What can change?
Inputs may change, users may adapt, attackers may discover new weaknesses, and a vendor may update a model. A system can therefore become less reliable without anyone changing its stated purpose.
Keep a baseline
Record pre-launch performance and operating assumptions. Compare later results against that baseline so gradual deterioration is visible rather than mistaken for normal variation.
6. Turn Incidents into a Managed Process
The incident card
Capture what happened, when it happened, which version was involved, who was affected, how it was detected, immediate containment, and the decision about restoration or suspension.
Do not hide near misses
A near miss can reveal a weak control before serious harm occurs. Recording near misses improves testing, training, thresholds, and escalation procedures.
7. Decide When to Pause, Roll Back, or Retire
Use this decision exercise for a hospital scheduling assistant. A new model update causes a sharp rise in incorrect appointment instructions. The team cannot yet reproduce every error. Ask three questions: Can the harm be contained? Is a safe fallback available? Is the remaining risk within the approved tolerance? If not, pause the update or roll back to the last known safe version. Retirement is appropriate when the system's purpose, data, safeguards, or risk profile no longer fits the context. NIST states that deployment should cease safely when severe or unacceptable risks are occurring or imminent.
8. Apply the Cycle
Choose the strongest responsible deployment plan.
A company launches an AI tool that screens warranty claims. Which plan best reflects continuous responsible deployment?
- Map affected people and consequences, test realistic cases, monitor outcomes, report incidents, and define pause or retirement thresholds.
- Launch after achieving a high overall accuracy score, then review the system only if customers complain publicly.
- Keep a human in the process and allow the model to continue operating unless the software crashes.
Show Answer
Answer: A) Map affected people and consequences, test realistic cases, monitor outcomes, report incidents, and define pause or retirement thresholds.
The first option connects impact assessment, pre-deployment testing, continuous monitoring, incident management, and continuation criteria into one lifecycle. Human involvement and software stability alone do not prove that the system remains safe or appropriate.
Key Terms
- TEVV
- Test, evaluation, validation, and verification activities used to examine whether an AI system works as intended and is fit for its context.
- rollback
- Returning an AI system to a previous version or safer operating configuration.
- retirement
- Ending an AI system's use because its purpose, safeguards, performance, or risk profile no longer supports continued deployment.
- risk tolerance
- The level and type of risk an organization is prepared to accept in a specific context.
- impact assessment
- A structured examination of who may be affected by an AI system, how they may be affected, and what safeguards are needed.
- incident reporting
- The documented process for recording, escalating, investigating, and communicating harmful or potentially harmful AI events.
- continuous monitoring
- Ongoing observation of system performance, inputs, users, incidents, and changing conditions after deployment.
- pre-deployment testing
- Testing performed before release to evaluate performance, limitations, risks, and impacts in conditions resembling intended use.