L8.3.2 — Procurement & vendor management for AI¶

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: NIST AI RMF Govern 6.1 · OWASP LLM05 (Supply Chain) · EU AI Act provider obligations

Learning objectives¶

Identify the AI-specific additions to a classical vendor security review.
Recognize three contractual provisions every AI vendor contract should include.

Core content¶

AI-specific additions to vendor security review¶

Most organizations have a standard vendor security review process — SOC 2 report, security questionnaire, DPA, etc. For AI vendors (foundation-model providers, fine-tuning services, agent platforms, eval tools), classical review is necessary but not sufficient. Six AI-specific additions:

1. AI-BOM disclosure. Vendor publishes a list of artifacts (base models, fine-tunes, datasets, key dependencies) their service uses. Allows you to assess transitive supply-chain risk.

2. Training-data governance. Vendor describes data sources, filtering, dedup, eval-set isolation. Particularly important for vendors fine-tuning on your data.

3. Safety / robustness evaluation results. Vendor publishes evals against safety benchmarks, jailbreak resistance, adversarial-robustness measurements. Vague claims fail this; specific PGD-AT scores, AutoAttack results, jailbreak-resistance metrics satisfy.

4. Incident-response procedures. Vendor describes their AI incident response — what triggers internal IR, how they notify customers, what timelines apply.

5. Sub-processor list. All third parties handling your data flowing through the vendor. Same standard as classical DPA sub-processor list, applied to the AI vendor's stack.

6. Compliance attestations. SOC 2 standard. Plus AI-specific: NIST AI RMF alignment statement, EU AI Act compliance posture (if applicable), sector-specific (HIPAA, FedRAMP, etc.).

The vendor questionnaire should ask all six. If the vendor doesn't have answers, that's a signal — either the vendor is immature on AI security or hasn't been pressed by previous customers.

Three contractual provisions¶

Beyond the security review, three provisions to negotiate into AI vendor contracts:

1. Data-use restrictions. Explicit prohibition on using your data for model training without consent. Many foundation-model vendors offer "zero-data-retention" or "no-training-on-your-data" tiers; insist on them for sensitive workloads. Get it in writing in the MSA.

2. Incident notification SLAs. Specific timelines for vendor-to-customer notification when an AI incident occurs that affects your data or your usage. 72 hours for confirmed exposure is the EU AI Act-aligned default; some customers negotiate 24 hours.

