On a Tuesday afternoon in late September 2026, the Acme Inc procurement team kicked off the Q3 vendor swap for its customer-service AI. The legacy supplier had raised prices 41% at renewal, so two challenger vendors were on the table. The procurement lead pulled the standard third-party-risk questionnaire, the same SIG-Lite + CAIQ + SOC 2 evidence pack the company had used for every SaaS purchase since 2022, and emailed it to both vendors. Two weeks later, both questionnaires came back "all green." Both vendors had SOC 2 Type II reports. Both had ISO 27001 certificates. Both had data processing agreements. The procurement lead signed the favored vendor and tabled the second. Six weeks later, in the Article 26 readiness review, the new vendor was asked for its Article 25(2) cooperation memo, its Annex IV documentation pass-through, its ML-BoM, and its GPAI Article 53 training-content summary. The vendor's response: "we don't share that level of detail with customers." Acme was the deployer of a high-risk customer-service AI. Acme had no Annex IV technical documentation. Acme had no Article 25(2) cooperation evidence. Acme was on the hook for Article 26 deployer obligations, and Article 99(3) penalty exposure of €15M / 3% of global turnover sat squarely on Acme. The legacy CAIQ-only DDQ had come back all green for a vendor that, for AI Act purposes, was not in fact procurement-ready. This lesson is the questionnaire that prevents that meeting. It is the L3 artifact, the dedicated AI Due-Diligence Questionnaire (AI-DDQ), that turns vendor procurement from "all green" theatre into Article 26-defensible diligence.

Why the Standard Vendor DDQ Is Insufficient for AI

Every mature organization has a vendor risk program. The toolset is mature and converged: the Shared Assessments SIG (Standardized Information Gathering) questionnaire, full and lite, for general third-party risk; the Cloud Security Alliance CAIQ (Consensus Assessments Initiative Questionnaire) for cloud providers; the AICPA SOC 2 Type II report for service organizations; ISO 27001 certificates for information-security management; and contractually, the GDPR Article 28 data processing agreement (DPA) for processors. For 95% of SaaS purchases, this stack is sufficient. For an AI vendor whose system will be in-scope of the EU AI Act, it is not.

The gap has six parts. First, provider-versus-deployer status. Under Article 3(3) the provider is the entity that develops or places on the market an AI system under its own name. Under Article 3(4) the deployer is the entity that uses the AI system under its authority. The vendor and the procuring organization need to agree, in writing, who is the provider and who is the deployer for each in-scope AI system in the engagement. SIG and CAIQ do not ask this question. SOC 2 does not ask this question. ISO 27001 does not ask this question. And yet, until provider-versus-deployer is settled, neither party knows which obligations they owe under Articles 16 (provider), 25 (provider-deployer transitions), or 26 (deployer).

Second, Annex IV documentation pass-through. Article 11 read with Annex IV requires the provider of a high-risk AI system to maintain technical documentation covering the intended purpose, the design specification, the data governance, the risk management system, the human-oversight provisions, the accuracy and robustness metrics, the post-market monitoring plan, and a dozen other artifacts. The deployer needs sufficient access to Annex IV documentation to discharge Article 26(1) "use in accordance with the instructions for use" and Article 26(5) "monitor the operation." SIG/CAIQ/SOC 2 do not surface Annex IV documentation. The DDQ must.

Third, Article 25(2) cooperation evidence. Where the vendor and the deployer are in a value-chain relationship, vendor produces the AI system, deployer puts it to a specific use, Article 25(2) requires the vendor to cooperate with the deployer to enable the deployer's compliance with the Act. Cooperation evidence includes an inter-company memo (or contractual clause), a quarterly coordination cadence, an incident-coordination clause, and downstream-deployer information per Annex XII. None of this appears in SIG or CAIQ.

Fourth, ML-BoM and fine-tune lineage. The CycloneDX 1.7 ML-BoM (machine-learning bill of materials) is the AI supply-chain analogue to the SBOM. It lists the base model, training datasets, model dependencies, evaluation datasets, and signing. SBOMs are increasingly standard at AI procurement; ML-BoMs are not yet, but they should be. The DDQ must ask. Fine-tune lineage, what base model did the vendor fine-tune from, with what data, with what evaluation, is the corresponding provenance evidence.

