Foundation Model Due Diligence

What this paper is for.

Foundation models are not a procurement item. They are a regulated dependency. Deployer obligations under EU AI Act, ISO 42001, NIST AI RMF and OSFI B-10 converge on a diligence artifact set the provider's sales team rarely produces. This paper walks the practitioner cut: provider assessment, training data posture, safety testing review, model card interpretation, contractual flow-down, and ongoing monitoring.

The takeaways our research desk stands behind.

• Model cards are necessary but rarely sufficient. Plan for a diligence questionnaire that probes training data provenance, sub-processor list, and safety evaluation methodology.
• EU AI Act Article 25 value-chain responsibilities and Article 53 GPAI obligations flow down to deployers through contractual terms. Default master service agreements are not sufficient.
• Responsible scaling frameworks (Anthropic, OpenAI, Google) are provider authored and unilaterally amendable. Treat them as inputs, not guarantees.
• Sovereign deployment configurations (OCI, Azure sovereign, AWS GovCloud, on-prem) carry distinct residual risk profiles that change the diligence posture.

What is inside.

1. Executive summary
2. Why foundation model diligence is not vendor diligence
3. Provider assessment: the five-layer stack
4. Training data posture: what to ask, what to accept
5. Safety testing: red teaming and evaluation maturity
6. Model cards, spec documents and their gaps
7. Responsible scaling and release policies
8. Contractual flow-down: EU AI Act Articles 25 and 53
9. B-10 third-party AI posture
10. Ongoing monitoring and change management
11. Sovereign and on-premise deployment options
12. Appendix: provider diligence questionnaire

Regulator and standards reach.

Keep reading.