A CEO signing up for an artificial intelligence (“AI”) tool usually sees a familiar-looking subscription form and assumes the terms are standard. They are standard, in the sense that they are written for the vendor. AI vendor contracts allocate risks that did not exist a few years ago: who owns what the tool produces, whether your data trains the vendor’s model, and who pays when an AI output turns out to infringe someone else’s work. Most of this is set by ordinary Minnesota contract law, which means it is yours to negotiate, with three statutory overlays that matter once data and goods enter the picture. In my Minnesota contracts practice, the agreements that protect a business are the ones where the buyer treated the vendor’s form as a starting draft, not a closing document, and knew which red flags buried in vendor agreements to fix before signing.
Who owns the inputs and outputs my AI vendor generates?
Ownership of the data you put into an AI tool and the content it produces is set by your contract, not by default law, because settled ownership rules do not cleanly resolve who owns AI output. A Minnesota business should confirm two things in writing: that it keeps ownership of the inputs it supplies, and that it owns the outputs the tool generates from those inputs, or holds a license broad enough to use them without limits. Vendor forms often stay silent on outputs or claim a license back to themselves.
The practical risk is not theoretical. A marketing team feeds product data and customer language into a tool, the tool generates campaign copy, and the form never says who owns the result. Spell it out. State that inputs remain your property, that outputs are assigned to you on creation, and that the vendor gets no license to reuse either beyond running the service for you. Ownership language is cheap to add at signing and expensive to fix in a dispute.
Can the vendor train its model on my data?
A vendor may train its model on your data only if your contract permits it, so the default you want is a clear no-training commitment. The terms to negotiate are an outright bar on training the vendor’s general models with your data, a narrow carve-out (if any) for aggregated and de-identified data, and a duty to delete your data on request. Many vendors reserve broad training rights in the fine print, which means your confidential inputs can improve a product your competitors also use.
Training rights also reach your trade secrets. Under the Minnesota Uniform Trade Secrets Act (“MUTSA”), information qualifies as a trade secret only when it is “the subject of efforts that are reasonable under the circumstances to maintain its secrecy.” (Minn. Stat. § 325C.01, subd. 5.) Letting a vendor ingest your secret formulas, pricing models, or customer data into a shared model can undercut the secrecy that makes them protectable in the first place. A no-training clause is partly a confidentiality tool: it keeps the inputs that give you an edge from leaking into someone else’s system.
How do I keep my confidential information and trade secrets protected in an AI contract?
Confidentiality protection comes from a definition of confidential information broad enough to cover what you feed the tool, backed by real secrecy measures, because trade-secret law protects only information actually kept secret. Under both MUTSA and the federal Defend Trade Secrets Act (“DTSA”), a trade secret must derive “independent economic value” from not being generally known and must be guarded by reasonable efforts. (Minn. Stat. § 325C.01, subd. 5; 18 U.S.C. § 1839(3).) The DTSA gives the owner of a misappropriated trade secret a federal civil claim where the secret relates to interstate commerce, so the protection runs in two tracks, state and federal.
Tie the contract to your practice. Define confidential information to include the data, prompts, and configurations you put into the tool, not just documents marked “confidential.” Pair the nondisclosure terms with access controls and a no-training clause so the secrecy on paper matches the secrecy in fact. The same care that makes a standalone nondisclosure agreement enforceable in Minnesota applies inside a vendor contract: a confidentiality promise the vendor cannot realistically keep, or that your own loose handling contradicts, will not hold up when it counts.
What happens if the AI output infringes someone else’s intellectual property?
When an AI output copies someone else’s protected work, the question of who pays the resulting claim turns entirely on the indemnification clause. A Minnesota business should negotiate vendor indemnification for third-party intellectual property (“IP”) claims arising from the tool’s outputs, because the buyer using the output is the natural target of an infringement suit even though the vendor built the model. Without that clause, you absorb a risk you did not create.
Read the indemnity for the exceptions that hollow it out. Many AI vendors indemnify outputs but carve out any output you modified, combined with other material, or used outside narrow guidelines, which can cover most real-world use. Confirm how the promise works using the same lens you would apply to indemnification in IP licensing deals, and watch for the carve-outs that can swallow an indemnity before you rely on it. Then check one more connection: an indemnity is only as strong as the liability cap above it. If the contract caps total liability low and does not exempt the IP indemnity, the vendor’s promise to cover infringement claims is worth no more than the cap. The way an indemnification clause shifts third-party-claim risk only protects you if the cap does not quietly take it back.
What does a limitation-of-liability clause actually cap, and which carve-outs matter?
A limitation-of-liability clause caps the dollars you can recover from the vendor and usually excludes consequential damages, the indirect losses like lost profits or downstream costs that often dwarf the direct ones. Which body of law backstops the cap depends on what you are buying. A pure AI subscription is usually a service, governed by Minnesota common-law contract rules, and the protections below do not automatically apply to it. Where the deal is a sale of goods, or the agreement is structured or treated as one, Minnesota’s version of the Uniform Commercial Code (“UCC”) governs these limits instead. Section 336.2-719 lets parties “limit or alter the measure of damages recoverable” and make a remedy exclusive only when it is “expressly agreed to be exclusive.” (Minn. Stat. § 336.2-719.)
Two statutory limits matter to the buyer. First, an exclusive remedy that fails the buyer is not the end of the road: “Where circumstances cause an exclusive or limited remedy to fail of its essential purpose, remedy may be had as provided in this chapter.” (Minn. Stat. § 336.2-719.) A repair-or-replace remedy that never actually fixes the problem can be set aside. Second, a commercial consequential-damages exclusion is generally enforceable: the statute provides that “Consequential damages may be limited or excluded unless the limitation or exclusion is unconscionable,” and adds that limiting commercial loss “is not” prima facie unconscionable, unlike a limit on personal-injury damages for consumer goods. (Minn. Stat. § 336.2-719.) The takeaway for a business buyer: expect the consequential-damages waiver to stand, and instead bargain over carve-outs and the cap amount. Most of the negotiation in Minnesota limitation-of-liability clauses is about which losses sit outside the cap, not whether a cap exists.
What data-security and privacy duties should the contract put on the vendor?
The contract should require the vendor to maintain reasonable security and to support your privacy obligations, because under the Minnesota Consumer Data Privacy Act (“MCDPA”) a covered business stays responsible for the personal data even when a vendor does the processing. The MCDPA requires a controller to “establish, implement, and maintain reasonable administrative, technical, and physical data security practices to protect the confidentiality, integrity, and accessibility of personal data, including the maintenance of an inventory of the data that must be managed to exercise these responsibilities.” (Minn. Stat. § 325M.16, subd. 2(c).) The statute also bars processing personal data for purposes that are “not reasonably necessary to, or compatible with,” the purposes disclosed to the consumer. (Minn. Stat. § 325M.16, subd. 2(b).)
You cannot hand the legal duty itself to a vendor, so you handle it through the contract. Require the vendor to meet a named security standard, to use the data only for your purposes, to notify you promptly of a breach, and to carry security obligations that survive the agreement. The MCDPA is enforced by the Minnesota Attorney General, not through private lawsuits (Minn. Stat. § 325M.20), which means strong vendor obligations are your main lever for managing the exposure that sits, by law, on you and not on the processor. This contract work is the front line of your own consumer-privacy compliance obligations.
Do I need a data-processing agreement with my AI vendor?
A covered Minnesota business that lets a vendor process personal data needs a binding data-processing agreement, because the MCDPA requires a contract that governs the processing. Under Minn. Stat. § 325M.13(e), that contract must set the vendor’s processing instructions and the nature, purpose, type, and duration of the processing; impose security and confidentiality duties, including a requirement to “ensure that each person processing the personal data is subject to a duty of confidentiality with respect to the data”; require deletion or return of the data at your direction; give you information to demonstrate compliance; and let the vendor engage a subcontractor only under a written contract that binds the subcontractor to the same duties.
In practice this is a separate exhibit, often called a data processing addendum, attached to the main agreement. Treat it as substance, not boilerplate. The subcontractor flow-down matters most with AI vendors, who frequently route processing through cloud and model providers you never see. The gap I run into most often is a vendor that cannot name its subprocessors or bind them to the same duties, and that gap is yours to absorb when it surfaces.
What accuracy, warranty, and human-review terms protect against bad AI output?
Because most AI vendors disclaim warranties and sell output “as is,” accuracy protection has to be negotiated into the contract rather than assumed. The vendor’s standard form typically promises nothing about whether the output is correct, leaving the accuracy risk with you, which matters when the tool drafts a contract clause, summarizes a regulation, or generates customer-facing content. The protection is a negotiated performance term: a service-level commitment, a limited warranty that the service will perform as described, and a stated expectation that a qualified person reviews material output before the business relies on it.
A human-review expectation does double duty. It sets a realistic standard the vendor can meet, and it documents that your business does not treat raw AI output as final, which strengthens your position if a flawed output causes harm. Do not let the warranty disclaimer pass unread. Knowing how warranty terms and disclaimers work under Minnesota law is what tells you which protections the vendor stripped out and which ones to put back.
What audit rights and transparency terms should I negotiate?
Audit and transparency terms let you confirm the vendor is actually meeting its security and data-use promises, instead of taking them on faith. A Minnesota business should negotiate the right to receive current security documentation, such as a recognized third-party security report, and to be told of material changes to how the tool processes data. For personal data, the MCDPA contemplates that a controller can verify a processor’s compliance, and Minn. Stat. § 325M.13(e) directs that the processing contract give the controller information sufficient to demonstrate compliance and allow reasonable assessments.
Calibrate the audit right to the relationship. A full on-site inspection right is rare with large AI vendors and not always worth the fight; a contractual right to current security reports, breach notice, and notice of subprocessor changes gives most businesses the visibility they need. The point is to avoid a contract where the vendor’s promises are unverifiable, because a promise you cannot check is a promise you cannot enforce.
How do termination and transition-assistance clauses protect me when the relationship ends?
Termination and transition terms decide whether you can leave a vendor and take your data with you, which is where AI dependence becomes dangerous. Negotiate three things: a termination-for-convenience right so you are not locked in, a defined transition-assistance period during which the vendor helps you migrate, and a duty to return your data in a usable format and then delete its copies. Make the confidentiality and data-protection obligations survive termination, so they do not expire the moment the contract does. Minn. Stat. § 325M.13(e) already requires deletion or return of personal data at your direction; extend that duty to all of your data, not just personal data.
The exit is easiest to bargain for before you sign. A termination-for-convenience right in a SaaS contract keeps you from being trapped by a tool that no longer fits, and clear rules about which obligations survive after the contract ends keep your data protected through the wind-down. Once a vendor knows you are leaving, its leverage to help you go drops; the time to set the terms of departure is at the start of the relationship.
Can I use a vendor's standard click-through AI agreement as-is?
You can, but a click-through form is drafted to favor the vendor. For any tool that touches your confidential data or core operations, negotiate the ownership, training, security, and liability terms instead of accepting the form. The convenience of clicking agree is rarely worth the risk it leaves with you.
Do I own a contract or marketing piece an AI tool drafts for my business?
Between you and the vendor, ownership of that output is whatever the contract says, so confirm the agreement assigns output ownership or a broad license to you. Separately, the U.S. Copyright Office has taken the position that material generated purely by AI, without human authorship, is not eligible for copyright, which affects what you can stop competitors from copying even when the vendor agrees you own it.
Is a no-training clause enough to protect my trade secrets?
A no-training clause helps but does not finish the job. You also need a confidentiality definition that covers what you input and real secrecy measures on your side, because Minnesota and federal trade-secret law protect only information kept secret by reasonable efforts. The clause and the practice have to match.
Will a liability cap stop me from recovering if the vendor's AI causes a data breach?
Often yes, unless you carve security and confidentiality breaches out of the cap. Negotiate an exception, or a higher cap, for data-breach and confidentiality losses so the limitation does not leave you uncovered for your largest exposure. A standard cap set at one year of fees rarely matches the cost of a breach.
Do I have privacy-law duties if my AI vendor is the one handling the personal data?
Yes. If your business is covered by the Minnesota Consumer Data Privacy Act, you stay responsible for the personal data even when a vendor processes it. That is why the contract has to put security, use-limitation, and deletion duties on the vendor: you cannot hand the legal duty itself to a processor.
What if the vendor goes out of business or I want to switch tools?
Your protection is a transition-assistance and data-return clause negotiated up front. Require the vendor to export your data in a usable format, provide a defined wind-down period, and delete its copies, so a vendor’s exit does not strand your operations. The time to bargain for the exit is before you sign, not after.
The contract is where the risk gets decided
AI vendor agreements move real risk onto the business that signs them, and almost all of that risk is negotiable. The clauses worth your attention are the ones covered above: ownership of inputs and outputs, the vendor’s training rights, confidentiality and trade-secret protection, IP-infringement indemnity, the liability cap and its carve-outs, security and privacy duties, a real data-processing agreement, accuracy and human-review terms, audit rights, and a clean exit. None of them depends on novel law; they depend on reading the form as a draft and bargaining for the terms a one-sided form leaves out. The exact language of your vendor’s agreement controls the outcome, so the specifics of your form matter more than any general rule.
If you would like a second set of eyes on a specific AI vendor agreement before you sign, email [email protected] with the agreement and a short note on how you plan to use the tool. For the broader picture of how these clauses fit together with your other agreements, see our guidance on managing vendor-contract risk across your agreements and how I approach business contracts work.
