The battle of forms: template contracts vs AI-era risks

Our client is a UK AI development studio. It builds AI systems for other businesses: bespoke models, fine-tuned on the customer's data, integrated into the customer's own environment and doing real work inside the customer's day-to-day operations.

It had won a significant engagement. The commercial terms were agreed quickly. The contract was not.

Two forms, one deal

With our help the studio had prepared a master services agreement (the "MSA") that did something most development agreements still do not do. It named the ways an AI system can fail, said which party carries each failure and priced that allocation into the deal. Measurable performance thresholds against an agreed evaluation set instead of a promise to "perform in accordance with the documentation". A clear rule on what the customer must do before relying on an output for a decision that matters. A line between the studio's reusable tools and the deliverable the customer was paying for. Rights over inputs, outputs and training. A mechanism for model changes and upstream deprecations. A liability cap sized to the actual exposure rather than to the whole contract value.

The customer was advised by a well-established US technology law firm. Their first response was short: they would not work from our draft. The deal would be papered on their template, a classic software development MSA of the kind that has closed thousands of engagements.

That is a normal opening position, and often a sensible one. A customer's template is the customer's comfort zone, and a supplier that refuses to engage with it usually loses the deal rather than the argument. So we agreed to work from their paper.

What the template did not say

Their template was a good document for what it was written for. It was simply written for software that behaves the same way every time. Read against an AI build, it was silent on every question that decides who pays when something goes wrong, and in one place it pointed the wrong way.

• What counts as the system working. The warranty was conformity with a specification. A probabilistic system cannot conform to a specification in that sense. It can meet a threshold, measured in an agreed way, on an agreed set of cases.
• What the customer must do before relying on an output. Nothing. Which meant every wrong answer was, on the template's own terms, arguably a breach.
• Who owns what. The template assigned all intellectual property in the deliverables to the customer and carved out only material the studio had developed before the engagement. Nothing distinguished the studio's background IP (its model architectures, fine-tuning pipelines, prompt libraries, evaluation harnesses and scaffolding code, built up across many engagements) from the foreground IP created for this customer. Prompts were not mentioned at all. Nor was the trained model: the definition of deliverables could not tell a set of model weights from a written report.
• Whose data trains what. The confidentiality clause pre-dated the idea that data fed into a model can shape the model, and that inferences drawn from non-confidential data can themselves be confidential. Read literally, its restriction on processing confidential information through AI models would have prohibited the very work the studio was engaged to do.
• What happens when the model underneath changes. The studio's product sits on third-party model terms it does not control. The template had no mechanism for a deprecation, a price change or a usage-policy change flowing down the chain.
• Who is responsible for which regulatory obligations. Not a word on provider and deployer roles, human oversight or the customer's own automated decision-making exposure.
• How much liability is in play for an inaccurate output, and whether it sits under the general cap, under a separate cap or outside the cap altogether.

None of this was hostile drafting. It was a template that had not caught up with its subject matter.

How the conversation turned

We did not send a mark-up with twenty new clauses and a cover note. We ran the negotiation as a series of explanations, first with our own client and then, with the client in the room, with the customer's commercial team and their lawyers.

For each gap we asked the same three questions. What does this failure look like in practice? Who would the customer expect to carry it if it happened next month? What does the template currently say about it? The answers to the first two questions were almost always agreed on the spot. The answer to the third was, almost always, nothing.

That reframing mattered. The customer's lawyers were not resisting our allocation of risk. They were resisting an unfamiliar document. Once each clause was tied to a concrete scenario that their own client had already said it understood, the clause stopped being a supplier's wish-list and became the written form of a commercial agreement that already existed.

The IP point is a good example. Put as "the supplier keeps its tools", it reads as a grab. Put as "you are paying for this model and this integration, not for the right to stop us building the next one", with the customer getting a perpetual licence to whatever of those tools is embedded in its deliverable, it was agreed in a single call.

It took longer than a conventional negotiation. There were several rounds with the client, and several with the other side. Each round closed a gap rather than reopening one.

The result

The signed contract contains the same clauses we proposed at the start, now sitting inside the customer's template. Performance thresholds against an agreed evaluation set. A defined reliance and review obligation. A clean split between background and foreground IP, with prompts, pipelines and weights dealt with by name. Explicit rules on inputs, outputs and training. A model-change mechanism. A liability structure that both sides can explain to their boards.

The customer's lawyers said, near the end, that their client had agreed with our client's proposals in practice from the beginning. The open question had only ever been the legal allocation of risk, and they had come to see that their template did not address any of the questions on which that allocation turned.

"AI deals rarely stall on commercial disagreement. They stall on a contract that has no vocabulary for the risks both sides already accept."

What this means for you

If you sell AI, your first enterprise contract becomes the template for the next twenty. Fixing it later means renegotiating with every customer at once.

If you buy AI, the supplier's silence on these points is not neutral. It leaves you carrying the risk of a wrong output, a model change and a regulatory role you may not have chosen.

Either way, the contract you are about to sign can be tested in an afternoon. The checklist below is the one we use. Tick each line your MSA answers. The unticked lines in the first four groups are where the next dispute will start.

The client and the counterparty are not named and identifying details have been altered. Nothing in this article is legal advice.