Artificial intelligence is no longer an experimental add-on to ordinary business operations. It is increasingly embedded in document review, customer service, marketing, product development, software engineering, compliance, finance, human resources, and legal workflows. As a result, the contract between a company and its AI vendor has become one of the most important governance documents in the organization. A standard software-as-a-service agreement may address uptime, subscription fees, user accounts, and ordinary data security, but those provisions rarely answer the most important AI-specific questions. Who may use the customer’s data to train or improve the model? What happens to confidential information entered into prompts? Who owns the output? Who is responsible if the model produces infringing, false, biased, unsafe, or legally defective material? When must a human review the output before it is used? These questions should not be left to assumptions, marketing materials, or informal assurances. They should be addressed directly in the written contract.
The purpose of AI vendor contract clauses is not to eliminate every risk. No contract can make an AI system perfect, prevent every hallucination, or guarantee that every output will be legally safe in every context. The purpose is to allocate responsibility, create operational safeguards, preserve rights, and make the customer’s expectations enforceable. A well-drafted agreement converts broad AI governance principles into practical obligations that the vendor and customer can actually follow. NIST’s generative AI risk guidance emphasizes that organizations should identify and manage risks throughout the AI lifecycle, including risks arising from data, model behavior, misuse, measurement, monitoring, and governance. ¹ In contract terms, that means the agreement should not merely describe the product. It should describe the permitted data uses, confidentiality rules, ownership treatment, review obligations, warranties, indemnities, audit rights, and remedies that will apply when the AI system is deployed in the real world.
Training data clauses deserve particular attention because they determine whether the customer’s inputs, prompts, uploaded files, feedback, usage patterns, or outputs can become part of the vendor’s model-improvement pipeline. Many customers assume that because they are paying for an enterprise product, their data will not be used to train the vendor’s general model. That assumption may be correct for some vendors and some service tiers, but it should never remain unstated. The contract should clearly define “customer data” to include not only files and database records supplied by the customer, but also prompts, queries, embeddings, fine-tuning data, retrieval-augmented generation materials, user feedback, generated outputs, metadata, logs, and any other information derived from the customer’s use of the system. Without a broad definition, a vendor may argue that certain operational data, diagnostic information, or user interactions fall outside the customer’s control.
A strong training data clause should also distinguish between different kinds of use. A vendor may need to process customer data to provide the service, secure the system, troubleshoot errors, detect abuse, or comply with law. Those operational uses are different from using the data to train, fine-tune, evaluate, benchmark, or improve models for the benefit of the vendor or other customers. The contract should say that customer data may be used only to provide the contracted services unless the customer gives express written permission for broader use. If the customer is willing to permit model improvement, the agreement should specify whether the permission applies to all data or only to selected datasets, whether data must be de-identified, whether de-identification must meet a defined standard, whether the customer can revoke permission, and whether the vendor may use the improved model for other customers.
The customer should also require transparency about the vendor’s own training data practices. The vendor may not be willing or able to disclose every dataset used to build a foundation model, but it can still provide meaningful commitments. For example, the vendor can represent that it has implemented procedures to assess the legality, provenance, licensing status, and quality of training datasets. It can agree to maintain records sufficient to support its warranties and indemnity obligations. It can disclose whether customer data will be commingled with third-party data, whether subcontractors or model providers will receive customer data, and whether any data will be transferred across borders. The EU Artificial Intelligence Act reflects the growing regulatory importance of data governance, including attention to training, validation, and testing data practices for certain AI systems.⁴ Even where the Act does not directly govern a particular transaction, its emphasis on data governance signals a broader expectation that AI deployers and providers should understand how data-related risks are being controlled.
Confidentiality clauses also need to be modernized for AI. Traditional confidentiality provisions often prohibit disclosure of confidential information to third parties and require reasonable safeguards. Those provisions remain important, but AI systems create additional risk because confidential information may be copied into prompts, stored in logs, reviewed by vendor personnel, transmitted to model providers, used for monitoring, or retained in ways the customer does not expect. The FTC has warned AI companies that they must honor privacy and confidentiality commitments, and that misrepresentations or material omissions about data use can create enforcement risk. ² For customers, the practical lesson is that confidentiality should not depend on the vendor’s public-facing claims. The contract should state exactly what the vendor may do with confidential information and exactly what it may not do.
A well-drafted confidentiality clause should provide that all customer data, prompts, uploads, outputs, business information, personal information, trade secrets, privileged materials, and usage information are confidential information of the customer. It should prohibit the vendor from using that information for any purpose other than providing the services. It should also prohibit disclosure to any third party except approved subcontractors who are bound by written obligations at least as protective as the contract. If the vendor uses a third-party model provider, hosting provider, analytics provider, human review team, or support contractor, the customer should know who those parties are, where they are located, what data they receive, and what obligations apply to them. A confidentiality clause is incomplete if the vendor can route sensitive information through an undisclosed AI supply chain without the customer’s approval.
Retention and deletion provisions should be equally specific. AI vendors often retain logs for security, abuse monitoring, debugging, quality assurance, or legal compliance. Some retention may be reasonable, but the contract should identify the categories of retained data, the retention period, the storage location, the access controls, and the deletion process. Customers should avoid vague language stating that data will be retained “as needed” or “in accordance with vendor policy” unless the policy is attached, fixed, and contractually enforceable. If the customer handles regulated information, privileged communications, trade secrets, health information, financial information, children’s information, export-controlled data, or sensitive employee data, the agreement should require stricter controls and may need to prohibit certain categories of data from being entered into the system at all.
Confidentiality clauses should also address privilege and professional obligations. For lawyers and law firms, the use of generative AI raises duties of competence, confidentiality, communication, supervision, and independent professional judgment. ABA Formal Opinion 512 states that lawyers using generative AI tools must consider their ethical obligations, including protecting client information and supervising the use of such tools.⁵ That guidance has contract implications. A law firm using an AI vendor should not rely solely on general confidentiality language. It should require terms that support the firm’s duties to its clients, including restrictions on human review of prompts by vendor personnel, limits on data retention, restrictions on training use, and adequate assurances regarding security and subcontractors. Other professional service providers face similar concerns, even if their duties arise from different statutes, regulations, fiduciary obligations, or client contracts.
Output ownership is another area where ordinary software contracts may not be enough. Businesses often assume that if they pay for an AI tool, they own whatever the tool produces. The contract may say that the customer owns outputs, but that statement does not necessarily answer the harder legal questions. Ownership, as between vendor and customer, is a matter of contract. Copyright protection against the world is a matter of law. The U.S. Copyright Office has explained that copyrightability of works involving generative AI depends on human authorship, and that material generated by AI without sufficient human creative contribution may not be protected by copyright. ³ Therefore, an AI vendor contract should not simply promise that the customer “owns all output” without explaining what that means and what it does not mean.
A practical output ownership clause should first provide that, as between the vendor and the customer, the customer owns all rights the vendor may have in outputs generated from the customer’s use of the service. The vendor should assign to the customer any vendor rights in those outputs, waive any conflicting claims to the extent permitted by law, and agree not to use customer-specific outputs for other customers except as expressly permitted. The clause should also state that the vendor retains ownership of its preexisting technology, models, algorithms, software, documentation, and general know-how. This distinction matters because the customer usually needs ownership or exclusive control over its business outputs, while the vendor needs to preserve ownership of the underlying AI system.
The contract should then address the limits of output exclusivity. Generative AI systems may produce similar or identical outputs for different users, especially when users ask common questions or request generic language, code, images, summaries, or business templates. A vendor may resist promising that every output will be unique. The agreement should therefore state whether the vendor guarantees uniqueness, disclaims uniqueness, or offers only a limited commitment. For many business uses, the customer may accept that nonconfidential generic outputs could resemble outputs generated for others. For sensitive uses, such as branding, product design, software, advertising campaigns, legal work, or strategic materials, the customer may require stronger protections, including plagiarism checks, originality representations, restricted reuse, or indemnity for third-party claims.
The customer should also consider whether outputs may include third-party material. AI systems can generate text, images, code, or other content that resembles existing works, includes open-source code, reproduces protected expression, or reflects licensed datasets. The vendor should represent that it has taken reasonable measures to reduce the risk that outputs infringe third-party rights, but customers should be cautious about absolute guarantees. A more balanced clause may require the vendor to provide infringement indemnity for covered outputs, subject to conditions such as using the system as intended, not modifying outputs in a way that creates the claim, following required filters, and not using outputs after receiving notice of a problem. If the AI tool generates software code, the contract should specifically address open-source contamination, license compliance, attribution, copyleft risk, and the customer’s right to scan outputs before use.
Output ownership should also be connected to human authorship and review. Because copyright protection may depend on the extent of human creative contribution, businesses should develop workflows that document human involvement in important AI-assisted works. This may include recording who selected, arranged, edited, revised, approved, or materially transformed the AI-generated material. The contract can support this process by requiring the vendor to provide output logs, version history, prompt records, or other documentation that allows the customer to show how a final work was created. The contract should also avoid overpromising that every AI-assisted output will be copyrightable. A more accurate clause will assign whatever rights the vendor has, preserve the customer’s rights in its inputs and human-created modifications, and acknowledge that legal protection for AI-assisted works may depend on applicable law and the facts of human contribution.
Human review clauses are essential because AI systems can produce fluent but incorrect results. The risk is not merely that an output will be awkward or incomplete. AI tools can fabricate citations, misstate law, misclassify records, generate biased recommendations, overlook important context, produce unsafe instructions, or create content that violates company policy. NIST’s generative AI profile treats testing, evaluation, validation, monitoring, and governance as central features of AI risk management. ¹ A contract should therefore make clear when AI outputs are final deliverables and when they are only draft recommendations requiring human judgment. The more consequential the use case, the more explicit the human review obligation should be.
Human review provisions should define the roles of the vendor and the customer. Vendors often state that customers are responsible for reviewing all outputs before use. Customers may accept some responsibility, but they should not allow the vendor to shift every risk through a blanket disclaimer. If the vendor markets the tool for legal, medical, financial, employment, safety, compliance, or other high-stakes uses, the vendor should have obligations to design the system for appropriate oversight, provide documentation, disclose known limitations, maintain testing procedures, and warn against uses for which the system is not suitable. The customer, in turn, should agree to implement reasonable review procedures, train users, restrict unauthorized use cases, and avoid relying on outputs as professional advice unless qualified personnel have reviewed them.
A strong human review clause should also describe the standard of review. A vague requirement that a human “review” output may not be enough. For low-risk drafting, review may mean proofreading and confirming business accuracy. For legal filings, it may mean verifying every case citation, statute, quotation, factual assertion, and procedural statement. For employment decisions, it may mean assessing whether the recommendation is job-related, nondiscriminatory, explainable, and consistent with applicable law. For medical, financial, or safety-related use, it may mean review by licensed or specifically qualified professionals. The contract should reflect the actual risk of the use case, not a one-size-fits-all approval box.
The agreement should also provide for documentation of human review. If a dispute arises, the parties may need to show who reviewed the output, what information was available, what changes were made, and why the output was approved. For important workflows, the contract may require audit logs, approval records, version histories, escalation procedures, and retention of prompts and outputs for a defined period. This documentation helps the customer prove that it did not blindly rely on AI. It also helps identify whether an error came from the model, the vendor’s configuration, the customer’s data, user misuse, or inadequate review. In regulated settings, documentation may be as important as the review itself.
Human review clauses should also address the vendor’s duty to notify the customer of known defects, limitations, and material changes. AI systems are not static. Models may be updated, safety filters may change, retrieval sources may be modified, and performance may improve or decline for particular tasks. A contract should require notice of material changes that could affect accuracy, security, confidentiality, compliance, explainability, or output behavior. The customer should have the right to test material changes before they are deployed to production, especially if the AI system supports critical operations. Without a change-management clause, the customer may find that the system it approved is not the same system operating six months later.
Indemnity is often the most heavily negotiated AI contract provision because it determines who pays when something goes wrong. In a traditional software agreement, indemnity often focuses on claims that the software infringes third-party intellectual property rights. AI requires a broader conversation. The customer may want indemnity for claims arising from training data, output infringement, confidentiality breaches, privacy violations, data security incidents, regulatory violations, biased or discriminatory outputs, harmful content, product liability, and vendor misconduct. The vendor may seek to limit indemnity to third-party intellectual property claims and exclude responsibility for the customer’s prompts, data, modifications, use cases, or failure to review outputs. Both positions are understandable, but the final contract should allocate risk based on control.
Control is the key principle in AI indemnity. The vendor is usually in the best position to control the model architecture, training process, safety systems, system documentation, security controls, subcontractor relationships, and product claims. The customer is usually in the best position to control its own data, prompts, user instructions, deployment context, human review, and final use of outputs. An effective indemnity clause should reflect that division. The vendor should indemnify the customer for claims caused by the vendor’s technology, data practices, infringement, confidentiality breach, security failure, violation of law, or failure to meet contractual obligations. The customer may indemnify the vendor for claims caused by the customer’s unlawful data, unauthorized use, prohibited prompts, misuse of the system, or use of outputs after ignoring required warnings.
Output infringement indemnity deserves special care. Some vendors now offer limited indemnity for claims that AI-generated outputs infringe third-party copyrights, but the scope varies significantly. The contract should define which outputs are covered, which claims are covered, and which conditions must be satisfied. For example, the indemnity may apply only to paid enterprise use, only when built-in safety features are enabled, only when the customer has not intentionally prompted the system to imitate a third-party work, and only when the customer has not materially modified the output. The customer should review these limitations carefully. A narrow indemnity may sound reassuring in sales discussions but provide little protection in the situations the customer actually cares about.
Training data indemnity is equally important but often harder to obtain. If a model was trained on data that allegedly infringes copyrights, violates database rights, misappropriates trade secrets, or breaches privacy laws, the customer may be named in a claim simply because it used the model or commercialized outputs. The vendor may argue that training-related claims are too broad or uncertain to indemnify. The customer may respond that it has no ability to audit the vendor’s training corpus and therefore needs protection from risks created upstream. A negotiated compromise may include vendor representations about lawful data practices, a duty to defend claims alleging that the vendor’s model was unlawfully trained, and a right to terminate or suspend use if training data litigation creates material risk.
Confidentiality and privacy indemnities should not be overlooked. If the vendor uses customer data to train a model contrary to the contract, discloses prompts to unauthorized third parties, fails to delete data, or suffers a breach, the customer may face regulatory investigations, client claims, contractual disputes, reputational harm, and remediation costs. The FTC’s guidance underscores the importance of truthful data-use commitments in the AI marketplace. ² Contractually, the customer should require indemnity for losses arising from the vendor’s breach of confidentiality, violation of privacy obligations, unauthorized data use, or failure to comply with data protection terms. The agreement should also specify whether indemnified losses include attorneys’ fees, regulatory fines where legally permissible, notification costs, credit monitoring, forensic investigation, and costs of mitigation.
Indemnity should be coordinated with limitations of liability. A vendor may agree to indemnify the customer but then cap all liability at a small amount, such as fees paid in the prior twelve months. That may be inadequate for AI risks involving confidential data, intellectual property, regulatory exposure, or mission-critical operations. The customer should consider higher caps or uncapped liability for confidentiality breaches, data security incidents, privacy violations, intellectual property indemnity, willful misconduct, gross negligence, and unauthorized training use. The contract should also clarify whether defense costs erode the cap, whether equitable relief is available, and whether exclusions of consequential damages apply to indemnified claims. Otherwise, a carefully negotiated indemnity may be undermined by a general limitation clause.
Insurance can support but not replace indemnity. AI vendors should maintain appropriate insurance coverage, which may include technology errors and omissions, cyber liability, media liability, intellectual property coverage, and commercial general liability depending on the product and use case. The contract should require evidence of coverage, minimum limits, notice of cancellation, and coverage for subcontractors where appropriate. However, insurance policies may contain exclusions for intellectual property, professional services, intentional misconduct, biometric data, regulatory fines, or emerging AI risks. The customer should not assume that an insurance certificate guarantees recovery. Indemnity, liability caps, insurance, and operational safeguards should be reviewed together.
AI vendor contracts should also include audit, reporting, and cooperation provisions that make the major clauses enforceable. A promise not to use customer data for training is more meaningful if the customer has the right to request documentation, certifications, security reports, or third-party audit results. A confidentiality clause is stronger if the vendor must report unauthorized access promptly and cooperate in investigation and remediation. An ownership clause is more useful if the customer can obtain logs and records needed to document human contribution. A human review clause is more effective if the system supports approval workflows and audit trails. An indemnity clause is more valuable if the vendor must cooperate in defense, preserve evidence, and provide technical information relevant to the claim.
The contract should also address acceptable use, prohibited use, and customer governance. Vendors often include acceptable use policies to prevent unlawful or harmful use of AI systems. Customers should review those policies carefully because they may restrict intended use cases or allow the vendor to suspend service. At the same time, customers should create their own internal AI use policies. Employees should know what information may be entered into the system, what outputs require review, what uses are prohibited, who may approve high-risk deployments, and when legal, compliance, security, or procurement teams must be involved. Contract clauses work best when they are matched by internal procedures.
Negotiating AI vendor clauses requires a practical understanding of leverage. Large foundation model providers may resist custom terms, while smaller vendors may be more flexible but less financially able to support broad indemnities. Customers should prioritize the provisions that matter most for the specific use case. A low-risk internal brainstorming tool may require strict confidentiality and no-training commitments but not extensive output indemnity. A customer-facing chatbot may require performance monitoring, escalation, consumer protection safeguards, and strong privacy terms. A legal, financial, medical, or employment-related tool may require human review, auditability, explainability, regulatory cooperation, and heightened liability protection. The contract should be risk-based rather than copied from a generic template.
Customers should also avoid being distracted by the label “AI.” The legal analysis should begin with the business function. If the AI tool processes personal information, data protection terms are needed. If it creates marketing content, advertising, copyright, trademark, and publicity rights matter. If it generates software, open-source and code-security provisions matter. If it supports decisions about people, bias, discrimination, explainability, and human appeal rights may matter. If it handles trade secrets or privileged materials, confidentiality and access controls become central. If it automates regulated activity, compliance obligations and audit rights become critical. AI does not replace traditional contract review; it adds a new layer to it.
The best AI vendor contracts are specific, operational, and honest about uncertainty. They do not pretend that AI outputs are always correct, always original, always confidential, or always copyrightable. They explain who controls the data, how the system may learn, what information is protected, what rights are assigned, when people must review outputs, and who bears the cost of defined failures. They also recognize that AI law and technology are evolving. The U.S. Copyright Office’s treatment of AI-generated material, the FTC’s attention to data-use promises, the EU AI Act’s governance framework, NIST’s risk management guidance, and professional ethics opinions such as ABA Formal Opinion 512 all point in the same direction: organizations should not rely on vague assurances when deploying AI. ² ³ ⁴ ⁵ They should build governance into the contract.
For companies adopting AI tools, the contracting process is an opportunity to ask disciplined questions before risk becomes a dispute. What data will the vendor receive? Can the vendor use it to train models? Who can see it? How long is it retained? What happens if it is deleted? Who owns outputs as between the parties? Are outputs unique? Are they copyrightable? What human review is required? What claims will the vendor defend? What claims are excluded? What liability cap applies? What happens when the model changes? These questions may seem detailed, but they are the practical foundation of responsible AI procurement.
AI vendor agreements should be reviewed not only by procurement teams but also by legal, information security, privacy, compliance, business, and technical stakeholders. The legal team can identify contractual risk. The security team can evaluate controls and data flows. The privacy team can assess personal information and regulatory obligations. The business team can explain the intended use case. The technical team can test limitations, integrations, and auditability. When these perspectives are combined, the contract becomes more than a legal form. It becomes a governance tool that helps the organization use AI productively while preserving accountability.
In the end, AI vendor contract clauses should be drafted with the same realism that responsible AI deployment requires. AI systems can increase speed, reduce cost, improve access to information, and help professionals work more efficiently. They can also create errors at scale, expose sensitive information, blur ownership rights, and shift risk to customers that did not understand the fine print. Training data, confidentiality, output ownership, human review, and indemnity are not secondary provisions. They are the core terms that determine whether the customer can trust the AI system as a business tool. A company that negotiates those clauses carefully is not slowing innovation. It is creating the legal and operational foundation that allows innovation to proceed with confidence.
Contact Tishkoff
Tishkoff PLC specializes in business law and litigation. For inquiries, contact us at www.tish.law/contact/. & check out Tishkoff PLC’s Website (www.Tish.Law/), eBooks (www.Tish.Law/e-books), Blogs (www.Tish.Law/blog) and References (www.Tish.Law/resources).
References:
1- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
2- Federal Trade Commission, AI Companies: Uphold Your Privacy and Confidentiality Commitments, January 2024. https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/01/ai-companies-uphold-your-privacy-confidentiality-commitments
3- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, January 2025. https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
4- Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024, Artificial Intelligence Act, Official Journal of the European Union, July 12, 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
5- American Bar Association Standing Committee on Ethics and Professional Responsibility, Formal Opinion 512, Generative Artificial Intelligence Tools, July 29, 2024. https://www.americanbar.org/news/abanews/aba-news-archives/2024/07/aba-issues-first-ethics-guidance-ai-tools/