AI Implementation Contract Checklist: 46 Items to Review

An AI implementation contract should be reviewed across nine blocks: scope and measurable outcome, acceptance against a benchmark set, data and personal data, rights to the code, datasets and models, third-party models and their licenses, operating costs, security, support, and project exit. The key difference from a standard IT contract is that the result is probabilistic: “the bot answers correctly” cannot be accepted without a set of test questions and a quality threshold. Below are 46 items with owners and “done” criteria that you can copy into a working document.

Prepared by AIrassvet October 19, 2026 for executives, CIOs, lawyers, and procurement professionals on the customer side. The checklist is based on the Russian Civil Code (Arts. 720, 1235, 1296), Federal Law No. 152-FZ “On Personal Data” (Arts. 6, 12, 18), open-model licenses, and OpenAI documentation on model decommissioning. The structure and wording of the items are editorial methodology, not research findings. This is not legal advice: have your lawyer, who is familiar with your industry, review the final contract language.

In Brief
Who This Checklist Is For and What It Does Not Cover
How an AI Contract Differs from a Standard IT Contract
What Type of Contract Do You Have?
What to Prepare Before You Start
Checklist by Stage
Copyable Template
Common Mistakes
How the Checklist Was Built
Frequently Asked Questions
Primary Sources

In Brief

Without a benchmark set, there is no acceptance. Article 720 of the Civil Code of the Russian Federation requires the customer to inspect and accept the work in the manner provided by the contract — for AI, that process must be defined through test prompts and thresholds.
Rights to the result belong to the customer by default, but not to everything. Under Article 1296 of the Civil Code of the Russian Federation, a program created to order belongs to the customer unless the contract says otherwise; third-party model weights remain governed by that model’s license.
Personal data requires a separate instruction. Part 3 of Article 6 of Federal Law No. 152-FZ lists what must be included in a data-processing instruction.
The cost of ownership is not just development. Tokens, GPUs, monitoring, and retraining should be calculated before signing.
Project exit is planned from the start. Code, prompts, datasets, and deployment instructions are transferred according to a list, not “upon request.”

Who This Checklist Is For and What It Does Not Cover

This checklist is intended for a customer entering into a contract for the development and implementation of an AI solution: an AI agent, a RAG system, a chatbot, a forecasting model, or computer vision. It helps you avoid missing AI-specific terms. We do not cover the general terms of any work-for-hire contract (penalties, venue, payment procedure), industry-specific regulation such as healthcare and finance, or public procurement requirements under Federal Laws No. 44-FZ and No. 223-FZ — those require a separate review.

If you are still choosing a contractor, start with the article “How to Choose an LLM Integrator”: it covers team evaluation criteria. This checklist is the next step, once the vendor has been selected and you have a draft contract on the table.

How an AI Contract Differs from a Standard IT Contract

Conventional software is deterministic: the same button produces the same result, and acceptance can be described in “click and receive” scenarios. An AI system responds with a probability of error that depends on the data, the prompt wording, and the model version. That is why four new topics must be agreed on in the contract.

Quality as a threshold, not as a feature. You need a benchmark set of prompts, a metric, and a minimum value at which the result is considered accepted.
Customer data as input material. Documents, correspondence, and call recordings become training or retrieval data, and their processing is governed by Federal Law No. 152-FZ.
Third-party models inside the solution. The contractor almost always uses a third-party model — cloud-based via API or open-source under its own license.
Variable costs. Operating cost depends on the number of requests and the length of responses, and the provider may change pricing or decommission the model.

What Type of Contract Do You Have?

The set of critical points depends on exactly what you are buying. Use the table to determine which blocks of the checklist to focus on.

Contract type	What you are buying	Most important blocks	When it fits
Custom development	Code, integrations, configuration for your process	Rights to the result, acceptance, exit	The process is unique, and the solution must remain with the company
Subscription to a ready-made platform (SaaS)	Access to the service and support	Data, SLA, exit, pricing changes	A standard use case, launch speed matters
A pilot with a fixed scope	Testing a hypothesis in one process	Acceptance, success criteria, fate of the data after the pilot	The effect is not obvious, so it needs to be measured before scaling
Maintenance and development	Support, monitoring, enhancements	SLA, retraining, model changes	The solution is already running in production

If the contract is mixed — for example, a pilot followed by a subscription — review the blocks for both types and separately define what happens to the data and deliverables during the transition between stages.

What to Prepare Before You Start

Before you sit down with the checklist, gather four documents. Without them, most of the items will have nothing to be filled in with.

