The first enterprise deal for most AI startups doesn’t start with a three-year subscription. It starts with a paid pilot — 30, 60, or 90 days in which the customer tests the product on its own data, against its own benchmarks, before anyone signs an MSA.
A good pilot is the fastest route to a signed enterprise contract. A badly papered pilot is a free consulting engagement that ends with “interesting results — let’s revisit next quarter.”
The difference usually comes down to the proof of concept agreement. SaaS AI Lawyer Andrew S. Bosin, a two-time SaaS founder, sees the same gaps again and again: success criteria nobody can measure, a pilot fee with no link to the subscription, and data terms written for traditional software rather than a product whose output changes from one run to the next.
This guide covers what an AI proof of concept agreement should include, and where AI pilots differ from the software pilots most templates were written for.
Quick Answer
An AI proof of concept agreement should:
- Define measurable success criteria that account for non-deterministic AI output — an agreed test set, a baseline, a metric, and who does the scoring
- Charge a pilot fee and credit it toward the first-year subscription on conversion
- Pre-agree the conversion terms — price, term, and the order form that activates if the criteria are met
- Limit data scope and training rights — what data the customer supplies, whether it can be used to improve models, and how it is deleted, including logs and embeddings
- Cap liability at a level proportional to the pilot, with a separate approach for data incidents
- Expire on a fixed date, so the pilot can’t drift into unpaid production use
When a Paid Pilot Is the Right Contract
A paid pilot is one of five early-access contracts an AI startup may use. Andrew’s comparison of beta, pilot, NDA, and free trial agreements explains how to choose between them. In short, a paid pilot fits when:
- The buyer is an enterprise with procurement, security review, and a budget owner
- The product works — it is not a rough beta, even if it isn’t fully mature
- The customer wants proof on its own data before committing to an annual contract
- Both sides want a defined buying decision at the end, not open-ended evaluation
If the customer is helping build the product rather than evaluating it, the relationship is closer to a design partnership, and the design partner agreement guide is the better starting point. If the product is still unfinished and free, a beta test agreement for AI startups is usually the right document.
Part 1: The Commercial Terms
The Pilot Fee
Charging for a pilot does two things: it filters out prospects who aren’t serious, and it forces the customer to get internal budget approval — which means a budget owner exists by the time the pilot ends.
The agreement should state:
- The fee and payment timing — typically all upfront, or split between kickoff and the midpoint
- What the fee covers — seats, usage volume, onboarding hours, and integration work
- The conversion credit — whether the full fee, or a portion, is credited against first-year subscription fees if the customer converts within a set window
- No refund on failure — unless the startup has chosen to offer one as a sales concession
A credit that applies only if the customer signs within 30 or 60 days of the pilot ending adds useful urgency to the buying decision.
Usage Caps and Inference Costs
This is a term traditional software pilots rarely need. An AI pilot has a real marginal cost: every query calls a model, and a pilot team running batch jobs over a large document set can burn through inference spend quickly.
The pilot order should set:
- A usage allowance — queries, documents, tokens, or API calls
- What happens at the cap — throttling, a notice-and-approve process, or overage fees
- Rate limits consistent with the startup’s upstream model-provider limits
Without a cap, a “fixed-fee” pilot can end up costing the startup more than the fee it collected.
Conversion Terms
The strongest pilots end with a pre-negotiated next step. Rather than starting a new negotiation after the pilot, the parties agree up front on:
- The subscription price and term the customer can take if the pilot succeeds
- How long that offer stays open after the pilot ends
- The form of commercial agreement — ideally the startup’s own MSA, attached or referenced
Some startups go further and attach a signed but conditional order form that becomes effective automatically if the success criteria are met, unless the customer opts out in writing. Enterprise buyers often resist automatic conversion, but even a non-binding price commitment shortens the path to signature.
Part 2: Success Criteria for AI Output
This is where AI pilots differ most from traditional software POCs.
A traditional software POC can use pass/fail criteria: the integration works, the report generates, the page loads in under two seconds. AI output doesn’t work that way. The same input can produce different outputs, quality is often a matter of degree, and “accuracy” means nothing until someone defines what it’s measured against.
Vague criteria like “the solution performs to the customer’s satisfaction” turn the pilot into an option the customer can decline for any reason. Measurable criteria make the buying decision a factual question.
What AI Success Criteria Should Specify
- The test set — a defined set of documents, tickets, records, or queries, fixed before the pilot starts, so the results can’t be judged against moving targets
- The baseline — what the AI is compared against: the current manual process, an existing tool, or a human reviewer’s results on the same set
- The metric — accuracy against a labeled answer key, precision and recall, time saved per task, deflection rate, or reviewer-rated quality on a defined scale
- The threshold — the number that counts as success, such as 90% agreement with expert labels on the test set
- Who scores the results — the customer’s reviewers, a joint panel, or an agreed rubric, and how disagreements are resolved
- Repeat runs — how non-deterministic results are handled, such as scoring the average across multiple runs
Customer Dependencies
AI results depend heavily on the customer’s inputs. If the customer supplies poor-quality data, provides it late, or never assigns reviewers, the pilot can fail for reasons the product had nothing to do with.
The agreement should list the customer’s responsibilities — data delivery dates, data quality, reviewer availability, system access — and say that the pilot timeline extends, or the criteria are adjusted, if the customer doesn’t meet them.
Sample Clause: Success Criteria
“Success Criteria” means the performance thresholds set out in Exhibit A, measured on the Evaluation Set in accordance with the scoring method in Exhibit A. The Evaluation Set will be fixed on or before the Pilot Start Date and may be changed only by mutual written agreement. If Customer does not provide the Customer Materials or reviewer availability described in Exhibit A by the dates stated there, the Pilot Period will be extended day-for-day, and Company will not be deemed to have failed any Success Criterion affected by the delay.
Part 3: Data, Training, and Security Terms
Limit the Data in Scope
Enterprise security teams often allow a pilot to proceed with a lighter review than a full production deployment — but usually only if the data in scope is limited. The pilot agreement should state exactly what data the customer will provide:
- Synthetic or de-identified data where possible
- A limited production subset where real data is needed
- Excluded categories — for example, no health information, payment card data, or biometric data without an agreed addendum
If any personal data is involved, a data processing agreement is still needed, even for a 60-day pilot. The AI SaaS DPA guide covers what the customer’s security and privacy teams will expect.
Training Rights
Enterprise pilot customers almost always expect that their data won’t train the startup’s models. The startup needs to decide before the pilot starts whether it needs any use rights beyond providing the service, and say so plainly:
- Service delivery only — the simplest position, and the one most enterprises will accept
- Debugging and evaluation — use of pilot data to fix errors and measure quality, without training
- Model improvement — training or fine-tuning on pilot data, which usually requires express, negotiated consent
Whatever the pilot says will set expectations for the enterprise contract that follows. The no-training clause guide explains how those terms are negotiated at the MSA stage, and can an AI beta use customer data? covers the privacy-law limits that apply regardless of the contract.
Deletion — Including the Places Data Hides
An AI pilot leaves customer data in more places than a traditional software pilot: prompt and response logs, vector stores and embeddings, fine-tuned model weights, evaluation datasets, and the model provider’s own retention.
The deletion clause should cover each of these, set a timeline after the pilot ends, and be honest about what can and can’t be deleted. A promise to “remove all customer data from the model” when the data is embedded in fine-tuned weights is a promise the startup may not be able to keep.
Sample Clause: Pilot Data Use
Company will use Pilot Data solely to provide the Pilot Services to Customer and to measure performance against the Success Criteria. Company will not use Pilot Data to train, fine-tune, or otherwise improve any machine learning model made available to any party other than Customer. Within thirty (30) days after the end of the Pilot Period, Company will delete Pilot Data, including associated logs, embeddings, and evaluation copies, except as required to be retained by law or as held in routine backups that are deleted in the ordinary course.
Part 4: IP, Liability, and Other Legal Terms
IP in Pilot Configurations
During a pilot, the startup’s team often builds customer-specific prompts, workflows, integrations, and sometimes a fine-tuned model. The agreement should state that:
- The customer owns its data and its confidential materials
- The startup owns the platform and all improvements, configurations, and know-how developed during the pilot, other than the customer’s data
- Customer-specific configurations are licensed to the customer during the pilot, and carry into the subscription if it converts
Avoid joint ownership of anything built during the pilot. Andrew’s guide to customer content ownership in AI betas explains why jointly developed IP causes problems later — including in investor diligence.
Feedback License
The startup should receive a broad, perpetual license to use the customer’s feedback and suggestions — without any obligation to implement them, pay for them, or attribute them.
Benchmark and Publication Restrictions
Enterprise pilots generate performance data. The agreement should restrict the customer from publishing benchmark results, sharing them with competing vendors, or using them in a competitive evaluation without the startup’s consent. This is particularly important when the customer is running parallel pilots with competitors.
Liability Cap
A pilot is a limited engagement, and the liability cap should be limited too. A common approach is to cap each party’s liability at the greater of the pilot fee or a fixed dollar amount. Enterprise buyers may push for a higher “super-cap” for data breaches and confidentiality violations. A defined, separate cap for those claims is usually a better compromise than removing the cap altogether.
AI Output Disclaimers
Even a paid pilot should state that AI outputs may be inaccurate or incomplete, that the customer is responsible for reviewing outputs before relying on them, and that pilot outputs shouldn’t be used as the sole basis for decisions about employment, credit, housing, insurance, healthcare, or legal matters.
The Customer’s Paper
Large enterprises often insist on their own evaluation or pilot agreement. Those forms are drafted for the buyer and frequently include:
- Broad feedback or residuals clauses that let the customer’s team use what they learned from the product
- Ownership of “deliverables”, which can be read to include pilot configurations
- Uncapped indemnities unsuited to a short, low-fee engagement
- No conversion terms at all
Reviewing the customer’s form before the pilot starts takes far less time than untangling it later. Andrew’s guide to choosing a SaaS contract attorney before your first enterprise customer covers what to expect when an enterprise sends its own paper.
Part 5: Term, Termination, and What Happens Next
A Fixed End Date
Every pilot should end on a date, not an event. Open-ended pilots slide into unpaid production use, weaken the “evaluation only” framing, and remove the pressure to decide.
A short extension clause — one extension of up to 30 days by mutual written agreement — gives flexibility without letting the pilot become permanent.
Precedence Over Later Agreements
If the customer converts, the MSA should expressly supersede the pilot agreement, with any terms that need to survive — the pilot fee credit, confidentiality, and IP ownership of configurations — carried over deliberately. The SaaS MSA guide for AI companies covers the enterprise agreement that typically follows.
Publicity and References
A successful pilot is sales material. The agreement can give the startup the right to name the customer, or request a case study, conditional on a successful pilot and the customer’s approval of the final text.
Pilot Agreement Checklist for AI Startups
Before sending a pilot agreement, confirm it addresses:
- Pilot scope, users, and environment
- Pilot fee, payment timing, and conversion credit
- Usage caps and inference cost limits
- Success criteria: test set, baseline, metric, threshold, scorer
- Customer dependencies and timeline extensions
- Data in scope and excluded data categories
- Training and use rights for pilot data
- Deletion, including logs, embeddings, and model artifacts
- IP ownership of configurations and a feedback license
- Benchmark publication restrictions
- AI output disclaimers
- Liability cap and any super-cap
- Fixed end date and extension mechanics
- Pre-agreed conversion price, term, and contract form
For a broader view of where a pilot agreement fits among a startup’s other contracts, see which agreements does your AI startup actually need?
Frequently Asked Questions
What is the difference between a proof of concept agreement and a pilot agreement?
The terms are often used interchangeably. Strictly speaking, a proof of concept tests whether the technology can work for the customer’s use case, while a pilot tests it in the customer’s real environment with real users. For AI startups, the same agreement usually covers both, and what matters more is whether the success criteria and conversion terms are clearly defined.
Should an AI startup charge for a pilot?
For enterprise customers, usually yes. A pilot fee confirms that a budget exists and that a decision-maker is involved. Crediting the fee toward the first-year subscription on conversion removes most of the resistance to paying it.
How long should an AI pilot last?
Most enterprise AI pilots run 30 to 90 days. The period should be long enough to generate results on the agreed test set, but short enough to keep the buying decision on the calendar.
Can a startup use pilot data to improve its AI models?
Only if the agreement allows it and applicable privacy law permits it. Most enterprise customers will refuse training rights in a pilot, so the startup should decide in advance whether it needs any rights beyond delivering the service and evaluating results.
What if the pilot fails because of the customer’s data?
The agreement should list the customer’s obligations — data delivery, data quality, reviewer availability — and state that the timeline extends, or the affected criteria don’t count as failed, if the customer doesn’t meet them.
Should the startup sign the customer’s pilot agreement?
It can, but only after review. Enterprise pilot forms are drafted for the buyer and often include broad IP, feedback, and indemnity terms that don’t fit an AI startup’s product or a short, low-fee engagement.
Get a Pilot Agreement Built to Convert
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 drafts and negotiates paid pilot, proof of concept, beta, and design partner agreements built around the startup’s actual model stack, data flows, and sales process — so the pilot produces a clear buying decision and the startup keeps the rights it needs.
He personally drafts every agreement, gives every client his personal cell phone number, and responds quickly.
Andrew S. Bosin LLC 36 Highland Road, Glen Rock, New Jersey 07452 📞 201-446-9643 📧 andrewbosin@gmail.com 🌐 www.njbusiness-attorney.com
#AISaaSLawyer #AIStartupLawyer #BestAISaaSLawyer #PaidPilot #ProofOfConcept #EnterpriseSaaS #SaaSContracts #AIContracts
This post is provided for general informational purposes and does not constitute legal advice.