The AI MSA Red-Team Checklist — what to look for in vendor enterprise contracts

Most AI vendor MSAs in 2026 are recycled SaaS MSAs with an AI-specific addendum bolted on. The recycled SaaS portion is usually fine; standard cloud-procurement legal review handles it. The AI addendum is where the failure modes cluster, and those failure modes are not the ones a generalist legal review will catch. Seven clause families repeatedly create the procurement disputes that surface six to eighteen months into a deployment, and this checklist is the red-team pass for each of them.

The checklist is built for a working session between procurement and legal counsel reviewing actual vendor paper. It is not a substitute for that review; it is the structured reading layer that makes the review consistent across vendors and across renewals. Each item is a yes/no question with a follow-up prompt explaining what acceptable language looks like and what unacceptable language usually contains.

Use the checklist after the AI Vendor Security Questionnaire (RES-001) has been completed. The questionnaire surfaces what the vendor does; the MSA review surfaces what the vendor has contractually committed to. The two answers should be consistent. Where they are not, the discrepancy is the most informative signal in the procurement process.

Clause family 1: Training-data carve-outs (6 items)

The single most common contractual failure mode in 2025 enterprise AI MSAs was a training-data carve-out written so loosely that the vendor retained the right to use customer data for model improvement under conditions the customer did not realise existed.

Acceptable language commits the vendor to not training, fine-tuning, evaluating, improving, or otherwise using customer prompts, completions, embeddings, intermediate agent state, or tool-use traces for any model improvement purpose, with the technical mechanism enforcing this commitment named or referenced in the contract. Unacceptable language uses words like “aggregated,” “anonymised,” “improvement,” “service quality,” or “with appropriate privacy protections” without operational specificity.

1. Does the contract explicitly prohibit using customer prompts for model training, fine-tuning, evaluation, or improvement?
2. Does the prohibition extend to completions, embeddings, intermediate agent state, and tool-use traces?
3. Does the prohibition extend to upstream model providers (Anthropic, OpenAI, etc.) the vendor relies on?
4. Is the technical mechanism enforcing the prohibition named in the contract or referenced in a linked technical document?
5. Does the contract require the vendor to certify on request that no customer data has been used in training?
6. Does the contract specify the audit mechanism the customer can use to verify the prohibition has been honoured?

Clause family 2: Output ownership and IP indemnification (5 items)

AI output ownership is unsettled law in most jurisdictions, and vendor MSAs treat the question with widely varying degrees of seriousness. The acceptable position is that the customer owns its inputs, the customer owns the outputs generated from those inputs, and the vendor indemnifies the customer against IP infringement claims arising from those outputs. The unacceptable position uses language like “to the extent permitted by law” or “subject to applicable third-party rights” without naming what those rights are.

1. Does the contract clearly state that the customer owns the outputs generated by the AI system using the customer’s prompts?
2. Does the vendor indemnify the customer against IP infringement claims arising from model outputs?
3. Is the indemnification cap consistent with the customer’s potential exposure (often: contract value plus a multiplier, not contract value flat)?
4. Does the contract carve out the indemnification for outputs the customer modified after generation, or does it cover the original output as generated?
5. Does the vendor warrant that the model was trained on data the vendor had the right to use, or does the contract place the burden on the customer?

Clause family 3: Model-deprecation and version-change rights (5 items)

The 2024 deprecation of GPT-4 base, the 2025 retirement of multiple Anthropic and Google models, and the ongoing version cadence at all major model providers have made model-deprecation a live procurement risk. Acceptable language gives the customer notice of model changes with a window long enough to test the new version against production workloads. Unacceptable language reserves the vendor’s right to “update, modify, or discontinue” the underlying model without notice or consent.

1. Does the contract specify the notice period for model version changes?
2. Is the notice period long enough for the customer to test the new version against production workloads (typical minimum: 90 days for major version, 30 days for minor)?
3. Does the contract specify the vendor’s obligation to maintain the prior model version during the transition window?
4. Does the contract specify the customer’s rights if the new model materially degrades performance against the original use case?
5. Does the contract specify the migration support the vendor will provide (test environments, prompt re-tuning assistance, A/B comparison tooling)?

Clause family 4: Sub-processor expansion (5 items)

The standard SaaS sub-processor clause assumes a relatively stable vendor stack with notification of new sub-processors and a customer right to object. The AI MSA frequently expands the sub-processor surface as the vendor integrates new model providers, vector stores, evaluation frameworks, and observability tools. Acceptable language requires named-list disclosure with notification SLA and a meaningful right to object. Unacceptable language refers to “categories” of sub-processors without naming them.