Process description and current baseline. How many requests, documents, or transactions per month, how long the work takes now, and what error rate is acceptable.
List of data. Which systems and documents the contractor will need, and whether they contain personal data, trade secrets, or third-party data.
Draft technical specification. A strong starting point is the template from the article “Technical Specification for an AI Agent”.
Cost of ownership. Guidance on expense categories is available in the breakdown “The Cost of Implementing AI in Business”.

Stage-by-Stage Checklist

Each section lists the customer-side owners and the “done” criterion—the condition under which the section can be considered complete.

1. Scope and Measurable Outcome

Responsible party: process owner and IT director. Done when: the outcome is described in a way that an independent person can verify it from the document without the contractor’s involvement.

☐ A specific process and the solution boundaries are defined: which requests the system handles and which it passes to a human.
☐ Integrations with company systems and the access level for each are listed: read, write, action.
☐ The current baseline for the metric is recorded (processing time, error rate, volume of manual work) so the result can be compared against it.
☐ It is specified what counts as the stage result: a prototype, a pilot for part of the user base, or production deployment.
☐ It is described which AI actions are performed only after human approval.

2. Acceptance and Quality

Responsible party: process owner and subject matter experts. Done when: the contract addendum includes a benchmark set, metric, threshold, and retesting procedure.

☐ A benchmark set of real requests with correct answers is provided before work begins and is not used for training.
☐ A metric is selected for each task: accuracy, field extraction completeness, expert score using a checklist.
☐ The acceptance threshold is specified, along with what happens if it is not met: remediation, retest, or the right to reject the stage.
☐ The acceptance procedure under Article 720 of the Russian Civil Code is described: who reviews, within what timeframe, and how any defects are recorded in the act.
☐ Testing for “forbidden” scenarios is included: off-topic questions, attempts to obtain confidential data, and provocative requests.
☐ The model version used for acceptance is recorded, and any version change requires retesting.

3. Data and Personal Data

Responsible party: personal data processing officer and legal counsel. Done when: every data flow to the contractor and into model services is documented and has a legal basis.

☐ A list of data received by the contractor has been prepared, with notes indicating personal data and trade secrets.
☐ If the contractor processes personal data, the contract includes the instruction under Article 6, Part 3 of Federal Law No. 152-FZ: list of data, actions, purposes, confidentiality obligation, and protection requirements.
☐ It is defined where the data physically goes when the model is used; for cross-border transfers, the obligation to notify Roskomnadzor before the transfer begins has been accounted for (Article 12, Part 3 of Federal Law No. 152-FZ).
☐ The ban on keeping databases containing Russian citizens’ personal data abroad when collecting such data has been taken into account (Article 18, Part 5 of Federal Law No. 152-FZ)—this also applies to logs and vector indexes.
☐ Using the customer’s data to train the contractor’s or third parties’ models is prohibited without separate written consent.
☐ Retention periods and the procedure for deleting data, logs, and copies after contract termination are specified, along with a deletion certificate.

For more on transferring data to foreign AI services, see the article “Federal Law 152-FZ and Foreign AI”.

4. Rights to the Deliverable

Responsible party: lawyer and IT director. Done when: for each project artifact, it is stated who owns the exclusive right or under what terms the customer may use it.

☐ The artifacts are listed: source code, prompts and system instructions, agent configurations, datasets, labeling, fine-tuning adapters, and test reports.
☐ For custom development, it is explicitly stated that exclusive rights transfer to the customer; under Article 1296 of the Russian Civil Code, this is the default rule, but an explicit clause removes disputes.
☐ The components that remain with the contractor (its libraries, platform) are listed separately, along with the license terms for the customer.
☐ If the rights remain with the contractor, a written license agreement is executed with territory, term, and methods of use specified (Article 1235 of the Russian Civil Code).
☐ It is recorded that datasets assembled from the customer’s data belong to the customer, even if the contractor cleaned and labeled them.

5. Third-Party Models and Services

Responsible party: IT director and information security team. Done when: all models and external services in the solution, their licenses, and the fallback plan in case of shutdown are known.

☐ The contractor discloses the list of models and external APIs used by the solution, including versions and providers.
☐ Open-source models have their licenses attached and restrictions checked: for example, the Llama 3.1 license requires separate permission from Meta for companies with an audience of more than 700 million monthly active users.
☐ It is described who signs the contract with the model provider and whose account is used: the customer’s or the contractor’s.
☐ A plan is in place for when a model is retired: providers disable older versions—at OpenAI, even fine-tuned models work only until the base model is retired.
☐ The solution is designed so the model can be replaced without rewriting the entire system, and this is checked during acceptance.

