Seek a feasibility statement of work with a capped scope, buyer-controlled acceptance and a useful failure report. Ask the supplier to identify the lowest-cost experiment that could disprove its recommendation.
The common brief should go to each shortlisted delivery team with the same permitted information. Require a work breakdown for data preparation, baseline optimisation, adaptation, evaluation, serving and handover. Distinguish activities included in the fee from dependencies on buyer staff.
| Pilot contract item | Required clarity |
|---|---|
| Comparators | Current path, improved practical baseline and proposed specialist route |
| Experiment boundary | Task, eligible traffic, excluded cases and permitted data |
| Acceptance | Locked rubric, buyer holdout, critical failures and review responsibility |
| Deliverables | Run configurations, evaluation results, cost ledger and failure analysis |
| Assets and rights | Exact datasets, code, adapters, checkpoints and export limitations |
| Commercial terms | Fixed or capped work, variable charges, assumptions and change control |
| Stop rule | Conditions under which work stops without a production recommendation |
| Handover | Named operator, documentation, incident process and testable export |
Review the exact base-model and dependency licences. The Open Source AI Definition and the Llama 3.3 agreement illustrate why “open” is not an adequate contract schedule. The buyer needs the rights required for its actual deployment and exit, not an abstract ownership slogan.