Your vendor risk questionnaire was built for SaaS. It asks about SOC 2 Type II, encryption at rest, data residency, sub-processor lists, and breach notification timelines. In 2026 it is no longer fit-for-purpose. AI vendors carry obligations no SaaS vendor ever carried: EU AI Act Article 25 transfer triggers, Annex IV technical-file deliverables, Article 47 declarations of conformity, GPAI Code of Practice signatory status, Annex XII downstream-deployer receivables, NIST AI RMF Measure 2.7 red-team evidence, model-card minimum requirements, and SOC 2 + AI scope attestations from a handful of attestation firms. This is the lesson where a Vendor Risk Director who has been told "we just bolt AI questions onto the existing questionnaire" finds out the AI-specific diligence is a different artifact entirely, mapped to ISO 42001 A.10 third-party relationships and the EU AI Act Article 25 provider-transfer clause the way the existing questionnaire is mapped to SOC 2. This lesson is the AI vendor risk policy, the 30-to-40-question questionnaire across six sections, the model-card minimum requirements, the SOC 2 + AI scope expectations, the EU declaration of conformity status check, and the OpenAI / Promptfoo M&A example showing why static questionnaires fail.

Why an AI-Specific Vendor Risk Policy in 2026

The traditional vendor risk questionnaire, SOC 2 Type II + data processing addendum + sub-processor list + breach notification SLA, was built for a world where the vendor's product was a database, an API, or a SaaS application. The AI vendor in 2026 is a different animal. The product is a model. The model was trained on data the vendor will not fully disclose. The model's behavior is non-deterministic. The model is subject to a regulatory regime, the EU AI Act, that imposes specific cooperation, disclosure, and documentation obligations on the provider that the customer must verify. The model may carry GPAI status that triggers Article 53 obligations. The model may carry systemic-risk status that triggers Article 55 obligations. The vendor may be a signatory to the GPAI Code of Practice (Anthropic, Google, OpenAI, Microsoft, Mistral) or a non-signatory (Meta, xAI), the signatory status materially changes the customer's downstream diligence work. The model may be subject to substantial modification on the customer side that triggers Article 25(1)(b) transfer of obligations to the customer. None of this fits the SOC 2 questionnaire structure.

The AI-specific vendor risk policy is the procurement-side artifact that closes this gap. Anchored to ISO 42001 Annex A control A.10 (third-party relationships) and the EU AI Act Article 25 provider-transfer clause, the policy specifies a 30-to-40-question AI-specific questionnaire across six sections, the model-card minimum requirements, the SOC 2 + AI scope attestation expectations, the EU declaration of conformity status check where applicable, the procurement-contract clause checklist, the tiered diligence depth aligned to vendor risk tier, and the refresh cadence as articles evolve. The policy operates alongside the existing SOC 2 questionnaire. It does not replace it. AI vendors get both questionnaires.

The cost of not having the AI-specific policy is exposure. A vendor that has not produced an Annex IV technical file cannot serve a high-risk customer obligation. A vendor that is not a GPAI Code of Practice signatory adds diligence overhead the customer must absorb. A vendor that has not produced an Article 47 declaration of conformity cannot be deployed in a high-risk Annex III use case. A vendor that has not produced a model card cannot support the customer's Article 13 transparency-to-deployer documentation. The procurement-side diligence is the gate that catches these gaps before contract execution rather than after deployment.

The Six-Section AI Vendor Risk Questionnaire

The questionnaire is structured in six sections, totaling 30 to 40 questions depending on the vendor's risk tier. Each section maps to a specific framework or article.

Section 1 - Vendor Identification (5-6 questions)

• Legal entity name and jurisdiction of incorporation. Determines whether the vendor is EU-established or non-EU. Non-EU vendors trigger Article 22 (high-risk AI provider) or Article 54 (GPAI provider) authorized representative requirements.
• EU establishment status. Where is the vendor's EU place of business; does the vendor have an EU subsidiary; what is the registered EU contact for AI Act purposes.
• Article 54 authorized representative (non-EU GPAI providers). Name, address, scope of authority, contact for the AI Office and national supervisory authorities. The AR must be designated and operational before the GPAI is placed on the EU market.
• Parent company and ultimate beneficial ownership. M&A exposure analysis, has the vendor been acquired (OpenAI acquired Promptfoo on March 9, 2026; license-posture changed); is acquisition in progress or pending; vendor-concentration risk in the broader portfolio.
• Trade-control posture. Export control license status (BIS, EAR, ITAR exposure); sanction screening; country-of-residence and country-of-data-residence disclosure.
• Insurance and indemnification posture. Cyber-liability, errors-and-omissions, AI-specific coverage (if available); indemnity scope for regulatory penalties, third-party claims, IP infringement (training data).

