AI/ML Legal Risk (Vendor & User)
AI/ML Legal Risk (Vendor & User)
In 2026, AI enterprise contracting has shifted from "experimental" to "high-stakes risk allocation." Startups must approach contracts as a legal moat, balancing aggressive innovation with institutional-grade compliance. Here are the top concerns we talk about with our startup clients:
Data and IP Governance: Warranting training data provenance is now a baseline requirement to prove your models aren't "toxic" or "copyright-contaminated" to satisfy the EU AI Act. Simultaneously, customer data use limits must be airtight—explicitly guaranteeing that client data will not be commingled or used to train global models without an opt-in private instance. Regarding output IP ownership, our startups use "contractual assignment" language to transfer rights to the buyer, while reserving a perpetual license to the underlying architectural patterns and prompts.
Liability and Workflow Security: To manage hallucination liability, contracts must include "Non-Determinism Disclaimers" and mandate a "Human-in-the-Loop" (HITL) review for consequential outputs, shifting the burden of accuracy back to the user. Internally, managing inbound AI tools in your dev workflow is critical; you must warrant to customers that AI-generated code snippets (e.g., from Copilot) haven't introduced "copyleft" viral licenses into your proprietary stack. By codifying these AI-specific reps, you transform legal overhead into a competitive advantage during enterprise procurement.
DPA: Most of our clients don't just sign a “standard” SaaS DPA. As most of the clients here are currently AI enterprise SaaS/PaaS in 2026, most sign an AI-Specific Data Processing Addendum that defines exactly how model weights are treated during data deletion requests ("The Right to be Forgotten from the Model").
***
Transcript:
Lindsey S. Mignano: Hi everyone, Lindsey Mignano here of Mignano Law Group. I've got Phil here again with me today. He's our AI guy at the firm. We're talking about contracts with AI companies, especially because most of our clients they are AI companies and they're entering into contracts with vendors to either sell AI or buy AI. And that is an important topic of conversation because These contracts used to be considered an afterthought and now it's kind of a moat. So Phil, if you're advising one of our startups, whether they're buying or selling AI in this instance, what are your top three things to look out for?
Phil Omorogbe: The first one is who owns the AI output. And the law is genuinely unsettled because purely AI generated material may not be copyrightable at all. So we don't rely on copyright. We assign by contract. The vendor assigns the outputs to the customer, but reserves a license back to the underlying models, prompts, and the architecture. So with AI output, you don't inherit ownership through copyright law. You build it into the contract. You assign the output, you reserve the engine.
Number two issue, I think would be customer data use. This is a very, very negotiated clause that I see in AI contracts. The buyer wants it airtight. will not co-mingle our data with anyone else's. You will not use it to train your global models unless you explicitly opt in. The clean version is a private instance with a no retention guarantee. If you can offer that off the shelf, you shorten every enterprise sales cycle you have.
The third one is just about managing hallucinations because obviously hallucinations come with liability and your contract needs a non-determinism disclaimer here. So in plain language, you want to say that the system can be wrong and isn't guaranteeing accuracy. You want to build in that buffer for yourself against hallucinations and you want to mandate a human in the loop for any consequential output. So this shifts the accuracy burden to where a human can actually catch the error. so that you're not responsible if there's, you know, hallucinations that occur from using your AI product. So one caution though is this disclaimer can't be a blank check. It shouldn't excuse gross negligence, bad faith, or your IP indemnity because a sophisticated buyer will push back here if it tries to do that.
Lindsey S. Mignano: Aside from those three things, anything else that we should know about? What about DPAs?
Phil Omorogbe: You know, most of my clients no longer sign a standard DPA. They sign an AI specific one because the old privacy rules assumed data sits in a database you can delete from. But what happens when a customer's data is already baked into your model weights, right? Like this, you cannot remove that data anymore. So the old question was, can you delete my data? I think the question in 2026 is, can you make the model forget it learned from me? And your contract, you it has to have a better answer. So you need to get these reps right and they stop being legal overhead. They become the reason the enterprise customer picks you over a competitor who can't answer the questions.
AI Contracts Are Becoming Core Commercial Documents
If your company buys, builds, or sells AI-enabled products, the AI provisions in the contract can matter as much as the price.
Traditional SaaS agreements often assumed that customer data stayed within the service, outputs could be treated like ordinary software deliverables, and system behavior was relatively predictable.
AI systems complicate each assumption.
1. Customer Data Use and Model Training
The first question should be: what can the vendor do with customer data?
The contract should clearly address whether prompts, inputs, outputs, uploaded documents, telemetry, and other customer data may be used to train or improve models; whether use is optional or automatic; whether data is retained; and what happens after termination.
If the customer prohibits training on its data, the contract should make the restriction operational rather than relying on a marketing statement.
2. Output Ownership Is Not the Same as Copyright
Customers often want the vendor to say, “You own the output.”
That is useful, but it is not the whole legal analysis. A vendor can contractually allocate whatever rights it has in an output, but copyright protection for purely AI-generated material can depend on the nature and extent of human authorship.
The U.S. Copyright Office has emphasized that human authorship remains the key issue. Human selection, arrangement, modification, or other sufficiently creative contributions can affect the copyright analysis.
The contract should therefore address both contractual rights in outputs and the possibility that some output may not receive copyright protection.
3. Third-Party and Training-Data Risk
AI contracts should address the provider's representations about the sources and use of training data and other third-party material.
For general-purpose AI models, the EU AI Act includes copyright-related compliance and training-data transparency requirements for providers. Those rules make provenance, compliance representations, and allocation of third-party IP risk increasingly important in enterprise contracting.
Do not turn this into an absolute warranty that every output is free of third-party claims. Instead, define the provider's representations, exclusions, indemnities, and remediation obligations.
4. Indemnification
AI products can create IP, privacy, security, and regulatory risks that traditional SaaS indemnities may not address.
Review whether the vendor provides IP infringement indemnification for AI outputs and, if so, what exclusions apply. Also consider whether the indemnity is limited by use restrictions, modifications, combinations with third-party materials, customer-provided content, or failure to follow provider instructions.
5. Accuracy and Human Review
AI systems can generate incorrect, incomplete, or inconsistent outputs.
The contract should allocate responsibility for reviewing outputs and define prohibited or high-risk uses where appropriate. A human-review requirement may be appropriate for certain use cases, but it should be treated as a negotiated risk-control mechanism rather than a universal legal requirement.
The contract should also address service levels, model changes, material degradation, and what happens if a provider changes or retires a model on which the customer's workflow depends.
6. Confidentiality and Security
Confidentiality provisions should be reviewed specifically for AI workflows.
Ask whether prompts and uploaded materials are stored, where they are stored, who can access them, whether subprocessors receive them, and whether the vendor can use them for product improvement.
Security terms should address applicable standards, incident response, subprocessors, deletion, access controls, and customer audit or reporting rights where appropriate.
7. Regulatory and Compliance Allocation
AI regulation is developing quickly. Contracts should identify which party is responsible for compliance obligations that actually apply to the product and use case.
Do not assume that a single AI-law clause solves the issue. The relevant obligations can depend on the model, deployment, geography, industry, and use case.
A good contract allocates responsibility for compliance rather than simply stating that the vendor is “AI compliant.”
8. Termination, Portability and Model Changes
AI customers should think beyond the first year of the contract.
Address data deletion, export and portability, transition assistance, model changes, material feature changes, and termination rights. If the customer's business depends on a particular model or output format, the agreement should address what happens when that model changes.
Bottom Line
AI contracts should answer a simple set of questions:
What data goes in? Who can use it? What comes out? What rights does the customer receive? What happens if the output infringes someone else's rights? Who bears the risk of inaccurate output? How is the system secured? And what happens when the model changes?
The strongest AI contracts turn those questions into specific, enforceable allocations of risk rather than relying on broad assurances about “responsible AI.”
AI Contracts Are Becoming Core Commercial Documents
If your company buys, builds, or sells AI-enabled products, the AI provisions in the contract can matter as much as the price.
Traditional SaaS agreements often assumed that customer data stayed within the service, outputs could be treated like ordinary software deliverables, and system behavior was relatively predictable.
AI systems complicate each assumption.
1. Customer Data Use and Model Training
The first question should be: what can the vendor do with customer data?
The contract should clearly address whether prompts, inputs, outputs, uploaded documents, telemetry, and other customer data may be used to train or improve models; whether use is optional or automatic; whether data is retained; and what happens after termination.
If the customer prohibits training on its data, the contract should make the restriction operational rather than relying on a marketing statement.
2. Output Ownership Is Not the Same as Copyright
Customers often want the vendor to say, “You own the output.”
That is useful, but it is not the whole legal analysis. A vendor can contractually allocate whatever rights it has in an output, but copyright protection for purely AI-generated material can depend on the nature and extent of human authorship.
The U.S. Copyright Office has emphasized that human authorship remains the key issue. Human selection, arrangement, modification, or other sufficiently creative contributions can affect the copyright analysis.
The contract should therefore address both contractual rights in outputs and the possibility that some output may not receive copyright protection.
3. Third-Party and Training-Data Risk
AI contracts should address the provider's representations about the sources and use of training data and other third-party material.
For general-purpose AI models, the EU AI Act includes copyright-related compliance and training-data transparency requirements for providers. Those rules make provenance, compliance representations, and allocation of third-party IP risk increasingly important in enterprise contracting.
Do not turn this into an absolute warranty that every output is free of third-party claims. Instead, define the provider's representations, exclusions, indemnities, and remediation obligations.
4. Indemnification
AI products can create IP, privacy, security, and regulatory risks that traditional SaaS indemnities may not address.
Review whether the vendor provides IP infringement indemnification for AI outputs and, if so, what exclusions apply. Also consider whether the indemnity is limited by use restrictions, modifications, combinations with third-party materials, customer-provided content, or failure to follow provider instructions.
5. Accuracy and Human Review
AI systems can generate incorrect, incomplete, or inconsistent outputs.
The contract should allocate responsibility for reviewing outputs and define prohibited or high-risk uses where appropriate. A human-review requirement may be appropriate for certain use cases, but it should be treated as a negotiated risk-control mechanism rather than a universal legal requirement.
The contract should also address service levels, model changes, material degradation, and what happens if a provider changes or retires a model on which the customer's workflow depends.
6. Confidentiality and Security
Confidentiality provisions should be reviewed specifically for AI workflows.
Ask whether prompts and uploaded materials are stored, where they are stored, who can access them, whether subprocessors receive them, and whether the vendor can use them for product improvement.
Security terms should address applicable standards, incident response, subprocessors, deletion, access controls, and customer audit or reporting rights where appropriate.
7. Regulatory and Compliance Allocation
AI regulation is developing quickly. Contracts should identify which party is responsible for compliance obligations that actually apply to the product and use case.
Do not assume that a single AI-law clause solves the issue. The relevant obligations can depend on the model, deployment, geography, industry, and use case.
A good contract allocates responsibility for compliance rather than simply stating that the vendor is “AI compliant.”
8. Termination, Portability and Model Changes
AI customers should think beyond the first year of the contract.
Address data deletion, export and portability, transition assistance, model changes, material feature changes, and termination rights. If the customer's business depends on a particular model or output format, the agreement should address what happens when that model changes.
Bottom Line
AI contracts should answer a simple set of questions:
What data goes in? Who can use it? What comes out? What rights does the customer receive? What happens if the output infringes someone else's rights? Who bears the risk of inaccurate output? How is the system secured? And what happens when the model changes?
The strongest AI contracts turn those questions into specific, enforceable allocations of risk rather than relying on broad assurances about “responsible AI.”