Most of the real negotiation in an AI beta testing agreement doesn’t happen in the operative clauses. It happens in the definitions.
A clause that says the startup “may use Usage Data to improve the Services” sounds harmless — until “Usage Data” is defined to include prompts, and “improve the Services” includes retraining a model shared across every customer. Change two definitions and the same clause means something entirely different.
This glossary walks through the key terms in an AI beta testing agreement: what each one should capture, sample definition language, and the drafting traps SaaS AI Lawyer Andrew S. Bosin sees most often. For how those terms fit into the full contract, see Andrew’s guide to the beta test agreement for SaaS and AI startups.
Sample language below is illustrative only. It is not a template and should be adapted to the specific product, data, and deal.
Why Definitions Matter More in an AI Beta
In a traditional software beta, definitions are mostly housekeeping. In an AI beta, three things raise the stakes:
- The same data can play several roles. A tester’s correction is an input, a piece of feedback, and a potential training example at the same time. Which definition it falls under decides who controls it.
- Enterprise reviewers read definitions first. Procurement and privacy teams go straight to “Customer Data,” “Usage Data,” and anything mentioning training.
- Regulators read them too. The FTC has warned AI companies that quietly broadening data-use rights through terms changes may be unfair or deceptive. Precise definitions are the first line of defense.
Group 1: The Product and the Parties
Beta Service
What it should capture: the specific pre-release features, models, or endpoints covered by the agreement — not the entire platform.
“Beta Service” means the pre-release features, functionality, and AI models identified in the Beta Order or designated by Company as “beta,” “preview,” or “early access,” including any updates Company makes available during the Beta Period.
Drafting trap: defining the Beta Service as “the Services” generally. That can pull production features — and their warranties or SLAs — into the beta, or pull beta disclaimers into production.
Beta Period
What it should capture: a start date, an end date or trigger (such as general availability), and the effect of early termination.
Drafting trap: no end date. An open-ended beta blurs into production use, and the “as-is” framing gets harder to defend over time.
Authorized Users
What it should capture: who at the tester’s organization may access the beta, and that the tester is responsible for their compliance.
Drafting trap: allowing contractors or affiliates without saying so. They may not be bound by the tester’s confidentiality obligations.
Group 2: What Goes In
Customer Data
What it should capture: everything the tester or its users submit to the Beta Service. This is usually the umbrella term, with Inputs as a subset.
“Customer Data” means all data, content, and materials that Customer or its Authorized Users submit, upload, or otherwise provide to the Beta Service, including Inputs, but excluding Usage Data and Feedback.
Drafting trap: failing to exclude Usage Data and Feedback expressly. Without that carve-out, every right the startup takes in Usage Data can be argued to reach Customer Data too — or the reverse.
Inputs
What it should capture: prompts, queries, instructions, files, and other material submitted to the AI model specifically.
Drafting trap: treating system prompts, retrieval-augmented context, and tool results as the tester’s Inputs. Material the startup injects into the model is typically the startup’s own and should be carved out.
Prohibited Data
What it should capture: categories the tester may not submit without a separate written agreement — typically protected health information, biometric identifiers, children’s data, payment card data, government ID numbers, and certain regulated personal data.
Drafting trap: a vague “sensitive data” label with no list. A defined term with specific categories gives the startup a clear right to delete non-conforming uploads.
Group 3: What Comes Out
Outputs
What it should capture: content generated by the AI model in response to Inputs.
“Outputs” means text, code, images, data, and other content generated by the Beta Service in response to Inputs, excluding the Beta Service itself and any Company templates, formats, or materials incorporated into such content.
Drafting trap: defining Outputs broadly enough to include the startup’s own templates, formatting, or scaffolding. Outputs are usually assigned to the tester, so over-inclusion gives away startup IP. Output ownership and copyright limits are covered in Andrew’s article on who owns customer content in an AI beta.
Customer-Specific Model
What it should capture: any model, fine-tune, adapter, embedding index, or configuration created using a particular tester’s data and used only for that tester.
Drafting trap: leaving this undefined. Without it, there’s no clean way to say the startup owns the weights while the tester gets exclusive use — and the two sides will assume different things.
Group 4: What Comes Back
Feedback
What it should capture: suggestions, bug reports, feature requests, and evaluations of the Beta Service.
“Feedback” means suggestions, comments, bug reports, feature requests, and other evaluations of the Beta Service provided by Customer or its Authorized Users. Feedback does not include Customer Data, Inputs, or Outputs, except to the extent expressly incorporated into a written Feedback submission.
Drafting trap: the AI-specific one. If thumbs-up and thumbs-down ratings and edited corrections to Outputs fall inside “Feedback,” and Feedback is licensed broadly, the startup may have training rights it never negotiated for — or the tester may argue the reverse. Decide expressly whether ratings and corrections are Feedback, Customer Data, or their own defined term.
Ratings and Corrections
What it should capture: structured signals about Output quality — scores, preference choices between responses, and human-edited versions of Outputs.
Drafting trap: not defining them at all. In an AI product these are the most valuable training signals the beta produces. Giving them their own defined term lets the parties negotiate them separately from ordinary Feedback.
Group 5: What the Startup Collects on Its Own
Usage Data
What it should capture: operational and telemetry data about how the Beta Service is used — performance, feature adoption, error rates, latency.
“Usage Data” means technical and operational data generated by Customer’s use of the Beta Service, such as log data, performance metrics, and feature usage statistics. Usage Data does not include the content of Customer Data, Inputs, or Outputs.
Drafting trap: this is the most abused definition in AI contracts. A “Usage Data” definition that includes prompt or output content — often buried in a phrase like “data relating to Customer’s use of the Services” — can quietly convert tester content into startup-controlled data. Enterprise reviewers look for this first.
Aggregated Data
What it should capture: Usage Data or other information combined across customers so that no individual tester, user, or its content can be identified.
Drafting trap: allowing “aggregation” of content. Aggregating latency metrics is uncontroversial; “aggregating” customer documents into a training set is not.
De-identified Data
What it should capture: data that cannot reasonably be linked to an individual or the tester, meeting the applicable legal standard.
Drafting trap: defining it as “data with names removed.” Legal standards are stricter. Under the CCPA, for example, de-identified data requires reasonable technical measures plus public and contractual commitments not to re-identify. How those standards affect AI use is covered in can an AI beta use customer data?
Group 6: What the Startup May Do With It
Model Improvement (or Training)
What it should capture: use of data to train, retrain, fine-tune, or evaluate models — and, critically, which models: customer-specific, or shared across customers.
“Model Improvement” means using data to train, retrain, fine-tune, or otherwise modify the parameters of any machine learning model made available to customers other than Customer. Model Improvement does not include (a) processing data to provide the Beta Service to Customer, (b) debugging and quality evaluation, or (c) training a Customer-Specific Model.
Drafting trap: “improve the Services.” Those three words appear in most SaaS contracts, and in an AI product they can be read to include shared-model training. If training is intended, say so. If it isn’t, exclude it expressly.
Evaluation
What it should capture: retaining samples of Inputs and Outputs to test future model versions, measure quality, or build benchmarks.
Drafting trap: treating evaluation as part of debugging. Debugging is transient; evaluation sets are kept, often indefinitely. Give evaluation its own definition with a retention limit.
Subprocessor and Third-Party Model Provider
What it should capture: any third party that processes Customer Data — especially the foundation model provider.
Drafting trap: omitting the model provider from the subprocessor list. Enterprise testers want to know which model provider sees their data and under what terms, including that provider’s own training and retention policies.
Group 7: Protection and Exit
Confidential Information
What it should capture: both parties’ non-public information — including the tester’s Inputs and the startup’s system prompts, evaluation results, and model behavior.
Drafting trap: a one-way definition protecting only the startup. AI testers routinely paste sensitive material into prompts; the definition should cover it.
Deletion
What it should capture: what “delete” means for each category — raw data, logs, evaluation sets, and trained model parameters.
Drafting trap: one generic deletion obligation that implies data will be removed from trained models. If learned parameters won’t be deleted, the definitions should say plainly that model weights are not Customer Data.
Definitions Checklist for an AI Beta Agreement
- Beta Service limited to named features or models
- Customer Data defined broadly, with Usage Data and Feedback carved out
- Inputs distinguished from startup-supplied system prompts and context
- Outputs excluding startup templates and scaffolding
- Ratings and Corrections defined separately from Feedback
- Usage Data limited to operational metadata, never content
- Aggregated and De-identified Data tied to real legal standards
- Model Improvement distinguished from operation, debugging, evaluation, and customer-specific training
- Model provider listed as a subprocessor
- Deletion defined category by category, including model weights
Frequently Asked Questions
What is the most important definition in an AI beta agreement?
Usually “Usage Data,” closely followed by “Model Improvement” or “Feedback.” Those three decide whether the startup can reuse tester content beyond running the beta.
Can “improve the Services” include training AI models?
It can be read that way, which is exactly the problem. If training is intended, define it expressly and get consent. If it isn’t, exclude it.
Should ratings and corrections count as Feedback?
It’s a business decision, but it should be an explicit one. In an AI product, they are training signals, so many agreements give them their own defined term.
Do definitions need to match our privacy policy and DPA?
Yes. If “Customer Data” or “De-identified Data” means one thing in the beta agreement and another in the privacy policy or DPA, the inconsistency becomes a negotiation problem at best and a compliance problem at worst.
Is this sample language a template I can use?
No. It’s illustrative, to show how definitions interact. The right language depends on the product, the data, the model stack, and the deal.
Is this article legal advice?
No. For which agreements an AI company needs at each stage, see Which Agreements Does Your AI Startup Actually Need?
Get Definitions That Say What You Mean
Andrew S. Bosin drafts AI beta, design partner, and subscription agreements with definitions built around the product’s actual data flows and model stack — so the rights the business needs are secured, and the promises enterprise reviewers look for are made clearly.
About Andrew S. Bosin, Esq.
Andrew S. Bosin is a New Jersey technology attorney and two-time SaaS founder who represents AI and SaaS startups nationwide on a flat-fee basis. He personally drafts every agreement, gives every client his personal cell phone number, and responds to calls and texts quickly.
📌 Andrew S. Bosin LLC 🌐 www.njbusiness-attorney.com 📧 andrewbosin@gmail.com 📞 (201) 446-9643 📍 36 Highland Road, Glen Rock, NJ 07452
Call for a consultation. Flat-fee legal services for AI and SaaS startups, nationwide.
#AISaaSLawyer #BestAISaaSLawyer #AIStartupLawyer #AIContracts #SaaSContracts #BetaTestAgreement
This post is provided for general informational purposes and does not constitute legal advice.