Put Pilot, Data, and Product Terms in Place

Task

Create pilot terms, data permissions, and product terms.

Summary

Define permissions, obligations, ownership, risk, and commercial boundaries before pilots begin.

Pilot Terms and Data Permissions That Do Not Block the Sale

Task ID: S3-07

S3-07 requires a company to turn an informal product pilot into a controlled commercial relationship. The work is complete only when the pilot agreement, product terms, data-processing permissions, security commitments, and acceptance process match the product’s actual behaviour—and when no unresolved issue could lawfully or operationally prevent the pilot from starting.

Executive summary

The purpose of this task is to remove critical legal blockers from demo-led pilots and design-partner conversions. The work should produce a pilot agreement and product terms template that sales, product, engineering, legal, and operations can actually follow.

The task appears at the point where a company stops treating early customers as informal collaborators and starts asking them to use a repeatable product. That transition creates legal and operational questions that a handshake, nondisclosure agreement, or consulting statement of work usually does not answer:

• What exactly may the customer use, for how long, and in which environment?
• Is the pilot production-ready, evaluation-only, or somewhere in between?
• What customer data may the supplier collect, process, retain, derive, or use for product improvement?
• May data be used to train artificial-intelligence models?
• Which subcontractors, hosting regions, and security measures apply?
• What happens to data, access, fees, and feedback when the pilot ends?
• Which terms continue if the customer converts to a paid subscription?

The central operating principle is that legal terms must describe and constrain the product that actually exists. A broad template cannot compensate for an undocumented data flow, an unsupported security promise, an unlawful international transfer, or a product that cannot delete data when the contract says it will. European data-protection law requires processor contracts to identify the subject, duration, purpose, data types, data subjects, instructions, security, subprocessors, assistance, audits, and end-of-service treatment. California rules similarly require contracts to identify specific—not generic—business purposes and restrict secondary use.

Research on online contracting also shows why publication alone is not enough. In one large empirical study, only one or two of every 1,000 software shoppers accessed the applicable end-user licence agreement, and most who opened it did not appear to read much of it. Courts therefore focus heavily on whether users received conspicuous notice and took an action that unambiguously communicated assent.

A credible S3-07 implementation should produce a modular contracting system rather than a single oversized document:

The working target of “no critical blockers” is reasonable as an internal release condition, but it is not an industry benchmark. A critical blocker should mean an issue that could invalidate the agreement, make the contemplated processing unlawful, expose the company to an unaccepted high-severity risk, or require a product capability that does not exist. Lower-severity drafting improvements can remain open if an accountable owner, decision date, and temporary control are recorded.

The highest-priority recommendations are to map the real data flows before drafting; separate pilot-specific risk from ordinary product terms; state every data purpose precisely; make contractual promises testable against product capabilities; establish valid electronic assent and version records; and create a documented exception process for customer redlines. The task is complete when the company can start, operate, convert, and end a pilot without inventing new legal terms or data-handling practices for each customer.

Context, purpose, scope, and intended audience

A product pilot often begins before the commercial and legal system around the product is ready. A salesperson promises access after a demonstration. A design partner offers feedback. Engineers connect a data source. The customer assumes the supplier will secure and delete the data. The supplier assumes the customer has the necessary permissions. Neither side has written down whether the system is experimental, whether production data may be used, or what happens when the trial ends.

That informality can be tolerable while a founder is performing custom work for one trusted customer. It becomes dangerous when the company wants to repeat the same sale. S3-07 exists to replace relationship-specific assumptions with terms that can support multiple pilots without reconstructing the legal arrangement each time.

The intended audience is broader than the legal team. It includes:

• founders and product leaders deciding what the pilot can safely promise;
• sales leaders deciding what can be offered without special approval;
• engineers responsible for security, deletion, exports, logs, and integrations;
• privacy and security personnel reviewing data flows and subprocessors;
• finance and operations personnel administering fees, renewals, and conversion;
• customer procurement, legal, privacy, security, and technical reviewers.

The scope is not to build a complete enterprise contracting program. It is to establish the minimum repeatable legal and operational foundation for initial standalone product sales. Enterprise procurement schedules, complex service-level credits, bespoke indemnities, regulated-sector addenda, marketplace terms, reseller arrangements, and multinational tax structures may follow later when the customer and channel require them.

The absence of a stated dependency does not mean the task can be completed without information from the product. Drafting requires at least a provisional answer to the following factual questions:

The intended outcome is not “a lawyer approved the template.” The outcome is that sales, product, engineering, and operations can all explain what the documents mean and can perform the obligations they impose.

Contract architecture and substantive requirements

A modular document system

A pilot should not require an entirely separate legal universe, but neither should it be governed only by ordinary production terms. A practical structure uses a stable base agreement with a pilot-specific overlay.

