Foundation model due diligence — what a regulated deployer must now produce.

The deployer is the accountable party. Diligence is non-delegable.

Every regulatory regime the firm reads converges on the same position when a foundation model is brought into a regulated workflow. The deployer — the bank, the insurer, the dealer, the payer — is the accountable party for the outcome. The model provider supplies the capability; the deployer supplies the control environment, the intended use, the human oversight and the record. A regulator that finds a material failure does not ask why the model behaved that way. It asks what the deployer knew, at procurement, about the risk. The diligence file has to answer that question in writing, dated to the moment of onboarding.

Provider diligence — four planes to evaluate.

The provider-diligence package we see work in practice reads across four planes. The corporate and governance plane: ownership, control, sanctions exposure, jurisdictional posture, incident history, Responsible Scaling or equivalent published commitments. The security plane: SOC 2 or ISO 27001 attestations scoped to the inference infrastructure, penetration test summaries, vulnerability-handling posture, key-management architecture. The AI-specific plane: published safety evaluations, red-team records, bias and robustness testing, documented release-gating criteria, model-spec or usage-policy disclosures. The supply plane: sub-processor list, training-infrastructure footprint, operational resilience posture. A deployer that has not gathered these four cannot defend the choice of provider at examination.

Training-data posture — what you can say, and what you cannot.

The training-data conversation is the most asymmetric in the procurement. The provider typically cannot produce the training corpus; the deployer has to be able to record what the provider will attest to. The firm’s read is that a defensible posture covers five points. A description of the training-data categories at a level the regulator recognises. A statement on copyrighted-content handling and the provider’s IP indemnification posture. A statement on personal-data exclusions and any processes that address deletion requests. A statement on the provider’s treatment of opt-outs, common-crawl sources, and any jurisdiction-specific exclusions. And the change-notification covenant — how the deployer learns when the corpus shifts. The file is incomplete without all five.

Safety-testing review — reading the evaluation that the provider publishes.

Most providers now publish some form of safety-evaluation record — model cards, system cards, evaluation appendices, red-team summaries. Reading these is not a formality. The deployer’s review has to map the evaluated capabilities to the intended use, identify the capabilities the evaluation did not cover, and flag the residual risks that the deployer will carry. Where the provider’s evaluation is thin on a capability the deployer depends on — long-context reasoning in a particular domain, tool-use safety, multilingual fidelity — the deployer has to commission or document its own evaluation. The evaluator’s memo is the artifact that closes the loop, and it sits in the same file as the provider documentation.

Contractual flow-down — the clauses that carry the posture.

The contract is where the governance posture becomes enforceable. The flow-down clauses that now appear, at a minimum, cover incident notification with defined timeframes, change-notification for material model or policy updates, evidence-production on regulator request, audit rights (direct or delegated), sub-processor notification, copyright and trade-secret indemnification, data-residency commitments, and the security-control floor. The EU AI Act’s GPAI obligations give some of this statutory weight. OSFI B-10 makes the procurement review a supervisory matter. The revised Product Liability Directive makes disclosure a civil-procedure matter. The contract that predates these regimes is almost certainly underclaused; renewal is the opportunity to refit.

Composing the file — provider-level and use-case-level.

The diligence file lives at two levels. The provider-level file — the four-plane assessment, the training-data posture, the safety-testing review, the contract — is produced once and maintained against change. The use-case-level file — the deployer’s intended-use statement, risk tiering, human-oversight architecture, validation posture, monitoring plan and incident runbook — is produced per deployment and joined to the provider file at examination. The separation matters. The provider file does not depend on the use case; the use-case file does not have to re-litigate provider questions. Composing the two produces the artifact the regulator, the auditor and the downstream customer all read at examination and renewal.

Our foundation model due diligence playbook walks the four phases — provider diligence, training-data posture, safety-testing review, contractual flow-down — and produces the artifact set: provider assessment, model card excerpt, residual-risk memo, contract addendum. The firm maintains the file against change; the deployer retains ownership. That is the shape a regulated deployer has to be able to produce now, and the shape every forthcoming regime will ratify.