A white-label AI development contract between an agency and its partner should include a mutual NDA and non-solicit signed before scoping; scope written as behaviour with a capability boundary and an out-of-scope list; acceptance tied to an evaluation set and agreed score; IP assigned to the agency on payment with no retained licence or copies; work in client-side repositories and accounts; model and hosting costs passed through at cost; a DPA, sub-processor list, no-training commitment, deletion terms and fast incident notice; confidentiality with an exception for legally required disclosure; a defect warranty, a separate support retainer and full handover on exit. It is not legal advice.
What contracts does a white-label AI project need?
Two, and they have to agree with each other. The agency signs one contract with its client and another with its white-label partner. Whatever the agency promises the client - on scope, ownership, data protection and support - has to be backed by a matching promise from the partner, or the agency is carrying a risk it cannot control.
This post sets out what to put in the agency-partner contract so that it does. It is a checklist from the side that builds the systems, not legal advice; have your own lawyer draft or review the agreement, particularly for regulated clients or cross-border data.
What should be signed before a white-label AI partner sees the brief?
A mutual NDA and a non-solicit, before the partner hears anything about the client. Scoping an AI project means sharing the client's name, their problem and often samples of their data, and that should never happen on a handshake.
- Mutual NDA covering the client's identity, the brief, and any data shared during scoping.
- Non-solicit covering the agency's client and the agency's staff, for the engagement and a period after it.
- Agreement that the partner does not contact the client directly unless the agency arranges it.
We sign both before scoping, and treat a partner that wants to see the brief first as a warning sign. How our engagements run from that point is on how a white-label engagement works.
How should scope and acceptance be written in an AI development contract?
AI projects are where vague scope does the most damage, because a system can be "working" and still wrong a fifth of the time. Write scope as behaviour and acceptance as a test, not as a list of features.
Scope
- The job, in one or two sentences: who uses it, what triggers it, what it produces.
- The systems it reads from and writes to, by name.
- A capability boundary: what it may do on its own, what needs a person to approve, what it must never do.
- An explicit out-of-scope list. What is not written down will be assumed by someone.
Acceptance
Tie acceptance to an evaluation set: a fixed list of real cases with agreed correct outcomes, built early in the project, and a score the system must reach on it. "The agent takes the right action on at least an agreed share of the test cases, and escalates rather than guesses on the rest" is a clause both sides can check. "The agent works as intended" is an argument waiting to happen.
Changes
Changes priced and agreed in writing before they are built. A good partner will not use change requests to recover a bad estimate, and the contract should say the fixed price covers the written scope in full.
Who should own the code, prompts and data in a white-label AI project?
The agency, and through the agency the client, depending on what the agency has promised. The partner should not keep anything that would let it resell the client's system or hold the agency hostage.
- Work is done in repositories and cloud accounts the agency or client owns, from the first commit - so there is nothing to transfer at the end.
- Intellectual property in the deliverables - code, prompts, evaluation sets, documentation - is assigned to the agency, or as the agency directs, on payment.
- The partner retains no licence to the deliverables and keeps no copy after handover.
- A carve-out for open-source components and the partner's general know-how, which cannot be assigned and should not need to be.
- Commit authorship and documentation under an identity the agency controls, if the work is to appear as the agency's own.
What data protection terms does a white-label AI contract need?
The partner will usually process the client's personal data, which makes it a processor or sub-processor under GDPR and similar laws. The contract needs to carry the client's data obligations down to the partner, and some of them cannot be hidden behind the white label.
- A data processing agreement between agency and partner that mirrors the one between client and agency.
- A list of the partner's own sub-processors - model providers, hosting - and notice before it changes. We give 30 days.
- A commitment that client data is not used to train the partner's or the model provider's models, with the account settings documented.
- Retention and deletion: what the partner holds on its own infrastructure is deleted at the end of the engagement and confirmed in writing. Ours is within 30 days.
- Incident notification to the agency fast enough for the client to meet its own deadlines - we commit to 24 hours, which leaves room inside GDPR's 72-hour window.
- Data residency, if the client needs data kept in a region.
The one place white-label confidentiality has to give way: if the client's contract or data protection law requires sub-processors to be named, the partner must be named, accurately and through the agency. Write that exception in rather than discovering it during the client's security review. Our standing terms are on the security and data handling page.
Who should pay for model API and hosting costs?
The client, directly, on accounts in the client's or the agency's name, at cost. The contract should say that the partner does not resell model usage or hosting, and that keys and billing for both belong to the client side from day one.
A partner that bundles API spend into a fixed fee is either padding the price or carrying a risk that becomes the agency's problem in a busy month. Pass-through also means nothing has to be migrated at handover, which is the most common point for a project to slip.
How do you keep the partner invisible to the client?
Spell out what "white label" means in practice, because each side tends to assume something different.
- The partner's name appears on no deliverable, commit, document or invoice the client sees.
- No publicity, case study, logo use or testimonial request about the agency or the client without written consent.
- Partner staff use agency email aliases and attend client calls only as the agency arranges.
- The legal-disclosure exception above, so confidentiality never conflicts with data protection law.
What warranty, support and SLA terms should a white-label AI contract include?
Defect warranty
A fixed period after acceptance during which the partner fixes defects against the agreed scope at no cost. Agree the length explicitly. Define a defect as a failure to meet the written scope or acceptance criteria - not a new requirement discovered in use.
Support and SLA
Ongoing support belongs in a separate retainer with its own terms: response times by severity, hours of cover, how incidents are reported, and what the monthly fee includes. Do not promise the client an SLA the partner has not signed up to.
Model changes
AI systems have a dependency ordinary software does not: providers update and retire models on their own schedule. Agree who notices, who re-runs the evaluation set and who pays for the work when a model is retired - usually covered by the retainer, and billed as a change if there is none.
Liability and exit
A liability cap that matches what the agency has accepted from the client, and a termination clause that guarantees handover of everything - code, prompts, evaluation data, documentation and access - whatever the reason the engagement ends.
What is the checklist for a white-label AI development contract?
| Clause | What to include | Why it matters |
|---|---|---|
| NDA and non-solicit | Mutual, signed before scoping, covering client and staff | Protects the relationship you are bringing |
| Scope | Job, systems, capability boundary, out-of-scope list | Fixed price is only as fixed as the scope |
| Acceptance | Evaluation set and agreed score | Makes "done" checkable |
| IP | Assigned on payment; no retained licence or copies | You can sell and support it without the partner |
| Accounts | Repos, cloud and model keys on the client side | Nothing to migrate; no hostage risk |
| Running costs | Passed through at cost, never resold | Keeps a busy month off your margin |
| Data protection | DPA, sub-processor list, no training, deletion, incident notice | Flows the client's obligations down |
| White label | No name on deliverables; disclosure only where legally required | Your brand, with no legal conflict |
| Warranty and support | Defect period; separate retainer with SLA; model-change terms | Month two is covered, not argued |
| Exit | Full handover on termination for any reason | You are never stuck |
What should a white-label AI development contract include?
A mutual NDA and non-solicit before scoping; scope written as behaviour with an explicit out-of-scope list; acceptance tied to an evaluation set and score; IP assigned to the agency on payment with no retained copies; work in client-side repositories and accounts; model and hosting costs passed through at cost; a DPA, sub-processor list, deletion terms and fast incident notice; white-label confidentiality with a legal-disclosure exception; a defect warranty, a separate support retainer, and full handover on exit. Have a lawyer review it - this is a builder's checklist, not legal advice.
For how this fits into delivering AI work as an agency, see white-label AI development and how agencies price AI services.