Section 2 - AI System Specification (5-7 questions)

• Model name and version. Specific model identifier; release version; release date; the customer must track the exact version under deployment for Article 25(1)(b) substantial-modification analysis on any vendor-side updates.
• GPAI dependency. If the vendor's AI system uses a GPAI model upstream, name the upstream GPAI; identify whether the GPAI is in scope of Article 51 systemic-risk designation; flow Annex XI / XII receivables through the upstream-GPAI-to-vendor chain to the customer.
• Training data summary (Article 53(1)(d)). For GPAI vendors, the publicly available summary of training data per Article 53(1)(d) and AI Office template; for narrow AI vendors, the training data characterization at the level required for Annex IV §2 technical-file documentation.
• Intended use and intended-purpose statement. The vendor's statement of intended use; mapping to Annex III high-risk categories where applicable; restrictions on use cases; the customer must align its planned use with the vendor's intended-purpose statement to avoid Article 25(1)(c) intended-purpose-change triggers.
• Foundation model lineage. What base model was used; what fine-tuning was applied; what alignment / RLHF / constitutional AI was applied; what evaluation suites the vendor ran.
• Multimodal scope. Text, image, audio, video, code, embeddings; for multimodal models, the per-modality risk profile.
• Agentic capabilities. Tool use, autonomous action, multi-step planning, agent-to-agent interaction; relevant to OWASP Agentic Top 10 coverage on the security side.

Section 3 - EU AI Act Compliance (6-8 questions)

• Annex IV technical-file status. Is the file complete; what is the version date; what are the gaps; what is the remediation timeline; is the file in a format that supports customer-side review and audit-committee briefing.
• Article 17 QMS evidence. Is the QMS implemented; what is the ISO 9001 / ISO 42001 alignment; what is the audit cadence; what is the management-of-change discipline; are the Article 17 elements (risk management, design, development, verification, validation, post-market monitoring, corrective action, records) all in place.
• Article 47 declaration of conformity status (where applicable). Has the declaration been drawn up for the high-risk Annex III use case; what is the version date; what is the CE marking status under Article 48; is the declaration in the format aligned to Annex V.
• Article 71 EU database registration. Is the provider registered; is the system registered (where applicable); what is the registration date; what is the registration ID for cross-reference.
• Conformity-assessment route. Annex VI internal control or Annex VII Module H assessment; if notified body, which notified body and what is the certificate number; what is the certificate validity period.
• Article 13 instructions for use. Are the instructions sufficient for the customer's Article 26 deployer compliance; do they cover all required elements per Article 13(3); are they kept current with system changes.
• Article 50 transparency obligations. Article 50(1) chatbot disclosure; Article 50(2) machine-readable marking of synthetic content (in scope from August 2, 2026); Article 50(3) deepfake labelling; what is the vendor's coverage and what does the customer need to layer on top.
• Article 73 serious incident reporting. What is the vendor's process for Article 73 reporting; what is the coordination process with the customer for Article 26(4) reporting; what are the timing and scope expectations.

Section 4 - GPAI Specifics (5-7 questions, GPAI vendors only)

