3.1.5. Transitioning Processes to AI and Between AI Platforms
💡 First Principle: Any transition replaces something that works, however imperfectly, with something that has not yet proven itself in your environment. The goal is to capture the benefit of the new approach without breaking the business during the switch. That requires protecting continuity, understanding true costs, confirming data readiness, and measuring performance against the old way before committing fully.
Two kinds of transition appear on the exam: moving a business process to an AI-based solution (for example, from manual claims review to AI-assisted review), and moving between AI platforms (for example, switching foundation model providers, moving from a vendor tool to a Bedrock-based application, or consolidating several AI tools).
The exam guide names four key considerations:
| Consideration | Questions to answer | Typical safeguards |
|---|---|---|
| Business continuity | What happens if the new system fails or underperforms? Can we fall back? | Parallel run, phased cutover, rollback plan, retained manual capability, defined incident process |
| Cost implications | What are one-time migration costs and the new run-rate? Are there exit fees, overlapping licenses, retraining costs? | Total cost comparison, pricing at projected volume, contract review before commitment |
| Data readiness | Is the data the new solution needs available, clean, accessible, and permitted for this use? Must data move, and can it legally? | Data assessment, migration plan, residency and privacy review |
| Performance impact | Will quality, speed, or accuracy change? How will users experience the change? | Baseline the current process, run side-by-side evaluation on real cases, define acceptance thresholds before switching |
Platform transitions carry hidden work. Prompts tuned for one model may perform differently on another. Evaluation sets, guardrail configurations, integrations, and user training may need to be rebuilt. Model behavior differences can affect tone, refusals, or output format that downstream processes depend on. And a switch made to save on per-token pricing can be erased by re-engineering effort.
Practical transition patterns include parallel runs (old and new side by side, comparing outputs), phased rollout by region, product, or customer segment, shadow mode (AI produces outputs that are logged and compared but not acted on), and human-in-the-loop during early operation, with autonomy increased as performance is proven. Communication with affected employees and customers is part of the plan, not an afterthought (Phase 5).
⚠️ Exam Trap: "Switch over completely on a fixed date to minimize the period of running two systems" is usually wrong for AI transitions. Prefer options that protect continuity (parallel run, phased cutover, rollback) and measure performance against a baseline before full commitment, while assessing full cost and data readiness.
Reflection Question: Your company plans to move its customer-service assistant from one foundation model to another that is 40% cheaper per token. List what must be re-validated before cutover, and describe a cutover approach that protects customers if the new model performs worse.