1. Does the contract include a named sub-processor list (not categories)?
2. Does the contract require notification of sub-processor additions, with SLA?
3. Does the customer have a right to object to new sub-processors with a meaningful remedy (typically: termination right or carve-out of affected processing)?
4. Does the contract restrict sub-processors to the geographies the customer has approved?
5. Does the contract require the vendor to flow down the customer’s data protection terms to all sub-processors?

Clause family 5: Kill-switch operability and SLA (5 items)

The kill-switch question that the AI Vendor Security Questionnaire surfaces operationally needs to be locked down contractually. Acceptable language commits the vendor to halting the agent within a defined SLA (target: 30 seconds from customer notification), with the kill-switch operationally accessible to a named customer-side party. Unacceptable language commits to “best efforts” or measures the SLA in hours or business days.

1. Does the contract define the kill-switch SLA in seconds?
2. Does the contract identify the customer-side party authorised to invoke the kill-switch?
3. Does the contract specify the procedure for emergency kill-switch invocation outside business hours?
4. Does the contract specify the vendor’s obligations during the kill-switch period (preserve forensic state, halt billing for the affected agents, provide root-cause analysis)?
5. Does the contract specify the customer’s remedies if the kill-switch SLA is not met (service credits are insufficient; consider termination right plus liquidated damages for material miss)?

Clause family 6: Exit-data portability (6 items)

Exit-data portability is the clause that determines whether the customer is locked in or can leave. Acceptable language commits the vendor to providing the customer’s data in a structured, machine-readable format with a retention window long enough for the customer to verify export completeness, and certifying deletion at the end of the retention window. Unacceptable language commits to “reasonable assistance” with export, in formats “selected by the vendor.”

1. Does the contract specify the export format for customer data (structured, machine-readable, schema documented)?
2. Does the contract specify the export SLA (delivery time from customer request)?
3. Does the contract specify the retention window for customer data after termination (long enough for verification)?
4. Does the contract specify the deletion certification the vendor will provide at the end of the retention window?
5. Does the contract include export of derivatives (embeddings, fine-tuning datasets, evaluation traces) generated from the customer’s data?
6. Does the contract include export of audit logs and the documentation required for the customer to satisfy its own retention obligations after termination?

Clause family 7: Regulatory cooperation and AI Act flow-through (6 items)

EU AI Act obligations flow between providers and deployers in both directions, and the 2 August 2026 enforcement window makes the contract language defining that flow active rather than theoretical. Acceptable language commits the vendor (as provider) to supplying the deployer documentation the customer needs under Article 26, cooperating with supervisory authority requests, and notifying the customer of any vendor-side regulatory action. Unacceptable language remains silent on these points.

1. Does the contract commit the vendor to providing Article 26 deployer documentation on request?
2. Does the contract commit the vendor to cooperating with customer DPIAs under GDPR Article 35?
3. Does the contract commit the vendor to notifying the customer of regulatory actions, supervisory authority investigations, or class-action litigation involving the vendor or product?
4. Does the contract commit the vendor to notifying the customer of model changes that affect the EU AI Act risk classification?
5. Does the contract commit the vendor to providing the technical documentation required under Annex IV on request?
6. Does the contract specify the customer’s rights if the vendor’s product loses its EU AI Act conformity assessment after contract signing?

Reading the answers

A vendor MSA that scores yes on 30 or more of these 38 items is contractually serious. A vendor that scores yes on 20–29 is treatable: each gap becomes a redline for negotiation. A vendor that scores yes on fewer than 20 is signalling either that the vendor has not yet developed the contractual discipline that the regulatory frame now expects, or that the vendor’s commercial position depends on retaining the rights this checklist is designed to constrain. Either signal is informative for the procurement decision.

The checklist deliberately does not weight the items. The reason is that weighting depends on the customer’s deployment scope: a kill-switch SLA matters more for an agent with payment-system access than for a knowledge-base retrieval agent, and the customer’s procurement team is in the best position to apply the weighting.

Versioning and review

This checklist is on a 60-day review cycle. New clause families will be added as they emerge in vendor MSAs (the most likely additions in 2026: agent-to-agent authorisation rights, autonomous spending caps, training-data provenance attestations). The current 38 items reflect the failure surface observable in the published 2024-2025 procurement disputes and the supervisory authority decisions that have followed.

Spotted a missing clause family, an unrealistic standard, or a contract language pattern that does not survive your vendor reality? The corrections policy applies.