An AI use clause defines how a vendor may use artificial intelligence when providing contracted products or services. It can address the systems involved, permitted data use, model training, human oversight, output rights, security, compliance, incidents, audit evidence, and responsibility for failures.
The clause should reflect the actual service. A generic prohibition on "AI" may be impractical, while a broad authorization may permit uses the customer never evaluated.
Begin With a Clear Description of the AI Use
The contract should identify where AI is used and what it does. Relevant activities may include document analysis, drafting, classification, decision support, recommendations, automation, monitoring, customer support, or autonomous actions.
Ask whether AI is part of the contracted service, an optional feature, a subcontracted component, or an internal vendor tool used to deliver the service. The answer affects disclosure, data access, performance commitments, and responsibility.
Avoid definitions so broad that ordinary calculators and security filters trigger unnecessary obligations. Also avoid definitions so narrow that a vendor can introduce a new model or agent without review.
Define Permitted and Prohibited Data Use
The clause should state what customer data the AI system may process and for which purposes.
Important questions include:
• May the vendor use customer data only to provide the service?
• May prompts, documents, outputs, metadata, or feedback be retained?
• May any of that information be used to train or improve a model?
• Does the restriction apply to the vendor's model providers and subprocessors?
• Can the vendor create aggregated or de-identified data, and under what standard?
• What happens to data after termination?
If training is prohibited, define the restriction across fine-tuning, reinforcement, evaluation, retrieval indexes, embeddings, and other improvement activities where appropriate. The wording should match the technical architecture rather than rely on one label.
Address Confidential and Privileged Information
AI processing does not remove existing confidentiality duties. The agreement should make clear that using an AI system is not an authorized disclosure beyond the permitted service chain.
For legal information, consider privilege, work product, client restrictions, protective orders, ethical walls, and matter-level access. The vendor should not use confidential material to answer another customer's query or expose it through logs, testing, support, or product analytics.
Access rules should apply to generated summaries and extracted data, not only the original files.
Control Models, Providers, and Material Changes
A service may rely on third-party model providers or switch models over time. The contract should identify which changes require notice or consent.
Material changes may include a new model provider, a different processing location, expanded data retention, new training rights, reduced human review, autonomous actions, or a significant change in the system's intended use.
Not every software update needs approval. Focus the change mechanism on developments that alter risk, data handling, compliance, or the agreed service.
Set Human Oversight Requirements
The contract should identify which decisions require human review and who provides it.
For lower-risk functions, the customer may review AI output before use. For higher-risk functions, the vendor may need trained personnel to monitor performance, investigate anomalies, and prevent the system from acting without approval.
State whether the AI output is advisory, whether it may trigger an external action, and what happens when confidence is low or required information is missing.
The NIST Generative AI Profile offers a useful framework for considering governance, measurement, and management of generative AI risks. Contract terms should translate relevant controls into operational obligations.
Define Performance and Verification
Avoid a promise that the AI will always be accurate. That is unlikely to be meaningful or enforceable in practice. Define measurable performance relevant to the service.
Possible terms include response times, service availability, supported document types, required source citations, escalation rates, quality thresholds, testing procedures, correction obligations, and limits on unsupported output.
For legal, financial, medical, employment, or other consequential uses, specify that the system must preserve enough source information for the customer's reviewer to verify material conclusions.
Allocate Responsibility for Outputs
The contract should explain which party decides whether an output is suitable for use. A vendor may provide analysis, while the customer remains responsible for the final legal or business decision. That allocation should not erase the vendor's responsibility for security failures, unauthorized data use, misrepresentation, or breach of contractual controls.
Review warranties, disclaimers, indemnities, liability caps, and exclusions together. A broad AI disclaimer can undermine a specific service commitment elsewhere in the agreement.
Clarify Intellectual Property Rights
Address rights in customer inputs, configurations, prompts, vendor materials, fine-tuned components, retrieved content, and outputs.
The contract should also address third-party claims. Relevant questions include whether the vendor has rights to provide the system, what happens if an output allegedly infringes another party's rights, and whether the vendor will defend or indemnify defined claims.
Do not assume that an ownership clause resolves whether an output receives copyright protection. Ownership between the parties and protection under applicable law are different questions.
Add Security and Access Controls
The AI feature should fall within the agreement's security program. Relevant controls may include encryption, authentication, role-based access, tenant separation, secure development, vulnerability management, logging, deletion, backups, and incident response.
If the system uses retrieval or agents, confirm that it cannot bypass source-system permissions. An agent should not obtain broader contract or matter access than the user directing it.
Security exhibits and data processing agreements should be updated when the AI architecture changes the actual processing.
Define AI Incident Notification
Traditional security-incident language may not cover every material AI failure. Consider defining events such as unauthorized model training, confidential output leakage, harmful autonomous action, systematic hallucination affecting deliverables, model compromise, or loss of required human control.
The clause should address notice timing, content, investigation, containment, correction, evidence preservation, customer cooperation, and prevention of recurrence.
Avoid requiring notice for every minor incorrect output. Focus on events with meaningful legal, security, operational, or customer impact.
Require Records and Audit Evidence
The customer may need evidence that the vendor followed the agreed controls. Depending on risk, this may include system documentation, model and subprocessor lists, testing summaries, access logs, change records, incident reports, audit reports, and source-linked output records.
Audit rights should be proportionate. Many customers can rely on independent assessments and targeted information rights, with expanded access after a material incident or credible compliance concern.
Plan for Suspension, Exit, and Data Return
The customer should be able to disable an AI feature without necessarily losing the underlying service when feasible. The contract should address what happens if a model provider becomes unavailable, a regulator restricts a use, or the system fails required controls.
At termination, define data return, deletion, transition assistance, continued access to records, and treatment of models or indexes influenced by customer data.
Exit planning is particularly important when the AI feature becomes embedded in contract review, compliance, customer communication, or another recurring workflow.
Align the Clause With Applicable Law
AI obligations may arise from privacy, consumer protection, employment, intellectual property, sector-specific, and emerging AI laws. The contract should allocate operational tasks without implying that private agreement can eliminate statutory responsibility.
For services affected by the EU AI Act, the parties may need to allocate information, documentation, monitoring, human oversight, and cooperation duties according to their actual roles. The official regulation is available through EUR-Lex.
Use jurisdiction-specific counsel when the system supports consequential decisions or operates across several regulatory regimes.
How Alloomi Helps Review AI Contract Terms
Alloomi AI can help legal professionals review vendor agreements, compare AI-related language, identify missing provisions, and connect findings to the relevant contract text for human analysis.
The tool does not decide the appropriate allocation for a particular transaction. The reviewer should consider the system's actual use, data, users, bargaining position, applicable law, and potential consequences. For the broader process, see How to Review a Contract.
Conclusion
An effective AI use clause translates a technical workflow into enforceable responsibilities. It should identify the AI use, limit data processing, address training and providers, require appropriate oversight, preserve source evidence, allocate output and IP risk, cover incidents, and support an orderly exit.
The clause should not be copied from a generic checklist without understanding the product. Start with the actual architecture and decisions, then draft obligations proportionate to the legal and operational risk.
Frequently Asked Questions
1. Does every vendor contract need an AI use clause?
No. The need and level of detail depend on whether AI is used, what data it processes, what actions it supports, and the consequences of error. Some agreements may address the issues through existing security, data, IP, and service provisions.
2. Should a contract prohibit all AI training on customer data?
Many customers choose that position, especially for confidential or regulated data. The appropriate term depends on the service and negotiation, but any permission should be specific, informed, and consistent with downstream providers.
3. Is an AI disclaimer enough to protect the vendor?
Not necessarily. Disclaimer enforceability and effect depend on applicable law and the rest of the agreement. It also does not replace accurate representations, security duties, or compliance obligations.