• Article 51 designation status. Is the GPAI designated as systemic-risk under Article 51 (10^25 FLOPs threshold or Commission decision); if so, what is the designation date; what is the Article 55 obligation set the vendor is meeting.
• Article 53 obligations evidence. Annex XI technical documentation; Annex XII downstream-deployer information; Article 53(1)(c) copyright policy; Article 53(1)(d) public training-data summary; AI Office template alignment.
• GPAI Code of Practice signatory status. Is the vendor a signatory to the European Commission's GPAI Code of Practice (Anthropic, Google, OpenAI, Microsoft, Mistral are signatories; Meta and xAI are notable non-signatories); the signatory status affects the customer's downstream diligence overhead, non-signatory vendors require additional diligence to fill the implementation-gap evidence.
• Annex XI receivables. Are the Annex XI deliverables available for customer review (training data summary, training methodology, evaluation results, energy consumption, computational resources used, intended task and use case, technical limitations).
• Annex XII receivables. Are the Annex XII deliverables available (technical documentation for downstream providers, intended task and use, capabilities and limitations of the model, integration guidance, the items the customer needs for Article 26 deployer compliance and for Article 25(1)(b) substantial-modification analysis if fine-tuning).
• Article 53(1)(c) copyright policy. Vendor's policy on respecting the TDM (text and data mining) opt-out under Article 4(3) of the CDSM Directive; rightsholder notification process; takedown response process.
• Article 53(1)(d) public training-data summary. Vendor's published summary aligned to AI Office template; coverage of training data sources, categories, processing; update cadence; the customer must be able to cite this summary in its own Article 13 transparency-to-deployer documentation.

Section 5 - Security and Red-Team (6-8 questions)

• SOC 2 + AI scope. Is the vendor's SOC 2 Type II report scoped to AI controls (AICPA Trust Services criteria mapped to AI-specific controls: model governance, training-data provenance, model validation, post-deployment monitoring); which attestation firm (Schellman, A-LIGN, BSI, KPMG are the primary firms producing SOC 2 + AI scope reports in 2026); what is the report date; what are the open findings.
• NIST AI RMF Measure 2.7 evidence. Is the vendor's red-team program aligned to NIST AI RMF Measure 2.7 (AI system performance is regularly evaluated); what is the evaluation cadence; what is the evaluation scope; are the findings documented and remediated.
• OWASP / MITRE ATLAS coverage. Does the vendor cover OWASP LLM Top 10 (prompt injection, sensitive information disclosure, supply chain, etc.); OWASP Agentic Top 10 (where applicable); MITRE ATLAS technique-by-technique coverage; what is the technique inventory and what is the per-technique attestation.
• AI-VSS-graded findings. Does the vendor use AI-VSS (the AI-specific equivalent of CVSS) for grading vulnerabilities and red-team findings; what is the current findings inventory by severity; what is the remediation SLA; what is the disclosure process.
• Red-team partnerships. Does the vendor work with the U.S. AISI, UK AISI, or other AI safety institutes; what are the engagement scopes; what are the joint test results; are the results published or held confidentially.
• Penetration testing. Standard application-security pen test cadence; AI-specific pen test (prompt injection, jailbreak, data extraction, model inversion, membership inference); what are the findings and remediation.
• Bug bounty. Does the vendor run an AI-specific bug bounty (OpenAI, Anthropic, Google have AI-specific bug bounty programs); what is the scope; what are the payout tiers; what is the response SLA.
• Incident-response runbook. Is the runbook AI-aware; does it cover model-specific incident classes (data exfiltration via prompt injection, model jailbreak, agentic-action gone wrong, training-data leakage); what is the customer-notification timing.

Section 6 - Article 25 Transfer Analysis (5-6 questions)

• Substantial-modification exposure. What customer-side operations does the vendor consider substantial modification under Article 3(23); what is the notification process; what is the vendor's cooperation commitment under Article 25(2); does the vendor support customer-side technical-file production for the fine-tuned model.
• Trademarking allocation. What is the vendor's position on Article 25(1)(a) allocation when the customer white-labels the product; what contractual language does the vendor support; what is the vendor's process for explicit allocation between the parties.
• Intended-purpose-change risk. What is the vendor's process for handling Article 25(1)(c) intended-purpose changes by the customer; what are the customer notification requirements; what is the vendor's cooperation on any re-classification.
• Contractual flow-down language. Does the vendor accept the customer's standard procurement-contract clauses (Article 25 allocation, Annex XI/XII delivery SLA, Article 73 / Article 26(4) incident coordination, substantial-modification change-control, acceptable-use restrictions); what are the vendor's standard clauses and what is the redline negotiation expectation.
• Vendor-side change-control discipline. What is the vendor's process for model updates; what is the customer-notification timing; what is the customer's right to refuse an update; what is the version-control cadence for downstream receivables (Annex XII, model card, Article 47 declaration).
• M&A and consolidation risk. What is the vendor's posture on M&A events affecting license posture, model continuity, customer obligations; what is the contractual continuity language; what are the assignment, change-of-control, and termination-for-convenience provisions.

