Terms Before Prompts: Contract Language for AI-Assisted Consulting

Most statements of work are drafted for a project that no longer quite exists. The engagement opens with a scope, a schedule, and a rate card, and then somewhere in week three an engineer pastes a client's schema into a chat window to see what a model makes of it. Nothing in the document anticipated that moment, so the conversation that follows is about trust rather than terms — which is the worst possible footing for either.

The fix is not a single sweeping paragraph. It is a small family of provisions, written in plain English, that answer five questions before anyone opens a browser tab. None of them require a law degree to draft; all of them require that the consultancy has actually thought about how it works.

What Leaves the Room

Start with data, because it is the provision most likely to be tested first and least likely to be documented. Define the categories explicitly: client data, prompt content, telemetry, and whatever the vendor retains on its side. Then say where each may go.

For a US client base, that usually means naming the applicable regime — a service-provider addendum under a state privacy statute, a business associate arrangement if health data is anywhere near the work, export-control language if the client is in defense or aerospace. The clause should state that prompts are submitted only through vendors offering a no-training configuration at the enterprise or API tier, that retention is set to the minimum the vendor permits, and that client data is deleted at termination on a documented schedule.

One sentence does a lot of work here: Consultant will not submit Client Data to any model provider that uses submitted content to train or improve its models, and will maintain a current list of approved providers in the project record. That is short enough to survive redlines and specific enough to be auditable.

Name the Models, or Name the Process

Clients reasonably worry about silent substitution — the tool named in the proposal is retired or repriced mid-engagement, and the substitute was chosen by a vendor nobody at the client has heard of. The statement of work cannot freeze technology forever, but it can make change visible.

Two mechanical options work. The first is an exhibit listing approved tools by name and version family, with a notice period before any addition or swap. The second is a process clause: consultant maintains a register of models and providers used on the engagement, updates it when the register changes, and treats a change of provider — not a version bump within the same provider — as a notice event. The process version ages better; a named list is stale within a quarter.

Either way, connect disclosure to the deliverable. The register belongs in the project documentation the client receives at close, alongside the architecture notes.

Ownership of What the Machine Produces

Ownership language that was adequate for hand-written code is now slightly incomplete. Under current US Copyright Office practice, works lacking human authorship are not registrable, and that includes output generated without meaningful human contribution. A consultancy cannot assign what does not exist, so the clause should do two things rather than one.

First, assign by warranty and by quitclaim: all rights the consultant holds in the deliverables pass to the client, and the consultant assigns any interest it may have in AI-assisted material incorporated into the deliverables. Second, warrant the human part — that the selection, arrangement, review, and modification of generated material was performed by the consultant's personnel, and that the consultant is not aware the deliverables infringe third-party rights.

Watch the downstream licenses as well. Open-weight models carry their own terms, and some impose attribution or use restrictions that survive into the client's product. The statement of work should promise disclosure of any such terms attached to the deliverables, so the client's counsel is not discovering them at launch.

Cost Creep Is a Scope Problem

Usage-based pricing breaks the fixed-fee habit. Two teams can run identical pipelines and see bills an order of magnitude apart because one of them retries aggressively. The statement of work should decide in advance which party carries that variance.

The cleanest arrangement is a stated monthly allowance per workstream, billed at pass-through cost with no markup, with anything above the allowance requiring written approval. Show the estimate in the proposal with the assumptions that produced it — token volume, model tier, evaluation runs — so the client understands the meter is theirs. Where the consultancy prefers a fixed fee, it should price the risk explicitly rather than absorb it silently and discover the problem at invoice time.

The Exit Ramp

Clients ask, sooner or later, whether they can run this themselves. The answer should be written down before the question is emotional.

A workable transition clause grants the client a perpetual license to use, modify, and operate the deliverables in-house, obliges the consultant to deliver the prompt library, pipeline configuration, and evaluation harness as project artifacts rather than internal assets, and offers a defined period of transition assistance at published rates. If the client instead wants to move to another firm, the same artifacts satisfy that path.

What the clause should not do is pretend switching is free. Model-specific prompting does not travel cleanly, and a candid consultancy says so in the document — a short paragraph noting that portability of results depends on the receiving model, and that re-validation is a scoped activity with its own estimate.

A Short Checklist

• Data categories defined, with permitted destinations and retention limits.
• Vendor tier specified: no training on client content, minimum retention.
• Register of models and providers, with notice obligations for changes.
• Assignment plus human-authorship warranty, and disclosure of upstream model terms.
• Usage allowance, pass-through terms, and an approval threshold.
• Transition rights, artifact list, and rates for assistance.

None of this is exotic. It is the ordinary work of writing down how a practice actually operates, which is what a statement of work has always been for. The tools changed; the obligation to describe them did not.