Most finance teams now buy more AI than they build. You call a hosted model API, get a useful answer, and move on. That convenience hides a governance fact people keep forgetting: when you call someone else’s model over the network, you have taken on an ICT service, with all the third-party AI risk that comes with it. The model is not in your repository. The weights are not yours. And yet the output is sitting in a workflow that touches client money.
This is not a reason to avoid vendor models. Building everything yourself is rarely the right answer, and the best hosted models are very good. It is a reason to put the same discipline around bought AI that you already put around any critical supplier.
A model API is a third-party in your register
Start with the boring administrative truth. A hosted model API is an ICT service provided by a third party, and it belongs in your third-party register alongside your custody platform and your market-data feed. DORA expects financial entities to maintain a register of contractual arrangements for ICT services and to assess the risk that comes with each one. A model endpoint your team reaches for ad hoc does not get an exemption because it is easy to call.
So the first piece of work is unglamorous: find every place an external model is being used. In practice that means grepping for API keys and base URLs across codebases, asking teams what they have wired up, and writing down what each call actually does. Some of these will be powering a customer-facing decision. Some will be doing filings extraction in a back office. The register has to know which is which, because the risk is not the same.
Concentration risk and the single provider
Once you have the list, a pattern usually appears. Three teams, five workflows, and one provider behind all of them. That is concentration risk, and it is the part DORA pushes hardest on. If the entity-resolution helper, the document summariser, and the customer chatbot all depend on the same vendor, a single outage or pricing change or terms-of-service shift hits every one of them at once.
Concentration is not automatically bad. Consolidating on one capable provider can be the right call. The point is that the decision should be made on purpose and written down, not arrived at by accident because everyone reached for the same name. You want to know your exposure before the provider has a bad week, not during it.
This is where exit and continuity stop being paperwork. Ask the plain questions:
- If this vendor withdrew the specific model we depend on, how long until we are running on an alternative?
- Can our prompts and our evaluation set move to another provider, or are they shaped around one model’s quirks?
- Is there a fallback path that degrades gracefully, even to a slower or cheaper model, rather than failing the workflow outright?
The silent-update problem
Here is the part that catches careful teams. With your own model you control the weights, so a change is an event you scheduled. With a vendor model the weights can change underneath you. The version label stays the same, the endpoint is unchanged, and yet the behaviour drifts because the provider retrained or tuned something. Your audit trail says nothing changed. Your outputs say otherwise.
You cannot inspect an opaque vendor model, so you validate around it. Two methods do most of the work. First, bound the inputs: constrain what you send so the model operates inside a range you have tested, and reject or flag anything outside it. Second, reconcile the outputs against an independent source. If the model extracts a revenue figure from a filing, check it against the structured feed. If it classifies a transaction, sample and compare against a rules-based result. When the two diverge more than usual, that is your early signal that the model moved, even when the vendor never told you.
Pin model versions where the API allows it, and keep a standing eval set you can rerun on a schedule. A drop in that score is how you catch a silent update before a client does. None of this lets you see inside the model. It lets you notice when its behaviour stops matching what you signed off on.
This is not legal advice, and your DORA obligations depend on your specific classification and arrangements. But the engineering posture holds regardless of how the regulation lands on you: treat every model API as a supplier, know where your concentration sits, and assume the model can change without telling you.