Model-Card Minimum Requirements

The model card is a critical AI-vendor artifact. The customer cannot complete Article 13 transparency-to-deployer documentation or Annex IV §2 system description without a vendor model card. The 2026 model-card minimum requirements draw from Mitchell et al. (2019) "Model Cards for Model Reporting", the nine canonical sections, plus an Annex IV §2 gap analysis to close the EU AI Act delta.

The nine Mitchell-et-al. sections:

• Model Details: Person or organization developing model; model date; model version; model type; information about training algorithms, parameters, fairness constraints, or other applied approaches; paper or other resource for more information; citation details; license; where to send questions or comments.
• Intended Use, Primary intended uses; primary intended users; out-of-scope use cases.
• Factors: Relevant factors (demographic groups, environmental conditions, technical attributes); evaluation factors used.
• Metrics, Model performance measures; decision thresholds; variation approaches.
• Evaluation Data, Datasets; motivation; preprocessing.
• Training Data: Same as evaluation data (datasets, motivation, preprocessing) plus any additional details.
• Quantitative Analyses, Unitary results; intersectional results.
• Ethical Considerations, Sensitive data; human life; mitigations; risks and harms; use cases.
• Caveats and Recommendations, Additional concerns not covered elsewhere.

The Annex IV §2 gap analysis closes the EU AI Act delta. Annex IV §2 (technical documentation: system description) requires: (a) intended purpose; (b) the persons or groups likely to be affected; (c) main classifications of input data, including type, source, and intended use; (d) main classifications of expected output data; (e) when the AI system is intended to interact with non-EU-AI-Act-compliant systems; (f) descriptions of pre-determined changes to the system and its performance. The Mitchell-et-al. template covers (a), (b), partially (c) and (d); the gap is in (e) interoperability and (f) pre-determined-changes documentation. The customer's model-card minimum requirement is the nine Mitchell sections plus explicit (e) and (f) coverage.

The model-card refresh cadence is on the order of every release (vendor-side) and every contract renewal (customer-side). Stale model cards lose value rapidly as model behavior changes.

SOC 2 + AI Scope - What the Customer Should Expect

SOC 2 Type II is the dominant attestation framework for SaaS vendors. In 2026 the AICPA Trust Services criteria (security, availability, processing integrity, confidentiality, privacy) have been mapped to AI-specific controls by the major attestation firms. The customer's vendor risk questionnaire should ask explicitly whether the vendor's SOC 2 Type II report includes AI scope.

The primary attestation firms producing SOC 2 + AI scope reports in 2026:

• Schellman: Early mover on AI scope; published the SOC 2 + AI mapping methodology in 2025; has AI-specific scope language for processing integrity (model validation, drift monitoring), security (model-access controls, prompt-injection prevention), privacy (training-data lineage, output-data handling).
• A-LIGN, Active in AI scope SOC 2 reports for mid-market AI vendors; alignment with ISO 42001 controls; integrated SOC 2 + ISO 42001 testing where the vendor seeks both.
• BSI, Active in AI scope SOC 2 for European-market vendors; integration with ISO 42001 audit work; alignment with EU AI Act Article 17 QMS evidence.
• KPMG (and Big-4 peers), Active for large enterprise AI vendors; integrated SOC 2 + ISO 42001 + EU AI Act readiness review; high cost but comprehensive scope.

The customer should ask for the SOC 2 + AI scope report explicitly, ask whether the report includes the AI-specific controls under each Trust Services criterion, ask for the list of open findings and the remediation SLA, ask for the auditor's letter affirming the AI scope coverage, and (for high-risk vendor relationships) ask for a customer-call with the auditor to walk the AI scope and findings.

Vendors without SOC 2 + AI scope coverage in 2026 are not necessarily disqualified but they impose additional diligence overhead on the customer, the customer must execute its own AI-specific audit work in lieu of the auditor letter.

EU Declaration of Conformity Status - When Applicable

The EU declaration of conformity under Article 47 is a provider obligation for high-risk Annex III AI systems. The customer's vendor risk questionnaire should establish: (1) whether the vendor's system is in scope for Article 47 (i.e., is it a high-risk Annex III system); (2) if in scope, has the declaration been drawn up; (3) what is the declaration date and version; (4) is the CE marking under Article 48 applied; (5) is the system registered in the EU database under Article 71; (6) what is the customer's access to the declaration for its own Article 13 / Article 26 compliance work.