Fifth, GPAI Article 53 obligations. Where the vendor is a GPAI provider (general-purpose AI model placed on the market), Article 53 imposes specific obligations: maintain technical documentation per Annex XI, make information available to downstream providers per Annex XII, comply with EU copyright TDM opt-outs under the DSM Directive Article 4(3), and publish a training-content summary in the Commission template. Where the GPAI is designated as systemic-risk under Article 51, Article 55 adds: model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office under Article 55(1)(c), and adequate cybersecurity. None of this appears in SIG, CAIQ, or SOC 2.

Sixth, AI-specific independent assurance. ISO 42001 (AI Management Systems) certification, SOC 2 with the new AI Trust Services Criteria, ATLAS / OWASP coverage attestations, model-card and system-card disclosure, fairness slices, ML-BoM signing. These are AI-specific assurance artifacts that the standard DDQ stack does not surface. The 2026 AI-DDQ asks for all of them.

The dedicated AI-DDQ is not a replacement for SIG, CAIQ, or SOC 2; it is the layer on top. The vendor risk program runs the general DDQ for general third-party risk and then runs the AI-DDQ for the AI-specific dimensions. Both questionnaires must come back acceptable before the vendor enters production.

The Fourteen-Section AI-DDQ Structure

The AI-DDQ runs to roughly 120 to 150 questions, organized into 14 sections. The structure below is the L3 reference structure; mature programs adapt it to their sector and risk tier.

Section 1 - Vendor and System Identification (10 questions)

The opening section captures the basic identifiers needed for the rest of the DDQ to be coherent: legal entity name and registration number, EU representative information for non-EU vendors per Article 25(4), product name and version, base-model lineage (which foundation model, which version, which fine-tune chain), system architecture summary, intended purpose statement as defined by the vendor, deployment topology (single-tenant, multi-tenant, on-prem), and the point of contact for AI-specific diligence.

Section 2 - EU AI Act Status (15 questions)

The status section is the gating section for the rest of the DDQ. The vendor must declare: (a) its provider-or-deployer classification under Article 3(3)/3(4) for the in-scope system; (b) whether the system is high-risk under Article 6 read with Annex III, with the specific Annex III category cited; (c) whether the underlying model is GPAI under Article 51, with the FLOPs threshold and the systemic-risk designation status; (d) the CE-marking status per Article 47 and the conformity-assessment pathway (Annex VI or Annex VII); (e) the Article 71 EU database entry ID where applicable for high-risk systems; (f) the notified body (where applicable) for Annex VII assessments; (g) the date of CE-marking declaration; (h) any sectoral overlays (medical devices under MDR, aviation under EASA, financial services under sector regulators). A vendor that cannot answer this section with citations is not procurement-ready.

Section 3 - Article 25(2) Cooperation Evidence (8 questions)

Where the vendor-deployer relationship is in scope, the vendor must produce: (a) a draft inter-company memorandum or contractual cooperation clause that recognises Article 25(2); (b) a proposed quarterly coordination cadence (or equivalent); (c) an incident-coordination clause that aligns Article 73 reporting between vendor and deployer; (d) the downstream-deployer information package per Annex XII (where the vendor is a GPAI provider); (e) the contact for substantial-modification notifications; (f) the cooperation arrangement for FRIA support (where the deployer must conduct a fundamental-rights impact assessment under Article 27); (g) the data-flow documentation needed for Article 26(5) deployer monitoring; (h) the sample artifacts the vendor will produce on request. Section 3 is the section that the legacy CAIQ does not even attempt to cover.

Section 4 - GPAI Article 53 / 55 Obligations (12 questions)

Where the vendor is a GPAI provider, or where the vendor's system is built on a GPAI base model that the vendor has fine-tuned beyond the Recital 109 threshold, Section 4 applies. Questions cover: (a) Article 53(1)(a) Annex XI technical documentation; (b) Article 53(1)(b) Annex XII downstream-provider information; (c) Article 53(1)(c) DSM Directive Article 4(3) TDM opt-out compliance policy; (d) Article 53(1)(d) training-content summary published in the Commission template; (e) Article 51 systemic-risk designation status (and the FLOPs threshold calculation); (f) where Article 55 applies, the model-evaluation and adversarial-testing evidence; (g) the Article 55(1)(b) systemic-risk assessment; (h) the Article 55(1)(c) serious-incident reporting capability to the AI Office; (i) the Article 55(1)(d) cybersecurity posture for systemic-risk models; (j) the GPAI Code of Practice signatory status; (k) the foundation-model provider (if the vendor is downstream of another GPAI); (l) the inter-company arrangements between the vendor and its upstream GPAI provider.

