22 July 2026
AI governance is also infrastructure governance: what model and cloud dependency means for hospitals
Henna Virkkunen, the European Commission’s digital chief, told the Financial Times that AI has become a geopolitical weapon, and that governments able to cut off other countries’ access to AI models could use that power in their own strategic interest (Barbara Moens and Henry Foy, “AI is becoming a geopolitical weapon, warns EU digital chief,” Financial Times, 21 July 2026). The case she pointed to is concrete: in June 2026, the US government placed export controls on Anthropic’s leading models over security concerns, then lifted them after a backlash from foreign governments and Silicon Valley. Virkkunen called it a preview of “how important it is now in our cyber security environment to be prepared for that kind of reality.” Brussels’ response is a tech sovereignty package backing European alternatives across semiconductors, cloud, and AI, including firms like Mistral, Scaleway, and OVHcloud.
Read at that scale, this is trade and foreign policy. Read at the scale of a single hospital running a patient-facing AI system, it is a governance question that is easy to miss, and the Anthropic episode makes it concrete rather than hypothetical.
Why this is not abstract to me. I did not come to this from the policy side. While building the patient-facing digital twin’s 3D generation and explanation components, I kept facing the same concrete choice: use a stronger third-party hosted model I do not control, or a weaker component I can run and own inside our own environment. On a deadline, the pull is always toward the hosted model, because it makes the demonstration better today. The question that does not show up in a demonstration is the one that matters here: if that hosted model changed its terms, raised its price, deprecated the version I validated against, or became unavailable for a policy reason, what exactly happens to the patient-facing feature, and who is responsible for that outcome? During incubation, the honest answer was often “nothing is decided, because the dependency was never written down.” The Anthropic cut-off is that private engineering question turned into public policy: a model you depend on can be switched off by a decision you had no part in.
A worked extension of the same mechanism. Suppose a hospital’s after-hours triage tool calls a foreign-hosted large language model to help route incoming patient messages by urgency, the same category of model that was briefly cut off in June. If a future export-control action reached that model with less warning, or without being reversed as quickly, the API would simply stop responding. Nobody on the clinical side approved a fallback plan, because the dependency was never named in the deployment’s risk documentation. The triage queue backs up, some messages sit unrouted, and by the time IT escalates it, a patient with a genuinely urgent symptom has waited hours instead of minutes. The model was never inaccurate. It was unavailable, for reasons entirely outside the hospital’s control, and unavailability was never assigned an owner. This is a constructed illustration built on a real mechanism, not a reported incident.
Most medical AI risk registers, including early versions of my own, are built around clinical failure: false negatives, subgroup performance, drift in accuracy. Far fewer name the infrastructure risk the Anthropic episode demonstrates: that the foreign-hosted model API, the cloud region, or the underlying chip supply a deployed system depends on can be disrupted by a policy decision made on the other side of the world, on a timeline the hospital does not control.
This fits inside instruments medical AI teams already maintain, it just needs to be named explicitly:
- Vendor and dependency mapping. Which parts of the system rely on a single foreign model provider, a single cloud region, or hardware subject to export control? A dependency map without this layer is incomplete.
- Continuity and fallback planning. If a model API becomes unavailable overnight, is there a documented fallback, a degraded mode, or a safe shutdown path, or does the patient-facing feature simply fail open or fail closed with no one having decided which?
- A named risk register entry. In the format I use in my own risk register, this would read: risk = “loss of access to a foreign-hosted model or cloud region disrupts a patient-facing workflow”; category = infrastructure / continuity; owner = named, not left to IT by default; mitigation = fallback mode and vendor diversification; review trigger = any export-control or vendor-access change, not just a fixed calendar date.
The governance point is not that hospitals should try to solve geopolitics. It is that model access, cloud dependency, and supply chain resilience are becoming part of the deployment-readiness question, sitting next to validation evidence and human oversight rather than outside it. The Anthropic cut-off showed that this risk can materialize in days, not decades. A system can be clinically validated and still be one export-control decision away from an unplanned outage in patient-facing care. That gap belongs in the risk register, with a named owner, before it becomes an incident.
Source: Barbara Moens and Henry Foy, "AI is becoming a geopolitical weapon, warns EU digital chief," Financial Times, 21 July 2026.