A pattern has surfaced in enterprise procurement through the first half of 2026 that buyers and in-house counsel are still catching up with. **PYMNTS reported in June 2026, in an article titled "Enterprise SaaS Contracts Are Secret AI Training Licenses,"** that the standard terms of many AI-enabled enterprise software agreements quietly grant vendors broad rights to use customer data to train and improve their models. The piece draws on contract-analysis work by **Stanford Law CodeX in partnership with TermScout**, which has been systematically reviewing the terms of service and master agreements of commercial AI products.
The CodeX / TermScout analysis, as summarized in the reporting, surfaces three numbers that should anchor any 2026 procurement conversation. **Roughly 92% of AI contracts claim data-usage rights beyond what is strictly necessary to deliver the service**, compared with a 63% market average for SaaS more broadly. **Only 17% of AI contracts commit clearly to compliance with all applicable laws**, against 36% for standard SaaS. And — the structural point — **legacy boilerplate phrasing like "improve," "build," "enhance" or "develop the product" is broad enough to encompass model training, fine-tuning and downstream AI use cases**, even where the contract was signed before the vendor offered an AI feature.
In practice that means a contract a procurement team signed in 2022 for a customer-support platform, a code repository, an analytics product or a contract-management tool can — under its existing terms — authorize the vendor to use the buyer's data to train an AI model the buyer never knew about. This article is the buyer-side audit playbook. It is written from the perspective of an in-house team that needs to act, not a market commentary on whether the practice is acceptable.
Three structural reasons explain how the industry got here.
The first is **inherited boilerplate**. SaaS master agreements have for two decades included a vendor right to use "service data" to "improve, develop and enhance the product." Drafted in an era when "improve the product" meant fixing bugs and adding features, the same wording in 2026 covers training a foundation model on customer inputs.
The second is **definitional drift**. The defined term that matters — usually "Service Data," "Usage Data" or "Customer Content" — has not been re-litigated in most contracts even as the categories of data flowing into AI systems exploded. A vendor that gained access to chat transcripts, support tickets, repository content, financial records or contract drafts under a definition that excluded "personal data" may now have a contractual basis to use everything in that category for training, with only an opt-out — and sometimes not even that.
The third is **opacity by default**. The 2026 CodeX / TermScout reading that only 17% of AI vendors commit clearly to applicable-law compliance, against 36% for SaaS broadly, reflects a deliberate drafting choice to leave latitude on jurisdiction, regulator interaction and downstream use. The clauses are not hidden — they are in plain text in the master agreement and the data processing addendum — but they are written to be passively accepted rather than actively negotiated.
A practical standard has emerged in 2026 among in-house teams who have done the work. It is not a maximalist position. It is the floor below which a buyer should not sign an AI-enabled SaaS contract that touches non-public data.
**Opt-out at minimum.** A contractual right to disable any use of customer data for model training, evaluation or improvement of any model other than a model exclusively serving the customer's own tenant. The opt-out must be effective at the master-agreement level, not buried in a console toggle the vendor can unilaterally change.
**Opt-in for any training.** The default state for training on customer data is **off**. Any change requires written authorization from a named customer signatory. No automatic enrollment when a new product feature ships.
**Contractual prohibition on cross-customer model improvement.** The vendor may not use customer data to improve any model whose outputs are served to other customers, even in aggregated, anonymized or de-identified form. The de-identification carve-out is the loophole that swallows the protection in most 2026 vendor contracts; close it explicitly.
**Audit and disclosure.** The vendor maintains an inventory of models trained on or fine-tuned with customer data, the categories of data used and the retention period, and discloses the inventory on request.
**Deletion on termination.** All models, model weights, embeddings, training artefacts and derived datasets containing or derived from customer data are deleted on contract termination, with a written attestation. The standard "we cannot un-train a model" answer is no longer acceptable as a contractual escape.
These five clauses are the difference between a contract that protects the buyer and one that documents the buyer's exposure.
The audit below is what we run for enterprise clients in 2026 when we sit on the buyer side of an AI-enabled SaaS engagement. It is sequenced for a single contract review and is scalable to a portfolio sweep.
The clauses that matter are almost never in the order form. The buyer's lawyers need the **master subscription agreement**, the **data processing addendum (DPA)**, the **AI addendum or AI terms** if one exists, and the **acceptable use policy**. The four documents reference each other, and the AI-specific terms often live in the latest of them to be amended. Insist on the live versions, not the marketing PDF.
In the master agreement and the DPA, search for the phrases that 2026 reading shows are doing the work: "improve, develop or enhance the Services," "to provide and improve our products," "in connection with operating our business," "to develop new features," "machine-readable use," "aggregated and de-identified," "service improvement," "research and development." Flag every occurrence. Each is a candidate to be narrowed or struck.
Independent of the contract text, build a one-page inventory of what the vendor's product actually ingests. **Source code?** (Code repositories, IDEs, code-review tools, contract-management tools that accept attached repositories.) **Financial records?** (ERPs, FP&A tools, billing platforms, expense tools.) **Customer personal data?** (CRMs, support platforms, marketing tools, analytics tools.) **Legal and contract content?** (CLM tools, e-signature platforms, contract analytics.) The category determines the severity of the broad rights the contract grants. A grant of training rights over a marketing analytics export is different from a grant over the contents of your code repositories or your legal contract corpus.
Present the five-clause standard above as the buyer's baseline. Mature vendors will accept some or most. Vendors who refuse all five are signaling a business model that depends on customer data as a training corpus; that is information the procurement team needs before signing.
Some categories of data should not transit a multi-tenant AI vendor under any contract. Source code that constitutes the company's competitive moat. Legal contract corpora that contain privileged material. Customer personal data in regulated sectors where the legal basis for transfer is contested. For those categories, the right answer is to build a sovereign alternative — a single-tenant deployment of an open-weights model, a custom application against a hosted model under a no-training contract, or a fully bespoke build — rather than to negotiate the multi-tenant vendor terms down. Our [custom software development practice](/en/services/software-development) is structured precisely for that "build the sovereign alternative" path, and the [API integration service](/en/services/software-development/api-integration) covers the case where you keep the third-party SaaS but route the AI-sensitive flows through a controlled gateway you own.
For European buyers, the contract conversation is also a legality conversation. Training a foundation model on customer personal data requires a lawful basis under the GDPR. "Legitimate interest" — the basis vendors usually invoke — is contested for foundation-model training; multiple European data-protection authorities through 2025 and 2026 have signaled skepticism. A buyer that ticks an opt-in box on the vendor's behalf is not curing the underlying legal-basis problem for the vendor; it is also exposing itself, as the controller, to a regulator who will see the buyer as the entity that authorized the processing.
The practical implication: for any data category that includes EU personal data, the negotiated position is opt-out at minimum, and opt-in is reserved for tenant-only models with documented purpose limitation and a defensible legal basis specific to the use case. Generic opt-in to "training" without those specifics is a regulatory risk the buyer carries, not the vendor.
This is also where the cybersecurity perimeter of the buyer's own environment matters. A vendor contract that protects you on paper is undermined if your own access controls, secrets management and data classification let sensitive data flow into the vendor without governance. Our [cybersecurity practice](/en/services/cybersecurity) covers the upstream controls — data classification, DLP, identity boundaries — that make the contractual protections enforceable in practice.
In-house teams considering the build-sovereign path will encounter the cost objection: bespoke development and dedicated hosting cost more per unit than a multi-tenant SaaS seat. The objection is true on the headline rate and incomplete on the loaded cost. The loaded cost of a multi-tenant AI vendor that uses your data for training includes the regulatory exposure, the loss-of-IP risk, the difficulty of switching once a vendor has trained on your corpus, and the ongoing per-token inference bill the vendor passes through.
For teams considering the build path on cost-sensitive workloads, the AI agent FinOps discipline matters as much as the contract. Token budgets, model routing and a deliberate run-economics choice — covered in our companion piece, [AI Agent FinOps: Why Most Enterprises Can't See What Their AI Agents Cost](/en/blog/ai-agent-finops-runtime-cost-visibility-playbook-2026) — are what make the sovereign alternative competitive on operating cost, not just on legal posture.
The geography of the build team is part of the equation. A sovereign build delivered by a nearshore team with European time-zone overlap, GDPR-aligned operations and senior engineering rates from roughly fifteen euros per hour changes the buy-versus-build math materially compared with a US or Western-European build. The full positioning of our nearshore delivery is in [why Morocco](/en/why-morocco).
For an enterprise legal and procurement team starting from scratch, the program that has worked for our clients is compressed and pragmatic.
**Week 1.** Build the portfolio inventory: every AI-enabled or AI-adjacent SaaS contract, the four documents per contract, the data categories flowing in, the renewal date.
**Week 2.** Triage by risk: contracts touching source code, customer personal data, legal corpora and financial records go to the top of the queue. Run the five-step audit against the top decile.
**Week 3.** Open negotiations on the top decile contracts whose terms fail the five-clause floor. Adopt a standard buyer-side AI rider that codifies the floor and append it to every renewal.
**Week 4.** For the contracts the vendor refuses to amend on categories that should not transit a multi-tenant AI vendor, scope the sovereign alternative — the build, the controlled gateway, or the single-tenant deployment — with a real budget and a real owner.
Thirty days does not close every contract. It does end the period in which the organization does not know what it has signed.
The 2026 evidence — 92% of AI contracts claiming usage rights beyond service necessity, 17% committing clearly to applicable-law compliance, inherited "improve the product" language quietly extending to model training — is not a vendor-side scandal. It is a buyer-side wake-up. Enterprises that audit their AI-enabled SaaS portfolio against a clear in-house standard, negotiate the five-clause floor, and build sovereign alternatives for the categories of data that should never have left their perimeter, will end 2026 with a defensible governance posture. Enterprises that defer the audit will end the year discovering — usually through a regulator, an incident or a vendor announcement — what they actually agreed to. ${CTA_SAAS_CONTRACTS}
As reported by PYMNTS in June 2026, the Stanford Law CodeX and TermScout review of AI software contracts found that roughly 92% of AI contracts claim data-usage rights beyond what is strictly necessary to deliver the service (versus 63% for SaaS more broadly), and only 17% commit clearly to compliance with all applicable laws (versus 36% for standard SaaS). Inherited "improve the product" language is broad enough to encompass model training.
In many cases yes, if the master agreement granted rights to use "Service Data" or "Customer Content" to "improve, develop or enhance" the product. The definitional drift between 2022 and 2026 means that pre-AI boilerplate now extends, on a literal reading, to model training and fine-tuning. The audit playbook in this article is the way to find out for a specific contract.
Opt-out at minimum on training; opt-in (not default) for any training on customer data; contractual prohibition on cross-customer model improvement, with no de-identification carve-out; vendor inventory of models trained on customer data with categories and retention disclosed on request; and deletion of all models, weights, embeddings and derived artefacts on contract termination, with written attestation.
Search for "improve, develop or enhance the Services," "to provide and improve our products," "in connection with operating our business," "to develop new features," "machine-readable use," "aggregated and de-identified," "service improvement," and "research and development." Each is a candidate to be narrowed or struck in the next renewal.
Contested. Multiple European data-protection authorities through 2025 and 2026 have signaled skepticism toward legitimate-interest as a lawful basis for foundation-model training on personal data. For EU personal data categories, the defensible position in 2026 is opt-out at minimum, with opt-in reserved for tenant-only models with documented purpose limitation and a use-case-specific legal basis.
For data categories that constitute the company's competitive moat (proprietary source code), privileged material (legal contract corpora), or regulated personal data in sectors where third-party transfer is contested. In those cases the right answer is a sovereign build — a single-tenant deployment of an open-weights model, a controlled gateway over a hosted model with a no-training contract, or a fully bespoke application — not contract negotiation.
We deliver custom development engagements aligned with GDPR data ownership, single-tenant deployments and controlled AI gateways, executed by senior engineers from a nearshore hub on Central European Time with rates from roughly fifteen euros per hour. The combination of European time-zone overlap, GDPR-aligned operations and nearshore economics makes the sovereign alternative competitive on operating cost, not just on legal posture.
CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai — contact@callitdev.com — +212-537-373777