A generic services master agreement was written for work whose output is a report, a configuration, or a set of hours. AI and data engineering produce something different: a system whose behavior is statistical rather than specified, built on data whose provenance carries obligations, running against third-party models whose own terms reach through the contract to bind both parties. A template that never contemplated any of that will be signed, and then the gaps will be discovered during delivery, which is the expensive moment to discover them.
This is a clause-by-clause guide for the counsel or procurement lead drafting or reviewing one. It covers what is missing from a standard template, the position each side usually takes, and where the reasonable landing point sits. It is a practical guide rather than legal advice, and the drafting should be done by counsel who knows the jurisdiction and the client's risk appetite.
The seven gaps in a generic template
Before the clause-by-clause, here is the shape of the problem. A standard services template handles confidentiality, liability, term and payment perfectly well. It typically has nothing useful to say about: who owns a trained model as distinct from the code that trained it; whether client data may be used to improve anything; how a third-party model provider's terms flow through; how to accept a deliverable whose output is probabilistic; what security obligations attach to data in transit through an inference endpoint; what audit rights mean when the thing being audited is a model's behavior; and what a knowledge transfer must contain for a system that will be retrained after the supplier leaves.
Clauses where a generic services template most often leaves a real gap
Editorial weighting, illustrative rather than measured. The last row is deliberately low: standard templates already handle confidentiality well.
Intellectual property: separate the four things being created
A single "deliverables are assigned to client" sentence is not enough, because an AI engagement produces four categories of artifact and they do not all move the same way.
The code. Pipelines, services, interfaces, infrastructure definitions, evaluation suites. This should be assigned to the client outright by a written present assignment. Work-made-for-hire language alone is insufficient in the United States for software, because a commissioned work qualifies as a work made for hire only where there is a written agreement and the work falls within a narrow enumerated set of categories, and software is not among them. Without a present assignment, a client can end up with an implied licence rather than title, and discover it during a due diligence process years later.
The trained model. Weights, adapters, fine-tuned checkpoints, prompt templates and configuration. These are distinct from the code that produced them and should be named separately in the assignment clause. A clause listing only "software and documentation" can leave the weights unaddressed, and weights derived from the client's own data are the artifact the client cares most about.
Derived data. Labels, annotations, embeddings, feature tables, synthetic data generated from client data, and evaluation sets built from client records. These should follow the client data and belong to the client. Suppliers sometimes want to retain annotation guidelines and label taxonomies. That is negotiable and usually fine; the labels themselves are not.
Supplier background technology. The tools, libraries, scaffolding and internal frameworks the supplier brought with them. These should be listed by name in a schedule, expressly excluded from assignment, and licensed to the client perpetually, irrevocably and royalty-free for use, modification and maintenance of the delivered system, with the right to let a third-party maintainer exercise the licence. An unlisted background carve-out is the clause that later blocks a client from hiring anyone else to maintain their own system.
The usual positions: clients open by asking for everything including background technology, suppliers open by offering a licence to the deliverables rather than assignment. The reasonable landing is assignment of code, models, derived data and documentation, with a named and bounded background carve-out plus a broad licence back. Requiring the schedule to be complete at signature, with a provision that anything not listed is deemed assigned, gives the client the protection without the fight.
Data: three separate permissions, not one
Most disputes labelled "data ownership" are actually about permission to use, and the clause should split into three questions.
May the supplier use client data to build this system? Yes, obviously, and the clause should specify where the data may live, who may access it, what environments it may enter, and what happens to it at termination. In practice the strongest arrangement is that the data never leaves the client's environment and the supplier works inside it, which removes most of the argument.
May the supplier use client data for anything else? The answer should be an explicit no, stated in words that cover training, fine-tuning, evaluation, benchmarking, product improvement, and any aggregated or de-identified derivative. Suppliers sometimes seek permission to use aggregated or anonymized data to improve their offerings. Clients in regulated sectors should decline. The clause is worth spending negotiation on, because a generic confidentiality clause does not clearly cover model training, and a supplier acting in good faith on a template can create an exposure nobody intended.
May any third-party model provider use it? This one is missed most often. When a system calls a hosted model, the data goes to a provider whose terms govern retention and training. The agreement should require the supplier to configure any such service so that client data is not retained beyond the request and is not used for training, to name the providers in a schedule, to obtain approval before adding one, and to pass through the client's restrictions. Providers offer enterprise arrangements that support this; the contractual obligation is to actually use them.
Training-data provenance and third-party rights
Where the system is trained or fine-tuned on data that is not purely the client's own, the agreement needs a representation about where that data came from and what rights attach to it. Public availability is not the same as permission to use, and the licence terms on open datasets and open-weights models vary widely, including terms that restrict commercial use, require attribution, or impose conditions on downstream outputs.
A workable clause requires the supplier to maintain a written inventory of every dataset and model used, with its source and licence, delivered to the client with the system; to represent that all use is permitted under those licences for the client's stated purpose; and to notify the client before introducing any dataset or model whose licence imposes conditions on the client's use of the output. That last part matters more than it sounds. A permissive-looking model with a condition attached to derived outputs can constrain how a client commercializes the system, and that is a business decision rather than an engineering one.
On indemnity, the usual positions are far apart. Clients want a full intellectual property indemnity covering all outputs. Suppliers resist indemnifying the behavior of third-party models they did not train. The reasonable landing is that the supplier indemnifies for the code and artifacts it created and for its representations about licences and provenance, while third-party model output risk is handled by naming the providers, passing through whatever indemnity those providers themselves offer, and by design controls such as retrieval grounded in the client's own content and human review at defined decision points.
Acceptance criteria for a probabilistic system
This is the clause most likely to be missing entirely, and it causes more delivery disputes than everything above combined. A deterministic deliverable either does what the specification says or does not. A model produces a distribution of outcomes, so acceptance has to be defined statistically or it cannot be defined at all.
- A named evaluation dataset, fixed before work starts. Identified by name and version, held by the client, with a stated construction method. Acceptance measured on a set the supplier assembled after seeing the model's behavior means nothing.
- Metrics with thresholds, chosen for the decision the system supports. Not "accuracy" in the abstract. Where errors are asymmetric, state precision and recall separately with separate thresholds, because a single blended figure hides exactly the failure the business cares about.
- Performance on named subgroups, not only in aggregate. A system that meets a threshold overall and fails badly on a segment is a system that will be withdrawn after launch. State the segments and the minimum performance on each.
- Operational thresholds alongside quality ones. Latency at a stated load, availability, and cost per thousand operations. A system that meets its quality bar at unacceptable latency or cost has not been delivered.
- A defined behavior for the cases the system cannot handle. Abstention, escalation to a human queue, or a fallback path, with a stated maximum rate. Systems without a defined abstention path fail in the ugliest way available.
- Reproducibility as an acceptance condition. The evaluation runs from a clean checkout, on the client's infrastructure, producing the same result within a stated tolerance. This single condition prevents most acceptance arguments, because it makes the claim checkable by the client rather than demonstrable by the supplier.
- A test window, cure cycles, and a deemed-acceptance provision. How long the client has to test, how many correction attempts the supplier gets, and what happens if the client neither accepts nor rejects. Suppliers want short windows and deemed acceptance; clients want long windows and none. Landing point: a defined window, deemed acceptance after it, but with warranty obligations continuing so the client is not left without recourse.
- What happens if the threshold is not met. Options are a cure period, a price adjustment, a scope reduction agreed in writing, or termination with payment for accepted milestones. Say which, in advance, while both parties are still calm.
Security, audit and liability
| Clause | Client's usual opening | Supplier's usual opening | Reasonable landing |
|---|---|---|---|
| Security obligations | Full control framework, certified, audited annually | Reasonable industry standard practices | Named controls appropriate to the data class, with evidence and a stated verification method |
| Audit rights | On-site audit at any time | Annual report review only | Documentation and evidence on request; on-site limited to cause or once yearly with notice |
| Breach notification | Immediate | Without undue delay | A stated hour count from confirmation, with defined content and a single contact |
| Liability cap | Uncapped, or a large multiple of fees | Fees paid in the preceding twelve months | A multiple of fees, with carve-outs for confidentiality, data misuse, IP indemnity and wilful misconduct |
| Data misuse | Inside the general cap | Inside the general cap | A separate, higher sub-cap. This is the risk that actually matters here |
| Subprocessors and model providers | Prior written consent for each | Notice with a right to object | A named schedule at signature, consent for additions that touch client data, notice otherwise |
One drafting note on liability. On AI work the risk is not usually a general services failure; it is data exposure or misuse. A structure that caps ordinary liability modestly while carving data misuse into a separate, higher sub-cap is more protective for the client and easier for a supplier to accept than a single large cap on everything, because it prices the risk where the risk actually lives.
Terms worth spending negotiation time on, weighted by effect on the delivered system
Editorial weighting, illustrative rather than measured. The last row is deliberately low: those clauses rarely change the delivered outcome.
Knowledge transfer, written as a deliverable
Standard templates handle termination and say nothing useful about what the client receives. For a system that will need retraining, this is the clause that decides whether the client owns a system or owns a black box.
Make the transfer package a named deliverable tied to final payment: source code and infrastructure definitions in the client's repositories; the trained artifacts with the exact configuration and commit that produced them; the data snapshot identifiers and the pipeline that reconstructs the training set; evaluation datasets and the suite that runs them; a documented retraining procedure including how often and on what trigger; the inventory of datasets, models and licences; runbooks covering monitoring, alerting, rollback and the kill switch; the incident history and known limitations, written honestly; and a rehearsal in which the client's own engineers deploy and retrain while the supplier observes and does not touch a keyboard.
That last item is the one to insist on. A handover document that has never been executed by the receiving team is a document, not a transfer.
How we approach the agreement
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack software, and delivers them into production, including inside U.S. federal agencies where the data-handling, accessibility and authorization bar is set by someone other than the sponsor. That work shapes the positions we take, because the terms above are the ones we already operate to.
Our standard positions, sent with the first package so counsel can see where we already agree: code, trained models, weights, prompts, derived data, labels and documentation assigned to the client outright by present assignment; our background tooling listed by name in a schedule and licensed to the client perpetually, irrevocably and royalty-free, including the right for a third-party maintainer to use it; client data never used to train, tune, evaluate or benchmark anything outside the client's own system, in any form including aggregated or de-identified; any third-party model service configured for no retention and no training, with the providers named in a schedule and no additions without approval; a written inventory of every dataset and model used with its source and licence, delivered with the system; acceptance criteria written as measurable tests on a client-held evaluation set, reproducible from a clean checkout on the client's infrastructure; a separate higher sub-cap for data misuse; and the transfer package above as a payment-gated deliverable including the rehearsal.
What the first weeks produce: an architecture and a written scope with those acceptance criteria inside the first two weeks, and a working slice against your real data in your environment by roughly week six. We build in your environment on your accounts wherever the architecture allows, which is also the arrangement that makes most of the data clauses straightforward.
How it is priced: fixed-price milestones tied to the acceptance criteria, or a committed team at a fixed monthly rate when the roadmap is open. Payment triggers on accepted milestones, so the invoice schedule and the delivery schedule are one document.
The first step is one email with a one-page brief: the business problem, the systems the result must live inside named by product and version, what data exists and who grants access, the security destination, the date that matters, and who can approve a scope change. We return a scoped, priced statement of work with acceptance criteria written as tests, plus our marked-up standard positions so your counsel starts from a short issue list.
Five drafting mistakes worth avoiding
Assigning "software and documentation" and never naming models or data. The weights, prompts, labels and evaluation sets fall outside the clause, and they are what the client actually needs.
Relying on confidentiality to prevent model training. Confidentiality restricts disclosure. Training is a use. Write the use restriction separately and in words that cover derivatives.
Leaving the background technology schedule blank. An unbounded carve-out is a permanent dependency, and it is discovered when the client tries to hire a different maintainer.
Writing acceptance in adjectives. "Production ready" cannot be accepted or rejected. Acceptance then becomes a negotiation at the worst possible moment, with the deadline already missed and both sides invested.
Making knowledge transfer an obligation rather than a deliverable. Obligations after final payment are enforced by goodwill. Tie the transfer package, including the rehearsal, to the last milestone.
Bottom line
A generic services master agreement handles confidentiality and payment well and leaves five holes that matter on AI and data work: it does not name trained models, weights, prompts and derived data as assigned property; it does not restrict the use of client data for training in words that cover derivatives and third-party providers; it does not require an inventory of dataset and model licences; it has no way to accept a probabilistic deliverable; and it treats knowledge transfer as a post-termination obligation rather than a payment-gated deliverable. Fill those five, put the liability weight on data misuse rather than on a single large general cap, keep the background technology schedule complete and bounded, and the rest of the template can stand largely as written. The agreement then supports the work instead of being discovered to be silent about it in month four.
Frequently asked questions
Whoever the agreement says, and a generic template usually says nothing. Assign the trained artifacts explicitly by name: weights, adapters, fine-tuned checkpoints, prompt templates and configuration, alongside the code that produced them and the derived data such as labels, annotations, embeddings and evaluation sets. A clause covering only "software and documentation" can leave the weights unaddressed, which is the artifact most clients care about most because it was derived from their own data.
Statistically, and against a dataset the client holds. Name the evaluation set and version before work starts, set metric thresholds chosen for the decision the system supports with precision and recall stated separately where errors are asymmetric, require minimum performance on named subgroups rather than only in aggregate, add latency at a stated load and cost per thousand operations, define the abstention or escalation behavior and its maximum rate, and require that the evaluation reproduces from a clean checkout on the client's own infrastructure within a stated tolerance.
Only if the agreement permits it, and it should not. Write an explicit prohibition covering training, fine-tuning, evaluation, benchmarking and product improvement, and extend it to aggregated, anonymized and de-identified derivatives, because those are the forms suppliers usually ask for. Extend the same restriction to any third-party model provider the system calls, require those services to be configured for no retention and no training, name the providers in a schedule, and require approval before any is added.
Structure matters more than size. The realistic risk on this work is data exposure or misuse rather than a general services failure, so a modest cap on ordinary liability paired with a separate, higher sub-cap for data misuse protects the client better than one large cap on everything, and it is easier for a supplier to accept because it prices the risk where the risk lives. Keep the usual carve-outs for confidentiality breach, intellectual property indemnity and wilful misconduct outside the cap entirely.
Source code and infrastructure definitions in the client's repositories, the trained artifacts with the exact configuration and commit that produced them, data snapshot identifiers and the pipeline that reconstructs the training set, evaluation datasets and the suite that runs them, a documented retraining procedure with its triggers, the inventory of datasets and models with licences, runbooks for monitoring, alerting, rollback and the kill switch, an honest account of known limitations, and a rehearsal in which the client's engineers deploy and retrain while the supplier watches without touching a keyboard.