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. Copyright vests only in human-authored works: the D.C. Circuit has held that “the Creativity Machine cannot be the recognized author of a copyrighted work because the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being.” Thaler v. Perlmutter, 130 F.4th 1039 (D.C. Cir. 2025). That is also the U.S. Copyright Office’s position, reaffirmed in its January 2025 report on AI copyrightability. Purely AI-generated output therefore has no author and no default owner, which is why the contract, not background law, has to allocate the rights. 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 a product or service used in, or intended for use in, interstate or foreign commerce. 18 U.S.C. § 1836(b)(1). The federal track carries real teeth: injunctive relief, actual-loss and unjust-enrichment damages or a reasonable royalty, up to double damages for willful and malicious misappropriation, and attorney’s fees (18 U.S.C. § 1836(b)(3)), on a claim that must be brought within three years of when the misappropriation is or reasonably should have been discovered (18 U.S.C. § 1836(d)). One more reason to lean on the contract and not the statute alone: the DTSA treats reverse engineering and independent derivation as lawful acquisition, not misappropriation, so a confidentiality clause can bar conduct the statute leaves permitted (18 U.S.C. § 1839(6)).
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. UCC Article 2 applies only to “transactions in goods” (Minn. Stat. § 336.2-102(1)), and “goods” are things that are movable (Minn. Stat. § 336.2-105(1)), so a pure AI subscription is usually a service, governed by Minnesota common-law contract rules, and the UCC protections below do not automatically apply to it. If the subscription is bundled with goods, such as an AI service sold with hardware, it is a hybrid transaction; effective August 1, 2024, Minnesota adopted a statutory rule for those deals under which, if the sale-of-goods aspects predominate, Article 2 applies to the whole transaction, and if they do not, only the provisions of Article 2 that relate primarily to the sale-of-goods aspects apply (Minn. Stat. § 336.2-102(2)). 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. 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)), and bars keeping personal data no longer reasonably necessary for the purposes it was collected for (Minn. Stat. § 325M.16, subd. 2(g)).
You cannot hand the legal duty itself to a vendor, and no contract can relieve you of the liabilities that attach to your role in the processing relationship (Minn. Stat. § 325M.13(f)), 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, in effect since July 31, 2025, is enforced by the Minnesota Attorney General, not through private lawsuits (Minn. Stat. § 325M.20), and a violation carries an injunction and a civil penalty of up to $7,500 per violation (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 after giving you a chance to object and 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, both the U.S. Copyright Office and the D.C. Circuit have taken the position that material generated purely by AI, with no human author, is not eligible for copyright, which affects what you can stop competitors from copying even when the vendor agrees you own it. Work you create with the help of an AI tool can still be protected where you supply the creative authorship: only output with no human author at all falls outside copyright.
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 want your specific AI vendor agreement analyzed before you sign, email [email protected] with a short note on how you plan to use the tool to start an intake and conflict check. 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.