Vendors whose products are in Article 47 scope but who have not produced the declaration cannot be deployed in high-risk Annex III use cases. This is a hard gate, the customer's procurement decision must condition on declaration availability.

The Article 47 declaration is functionally the "we have done the conformity assessment under Article 43; the technical file under Annex IV is in place; the QMS under Article 17 is operating; we attest to compliance with Chapter III Section 2" statement. The CE marking is the visible mark. The EU database registration is the regulator-facing record.

Procurement-Contract Clause Checklist

The five clauses from the lesson 008 procurement work apply directly to the AI vendor risk policy:

• Article 25 allocation clause: Explicit allocation of provider obligations between upstream vendor and customer; default rule for trademarking, fine-tuning, intended-purpose changes; notification process under Article 25(2); cooperation on technical-documentation access.
• Annex XI / XII delivery SLA: Specific deliverables, delivery dates, AI Office template alignment, update obligations on technical changes; format and access requirements.
• Article 73 / Article 26(4) incident-coordination clause: Timing, scope, communication owners, retention for cross-party serious-incident reporting; AI Office and national authority coordination.
• Substantial-modification change-control clause, What changes constitute substantial modification; notification process; provider/deployer cooperation; right-to-refuse process for customer-impacting changes.
• Acceptable-use clause. Use cases authorized vs. prohibited; trigger conditions for re-classification; restrictions on intended-purpose change; Article 5 prohibition risk acknowledgment.

The AI vendor risk policy enforces these five clauses as a pre-execution gate. The vendor risk review status (red / amber / green) integrates the questionnaire findings, the SOC 2 + AI scope findings, the EU declaration status, the model-card availability, and the contractual-clause coverage. Red status blocks procurement; amber status requires mitigation plan; green status proceeds.

Vendor M&A Risk - The OpenAI / Promptfoo Example

On March 9, 2026, OpenAI announced its acquisition of Promptfoo, the open-source LLM evaluation framework. The acquisition consolidates the leading independent open-source eval framework into a foundation-model vendor's portfolio. The implications for the customer's AI vendor risk policy:

• Vendor-concentration risk. OpenAI now owns Promptfoo and OpenAI Evals, two of the most-deployed eval frameworks. Customers running both have a single-vendor exposure they did not have on March 8, 2026. Vendor-concentration risk analysis must surface in the quarterly portfolio review.
• License-posture uncertainty. The Promptfoo license posture post-integration is still settling. Customers depending on the open-source license posture should expect change-control events and license-language updates over the 12 months following the acquisition.
• Tooling-diversity discipline. The procurement-side discipline is to maintain license-independent fallback, Garak (NVIDIA), PyRIT (Microsoft), Inspect (UK AISI), DeepTeam (Confident AI), alongside any OpenAI-stack-dependent tooling. License-independent fallback is the operating discipline that survives any single vendor's M&A event.
• Contractual flow-down language. Procurement contracts should anticipate consolidation events through change-of-control clauses, assignment provisions, and license-continuity language. The contractual language work is the most leveraged investment in vendor M&A resilience.
• Questionnaire refresh. Annual or trigger-based refresh of the AI vendor risk questionnaire should include parent-company / ultimate-beneficial-ownership questions; M&A pending status; recent M&A history; concentration risk in the portfolio. Static questionnaires that do not refresh on consolidation events miss the exposure.

The OpenAI / Promptfoo example is one of several 2026 consolidation events affecting AI tooling. The AI vendor risk policy must build in the refresh cadence and the contractual-language discipline that allow the customer to absorb consolidation events without operational disruption.

Tiered Diligence Depth - Aligned to Vendor Risk Tier

Not every vendor requires the full 40-question questionnaire. The AI vendor risk policy specifies tiered diligence depth aligned to vendor risk tier. The tiering follows the customer's internal AI tiering memo (lesson on tiering): high-risk vendors get deep diligence; medium-risk vendors get moderate diligence; minimal-risk vendors get light diligence.

