What questions should you ask before signing an AI development contract?

Before signing an AI development contract, ask about intellectual property ownership, liability for errors, performance benchmarks, data privacy obligations, and what happens if the relationship ends. These five areas define where the real risk lies. The sections below break down each question and what a reasonable answer looks like.

Who owns the AI model and the data used to train it?

Ownership of the AI model and training data must be defined explicitly in the contract before any work begins. Without clear language, vendors can retain rights to the model, the weights, and the proprietary data you contributed, even after you have paid in full. This is one of the most consequential clauses in any AI development agreement.

There are three ownership structures that typically appear in these contracts. The first is full client ownership, where everything developed using your data belongs to you. The second is shared ownership, where the vendor retains rights to the underlying model architecture or base model while you own the fine-tuned output. The third is a licensing model, where you receive the right to use the system but never own it outright.

Each structure has practical consequences. If you license rather than own, you may face ongoing fees, restricted deployment options, or limitations on modifying the system later. If the vendor trained the model on a shared dataset that includes other clients’ data, your data may have contributed to a system that benefits your competitors.

Ask specifically: who owns the trained weights, who owns the fine-tuning data, and whether any third-party datasets were used during training. Require documentation of all data sources. If the vendor cannot answer these questions clearly, that is a significant red flag before you sign anything related to AI development.

What happens when the AI makes a mistake or causes harm?

The contract must specify who bears responsibility when the AI system produces an incorrect output that leads to a measurable business loss. Liability for AI errors is rarely assigned by default, which means that without explicit contract language, the cost of a mistake typically falls on the client.

Vendors will often include broad disclaimers that limit their liability to the fees paid under the contract. That may be acceptable for low-stakes applications but is inadequate for systems used in regulated industries like healthcare, legal, or tax, where an incorrect output can trigger compliance failures, financial penalties, or client harm.

When reviewing the liability section of an AI software contract, look for the following:

Whether the vendor accepts liability for errors caused by model defects versus errors caused by incorrect data you provided
Whether there is an indemnification clause covering third-party claims arising from the system’s output
Whether the contract distinguishes between gross negligence and standard performance variation
Whether there is a defined escalation process when errors are identified in production

For any system operating in a regulated environment, the contract should also clarify which party is responsible for maintaining audit trails and documentation if a regulator asks questions about a specific output.

How should AI performance be defined in a contract?

AI performance in a contract should be defined using specific, measurable metrics tied to the business outcome the system is meant to achieve, not vague language like “high accuracy” or “production-ready.” Without defined benchmarks, there is no objective basis for determining whether the vendor has delivered what was promised.

Performance definitions vary depending on the type of system. A document classification model might be measured on precision and recall against a labeled test set. A workflow automation system might be measured on processing speed and error rate in production. A generative system might be evaluated on output quality scores agreed upon in advance.

When hiring an AI developer, the contract should include all of the following performance elements:

Acceptance criteria: The specific conditions under which the delivered system is considered complete and acceptable
Evaluation methodology: How performance will be measured, by whom, and using what data
Baseline comparison: What the system is being compared against, whether that is the current manual process, a previous system, or an industry benchmark
Degradation thresholds: At what point a drop in performance after deployment triggers a remediation obligation

Performance clauses should also address model drift. AI systems can degrade over time as the data they encounter in production diverges from the data they were trained on. The contract should specify who is responsible for monitoring, retraining, and maintaining performance over the agreed service period.

What should the contract say about data privacy and compliance?

The contract must clearly state how your data will be stored, processed, and protected, and which party is responsible for compliance with applicable privacy regulations. This is especially important if your data includes personal information governed by laws such as GDPR, HIPAA, or CCPA.

A common oversight when reviewing an AI development contract is focusing only on the development phase. Data privacy obligations extend to training, testing, deployment, and any ongoing model maintenance. If the vendor uses your data to improve their own models or shared infrastructure, that needs to be explicitly prohibited in writing.

For organizations operating in regulated industries or handling sensitive client data, the deployment architecture matters as much as the contract language. Cloud-based systems may not satisfy compliance requirements in sectors where data must remain on-premises or within a defined geographic boundary. The contract should specify where data is processed and stored, and whether the vendor is acting as a data processor under applicable law, which carries its own obligations.

Ask the vendor to provide a data processing agreement as a separate exhibit, and ensure it aligns with the privacy obligations in your own client-facing contracts. If there is a mismatch, you may be creating liability downstream even if the AI system itself performs correctly.

How do you protect yourself if the vendor relationship ends early?

If the vendor relationship ends before completion or after deployment, the contract must give you the ability to continue operating the system independently. Without exit provisions, a terminated contract can leave you with a system you cannot maintain, modify, or migrate without the original vendor’s involvement.

Exit risk is one of the most underestimated issues when reviewing an AI software contract. Vendors may hold critical dependencies, including proprietary tooling, undocumented model components, or infrastructure that is not transferable. When the relationship ends, those dependencies become leverage.

A well-structured contract addresses exit in several ways:

Source code and model delivery: All deliverables, including model weights, training scripts, and documentation, must be transferred to you at defined milestones, not only at project close
Transition support obligations: The vendor should be required to provide a defined period of handover support if the contract ends, whether by mutual agreement or termination
Escrow arrangements: For long-term engagements, consider requiring source code escrow with a third party that releases assets to you under defined trigger conditions
No-lock-in infrastructure: The contract should prohibit the use of proprietary infrastructure that cannot be replicated or migrated without the vendor’s ongoing participation

You should also confirm that the vendor’s key personnel are not the only people who understand the system. If critical knowledge lives in one person’s head and that person leaves, your operational continuity is at risk regardless of what the contract says.

How ArdentCode approaches AI development contracts

The questions above reflect the kind of operational and legal risk that surfaces when AI development is treated as a procurement exercise rather than an engineering partnership. At ArdentCode, we approach these engagements differently. We take on architecture responsibility and project leadership, which means we are accountable for the decisions that determine how these contract clauses play out in practice.

When we work with clients on AI development, we structure the engagement to address these risks from the start:

Clients retain full ownership of all models, weights, training data, and code produced during the engagement
Performance benchmarks are defined before development begins, not after delivery
Data privacy and deployment architecture are addressed at the design stage, including on-premise options for regulated industries
Documentation and handover materials are produced throughout the project, not compressed into a final delivery
We work across sectors, including legal, tax, healthcare, and education, where compliance and data sensitivity are not edge cases but operating conditions

If you are evaluating an AI development engagement and want to understand what a technically accountable partnership looks like, get in touch with ArdentCode to discuss your specific situation. You can also review our past work to see how we have handled similar challenges, or explore our solutions to understand where we focus.