Third-Party and Vendor Assurance

For most enterprises, the majority of AI risk now sits behind someone else's interface. You do not hold the weights, you cannot inspect the training data, you did not choose the safety layer, and you may not even be told when the model changes. Vendor assurance is therefore not a subsidiary topic in AI governance; for many firms it is the topic. The practical question is which levers actually produce assurance and which are negotiating theatre.

Contract terms that carry assurance weight

• Data handling. Explicit limits on retention of your inputs and outputs, and an explicit prohibition on using your data, prompts or outputs to train or improve the provider's models. This is the single term most likely to be quietly permissive in a standard agreement.
• Model change control. Advance notification of model version changes, with the ability to pin a version or delay migration. Without it, the system you validated can be replaced under you between one request and the next.
• Incident notification. Defined incident and breach notification duties with timelines that explicitly cover model-behaviour incidents, not only security breaches. A clause scoped to unauthorised access will not oblige anyone to tell you the model started producing something harmful.
• Rights to evaluate: permission to run your own evaluation battery against the service, and access to evaluation artefacts and system documentation rather than marketing summaries.
• Subprocessor and processing-location transparency, with notice of change, since your own obligations often flow through to wherever the data is actually processed.
• Deprecation notice periods and exit terms, including return and deletion of data, because a sudden end-of-life for a model version is an availability and continuity event.

What a security attestation does and does not cover

A vendor answers your AI due-diligence questionnaire by attaching a System and Organization Controls report of the Type II kind, commonly referred to as SOC 2 Type II, or an information security management system certification. These are genuinely useful documents and it is important to be precise about their scope. Such a report tells you that an independent auditor examined the vendor's control environment, and that controls over access to production, change management and similar operational concerns were designed appropriately and operated effectively over a defined audit window. That is real evidence about the organisation running the service.

It follows that vendor questionnaires should be split. One section covers the organisation and can be satisfied by attestations. A separate section covers the model and the deployed service, and can only be satisfied by evaluation evidence, documentation of guardrails and mitigations, a description of the change and deprecation process, and your own testing. A vendor that answers behavioural questions with an organisational attestation is not necessarily being evasive; frequently nobody on either side has noticed that the question and the answer are about different things. Noticing is your job.

Finally, due diligence at onboarding is a point-in-time act, and vendor risk is continuous. Attestation windows expire and bridge letters cover only the gap. Model versions change on the provider's schedule. Subprocessors are added. The vendor's own suppliers change. Build reassessment triggers into the relationship: on renewal, on notified model change, on incident, and on a period proportionate to the tier of the systems that depend on the vendor.