• Tier 1 - High-Risk Vendor (Annex III deployment, GPAI with substantial customer integration, fine-tuning relationship). Full 40-question questionnaire; SOC 2 + AI scope mandatory; EU declaration of conformity mandatory (where in scope); model-card review; Article 47 declaration access; Annex XI / XII receivable review; signatory-status verification; quarterly refresh; annual customer-call with vendor's auditor for SOC 2 + AI walkthrough.
• Tier 2 - Medium-Risk Vendor (limited-risk Article 50 deployment, GPAI without fine-tuning, narrow-AI vendor in non-high-risk use case). 25-question subset; SOC 2 + AI scope preferred (not mandatory); model-card review; basic Annex XII receivable check; signatory-status verification; semi-annual refresh.
• Tier 3 - Minimal-Risk Vendor (minimal-risk SaaS with AI feature, internal-tooling AI vendor without customer-facing deployment). 10-question subset; SOC 2 Type II (standard scope); basic model-card check; annual refresh.

The tiered approach allows the procurement team to deploy diligence resources efficiently. Tier-1 diligence is expensive (a high-tier diligence package can run 40-80 hours of procurement-and-legal time per vendor); tier-3 diligence is light (4-8 hours). The tiering memo gates the depth.

Cross-Walks - ISO 42001, NIST AI RMF, EU AI Act, SOC 2 + AI

The AI vendor risk policy crosses multiple frameworks. The cross-walk matrix:

• ISO 42001 Annex A - A.10 third-party relationships. The full questionnaire structure maps to A.10; the SOC 2 + AI scope check maps to A.10 control evidence; the contractual-clause checklist maps to A.10 process evidence; the tiered diligence depth maps to A.10 management discipline.
• NIST AI RMF - Govern 6 (third-party AI), Map 4 (impacts on individuals and society). The vendor questionnaire is the Govern 6 artifact; the model-card review and Annex IV §2 gap analysis is the Map 4 artifact; the SOC 2 + AI scope check is the Govern 6 control evidence; the Article 25 transfer analysis is the Govern 6 contractual evidence.
• EU AI Act - Articles 16 (provider obligations), 23 (importer), 24 (distributor), 25 (transfer mechanics), 26 (deployer obligations), 47 (declaration), 53 (GPAI), 54 (GPAI authorized representative). The questionnaire surfaces each article's evidence; the contractual-clause checklist operationalizes Article 25; the EU declaration of conformity check maps to Article 47; the GPAI section maps to Articles 53 and 54.
• SOC 2 + AI scope attestation framework. AICPA Trust Services criteria mapped to AI-specific controls (model governance, training-data provenance, model validation, post-deployment monitoring); attestation firms (Schellman, A-LIGN, BSI, KPMG); customer's questionnaire asks for the AI scope and the open-findings inventory.

The cross-walk matrix is the audit-defensibility evidence. ISO 42001 Stage 2 audit on A.10 third-party relationships expects the policy, the questionnaire, the contractual-clause coverage, the SOC 2 + AI scope evidence, and the tiered diligence depth. NIST AI RMF Govern 6 review expects the same artifacts. EU AI Act readiness review expects the Article 25 transfer analysis and the Annex XI / XII receivable status. The integrated cross-walk is the artifact procurement carries into every framework audit.

Six Common AI Vendor Risk Policy Mistakes

Mistake 1 - Generic Vendor Questionnaire Without AI Specifics

Bolting "do you use AI" and "is the AI biased" onto the existing SOC 2 questionnaire is not an AI vendor risk policy. The AI-specific diligence requires the 30-to-40-question structured artifact covering vendor identification, AI system specification, EU AI Act compliance, GPAI specifics, security and red-team, and Article 25 transfer analysis. Generic questionnaires miss the regulatory exposure.

Mistake 2 - No GPAI Code of Practice Signatory Diligence

The GPAI Code of Practice signatory status (Anthropic, Google, OpenAI, Microsoft, Mistral as signatories; Meta, xAI as non-signatories) materially changes the customer's downstream diligence overhead. Non-signatory vendors require additional diligence to fill the implementation-gap evidence. Questionnaires that do not ask the signatory question miss the cost differential and the obligation-gap exposure.

Mistake 3 - No Model-Card Minimum Requirements

Model cards vary widely in quality. Some vendors produce comprehensive Mitchell-et-al.-aligned cards; others produce one-page marketing summaries. The AI vendor risk policy must specify the model-card minimum requirements (nine Mitchell sections plus Annex IV §2 gap analysis coverage) and reject inadequate cards at the diligence stage rather than discovering the gap during Article 13 transparency-to-deployer documentation work.

