On October 28, 2026, GitHub announced general availability of Copilot Fusion, describing a system that routes and orchestrates models rather than requiring users to select a model for each task. That is the reported development. It raises a broader enterprise question: when software chooses the model, which decisions should remain under human control?
Model routing means delegating the choice of AI model to a system. Orchestration coordinates how models are used. The announcement supports those capabilities, but the supplied excerpt does not establish their accuracy, cost savings or governance effectiveness.
The following checklist is engineering guidance, not a description of announced product features. Its central recommendation is simple: automate model selection only within boundaries that people can explain, inspect and change.
**1. Define permitted data before routing begins**
Decide which information each approved processing path may receive. For example, an organization might permit public documentation while excluding customer records from an initial pilot. Check actual service terms and configuration rather than assuming that every possible model destination has identical data-handling rules. If destinations cannot be verified, narrow the permitted workload.
**2. Evaluate the workflow, not just individual answers**
Build a small evaluation set representing the intended work, including difficult cases and requests that should be rejected or escalated. Define acceptance criteria before comparing results: factual correctness, adherence to instructions and handling of sensitive content are possible dimensions. For coding tasks, include executable tests where appropriate. A fluent explanation should not substitute for checking whether the output meets the requirement.
**3. Establish what can be reconstructed**
Ask what records are available to explain a result: the request category, applicable policy, model or processing path where exposed, evaluation outcome and human approval. Do not assume that a routing service reveals every internal decision. Document visibility gaps and decide whether they are acceptable for the workload. Keep records proportionate; copying sensitive prompts into logs can create another data-management problem.
**4. Give people specific intervention points**
Human oversight should mean more than a general promise that someone is responsible. Assign a person or team authority to pause the workflow, investigate failures and approve changes to permitted uses. Set explicit review triggers, such as failed checks or outputs intended for consequential decisions. Avoid making reviewers approve every routine response without enough information to judge it.
**5. Plan for uncertainty and failure**
Specify what happens when a request cannot be completed within policy, when checks fail or when the routing path is unavailable. Depending on the task, the right response may be to stop, request clarification or send the work to a human. A fallback should not silently relax the original restrictions.
**Start small, then justify expansion**
These controls introduce costs: evaluation takes effort, records need protection and review consumes time. Excessive logging can undermine privacy; excessive approval steps can make oversight superficial. Start with a bounded, lower-consequence use case and expand only when evidence supports the decision.
The practical distinction is between delegating model selection and delegating accountability. An enterprise can consider the first without surrendering the second.