Artificial intelligence projects rarely fail in one dramatic moment. More often, a Michigan business discovers the problem in stages. The promised system does not connect reliably with legacy software. Results that looked impressive in a demonstration become inconsistent when the tool encounters the company’s actual data. Employees must review so much of the output that the projected efficiency disappears. A vendor misses one launch date, then another, while continuing to invoice subscription and implementation fees. In a more serious case, the platform exposes confidential information or uses customer data in a way the parties never discussed. By the time management concludes that the project will not deliver its expected value, the company may have spent substantial money, diverted employees from other priorities, delayed competing initiatives, and reorganized important workflows around a product that never became dependable. What began as an innovation project can quickly become a contract dispute.
Commercial failure, however, is not the same as legal breach. A system can be disappointing yet satisfy a modest contract that promised only access to software on an “as available” basis. Conversely, a product can appear functional while violating important promises concerning accuracy, integration, data use, security, or support. The strength of a claim therefore depends less on the general label “AI failure” than on the obligations the parties actually adopted, the evidence of performance, the causes of the shortfall, the customer’s own conduct, and the remedies that remain available after applying the contract’s limitations. A disciplined legal response translates a diffuse technical problem into familiar questions: What did the vendor promise? What was delivered? Why did performance fall short? Was notice given? Could the problem be cured? What losses followed, and did the parties allocate those losses in advance?
Under Michigan law, a party asserting breach of contract generally must establish the existence and terms of the contract, a breach of those terms, and damages caused by the breach. The claimant must also prove recoverable damages with reasonable certainty. ¹ In an AI dispute, identifying the complete contract can be surprisingly difficult. The parties’ bargain may be distributed across a master services agreement, an order form, one or more statements of work, a data-processing addendum, a service-level agreement, a security exhibit, an implementation plan, change orders, online terms, and technical documentation incorporated by reference. Sales proposals, demonstrations, emails, and presentation decks may contain the statements that persuaded the customer to proceed, yet those materials may not appear in the final signed package. Before deciding whether the implementation failed legally, the business should collect every document that may define the vendor’s duties, describe the intended use, establish dependencies, modify the scope, or restrict a remedy.
Integration and order-of-precedence clauses often control the first major dispute. The vendor may argue that the signed agreement superseded every prior statement and that the customer cannot rely on a proposal or demonstration. The customer may respond that the proposal, implementation plan, or technical response was expressly incorporated into the agreement. When provisions conflict, an order-of-precedence clause may determine whether a negotiated statement of work controls over standardized online terms. Michigan courts ordinarily enforce unambiguous language according to its plain meaning and read the contract as a whole, giving effect to every word when possible. ² The strongest contract claim therefore links the alleged failure to a specific obligation in the governing documents, rather than to an overall impression created during the sales process.
The business should also determine whether the vendor changed any terms or product characteristics after signing. AI services frequently depend on online policies, acceptable-use rules, model-provider terms, documentation, feature descriptions, and security practices that vendors reserve the right to revise. A later change may remove a capability, substitute an underlying model, alter how prompts are retained, restrict a regulated use, or make a promised integration impractical. The legal issue may then concern not only whether the original implementation was deficient, but also whether the contract authorized the vendor to make the change, whether required notice was provided, and whether the change deprived the customer of a material part of the bargain. Version histories, archived documentation, release notes, and dated screenshots may become essential evidence because the current website may no longer describe the service the customer purchased.
An AI project may be commercially unsuccessful without violating the contract. If the agreement promises only access to a platform while broadly disclaiming accuracy, compatibility, uninterrupted operation, and fitness for the customer’s purpose, a claim may be difficult even when the system is practically useless. A detailed statement of work creates a different case. It may specify required integrations, deliverables, staffing commitments, milestone dates, response times, acceptance tests, or accuracy thresholds. The more clearly the parties converted the business objective into measurable obligations, the easier it becomes to distinguish breach from ordinary implementation risk.
Failure can take several legally distinct forms. The vendor may never deliver the configured system, may miss a launch date that the contract treats as material, or may fail to connect identified data sources. The system may fall below an agreed accuracy rate, produce prohibited outputs, experience repeated outages, or require far more human review than the contract assumed. A vendor may deliver the technical components yet fail to achieve a business result that was expressly made part of the bargain. The same project may also involve nonperformance unrelated to output quality, including unauthorized use of customer information, inadequate security, refusal to provide promised support, or failure to return data at termination. Each theory should identify the particular promise, the objective evidence of deviation, and the causal connection between the deviation and the claimed loss.
Precision is especially important because many AI outputs are probabilistic rather than deterministic. A promise that a system will be “accurate,” “intelligent,” or “enterprise ready” may be too indefinite unless the agreement explains what is measured and under what conditions. A useful standard might address field-level extraction accuracy, false-positive and false-negative rates, response latency, escalation frequency, prohibited content, uptime, or performance against a representative test set. The National Institute of Standards and Technology’s voluntary AI Risk Management Framework organizes AI risk work around governance, mapping, measurement, and management. ³ Although the framework is not itself a rule of Michigan contract law, its vocabulary can help parties define performance evidence and continuing oversight. A customer that preserved its baseline, validation data, test protocols, error classifications, model versions, and acceptance results will usually be in a much stronger position than one relying on isolated examples or employee recollections.
The relevant benchmark may also change over time. A model can drift as data, user behavior, operating conditions, or upstream services change. A tool that passed a controlled pilot may perform poorly at production volume or after a vendor update. The contract should be examined for continuing monitoring obligations, regression testing, update notices, retraining commitments, and remedies when performance deteriorates after acceptance. If the agreement measures performance only on the launch date, the customer may have difficulty treating later degradation as an implementation breach unless ongoing service, warranty, or support provisions address it.
The most direct claim usually alleges breach of an express contractual promise. The vendor may have agreed to configure identified workflows, connect specified systems, maintain a particular service level, assign qualified personnel, meet a launch schedule, protect customer data, or correct defects during an acceptance period. The customer must prove more than poor performance. It must show that the performance violated one or more enforceable commitments. Contemporaneous records of missed milestones rejected deliverables, unresolved tickets, failed tests, recurring defects, and requests for correction often carry more weight than a retrospective declaration that the project was a failure.
The vendor will frequently argue that the customer prevented or delayed performance. Implementation contracts commonly require the customer to provide timely data, system access, subject-matter experts, decisions, testing, security approvals, and accurate information about its technical environment. If the customer delivered incomplete data, withheld access, changed internal priorities, or expanded the use case after signing, the vendor may contend that the resulting delay or defect was customer-caused. The customer should therefore examine its own performance candidly. A persuasive claim explains which dependencies were satisfied, which were waived or modified, how the vendor responded at the time, and why the vendor’s material shortfall would have occurred even without any customer-side difficulty.
Change control is often the point at which responsibility becomes blurred. AI projects evolve as the parties learn what the data and workflow actually require. A vendor may characterize an undelivered capability as a new enhancement, while the customer regards it as necessary to the original use case. Signed change orders are the clearest evidence, but backlog records, meeting minutes, revised project plans, statements accompanying additional invoices, and a consistent course of performance may also matter. The legal analysis should focus on the bargain the parties ultimately made and on whether authorized representatives mutually assented to any modification. It should not assume that the first proposal remained unchanged or that every later vendor request automatically became the customer’s obligation.
Acceptance provisions require the same care. Some contracts deem a deliverable accepted if the customer does not reject it within a short period or if the system is placed into production. A customer that continues testing may inadvertently allow an acceptance deadline to expire. Yet acceptance does not necessarily eliminate every warranty, confidentiality, security, or latent-defect claim. The business should identify what was accepted, which reservations were communicated, whether defects were reasonably discoverable, and which obligations survive acceptance. Formal rejection notices should use the contract’s standard and should explain objective nonconformities rather than merely express dissatisfaction.
Some AI transactions are principally services, some are licenses, and others combine software, hardware, implementation, maintenance, and support. Whether Article 2 of Michigan’s Uniform Commercial Code applies can depend on the nature of the transaction and, in a mixed agreement, whether the sale of goods predominates. That classification matters because Article 2 supplies rules concerning express and implied warranties, acceptance, revocation, notice, and remedies. A business should not assume that every software or AI agreement is governed by the UCC, but it should analyze the issue when the transaction includes a substantial product or hardware component.
If Article 2 applies, an affirmation of fact, product description, sample, or model that becomes part of the basis of the bargain may create an express warranty. Implied warranties of merchantability and fitness for a particular purpose may arise in appropriate circumstances unless they are effectively disclaimed. Michigan’s statutory warranty provisions make the exact language and context important.⁴ A contract may disclaim implied warranties, state that outputs can be inaccurate, limit reliance on demonstrations, or require the customer to determine whether the service is suitable for its use. The effect of those clauses depends on their wording, conspicuousness, the transaction’s classification, and the theory being asserted. A carefully worded express promise in a negotiated statement of work may remain important even when standardized terms contain broad general disclaimers.
When a buyer accepts nonconforming goods and gives the notice required by the UCC, Michigan law permits recovery for loss resulting in the ordinary course from the breach and provides a warranty measure based on the difference between the value as accepted and the value as warranted, together with available incidental and consequential damages. The UCC also permits parties to create exclusive or limited remedies. If an exclusive remedy fails of its essential purpose, other statutory remedies may become available, although a consequential-damage exclusion requires its own analysis.⁵ In an unsuccessful AI implementation, this doctrine may matter when the contract limits the customer to repair or replacement, but repeated repair attempts never yield a workable system. It should not, however, be treated as a universal rule that overrides limitations in every software or services agreement.
Sometimes the central misconduct occurred before the contract was signed. A vendor may have represented that the product already possessed a required capability, had been successfully deployed in comparable environments, achieved a stated performance level, complied with a security standard, or could integrate with a named system. If a material representation of existing fact was false and induced the purchase, the customer may consider a misrepresentation or fraudulent-inducement theory. Michigan recognizes remedies for contracts procured through actionable fraud, but a disappointing result does not by itself prove that a sales statement was false when made.⁶
The distinction between an existing fact and a future promise is often decisive. A representation that an integration currently exists or that a test already produced a particular result differs from a prediction that implementation will be completed by a future date. A promise of future conduct generally does not establish fraud merely because it was later broken; additional evidence is ordinarily needed to support an inference that the promisor had no present intention to perform. The claim must also identify the representation with specificity, including its substance, speaker, timing, falsity, materiality, reliance, and resulting injury. Optimistic adjectives and generalized praise may be treated as sales rhetoric, while fabricated test results or false statements about present capability are more concrete.
Contractual disclaimers complicate reliance. An integration clause may say that the written agreement contains the entire bargain, while a nonreliance clause may specifically address statements outside the contract. Those provisions do not grant a license to deceive, but they can narrow the dispute and affect the reasonableness of alleged reliance. The customer should preserve recorded demonstrations, proposals, questionnaires, due-diligence responses, internal approval memoranda, and contemporaneous communications describing why the company selected the product. Those materials can establish whether the challenged statement was a measurable factual representation, whether it was incorporated into the bargain, and whether it actually influenced the decision.
An implementation can fail legally even when the software functions as designed if the vendor mishandles information. Prompts, outputs, uploaded records, fine-tuning materials, embeddings, integration logs, and feedback may contain trade secrets, privileged communications, engineering drawings, customer records, employee information, financial data, or strategic plans. A vendor that uses those materials for generalized model training, sends them to an unauthorized subprocessor, retains them beyond the agreed period, or exposes them in a security incident may breach confidentiality, data-use, security, deletion, and incident-response obligations. The first step is to map the disputed information to the relevant contractual restriction and to determine which entity actually received or controlled it.
Michigan’s Uniform Trade Secrets Act protects qualifying information that derives independent economic value from not being generally known and is subject to reasonable efforts to maintain secrecy.⁷ Contractual controls over access, training, disclosure, retention, and deletion can therefore do two jobs: they create enforceable duties and help show that the owner used reasonable measures to protect its information. If misuse is suspected, the company should promptly identify the affected data, recipients, storage locations, model or dataset involvement, and available deletion mechanisms. Delay can increase both practical harm and the difficulty of showing that emergency relief is necessary.
A security incident may trigger duties beyond the vendor agreement. Michigan’s Identity Theft Protection Act addresses notice following certain breaches involving personal information, and other industry, customer, insurance, or regulatory duties may apply depending on the data and the business.⁸ The contract claim should be coordinated with incident response so that forensic preservation, legal notices, communications, containment, and mitigation remain consistent. An early written demand may seek relevant logs, the identity of subprocessors, forensic findings, evidence-preservation commitments, containment measures, and confirmation of deletion or return. The business should avoid making definitive public statements about cause or scope before the technical record supports them.
Contract damages generally seek to place the injured party in the position it would have occupied had the agreement been performed, subject to causation, foreseeability, reasonable certainty, mitigation, and the contract’s limitations. Michigan law permits lost profits caused by breach when they can be established with a reasonable degree of certainty rather than speculation.⁹ In an AI dispute, potentially recoverable losses may include fees paid for unusable work, reasonable correction or replacement costs, additional implementation expense, data-restoration costs, transition expense, and other losses sufficiently connected to the breach under the governing agreement and law.
The most difficult claims usually involve lost profits, production interruption, delay, lost opportunities, reputational injury, or internal employee time. The vendor may argue that these losses are speculative, unforeseeable, excluded as consequential damages, or attributable to management’s independent decision to rely on an unproven tool. A credible damages analysis begins with business records rather than round numbers created after litigation appears likely. Budgets, invoices, payroll and time records, production data, customer communications, replacement proposals, project forecasts, and board materials may help distinguish an actual economic loss from an anticipated benefit that was never reasonably certain.
Causation can be technically complex because an AI service often sits within a larger chain. Poor results may reflect the model, the vendor’s configuration, an upstream provider, the customer’s data, a third-party integration, or employee use. The same output may have several contributing causes. The business should reconstruct the sequence through version information, configuration records, input data, prompts, outputs, logs, tickets, and controlled testing. Experts may be needed to separate model limitations from implementation defects and to determine whether a proposed alternative would have prevented the loss. A damages model is only as strong as the evidence connecting the vendor’s breach to the claimed economic consequence.
Mitigation begins when the problem becomes apparent. A customer ordinarily cannot permit avoidable losses to accumulate simply to enlarge a claim. Reasonable mitigation may involve suspending a risky deployment, imposing manual review, limiting affected workflows, preserving an alternative system, engaging a replacement provider, or accepting a commercially adequate cure. Mitigation does not require the company to surrender valid rights, accept an unsafe product, or continue paying indefinitely for unsuccessful repairs. Management should document what alternatives were considered, their cost and risk, and why the chosen response was reasonable at the time rather than judged with hindsight.
A strong theory of breach may still produce a limited recovery if the contract caps liability at a modest amount, excludes consequential or special damages, disclaims lost profits and data loss, or makes repair, replacement, refund, or service credits the exclusive remedy. These clauses are often accepted as routine software terms even though the foreseeable cost of a failed implementation can greatly exceed the subscription fee. A serious remedies analysis should begin early by identifying every cap, exclusion, carveout, exclusive-remedy provision, notice condition, and survival clause.
The interaction among the provisions can be more important than any clause in isolation. A general cap may have a higher “supercap” or exception for confidentiality, security incidents, intellectual-property infringement, indemnification, fraud, or willful misconduct. A service-credit clause may be exclusive for uptime failures but not for failure to deliver the implementation. A refund right may cover prepaid subscription fees while leaving transition costs unresolved. Michigan law generally respects freedom of contract and enforces unambiguous risk-allocation provisions as written. ¹⁰ A customer should neither assume that every limitation is enforceable in every circumstance nor expect a court to disregard clear language merely because the economic result is severe.
The UCC concept that a limited remedy may fail of its essential purpose can be important when Article 2 governs and the promised remedy does not provide the substantial value of the bargain. It does not automatically invalidate a separate consequential-damage exclusion, and it should not be imported casually into a pure services agreement. The better analysis considers the transaction’s legal classification, the exact remedial language, the history of attempted cures, and the particular categories of loss. If the cap is tied to fees paid during a short lookback period, timing may also affect the ceiling, making payment records and the asserted breach date significant.
Termination is often the most valuable immediate remedy because it stops further fees and allows the business to redirect resources. Yet the agreement may permit termination for material breach only after written notice and an opportunity to cure. A customer that stops paying or abandons the project without following the specified procedure may invite a counterclaim for remaining committed fees. A compliant notice should identify the breached provisions, describe supporting facts, state the required cure, reserve rights, and follow the contract’s prescribed method and address. Operational communications can remain constructive while formal notice protects the legal position.
Rescission differs from ordinary damages because it seeks to unwind the transaction. It may be considered when a contract was induced by actionable fraud or another recognized equitable ground, but it is discretionary and generally calls for prompt action and restoration of benefits where practicable. A company that continues using the product for a long period after discovering the alleged fraud may face an argument that it affirmed the bargain. The choice among affirming the contract and seeking damages, terminating prospectively, and attempting to rescind should therefore be deliberate and consistent with the company’s communications and conduct.
Injunctive relief may be essential when a vendor is using trade secrets, disclosing confidential information, deleting evidence, or threatening to cut off access to critical customer data. Money damages may not adequately restore secrecy or preserve the ability to transition operations. Courts are generally reluctant to supervise complex ongoing technical performance, so broad specific performance of an AI implementation may be impractical. More targeted relief may be possible, however, such as requiring return of data, preserving evidence, honoring a transition obligation, or stopping a prohibited use. The requested relief should be concrete enough for compliance to be measured and closely tied to the threatened harm.
Some implementation failures expose the customer to claims from people who did not sign the vendor contract. A data incident may generate customer claims and notification expense. Allegedly infringing training data, outputs, or platform components may produce intellectual-property demands. An employment tool may contribute to a discrimination claim, and a system that sends erroneous communications or takes automated action may harm a customer, supplier, employee, or patient. Indemnification provisions determine whether the vendor must defend and reimburse the customer for specified third-party claims; they do not necessarily compensate the customer for its own direct loss.
The indemnity must be read together with exclusions, defense-control provisions, settlement rights, caps, and insurance requirements. A clause may appear broad yet exclude claims arising from customer data, prompts, configurations, combinations, modifications, or use after notice. Those exclusions may encompass the product’s ordinary intended operation. Timely notice is important because the vendor may deny responsibility or assert prejudice if the customer handles the third-party matter without tendering it. The customer should also consider whether the vendor’s insurer has been notified, whether defense counsel presents a conflict, and whether a proposed settlement could restrict the customer’s operations or admit facts affecting the direct contract dispute.
AI evidence can disappear while the parties are still trying to solve the problem. Model versions are replaced, logs roll over, prompts and outputs expire, dashboards update, employees leave, and online documentation is revised. The business should preserve the materials needed to reconstruct performance, including contracts, policies, model and software versions, configurations, prompts, outputs, source materials, validation datasets, error reports, tickets, system and access logs, meeting notes, demonstrations, sales communications, invoices, and internal decisions. Screenshots may help, but they are often insufficient when underlying data, timestamps, metadata, or machine-readable logs are available.
Preservation should extend to relevant employee communications and to information controlled by the vendor or other providers. Once litigation is reasonably anticipated, counsel can help define a proportionate legal hold and send a focused preservation demand. The company should avoid informal experiments that overwrite logs or change configurations without recording the change. It should also separate privileged legal analysis from ordinary operational communications and discourage unsupported speculation about blame. Preserving evidence does not mean freezing the business in place; it means making defensible copies before systems are repaired, replaced, or decommissioned.
Many disputes can still be resolved during the cure period. A useful notice does more than declare that the project failed. It identifies the contractual standard, describes objective deviations, summarizes prior cure attempts, states what must be delivered, and provides the required deadline. Depending on the circumstances, it may request a remediation plan, experienced personnel, controlled testing, additional security measures, fee adjustments, or transition assistance. If continued performance remains possible, the parties can adopt a revised schedule while stating expressly that cooperation does not waive existing claims or extend acceptance by implication.
If cure is unrealistic, an early commercial exit may preserve more value than prolonged technical and legal conflict. A negotiated resolution can address refunds, unpaid invoices, data return, deletion certification, transition support, customer and employee communications, confidentiality, releases, insurance, and responsibility for third-party claims. The company should compare the expected net recovery from litigation with cost, operational distraction, technical uncertainty, collection risk, and the need to restore a functioning process. That analysis is most reliable after counsel and the project team have evaluated the contract, evidence, damages, defenses, and available insurance rather than reacting to frustration alone.
When an AI project goes wrong, the most effective response neither treats the technology as uniquely mysterious nor reduces the dispute to an ordinary software complaint. Traditional contract questions still control, but AI-specific evidence makes them harder to answer. The business must identify the promised performance, the system and model versions involved, the data and dependencies that affected results, the customer obligations that were satisfied or missed, the notice and cure history, the resulting losses, and the contractual rules governing recovery. This translation turns an amorphous implementation failure into a dispute that can be investigated, valued, and managed.
The strongest legal position is usually built before implementation through precise scope, representative testing, measurable acceptance criteria, disciplined change control, restricted data use, meaningful security and audit obligations, workable cure procedures, balanced liability terms, and a planned exit. When those protections are missing, prompt preservation and exact contract analysis become even more important. AI does not displace Michigan contract law, but it can complicate proof because performance varies, products change, and responsibility is distributed among the vendor, model provider, cloud provider, data sources, integrations, and the customer’s personnel.
A failed AI implementation may support claims for breach of express promises, warranty violations, fraudulent inducement, misuse of confidential information, security failures, or indemnification. The label “AI failure,” however, does not determine the remedy. The governing documents, performance evidence, causation, damages, notice procedures, and negotiated risk limitations do. Michigan businesses should act quickly enough to preserve evidence and protect operations, but carefully enough to avoid waiving a remedy, accepting a defective deliverable, or creating a counterclaim through premature termination.
The central commercial principle is straightforward: responsibility should follow contractual obligation and practical control. A vendor that controls the model, implementation method, subprocessors, security environment, and product changes should not be insulated from every consequence of failures in those areas. The customer remains responsible for its own data, personnel, decisions, dependencies, and final use of the output. A well-supported claim identifies that boundary, proves how it was crossed, and seeks a remedy proportionate to the resulting harm.
This article is intended for general informational purposes and does not constitute legal advice. Contract claims and remedies depend on the language of the specific agreement, the transaction, the technology, the available evidence, and the surrounding circumstances. A business confronting an actual or threatened dispute should obtain advice based on the complete record and should act promptly to preserve rights and evidence.
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).
Footnoted Sources:
1. Miller-Davis Co. v. Ahrens Construction, Inc., 495 Mich. 161, 178; 848 N.W.2d 95 (2014). https://www.lexology.com/library/detail.aspx?g=cc6e05cb-6bdd-4348-8dd1-8dc6c6081973
2. Innovation Ventures, LLC v. Liquid Manufacturing, LLC, 499 Mich. 491; 885 N.W.2d 861 (2016). https://www.govinfo.gov/content/pkg/USCOURTS-mied-2_22-cv-12433/pdf/USCOURTS-mied-2_22-cv-12433-2.pdf
3. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (January 2023). https://www.govinfo.gov/content/pkg/USCOURTS-mied-2_22-cv-12433/pdf/USCOURTS-mied-2_22-cv-12433-2.pdf
4. Michigan Compiled Laws §§ 440.2313, 440.2314, and 440.2315. https://legislature.mi.gov/documents/mcl/pdf/mcl-chap440.pdf
5. Michigan Compiled Laws §§ 440.2714, 440.2715, and 440.2719. https://legislature.mi.gov/Laws/MCL?objectName=mcl-440-2714
6. Titan Insurance Co. v. Hyten, 491 Mich. 547; 817 N.W.2d 562 (2012). https://case-law.vlex.com/vid/titan-ins-co-v-890983141
7. Michigan Uniform Trade Secrets Act, Michigan Compiled Laws § 445.1901 et seq. https://www.legislature.mi.gov/Laws/MCL?objectName=mcl-445-1901
8. Michigan Identity Theft Protection Act, Michigan Compiled Laws § 445.61 et seq., including § 445.72. https://www.legislature.mi.gov/Laws/MCL?objectName=MCL-445-61
9. Lawrence v. Will Darrah & Associates, Inc., 445 Mich. 1; 516 N.W.2d 43 (1994). https://www.plainsite.org/cases/index.html?table=reporter&reporter=mich&volume=445
10. Rory v. Continental Insurance Co., 473 Mich. 457; 703 N.W.2d https://www.michbar.org/file/opinions/appeals/2006/062006/32148.pdf