3. Sub-processor change notice. Vendor must notify you before adding new sub-processors. Gives you the option to terminate if a new sub-processor is unacceptable (e.g., a new training-data provider you don't trust).

These mirror standard DPA / data-protection contractual norms; the AI-specific framing is what makes them enforceable for AI-context incidents.

When to walk away from a vendor¶

Three deal-breakers worth standing on:

Refusing to disclose model provenance. "We won't tell you which foundation model powers our product" — walk. The transitive supply-chain risk is unauditable.
Using your data for training without explicit opt-out. "We train on your data, that's why we're cheaper" — walk if your workload is sensitive. The privacy and IP risk is too high.
No incident-response procedures or vague ones. "We'll let you know if anything serious happens, generally speaking" — walk. The SLA gap will hurt during a real incident.

These aren't always negotiable; budget vs risk decision. But the AI security engineer should clearly flag each before contracts are signed.

The procurement question template¶

A reusable question set for vendor review:

1. Model provenance:
   - What foundation model(s) power your service?
   - What versions, who's the provider?
   - Do you offer signed model attestations?

2. Data handling:
   - Do you use customer data for training? Yes/No/Optional.
   - Retention: how long, where stored, encryption.
   - Sub-processors: complete list.

3. Safety + robustness:
   - Published eval results: link.
   - PGD-AT / AutoAttack scores: <values>.
   - Jailbreak-resistance metrics: <values>.

4. Compliance posture:
   - NIST AI RMF alignment statement: yes/no/in-progress.
   - EU AI Act risk-tier classification of your service: <tier>.
   - SOC 2, FedRAMP, HIPAA: yes/no, with most-recent report.

5. Incident response:
   - Customer notification SLA: <hours>.
   - Recent AI-specific incidents: disclosure available?
   - Post-incident reporting: process described.

6. AI-BOM:
   - AI Bill of Materials for your service: link.
   - Update frequency.

Use this as the AI section of any vendor security questionnaire. The L8.7 lab includes a worked example.

Real-world example¶

Enterprise customers buying AI products in 2025–2026 increasingly send some form of this questionnaire to vendors. Vendors that can't answer most of it lose deals; vendors that can answer all of it differentiate. The market is moving rapidly toward "transparency is table stakes."

Key terms¶

AI vendor security review — extended classical review with AI-specific additions.
Data-use restriction — contractual prohibition on training with your data.
Incident notification SLA — vendor-to-customer timeline obligation.
Procurement question template — reusable vendor-questionnaire AI section.

References¶

NIST AI RMF Govern 6.1 (third-party AI).
L4.4–L4.5 (the supply-chain risks this manages).
OWASP LLM05.

Quiz items¶

Q: Name three AI-specific additions to a classical vendor security review. A: Any three of: AI-BOM disclosure; training-data governance; safety/robustness eval results; incident-response procedures; sub-processor list; AI-specific compliance attestations (NIST RMF alignment, EU AI Act posture).
Q: Name three contractual provisions to negotiate into AI vendor contracts. A: Data-use restrictions (no training on your data without consent); incident notification SLAs (e.g., 72 hours); sub-processor change notice.
Q: Name two deal-breaker scenarios in AI vendor review. A: Refusing to disclose model provenance ("won't tell you which foundation model powers our product"); using your data for training without explicit opt-out (for sensitive workloads); vague or absent incident-response procedures.

Video script (~580 words, ~4 min)¶

[SLIDE 1 — Title]

Procurement and vendor management for AI. Five minutes.

[SLIDE 2 — Six AI-specific additions]

Most organizations have a standard vendor security review — SOC 2 report, security questionnaire, DPA. For AI vendors, classical review is necessary but not sufficient. Six AI-specific additions.

AI-BOM disclosure — vendor publishes list of artifacts their service uses. Allows transitive supply-chain risk assessment. Training-data governance — vendor describes data sources, filtering, dedup, eval-set isolation. Safety and robustness evaluation results — vendor publishes evals against safety benchmarks, jailbreak resistance, adversarial-robustness. Specific scores, not vague claims. Incident-response procedures — vendor describes their AI IR: triggers, customer notification, timelines. Sub-processor list — all third parties handling your data through the vendor. Compliance attestations — SOC 2 standard plus AI-specific: NIST AI RMF alignment statement, EU AI Act posture if applicable, sector-specific.

Vendor questionnaire should ask all six. If the vendor doesn't have answers, that's a signal — either immature on AI security or hasn't been pressed by previous customers.

[SLIDE 3 — Three contractual provisions]

Beyond the security review, three provisions to negotiate into AI vendor contracts. Data-use restrictions — explicit prohibition on using your data for training without consent. Many foundation-model vendors offer zero-data-retention tiers. Insist on them for sensitive workloads. Get it in writing in the MSA. Incident notification SLAs — specific timelines for vendor-to-customer notification. 72 hours for confirmed exposure is the EU AI Act-aligned default. Sub-processor change notice — vendor must notify before adding new sub-processors. Gives you option to terminate if a new sub-processor is unacceptable.

[SLIDE 4 — Three deal-breakers]

Three deal-breakers worth standing on. Refusing to disclose model provenance — "we won't tell you which foundation model powers our product." Walk. Transitive supply-chain risk is unauditable. Using your data for training without explicit opt-out — "we train on your data, that's why we're cheaper." Walk if your workload is sensitive. Privacy and IP risk too high. No or vague incident-response procedures — "we'll let you know if anything serious happens, generally speaking." Walk. SLA gap will hurt during a real incident.

Not always negotiable. Budget vs risk decision. AI security engineer should clearly flag each before contracts are signed.

[SLIDE 5 — Question template, part 1]

Reusable question set for vendor review. Model provenance: what foundation models, what versions, who's the provider, signed model attestations? Data handling: do you use customer data for training, retention, sub-processors? Safety and robustness: published eval results, PGD-AT and AutoAttack scores, jailbreak-resistance metrics?

[SLIDE 6 — Question template, part 2]

Compliance posture: NIST AI RMF alignment statement, EU AI Act risk-tier classification of your service, SOC 2 and FedRAMP and HIPAA? Incident response: customer notification SLA, recent AI-specific incidents disclosure, post-incident reporting process? AI-BOM: AI Bill of Materials for your service, update frequency?

Use as AI section of any vendor security questionnaire. L8.7 lab includes a worked example.

[SLIDE 7 — 2026 reality + up next]

Enterprise customers buying AI products in 2025-2026 increasingly send some form of this questionnaire to vendors. Vendors that can't answer most of it lose deals. Vendors that can answer all of it differentiate. Market moving rapidly toward "transparency is table stakes."

Next lesson: AI incident reporting obligations. Five minutes.

Slide outline¶

Title — "Procurement & vendor management for AI".
Six AI-specific additions — six-card layout.
Three contractual provisions — three-card layout.
Three deal-breakers — three red-flag cards.
Question template, part 1 — code-block-style question list.
Question template, part 2 — same shape.
2026 reality + up next — market trend + pointer.

Production notes¶

Recording: ~4 min. Cap 5.
Slides 5+6 (the template) should be designed as a downloadable reference.