Artificial intelligence is quickly becoming a routine part of business operations, but the legal architecture behind many AI vendor relationships has not caught up with the pace of adoption. Michigan businesses are now licensing AI tools for customer service, document review, marketing, hiring support, inventory forecasting, medical office administration, cybersecurity monitoring, accounting workflows, sales analytics, manufacturing quality control, and internal decision support. These tools are often sold with polished demonstrations, aggressive performance claims, and contract language designed to shift risk away from the vendor. When the tool does not work as promised, the buyer may discover that the most important legal question is not whether the product is called “AI,” “software,” “automation,” or “machine learning.” The question may be whether the transaction is governed by the Michigan Uniform Commercial Code, common law contract principles, or some combination of both.
The Michigan UCC matters because it supplies rules that can determine whether a vendor’s statements became warranties, whether implied warranties exist, whether those warranties were effectively disclaimed, what remedies are available, whether consequential damages can be limited, and whether the buyer may revoke acceptance after discovering a serious defect. For many AI disputes, the UCC is not the entire answer. AI contracts also raise issues involving data security, privacy, intellectual property, confidentiality, negligent implementation, professional judgment, regulatory compliance, insurance coverage, and indemnity. But when an AI vendor provides a product, embedded system, device, or mixed goods-and-services package, Michigan UCC principles may become a central part of the liability analysis. ¹
The first issue is classification. Article 2 of the Michigan UCC applies to transactions in goods. The statute defines goods, in general terms, as movable things identified to the contract for sale, subject to statutory exclusions. ¹ That definition fits many traditional commercial transactions, but AI vendor relationships are rarely traditional. A business may buy a physical device with embedded AI, such as a camera, sensor, machine-vision system, autonomous equipment component, or diagnostic unit. A business may license software hosted by the vendor as a cloud-based service. A business may buy access to an application programming interface, a model, an automated workflow platform, or a customized implementation package that includes data migration, configuration, training, support, and ongoing monitoring. The legal characterization of the transaction can be difficult because the buyer may view the deal as the purchase of a working AI capability, while the vendor may describe the deal as a service subscription, a license, or access to a platform.
Michigan courts approach mixed transactions by asking what predominates: the sale of goods or the provision of services. The analysis is not controlled by labels alone. Courts look at the thrust, purpose, and substance of the relationship. If the buyer’s ultimate goal is to acquire a product, the UCC may apply even though services such as design, installation, configuration, testing, and training are involved. If the buyer’s ultimate goal is to obtain services, the common law may control even though goods or materials are used along the way. ² In the AI context, that distinction can be decisive. A factory that buys an AI-enabled inspection camera system may have a stronger argument that it purchased goods, even if the vendor also installed and calibrated the system. A company that hires a vendor to review business processes and provide AI-driven consulting recommendations may face a stronger argument that the contract is predominantly for services. Between those two examples lies the hard middle ground where many real disputes will arise.
That middle ground is where careful contract drafting becomes essential. AI vendors often combine a subscription agreement, statement of work, order form, service-level exhibit, data processing addendum, usage policy, support policy, and online terms. Those documents may not speak with one voice. One section may describe a product, while another section disclaims all product warranties. One document may promise measurable performance, while another says the vendor makes no guarantees. One exhibit may identify a “solution,” while another says the customer is only receiving limited access to a hosted environment. If a dispute later arises, the parties may fight not only about whether the AI worked, but about what was actually purchased.
Michigan’s published decision in Challenge MFG Co, LLC v MetoKote Corp illustrates the importance of the goods-versus-services distinction in modern commercial contracts. Although that case involved industrial coating rather than AI, the reasoning is instructive for technology transactions because the court focused on the true nature of the bargain. The Court of Appeals explained that Article 2 governs transactions in goods and applied the predominant purpose analysis to determine whether the contract was governed by the UCC or common law. The court ultimately concluded that the transaction before it was predominantly for services, even though materials were involved. ³ For AI vendors and customers, the lesson is straightforward: when a transaction blends technology, implementation, configuration, and support, the governing law may depend on the practical commercial objective of the deal.
Once the UCC applies, warranty law becomes one of the most important risk-allocation tools. Express warranties may arise from affirmations of fact, promises, descriptions, samples, or models that become part of the basis of the bargain.⁴ This is especially significant in AI procurement because vendor sales materials often contain strong factual claims. A vendor may represent that its tool reduces review time by a certain percentage, identifies defects with a stated accuracy rate, produces compliant documentation, integrates with specified systems, operates within defined latency thresholds, or performs at enterprise scale. Those statements may be more than marketing puffery if they are factual, measurable, and relied upon in the transaction.
For AI vendors, the danger is that sales teams, demonstrations, white papers, benchmark results, and proposal language can create expectations that the legal department later tries to disclaim. For buyers, the danger is the opposite: the vendor’s most important promises may appear in sales materials but disappear from the final contract. A Michigan business purchasing AI should therefore insist that material performance representations be written into the operative agreement. The contract should identify what the system is supposed to do, what data environment it was evaluated against, what accuracy or performance standard applies, how performance will be measured, when testing will occur, and what happens if the system fails. A buyer should not assume that general enthusiasm about “accuracy,” “automation,” “compliance,” “efficiency,” or “human-level performance” will be enough.
The warranty of merchantability can also matter when the AI transaction is treated as a sale of goods by a merchant. Under Michigan’s UCC, a warranty that goods shall be merchantable is implied in a contract for sale if the seller is a merchant with respect to goods of that kind, unless the warranty is excluded or modified.⁴ In an AI context, the meaning of merchantability may be heavily contested. The ordinary purpose of a product may not be obvious when the product is a new AI-enabled system. A vendor may argue that the product is experimental, probabilistic, configurable, and dependent on customer data. A buyer may argue that a commercial AI product sold for a defined business function must be capable of performing that function in a commercially reasonable manner.
The implied warranty of fitness for a particular purpose may be even more important. Under Michigan’s UCC, where the seller has reason to know the buyer’s particular purpose and that the buyer is relying on the seller’s skill or judgment to select or furnish suitable goods, an implied warranty can arise that the goods will be fit for that purpose, unless excluded or modified.⁴ AI sales often involve exactly that type of reliance. A business may approach a vendor with a specific operational problem and rely on the vendor’s claimed expertise to recommend the right tool. The vendor may study the buyer’s workflow, data sources, industry, compliance environment, and desired outcome before proposing a solution. If the buyer is relying on the vendor’s skill to furnish a suitable AI product, the implied warranty of fitness may become a central theory of liability if the tool fails.
Vendors usually try to reduce this risk through disclaimers. They may disclaim implied warranties, state that the product is provided “as is,” limit the customer’s remedies, exclude consequential damages, and cap total liability at fees paid during a short lookback period. These provisions are not unusual in technology contracts, but they should not be treated as boilerplate. Under the UCC, warranty disclaimers and remedy limitations are governed by specific rules, and the enforceability of the vendor’s risk-shifting language can depend on the wording, conspicuousness, commercial context, and interaction among contract provisions.⁴ A vendor that wants predictable risk allocation should draft clearly and consistently. A buyer that accepts broad disclaimers without negotiated exceptions may be giving up the very protection it believes it is buying.
The difficulty with AI is that vendor disclaimers often collide with vendor sales claims. A vendor may promise that its system can safely automate a business process and then disclaim responsibility for the output. It may claim that the model can classify documents, screen resumes, identify fraud, detect defects, generate legal or compliance text, or recommend financial action, while also stating that the customer assumes all risk for results. That tension is where many disputes will arise. If the vendor’s measurable promises are central to the bargain, a buyer may argue that the vendor cannot reduce the contract to an empty promise. Conversely, if the final agreement clearly states that the customer is responsible for validation, human review, and deployment decisions, the vendor will argue that the buyer accepted the operational risk.
Acceptance testing is therefore critical. AI systems can appear impressive during a demonstration but fail in the buyer’s actual environment. The model may perform well on vendor-selected data but poorly on customer data. It may work during a pilot but degrade after deployment. It may produce accurate outputs most of the time but fail unpredictably in edge cases that matter. It may require training, tuning, monitoring, and feedback loops that were not adequately described during contracting. A Michigan business should not rely on a vague right to reject a system after implementation. The agreement should describe objective acceptance criteria, testing data, test duration, responsibility for remediation, retesting rights, and the consequences of failure.
The UCC’s revocation-of-acceptance concept may become relevant where the buyer accepted goods and later discovers a nonconformity that substantially impairs their value, particularly where acceptance was induced by the difficulty of discovering the defect or by the seller’s assurances.⁵ In AI transactions, some defects are difficult to discover at delivery because they emerge only after the system processes live data, encounters unusual inputs, integrates with other systems, or operates at scale. A model that appears functional on day one may later reveal biased outputs, unacceptable false positives, cybersecurity weaknesses, hallucinated content, unreliable classifications, or compliance failures. Contract language should address whether post-deployment discovery of such problems triggers cure obligations, refund rights, termination rights, service credits, indemnity, or expanded remedies.
Cure rights must also be tailored to the nature of AI. Traditional repair-or-replace remedies may not fit a system whose defect lies in training data, model architecture, prompt design, integration, configuration, access controls, or vendor-hosted updates. A vendor may need time to patch, retrain, adjust thresholds, modify workflows, add guardrails, or change documentation. A buyer may need immediate suspension rights if the system is creating legal exposure or operational harm. A limited remedy that works for ordinary goods may fail commercially when the AI system cannot be made to perform the essential function for which it was purchased. Under Michigan’s UCC, when an exclusive or limited remedy fails of its essential purpose, other remedies under the statute may become available.⁵ That concept should be considered before the parties sign a contract, not after the technology fails.
Damages are another central issue. AI failures can create losses that are difficult to classify. A defective system may cause internal rework, customer refunds, lost sales, reputational harm, regulatory inquiries, data remediation costs, breach notification expenses, business interruption, lost profits, replacement vendor costs, or third-party claims. Under the UCC, buyers may recover certain incidental and consequential damages caused by the seller’s breach, subject to statutory and contractual limits.⁵ Vendors commonly seek to exclude consequential damages because those losses can dwarf the contract price. Buyers, especially those using AI in core business functions, should understand that a consequential-damages exclusion may eliminate the most important recovery category.
A vendor’s limitation of consequential damages is not automatically invalid in a commercial case. Michigan’s UCC permits limitation or exclusion of consequential damages unless the limitation or exclusion is unconscionable, and limitation of damages where the loss is commercial is not treated the same way as personal injury damages involving consumer goods.⁵ This gives commercial parties substantial freedom to allocate risk. But freedom to allocate risk does not mean that every limitation is good business judgment for the buyer. A company that deploys AI to perform a mission-critical function should ask whether the liability cap bears any reasonable relationship to the risk. A cap equal to three months of fees may be unacceptable if a system failure could trigger hundreds of thousands of dollars in customer claims, regulatory costs, or production losses.
The buyer should also distinguish between ordinary contract damages and indemnity obligations. A vendor may agree to indemnify the buyer for third-party intellectual property claims but refuse to indemnify for data breach, privacy violations, employment-law claims, consumer-protection claims, or regulatory penalties arising from the AI output. A contract may exclude consequential damages but carve out confidentiality breaches, data-security obligations, gross negligence, willful misconduct, intellectual property infringement, or violation of law. These carveouts are not just drafting preferences. They often determine whether the vendor has meaningful financial responsibility for the most foreseeable harms. In AI contracting, the most important question is not merely whether there is a liability cap, but what is outside the cap.
Michigan’s economic loss doctrine also deserves attention. In Neibarger v Universal Cooperatives, Inc, the Michigan Supreme Court held that where a claim arises from the commercial sale of goods and the losses are purely economic, remedies are generally limited to those available under the UCC rather than tort. ² This matters because a disappointed AI buyer may want to frame the vendor’s conduct as negligence, negligent misrepresentation, or failure to exercise due care. In a commercial goods transaction, however, tort theories may be limited when the loss is essentially the disappointed commercial expectation that the product did not perform as promised. Buyers should therefore build their remedies into the contract instead of assuming that tort law will later fill the gap.
The economic-loss principle is especially important for AI tools because many failures produce economic harm rather than physical injury or property damage. A poor AI implementation may require expensive remediation, delay a product launch, produce bad internal decisions, or force the buyer to hire replacement personnel or consultants. Those losses can be real and substantial, but they may still be characterized as commercial expectations under the contract. A buyer that negotiates weak warranties, accepts broad disclaimers, and agrees to a low liability cap may later find that the contract defines the practical ceiling of recovery.
Statute-of-frauds and quantity-term principles also have a role in long-term AI supply relationships. Michigan’s UCC statute of frauds requires certain contracts for the sale of goods to be supported by a sufficient signed writing, and quantity can be a critical term. In MSSC, Inc v Air Boss Flexible Products Co, the Michigan Supreme Court held in the automotive supply context that a “blanket” purchase order without more did not express a quantity term sufficient to create the requirements-contract obligation claimed by the buyer. The Court treated the arrangement as release-by-release rather than an enforceable long-term requirements contract. ³ Although Air Boss was not an AI case, its reasoning is useful for AI procurement where the parties use master agreements, order forms, usage commitments, releases, statements of work, or future deployment phases. If the buyer expects the vendor to support a long-term AI deployment at fixed pricing, or if the vendor expects the buyer to purchase a defined volume of licenses, credits, devices, or model capacity, the writing should say so clearly.
AI usage models complicate this issue because the “quantity” may not look like traditional units of goods. The parties may speak in terms of users, seats, tokens, credits, devices, data volume, transactions, API calls, model instances, facilities, business units, or deployment phases. If a long-term obligation matters, the contract should define the commitment. A buyer that needs the vendor to supply capacity for a multi-year rollout should avoid language that merely expresses expectations or future intentions. A vendor that wants flexibility should avoid accidentally creating a requirements-style commitment through ambiguous exclusivity, preferred-provider, or life-of-program language. The more operationally important the AI system is, the more dangerous ambiguity becomes.
Another recurring problem is model performance over time. Traditional goods are often evaluated at delivery, but AI systems can change after deployment. The vendor may update the model, change the training data, alter safety filters, modify the user interface, retire features, adjust pricing, or change third-party dependencies. The buyer’s own data may also change, causing model drift or reduced performance. The contract should define whether the vendor is warranting the system only at initial deployment or throughout the term. It should also describe notice obligations for material changes, regression testing, rollback rights, version control, audit logs, and support obligations if an update reduces functionality.
For Michigan businesses, one of the most practical steps is to separate AI performance obligations from generalized service obligations. A service-level agreement that only promises uptime may not protect the buyer from inaccurate outputs. A system can be available 99.9 percent of the time and still produce unreliable classifications, flawed recommendations, or legally risky content. If output quality matters, the contract should address output quality. If response time matters, it should be measured. If bias testing matters, it should be required. If human review is part of the safety model, the contract should state who performs it and what documentation must be maintained. If the vendor claims that the tool complies with a legal or industry standard, the contract should identify the standard and allocate responsibility for maintaining compliance as the law and technology evolve.
Buyers should be cautious with vendor language stating that the customer is solely responsible for all outputs. Some allocation of responsibility is reasonable because AI systems often depend on customer inputs, prompts, data quality, user decisions, and deployment context. But a clause that shifts all output risk to the customer may be inconsistent with the buyer’s business reason for purchasing the tool. A more balanced approach is to allocate responsibility by cause. The customer can be responsible for its data, prompts, user instructions, and final business decisions, while the vendor remains responsible for the system conforming to agreed specifications, documentation, security commitments, and performance warranties.
Vendors also need disciplined contracting. AI vendors should avoid letting sales claims outrun technical reality. They should distinguish between beta features and production features, between general capabilities and guaranteed performance, and between benchmark results and customer-specific results. If the system requires human oversight, that requirement should be stated plainly. If the tool is not intended for regulated decisions, legal advice, employment selection, medical diagnosis, financial recommendations, or other high-risk uses, the contract and documentation should say so. If the vendor’s performance depends on the buyer providing clean data, adequate integration access, and trained users, those dependencies should be expressed as customer obligations.
The contract should also address documentation and evidence. AI disputes can become difficult because the relevant evidence may include prompts, inputs, outputs, confidence scores, logs, model versions, configuration settings, training materials, user permissions, exception reports, and support tickets. Without preservation obligations, a buyer may struggle to prove what happened. Without reasonable limits, a vendor may face burdensome demands for proprietary model information. The parties should decide in advance what records will be maintained, how long they will be retained, what audit rights exist, and how confidentiality and trade-secret concerns will be protected.
Insurance should not be overlooked. General commercial liability coverage may not respond to many AI-related economic losses. Cyber policies may respond to certain data breaches but not to defective model output. Technology errors-and-omissions coverage may be more relevant, but policy language varies. Buyers should request appropriate insurance requirements, but they should also understand that insurance is not a substitute for contractual risk allocation. Vendors should align their contractual indemnities and liability caps with available coverage so they do not promise protection that their insurance program will not support.
The Michigan UCC does not solve every AI liability problem, and in some AI contracts it may not apply at all. But its concepts remain highly relevant because AI is increasingly embedded in commercial products, operational systems, and mixed transactions. The core UCC questions are practical ones. What did the buyer purchase? What promises did the vendor make? Were those promises incorporated into the contract? Were implied warranties preserved or disclaimed? What testing was required before acceptance? What happens if defects appear after deployment? What damages are recoverable? What damages are excluded? Does the limited remedy actually give the buyer the benefit of the bargain?
For Michigan businesses, the safest approach is to treat AI procurement as a legal and operational risk-management exercise rather than a routine software purchase. The contract should be written for the actual use case. A low-risk internal drafting aid does not require the same protections as an AI system used for customer eligibility, quality control, regulated communications, financial review, or employment screening. The greater the potential harm, the more important it becomes to negotiate specific warranties, acceptance standards, monitoring obligations, indemnity provisions, data protections, and meaningful remedies.
AI vendor liability under the Michigan UCC will likely continue to develop as courts confront disputes involving software, services, embedded systems, and automated decision tools. Until then, Michigan businesses should not assume that traditional technology forms adequately address AI risk. The most important work happens before signature. Buyers should insist that the contract reflect the vendor’s actual promises and the buyer’s actual risks. Vendors should make sure their contracts accurately describe what the system can and cannot do. Both sides should recognize that AI does not eliminate ordinary commercial-law principles. It makes them more important.
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).
Sources:
1- Michigan Compiled Laws, Uniform Commercial Code, Article 2, including MCL 440.2102 and MCL 440.2105. http://legislature.mi.gov/documents/mcl/pdf/mcl-chap440.pdf
2- Neibarger v Universal Cooperatives, Inc, 439 Mich 512; 486 NW2d 612 (1992). https://law.justia.com/cases/michigan/supreme-court/1992/88206-3.html
3- Challenge MFG Co, LLC v MetoKote Corp, 345 Mich App 338; 5 NW3d 83 (2023); MSSC, Inc v AirBoss Flexible Products Co, 511 Mich 176; 999 NW2d 335 (2023). https://www.courts.michigan.gov/49f363/siteassets/case-documents/uploads/opinions/final/coa/20230126_c357280_60_357280.opn.pdf
4- Michigan Compiled Laws, Uniform Commercial Code, Article 2 warranty provisions, including MCL 440.2313, MCL 440.2314, MCL 440.2315, and MCL 440.2316. https://codes.findlaw.com/mi/chapter-440-uniform-commercial-code/mi-comp-laws-440-2313/
5- Michigan Compiled Laws, Uniform Commercial Code, Article 2 buyer-remedy and limitation provisions, including MCL 440.2608, MCL 440.2715, and MCL 440.2719. http://legislature.mi.gov/documents/mcl/pdf/mcl-chap440.pdf