flowchart LR
    A[Pilot order] --> B[Product terms]
    A --> C[Pilot schedule]
    B --> D[Data processing addendum]
    B --> E[Security schedule]
    B --> F[Acceptable-use terms]
    D --> G[Subprocessor and transfer notice]
    C --> H[Success, conversion, and exit plan]

Text description: The pilot order identifies the customer, product, users, term, fees, and incorporated documents. Stable product terms govern the overall relationship. A pilot schedule narrows the use case and states experimental limitations. Data, security, acceptable-use, subprocessor, conversion, and exit documents supply the operational details.

This modular model is visible in mature public contracting systems. Microsoft publishes a separate product-and-services data protection addendum, maintains current and archived versions, and incorporates the addendum into its wider product terms. GitHub similarly uses base customer terms plus product-specific and preview terms.

Pilot agreement

A good pilot agreement distinguishes an evaluation from an ordinary subscription. At minimum, it should answer the following questions:

GitHub’s public preview terms illustrate several pilot-specific distinctions: previews may be limited to non-production use, supplied as-is, changed or discontinued without notice, treated as confidential, and governed by different liability and support rules. Those provisions are not automatically appropriate for every pilot, but they demonstrate why preview risk should be stated expressly rather than hidden in general terms.

A paid design-partner pilot may require a more balanced arrangement. The customer may reasonably expect agreed support, a defined evaluation period, data protection, confidentiality, and a usable exit. Calling a product “beta” does not excuse deceptive claims, unlawful data processing, grossly inadequate security, or obligations that cannot legally be disclaimed.

Product terms

The product terms should govern the commercial relationship that remains after pilot-specific provisions are removed. The core subjects normally include:

Product terms should not contain highly specific data-processing descriptions that change whenever a subprocessor or feature changes. Those details are more maintainable in incorporated schedules, provided the hierarchy between the documents is clear and customers receive appropriate notice of material changes.

Data permissions

“Data permissions” is the most ambiguous phrase in S3-07. It should not be reduced to a sentence saying that the customer “consents” to all processing. At least four different legal and operational permissions may be involved:

Under the General Data Protection Regulation, a processor acts on documented instructions from a controller. The required contract must describe the processing and impose obligations concerning confidentiality, security, subprocessors, data-subject requests, compliance assistance, deletion or return, information provision, and audits. The parties’ labels are not decisive: an organization that determines its own purposes and essential means may become a controller for that processing.

California’s rules require even greater care with purpose language. A service-provider or contractor agreement must identify the specific business purposes for processing and may not describe them only by generic reference to the whole agreement. It must limit retention, use, disclosure, commercial use, and use outside the direct business relationship; provide for equivalent protection; and permit reasonable steps to verify compliance.

Canadian guidance likewise emphasizes that people must understand the nature, purposes, and consequences of collection, use, or disclosure. It recommends layered presentation of key information, clear choices for non-essential uses, renewed consent for significant changes, and testing whether notices are understandable from the user’s perspective.

The data schedule should therefore identify, in ordinary language:

• data categories and affected people;
• sources and collection methods;
• mandatory and optional data;
• each permitted purpose;
• privacy roles for each purpose;
• product telemetry and diagnostic data;
• support access;
• aggregated, de-identified, and derived data;
• artificial-intelligence inputs, outputs, logs, evaluation data, and training;
• subprocessors and hosting locations;
• international-transfer mechanisms;
• retention periods and deletion events;
• backup treatment;
• security measures;
• incident-notification process;
• assistance with access, correction, deletion, objection, and portability requests;
• audit and assurance evidence;
• post-termination export and deletion.

A contract should not claim that data is “anonymous” merely because names have been removed. Under the GDPR, data remains personal when a person can reasonably be identified directly or indirectly; pseudonymized data is still personal data when it can be reconnected to a person using additional information.

Technical, ethical, and operational consequences

The terms create product requirements. A deletion clause requires a deletion workflow. A data-residency promise requires architecture and deployment controls. A subprocessor-notice clause requires an inventory and change process. A security schedule requires evidence. A right to export data requires a supported format. An incident-notification commitment requires detection, escalation, legal analysis, and customer communications.

GDPR Article 32 ties security to risk and identifies measures such as encryption or pseudonymization, continuing confidentiality, integrity, availability and resilience, restoration capability, and regular effectiveness testing. NIST’s Cybersecurity Framework 2.0 adds explicit emphasis on governance and supply-chain risk and can be used to translate broad contractual promises into owned security outcomes.

Ethically, a pilot should not use the urgency of product access to obtain unexpectedly broad rights. Rights to combine customer data across accounts, train general models, create identifiable benchmarks, disclose data to advertising partners, or retain data indefinitely deserve conspicuous treatment and, where not essential to the service, a genuine choice. Canadian privacy guidance explicitly warns that information buried in terms serves little practical purpose and recommends highlighting key uses and consequences.

