On 14 September 2026, the UK Parliament’s Joint Committee on Human Rights published a report calling for a wide-ranging AI Bill and a single statutory oversight body with monitoring and enforcement powers. The headline for most readers is human rights. The detail that matters to a risk team is structural: the committee wants obligations to run across the AI lifecycle, so that designers, developers and deployers each carry due diligence proportionate to their role. Chair Alex Sobel MP put it plainly, saying new legislation is needed to deal with the entire AI supply chain.
That is recommendation, not law. But it describes a shape that third-party risk professionals will recognise at once. If accountability is spread across a chain of providers, models, data sources and deployers, then understanding that chain becomes a due diligence task, and due diligence across a supply chain is what TPRM exists to do.
Crest.Digital’s platform combines AI-assisted due diligence, continuous monitoring and evidence capture in one vendor lifecycle, so new risk categories can be added without starting again.
Explore the PlatformWhat the Committee Actually Proposed
The report’s main recommendations, as set out by the committee, can be grouped into four ideas. A risk-based framework would classify AI systems by level of risk and impose stricter requirements on the higher-risk ones. A single independent regulator would act as the central point for AI concerns, with powers to set codes of practice, require transparency and impose sanctions. Mandatory transparency would apply where a system has significant impact on individuals or communities. And certain applications would be prohibited outright. The supply chain point sits across all of this: duties follow the role an organisation plays, from building a system to putting it into use.
For global enterprises the lesson is not limited to the UK. The EU already takes a role-based approach in its AI Act, with different obligations for providers and deployers, and standards bodies are converging on lifecycle thinking. Our piece on regulatory compliance agents for AI governance looks at how timelines are shifting across jurisdictions.
Why This Looks Like TPRM Wearing a New Coat
Most organisations do not build frontier models. They buy them, embed them in tools they already use, or rely on suppliers who do. That makes the enterprise a deployer sitting at the end of a long chain, and deployers are exactly where proportionate due diligence would land. The risks are also third-party in nature: a vendor changes a model without notice, a subprocessor moves data to a new region, or a service concentrates dependence on one model supplier, a pattern examined in AI as a new category of critical third party.
Shadow adoption makes it harder. Teams sign up for AI features on their own, which creates vendors nobody has screened, as described in shadow AI as the new shadow vendor problem. A programme that cannot see these tools cannot assess them, so visibility comes before any module.
The AI Vendor Chain: Nine Links to Understand
Traditional vendor reviews ask who the supplier is, what they do and how secure they are. AI adds layers underneath. A useful way to structure the extra questions is to walk the chain from the vendor to the evidence, which also gives a clean HowTo for programmes that want to operationalise it.
AI Vendor
Identify the provider, its ownership and its financial and regulatory standing, using the same screening you apply to any critical supplier.
Model
Record which model or models power the service, their versions and how the vendor notifies customers of changes.
Training and Data
Ask what data trains and informs the system, where it comes from, whether your data is retained or reused, and what rights and consents apply.
Hosting
Capture where the service runs, in which regions and on which infrastructure provider, including concentration on a single cloud or model supplier.
Subprocessors
Map the downstream parties that touch your data or the service, then screen them as fourth parties.
Intended Use
Define in writing what the system may and may not be used for in your organisation, so risk is rated against real use rather than the sales deck.
Controls
Test the vendor's security, access, human oversight and testing controls, and look past certificates to scope and operating evidence.
Monitoring
Set continuous monitoring for change events, incidents, adverse media and posture shifts instead of relying on an annual review.
Evidence
Keep a retrievable record of what was assessed, what was decided, by whom and when, so the file stands up to a regulator, auditor or board.
Two points deserve emphasis. First, intended use is the link most often skipped, yet it decides how much risk a system carries: the same model can be low risk drafting internal summaries and high risk screening candidates. Second, controls need testing against scope. As we argued in why an ISO 42001 certificate does not mean AI is governed, the questions that matter are what the certificate covers and whether it covers the service you buy. Standards such as NIST’s AI Risk Management Framework and ISO/IEC 42001 help structure the vocabulary, but they do not replace due diligence on the specific service.
Building the AI Vendor Risk Module Without a Parallel Process
The sensible answer to “is AI vendor risk the next TPRM module?” is yes, provided it extends the programme instead of forking it. In practice that means four additions to what most teams already run.
What to Add to an Existing TPRM Programme
- An AI flag in inherent-risk tiering: Capture whether a vendor uses AI, what data it touches and what decisions it influences, so tiering reflects reality.
- Model, data and subprocessor questions: Extend due diligence beyond security to model versions, training data provenance and the downstream chain.
- Change-event monitoring: Treat a new model version, a new subprocessor or a changed data location as a trigger for reassessment, as we outline in AI vendor risk monitoring.
- Use-case records: Document intended use for each AI system and review it when the use changes.
Teams that already follow the approach in our guide to AI vendor due diligence will find most of this familiar. The shift is to make it routine and evidenced rather than a one-off questionnaire exercise, a point we make about questionnaires generally in why the questionnaire is the least interesting part of TPRM.
Where Agentic AI Helps, and Where Accountability Stays Human
Mapping nine links across hundreds of vendors is exactly the repetitive, document-heavy work that agentic AI handles well: reading vendor documentation and certifications, extracting model and subprocessor details, comparing claims with intended use, tracking change events and chasing missing evidence. What agents should not do is decide whether a vendor is acceptable for a given use. That remains a human-in-the-loop judgement, supported by a log of what was read, what was concluded and who approved it. Our article on why AI agents need audit trails covers this principle, and it applies as much to the agents running your due diligence as to the vendors you assess.
Crest.Digital’s Agentic AI workflows assist with due diligence and remediation tracking, with human approval and a full activity record. See how teams across industries apply them.
Five Moves to Make Now
A Short Playbook for Risk, Technology and Procurement Leaders
- Inventory AI and its vendors: Include embedded AI features and unsanctioned tools, not only contracted platforms.
- Tier by data and decision impact: Spend effort where AI touches sensitive data or consequential decisions.
- Extend the template: Add model, data, hosting and subprocessor questions to existing due diligence.
- Watch for change: Monitor model, subprocessor and location changes continuously.
- Keep evidence ready: Store assessments and approvals so they can be produced on request.
A final note on proportion. The committee’s report is a recommendation, the government has not committed to its shape, and rules in other jurisdictions will differ. Building visibility and evidence is worthwhile under almost any outcome. For more on how organisations measure the results of this kind of programme, see our business impact page and the overview of end-to-end vendor risk governance.
Crest Perspective
Risk programmes that treat third-party governance as a compliance checkbox are consistently underprepared when a material vendor incident occurs. The programmes that withstand regulatory scrutiny are not necessarily the most technologically sophisticated — they are the ones where risk tiering is documented, escalation paths are tested before they are needed, and the board receives accurate, timely information about the organisation’s most critical vendor dependencies.
Frequently Asked Questions
In a report published on 14 September 2026, the UK Parliament’s Joint Committee on Human Rights called for a wide-ranging AI Bill built on a risk-based framework, together with a single statutory oversight body holding monitoring and enforcement powers. It also said that actors across the AI lifecycle, including designers, developers and deployers, should carry out human rights due diligence proportionate to their role and the risks involved. Committee chair Alex Sobel MP said new legislation is needed to deal with the entire AI supply chain. These are recommendations to government, not enacted law, so organisations should treat them as a direction of travel rather than a current legal duty.
Not really. AI vendor risk is best treated as a specialised module inside an existing TPRM programme. The core questions are familiar: who is the provider, what do they process, who do they rely on, what controls operate and what evidence proves it. What changes is the depth needed in a few places, namely the model itself, the data used to train and run it, the hosting and subprocessor chain, and the way the system is used downstream. Programmes that already run inherent-risk tiering, due diligence, continuous monitoring and remediation tracking can extend them rather than build a parallel process.
A practical scope follows the chain from provider to evidence: the AI vendor and its ownership, the model and its version, the training and input data and where it comes from, the hosting environment and region, the subprocessors involved, the intended and permitted use, the controls the vendor operates, the monitoring you will run, and the evidence you will keep. Alongside that, ask contractual questions about incident notification, change notification when models are updated, audit rights and exit. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 give useful vocabulary for structuring these questions, but a certificate is a starting point, not a substitute for scoping the specific service you buy.
Start with visibility. Build an inventory of AI systems and the vendors behind them, including AI features embedded in tools already approved for other purposes. Tier them by what data they touch and what decisions they influence. Extend your due diligence template with model, data and subprocessor questions, record the intended use for each system, and set up monitoring for change events such as a new model version or a new subprocessor. Finally, keep evidence in a form that can be produced on request. If rules do eventually require proportionate due diligence across the AI lifecycle, much of the groundwork will already exist.
Agents can take on the repetitive work around the chain: reading vendor documentation and certifications, extracting model and subprocessor details, comparing answers to the intended use, tracking change events, chasing missing evidence and drafting a risk summary for review. Humans stay accountable for risk acceptance, for decisions on whether a vendor is suitable for a given use, and for the exceptions. Every agent action should be logged so a reviewer can see what was read, what was concluded and who approved it, which is the principle set out in our article on audit trails for AI agents.