AAISM lesson 8: AI vendors and supply chain

An AI vendor relationship differs from a normal software purchase in two ways: the vendor supplies behaviour that cannot be inspected like code, and that behaviour can change without the customer doing anything. Subtopic 2C of the AAISM outline covers this, and the supporting task is to embed, monitor and verify AI security requirements when using vendor AI-enabled solutions. It sits in the 31% risk domain because most organisations consume AI far more than they build it.

What the supply chain contains

A single assistant can depend on a foundation model from one provider, an embedding service from another, a vector database, a retrieval dataset licensed from a data broker, plugins or connectors to business systems, open-source libraries, and a cloud platform underneath. Each is a third party with its own weaknesses. The OWASP LLM list names supply chain as a risk in its own right, and ATLAS records techniques where tampered models or datasets are the way in.

Fourth parties matter too. A vendor that fine-tunes on a subcontractor’s data, or routes requests to another model provider, passes risk to the customer without the customer signing anything with that party.

Due diligence before signing

The questions fall into four groups.

A certificate such as an ISO/IEC 42001 certification or a security attestation shows that a management system exists; it does not show that a given model behaves safely for the intended use. Due diligence is also proportionate: a tool that summarises public web pages needs far less scrutiny than one that scores loan applicants.

Contract requirements

Contracts turn expectations into obligations. For AI services a practitioner looks for:

• a ban or an explicit opt-in on using customer data for training;
• advance notice of model changes, with the right to test before adoption or to stay on a version for a period;
• incident notification within a stated time, including model-related incidents such as a discovered poisoning or leakage;
• audit or assurance rights, or delivery of independent reports;
• sub-processor disclosure and flow-down of the same terms;
• exit terms covering data return and deletion, and what happens if the model is withdrawn;
• allocation of liability and intellectual property for outputs.

Legal drafting belongs to counsel; the security manager supplies the requirements and checks they are present.

Monitoring after go-live

Signing is the start. Ongoing work includes reviewing the vendor’s assurance reports each cycle, tracking vendor incidents and advisories, and running a fixed evaluation set against the live service so that a silent model update shows up as a measurable change. Service levels cover availability, so behaviour needs its own measures. Findings feed the risk register and vendor reassessment; the triggers are the same as for any other risk (see AI governance and risk).

Concentration risk arises when many processes depend on one provider, one model family or one cloud region. A provider outage, price rise, policy change or withdrawn model then hits everything at once. Responses include a documented fallback (an alternative model or a manual process), an abstraction layer that makes switching feasible, and a register that shows which business processes depend on which provider.

Worked example

A 400-person insurer wants a claims-summarisation service from a start-up that wraps a large third-party model. The start-up’s questionnaire answers are strong, but two points stand out: customer text is kept for 90 days “to improve quality”, and the underlying model provider is not named. The security manager requires a no-training clause, retention reduced to what is operationally needed, disclosure of the model provider as a sub-processor, and notice of model changes. Because claims summaries inform payment decisions, the insurer also requires a fixed test set rerun monthly and a manual fallback process. The vendor is classed as high criticality, so it is reviewed annually and after any reported incident.

Easy to confuse

• Vendor certification vs model assurance. One is about the organisation’s processes; the other is about how the model behaves in your use.
• Availability SLA vs behavioural stability. A service can be fully available while its answers get worse.
• Sub-processor vs fourth party. In practice the same relationship seen from two sides: a sub-processor handles your data for your vendor; fourth party is the risk vocabulary.

Key points

• List every third-party component, including data, plugins and the platform beneath.
• Origin, integrity, data handling and assurance are the four due diligence groups.
• Contracts must cover training use of data, change notice, incident notice and exit.
• Monitor behaviour with a fixed test set, not only uptime.
• Concentration risk needs a mapped dependency list and a fallback.

Check yourself

This lesson covers subtopic 2C of Domain 2, AI Risk Management (31%); the recap is at risk management explained.