6. Cost and Operating Expenses

Responsible party: CFO and process owner. Done when: the full annual cost of ownership has been calculated under expected and peak load.

☐ One-time costs (development, integration, training) and recurring costs (tokens, GPU, hosting, support) are separated.
☐ It is specified who pays for tokens and infrastructure and at what rates; any rate change by the model provider is not passed on to the customer without notice.
☐ Spending caps and alerts as those caps are approached are included.
☐ The cost of retraining or fine-tuning when the process or data changes is described.
☐ Costs for quality monitoring and error review are included in the budget, not billed “as incurred.”

7. Security and Access

Responsible party: information security team. Done when: the AI system has separate user accounts, an activity log, and agreed access restrictions.

☐ The AI agent operates under a separate account with the minimum necessary privileges, not under an employee account.
☐ All system actions in external systems are logged, and the log is available to the customer.
☐ The contractor describes protection against command injection through documents and emails (prompt injection) and tests it during acceptance.
☐ The contractor’s access to the customer’s systems is listed and revoked when the work is completed.
☐ A deadline is set for the contractor to report any incident involving the customer’s data.

8. Support, SLA, and Changes

Who is responsible: The IT Director. Done when: it is clear who responds to an outage and a drop in response quality, and within what timeframe.

☐ Availability incidents (the system does not respond) are separated from quality incidents (the system responds incorrectly), with a response time defined for each.
☐ Regular quality checks on a benchmark set are defined after model, data, or prompt updates.
☐ The change management process is documented: who can change prompts and settings in production, and how changes are approved.
☐ It is defined how the benchmark set is supplemented with new errors found in production.

9. Project Exit

Who is responsible: The IT Director and the lawyer. Done when: based on the handoff list, another team can deploy and support the solution without the original contractor.

☐ A handoff list has been prepared: source code, prompts, configurations, datasets, benchmark set, deployment instructions, access credentials.
☐ The handoff period and the data format on contract termination are specified.
☐ A transition period of joint work with another team is provided for.
☐ Accounts with model providers and cloud providers are either set up in the customer’s name or transferred to the customer on exit.
☐ A deployment rehearsal has been completed using the documentation before final payment.

More on how to prepare a backup environment and transition is in the article "AI Service Exit Plan".

Copyable template

Copy the list into a working document or spreadsheet and check off items as you agree them with the contractor.

AI IMPLEMENTATION CONTRACT CHECKLIST
Project: ______  Contractor: ______  Contract version: ______  Date: ______

1. SCOPE (process owner, IT Director)
☐ Process and solution boundaries
☐ Integrations and access level
☐ Current baseline metric
☐ Deliverable for each stage
☐ Actions only with human confirmation

2. ACCEPTANCE (process owner, experts)
☐ Benchmark set handed over before work starts and not used for training
☐ Metric for each task
☐ Acceptance threshold and consequences if not met
☐ Acceptance procedure and recording defects in the acceptance report
☐ Review of prohibited scenarios
☐ Model version at acceptance, retest after changes

3. DATA (personnel data officer, lawyer)
☐ List of data to be transferred
☐ Instruction to process personal data under Part 3 of Article 6 of Federal Law No. 152-FZ
☐ Processing geography, notice of cross-border transfer
☐ Localization of personal data databases, including logs and indexes
☐ Prohibition on training models on customer data
☐ Retention periods and deletion certificate

4. RIGHTS (lawyer, IT Director)
☐ List of project deliverables
☐ Transfer of exclusive rights to the customer
☐ Contractor components and license to them
☐ License agreement if rights remain with the contractor
☐ Datasets created from the customer’s data belong to the customer

5. THIRD-PARTY MODELS (IT Director, information security)
☐ List of models and APIs with versions
☐ Open-source model licenses reviewed
☐ In whose name provider accounts are registered
☐ Plan for decommissioning the model
☐ Model replacement without rewriting the system

6. COSTS (Chief Financial Officer, process owner)
☐ One-time and recurring payments separated
☐ Who pays for tokens and infrastructure
☐ Spending limits and alerts
☐ Cost of retraining and fine-tuning
☐ Quality monitoring included in the budget

7. SECURITY (information security)
☐ Separate account with minimum privileges
☐ Activity logs available to the customer
☐ Protection against prompt injection and its validation
☐ Contractor access revocation
☐ Incident notification deadline

8. SUPPORT (IT Director)
☐ Response time: availability and quality
☐ Quality control after updates
☐ Change management in production
☐ Benchmark set replenishment

