Verify these 5 safety clauses in discounted AI service terms

Here is the friction we keep seeing inside organizations that take that route: the discounted price is rarely the only thing that has been discounted. Liability limits, training-data waivers, and compliance shortcuts tend to ride along in the same package. The clauses are not hidden in the sense of being concealed. They sit in the standard terms of service, updated between quarterly releases, and they pass internal review only when somebody actually opens the document.

This guide is the field check we run before any team signs a discounted AI agreement. Five clauses, five questions, one short table. If we cannot answer all five to our own satisfaction, the discount is not large enough.

The Data Training Trap: Opt-Out Mechanics That Drift

The first clause we look for is the one that lets the provider use our prompts, completions, and uploaded files to improve their models. In most discounted tiers, the default is opt-in. The provider processes enterprise inputs as training data unless the user navigates to a settings panel, opens a privacy dashboard, or sends a written request to a data protection officer.

This is the trap. Self-service opt-outs look convenient. They are not. The flow goes like this: an admin enables the workspace, the data science team runs three months of pilots, the legal team discovers the opt-out only after a customer dataset has been logged in the vendor's improvement pipeline. The vendor's documentation states the opt-out can be requested at any time, but it does not guarantee retroactive deletion of data already used for training.

We have seen this play out at a logistics company running contract analysis through a discounted LLM tier. Their legal team assumed the enterprise agreement included a training exclusion. It did not. Six weeks of anonymized contract excerpts had already moved into the vendor's fine-tuning queue. The remediation took four months of audits and a formal data-subject notification under GDPR. The discount that attracted them to the tier in the first place was roughly one percent of the incident cost.

The clause that matters is not whether an opt-out exists. It is whether the Data Processing Agreement explicitly excludes customer inputs from model improvement by default. If the DPA is silent on the matter, the default falls back to the terms of service, and the terms of service usually favor the provider.

What we look for in the DPA before signing:

• A clause that names customer inputs as "Confidential Information" or equivalent.

• An explicit statement that inputs are not used for model training, fine-tuning, or evaluation without separate written consent.

• A retention window for telemetry, prompt logs, and abuse-monitoring samples, stated in days, not in vague phrases like "as needed."

• A sub-processor list with a defined update cadence, so we know who else sees the data.

• A deletion confirmation process that provides written evidence, not just a UI toggle that says "opt-out enabled."

A discount that comes with a training-data waiver is not a discount. It is a deferred cost we will pay in compliance hours and customer trust.

The subtlety that catches even experienced procurement teams is the distinction between "we do not train on your data" in a marketing FAQ and "customer inputs are excluded from model improvement" in a binding DPA schedule. The first is a claim. The second is a contractual obligation. If the DPA does not contain the second version in plain language, the first version is worth exactly nothing in a dispute.

Liability Caps That Do Not Match Enterprise Exposure

The second clause is the cap on liability. The industry default, in our experience, is twelve months of fees paid. We see this number across providers, regardless of the discount tier, and it is the line item that most often survives legal review without challenge. The reasoning inside procurement teams goes like this: we are only paying a small amount for the service, so a cap matched to that small amount is reasonable.

The reasoning fails because it compares the wrong two numbers. A twelve-month cap on a discounted AI subscription is typically a four- or five-figure liability ceiling. A single enterprise data exposure event, measured in regulatory fines, customer notification costs, and remediation engineering, runs into seven figures. The cap does not scale with the risk it is meant to cover. The provider is not bearing the residual risk. The user is.

Consider the arithmetic on a discounted tier priced at eighteen thousand dollars annually. A twelve-month liability cap puts the provider's maximum exposure at eighteen thousand dollars. A GDPR fine for a data-processing violation involving sensitive personal data can reach twenty million euros or four percent of global annual turnover, whichever is higher. Even a modest remediation effort, forensics, legal counsel, customer notification, and system hardening, typically costs ten to fifteen times the annual subscription value. The cap is not a safety net. It is a rounding error.

We have watched enterprise teams accept these caps because the alternative is a custom contract, and custom contracts take six to ten weeks. The discount saves money on day one. The gap between the cap and the exposure stays open for the life of the agreement.

