Not Your Mama’s SaaS: AI Didn’t Change Your SaaS Contract. It Changed What It Means.

Series Introduction

For decades, technology attorneys negotiated SaaS agreements around familiar concepts: customer data, service updates, documentation warranties, indemnities and liability caps. The rise of generative AI has not rendered those provisions obsolete. Instead, it has transformed their significance.

Many organizations are discovering that their AI governance challenges did not begin with an AI agreement. They began with a SaaS agreement signed years ago.

In this three-part series, we examine how AI is changing the practical operation of traditional SaaS contract provisions, the contractual terms that deserve renewed attention and the governance frameworks organizations need as AI-enabled functionality becomes embedded in everyday software products. Based on our presentation “Not Your Mama’s SaaS: Same Clauses. New Consequences,” given during Atlanta Technology Week 2026 at Render(ATL), we explore the legal and commercial issues that arise when familiar contractual language collides with rapidly evolving AI technologies.

That Legacy SaaS Agreement Is Risky in the AI Era

The biggest AI risk in your SaaS agreement may not be hiding in a clause that specifically calls out AI.

It may be hiding in a provision that your organization negotiated years ago.

Most legal teams evaluating AI risk begin by looking for terms such as “artificial intelligence,” “machine learning,” “training” or “large language models.” Increasingly, that approach misses the real issue. Many of the contractual provisions driving today’s AI risk were drafted years before generative AI entered the mainstream. The language has remained the same. The consequences have not.

A Critical Truth

Organizations should stop asking whether their contracts mention AI and start asking whether existing language already permits it.

Our Fact Pattern

Imagine arriving at work and discovering that your organization’s CRM vendor has released a new AI assistant.

The tool drafts customer communications, reviews support tickets, summarizes interactions and accesses information throughout the platform. The feature was activated as part of a routine product update.

No new agreement was negotiated. Procurement was not involved. Legal never reviewed the change. The vendor had previously provided a subprocessor notice, but that notice did not prompt a review of what activating the AI feature would mean for the organization’s data.

Yet overnight:

• A foundation model provider may now process company data.
• New categories of prompts and outputs now exist.
• New online terms may apply through incorporation-by-reference provisions.
• Data may be used in ways that were never contemplated when the contract was signed.

The governing agreement may be five years old. The technology is new, but the contractual provisions on which it relies remain the same. The question is whether its existing update provisions, data-use rights and incorporated terms authorize what the new feature actually does.

The Problem Is ‘Same Clause, New Consequence’

Traditional SaaS contracts contain provisions that appeared straightforward when software was largely deterministic. The problem now is that the clause hasn’t changed, but the consequence of the clause has.

Take a standard update clause, for example. Historically, a provision allowing a vendor to “modify or update the services” meant interface improvements, bug fixes or additional reports. Today, the same provision may authorize deployment of AI functionality that reads customer data and influences customer communications.

Similarly, de-identified data provisions once supported analytics and product development. In an AI environment, the same clause may become the contractual basis for training activities, model improvement or long-term retention of information.

Why Definitions Matter More Than Ever

Many AI contract negotiations focus on risk allocation. Equally important issues arise from definitions. Before evaluating warranties, indemnities and liability caps, legal teams need to understand what information those provisions cover.

The question is not simply whether customer data is protected. It is whether those protections also cover prompts, outputs and information derived from customer data.

Modern AI contract terms increasingly separate data into categories such as:

• Customer data
• Inputs or prompts
• Outputs
• Usage data
• Service data
• Aggregated or de-identified data
• An agreement may classify information derived from customer data as service data, usage data, or aggregated or de-identified data. If confidentiality, use restrictions and return-or-delete obligations apply only to customer data, those exclusions can create significant gaps. The question is not simply what the vendor calls the information but which protections and permissions follow it.

‘No Training’ Does Not Answer Every Data-Use Question

A common misconception when contracting for AI-enabled services is that a restriction on training resolves the data-use questions.

In practice, vendors often use data in several distinct ways, including:

• Base-model training
• Fine-tuning
• Evaluation and safety review
• Retrieval

Each activity creates different artifacts, retention concerns, ownership questions and deletion challenges. A restriction on “training” is only a starting point. Legal teams should distinguish base-model training, fine-tuning, evaluation and safety review from retrieval, which allows an AI system to draw on stored information when generating a response.

A clause stating that a vendor will not use customer data for “training” may not address the multiple ways data and an AI system can interact.  Effective drafting requires identifying precisely which activities are permitted, prohibited or subject to separate approval.

While retrieval is not itself model training, it is still important, as retrieval indexes and embeddings can create additional stores of customer information or representations derived from it. The agreement should address their permitted use, retention and deletion rather than assume that a no-training restriction resolves those questions.

The De-Identification Back Door

If there is one legacy provision that deserves renewed scrutiny, it is the de-identified data clause.

Many agreements permit vendors to use (and perhaps own) aggregated and de-identified data to improve products and services. These provisions have long supported analytics, benchmarking and product development. But the label “de-identified” does not establish what standard the vendor must meet or what uses the agreement permits. AI makes both questions more consequential. As discussed above, de-identified data often falls outside customer data and its deletion obligation. The agreement should separately address deletion of source data and the treatment of models developed using that data, rather than assume that a general deletion obligation resolves both. Moreover, where the clause also grants the vendor ownership, the vendor may own the de-identified dataset outright.

Legal teams should also review feedback provisions, product improvement clauses and usage analytics rights, including how those provisions permit de-identified data to be used or owned. A provision that seemed routine when signed may now carry rights far more valuable than the parties contemplated. 

Outputs Create New Questions and New Risks

Traditional SaaS agreements focused primarily on customer inputs and hosted data. AI requires equal attention to outputs.

Questions surrounding ownership, exclusivity, uniqueness and intellectual property protection are now central issues. Outputs may not be unique. Similar prompts can generate similar results for multiple customers. Some vendors expressly disclaim that outputs are protectable intellectual property at all.

At the same time, customers are frequently asked to provide broad warranties regarding everything they submit to AI systems, creating additional diligence obligations and risk allocation questions. This creates a contractual risk tension that must be resolved. The result is an asymmetry: The customer warrants its inputs, while the vendor may give no comparable assurance about outputs. In Part 2 of our series, we will address how to allocate for that risk.

Key Takeaways

One of the most important lessons from this new era of AI contracting is that the highest-risk provisions are not necessarily found in AI addenda or AI-specific terms. They are often found in familiar provisions, negotiated years ago and long treated as routine, that have now acquired new meaning.

For attorneys and procurement professionals, the challenge is not simply understanding AI. It is understanding how AI changes the practical meaning of contract language that already exists.