Section 5 - Model Card and System Card Disclosure (10 questions)

The Mitchell-et-al. model card (Mitchell, Wu, Zaldivar et al., 2019, the standard reference) and the more recent system card (OpenAI / Anthropic-style operational system documentation) carry AI-specific disclosure that the deployer needs. Section 5 asks: (a) presence of a model card aligned to Mitchell-et-al. sections (model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, caveats and recommendations); (b) presence of a system card; (c) refresh cadence (the lesson recommends quarterly minimum, monthly for higher-tier vendors); (d) ATLAS technique coverage attestations; (e) OWASP LLM Top 10 coverage attestations; (f) OWASP Agentic Top 10 coverage attestations for agentic systems; (g) intersectional fairness slices in the metrics section (not just demographic-parity by single attribute, but intersectional analyses); (h) the failure-mode taxonomy disclosure; (i) the prompt and response example library; (j) the negative-use-case statement.

Section 6 - ML-BoM Availability (8 questions)

The CycloneDX 1.7 ML-BoM is the AI supply-chain artifact. Section 6 asks: (a) does the vendor produce an ML-BoM; (b) in what format (CycloneDX 1.7 is the 2026 standard); (c) does it cover the base model, the training datasets, the fine-tune datasets, the evaluation datasets, the model dependencies; (d) is the ML-BoM signed (Sigstore / cosign or equivalent); (e) is it accessible to the deployer (and on what cadence); (f) what are the licence terms of each component; (g) what is the patch-and-vulnerability response process for ML-BoM components; (h) what is the notification cadence for ML-BoM changes.

Section 7 - Independent Assurance (12 questions)

The independent-assurance section is the section where the standard DDQ overlaps most with AI-specific diligence, but with AI-specific additions. Questions cover: (a) ISO/IEC 42001 (AI Management Systems) certification status: issued, in scope or pending; (b) the certifying body (Schellman, A-LIGN, BSI, KPMG, Coalfire, et al.); (c) the scope statement of the ISO 42001 certificate (some certificates carve out subsidiaries or product lines); (d) the certificate's expiry and surveillance audit cadence; (e) SOC 2 Type II report; (f) SOC 2 with the AICPA AI Trust Services Criteria (published 2025-2026 era, the AI-specific TSC additions); (g) the SOC 2 report observation period (typically 6-12 months); (h) penetration test report cadence (annual minimum); (i) red-team report cadence (annual minimum for high-risk AI); (j) responsible-disclosure policy; (k) bug-bounty program; (l) any prior audit findings of material weakness or significant deficiency relevant to the AI system.

Section 8 - Security Controls and OWASP / MITRE Coverage (15 questions)

Section 8 is the AI-specific security section. Questions cover, for each OWASP LLM Top 10 (2025-2026 update) entry LLM01 through LLM10, the vendor's mitigation attestation. Where the system is agentic, the OWASP Agentic Top 10 ASI01 through ASI10 attestations. Coverage of MITRE ATLAS v5.4.0 techniques (the AI-specific extension of MITRE ATT&CK) with technique-by-technique controls. Incident response capability summary. Vulnerability management for AI-specific findings. Encryption posture for model artifacts and training data. Access control for the model weights. Network isolation for model-serving infrastructure. Logging and observability for prompts and responses. Secrets management. Software supply-chain security for the model dependencies. Model-extraction protection. Membership-inference protection.

Section 9 - Data Privacy and Provenance (12 questions)

