Freelancing and Consulting in AI
5 min read · updated August 3, 2026
Consulting on this work has one structural difficulty that most software consulting does not: at the moment you sign, neither party knows whether the thing is possible to the standard required. Every contracting problem in the field descends from that one fact.
The problem with the usual contract shapes
A fixed-price contract prices certainty. It works when the work is knowable in advance — build this screen, integrate that API — because the supplier can estimate and pad. Here the central question is often “can a model do this reliably enough on your data”, and the honest answer before doing the work is that nobody knows. Fixed price under those conditions means one of two outcomes: you pad enormously and lose the work, or you do not and absorb an unbounded risk.
Time and materials shifts the risk entirely to the client, which is honest but unsellable to a buyer who has been told this technology makes things easy. And it creates a genuine misalignment: the supplier is paid more for taking longer on a problem that might not be solvable.
The resolution is not a cleverer contract. It is splitting the engagement at the point where the uncertainty resolves — which is almost always earlier than people expect, and cheaper to reach than they fear.
Sell the discovery separately
A short, separately priced first phase whose deliverable is a decision rather than a system. Two to three weeks is usually enough, and its output is:
- A written definition of failure for this task, agreed by the client. This alone justifies the phase; most organisations have never written one and discover during the exercise that two stakeholders wanted different things.
- A frozen evaluation set built from the client’s real data, with the failure definition applied. It belongs to the client and outlives the engagement, which makes it easy to justify paying for.
- A measured baseline — what a straightforward implementation achieves on that set today, with a cost per unit of work attached.
- A recommendation with a number, including the option of not proceeding. A discovery phase that can end in “this is not worth building” is worth far more than one that cannot, and being visibly willing to say it is the strongest trust signal available to a consultant.
After discovery, the uncertainty that made the main contract unpriceable is largely gone. You now know roughly where quality sits, what it costs per unit, and which part is hard. Fixed price becomes possible precisely because the discovery was not fixed price.
Four structures and who carries the risk
| Structure | Description |
|---|---|
| Time and materials | Client carries all outcome risk. Appropriate for genuinely exploratory work and for augmenting a team that has its own direction. Needs a spend cap and a regular checkpoint to be acceptable to a buyer, and the checkpoint should be a decision point, not a status update. |
| Fixed price on a defined deliverable | Supplier carries delivery risk. Only safe after discovery, and only where the deliverable is defined by an artefact ('a pipeline that processes these documents into this schema') rather than by a quality level. |
| Fixed price against a quality threshold | Supplier carries outcome risk, which is the dangerous one. Signable only when the threshold is defined against a frozen set that exists at signing, and even then it prices a risk you cannot fully assess. Requires an explicit clause for what happens if the threshold is unreachable. |
| Retainer for ongoing operation | Shared. The most underrated structure in this field, because model-based systems need continuous attention — evaluation runs, provider changes, cost drift, silent regressions. It matches how the work actually behaves after launch. |
The retainer row deserves emphasis. A system built on a hosted model is not finished when it ships: the dependency changes underneath it, usage patterns drift, and the cost profile moves. A client who understands that is a client who needs somebody after go-live, and it is the most sustainable part of this business.
Writing a scope that survives
Four clauses that prevent the specific disputes this work produces. Each exists because of a predictable argument.
- Define success against a named artefact. “90% on the evaluation set frozen on the 12th, per the failure definition in appendix A” — not “accurate extraction”. Once the set is frozen and shared, the argument about whether it works becomes an arithmetic question. Freeze it before you start.
- State what happens if the threshold is unreachable. Because sometimes it is. A phased release of payment against evidence, or an agreed pivot to a narrower scope, or an explicit option to stop with the discovery deliverables retained. Silence here is where relationships end badly.
- Name who owns the data, the prompts and the evaluation set. Ambiguity here surfaces at exactly the wrong moment. Also name what may be used in your own future work; clients care about this more than consultants expect.
- Put a boundary around inference cost. Whose account is billed, what the cap is, and what happens if usage exceeds the forecast. A spend control agreed in the contract is much easier than one negotiated after an invoice, and a forecast with visible assumptions is the document that makes the conversation calm.
One more, less formal: agree in writing who the decision-maker is on quality. Model-based systems produce endless small judgement calls about acceptable output, and a project with three stakeholders and no named arbiter will consume its budget in review meetings.
On rates, and where to find them
This page contains no rate figures, deliberately. Rates vary by country, sector, engagement type and year by more than any single number could usefully span, and a figure printed here would be both unsourced and quickly stale — and a consultant who priced from it would be pricing from fiction. What can be said is what moves the number, and where to look it up.
- What you are selling changes the price more than what you can do. Implementation capacity is priced against engineering labour. A decision — is this feasible, what will it cost, should we build it — is priced against the value of the decision, which is a different and usually larger number for the same week of work.
- Scarcity attaches to specifics. Familiarity with a regulated sector, a language, a document type or a compliance regime is scarcer than familiarity with models, and it is what makes an engagement non-substitutable.
- Risk carried is compensated. A fixed price against a quality threshold should cost the client materially more than time and materials, because you are selling insurance as well as work. Consultants routinely forget to price that.
- Where to look: published rate cards from comparable independent consultants in your country, rates in public sector procurement frameworks (frequently published and a genuinely useful floor), professional body surveys, and — the most accurate source available to you — what your last three engagements actually closed at, adjusted for how long you waited between them.
A final note on utilisation, because it is the number that determines whether the business works and is not the day rate. Time spent selling, writing proposals, and on engagements that do not close is unpaid, and it is a large fraction of the year. Any rate comparison against an employed salary that ignores it is not a comparison.