Starting August 2, 2026, the European Commission gains enforcement power over Article 53 of the EU AI Act, the provision requiring every general-purpose AI model provider to maintain technical documentation, share model information with downstream integrators, and publish a training data summary. That date has quietly reshaped what a foundation model vendor review needs to cover.
Most organizations still run these vendors through the same questionnaire they use for a payroll platform, asking about encryption and SOC 2 reports while skipping the questions that actually determine regulatory exposure. Foundation model vendor risk assessment sits at the intersection of procurement, AI governance, and model risk management, and it needs its own question set, mapped to the specific ISO 42001, EU AI Act, and NIST AI RMF requirements that justify asking it.
Why Foundation Models Need a Different Risk Review
A standard SaaS vendor review answers one question: can we trust this company with our data. A foundation model vendor review has to answer three more. What is the model doing with the inputs it receives. What was it trained on, and does that training carry legal or bias exposure your organization now inherits. And what happens when the vendor updates the model without telling you.
That last point trips up more compliance teams than any other. A traditional software vendor ships a new version and you can read the changelog. A foundation model provider can silently update weights, fine-tuning data, or safety guardrails, and your downstream application behaves differently the next morning with no code change on your end. According to an implementation guide from Mitratech’s analysis of the NIST AI RMF, the framework builds third-party accountability into three specific categories: GOVERN 6 for policies covering third-party software and data, MAP 4 for mapping risk across all AI system components including third-party ones, and MANAGE 3 for managing risks and benefits from third-party entities. None of those categories exist in a generic vendor security framework, because none of them apply to static software the way they apply to a model that can drift.
There’s a scope question worth settling early, too. Foundation model vendor covers two different relationships: buying direct API access to a frontier model, and buying a smaller vendor’s application built on top of one. The second case is more common and more often mishandled, because the wrapper vendor rarely volunteers which foundation model sits underneath, what your submitted data gets used for, or whether prompts flow through additional sub-processors. Your question set needs to work for both, which means asking about the underlying model even when the vendor in front of you isn’t the one who built it.
Where This Fits: ISO 42001, EU AI Act and NIST AI RMF Side by Side
No single framework gives you a complete foundation model vendor review. Each one covers a different slice, and the gap between them is exactly where most reviews fail. ISO 42001 tells you what to document about the relationship. The EU AI Act tells you what the vendor is legally obligated to disclose. NIST AI RMF tells you how to fold the whole exercise into your broader risk operating model. Mapped clause by clause, both the overlap and the gaps become visible.
Cross-framework mapping: foundation model vendor risk
| Governance Question | ISO/IEC 42001 | EU AI Act (Reg. 2024/1689) | NIST AI RMF 1.0 |
|---|---|---|---|
| Must suppliers be formally assessed before use? | Annex A.10.3: supplier selection, evaluation, and monitoring process | Article 53(1)(b): downstream provider documentation obligation on the vendor | GOVERN 6.1: policies for third-party software, data, and services |
| Who documents roles and responsibilities? | Annex A.10.2: stakeholder responsibility allocation | Article 25: allocation of obligations along the AI value chain | MAP 4.1: risk mapped across all system components, including third-party |
| What must the vendor disclose about the model? | Annex A.6/A.7 data governance, referenced in supplier due diligence | Article 53(1)(a) technical documentation (Annex XI); Article 53(1)(d) training data summary | MAP 1.1, MAP 5.1: context and impact of third-party components |
| How is the relationship monitored after approval? | Annex A.10.3 ongoing monitoring requirement | Article 53(3): cooperation duty with regulators, ongoing | MANAGE 3.1, MANAGE 3.2: third-party risk and benefit management, continuous |
| What if the vendor is a systemic-risk model? | Not addressed directly (general AIMS scope) | Article 55: adversarial testing, incident reporting, cybersecurity for models above 10^25 FLOP | MEASURE 2.7: AI system security and resilience evaluation |
The pattern worth noticing: ISO 42001 gives you the process, the EU AI Act gives you the legal floor for what the vendor owes you, and NIST AI RMF gives you the operating cadence. A vendor review built on only one of these will either be under-documented for audit purposes, missing the legal disclosure requirements or missing the ongoing monitoring discipline.
Govern365.ai‘s clause-level mapping keeps all three current in a single register, so when a framework updates, you can see exactly which vendor review questions need to change instead of re-deriving the mapping from scratch.
Model Transparency and Documentation Questions
Ask these before anything else, because the answers determine how much additional scrutiny the rest of the review needs.
- Which specific foundation model, including version number, underlies this product, and how will we be notified before that model changes or is deprecated?
- Can you provide a model card covering intended use, known limitations, and evaluated failure modes?
- What training data sources were used, and is there a documented process for handling copyright opt-outs under the text-and-data-mining provisions of EU copyright law?
- Is the model released under an open-source license, and if so, does it meet the Article 53(2) exemption criteria, or does systemic-risk status remove that exemption?
- Do outputs remain consistent across identical inputs, or is there meaningful non-determinism we need to account for in downstream validation?
Most vendors can answer questions one and two without friction. Question three is where the review usually stalls. Under Article 53’s four baseline obligations, every general-purpose AI model provider must implement a copyright compliance policy respecting text-and-data-mining opt-outs and publish a training data summary using the AI Office’s mandatory template, yet a large share of vendors, particularly smaller ones building on top of a frontier model rather than training their own, cannot produce this documentation because they never had to generate it themselves.
That is a legitimate finding, not a disqualifier. It tells you the obligation sits one layer up, with the foundation model provider, and your contract needs to require the vendor to pass that documentation through.
Regulatory Standing and Provider Obligation Questions
This section separates vendors who understand their EU AI Act position from vendors who are guessing.
Ask whether the vendor has determined if it qualifies as a GPAI model provider under Article 3(63), and if so, whether its model crosses the 10^25 FLOP systemic-risk threshold under Article 51. That threshold matters more than it looks. Per the AI Act’s general-purpose AI provisions, Article 55 adds obligations for systemic-risk GPAI models that don’t apply to smaller models at all, including model evaluation with adversarial testing and systemic-risk mitigation. A vendor that can’t answer this question hasn’t done the legal analysis your compliance file will eventually need.
Ask whether the vendor has signed the GPAI Code of Practice. The Code, as described in a EU AI Act Newsletter briefing on its rollout, lets providers who voluntarily adopt it demonstrate AI Act compliance while reducing administrative burden and gaining legal certainty compared to other compliance routes. A signed vendor gives you a documented compliance pathway to point to during your own audit. An unsigned vendor isn’t automatically non-compliant, but the burden shifts to you to independently verify their obligations are met, which is more work and more risk.
Ask directly: as of August 2, 2026, is your organization prepared for AI Office enforcement of Article 53 obligations, and what happens to our contract if a compliance gap surfaces after that date. Vendors who haven’t thought about this yet will tell you so in how they answer.
Vendor risk does not end at procurement. Organizations also need LLM change management processes to assess how model updates, version changes, and provider changes could affect an approved system.
Data Handling, Security and Sub-Processor Questions
This is the section that overlaps most with a traditional vendor security review, with AI-specific additions layered in.
Confirm whether your prompts, inputs, or uploaded documents are used to train or fine-tune the model, and whether that setting is contractually guaranteed rather than a togglable default. Ask for the full sub-processor list, including any additional foundation model providers the vendor routes traffic through, since Nth-party exposure is where most foundation model risk actually hides. Ask what the incident notification timeline looks like specifically for model-level issues, not just data breaches, since a jailbreak or a hallucination-driven customer-facing failure often falls outside a standard breach clause entirely.
One detail generic questionnaires miss: does the vendor’s incident response plan distinguish between a security incident and a model behavior incident. The two require different remediation paths, and a vendor whose plan only covers the former hasn’t fully mapped its own risk surface.
Governance and Human Oversight Questions
ISO 42001’s supplier domain exists for a specific reason. As explained in a practical guide to the standard’s Annex A controls, Annex A.10 helps an organization ensure responsibilities are distributed between itself, its partners, suppliers, and customers, with A.10.3 specifically requiring a process to ensure the use or development of the AI system aligns with the organization’s approach to responsible AI. In practice, that translates into questions about who is accountable when the model produces a harmful or incorrect output in a customer-facing context, and whether the vendor supports the human-in-the-loop review points your own governance program requires.
Ask whether the vendor’s product allows you to log and export decision records where the model’s output influences a business decision. If it doesn’t, and the use case is high-risk under your internal risk tiering, that’s a real constraint, not a nice-to-have gap. An AI model registry that automatically flags which vendor integrations lack decision-logging capability saves a governance team from discovering this during an audit instead of during procurement.
Turning Vendor Answers Into an Approval Decision
A completed questionnaire isn’t a decision. It’s an input to one, and the step most organizations skip is converting answers into a risk tier that determines what level of sign-off the vendor actually needs.
A workable three-tier structure: Tier 1 covers internal-only, non-customer-facing use of a well-documented frontier model with no fine-tuning on your data, approvable at the governance team level. Tier 2 covers customer-facing use, or any use involving personal data, requiring legal and security sign-off in addition to governance review. Tier 3 covers high-risk use under the EU AI Act’s Annex III categories, or any use where the vendor could not produce adequate model documentation, requiring executive and, where applicable, board-level visibility before approval.
The tiering decision should hinge on three factors pulled directly from the questionnaire: whether the vendor could produce model documentation, whether personal or sensitive data flows into the model, and whether the vendor’s own regulatory position under Article 53 is settled or unresolved. A vendor that fails all three isn’t necessarily rejected, but it moves to Tier 3 and the approval conversation changes accordingly.
Vendor due diligence should also consider whether the provider can supply reliable LLM evaluation evidence before a new model version is approved for production.
Contract Terms and Ongoing Monitoring After Approval
Approval is a snapshot. Foundation models change, and your contract needs to survive that change. Three provisions are worth negotiating specifically for foundation model vendors rather than relying on standard SaaS contract language: advance notice before a material model change or version deprecation, a right to audit or request updated model documentation on a defined cadence, and a defined incident notification SLA that explicitly covers model behavior issues, not only security breaches.
A supplier management guide from Knowlee’s ISO 42001 controls checklist puts it plainly: third-party AI systems need to be monitored after deployment, not just assessed at procurement, with review frequency defined based on risk level. That means the Tier 3 vendor from your approval decision needs a shorter re-review cycle than the Tier 1 vendor, not the same annual check-in applied uniformly across every AI vendor on your books. A compliance dashboard that tracks each vendor’s re-review date against its assigned risk tier turns this from a spreadsheet someone forgets to update into a scheduled control with an owner.
Frequently Asked Questions
What’s the difference between a foundation model vendor and a regular SaaS AI vendor?
A foundation model vendor either provides direct access to a large pretrained model or builds a product on top of one. The distinction matters because foundation models can update without your knowledge, carry training-data provenance questions a typical SaaS tool doesn’t, and may trigger EU AI Act GPAI obligations that don’t apply to conventional software.
Do I need to assess a vendor if they only use a foundation model internally, not customer-facing?
Yes, though the tier and depth of review should be lighter. Internal use still carries model drift risk, data handling exposure, and potential bias in outputs that inform business decisions, all of which belong in your AI system inventory regardless of whether customers ever see the output.
What if the vendor won’t share their model card or training data summary?
Treat this as a material finding, not an automatic disqualifier. Under Article 53, providers must make training data summaries available, so refusal may signal the vendor hasn’t met its own obligations. Document the gap, raise the risk tier, and consider requiring the disclosure as a contract condition before renewal.
How often should foundation model vendors be re-reviewed?
Tie the cadence to risk tier rather than a fixed calendar. High-risk or customer-facing vendors warrant review every six months or after any material model change; lower-risk internal tools can move to an annual cycle, provided the vendor commits to proactively notifying you of model updates.
Does ISO 42001 certification from the vendor satisfy our own supplier due diligence obligation?
It’s strong evidence but not a full substitute. ISO 42001 certification shows the vendor operates a functioning AI management system, which should reduce the depth of your own review, but you still need vendor-specific answers on data use, sub-processors, and contractual terms that certification alone doesn’t cover.
Is NIST AI RMF compliance legally required for foundation model vendors?
No. NIST AI RMF is voluntary, but it’s increasingly referenced by regulators, including the FTC, CFPB, and SEC, as an expected baseline, and many enterprise customers now require vendors to map their practices to it as a condition of the relationship.
What happens if a vendor’s foundation model is later found to be a systemic-risk model under Article 51?
The vendor takes on additional Article 55 obligations, including adversarial testing and incident reporting. Your organization should have a contract clause requiring notification of this reclassification, since it may change your own risk tier and required oversight level for that vendor.
Conclusion
Foundation model vendor risk isn’t a bigger version of a SaaS questionnaire. It’s a different kind of question entirely, one that asks what a vendor’s model was trained on, what happens when that model changes, and who bears the regulatory exposure when it does.
The organizations that get this right treat the vendor review as the first entry in an ongoing record, not a one-time gate. Start by mapping your current AI vendor list against the questions above and flag anywhere a vendor could not produce model documentation. Govern365.ai’s AI model registry and clause-level cross-framework mapping keep that record current across ISO 42001, the EU AI Act and NIST AI RMF as each one evolves. Start your 14-day free trial of Govern365.ai