The practical test is simple. Does the liability cap scale with the category of data processed, not just the subscription value? For workloads that touch personally identifiable information, financial records, or regulated health data, a flat twelve-month cap is a structural mismatch. We push for either a higher cap, a category-specific carve-out, or a separate cyber-liability policy that the provider acknowledges in writing.

There is a negotiation move that works more often than teams expect: requesting a liability floor tied to the data category. Instead of asking the provider to remove the cap entirely, which they almost never do, we ask for a floor that matches the regulatory exposure of the data we will process. This reframes the conversation from "trust us more" to "align the contract with the actual risk profile," and it gives the provider's legal team a defensible reason to approve the change.

Copyright Indemnity and the Question of Who Owns the Output

The third clause covers intellectual property. The standard pattern in discounted AI agreements is two sentences, and both of them work against the user. The first sentence grants the user a license to use the outputs. The second sentence disclaims any warranty that the outputs do not infringe third-party rights.

A copyright indemnity clause, where it exists, says the provider will defend the user against infringement claims arising from the model's outputs. In practice, this clause is often capped at the same twelve-month liability limit, restricted to specific model versions, or limited to claims under United States copyright law. If the team operates in the European Union, the United Kingdom, or any jurisdiction with a different fair-use framework, the indemnity may not travel.

The asymmetry is sharp. The provider charges a fraction of the enterprise price. The user assumes the full weight of any infringement claim generated by the model. We have seen teams discover this asymmetry only after a downstream customer receives a takedown notice on AI-generated marketing copy.

A recent pattern we have tracked is the provider offering indemnity only for outputs generated through their proprietary interface, excluding outputs produced via API calls where the user has applied any custom prompt engineering, fine-tuning, or retrieval-augmented generation. The practical effect is that the indemnity covers the simplest, lowest-risk use case and vanishes the moment the integration becomes genuinely enterprise-grade. The clause reads like protection. It functions as an escape hatch.

What we verify before signing:

1. Whether the indemnity applies to the specific model version deployed, not just the family name.

2. Whether the cap is uncapped, or at least sized to the worst-case exposure for our use case.

3. Whether the provider maintains a documented process for handling model-output infringement claims, with named contacts and a defined response window.

4. Whether the clause survives termination of the agreement for claims that arise from outputs generated during the contract term.

5. Whether the indemnity covers all jurisdictions where our outputs will be distributed, not just the jurisdiction of the provider's headquarters.

The provider that offers indemnity only for outputs from its default interface is offering a warranty on a sandbox. The enterprise is building in production.

SOC 2 Type II: The Difference Between a Badge and a Report

The fourth clause is about security certifications, and this is where the marketing language and the operational reality diverge the most. A "SOC 2 compliant" badge on a vendor's website tells us that the vendor has engaged an auditor. It does not tell us what the auditor reviewed, which trust services criteria were in scope, or whether the audit was Type I (a point-in-time assessment) or Type II (a multi-month review of operating effectiveness).

Discounted AI tiers frequently rely on self-attestation rather than an independent audit. The reason is cost. A Type II report requires the vendor to operate its controls over a period of months, with evidence collection and auditor walkthroughs. Vendors that compete primarily on price tend to skip this expense. They may have an internal security team and a well-written policy library. They may not have a third party who has tested those controls against an actual production environment.

We have encountered providers who produce a SOC 2 Type II report that covers their corporate IT infrastructure, email systems, and HR platforms, but explicitly excludes the AI inference layer, the model-serving clusters, and the prompt-logging pipeline. The report is technically valid. It is also technically irrelevant to the systems that will touch our data. This is the gap that only reading the full report, not the summary page, will surface.

A SOC 2 badge is a logo. A SOC 2 Type II report is a document. We do not sign enterprise agreements against logos.

The verification step is to request the most recent SOC 2 Type II report, the bridge letter covering the period since the last audit, and the auditor's opinion. We look at the scope: which systems, which regions, which trust services criteria. We check for any qualifications, scope limitations, or exceptions. We confirm that the systems covered in the report are the same systems that will process our data. A report on the corporate IT environment does not cover the inference cluster that runs our prompts.

