Terms for small AI projects: what to cover (not legal advice)

Terms for a small AI project fit on one page and cover seven things: the scope (the brief, attached, with exclusions), payment (amounts, schedule, what triggers each), what the client provides and by when, how data is handled, whose accounts host the automation and who owns what afterwards, what support is included and for how long, and how changes, delays and cancellation work. This is a checklist for what your terms must say, not a contract; have a lawyer turn it into your standard document once and reuse it for every project.

Why one page, and why before the first invoice?

Because the disputes on small projects are predictable: "I thought that was included", "we'll pay when it's fully working", "we need it on our server after all", "can you keep supporting it for free?". Each one is a paragraph. Written before the pilot, they are agreements; discussed after, they are arguments.

1. Scope

Attach the one-page brief and refer to it. Repeat the exclusions in the terms. State what "done" means in the same words as the brief: "runs on real inputs for five working days without manual fixes". Ambiguity here costs more than anywhere else.

2. Payment

Amounts, currency, and what triggers each payment: a share on approval of the brief, the rest on "done" as defined. Payment terms in days. What happens if the client delays access (the clock pauses, or the schedule shifts). Whether the pilot fee is credited against a full build. Invoice details per the Tax Authority's rules for your business status.

3. Access and cooperation

What the client provides and by when: accounts, credentials, sample data, a decision-maker's availability. Say plainly that the timeline starts when access is granted. This one sentence prevents the three-week pilot.

4. Data

Reference the data checklist: what personal data the automation touches, which vendors process it, retention, and what happens to your access at the end. State that the client remains responsible for their customer data and their legal obligations, and that you'll handle it as agreed in writing.

5. Ownership and accounts

Prefer the client's accounts for every tool. State that the workflow built for them is theirs to use, that your generic templates and know-how remain yours, and that your access ends at hand-over unless a support plan says otherwise. Say who pays the tool subscriptions.

6. Support

What's included after hand-over and for how long: usually a short warranty period for defects in the agreed scope, then the support plan if they take one. Not included: changes, new features, failures caused by changes the client made.

7. Changes and ending

Changes are written add-ons with their own price and timing. Either side can end the project with notice; work done is paid for; you hand over what exists. Without this paragraph, ending badly is the only way to end.

Keep the tone readable

Terms an owner can read in five minutes get signed; terms that look like a lease get "let me check with someone" and silence. Plain language, short sections, the same words as the brief.

Note This guide is editorial, not legal advice. Laws on contracts, invoicing and data differ; a lawyer should review your standard terms once, and anything sensitive every time.

Best fit and not a good fit

Best fit: builders about to invoice their first or fifth client who have no written terms yet. Not a good fit: large or regulated projects; those need a lawyer from the start, not a checklist.

What to do this week

Draft your seven sections on one page from your last project's brief. Book an hour with a lawyer to turn it into your standard terms. Send it with your next pilot offer.