For most organizations, the bulk of their AI exposure does not come from models they train. It comes from vendors: foundation model APIs, AI features switched on inside existing SaaS platforms, specialized AI products for HR, finance or customer service, and service providers who use AI while delivering work for you. Yet many third-party risk programs still evaluate these suppliers with questionnaires designed for conventional software, asking about encryption and uptime while ignoring how the vendor’s model was trained, what it does with your prompts, and how its behavior will change next quarter.
This article explains why AI suppliers need a distinct due diligence approach, how emerging frameworks help, and provides a practical checklist you can adapt for procurement, onboarding and renewal.
Why Conventional Vendor Reviews Miss AI Risk
AI products differ from traditional software in ways that matter for risk:
- Behavior changes without a release. A vendor can swap or update the underlying model, alter system prompts or change retrieval sources, and output quality or safety shifts overnight even though your contract and integration stay the same.
- Your data can become their asset. Prompts, files and feedback may be retained, reviewed by humans or used to improve models unless contracts say otherwise.
- Supply chains are deep. An HR tool may rely on a model from one provider, hosted on another’s cloud, orchestrated by a third, with a fourth providing evaluation or moderation.
- Regulatory roles are shared. AI laws distinguish providers from deployers. Buying a system does not transfer your deployer obligations, such as human oversight, user transparency or impact assessment, to the vendor.
- Lock-in looks different. Fine-tuned models, embeddings, prompt libraries and evaluation datasets are derived assets that can be hard or impossible to move.
Frameworks That Make AI Due Diligence Easier
You do not need to invent your questionnaire from scratch. Several 2025–2026 developments provide structure.
CSA AI Controls Matrix and AI-CAIQ
The Cloud Security Alliance’s AI Controls Matrix (AICM) is a vendor-agnostic control framework for AI systems. Version 1.1, published in July 2026, contains 247 control objectives across 18 domains, including a model security domain covering threats such as poisoning, prompt injection and unauthorized model access. It defines implementation guidance by role, including model provider, application provider, orchestrated service provider, cloud service provider and AI customer. Its companion questionnaire, the AI-CAIQ, has 320 questions and can be used for self-assessment or third-party evaluation, and CSA’s STAR for AI program offers self-assessment and third-party audit levels. CSA also publishes mappings to ISO/IEC 42001, the EU AI Act and the NIST AI RMF. For buyers, the practical benefit is a common vocabulary: you can ask vendors for a completed AI-CAIQ rather than a bespoke spreadsheet.
ISO/IEC 42001
Vendors certified to ISO/IEC 42001 operate an audited AI management system, including controls over their own suppliers. Certification does not prove a specific product is safe, but it signals that governance processes exist and are periodically audited. Always check the certificate scope: it may cover one product line, not the service you are buying.
Public-Sector Acquisition Rules as a Benchmark
The US Office of Management and Budget memo M-25-22, “Driving Efficient Acquisition of Artificial Intelligence in Government,” issued in April 2025, offers a useful private-sector benchmark even if you are not a federal contractor. According to a PilieroMazza analysis, it directs agencies to restrict vendors from using non-public government data to train commercially available AI without explicit consent, to clarify ownership and IP rights, to require knowledge transfer and data and model portability to avoid lock-in, to include ongoing testing and monitoring terms and performance requirements, and to require vendors to notify agencies when they add new AI features to delivered systems. Those are sensible clauses for any buyer.
The most important AI contract clauses are the boring ones: no training on your data without consent, notice before model or feature changes, testing and monitoring rights, and a defined exit with portable data and derived assets.
Tier Your Vendors Before You Assess Them
Not every AI supplier needs the full treatment. Tier vendors first, so effort matches exposure:
- Tier 1 – High impact. AI that influences decisions about people (hiring, credit, insurance, healthcare, access to services), processes regulated or highly confidential data, or acts autonomously in core systems. Full due diligence, legal review and periodic reassessment.
- Tier 2 – Business critical. AI embedded in important workflows or customer-facing output, but with human review and no consequential decisions. Standard AI questionnaire and contract clauses.
- Tier 3 – Productivity. General assistants and tools used with internal or public data. Lightweight review focused on data use, retention and account controls.
The Due Diligence Checklist
Adapt the questions below to your tiers. For Tier 1 vendors, ask for evidence, not just answers.
1. Use Case and Regulatory Role
- What exactly does the AI do, and which decisions or outputs does it influence?
- Under relevant AI laws, is the vendor a provider, and are we a deployer? Does any customization we perform make us a provider?
- Which jurisdictions’ requirements has the vendor assessed (for example EU AI Act risk class, US state automated decision-making rules, Korea or Vietnam AI laws)?
- What documentation will the vendor give us to meet our own deployer obligations, such as instructions for use, limitations and transparency notices?
2. Model Provenance and Supply Chain
- Which models power the product, who provides them, and where are they hosted?
- Which subprocessors handle our data, including model providers, moderation and evaluation services?
- Will the vendor notify us before changing the underlying model or adding significant AI features, and can we test before the change reaches production?
- Are model cards, system cards or equivalent documentation available?
3. Data Use, Retention and Residency
- Are our prompts, files, outputs or feedback used to train or improve any model? Is the default opt-in or opt-out, and is it contractual?
- How long are inputs and outputs retained, including in logs and abuse-monitoring systems? Can retention be reduced to zero?
- Do humans at the vendor or its subprocessors review our data, and under what conditions?
- Where is data processed and stored, and can residency be guaranteed for regulated workloads?
- How is our data isolated from other customers in retrieval indexes, caches and fine-tuned models?
4. Security and Model Security
- Can the vendor provide a completed AI-CAIQ, ISO/IEC 42001 certificate, SOC 2 report or STAR for AI entry, and what do they cover?
- How does the product defend against prompt injection, including indirect injection through documents, emails and web content?
- What permissions do agentic features require, and can they be scoped to least privilege?
- How are API keys, OAuth tokens and connectors secured, and are actions logged in a way we can export?
- Has the product been red-teamed, by whom, and how are findings remediated?
5. Performance, Fairness and Testing
- What evaluation results exist for accuracy, robustness and, for decisions about people, bias across relevant groups?
- Can we run our own evaluations on representative data before go-live and after model changes?
- What monitoring does the vendor perform in production, and which metrics will they share with us?
- How are hallucinations, errors and harmful outputs reported, tracked and fixed?
6. Human Oversight and Transparency
- Does the product support human review, override and appeal for consequential outputs?
- Does it provide explanations or reason codes suitable for affected individuals?
- Does it support disclosure that users are interacting with AI and labeling of synthetic content, including machine-readable provenance?
7. Incidents and Accountability
- How and how quickly will the vendor notify us of AI incidents, including safety failures, data leakage and significant performance degradation?
- Does the vendor maintain an incident log, and will it support our own regulatory reporting?
- Who is the named contact for AI risk, and is there a local representative where laws require one?
8. Commercial Terms and Exit
- Who owns outputs, fine-tuned weights, embeddings, prompts and evaluation datasets created during the engagement?
- In what formats can data and derived assets be exported at termination, and within what timeframe?
- Is pricing transparent for tokens, usage tiers and overages, and are there protections against unilateral price changes?
- Are IP indemnities offered for generated output, and what are their limits?
- What are our audit and assessment rights?
Scoring Responses and Making the Call
Collecting answers is the easy part; turning them into a decision is where programs stall. Score each checklist section as meets, partially meets or does not meet, and define in advance which sections are non-negotiable for each tier. For a Tier 1 vendor, a refusal to commit contractually to no training on your data, or to notify you before model changes, should normally be a stop, while gaps in documentation might be acceptable with a remediation plan and deadline. For Tier 3 tools, data use and account controls usually matter most, and most other gaps can be accepted. Record the residual risks you accept, who accepted them and when they will be revisited. That record is what auditors and regulators will ask for, and it protects the business owner as much as the risk team. Finally, share the outcome with the vendor: suppliers often close gaps quickly when they know exactly what blocked the deal.
Embedding AI Diligence Into the Vendor Lifecycle
A checklist is only useful when it is wired into the processes that actually govern suppliers:
- Intake. Add AI screening questions to every procurement request: does this product use AI, will it process our data with AI, and will it influence decisions about people?
- Assessment. Route AI vendors by tier, request standard artifacts such as the AI-CAIQ, and involve legal, privacy, security and the business owner.
- Contracting. Maintain an AI addendum with standard clauses for training restrictions, change notification, testing rights, incident notice, and exit.
- Onboarding. Record the vendor’s AI systems in your AI register, configure retention and training settings, and set up monitoring.
- Ongoing monitoring. Reassess Tier 1 vendors at least annually and after material model changes; review release notes of strategic SaaS platforms for new AI features.
- Renewal and exit. Use renewals to close gaps, and rehearse data and asset export before you need it.
A Hypothetical Worked Example
Consider a hypothetical regional insurer evaluating an AI claims-triage product that reads claim documents, extracts key facts, flags potential fraud and recommends a handling route. Because it influences decisions about customers and processes health and financial data, the insurer classifies it as Tier 1.
Due diligence reveals that the vendor uses a third-party foundation model hosted in a different region from the insurer’s main operations, that default settings retain inputs for thirty days for abuse monitoring, and that the vendor updates its model quarterly without customer notice. The vendor provides an ISO/IEC 42001 certificate, but its scope covers a different product line. It offers fraud-detection accuracy metrics but no analysis across customer groups.
The insurer negotiates in-region processing, zero retention beyond operational needs, a contractual ban on training with its data, thirty days’ notice and a test window before model changes, quarterly sharing of performance and fairness metrics, and an exit clause that covers export of extracted data and evaluation sets. Internally, it designs human review of every fraud flag before action and adds the system to its AI register with the vendor’s change notices feeding its monitoring calendar. The product goes live a few weeks later than planned, but with controls the insurer can evidence to supervisors.
Common Pitfalls
- Accepting a certification without checking its scope against the service actually purchased.
- Ignoring AI features added to existing platforms, which bypass procurement entirely.
- Assuming the vendor carries your regulatory obligations; deployer duties stay with you.
- Failing to secure change notification, so you discover model swaps through user complaints.
- Neglecting exit planning until termination, when leverage is lowest.
Outlook to 2027
Standardized AI assurance is arriving quickly. As AI-specific questionnaires, ISO/IEC 42001 certifications and registry-based programs like STAR for AI mature, buyers will increasingly request artifacts rather than writing their own questions, and vendors that cannot provide them will lose deals. Expect contract templates to converge around the themes in public-sector rules, and expect regulators to look more closely at how deployers oversee AI they buy. Agentic products will push diligence further toward permission scoping, action logging and kill switches.
Conclusion
Third-party AI is where most organizations’ real AI risk lives. Tier your suppliers, use standard frameworks such as the AI Controls Matrix and ISO/IEC 42001 to ask better questions, lock in the clauses that matter most, and connect vendor diligence to your AI register and monitoring. Done well, AI due diligence becomes a repeatable procurement capability rather than a bottleneck, and it lets you adopt vendor innovation with confidence.
How Hanoi Technology Can Help
Hanoi Technology helps organizations design AI vendor tiering, due diligence questionnaires and contract addenda, and connect them to a living AI register.