07 August 2026
Vendor due diligence cannot see concentration: what the FSB on AI in finance adds to a hospital's dependency map
The Financial Stability Board’s 2024 report on the financial stability implications of AI lists the AI-related vulnerabilities that stand out for their potential to increase systemic risk, and it puts two of them first: third-party dependencies and service provider concentration, and market correlations (FSB, “The Financial Stability Implications of Artificial Intelligence,” 14 November 2024). In 2026 the FSB went further than monitoring, publishing Sound Practices for Responsible Adoption of AI as a consultation report on 10 June, closing comments on 22 July, and publishing the public responses on 6 August. The direction of travel is clear: provider concentration in AI is being treated not as a procurement detail but as a stability question that supervisors expect institutions to govern.
Read at the scale of the global financial system, this is macroprudential policy. Read at the scale of one hospital running a patient-facing AI system, it points directly at a weakness in an instrument I already build and rely on, and naming that weakness is more useful to me than the headline.
Why this lands on work I have already done. While building the patient-facing digital twin’s 3D generation and explanation components, I kept making the same concrete choice on a deadline: reach for a stronger third-party hosted model that makes the demonstration better today, or stay with a weaker component I can run and own. I wrote that trade-off up in an earlier note arguing that AI governance is also infrastructure governance: a clinically validated system can still be one export-control decision or one vendor change away from an unplanned outage, so model access and cloud dependency belong in the risk register with a named owner. The instrument I proposed there is a vendor and dependency map for a single deployment. What the FSB report makes uncomfortably clear is that this map, which I built to protect my own system and would defend as done carefully and honestly for one hospital, still cannot see the risk the FSB is most worried about.
The blind spot is structural, not a matter of diligence. Suppose ten hospitals each run their own after-hours triage support, and each one completes a thorough vendor review of its chosen model. Every review can pass on its own terms, and every institution can be individually prudent, while all ten happen to route through the same foreign-hosted base model, the same cloud region, or a component that traces back to the same chip supply. Nothing inside a single hospital’s risk register reveals this, because the register is scoped to that hospital. The exposure lives in the correlation across institutions, which is exactly what the FSB names alongside concentration. A single-institution review is the right tool and is still blind here, in the same way each bank’s own due diligence can be sound while the sector as a whole leans on a handful of providers. Per-institution prudence does not add up to system-level safety when the dependency is shared. This ten-hospital case is a constructed illustration built on the mechanism the FSB names, not a reported incident.
What the finance frame hands back. The useful move is not to claim I now govern systemic risk. It is to notice that my hospital-scoped dependency map was missing a column, and the finance framing tells me which one. My original map recorded, for each dependency, the provider, the critical service it supports, and who owns the fallback. The version I would build after reading the FSB adds what a single-deployment view structurally omits:
- Provider and critical service. Which foreign model, cloud region, or hardware line does this patient-facing feature actually depend on.
- Market alternatives. Is there a substitutable provider I could move to, or is this component effectively non-substitutable today.
- Migration time. If I had to switch, is that days, a validation cycle, or realistically not feasible before the feature must keep running.
- Common-sector exposure. Are peer institutions likely to depend on the same provider, so that a single disruption would hit many of us at once rather than only me.
The first three sharpen an instrument I already had. The last one is the FSB’s contribution, and it is precisely the row a hospital acting alone has no reason to write, because the risk it captures does not belong to any single hospital.
What I am not claiming. I do not govern financial stability and will not pretend the leap from one deployment to a national banking system is small. The scale, the instruments, and the supervisors are not mine. What does transfer is narrower and, I think, real: the discipline of deciding for a specific system what it depends on, who owns the fallback, and what must be true before it is trusted, is the same discipline the FSB is applying at system scale, and reading one against the other showed me a column my own map was missing. That is the point of writing it down rather than filing it as an interest. The concentration risk that a whole sector has to govern is the same dependency risk I govern for one hospital, viewed from far enough back that the correlation becomes visible.
Sources: Financial Stability Board, "The Financial Stability Implications of Artificial Intelligence," 14 November 2024, which names third-party dependencies and service provider concentration, and market correlations, among the AI vulnerabilities with potential to increase systemic risk; and FSB, "Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Consultation report," 10 June 2026 (consultation closed 22 July 2026; public responses published 6 August 2026). This note is a governance reflection and not financial or supervisory advice.