9. EXIT (IT Director, lawyer)
☐ Handoff list of deliverables
☐ Handoff period and format upon termination
☐ Joint work period
☐ Provider accounts in the customer’s name
☐ Deployment rehearsal before final payment

Common mistakes

Acceptance based on a demonstration. The contractor shows successful answers on its own examples, the acceptance report is signed, but the quality is lower on real requests. This is fixed with the customer’s benchmark set, handed over before work begins.
Training on the benchmark set. If the test questions were included in training or the prompt, acceptance will show inflated results. The set must be kept by the customer and provided only for testing.
"Rights to the system" without a list. The code was handed over, but the prompts, datasets, and adapters remained with the contractor — without them, the solution cannot be reproduced.
The model provider account is under the contractor’s name. When the contract is terminated, the solution stops working, and the request history remains with another company.
Token costs billed "as incurred." Without limits and forecasting, a spike in load turns into an unexpected bill.
No plan for switching models. The provider decommissions the version, and the contract does not say who will migrate the solution and repeat acceptance, or at whose expense.

How the checklist was developed

We broke the contract down into the stages of the AI solution lifecycle — from defining the task to exit — and for each stage listed the conditions that distinguish an AI project from standard custom development. We then compared the items with the Russian Civil Code rules on acceptance, custom works, and license agreements, with Federal Law No. 152-FZ requirements for delegated processing, cross-border transfer, and localization, as well as with model provider documentation. Items that are the same for any service contract were deliberately excluded so the list would remain practical.

Methodology limitations: the checklist does not account for industry-specific requirements, does not replace a lawyer’s review of a specific contract, and was not tested against our own sample of contracts. The rules are cited in the versions available as of October 19, 2026.

Frequently Asked Questions

Who owns the rights to an AI solution created under a contract?

Under Article 1296 of the Russian Civil Code, the exclusive right to a program or database created to order belongs to the customer unless the contract provides otherwise. But the solution usually includes third-party models and the contractor’s libraries — the rights to those do not transfer. That is why the contract should list the deliverables by name: code, prompts, datasets, adapters, reports.

How do you accept an AI system if it sometimes makes mistakes?

By setting a quality threshold on a benchmark set. Collect real requests with correct answers in advance, agree on the metric and minimum acceptable value, and run the test on that set. Errors below the threshold are acceptable if they are described in the contract; errors above the threshold are grounds for remediation under the procedure set out in the contract.

Is a personal data processing instruction required if the contractor only configures the model?

If the contractor has access to personal data — for example, customer correspondence for tuning or testing — that is processing by instruction, and Part 3 of Article 6 of Federal Law No. 152-FZ requires the instruction to specify the list of data, actions, and purposes. It is safer to anonymize the data in advance. Make the decision together with the person responsible for personal data.

What should you do if the contractor uses a foreign model?

Find out where requests and responses go, whether they contain personal data, and whose name the account is under. In the case of cross-border transfer of personal data, the operator must notify Roskomnadzor in advance. If the data is sensitive, discuss with the contractor using a model in a Russian cloud or on your servers.

Should a specific model be specified in the contract?

It’s better to specify the requirements and procedure, not just the model name. Models are updated and eventually retired, so the contract should use the model as of the acceptance date, include a rule for re-validation when the version changes, and require the contractor to design the solution so the model can be replaced.

Primary Sources

Regulations and documents checked on October 19, 2026:

How AIrassvet Helps Prepare an AI Project for Contracting

Most checklist items can’t be completed until the process, its current state, and the data are described. On the AIrassvet website the work areas are listed that relate to this preparation and to the project itself:

process audit and data preparation: what to automate, what data is needed, and where personal information appears in it;
MVP development, integration, and testing — with a reference dataset and an acceptance criterion that can be carried over into the contract;
deploying the LLM on the customer’s servers if the data cannot be transferred to an external service;
launch, team training, and support after going live.

The first step is to choose one process and describe its current state, data sources, constraints, and acceptance criterion: this forms the contract sections on scope and acceptance.

Discuss the Project

Bottom Line: The Contract as an Extension of the Technical Specification

An AI implementation contract protects the customer only if it explains how quality is measured, where the data goes, who owns all artifacts, and what happens if the model or contractor changes. The nine checklist sections cover exactly these differences between an AI project and a standard software development project.

Go through the template together with the process owner, CIO, lawyer, and security team before signing, not after the first dispute. Unanswered items are a list of questions for the contractor, not a formality.