AI Vendor Risk Assessment UK: How to Assess Your AI Supply Chain

Most organisations already run a competent third-party risk process for software vendors. Then they buy an AI tool, send it through the same questionnaire, receive a completed SIG Lite and a SOC 2 report and approve it. The process worked exactly as designed and caught almost nothing that matters.

An AI vendor risk assessment UK organisations can rely on has to ask different questions, because the failure modes are different. Traditional vendor assessment asks how a supplier protects data at rest, who can access it and what happens if they suffer a breach. Those questions remain valid. They simply do not cover a model trained on data of unknown provenance, an API that will follow instructions hidden inside a document your staff upload, or an integration you granted read access to a mailbox eighteen months ago and never reviewed.

Why AI vendor risk behaves differently

The short answer: with conventional software, the vendor controls the code and you control the data. With AI systems, the boundary blurs in both directions.

Your data may influence the vendor’s model. Their model shapes decisions inside your organisation. The system’s behaviour is probabilistic rather than deterministic, so “we tested it and it worked” does not carry the assurance weight it does elsewhere. The supply chain also runs deeper than one contract, because the vendor you assessed has almost certainly built on a foundation model, fine-tuning datasets and open-source components supplied by parties you have never named.

This matters most where the AI is embedded rather than bought. A case management platform quietly adds a summarisation feature. A recruitment tool starts ranking candidates. No procurement event took place, so no assessment was triggered and your AI supply chain expanded without anyone recording it.

The four attack vectors worth assessing against

AI supply chain security concerns are not unbounded. Four vectors account for most of what we see in practice, and a competent assessment framework should map to each.

Compromised third-party models and datasets. Models pulled from public repositories can carry malicious code in their serialisation format or behaviour deliberately trained in. If your vendor cannot tell you which base model they used and where it came from, they cannot tell you whether it is clean.

Poisoned training data. An attacker who influences training or fine-tuning data can shape model outputs in ways that only appear under specific conditions. This is difficult to detect after the fact and near-impossible to detect without provenance records, which is precisely why provenance belongs in the assessment.

Shadow prompting through vendor APIs and documents. Instructions embedded in content the model processes, a supplier invoice, a CV, a web page it retrieves, can redirect the system’s behaviour. This is prompt injection arriving through a third party. The organisation did not issue the instruction and often has no log showing that it was followed. Where a vendor’s AI reads untrusted external content, this vector is live by default.

Over-permissioned integrations. The commercial pressure during onboarding is to grant broad access so the tool demonstrates value quickly. Six months later that integration retains mailbox, file store and ticketing permissions that no one has revisited. Compromise the vendor and you have compromised a privileged identity inside your estate.

Start with an AI Bill of Materials

You cannot assess a supply chain you have not mapped. An AI bill of materials, or AI-BOM, is a catalogue of every AI component, model, dataset and third-party AI service in use across the organisation, including the ones embedded in tools already approved for other purposes.

A usable AI-BOM records, for each component: what it does, which business process depends on it, the underlying model or provider where known, what data flows into it, what permissions it holds and who owns it internally. Discovery is the hard part. Procurement records will show the deliberate purchases; they will not show the AI features switched on inside existing platforms, and they will not show the tooling staff adopted independently.

The AI-BOM is not a compliance artefact for its own sake. It is the input to everything downstream, because it tells you which vendor relationships actually carry risk and therefore which ones justify assessment effort.

A practical assessment checklist

For each AI vendor that matters, we work through four areas.

• Data handling during training and inference. Is our data used to train or improve their models, and can that be contractually excluded? Where is inference processed, and under which jurisdiction? How long are prompts and outputs retained, and who inside the vendor can read them?
• Model provenance. Which base model underpins the service? What fine-tuning has been applied and on what data? How are model updates communicated, and can we decline or delay one that changes behaviour in a process we depend on?
• Monitoring and alerting on outputs. What does the vendor monitor for, and what will they tell us about? Can we obtain logs of prompts and responses in a form our own monitoring can consume? Anomalous AI behaviour is invisible unless someone is watching output patterns rather than uptime.
• Incident response for AI-specific failures. A model producing confidently wrong output at scale is an incident, and most vendor incident response plans do not treat it as one. Ask what triggers their process, what their notification timeframe is for a model-level issue, and what rollback options exist.

Point-in-time assessment is not sufficient

The assessment you completed at onboarding described a system that no longer exists. Models are retrained, capabilities are added, permissions accumulate and the vendor’s own supply chain shifts beneath them. AI third-party risk requires continuous monitoring of the workflows themselves: what data is moving to which AI services, which integrations hold which permissions and whether output behaviour has drifted. Annual reassessment on a spreadsheet cycle will report on last year’s system.

Key questions on AI supply chain risk

Where should we start if we have no AI-BOM at all?

Start with discovery rather than assessment. Identify which AI services staff and systems are actually using, including features embedded in approved platforms. A partial catalogue you trust is more useful than a complete one you assembled from procurement records alone, because the unrecorded usage is usually where the risk sits.

What if a vendor refuses to answer provenance questions?

Treat the refusal as the finding. A vendor unable to describe their base model, fine-tuning data or update process is telling you they cannot evidence control over their own supply chain. That does not automatically disqualify them, but it should change the risk rating and the compensating controls you require.

Who should own AI vendor assessment internally?

It works best where existing third-party risk ownership sits, with AI-specific expertise brought in to shape the question set. Creating a parallel process alongside vendor risk management tends to produce two incomplete registers rather than one reliable one.

How does this relate to the assessments we receive from our own clients?

The same control evidence answers both directions. Provenance records, permission registers and output monitoring that satisfy your assessment of a vendor are what your clients will ask you to demonstrate.

If you need to establish this properly, our AI Security Gap Analysis covers third-party AI risk as a discovery area and will tell you where your current vendor process falls short. Where the work is scoped and bounded, an AI Security Project can deliver the supply chain review and AI-BOM directly. Contact us to discuss which fits your position.