Why AI regulation now sets the terms for SaaS contracts

Crucially, the Act also creates rules for General-Purpose AI (GPAI) models (the foundation models behind tools like GPT-4, Claude, or Gemini), with extra obligations for models deemed to carry "systemic risk" based on compute thresholds. Source: EU AI Act official text summary, European Commission.

In the US, there is no single federal AI law as of 2026. Instead, a patchwork of state rules is emerging: Colorado's AI Act (targeting high-risk automated decision systems), California's various AI transparency and automated decision-making rules, and sector-specific guidance from bodies like the FTC (Federal Trade Commission) on deceptive AI claims. This fragmentation is itself a compliance burden: a SaaS vendor selling nationally may need different disclosures state by state.

How this lands inside actual contracts

Enterprise buyers, especially in regulated sectors (banking, insurance, healthcare), now push AI-specific clauses into DPAs and Master Service Agreements. Common additions in 2026:

• Model provenance disclosure: name the underlying model provider (OpenAI, Anthropic, Google, Mistral, or an open-weight model the vendor hosts itself).
• Risk tier attestation: a written statement of where the embedded AI feature falls under the EU AI Act's tiers, even for US-only customers, because many enterprise buyers operate globally.
• Right to audit or request model cards: documentation describing training data provenancedata provenanceData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition →, known limitations, and evaluation results.
• Data flow restrictions: prohibiting customer data from being used to train the underlying foundation model, or requiring opt-out confirmation.
• Liability allocation: who is responsible if the AI feature produces a discriminatory hiring recommendation or a hallucinated compliance answer, the SaaS vendor, or the upstream model provider?

That last point is where most vendors get caught flat-footed.

What a vendor actually inherits by embeddingembeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.View full definition → a third-party model

If your SaaS product calls an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → from OpenAI or Anthropic to power a "smart summarize" feature, you do not get to say "that's their model, not our problem." Under both the EU AI Act and most enterprise contract norms, the deployer (the company putting the AI system into a specific use context) carries real obligations even when it did not build the underlying model.

Concretely, a SaaS company embeddingembeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.View full definition → a third-party large language modellarge language modelA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → (LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition →) typically inherits:

1. Classification responsibility: you must assess whether *your specific use case* (not the base model in the abstract) falls into a high-risk category. A general chatbot is low risk; the same model wired into a resume-screening feature is high risk under the EU AI Act.

2. Transparency duties: telling end users they are interacting with AI-generated output.

3. Human oversight requirements: for high-risk uses, ensuring a human can review and override AI outputs before consequential decisions are made.

4. Data governanceData governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition →: confirming what customer data flows to the model provider, whether it is retained, and whether it could be used for further training.

5. Incident and error logging: increasingly expected practice, keeping records of model failures or overrides, useful both for audits and for post-incident review.

The upstream provider (OpenAI, Anthropic, etc.) typically retains obligations only for the base model itself (its own conformity assessments as a GPAI provider). The deployer obligations are yours.

A simple way to see the exposure

A useful mental model, adaptable as a quick internal checklist:

This is not code that runs, it is the kind of structured risk triage a product and legal team should run together before shipping any AI feature, and increasingly, before signing the DPA that a customer's procurement team sends back redlined.

Why this matters even for "boring" SaaS

It is tempting to think this only applies to obviously sensitive domains like hiring or credit. But EU AI Act obligations and US state rules increasingly reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → into ordinary SaaS functions: AI-assisted customer support that could give faulty medical or financial guidance, AI scheduling tools that indirectly affect access to services, or AI content moderation that shapes what users see. The classification exercise has to be done use case by use case, not product by product.

What good governance looks like in practice

Vendors that handle enterprise deals smoothly in 2026 tend to do three things early:

• Maintain a living AI inventory: every feature using AI, which model powers it, what data it touches, and its risk classification. This is what gets attached to security questionnaires instead of scrambling each time.
• Pre-negotiate model provider terms: knowing in advance what OpenAI, Anthropic, or other providers commit to on data retention and training use, since your customer contract cannot promise more than your upstream contract allows.
• Build a human-in-the-loop path for anything touching employment, credit, healthcare, or safety decisions, even if the current feature feels low stakes, because reclassification is easier to defend than retrofitting oversight after an incident.

For a practical overview of how these risk tiers mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → to obligations, the NIST AI Risk Management Framework (US, voluntary but widely referenced) is a solid complement to the EU's binding rules, useful for vendors trying to build one internal governance process that satisfies both regulatory logics.

Key Takeaways

• AI regulation has moved from policy debate to contract language: DPAs and security questionnaires now routinely ask about embedded model provenance, risk classification, and data flows.
• The EU AI Act's four risk tiers (unacceptable, high, limited, minimal) apply to specific use cases, not just to models in the abstract; the same LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → can be low risk in one feature and high risk in another.
• US regulation remains fragmented across states (Colorado, California, and others), while the EU has one binding framework, creating extra complexity for vendors selling in both markets.
• Deploying a third-party model does not offload responsibility: SaaS vendors inherit classification, transparency, human oversight, and data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → obligations even when they did not build the underlying model.