An artificial intelligence contract needs clauses that older software agreements were never built to handle: who owns machine-generated outputs, what happens to proprietary data fed into prompts, how model accuracy is measured, and who pays when an algorithm produces a discriminatory or infringing result. The provisions below are the ones that separate a workable AI vendor agreement from a template that will fail under stress.
Ownership of AI-Generated Outputs
Ownership is the most misunderstood provision in these contracts, and getting it wrong can leave a company with content it cannot legally protect. The U.S. Copyright Office has stated that copyright protects only material produced by human creativity, and that when an AI system determines the expressive elements of its output, that material is not eligible for copyright registration.1Federal Register. Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence The D.C. Circuit reinforced this in 2025, holding that the Copyright Act requires all eligible works to be authored by a human being in the first instance.2U.S. Court of Appeals for the D.C. Circuit. Thaler v. Perlmutter, No. 23-5233
That has a direct drafting consequence. A clause declaring that AI outputs are “works made for hire” does not create copyright where none exists. The D.C. Circuit ruled that the human authorship requirement applies to all copyrightable work, including work made for hire.2U.S. Court of Appeals for the D.C. Circuit. Thaler v. Perlmutter, No. 23-5233 If no human contributes meaningful creative expression to the output, there is nothing to own under copyright.
Many AI-assisted works do involve enough human input to qualify. The Copyright Office allows registration when a person selects, arranges, or substantially modifies AI-generated material so the final work reflects original human authorship.1Federal Register. Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence The contract should define which party is contributing the human creative elements and who owns the resulting copyright in those elements. Work made for hire only reaches commissioned works within specific statutory categories such as contributions to collective works, compilations, translations, and instructional texts, and only when both parties sign a written agreement designating the work as made for hire.3Office of the Law Revision Counsel. 17 U.S. Code 101 – Definitions
When the output does not fit a work-for-hire category, the contract needs an express written assignment of copyright. Federal law makes a transfer of copyright ownership invalid unless it is documented in writing and signed by the rights owner.4Office of the Law Revision Counsel. 17 U.S. Code 204 – Execution of Transfers of Copyright Ownership The clause should identify when the transfer takes effect, usually upon full payment, and should carve out the developer’s pre-existing software and models from any assignment. Developers often retain a perpetual, royalty-free license to use outputs to improve the service; that license needs boundaries preventing resale of unique outputs to the customer’s competitors.
For outputs that fall outside copyright, the contract should still provide protection through trade secret treatment or contractual use restrictions, so the customer isn’t left with content anyone can copy.
Confidentiality of Inputs and Prompts
The exposure most companies overlook has nothing to do with output ownership. It is what happens the moment an employee pastes business strategy, customer data, financial projections, or a product formula into a third-party AI tool. That information may enter an environment where the vendor can access, store, or inadvertently incorporate it into training data. Once a trade secret enters a shared model, it may no longer qualify as secret.
Confidentiality provisions in an AI contract need to do three things that standard nondisclosure language usually doesn’t. They need to define confidential information to include inputs and prompts, not just documents exchanged during negotiations. They need to restrict the vendor from using confidential inputs for any purpose beyond delivering the contracted service. And they need to require technical safeguards that isolate the customer’s data from other users’ data.
Federal law provides a backstop through the Defend Trade Secrets Act, which allows civil claims for misappropriation with remedies including injunctions, actual damages and unjust enrichment, and exemplary damages up to twice the compensatory award when misappropriation is willful.5Office of the Law Revision Counsel. 18 U.S. Code 1836 – Civil Proceedings But winning that claim requires showing you took reasonable steps to keep the information secret. A contract silent on AI inputs undermines that argument.
Training Data and Model Improvement Rights
Vendors want customer inputs to improve their models. Customers want assurance that their proprietary information isn’t training a system competitors also use. The contract has to resolve that tension explicitly.
Three approaches are common. The broadest grants the vendor a license to use all input data for training, research, and service improvement. A middle ground allows the vendor to use only de-identified or aggregated data, stripped of anything traceable to the customer. The most restrictive prohibits training use entirely, sometimes called an opt-out clause. The right choice depends on how sensitive the data is and whether the customer’s competitive advantage depends on keeping it private.
When a contract permits training use, de-identification requirements need teeth. The provision should specify the technical standard for anonymization, require vendor certification of compliance, and impose consequences for failure. “Anonymized” without a definition leaves too much discretion with the vendor. Companies in healthcare, financial services, and other regulated industries face sector-specific privacy rules that may limit what can be shared regardless of contract terms.
A middle path some organizations negotiate: the vendor may use customer data only to fine-tune a private instance dedicated to that customer, not the general model. Training permissions should also be limited to the contract term so the vendor cannot continue using data after the relationship ends.
Performance Metrics for AI Systems
Service level agreements for AI need to measure things traditional software SLAs don’t. Uptime and latency still matter. The harder question is whether outputs are accurate and useful.
- Latency: time between prompt and response, typically measured in milliseconds or seconds depending on task complexity.
- Uptime: system availability, commonly targeted at 99.9%, with exclusions for scheduled maintenance.
- Accuracy: the percentage of correct outputs measured against a verified reference dataset the customer provides or the parties agree upon.
- Hallucination rate: the frequency of confidently stated but factually incorrect outputs. The NIST Generative AI Risk Profile identifies this as “confabulation” and flags it as a distinct risk category for generative AI.6National Institute of Standards and Technology. NIST AI 600-1 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Hallucination thresholds are where AI contracts differ most from conventional software agreements. Traditional software either processes a calculation correctly or it doesn’t. Generative AI can produce outputs that look authoritative and are fabricated. The contract should define an acceptable error rate, specify how errors are measured and reported, and establish consequences when the threshold is exceeded. Without that, the customer has no contractual basis to demand improvements when quality degrades.
Performance specifications work best in a separate exhibit the parties can update without renegotiating the whole agreement. AI models change frequently through updates and retraining, and a standard that made sense at signing may be outdated within months. The contract should require regular performance reports and give the customer termination rights if metrics fall below agreed thresholds for a sustained period, such as three consecutive months.
Liability Caps and Indemnification
When an AI system produces harmful, inaccurate, or infringing outputs, the contract determines who bears the financial consequences. Leverage usually favors the vendor.
Most AI vendors cap total liability at the fees paid over the preceding twelve months and disclaim liability for indirect, incidental, and consequential damages. In practice, that means the vendor won’t pay for downstream business losses caused by a bad output. Customers with significant exposure should push for higher caps or carve-outs excluding certain categories from the cap entirely, such as data breaches, willful misconduct, or intellectual property infringement.
Indemnification provisions assign responsibility for legal claims. The common structure: the vendor indemnifies the customer against claims that the underlying AI system infringes a third party’s patent, copyright, or trade secret; the customer indemnifies the vendor against claims arising from how it used the outputs, including infringement caused by the specific prompts submitted. Many major AI vendors now offer IP indemnification for outputs to encourage commercial adoption, though scope varies. Each party’s obligations should cover defense costs and any resulting settlements or judgments, with a clear process for prompt notice.
One unsettled question is whether an AI platform qualifies as a “good” under Article 2 of the Uniform Commercial Code, which would trigger implied warranties of fitness for a particular purpose.7Legal Information Institute. Uniform Commercial Code 2-315 – Implied Warranty: Fitness for Particular Purpose Courts have not resolved this for cloud-based AI services. Most vendors include broad warranty disclaimers, but those disclaimers may not hold in every jurisdiction. At minimum, the contract should address whether any warranties attach to the outputs and what remedies exist when the system fails to perform as represented.
Bias, Discrimination, and Civil Rights Compliance
When an AI system makes decisions affecting people, existing civil rights laws apply regardless of whether a human or an algorithm made the call. The CFPB has stated that creditors using complex or opaque algorithms cannot use that complexity as an excuse to avoid providing applicants with specific reasons for adverse credit decisions, as the Equal Credit Opportunity Act requires.8Consumer Financial Protection Bureau. CFPB and Federal Partners Confirm Automated Systems and Advanced Technology Not an Excuse for Lawbreaking Behavior Title VII of the Civil Rights Act holds employers liable when hiring tools disproportionately exclude candidates based on protected characteristics, even when the bias is unintentional. Employers remain legally responsible for discrimination caused by AI tools even when a third-party vendor developed the tool.
That creates a contractual problem: the customer faces the regulatory exposure, but the vendor controls the algorithm. Key provisions to bridge the gap include audit rights allowing the customer to examine the system for discriminatory patterns, compliance warranties in which the vendor represents that the system was tested for bias before deployment, and indemnification covering the customer if the vendor’s algorithm produces a discrimination claim. Without these, the customer absorbs all the legal risk for a system it cannot fully inspect.
Several states have enacted AI-specific legislation adding compliance obligations beyond federal civil rights law. These laws generally require companies deploying AI for consequential decisions to implement risk management programs, conduct annual impact assessments, notify individuals when AI influences decisions affecting them, and provide an appeal process. Some states prohibit AI systems from using proxies for protected characteristics. Companies using AI for hiring, lending, housing, or insurance decisions should ensure their contracts require vendor support for compliance with these requirements.
Regulatory Transparency and Disclosure
The NIST AI Risk Management Framework provides a voluntary structure for managing AI risk.9National Institute of Standards and Technology. AI Risk Management Framework It isn’t mandatory, but incorporating its principles into a contract gives both parties a shared vocabulary and creates documentation of good-faith compliance if regulators ask questions. The NIST Generative AI Profile identifies twelve risk categories specific to generative AI, including confabulation, data privacy leakage, harmful bias, information security vulnerabilities, and intellectual property exposure.6National Institute of Standards and Technology. NIST AI 600-1 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile A well-drafted contract should address vendor obligations for each relevant category.
On transparency, there is no standalone federal AI disclosure statute, but the FTC treats undisclosed use of AI-generated content as potentially deceptive under Section 5 of the FTC Act when it creates confusion about the origin of a product or service. Disclosures must be clear and conspicuous, not buried in fine print. Companies deploying customer-facing AI tools should include contractual requirements that the vendor’s system supports appropriate disclosure mechanisms.
International exposure raises the stakes. The EU AI Act’s transparency obligations take full effect on August 2, 2026, requiring providers to mark AI-generated synthetic content in machine-readable form and requiring deployers to disclose deepfakes and certain AI-generated content of public interest.10Artificial Intelligence Act. Article 50 – Transparency Obligations for Providers and Deployers of Certain AI Systems Non-compliance penalties reach up to €15 million or 3% of global annual turnover. If the AI system will interact with users in the EU, the contract should allocate responsibility for meeting these marking and disclosure requirements between provider and deployer.
The contract should also include a regulatory change provision requiring the vendor to update the system when new laws take effect, or at least notify the customer of developments that affect compliance status. Given how quickly AI regulation is moving, an agreement with no adaptation mechanism could become a liability within a year.
Termination, Data Return, and Fine-Tuned Weights
How a contract ends matters almost as much as how it begins. At termination, the customer needs its data back in usable form and needs assurance the vendor isn’t retaining copies or continuing to benefit from the information.
The contract should require the vendor to return all customer data in a mutually agreed format within a defined window, typically 30 to 60 days after termination. The vendor should then certify in writing that all copies have been destroyed, including backups and any data that entered training pipelines. Some contracts impose daily financial penalties for late returns. Destruction certification should cover not just raw data but any derived datasets or fine-tuned model parameters that incorporate the customer’s proprietary information.
Access to the system typically ends immediately at expiration, but abrupt cutoffs can be operationally devastating. A well-negotiated agreement includes a transition period, usually 30 to 90 days, during which the customer maintains limited access at a prorated fee while migrating to a replacement system. The contract should specify what functionality remains available and whether the vendor will cooperate in transferring workflows.
Fine-tuned model weights are a newer complication. When a customer pays to fine-tune a model on its own data, whether it can export those weights at termination depends entirely on the contract. Some vendors treat fine-tuned weights as their proprietary technology. Others allow export, but federal export control regulations now impose licensing requirements on certain AI model weights, which may limit where those weights can be transferred.11Eversheds Sutherland. New Export Controls on AI Model Weights and Advanced Computing Integrated Circuits The contract should address ownership and portability of fine-tuned parameters explicitly, along with any regulatory constraints on transfer.
The agreement should also clarify whether the customer retains rights to analytics, reports, and derived insights generated during the contract term. Losing access to historical performance data when switching vendors can set a company back significantly. Defining these rights upfront avoids a scramble during an already stressful transition.