Mistake 4 - No Article 25 Transfer Analysis

The Article 25 transfer analysis (trademarking, substantial modification, intended-purpose change) is the most consequential single section of the AI vendor risk questionnaire. Vendors that do not address Article 25 explicitly in their standard terms leave the customer carrying the inherited-provider-obligation exposure. The questionnaire and the contractual-clause checklist must close this gap before contract execution.

Mistake 5 - No SOC 2 + AI Scope Check

Customers that accept a generic SOC 2 Type II report from an AI vendor and do not verify the AI scope coverage are not getting the control attestation they think they are getting. The AICPA Trust Services criteria can be applied to AI-specific controls (Schellman, A-LIGN, BSI, KPMG have published mappings), but the application requires explicit scope language in the report. The customer's questionnaire must ask for the AI scope language explicitly.

Mistake 6 - Static Questionnaire That Does Not Refresh

The EU AI Act, the GPAI Code of Practice, the AI Office template library, the harmonized standards under Article 40, and the vendor consolidation landscape all evolve. A questionnaire built in 2025 and not refreshed in 2026 misses the Article 50(2) machine-readable marking obligations (August 2, 2026), the OpenAI / Promptfoo acquisition (March 9, 2026), the post-Omnibus VII compliance-timeline changes, and the AI Office template updates. The AI vendor risk policy must build in a quarterly refresh cadence and a trigger-based refresh on regulatory events.

Key Takeaways

• The AI vendor risk policy is a different artifact from the SOC 2 questionnaire. The AI-specific 30-to-40-question structured questionnaire is anchored to ISO 42001 A.10 third-party relationships and the EU AI Act Article 25 provider-transfer clause. It operates alongside the SOC 2 questionnaire, not as a replacement.
• The six-section questionnaire structure. Vendor identification; AI system specification; EU AI Act compliance; GPAI specifics; security and red-team; Article 25 transfer analysis. Each section maps to specific framework controls and article evidence.
• The model-card minimum requirements. Nine Mitchell-et-al. sections (Model Details, Intended Use, Factors, Metrics, Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations, Caveats) plus Annex IV §2 gap analysis (interoperability and pre-determined changes coverage). Model cards are the foundation for Article 13 transparency-to-deployer documentation.
• SOC 2 + AI scope is the dominant attestation framework for AI vendors in 2026. Schellman, A-LIGN, BSI, KPMG are the primary attestation firms. The customer must ask for the AI scope language explicitly; generic SOC 2 Type II without AI scope is insufficient.
• EU declaration of conformity status is a hard gate for high-risk Annex III deployments. Vendors whose products are in Article 47 scope but who have not produced the declaration cannot be deployed in high-risk use cases. The procurement decision must condition on declaration availability.
• The procurement-contract clause checklist (five clauses). Article 25 allocation; Annex XI / XII delivery SLA; Article 73 / Article 26(4) incident coordination; substantial-modification change control; acceptable-use restrictions. The AI vendor risk policy enforces these five clauses as a pre-execution gate.
• Vendor M&A risk is a 2026 reality. The OpenAI / Promptfoo acquisition (March 9, 2026) is one example. The AI vendor risk policy must build in concentration-risk analysis, license-posture verification, tooling-diversity discipline, contractual flow-down language, and questionnaire refresh on consolidation events.
• Tiered diligence depth aligned to vendor risk tier. Tier 1 high-risk vendors get the full 40-question diligence; Tier 2 medium-risk vendors get a 25-question subset; Tier 3 minimal-risk vendors get a 10-question subset. The tiering memo gates the depth and allocates procurement-and-legal resources efficiently.
• Cross-walks across ISO 42001 A.10, NIST AI RMF Govern 6 + Map 4, EU AI Act Articles 16/23/24/25/26/47/53/54, and SOC 2 + AI attestation. The cross-walk matrix is the audit-defensibility evidence carried into every framework audit.
• Six common mistakes to avoid. Generic questionnaire without AI specifics; no GPAI signatory diligence; no model-card minimum requirements; no Article 25 transfer analysis; no SOC 2 + AI scope check; static questionnaire that does not refresh. The AI vendor risk policy that addresses all six mistakes is the procurement-side artifact that closes the AI Act readiness gap on the vendor diligence dimension.