For products containing artificial intelligence, the agreement should also allocate responsibility for lawful inputs, human review, prohibited uses, output limitations, intellectual-property claims, transparency, and model improvement. As of August 2, 2026, EU AI Act transparency obligations apply to specified systems, including requirements associated with direct human interaction and certain generated or manipulated content. High-risk obligations have separate application dates depending on the category of system.

Evidence from law, standards, research, and public cases

Comparison of the principal sources

Contract formation and notice

Publishing product terms at the bottom of a website is weak evidence that a customer agreed to them. Modern U.S. cases generally ask whether the interface provided reasonably conspicuous notice and whether the user performed an act that unambiguously manifested assent. Courts examine screen simplicity, placement, font, contrast, proximity to the action button, and the relationship between the disclosure and the user’s action.

For a demo-led business-to-business sale, the strongest evidence usually consists of a signed order form or electronic signature that incorporates named documents by version or effective date. For self-service accounts, an unchecked acceptance box, a direct statement that clicking creates agreement, conspicuous links, and a retained acceptance log are safer than passive browsewrap.

The acceptance record should preserve:

This matters even in business-to-business pilots. A customer user may have technical authority to create an account but lack authority to accept uncapped fees, arbitration, publicity rights, or broad data use on behalf of the employer.

The lesson from unread terms

Bakos, Marotta-Wurgler, and Trossen examined tens of thousands of visitors to software websites and found that only approximately 0.1–0.2% accessed the end-user licence agreement; those who did generally spent too little time to read most of it. Later experimental work has similarly found that users commonly accept policies without meaningfully reviewing them, even when the policies contain extreme provisions.

The operating lesson is not that legal terms are pointless. It is that different objectives require different mechanisms:

• Contract formation requires adequate notice and assent.
• Regulatory transparency requires understandable information about material practices.
• Operational control requires internal procedures and technical enforcement.
• Customer trust requires that the most consequential uses are not concealed in boilerplate.

A concise pilot summary should therefore identify the product’s evaluation status, permitted data, model-training position, material limitations, exit treatment, and conversion mechanics, even when complete terms remain available separately.

BetterHelp: promises must match data flows

The Federal Trade Commission’s BetterHelp action illustrates the consequences of inconsistency between privacy representations and actual data practices. The FTC alleged that the company disclosed email addresses, Internet Protocol addresses, and health-questionnaire information to advertising platforms despite making limited-use and privacy representations. The final order required a $7.8 million payment, restrictions on advertising disclosures, affirmative express consent for specified sharing, a comprehensive privacy program, third-party deletion, and a retention schedule.

The lesson for a pilot is direct: a statement such as “customer data is used only to provide the service” must be tested against analytics software, advertising pixels, support systems, logging, model providers, fraud tools, and product-improvement pipelines. A contractual purpose cannot be narrower than the real implementation unless those other flows are removed.

Drizly: collecting data creates a continuing duty

In the Drizly matter, the FTC alleged that inadequate security contributed to a breach affecting approximately 2.5 million people. The resulting order required destruction of unnecessary data, purpose-based retention limits, publication of collection purposes, and a comprehensive information-security program.

The practical lesson is that data permissions should not be drafted only as rights granted to the supplier. Every additional category and retention period creates security, access-control, incident-response, deletion, and evidentiary obligations. A useful default for pilots is therefore to prohibit sensitive or regulated data unless the use case requires it and the product has been specifically approved to process it.

Ambiguities, risks, and open questions

Principal ambiguities

The phrase “pilot terms” does not say whether the pilot is paid, production-facing, technically unsupported, or intended to produce a binding conversion decision. Each interpretation changes the agreement.

The phrase “data permissions” may refer to customer-to-supplier contractual authority, end-user consent, processor instructions, rights to use aggregated data, model-training rights, intellectual-property licences, or all of these. Those concepts should be separated rather than compressed into one grant.

The phrase “product terms” may describe negotiated business-to-business terms, self-service click-through terms, consumer terms, an end-user licence agreement, or an acceptable-use policy. The applicable formation rules and mandatory protections vary.

Practical implementation usually requires a coordinated document set. A single template is likely to become either too vague to protect the parties or too long to remain usable.

“No critical blockers” is also undefined. Without a severity model, a team can report that no blockers exist merely by classifying every issue as a drafting preference.

Risk register

Open questions requiring company judgment

The appropriate position on the following subjects cannot be derived from the S3-07 record alone:

1. Production use: Some pilots are safe only with synthetic or test data. Others need live use to generate meaningful evidence. The agreement should follow a product risk assessment, not a generic beta label.

2. Model training: A prohibition on training with customer content may simplify sales but reduce access to improvement data. An unrestricted right may make the product unacceptable to customers and may be inconsistent with privacy purposes. The decision should distinguish customer content, prompts, outputs, diagnostic logs, explicit feedback, and de-identified evaluation data.

