The liability clause she had already signed did not say what she thought

The situation

Mihaela realized something was wrong on a Sunday evening, three weeks after she had signed up for the tool, when she finally sat down to read the full terms of service instead of skimming past them on the setup screen. Her stomach dropped somewhere around the fourth paragraph of a section titled ‘Limitation of Liability,’ and she read it twice more before deciding it was not simply her misunderstanding the wording.

Mihaela worked as a warehouse worker during the day, and had spent the past two years building a small side business coordinating delivery schedules and route planning for a handful of local trucking clients, working evenings and weekends around her shifts. Her business partner, Soraya, drove long-haul routes for a separate carrier and had put money into the venture early on as a silent investor, staying out of day-to-day decisions almost entirely but holding a real financial stake in how the company performed and a real interest in not losing it. The business had grown from a favour done for one client into something closer to real, with revenue approaching one hundred thousand dollars a year, still modest but no longer a side hustle in any meaningful sense of the word.

The scheduling work had become the bottleneck limiting how much further the business could grow. Mihaela was spending several hours each week manually juggling driver availability, delivery windows, and last-minute changes across several clients' fleets, often late at night after her warehouse shift ended. A fellow small business owner had recommended an AI-powered scheduling platform that promised to automate most of that manual coordination. Mihaela signed up during a free trial, clicked through the onboarding screens, and agreed to the platform's standard terms without reading past the pricing section, assuming, as most people reasonably do under time pressure, that the fine print was boilerplate she had seen a hundred times before.

It was not boilerplate. The vendor, a company run by a man named Zoltan, had written a liability clause that went well beyond the usual limits on consequential damages common in software contracts. It disclaimed responsibility for essentially any error the AI tool made, including scheduling mistakes that caused a client's delivery to be missed entirely, and it stated that the platform's outputs should always be independently verified by the user before being relied upon for any business-critical decision — a requirement that, if taken seriously and literally, undercut much of the reason to adopt the tool in the first place.

What was actually at stake

Mihaela called our office describing the problem as one about a contract clause, but the real question underneath it was about what would actually happen the first time the tool got something wrong while managing a live client's delivery schedule, and who would be left holding the cost when it did.

When a business brings in an AI tool to make decisions or recommendations that a person used to make, it is stepping into a newer and less settled area of contract risk than most owners realize at signing. The vendor's terms typically try to shift as much responsibility as possible onto the customer, on the theory that the tool is a decision-support aid rather than a guarantee, and that the human user remains responsible for checking its output before acting on it. That framing is not unreasonable in principle. It becomes a serious problem, though, when the contract disclaims liability so broadly that the business using the tool absorbs essentially all of the downside if the tool fails, while the vendor absorbs almost none of it, regardless of whether the failure was foreseeable, preventable, or entirely the vendor's own doing.

In Mihaela's case, the exposure was concrete rather than theoretical. If the scheduling tool double-booked a driver, or missed a delivery window because of a data error in how it processed a client's stated constraints, the resulting cost — a missed shipment, a damaged client relationship, potentially a penalty clause already sitting inside one of her own client contracts — would land entirely on Mihaela's business under the terms as signed. The tool's error would be treated, under the vendor's own contract, as something Mihaela should have caught and prevented herself, since she had already agreed that every output required independent verification before use.

There was also a second, quieter problem sitting underneath the first one. Because Mihaela had already signed the agreement and begun onboarding real client data into the platform before raising any concern, some of her own client information was sitting on a third-party vendor's system under terms nobody at her business had actually reviewed for data handling, storage, or deletion either. The liability clause was the most urgent issue on the table, but it was really a symptom of a broader pattern: the business had adopted a new tool the way it might adopt a new pen, clicking through rather than treating the contract as something that needed review before use began, not after it was already underway with real client data attached.

What we did