If the vendor cannot produce a Type II report, we treat the absence as a known risk and price it into the deployment plan. That price usually shows up as additional internal monitoring, stricter access controls, and a slower rollout to high-value workloads.

One additional signal we have learned to watch for: the date of the bridge letter relative to the contract signing. A bridge letter that covers a six-month gap between the end of the audit period and the start of our contract is a period of unmonitored control effectiveness. The shorter that gap, the more confidence we have that the controls described in the report are still operating as audited.

Regulatory Alignment: The EU AI Act and What Discounted Tiers Skip

The fifth clause is regulatory, and it is the one most likely to be missing entirely. The EU AI Act entered into force in August 2024, and its requirements for high-risk AI systems are now in their implementation window. Providers of high-risk systems must maintain detailed technical documentation, a risk management system, a quality management system, post-market monitoring, and a logging infrastructure that supports traceability of model behavior.

Discounted AI tiers, particularly those sold as beta or experimental, often position themselves outside this framework. The terms of service may state that the service is not intended for high-risk use cases, that the user is responsible for determining suitability, or that compliance documentation will be provided on request at additional cost.

The clause we look for is one that explicitly addresses the user's regulatory obligations. The strongest version commits the provider to supporting compliance: providing the technical documentation the user needs to file under Annex IV of the Act, maintaining a register of model versions and training data sources, and notifying the user of material changes that affect the risk classification.

The weaker version contains a single line: the user is responsible for compliance with applicable laws. That line is true, but it transfers the entire documentation burden to the organization buying the service. We have seen teams absorb that burden only to realize, six months in, that the provider cannot produce the artifacts the regulator expects. For organizations operating inside the EU, this clause is not optional. GDPR Article 28 still applies, and the AI Act builds on top of it. Discounted tiers that bypass the documentation requirements are not compatible with high-risk deployment, regardless of price.

There is a practical nuance here that does not show up in the legal text. The EU AI Act requires downstream deployers of high-risk systems to maintain their own risk management documentation. But that documentation depends on upstream artifacts from the provider: training data provenance, model evaluation results, known limitations, and bias testing outcomes. If the provider's terms do not commit to delivering these artifacts on a defined schedule, the deployer cannot fulfill their own obligations. The contract does not need to make the provider responsible for the deployer's compliance. It does need to make the provider responsible for producing the inputs the deployer requires.

How We Run the Audit in Practice

The five clauses are not a theoretical list. They map directly to a workflow we run inside procurement and security reviews. The table below shows the mapping.

If any row returns a no, or if the evidence is incomplete, we have three options: negotiate the clause, narrow the deployment scope, or decline the discount. The third option is the one that requires the most discipline, and it is the one that has saved us the most money over the long run.

The negotiation path works best when the team arrives at the table with a clear internal benchmark. Before the first call with the vendor, we define the minimum acceptable position on each clause and the walk-away threshold. This removes the pressure of improvising during the conversation and gives the procurement lead authority to move on if the vendor cannot meet the floor.

Closing Position

Discounted AI tiers are not inherently unsafe. Some providers price aggressively to win share, and the underlying controls are sound. The risk is not the price. The risk is the contract.

The five clauses above are the ones we will not move on. They protect data, they bound liability, they preserve ownership, they verify security, and they keep us compliant with the frameworks our regulators are now actively enforcing. A discount that asks us to soften any of them is a discount that costs more than it saves.

We have walked away from deals that looked good on the price sheet. We have also closed deals at higher list prices because the clauses were already where we needed them. Either outcome is acceptable. Signing an agreement that we have not audited against these five points is not.

A useful habit, when reviewing any new AI agreement, is to look beyond the price and the model card. The cost of inference, the cost of data transfer, and the cost of compliance drift compound quietly over the life of a contract. The clauses in this guide are the visible line items. The infrastructure and governance costs are the ones that surface twelve months later, when the contract is up for renewal and the total cost of ownership is finally in focus.

Run the audit. Sign with the lights on. The discount will come back if it is real. The trust of your security team, your legal counsel, and your customers is much harder to rebuild.