One interface no longer means one operating path.

On 24 September 2025, Microsoft announced that eligible customers could use Anthropic models for certain tasks in Microsoft 365 Copilot. Copilot Studio first made the models available in early-release environments. The visible product to users is still Copilot. However, underneath that shiny exterior, it uses them. Users can now choose a different model and a different processing workflow.

For the user, that was an extra option. For the accountable owner, it raises a bigger question: what else changes when the model changes?

The answer isn't visible in the button the user presses. However, under the hood, data handling, retention, monitoring, contractual terms, incident escalation - the list goes on. These may be common or vastly different, and it's up to the user to verify the answer and what it means for their setup.

Let's take a further look behind the submit button

A Model Menu is an Architecture Decision

Microsoft's announcement of adding Anthropic's Claude Opus 4.1 as an option in the Researcher agent and Claude Sonnet 4 and Opus 4.1 for agents built in Copilot Studio. Microsoft said Copilot would continue to use OpenAI's latest models.

Same code, pilot interface, different path of processing

The route also carried a concrete contractual distinction. Microsoft said Anthropic models were hosted outside Microsoft-controlled environments and were subject to Anthropic's terms. A familiar Copilot interface therefore did not erase the provider boundary.

The change did not show that one provider was safer, more capable or more compliant than another. Nor did it establish Microsoft's business plans. However, its significance is architectural. Its significance was architectural at both the machine and human level, because work begun in one familiar product can now take more than one route.

Different models may suit different tasks, and an alternative can reduce reliance on one provider. But a second provider is not resilience on its own. It becomes resilience only if the paths are sufficiently independent, their control conditions are understood, and work can move between them without creating a fresh risk.

For each permitted route, the organisation needs to know what data crosses the boundary, which evidence is retained, who can stop the work and who owns an incident. Product approval at the surface is too coarse.

Shared Services Carry Consequences across Contracts

A few days earlier, ransomware disrupted a Collins Aerospace passenger-processing service used at several European airports. Reuters reported that automated check-in and boarding were affected, forcing some airports to use manual processes.

This was not an AI incident. It is interesting because the architecture is familiar: one supplier service sat inside several organisations' ability to serve their customers. When the service failed, the operational consequence crossed the contractual boundary at once.

A contract can allocate obligations after an incident. It cannot stop a dependency from becoming a continuity problem during one.

A contract can allocate obligations after an incident. It cannot stop a dependency from becoming a continuity problem during one. The practical questions are closer to the workflow: which business process stops, what manual or alternative route remains, what evidence survives and who coordinates recovery across the supplier and the affected organisations?

The same questions apply to an AI workflow that depends on a model provider, orchestration layer, identity service or external data source. The airport case does not show that AI services are inherently fragile. It shows why you must understand an embedded dependency through the consequences of losing it.

Human Oversight Now Needs a Working Control

The enacted EU AI Act made the link between accountability and intervention explicit for high-risk AI systems. Article 14 set out forthcoming requirements for human oversight measures proportionate to risk, autonomy and context. As appropriate, the person assigned oversight would need to monitor the system, interpret its output, disregard or override it, and interrupt it so it reaches a safe state.

Those duties were not yet generally applicable in September 2025. Under the Act's original Article 113 timetablemost provisions would apply from August 2026, with obligations linked to high-risk systems under Article 6(1) following later.

That provision does not make every Copilot task a high-risk system, and it should not be stretched into a demand for manual approval of every output. Its useful operating principle is narrower: naming a responsible human means little if that person cannot see the workflow or intervene in time.

Multiple model routes make that test harder. A stop mechanism may work at the product layer while logging, retention or recovery differs underneath it. If the route changes, the process owner needs to know whether the evidence and intervention options changed too.

Final Perspective

The spectre I'd carry into a leadership conversation here is that product approval has become too coarse. A person can remain inside one familiar Copilot interface while the work crosses into a provider environment subject to different terms. Accountability therefore has to attach to the workload's actual route, not stop at the product name.

For one consequential workflow, I'd want its owner to show where that route changes and whether the person responsible can still see and interrupt the work. If the explanation ends with “we approved Copilot”, the interface has hidden a fundamental decision behind a shiny user interface.