The modern
SaaS contract.

For two decades, SaaS contracts followed a stable template: an MSA up top, an order form per deal, a DPA stapled on after the GDPR landed in 2018, and a BAA for healthcare buyers. The negotiation moves were predictable. Procurement scored you on uptime, data residency, and a limitation-of-liability cap pegged to one year of fees.

Then three things happened, almost simultaneously. AI vendors moved into the enterprise stack and brought a category of risk procurement teams had never priced. Privacy regulators tightened Article 28 sub-processor obligations and made transfer impact assessments operational. And US states started shipping their own privacy and AI laws on a quarterly cadence: Colorado, Connecticut, Utah, Texas, the EU AI Act spilling over, the NYC bias-audit rule landing in HR tooling.

The contract package that worked in 2022 doesn’t close enterprise deals in 2026. The clauses didn’t age. The world around them did.

Every enterprise procurement team you sell to now has “What is your AI policy?” on the security questionnaire. If you can’t answer it credibly, you don’t close the deal, or you close it on much worse terms because they’ve flagged you as risky.

The credible answer has three parts. A written, board-approved AI Use Policy. A vendor risk process for evaluating the AI you use. And evidence: sub-processor lists, training records, output review attestations. The policy must be operational, not just papered.

Most mid-market vendors don’t have any of this yet. The first ones to ship a credible answer are picking up enterprise deals that used to go to incumbents.

The modern stack is MSA + Order Form + DPA + AI Addendum + Sub-processor List, with the BAA layered in for healthtech and the SCCs layered in for cross-border. The order matters: and so does which document is the controlling one when they conflict.

We map the architecture in detail in CSLA Module 01 and the corporate training pillar 01. The headline: every clause that used to be one paragraph in the MSA now has its own document, its own audience, and its own negotiation cycle.

AI clauses now appear in three places: the AI Use Addendum (operational obligations), the IP section (training data + ownership), and the indemnity section (AI-specific carve-outs and super-caps). Each one has to align: and most templates don't.

The frameworks worth aligning to are ISO/IEC 42001, NIST AI RMF, and the EU AI Act risk tiers. The Colorado AI Act adds employer-side obligations. None of these are optional anymore. They're showing up in procurement scoring.

Article 28 made sub-processor lists operational. Cross-border transfers made TIAs operational. Together they turned the DPA from a one-time contract negotiation into an ongoing privacy program obligation.

The DPA discipline isn't about drafting a better DPA. It's about running a sub-processor list, a TIA file, and a vendor review cadence that survives a regulator visit. The contract is the artifact; the program is the work.

AI-specific indemnities are now the most negotiated section of an enterprise SaaS contract. The structure: a baseline IP indemnity, an AI-output indemnity carve-out, a super-cap for IP and AI claims, and a separate cap for confidentiality and data breach.

The negotiation is no longer just about cap size. It's about which carve-outs hold under what scenarios: and whether the vendor's insurance actually backs the indemnity. We spend a full module on this in CSLA.

A modern contract package looks like this: a clean MSA, an Order Form per deal, a DPA that aligns with a real sub-processor program, an AI Addendum that maps to a written AI Use Policy, and an indemnity structure with carve-outs and super-caps that actually hold.

The teams that ship this win the enterprise deals. The ones that don't lose them: quietly, on the procurement scorecard, before they ever get to negotiation.