1. Read the full agreement Mihaela had already signed — we reviewed the entire terms of service and any separate order form or onboarding agreement, not just the liability section she had already flagged, to understand the complete picture of what she had actually agreed to and where the real exposure sat. A single clause rarely tells the whole story on its own, and in this case the data handling terms elsewhere in the same document turned out to matter almost as much as the one she had called about.
2. Assessed whether the tool had touched real client work yet — we confirmed with Mihaela, in careful detail, whether any scheduling decisions generated by the tool had already been acted on for an actual client delivery, or whether it had so far only been tested on dummy data during the trial period. The urgency and the negotiating posture were very different depending on the answer, since exposure that is still purely theoretical is a far easier position to renegotiate from than exposure already sitting on a live account.
3. Paused the tool's use on live client scheduling — we advised Mihaela to stop relying on the platform's output for any active client work immediately, reverting to her manual scheduling process temporarily even though it meant late nights again, so that no further exposure accumulated on real deliveries while the contract terms were being renegotiated behind the scenes. A short-term inconvenience was a small price against the risk of a live error happening mid-negotiation.
4. Identified the specific terms worth fighting for — rather than demand the vendor remove its liability disclaimer entirely, which was unlikely to succeed against a company with a standard-form contract used across many customers, we prioritized a narrower set of changes: a cap on Mihaela's own exposure, a clear allocation of responsibility for data errors originating on the vendor's side, and a defined process for reporting and correcting tool errors.
5. Opened direct negotiation with Zoltan's company — we contacted the vendor's team directly, framing the request not as a legal threat but as a reasonable ask from a small customer who wanted to keep using the product responsibly and stay a customer, not walk away from it. That framing is often a more productive opening than an adversarial demand letter when the business genuinely wants the relationship to keep working, rather than simply wanting to win a single point on paper.
6. Reviewed the data handling terms alongside the liability clause — since client scheduling data was already sitting on the platform by the time we were retained, we checked what the contract said about data ownership, deletion on termination, and the vendor's own security obligations, not only about liability for errors. We flagged two real gaps in that coverage and raised them in the same conversation as the liability terms, rather than letting them sit as a separate problem for another day.
7. Negotiated a revised addendum before resuming full use — we worked through several rounds of changes with the vendor's team over a few weeks, trading proposed language back and forth, and landed on amended terms that capped Mihaela's liability for tool-driven scheduling errors at a defined amount and clarified the vendor's own obligations for data it stored on her behalf. Only once that addendum was signed did Mihaela resume using the platform for live client scheduling.
8. Set up an internal contract-review habit for the business — we gave Mihaela and Soraya a short checklist for any future software or vendor agreement, covering liability, data handling, and termination terms, and a simple rule: no new tool touches real client work until someone has actually read the contract, not skimmed it. The goal was to make sure the next tool the business adopts gets reviewed before it goes live, not weeks after, the way this one was.

The outcome

Zoltan's company did not agree to remove its liability disclaimer, and it made clear early in the negotiation that its standard terms applied to every customer on the platform, not just to Mihaela's business. That position held throughout and was never seriously in doubt. What changed was the scope of it: the revised addendum capped Mihaela's exposure for tool-driven scheduling errors at a defined, modest dollar amount rather than leaving it open-ended, and it added a written commitment that data errors originating from a flaw in the vendor's own system would be the vendor's responsibility to correct and, where it caused a direct measurable loss, to cover up to that same capped amount.

It was not the outcome Mihaela had hoped for when she first called, which was closer to having the disclaimer disappear from the contract altogether. She and Soraya were candid that accepting a capped, shared-risk arrangement instead of full protection felt like giving up real ground, and it genuinely was a compromise rather than a clean win. But it reflected the actual leverage available to a business their size: a small customer negotiating against a vendor with many other customers bound by the same standard terms was never going to rewrite the contract entirely in its favour, and pushing harder risked the vendor simply declining to negotiate at all.

The tool went live on real client scheduling about five weeks after Mihaela's original signature, operating under the revised terms, and it has run without a significant incident since. The business now treats every new software agreement as something to review carefully before adoption, a habit that started, somewhat uncomfortably, with one Sunday evening spent finally reading a contract she had already signed weeks earlier. Soraya, for her part, now asks to see any vendor contract before Mihaela signs it.

What you can learn from this