AI and ML
AI Implementation Contracts: Accuracy KPIs, Error Liability, and Model Ownership
A contract copied from a standard software project does not answer the questions specific to AI: what counts as a model error, and who is liable if the agent gives a customer the wrong answer.
In short
A standard software development contract does not cover three questions specific to an AI project: how answer accuracy is measured and what counts as an acceptable threshold, who bears liability if a model error caused a loss or gave a customer wrong information, and who owns the fine-tuned model, prompts and knowledge base after the work concludes. Each of these is worth writing in explicitly and in advance, by default neither the law nor standard contract templates give an unambiguous answer to any of them.
Why a standard template falls short here
A website or app development contract is built around a clear acceptance criterion: a feature either works to spec or it does not. An AI system works differently, it does not give a stable, identical result for an identical input, and "working correctly" is a probabilistic characteristic, not a binary one. A contract that ignores this difference leaves both sides with no clear criterion for what even counts as completed work.
The three clauses that need writing in separately
| Clause | What it establishes |
|---|---|
| Accuracy KPI | An accuracy metric, a measurement method, and an acceptable threshold tied to the final payment milestone |
| Error liability | Who is liable for loss from a wrong model answer: vendor, client, or split liability by error type |
| Rights to the model and data | Who owns the fine-tuned model, prompts, knowledge base and configuration after the project concludes |
How to measure accuracy so it is actually checkable
An AI system’s accuracy is measured against a pre-agreed test set of realistic questions with known correct answers, not a subjective "looks pretty good" impression from a few examples during a demo. The contract should fix: who compiles the test set (ideally both sides jointly, to avoid bias), what percentage of correct answers counts as an acceptable threshold, and what happens if the threshold is not met, rework at the vendor’s expense, not automatic payment as for a completed milestone.
Error liability: split by type, not a blanket clause
A blanket clause saying "the vendor bears no liability for the AI system’s output" is a red flag, not standard practice, it shifts all risk onto the client, including cases where the error stems from objectively poor architecture or insufficient testing on the vendor’s side. The working approach is splitting liability by error type: the vendor is liable for systemic failures and errors caught on the agreed test set; the client is liable for the quality and completeness of the source data they provided for training or configuring the system.
Rights to the model: what needs naming explicitly
By default, if the contract stays silent on this, rights to the fine-tuned model, prompts and knowledge base can remain ambiguous or de facto belong to the vendor, especially if the whole system runs on the vendor’s own infrastructure. The client should explicitly write in the right to receive a copy of all prompts, configurations and the knowledge base in a portable format, and, where applicable, the right to the fine-tuned model weights, before signing the contract, not at the moment the decision to switch vendors has already become urgent.
Frequently asked questions
Why doesn’t a standard software development contract fit an AI project?
Because it is built around a binary acceptance criterion ("works or doesn’t"), while an AI system produces a probabilistic, not always identical result. Without separately written accuracy KPIs, error liability and model rights, both sides are left with no clear criterion for what counts as finished work.
How should an AI system’s accuracy be measured in a contract?
Against a pre-agreed test set of realistic questions with known correct answers, not a subjective impression from a demo. The contract should fix who compiles the test set, what accuracy percentage is acceptable, and what happens if the threshold is not met.
What in a liability clause should raise a red flag?
A blanket clause fully absolving the vendor of liability for the AI system’s output, that is a red flag shifting all risk onto the client. The working approach is splitting liability by error type: the vendor for systemic failures, the client for the quality of the source data they provided.
Who owns the trained model if the contract says nothing about it?
By default this can remain ambiguous or de facto go to the vendor, especially if the system runs on their infrastructure. Rights to the prompts, knowledge base and configuration in a portable format are worth writing in explicitly before signing, not retroactively when switching vendors.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- AI strategy consultingMost companies have already run at least one AI pilot. A minority have taken even one pilot to stable, ongoing use. The gap usually is not the model, it is whether the process had a measurable payoff and whether the real running cost was worked out before starting. We help pick the right entry point so budget does not disappear into a demo that stays a demo.
- IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
- AI and ML developmentWe build AI that solves a defined task and pays for itself, not demos for the sake of demos. Classifiers, recommendations, text and document processing, LLM assistants, and model integration into an existing product.
Read next
- How to Tell Custom AI Development From a Wrapper Around Someone Else’s APIA ready-made bot on someone else’s API and genuine custom development look identical in a demo. The difference only shows up in questions most people never ask.
- How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.
- Technical Due Diligence Before Investment or AcquisitionA codebase red flag rarely kills a deal outright — more often it changes the price, the escrow terms, or the post-close commitments. What gets reviewed, and why rushing it under deal pressure produces worse findings.