The Shared Providers That Make AI a System-Risk Problem

For a financial institution, third-party AI risk begins with a vendor relationship but does not end at the contract boundary. The focus here is the network behind a financial AI use case: data vendors, model and foundation-model providers, cloud and hardware infrastructure, deployment platforms and the institutions that place those services into credit, payments, fraud or other critical operations. Mapping that network lets the reader distinguish two questions that are often merged: can the institution understand its provider, and how many institutions depend on the same provider or input?

Those questions describe different failure surfaces. A proprietary model can be difficult to inspect even when only one firm uses it. A widely used cloud or foundation-model provider can create concentration risk even if its service is well documented. When opacity and common dependence occur together, an institution may be accountable for an AI outcome without being able to see the conditions that produced it—and its peers may be exposed to the same conditions.

The visible vendor is only one layer

A financial institution may think it has acquired “an AI tool,” but the tool is usually an arrangement among several components. At one layer, a data provider supplies market information, credit records, identity signals, fraud indicators or other alternative data. At another, a model provider supplies a traditional machine-learning model, a foundation model, a language model or a complete application. Beneath or alongside the model sits computing infrastructure: cloud services, specialised hardware, storage and networking. A deployment platform may connect those pieces to the institution’s own systems, customer channels and staff workflows.

The layers have different responsibilities and different interfaces. Data cross a boundary with assumptions about origin, permission, quality, format and update frequency. A model crosses a boundary with assumptions about its intended use, limitations, version, performance and required inputs. A cloud or deployment service crosses a boundary with assumptions about availability, access control, logging, geographic processing and recovery. The institution’s application then adds its own prompts, records, business rules and decisions. A failure at one interface can be hidden by the interface above it: a model may return an answer while concealing that a feed changed, a document was omitted or a provider silently switched an underlying component.

The distinction between a direct relationship and a wider dependency network is especially important for smaller institutions. A bank may contract with a software company that provides a customer-service application. That company may use a foundation model from another provider, host it on a cloud platform and draw its information from a separate data service. The bank may have access to the application’s controls but not to the training data, model changes, storage location or downstream service providers. The visible contract is therefore an interface to a supply chain, not a complete description of the system.

The Financial Stability Board describes several ways a financial institution can obtain third-party AI: it can use a provider’s service without customisation, customise or fine-tune the service, or encounter AI embedded inside a broader product. These arrangements may look similar to a user, but they expose the institution to different forms of control. Fine-tuning may add customer or proprietary information. A software-as-a-service product may conceal more of the underlying model. Embedded AI may be introduced when the institution buys a service whose central purpose is not presented as AI at all.

The model’s proprietary character creates an information gap. A provider may not disclose the examples used in training, the tests performed, the sources of a generated answer or the changes made between versions. Commercial confidentiality can be legitimate, but it does not remove the deployer’s need to understand material limitations.