Markets
Your AI supplier may depend on another supplier
Map the dependency chain so a service outage has a clear owner and an operating fallback.
Zocri · 2 min read · Sources checked
The visible vendor may not operate the whole service
The Bank of England and FCA survey examines third-party AI use and additional evaluation considerations reported by firms. Its findings belong to financial-services respondents. For other small businesses, the transferable question is practical: which parts of the service does your vendor operate, and which depend on another provider?
A familiar product can rely on separate services for generation, storage or communication. That does not make the arrangement unsuitable. It does mean the business should understand who investigates when a customer-facing process stops working and what information is available during the interruption.
Map dependencies around the customer journey
Take one ordinary request from arrival to completion. Identify the supplier responsible for each step and any known upstream service supporting it. Keep the map focused on dependencies that affect operation, rather than collecting technical detail that staff cannot use.
Ask the vendor how changes to an upstream provider are communicated and whether they can materially alter behavior, availability or pricing. Record unanswered questions as purchasing uncertainties.
Do not mistake two interfaces for redundancy
Two applications may rely on the same upstream service. If the business buys both as a fallback, ask whether the relevant failure could affect them together. Genuine continuity depends on the independence of the critical path, not the number of logos in the subscription list.
A simpler manual fallback may be sufficient for a small workload. The important requirement is that staff can use it and later reconcile the work completed while the automated path was unavailable.
Rehearse a bounded outage
Temporarily withhold the assistant from a test workflow and have staff complete the important job through the agreed fallback. Check how unfinished requests remain visible and who tells customers about delays. Avoid a plan that depends on the unavailable system to explain how to recover from its own outage.
Record the time and effort required, along with any information staff could not retrieve.
Purchase clear responsibility
Compare vendors on incident communication, usable records and support ownership alongside feature quality. A supplier does not need to promise that nothing will fail. It should explain what the business can expect when a dependency does fail.
This dependency map is our procurement analysis, not a regulatory checklist. The financial-sector source motivates the question; the small business's own customer journey determines which dependencies matter and what continuity arrangement is proportionate to the work.