60 Seconds on Tech & Sourcing: Key Considerations for Multi-Vendor AI Solutions

As AI offerings mature, multi-component solutions have become increasingly common. These solutions typically combine one or more foundation models with additional data sources to create user-facing tools, such as AI-enabled chatbots. While customers are accustomed to the traditional “one-throat-to-choke” model of the prime-subcontractor relationship, where a single accountable vendor stands behind the entire deliverable, multi-vendor AI solutions complicate that expectation, because the prime contractor frequently depends on third-party foundation models and data sources it does not fully control. Accordingly, the diligence process and the underlying agreements for these solutions should address the following risks and pitfalls.

Data Leakage Risk

Multi-model AI solutions necessarily involve multiple vendors, each of which processes and/or accesses customer data. IT teams involved in diligence should ensure that data flows are clearly mapped so they know which vendors are processing data, what data is being processed and where that processing occurs. A key diligence question is whether the prime contractor and its downstream (or upstream) providers are using closed enterprise solutions or public AI models. To mitigate data leakage risk, closed enterprise solutions are preferred over public models throughout the tech stack. This matters because, as more vendors touch customer data, the risk of leakage grows, and even where an agreement contains strict limitations on downstream use, a prime contractor relying on public models may not be able to pass those restrictions through to its foundation model licensors. 

Aggregated Data Considerations

AI vendors often seek broad rights to aggregate de-identified customer data across their customer base, and to use and monetize that aggregated data. Vendors are frequently willing to agree that aggregated data will be used only to improve the products their customers are actually using, but downstream data aggregation deserves equal scrutiny. Where a solution is built on third-party foundation models, customers should consider requiring the prime contractor to prohibit its foundation model licensors from using any customer data (whether or not aggregated or de-identified) to train public-facing AI models. Without such a restriction, customer data disclosed for a limited purpose to a tool’s licensor could end up in the pool of data used to train the underlying foundation models. 

Liability for Compliance with AI Laws

Vendors licensing AI tools built on third-party foundation models may seek to limit their legal compliance obligations. A vendor may be willing to agree to compliance obligations with respect to its own tool, but may decline to warrant that the underlying foundation models are compliant with applicable laws. Customers should therefore consider how best to allocate compliance obligations across the full technology stack in multi-model, multi-vendor solutions, rather than assuming the prime contractor stands behind the entire chain. 

Output Errors

Similarly, while vendors may be willing to address output errors and hallucinations arising from the components they control, they may disclaim responsibility for outputs generated by foundation models they do not control. As with traditional prime-subcontractor relationships, AI contracts should properly allocate responsibility among the parties for AI output errors, including for third-party components the vendor is merely licensing. 

Audit Rights

Customers routinely seek broad audit rights to ensure their data is properly secured, while vendors often seek to limit those rights. In multi-vendor solutions, customer audit rights frequently do not extend to the providers of the foundation models, and both the diligence assessment and the contract should recognize this limitation in scope. At a minimum, customers should seek commitments from their contracting partner to make good-faith efforts to enforce audit rights against subcontractors, or to provide the reports and attestations that the foundation model providers make available. 

Key Takeaways

• Map the data flows. Confirm which vendors touch customer data, what data they process, and whether each layer relies on closed enterprise or public models.
• The “one-throat-to-choke” model breaks down. A prime contractor often cannot pass strict data, compliance and audit obligations through to the foundation model providers it depends on, so identify where accountability actually stops.
• Close the training-data loophole. Address both direct and downstream aggregation, and expressly prohibit use of customer data to train third-party or public-facing foundation models.
• Allocate compliance and error correction across the whole stack. Do not assume a vendor’s tool-level warranties extend to embedded foundation models or other third-party components.
• Build in fallback audit mechanisms. Where direct audit rights against subcontractors are unavailable, secure good-faith enforcement commitments plus reports and attestations from foundation model providers.