Every AI startup running a beta hits the same question: the testers are uploading real data — can the company actually use it?
Not just to run the beta. To debug it, build evaluation sets, and — the question founders really mean — train or fine-tune the model.
The short answer: sometimes, and the beta agreement alone doesn’t decide it. Three things do:
- The contracts — the beta agreement, plus any MSA or DPA the customer already signed
- The privacy laws that apply to the data, and the role the startup plays under them
- Sector laws for health, children’s, and biometric data
This article works through each one. For the full clause-by-clause drafting of the agreement itself, see Andrew’s guide to the beta test agreement for SaaS and AI startups. This piece focuses only on the data question.
Quick Answer
An AI startup can generally use beta customer data to run the beta and fix what breaks. Using it to train a model shared across customers is where legal risk concentrates — and in many cases it requires express consent, a different privacy-law role, or data that has been properly de-identified first.
Step 1: Figure Out Whose Data It Is
“Customer data” in a beta is usually three different things, and each carries different rules:
- The tester’s own business data — documents, code, internal records. This is mostly a contract and confidentiality question.
- Personal data about the tester’s customers or employees — names, emails, call recordings, support tickets. The tester usually can’t give away rights it doesn’t have. Privacy law follows this data wherever it goes.
- Production data from existing paying customers who were switched into a beta feature. Their existing agreement already governs it — often more strictly than any beta terms.
The third category catches founders off guard. Turning on a beta AI feature for current customers doesn’t reset their contract. If their MSA or DPA says their data is used only to provide the services, a beta toggle doesn’t change that.
Step 2: Check What the Customer Already Signed
Before the beta agreement says anything about data, check what existing documents already promise:
- “Customer Data” definitions that say data is used “solely to provide the Services”
- DPA instructions limiting processing to the customer’s documented instructions
- No-training commitments — increasingly standard in enterprise AI deals
- Order-of-precedence clauses stating the MSA or DPA controls over any conflicting terms
If the master agreement controls and prohibits training, a click-through beta addendum that grants training rights may simply lose. Worse, relying on it can look like the “quietly changed terms” problem the FTC has warned about.
In early 2024, the FTC cautioned AI companies twice: once that they must honor their existing privacy and confidentiality commitments, and once that changing terms to allow broader AI-training use of data already collected — without clear notice and consent — may be unfair or deceptive. The fix is an express, separately accepted consent, not a buried amendment. Andrew’s clause-by-clause DPA guide covers how these instructions are typically drafted.
Step 3: Know Your Privacy-Law Role
When a beta tester uploads personal data about its own customers, the startup is usually processing that data on the tester’s behalf. That role matters more than anything the beta agreement says.
CCPA: Service Provider Limits
Under California’s CCPA regulations (11 CCR § 7050), a service provider can use personal information to build or improve the quality of the services it provides to that business — but not to perform services on behalf of another business.
That line maps directly onto AI training:
- Improving the tester’s own instance — debugging, evaluating quality, tuning a customer-specific model — fits comfortably within the service-provider role.
- Training a shared model that serves every other customer is harder to defend. If one tester’s customer data improves the product delivered to everyone else, the startup risks stepping outside the service-provider role — and becoming a “third party” with very different obligations.
GDPR: Processor or Controller
The GDPR draws a similar line. A processor acts only on the controller’s documented instructions. Under Article 28(10), a processor that decides its own purposes for the data is treated as a controller for that processing — with its own legal basis requirements, transparency duties, and liability.
Training a general-purpose model on EU testers’ personal data is a startup-determined purpose. That makes the startup a controller for training, and it needs its own lawful basis — which a beta tester’s click usually can’t supply for the tester’s customers.
What This Means in Practice
For personal data belonging to the tester’s customers, the tester’s consent alone usually isn’t enough for shared-model training. Either the data is de-identified properly before it’s used, or the startup needs a lawful basis that runs to the individuals themselves.
Step 4: Watch for Sector-Specific Data
Some categories of data carry rules that no beta agreement can override:
- Health data (HIPAA). A business associate can use protected health information only as its business associate agreement permits. De-identifying PHI for other uses is allowed only if the BAA authorizes it, and only under HIPAA’s Safe Harbor or Expert Determination standards.
- Children’s data (COPPA). In 2023, the FTC and DOJ reached a $25 million settlement with Amazon over retention of children’s Alexa voice recordings, including allegations that the data was kept in part to improve its algorithms. Children’s data and AI training is a known enforcement target.
- Biometric data (BIPA and similar laws). Voiceprints and face geometry require written notice and consent in Illinois, with a private right of action. Andrew’s BIPA and AI voice architecture analysis covers how this reaches AI products.
- Financial data (GLBA) — reuse is constrained by the financial institution’s own obligations and contracts.
The safest approach is to keep these categories out of the beta entirely unless there’s a specific agreement covering them.
How Risky Is Each Use? A Practical Ladder
Not every use of beta data carries the same risk. From lowest to highest:
- 1. Operating the beta — processing inputs to return outputs to that tester. Generally permitted with a basic contract.
- 2. Debugging and support — reviewing specific failures. Low risk with access controls and confidentiality.
- 3. Aggregated usage metrics — counts, latency, feature adoption, with no content. Low risk if genuinely aggregated.
- 4. Evaluation sets — keeping examples of inputs and outputs to test future model versions. Moderate risk; needs express permission and a retention limit.
- 5. Customer-specific fine-tuning — a model tuned only for that tester. Moderate risk; usually fits the service-provider role if isolated.
- 6. Shared-model training on de-identified data — acceptable only if de-identification meets the legal standard, not just the marketing one.
- 7. Shared-model training on identifiable customer data — highest risk. Needs express consent, a confirmed privacy-law role, and no conflicting master agreement.
The beta agreement should grant or exclude each rung expressly. How to draft those tiers is covered in the training-rights section of the beta agreement guide.
“De-Identified” Is a Legal Standard, Not a Label
Founders often assume that stripping names makes data safe to train on. Legally, it usually doesn’t.
- Under the CCPA, data counts as “deidentified” only if the business takes reasonable measures to prevent re-identification, publicly commits to keep it in de-identified form, and contractually requires recipients to do the same.
- Under HIPAA, de-identification requires either removing 18 specified identifiers (Safe Harbor) or a qualified expert’s written determination.
- Under the GDPR, pseudonymized data is still personal data. Only truly anonymous data falls outside the regulation.
Free text — support tickets, transcripts, uploaded documents — is especially hard to de-identify. Names, account numbers, and health details hide inside the content itself.
Safer Alternatives That Still Improve the Model
If shared-model training on beta data isn’t clearly permitted, there are workable paths:
- Opt-in training programs. A separate, clearly worded consent — often paired with a pricing incentive — for testers willing to contribute data.
- Customer-specific models. Isolated fine-tunes that improve only that customer’s experience.
- Synthetic or sample datasets. Testers use representative fake data during the beta; real data waits for production terms.
- Human-labeled feedback only. Train on ratings and corrections, not on the underlying customer content — defined carefully so the two don’t blur.
- Staged rollout. Start with testers whose data is the startup’s own or who have no end-customer personal data in scope.
Founder Decision Checklist
Before using any beta customer data beyond operating the beta, confirm:
- Whose data it is: tester business data, end-customer personal data, or existing production data
- What any existing MSA, DPA, or order form already says — and which document controls
- The startup’s role under the CCPA and GDPR for that specific use
- Whether any health, children’s, biometric, or financial data is in scope
- Which rungs of the use ladder the beta agreement expressly grants or excludes
- Whether de-identification meets the actual legal standard
- That the privacy policy and public statements match what’s actually happening
Keeping those documents consistent is its own discipline — Andrew’s AI data governance work starts there.
Frequently Asked Questions
Can I use beta testers’ data to train my AI model?
Sometimes. It depends on express consent in the beta agreement, the absence of conflicting commitments in any master agreement, your role under privacy law, and whether sector-specific data is involved. Training a model shared across customers carries the most risk.
If a beta tester consents, can I train on their customers’ personal data?
Usually not on the tester’s consent alone. The tester is typically the business that controls that data, and the startup is its service provider or processor. Using the data for the startup’s own purposes can change the startup’s legal role and require a lawful basis that runs to the individuals.
Does a click-through beta addendum override our existing MSA?
Not necessarily. Many MSAs and DPAs include order-of-precedence clauses stating they control over conflicting terms. And the FTC has warned that quietly expanding AI-training rights through changed terms may be deceptive.
Can we use existing customers’ production data to test a new AI feature?
Only within what their existing agreement allows — often limited to providing the services. Testing and improving the feature for that customer is usually fine; reusing their data to train a shared model usually needs new, express permission.
Is anonymized data safe to use for training?
Only if it meets the applicable legal definition. CCPA de-identification requires technical measures plus public and contractual commitments. HIPAA has its own standards. Under the GDPR, pseudonymized data is still personal data.
Is this article legal advice?
No. The answer depends on the specific data, contracts, jurisdictions, and product architecture. For a broader view of which documents an AI startup needs, see Which Agreements Does Your AI Startup Actually Need?
Get Clear Data Rights Before the Beta Starts
Andrew S. Bosin helps AI and SaaS startups map what data their beta will touch, align the beta agreement with existing customer contracts and privacy obligations, and secure the training rights the business actually needs — before the first tester uploads anything.
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 #AIDataRights #BetaTestAgreement #SaaSContracts
This post is provided for general informational purposes and does not constitute legal advice.