The privacy section overlaps with the GDPR Article 28 processor terms but adds AI-specific dimensions. Questions cover: (a) the standard Article 28 processor terms; (b) Article 9 special-category data handling (where in-scope); (c) the Schrems II transfer mechanism for any data flow outside the EU (Standard Contractual Clauses, adequacy decision, Binding Corporate Rules); (d) training-data provenance, where did training data come from; (e) opt-out compliance for content scraped under exceptions; (f) the DSM Directive Article 4(3) TDM opt-out process; (g) Article 14 transparency obligations where customer data is used in training; (h) the data-retention schedule for inference inputs and outputs; (i) any data-residency commitments; (j) the right to portability and erasure for inference logs; (k) the anonymisation or pseudonymisation posture for inference logs; (l) the data-poisoning prevention controls.

Section 10 - Operational Resilience (8 questions)

The operational-resilience section captures the SLA and DR posture but with AI-specific additions: (a) availability SLA (typically 99.5% to 99.95%); (b) disaster recovery and business continuity posture; (c) model-rollback capability (can the vendor revert to a prior model version under deployer instruction); (d) upstream-model change-notification SLA (where the vendor's model is built on an upstream foundation model that the vendor does not control); (e) the model-versioning policy; (f) the substantial-modification notification commitment under Article 25(1)(b) where applicable; (g) the planned-maintenance window policy; (h) the regional failover topology.

Section 11 - Article 73 Incident-Reporting Capability (6 questions)

Section 11 confirms that the vendor can support the deployer's Article 73 reporting workflow: (a) serious-incident detection capability; (b) notification SLA to the deployer (the lesson recommends 24 hours or less); (c) the vendor's own Article 73 reporting capability (where the vendor is the provider) under the 10-day / 2-day / 15-day Commission-template clocks; (d) the vendor's Article 26(4) deployer-notification interface; (e) the incident dossier evidence the vendor will share; (f) the joint-investigation arrangement.

Section 12 - Contractual Flow-Down (10 questions)

Section 12 captures the contract clauses that translate the DDQ answers into binding obligations: (a) right-to-audit clause (the deployer's right to verify DDQ answers on reasonable notice); (b) right-to-redo-DDQ clause (triggered on substantial modification per Article 3(23) or major version upgrade); (c) indemnity clause aligned to AI-specific harm classes; (d) data-processing agreement with AI-specific addendum (DPA-AI); (e) the cooperation clause aligning with Article 25(2); (f) the incident-coordination clause aligning with Article 26(4) and Article 73; (g) the source-code or weights escrow (where appropriate); (h) the substantial-modification notification clause; (i) the termination-for-AI-Act-non-compliance clause; (j) the transition-services clause on exit.

Section 13 - Pricing and Commercial (5 questions)

Section 13 is shorter but operationally important: (a) the pricing model (per-seat, per-inference, per-token); (b) training-data control (does the deployer's data become training data for vendor models, and is this opt-in/opt-out); (c) output IP rights (who owns the outputs of the deployer's inference calls); (d) exit and portability terms; (e) any volume-commit clawbacks.

Section 14 - Vendor Concentration and Supply Chain (8 questions)

The final section captures supply-chain risk specific to the AI supply chain: (a) which upstream foundation-model provider the vendor depends on (OpenAI, Anthropic, Google, Mistral, Meta, etc.); (b) what happens if the upstream provider terminates the vendor's access; (c) what the vendor's alternative-vendor readiness looks like (multi-cloud, multi-model); (d) the vendor's own concentration risk on a single customer; (e) the cybersecurity posture of the upstream provider; (f) the deployer's option to negotiate directly with the upstream provider where necessary; (g) the documented dependency map; (h) the supply-chain incident notification SLA.

Scoring Rubric and Tier Mapping

A DDQ without a scoring rubric is a checkbox exercise. The 2026 AI-DDQ uses a three-state per-question rubric with section-level aggregation and vendor-level tiering.

Per-question scoring. Each of the ~120-150 questions resolves to one of three states. Pass: the vendor answered with evidence (memo, certificate, report, contract clause) that meets the question's expected bar. Conditional Pass with CAR (Corrective Action Request), the vendor answered with partial evidence and a credible remediation plan with a date; the deployer accepts the conditional pass subject to remediation tracking. Fail: the vendor refused to answer, answered with no evidence, or provided evidence that does not meet the bar.

Section-level aggregation. For each of the 14 sections, the aggregate is the worst per-question rating. A section with one Fail is a section Fail. A section with zero Fails and at least one Conditional Pass is a section Conditional Pass. A section with all Passes is a section Pass. Section Fails on Sections 1, 2, 3, 7, or 11 are program-blocking, the vendor cannot enter production until those sections clear.

Vendor-level tiering. The DDQ resolves to a vendor risk tier: Tier A, all sections Pass; vendor is procurement-ready. Tier B, at most two sections Conditional Pass; remediation tracked; vendor may enter production with executive sign-off and time-boxed CAR closure. Tier C, three or more sections Conditional Pass, or one Section Fail on a non-blocking section; vendor enters a watch-list with mandatory quarterly re-DDQ; production deployment requires CISO and Chief AI Officer sign-off. Tier D, any Section Fail on a program-blocking section, or four or more section Conditional Passes; vendor is not procurement-ready; either remediate to Tier C or terminate the procurement.

Mapping to the model-inventory tier. The vendor tier maps to the model-risk tier from lesson 069's inventory work. A Tier A vendor providing a Tier 1 high-risk system inherits the full provider-deployer cooperation obligation. A Tier D vendor on a Tier 1 system is a non-starter, the deployer cannot defend the Article 26 posture. A Tier C vendor on a Tier 4 low-risk system may be acceptable. The matrix is enumerated in the policy so procurement decisions are defensible.

Common Vendor Pushback and Counter-Arguments

Vendors push back. The standard patterns and the procurement-team responses follow.

Pushback 1: "We don't share that level of detail with customers." Counter: Article 25(2) requires the vendor to cooperate with the deployer to enable the deployer's compliance. The deployer's Article 26 obligations and Article 99(3) penalty exposure cannot be discharged without the cooperation. If the vendor refuses, the vendor is signalling that it does not understand its own Article 25(2) obligations and is not procurement-ready for an in-scope deployer. Document the refusal in the procurement file and move to the alternative vendor.

Pushback 2: "We are not high-risk in our jurisdiction." Counter: the risk classification follows the use, not the vendor. If the deployer is using the system for a use case enumerated in Annex III (e.g., recruitment, credit scoring, critical-infrastructure management), the system is high-risk in the deployment regardless of how the vendor classifies it in its home jurisdiction. The vendor's classification is informative but not dispositive. The deployer's own legal team makes the dispositive classification.

Pushback 3: "Ask the foundation-model provider, that's their obligation, not ours." Counter: this is partially true and partially evasion. Where the vendor is a downstream re-seller or thin wrapper on an upstream GPAI provider, some answers do live upstream, particularly Section 4 GPAI questions. But the vendor remains the deployer's contractual counterparty and retains the Article 25(2) cooperation obligation. The correct posture is: the vendor produces the upstream information it can produce (under its own Annex XII receipts from the upstream GPAI provider) and discloses the gaps. A vendor that refuses to produce any GPAI documentation is not procurement-ready.

Pushback 4: "ISO 27001 covers it. You don't need a separate AI-DDQ." Counter: ISO 27001 is the information-security-management baseline; it does not address provider-deployer status, Annex IV documentation, Article 25(2) cooperation, GPAI obligations, ML-BoM, model-card disclosure, or fairness slices. ISO 42001 is the AI Management Systems standard that addresses many of those (though it is not itself a substitute for the DDQ either). Treating ISO 27001 as sufficient is the same category error as treating SOC 2 as sufficient.

Pushback 5: "This is too much paperwork for a $50k contract." Counter: the depth of the DDQ scales with risk tier and contract value. A Tier 4 low-risk system on a $50k contract may justify a 30-question lite-DDQ. A Tier 1 high-risk system on any contract value justifies the full 120-150 question DDQ. Procurement applies the proportionate version based on the model-inventory tier.

Pushback 6: "The DDQ asks questions our legal team cannot answer." Counter: that is by design. If the vendor's legal team cannot answer questions about their own EU AI Act posture, their CE-marking status, their Article 71 EU database entry, or their conformity-assessment pathway, the vendor is signalling AI Act non-readiness, which is the answer the deployer needed to extract from the diligence. The DDQ has done its job.

Worked Example - Acme Inc Vendor Swap

Acme Inc is the deployer of a customer-service AI used for first-line support across its European footprint. The system is in-scope of Annex III (consumer interaction in financial-services context, intersecting with credit-decision support). Acme is evaluating two challenger vendors after the legacy supplier raised prices 41%.

Vendor A. Enterprise GPAI deployer, in market since 2022. ISO 42001 certified March 2026 (Schellman, scope statement covers the customer-service-AI product line, surveillance audit December 2026). SOC 2 Type II + AI Trust Services Criteria report covering January-December 2025 (BDO). Annex IV technical documentation available under NDA. Model card and system card published quarterly. ML-BoM CycloneDX 1.7 signed. Article 25(2) cooperation memo provided. Article 73 incident notification SLA: 24 hours. Right-to-audit clause: standard. Pricing: 18% above the legacy supplier; predictable. Vendor A DDQ result: Sections 1-3, 5-12, 14 Pass; Section 4 GPAI Conditional Pass (Vendor A is downstream of OpenAI; the GPAI Article 53 information comes via OpenAI's Annex XII package which is in scope but with a 30-day refresh cycle, CAR opened to tighten); Section 13 commercial Pass. Vendor A overall: Tier A with one minor CAR. Procurement-ready.

Vendor B. Newer specialist vendor, in market since 2024. ISO 42001: in progress; certification expected Q4 2026 with Coalfire. SOC 2 Type II: report covering July 2025-June 2026 (no AI Trust Services Criteria; legacy SOC 2 only). Model card: present but no system card. ML-BoM: provided as JSON spreadsheet (not CycloneDX). Article 25(2) cooperation memo: vendor's first draft is a three-paragraph statement of intent, no quarterly cadence, no incident-coordination clause. Article 73 incident notification SLA: 72 hours. Right-to-audit clause: vendor's standard template; deployer asked for amendments and vendor declined. Pricing: 6% below the legacy supplier; attractive. Vendor B DDQ result: Sections 1, 2, 5, 6, 9, 10, 13, 14 Pass; Section 3 cooperation Conditional Pass with CAR for the proper memo by signature; Section 4 GPAI Conditional Pass (Vendor B is downstream of Mistral; the Annex XII receipts are partially available); Section 7 assurance Conditional Pass (ISO 42001 pending; SOC 2 lacks AI Trust Services Criteria); Section 8 security Conditional Pass (OWASP coverage attestations partial); Section 11 Article 73 Conditional Pass (72-hour SLA exceeds the deployer's required 24-hour); Section 12 contractual Fail (right-to-audit clause refused). Vendor B overall: Tier D - Section 12 Fail on a program-blocking section. Not procurement-ready as offered.

Procurement-decision memo. The procurement-decision memo to the Chief AI Officer and General Counsel concludes: (1) Vendor A is procurement-ready at Tier A with one minor CAR scheduled for closure by Q1 2027; (2) Vendor B is not procurement-ready as offered and is Tier D on the contractual-flow-down section; (3) if Vendor B is willing to revisit Section 12 (right-to-audit) and Section 11 (incident SLA), Vendor B may upgrade to Tier C; (4) the recommendation is to award to Vendor A at 18% above the legacy supplier, on the basis that the AI-Act-defensibility delta versus Vendor B materially exceeds the 24% pricing spread when Article 99(3) penalty exposure is priced into the decision; (5) the negotiating position with Vendor B is open for the next 30 days to give Vendor B a chance to remediate, which becomes the backup-vendor track. The memo is signed by the Chief AI Officer, General Counsel, and CFO and retained per Article 18 (10 years).

Cross-Walks and Penalty Exposure

The 2026 AI-DDQ cross-walks to the regulatory and standards stack as follows. EU AI Act: Articles 3(3) and 3(4) (provider / deployer definitions), Article 6 and Annex III (high-risk classification), Article 11 and Annex IV (technical documentation), Article 16 (provider obligations), Article 25(1)(a)(b)(c) (provider transitions), Article 25(2) (vendor cooperation with deployer), Article 25(4) (EU representative), Article 26 (deployer obligations), Article 27 (FRIA), Article 47 (CE marking), Article 51 (GPAI systemic-risk designation), Article 53 (GPAI obligations), Article 55 (GPAI systemic-risk obligations), Article 71 (EU database), Article 72 (post-market monitoring), Article 73 (serious-incident reporting), Article 99(3) (penalties). Annexes IV, XI, XII. NIST AI RMF: Govern 6.1 third-party risk, Govern 6.2 third-party transparency, Map 4.1 contextual risks. ISO/IEC 42001: Annex A.10 third-party AI. Vendor-risk industry: Shared Assessments SIG, CSA CAIQ, AICPA SOC 2 with AI Trust Services Criteria. Software supply chain: CycloneDX 1.7 ML-BoM specification, NTIA SBOM minimum elements. Security: OWASP LLM Top 10 (2025-2026 update), OWASP Agentic Top 10, MITRE ATLAS v5.4.0. Privacy: GDPR Article 28 (processor), Article 9 (special category), Schrems II SCCs. Copyright: DSM Directive Article 4(3) TDM opt-outs.

Penalty exposure. The DDQ exists because Article 99(3), €15M or 3% of global turnover, whichever is higher, applies to the deployer where Article 26 obligations are not met. The deployer cannot meet Article 26 without the vendor's cooperation. The vendor's cooperation cannot be verified without the DDQ. A deployer that procures a vendor on a SIG-only DDQ and then has an Article 26 finding has no audit trail to show that diligence was performed. The DDQ is the audit trail. On top of the statutory penalty, reputational exposure compounds: a regulator-published finding of a defective vendor-risk program is its own commercial harm.

Key Takeaways

• The standard vendor DDQ stack, SIG, CAIQ, SOC 2 Type II, ISO 27001, GDPR Article 28 DPA, is necessary but insufficient for AI vendors in scope of the EU AI Act. It does not cover provider-versus-deployer status, Annex IV documentation pass-through, Article 25(2) cooperation, GPAI Article 53 / 55 obligations, ML-BoM, fine-tune lineage, ATLAS / OWASP coverage, or AI-specific independent assurance.
• The dedicated AI-DDQ runs ~120-150 questions across 14 sections: vendor and system identification; EU AI Act status; Article 25(2) cooperation evidence; GPAI Article 53 / 55 obligations; model and system card disclosure; ML-BoM; independent assurance (ISO 42001, SOC 2 + AI Trust Services Criteria, pen-test, red-team); security controls (OWASP LLM Top 10, Agentic Top 10, MITRE ATLAS v5.4.0); data privacy and provenance; operational resilience; Article 73 incident reporting; contractual flow-down; pricing; vendor concentration and AI supply chain.
• Scoring is three-state per question (Pass / Conditional-Pass-with-CAR / Fail) and aggregates to four vendor tiers (A / B / C / D), mapped to the model-inventory risk tier from lesson 069. Section Fails on Sections 1, 2, 3, 7, or 11 are program-blocking.
• Vendor pushback patterns are predictable: "we don't share that," "we are not high-risk in our jurisdiction," "ask the foundation-model provider," "ISO 27001 covers it," "this is too much paperwork," "our legal team cannot answer that." Each has a documented counter-argument grounded in Article 25(2), Article 26, and Article 99(3) penalty exposure.
• The Acme worked example produces a Tier A award to Vendor A despite an 18% premium, on the basis that Vendor B's Section 12 contractual-flow-down Fail and Tier D overall makes Vendor B not procurement-ready as offered, and the AI-Act-defensibility delta materially exceeds the pricing spread.
• Article 99(3) penalty exposure of €15M or 3% of global turnover applies to the deployer where Article 26 obligations are unmet; the DDQ is the audit trail that defends the deployer's vendor-risk program at audit.
• The AI-DDQ cross-walks to EU AI Act Articles 3(3)/3(4), 6, 11, 16, 25, 26, 27, 47, 51, 53, 55, 71, 72, 73, 99; Annexes III, IV, XI, XII; NIST AI RMF Govern 6.1/6.2 and Map 4.1; ISO 42001 A.10; the Shared Assessments SIG and CSA CAIQ baselines; SOC 2 + AI Trust Services Criteria; CycloneDX 1.7 ML-BoM; OWASP LLM and Agentic Top 10; MITRE ATLAS v5.4.0; GDPR Articles 9, 28, and Schrems II; DSM Directive Article 4(3) TDM opt-outs.
• The DDQ is owned by Procurement, scored by the AI Governance lead with the CISO and Privacy Officer, decided by the Chief AI Officer with General Counsel sign-off, and retained for ten years per Article 18 as part of the deployer's audit-defensibility file.