3. Reliability commitments: An early product may be unable to promise a formal service level. It can still promise reasonable support, security measures, backup practices, and an escalation channel.

4. Pilot fees: A free pilot may encourage participation but produce weak buying evidence. A paid pilot may better test willingness to pay but will usually attract higher expectations and more procurement review.

5. Publicity and references: Design partners often expect confidentiality until results are confirmed. Customer-logo or case-study rights should normally require a separate, explicit approval rather than being treated as routine feedback rights.

6. Liability cap: A low pilot fee can produce a commercially meaningless cap when the supplier processes valuable or sensitive data. The cap should reflect data, security, intellectual-property, and operational exposure rather than being derived automatically from fees.

7. Regulated customers: Health, financial, education, employment, children’s, government, critical-infrastructure, and export-controlled use may require additional agreements or product controls. A standard pilot template should include an intake gate that identifies these cases before signature.

Prioritized recommendations and next steps

Implementation priorities

Recommended pilot agreement structure

A practical first template can follow this order:

1. Parties, contracting entity, and authorized representatives.
2. Pilot product, features, environment, users, territory, and permitted use.
3. Start date, evaluation period, extension, and termination.
4. Fees, expenses, taxes, and any conversion credit.
5. Customer prerequisites and supplier onboarding obligations.
6. Success criteria, evaluation process, and decision date.
7. Support model and explicitly excluded service levels.
8. Production-use status and prohibited reliance.
9. Data categories, prohibited data, and incorporated data documents.
10. Security commitments and incident contacts.
11. Confidentiality and treatment of pilot results.
12. Product intellectual property, customer materials, and feedback.
13. Warranties, disclaimers, indemnities, and liability.
14. Conversion options and order process.
15. Export, return, deletion, and continuing retention exceptions.
16. Governing law, notices, entire agreement, and document priority.

The template should use fields and selectable clauses for decisions that genuinely vary—such as paid versus free, test versus production, or training permitted versus prohibited—rather than inviting free-form rewriting of the whole agreement.

Measuring legal blockers

The primary measure should be a live blocker register, not a subjective statement that legal is “comfortable.” At minimum, each item should record:

Useful supporting measures include the percentage of pilots signed on standard terms, median contract cycle time, number of material exceptions per pilot, oldest critical or high issue, repeated redline topics, percentage of data flows with documented purposes, subprocessor-inventory completeness, and percentage of contractual security promises linked to current evidence.

These are diagnostic measures rather than universal targets. A heavily regulated health product will appropriately carry more review work than a low-risk business productivity tool. A large enterprise pilot may require more negotiated exceptions than a small-business self-service trial. The important test is whether variance is understood and controlled.

Completion and release decision

S3-07 should be treated as complete when all of the following are true:

• the original task has been converted into approved, usable documents rather than unresolved drafting notes;
• the pilot template covers scope, duration, success, support, conversion, and exit;
• product terms cover the ordinary commercial relationship;
• all material data flows have identified purposes, roles, recipients, locations, retention, and security controls;
• required data-processing and transfer terms are available;
• the supplier can technically perform its contractual commitments;
• the acceptance process records authority, notice, version, and assent;
• subprocessors and contractual versions are governed;
• customer-facing teams know which terms may be changed and who approves exceptions;
• critical blockers are closed or the affected pilot is prohibited from starting.

The result should be a repeatable decision: this customer, using this product, with these data and this operating model, may begin the pilot under the approved document set. Where that statement cannot be made, the blocker register—not optimistic sales language—should determine whether the launch proceeds.

Sources

Primary and official sources

• General Data Protection Regulation, including Articles 28 and 32 — European Union.
• Guidelines on controller and processor concepts — European Data Protection Board, final version, July 7, 2021.
• Standard Contractual Clauses — European Commission.
• California privacy contract requirements for service providers and contractors — California Privacy Protection Agency.
• Meaningful consent guidance — Office of the Privacy Commissioner of Canada.
• Cybersecurity Framework 2.0 and supply-chain guidance — National Institute of Standards and Technology.
• Privacy Framework — National Institute of Standards and Technology.
• BetterHelp privacy enforcement materials — Federal Trade Commission.
• Drizly security enforcement materials — Federal Trade Commission.
• Transparency obligations and current AI Act implementation timeline — European Commission.

Public implementation examples

• GitHub terms for previews and additional product features.
• Microsoft Products and Services Data Protection Addendum, May 2026 edition and archive.

Open and academic research

• Yannis Bakos, Florencia Marotta-Wurgler, and David R. Trossen, “Does Anyone Read the Fine Print?”
• Jonathan A. Obar and Anne Oeldorf-Hirsch, research on clickwrap and user engagement with online policies.
• Berman v. Freedom Financial Network and related online-contract decisions.