The Only Control That Binds The Vendor

A Canadian firm signs an AI subscription the way it signs any software subscription, which is to say quickly and on the vendor's paper. Two years later, at renewal, it discovers which of those terms were load-bearing.

What This Article Is

A necessary framing before anything else.

This publication is written by an accounting and advisory practice, not a law firm. Nothing here is legal advice, no clause below should be adopted without counsel, and the sources cited are legal commentary rather than legal opinion addressed to any reader.

What this article can usefully do is different and, we think, valuable. A Canadian business owner who understands which questions are commercially significant will get better value from an hour of a lawyer's time, and will not spend it discovering that the training data clause matters.

So the output here is a set of questions to take to counsel, with enough context to explain why each one is on the list, and one Canadian jurisdictional point that a general commentary will not surface.

The Only Control That Reaches Them

The observation that positions this article within the series, and it is our own.

Consider what the preceding articles recommended. Scheduled regression runs, execution logging, correlation identifiers, approval gates outside the model, per-task cost ceilings, abstraction layers, unassisted capability checks. Every one of those is a control the buying firm imposes on itself, at its own cost, to manage a risk created elsewhere.

None of them reaches the vendor. A firm cannot log its way to being told about a model change, cannot instrument its way into owning its outputs, and cannot architect its way out of a liability cap.

One source puts the point in operational terms: AI changes the procurement risk surface, because data may be reused in unexpected ways, outputs may affect customers and employees, and models can change after signature. Its rule is that AI risk starts before the first prompt, inside the contract[1].

That is the correct sequencing and it is the opposite of what most firms do. The technical controls get built after deployment, when the exposure is visible. The contractual controls have to be secured before signature, when the exposure is theoretical and the leverage exists.

The leverage point matters. A buyer has commercial leverage exactly once, before signing, and again at renewal. In between, the vendor's incentives are unchanged by anything the buyer builds internally.

The Liability Asymmetry

The commercial fact that should govern how seriously a professional firm takes this.

One source describes the standard position: limitation of liability provisions in many AI vendor contracts disclaim indirect, incidental and consequential damages, cap liability at tool fees, and deny indemnity for IP infringement[2].

The same source gives a scenario in which a service company issued an AI-generated deliverable containing an unsubstantiated regulatory compliance claim, and when the client faced penalties, the vendor's liability limitations left the service company responsible for all damages and costs[2].

Set the two sides of that arrangement beside each other, which is our own analysis.

The vendor's maximum exposure is what the firm paid for the tool, which for a mid-sized Canadian practice might be a few thousand dollars a month. The firm's exposure is whatever its client suffers, which is bounded by the client's loss and by the firm's professional liability position rather than by anything in the software agreement.

Those two numbers are not comparable and are frequently not within an order of magnitude of each other. The risk allocation in a standard AI subscription places nearly all of the downside on the party with the least ability to control the model's behaviour.

That is not an argument against using the tools. It is an argument that the professional liability question, which the next article in this series addresses, cannot be answered by pointing at a vendor agreement, because the agreement has been drafted specifically to prevent that.

Why Templates Do Not Cover This

The reason a firm's existing software agreement checklist is inadequate.

One practitioner guide states that AI vendor contracts are not standard procurement, because they involve risks traditional contract templates were never built for, naming data training that can compromise confidentiality and outputs that hallucinate[3].

Another lists what changed: AI is embedded into core operations across support, marketing, finance, human resources, fraud and analytics; models update continuously, so what you buy today can change next month, affecting accuracy, cost and risk; and evidence expectations have increased, with partners and enterprise customers now asking for vendor terms, security posture and governance controls as part of due diligence[1].

The middle item is the one this series has documented from several directions. A conventional software agreement contemplates a product that is fixed except when the parties agree to change it. An AI service is a product that changes without the parties agreeing to anything, which is a materially different thing to be buying.

The third item deserves attention from Canadian professional firms specifically. Client due diligence is now reaching vendor terms, which means a firm's AI contracts are becoming an asset or a liability in its own sales process, not merely an internal procurement matter.

The Clause That Did Not Exist

The provision that has moved fastest, with a clear statement of the buyer position.

One source records that this clause did not exist in pre-2024 templates and now sits among the most-negotiated clauses on any deal touching an AI feature, on a level with liability and indemnity. It frames the threshold question as consent: does the vendor have the buyer's authorisation to use customer data to train AI models, including foundation models the vendor licenses from a third party. It states the standard buyer position as opt-out at minimum, opt-in for any model training, and a contractual prohibition on using customer data for any non-customer-facing model improvement, with the fallback when a vendor refuses being zero-retention processing, meaning the vendor processes the data to generate output and does not retain it for training[4].

That is the clearest articulation of a negotiating ladder we found, and it is directly usable: opt-in, failing that opt-out, failing that zero retention.

For a Canadian accounting or advisory firm the stakes are higher than for most buyers, because the data in question is client confidential information held under professional obligations, and in many cases privileged or subject to statutory confidentiality.

The relevant question is therefore not only whether the firm consents. It is whether the firm is entitled to consent on its clients' behalf, which is a question about the firm's own engagement terms rather than about the vendor's.

Our observation is that many Canadian firms have adopted AI tools without checking whether their client engagement letters permit disclosure of client information to a third-party processor for that purpose. That is a gap on the firm's side of the arrangement, and it is not fixed by anything in the vendor contract.

The Sub-Processor Chain

A detail in that formulation that is easy to read past and that matters considerably.

The consent question is framed as covering foundation models the vendor licenses from a third party[4]. Another source lists among its required clauses a full list of sub-processors and processing locations[5].

The structure this describes is that a Canadian firm's data frequently reaches a model operated by an organisation the firm has never contracted with, never assessed and possibly cannot name.

The typical chain has three links. The firm contracts with a software vendor. The vendor licenses a model from a foundation model provider. That provider may itself host on infrastructure belonging to a fourth party.

A confidentiality commitment given by the first link is worth what the chain beneath it supports. If the vendor's own agreement with its model provider permits retention or training, the vendor cannot honour a stricter promise to its customer regardless of what it signs.

The practical ask is therefore not a warranty but disclosure: who processes the data, where, under what terms, and what happens when the vendor changes that arrangement. The last part matters because sub-processor changes are typically made unilaterally with notice, if notice is given at all.

Indemnity And The Qualifier That Guts It

The protection most commonly absent, and a drafting trap worth recognising.

One Canadian source reports that a 2026 industry scan found only about 33 percent of AI vendors offer IP indemnification by default, so it is usually something a buyer must ask for[5]. We report that figure as stated; it reaches us at second hand and the underlying scan was not accessed.

A practitioner guide offers model language in which the vendor defends and indemnifies the customer against third-party claims that the service, used in accordance with the agreement and documentation, infringes any third-party intellectual property right, to the best of Vendor's knowledge[3].

That closing qualifier is worth pausing on, and this observation is our own. An indemnity limited to the best of the indemnifier's knowledge is substantially narrower than an unqualified one, because it converts a risk allocation into a representation about the vendor's state of mind. A vendor unaware of an infringement claim has, on that wording, a defence to the indemnity itself.

We are not lawyers and cannot advise on the effect of any particular wording. We flag it because the qualifier is easy to read past and because a buyer who believes they have obtained an indemnity may have obtained something considerably less.

The same guide offers a negotiating line worth borrowing: that a competitor provides output-level indemnification, that equivalent protection is expected, and that if it cannot be provided the buyer needs to understand why, because its risk assessment of the tool changes significantly[3].

Another source's redline position is broader: explicit customer ownership of customer-derived output, vendor indemnification against third-party IP claims subject to documented use within agreed parameters, and a defined notification and defence protocol when claims arise[6].

Notice Of Model Change

The provision this series has arrived at repeatedly from technical directions, stated here as the procurement ask.

The drift article established that providers ship silent updates and that the model answering in one month may not be the one that answered previously. The lock-in article argued that where a firm's prompts and thresholds are tuned to a specific version, such an update imposes the costs of a migration without granting the choice of one. One source here confirms the commercial framing: models update continuously, and what you buy today can change next month, affecting accuracy, cost and risk[1].

There is no technical control for this. A firm can detect a change after the fact through scheduled regression testing, which is worth doing, and detection is not notice.

The only mechanism that converts a silent update into a managed event is a contractual right to be told in advance, and this is our own conclusion rather than a recommendation we found stated in these sources.

Three variants are worth asking about, in descending order of what a mid-market buyer is likely to obtain: advance notice of material changes to the underlying model; the ability to pin a version for a defined period; and a right to terminate without penalty if a change materially degrades performance against agreed measures.

The third is the most valuable and the least likely to be granted, because it requires the agreed measures discussed below. It is also the provision that most directly addresses the asymmetry, since it gives the buyer an option that the vendor's unilateral change would otherwise extinguish.

An SLA That Measures The Right Thing

The service level problem, stated well by the practitioner guide.

It observes that traditional service levels measure uptime and response time, while an AI service level needs to measure something fundamentally different, being the quality and reliability of outputs that change every time the model runs, and that acceptable performance must be defined in measurable terms[3].

The difficulty is obvious and worth naming. Uptime is a property of the service that both parties can observe identically. Output quality is a judgment about work product, on a task that is specific to the buyer, using criteria the vendor did not write.

That is why most AI agreements do not contain a meaningful quality service level: not because vendors refuse, though some do, but because neither party has an agreed instrument for measuring the thing.

Which is precisely what the next two sections address, and it is the reason the pilot matters more in AI procurement than in ordinary software procurement.

The Pilot As Evidence

A reframing of the pilot that a Canadian firm should adopt.

The practitioner guide recommends structuring a pilot agreement to include a defined scope of use, performance metrics the buyer will measure, a clear path to the full agreement if metrics are met, and the right to terminate without penalty if they are not. It states that the pilot also gives data on the vendor's actual performance, strengthening the buyer's negotiating position for the full contract, and that the pilot is not a concession but a way to de-risk the deal for both sides while building the data. Critically, it notes that the pilot metrics become the service level metrics in the full agreement[3].

That last mechanism is the useful one, and it solves the measurement problem above.

A pilot run against defined metrics produces two things simultaneously: a decision about whether to proceed, and a mutually observed body of evidence about what the system actually achieves on this buyer's work. The second is what makes a quality service level draftable, because both parties have seen the number.

This also corrects the way most Canadian firms run pilots, which the earlier article on total cost noted is as a demonstration rather than as a measurement. A pilot whose output is an impression produces no negotiating leverage. A pilot whose output is a measured performance level on defined tasks produces a service level.

The framing that the pilot is not a concession is worth carrying into the conversation, because vendors frequently present a pilot as a favour and price the full agreement as though the buyer had already committed.

The Evaluation Set, Fifth Use

Completing an argument this series has built across five articles.

The private evaluation set, built from a firm's own closed files, was first recommended because published benchmark scores are contaminated and cannot support a procurement decision. It then proved to be the only instrument that detects a provider changing behaviour underneath a validated workflow. It is what establishes which model tier is sufficient for which task class, and therefore what makes cost routing possible. It is what makes a migration decision testable.

Here it becomes the fifth thing: the measurement instrument that makes a quality service level draftable, and the evidence base for the pilot-to-SLA pipeline above.

We would put the conclusion plainly for a Canadian firm weighing whether to build one. A single artefact, assembled from files the firm already holds, is the precondition for procurement evidence, drift detection, cost routing, migration testing and contractual quality measurement.

There is no other investment in this entire subject with a comparable ratio of cost to number of problems addressed, and the reason it is rarely built is that no single one of the five problems is anyone's job.

The Rate Card And Fair Use

The commercial terms that carry the cost risk, which sit alongside the unit economics discussed earlier in this series.

One source describes the prevailing structure: most agentic AI commercial contracts are token-metered with enterprise minimum commitments and discount tiers layered on top, and states that the risk is not the published rate but the vendor's reserved right to revise the rate card on advance notice, and fair use definitions that reset on renewal[6].

Both of those interact badly with findings from the inference economics article.

A reserved right to revise the rate card, combined with consumption that rises as quality levers are added, means a buyer's exposure is the product of two variables the vendor influences and the buyer does not fully control. The published price at signature constrains neither.

Fair use definitions that reset on renewal are the more insidious of the two, because a buyer whose usage grew during the term discovers at renewal that the growth is now priced differently. That is the same renewal-time discovery the next section describes.

The questions worth putting are narrow and answerable: what notice applies to a rate change, is there a ceiling on increases during a term, what happens if usage exceeds a fair use threshold, and does the threshold reset. None requires legal expertise to ask, and all four determine the cost forecast.

The Quebec Position

The only concrete Canadian statutory content in this area, and it is worth setting out precisely.

A Quebec law firm describes the contract as where a Quebec small or medium business operationalises Law 25. It identifies section 17 cross-border rules as requiring data-location transparency and a written transfer agreement, section 12.1 automated-decision rules as requiring the vendor to give the customer the explanation factors, and the breach-notification clock as needing to be fast enough to meet the duty to inform the Commission d'accès à l'information and affected individuals with diligence[5].

Its clause list follows from those: an IP-infringement indemnity; security and breach notification covering encryption, access controls, a recognised security certification and a notice timeline tight enough for the diligence duty; sub-processor and data-location transparency sufficient for the cross-border assessment; a regulatory compliance covenant; and explainability support, meaning the vendor provides the factors the customer needs to satisfy its automated-decision explanation duties[5].

We report this as the source states it and note we have not verified the provisions against the statute; a Quebec business should take this to Quebec counsel.

The structural point is the one worth extracting. Two of those obligations, cross-border transfer assessment and automated-decision explanation, are duties the business owes, and neither can be discharged without information only the vendor holds. So the contract is not merely risk allocation; it is the mechanism by which a Quebec business obtains the inputs required to comply with its own obligations.

A Refinement To What We Said Earlier

A correction this publication owes its readers, stated openly.

Earlier articles in this series characterised Canada as having no general statutory requirement for human oversight or explanation of AI-assisted decisions, and contrasted that with foreign regimes. That characterisation was accurate as far as it went and it was insufficiently precise about Quebec.

On the account above, Quebec's Law 25 contains an automated-decision provision requiring that explanation factors be available[5], which is a concrete Canadian obligation of a kind we described as absent.

The accurate position, as best we can state it, is that Canada has no general federal AI statute and no general private-sector automated-decision requirement, and that Quebec is the exception within Canada, with Law 25 imposing automated-decision and cross-border transfer duties that other provinces do not.

Two consequences follow for readers of the earlier articles. A Quebec business should not read this publication's general Canadian statements as describing its position. And a business outside Quebec with Quebec clients or Quebec-resident individuals' personal information may find the provincial regime relevant regardless of where it is established, which is a question for counsel rather than for us.

We would rather correct this in the open than let the earlier framing stand, and readers should treat the general Canadian statements elsewhere in this series as subject to it.

Outside Quebec

What applies to the rest of the country, offered as our own analysis and expressly not as legal advice.

A business elsewhere in Canada handling personal information remains subject to federal or provincial private-sector privacy law, which applies to AI processing as it does to any other processing, and which is the source of most of the concrete contractual obligations such a business will have.

Beyond privacy, the operative constraints are not statutory but professional and contractual: the duties a firm owes its clients under its engagement terms and its professional body's rules, and whatever it has promised its own customers about confidentiality and data handling.

Those are frequently stricter than anything a general commentary will identify, and they are the ones most likely to be breached by an unconsidered AI adoption.

The practical consequence is that a non-Quebec Canadian firm's contract review should start from its own outbound commitments rather than from a statutory checklist. The question is not what the law requires of the vendor, but whether the vendor's terms allow the firm to keep the promises it has already made.

No Security Breach Occurred

A scenario worth reading closely, because it describes a failure mode with no technical fault.

One source describes a services company implementing an AI support assistant integrated into its helpdesk. Staff begin pasting screenshots into the tool to speed up ticket resolution, and those screenshots include customer identifiers, account details and internal notes. A customer subsequently complains after receiving a response revealing information that should not have been shared. The source states plainly that no security breach occurred, and that the business faces a confidentiality issue, a data protection question about what data was processed and under what terms, and commercial risk as clients begin asking for vendor due diligence evidence[1].

The structure is the same one the segregation of duties article identified in a different context. Nothing malfunctioned, no rule was broken, no attacker was involved, and real harm followed.

What went wrong is that the scope of what employees fed into the tool was never defined, and the contractual terms governing that data were never assessed against what employees would in fact do.

The lesson for a Canadian professional firm is that the contract has to be matched to actual use rather than to intended use. A term permitting processing of the data the firm meant to submit is no protection where staff submit something broader, and staff will submit whatever makes the work easier unless told otherwise.

That makes an acceptable use policy a contractual necessity rather than an internal nicety, because it is what aligns the firm's behaviour with the terms it obtained.

Renewal Is The Test

The timing point, and the reason this article is more urgent than it looks.

One source observes that the procurement community has been catching up with agentic AI contract grammar for two years, that professional bodies have published redline templates over that period, and that what is new is that the templates are being tested at renewal time, with customers who signed without redlines in 2024 now discovering which clauses bound them[6].

Renewal is also the only other moment at which a buyer has leverage, and it is a better moment than the original signature in one respect: the buyer now has usage data, performance experience and a clear view of what the tool is worth.

Our recommendation for a Canadian firm is to treat the first renewal of any AI agreement as a genuine negotiation rather than an administrative rollover, and to prepare for it during the term rather than in the month before.

Preparation means the things this series has described: measured performance on the firm's own evaluation set, recorded consumption and cost per task, a documented list of what the firm has become dependent on, and a clear answer to what the workflow degrades to without the tool.

A buyer who arrives at renewal with those four things is negotiating from evidence. A buyer who arrives with an invoice and a general impression is not negotiating at all.

A Worked Case: Capped At The Subscription

A Canadian advisory firm using an AI tool in client deliverables. The reconstruction illustrates the allocation rather than reporting a specific matter.

The firm signed a standard subscription. On the reported pattern, the agreement disclaims consequential damages, caps liability at fees paid, and contains no IP indemnity[2], the last being the default position for roughly two thirds of vendors on the figure reported[5].

An AI-assisted deliverable contains an incorrect assertion. The client relies on it and suffers a loss. The firm's exposure runs to the client's damages and its professional position; the vendor's exposure runs to the subscription fees.

Separately, staff have been submitting client documents to the tool. Whether the firm was entitled to do so depends on its engagement letters, not on the vendor agreement, and nobody checked.

The vendor updated the model during the term without notice, which the firm detected only because a figure looked wrong, and it has no contractual remedy because it never asked for one.

At renewal the firm has no measured performance data, no cost per task, and no documented dependency list, so it accepts the new rate card and the reset fair use threshold[6].

Every one of those outcomes was determined before the tool was ever used, by terms nobody read and questions nobody asked.

What To Take To Counsel

The questions, framed as an agenda rather than as drafting.

What is the liability cap and what does it exclude? Compare it against your exposure to your own clients, not against the subscription price.

Is there an IP indemnity, and is it qualified? A knowledge qualifier narrows it substantially, and roughly two thirds of vendors are reported not to offer one by default.

Can our data be used for model training? Ladder: opt-in, failing that opt-out, failing that zero-retention processing.

Are we entitled to submit client data at all? This is a question about your engagement letters, not the vendor's terms, and it is on your side of the arrangement.

Who are the sub-processors, where are they, and what governs changes? Your data likely reaches a model you never contracted with.

What notice applies to material model changes, and can we pin a version? This is the only remedy for silent updates, and there is no technical substitute.

What does the service level actually measure? Uptime is not the risk; output quality is, and it needs a defined measure.

Can the rate card change, and does fair use reset at renewal? Ask for a ceiling on in-term increases.

What is returned on termination, in what format, and by when? Including derived artefacts such as embeddings and any tuned model.

If we are in Quebec, does this contract give us what Law 25 requires us to have? Cross-border transparency and automated-decision explanation factors are duties you owe, discharged with information only the vendor holds.

The Limits Of This Analysis

Several caveats matter, and the first is that nothing here is legal advice and this publication is not a law firm. Sources are legal commentary and vendor-adjacent publications rather than legal opinions addressed to any reader, and several are published by firms selling contract review services or software. The reported figure that about a third of AI vendors offer IP indemnification by default reaches us at second hand from a 2026 industry scan we did not access. Model clause language quoted is illustrative and should not be adopted without counsel; we have flagged one qualifier as narrowing but express no view on its legal effect. Our description of Quebec's Law 25 provisions is taken from a Quebec law firm's commentary and has not been verified against the statute, and Quebec businesses should take it to Quebec counsel. Scenarios described in sources are presented by those sources as illustrative and were not independently verified. The liability asymmetry argument, the sub-processor chain analysis, the notice-of-change ask, the pilot-to-service-level reasoning, the evaluation set synthesis, the entitlement-to-consent point about engagement letters, the renewal preparation list and the worked case are our own analysis. This article does not address competition law, public sector procurement rules, employment implications, cross-border tax, or professional liability, which the next article in this series treats separately. Nothing here is a substitute for advice from qualified counsel on a specific agreement.

Related Reading

AI & Automation In Finance Trapped By Weights You Do Not Control Why notice of model change is the contractual remedy for a problem with no technical fix. Compliance & Reporting The Log Is The Obligation The Quebec and federal privacy duties that a vendor's breach notice timeline has to be fast enough to serve. AI & Automation In Finance Silence Is Not Coverage Most professional liability policies predate AI and do not mention it. That produces ambiguity rather than coverage, and the ambiguity is resolved by...

Frequently Asked Questions

Why does the contract matter more than our internal controls?

Because every technical control binds the firm that builds it. Logging, regression testing, approval gates and cost ceilings all manage a risk created elsewhere, and none of them reaches the vendor. The contract is the only instrument that does, and the leverage to secure it exists at signature and at renewal, not in between.

What is the standard liability position?

Commentary reports that many AI vendor contracts disclaim indirect, incidental and consequential damages, cap liability at tool fees, and deny IP indemnity. For a professional firm that means the vendor's maximum exposure is the subscription price while yours is whatever your client suffers, and those numbers are frequently not within an order of magnitude.

What should we ask about training on our data?

Work down a ladder: opt-in for any model training, failing that opt-out, failing that zero-retention processing where the vendor generates output and retains nothing for training. Note the consent question extends to foundation models the vendor licenses from a third party, so ask who the sub-processors are and what governs changes to them.

Is there anything specifically Canadian here?

Quebec. Law 25 is reported to include cross-border transfer rules requiring data-location transparency and a written transfer agreement, and automated-decision rules requiring that explanation factors be available. Both are duties the business owes and neither can be discharged without information only the vendor holds, which makes the contract the compliance mechanism. No equivalent applies elsewhere in Canada.

How do we get a meaningful service level?

Through the pilot. Traditional service levels measure uptime, while an AI service level has to measure output quality that changes every run, and neither party can draft that without an agreed measurement. A pilot run against defined metrics on your own work produces the evidence, and those pilot metrics become the service level metrics in the full agreement.

When should we revisit an agreement we already signed?

At the first renewal, treated as a real negotiation rather than a rollover. Commentary notes that customers who signed without redlines are now discovering at renewal which clauses bound them. Prepare during the term: measured performance on your own evaluation set, cost per task, a documented dependency list, and a clear answer to what the workflow degrades to without the tool.

References

1. MN Legal. (2026, February 5). AI Vendor Contracts: Key Clauses to Demand in 2026, on AI changing the procurement risk surface through unexpected data reuse, outputs affecting customers and employees, and models changing after signature; the rule that AI risk starts inside the contract; continuous model updates altering accuracy, cost and risk; increased evidence expectations in customer due diligence; and the helpdesk scenario in which no security breach occurred yet confidentiality, data protection and commercial risks followed. Note: a law firm publication in a non-Canadian jurisdiction; general commentary rather than advice. mnlegal.net/insights/ai-vendor-contracts-key-clauses-to-demand-in-2026
2. Gouchev Law. (2026, March 13). 10 Critical Clauses for AI Vendor Contracts, on limitation of liability provisions disclaiming indirect, incidental and consequential damages, capping liability at tool fees and denying IP indemnity; the scenario in which a service company bore all damages after an AI-generated deliverable contained an unsubstantiated compliance claim; and the recommendations on indemnity, ownership of data and outputs, limits on training with proprietary content, and warranties on model behaviour and updates. Note: a United States law firm publication; general commentary rather than advice. gouchevlaw.com/10-critical-clauses-for-ai-vendor-contracts
3. Levy, C. S. (2026). Contracting with AI Vendors: A Practical Guide for Lawyers, on AI vendor contracts not being standard procurement and involving risks traditional templates were never built for; the distinction between traditional uptime service levels and AI service levels measuring output quality that changes every run; illustrative indemnity language including a knowledge qualifier; the competitor-comparison negotiating line; and the pilot structure with defined scope, measured metrics, a path to full agreement, termination without penalty, and pilot metrics becoming service level metrics. Note: a practitioner guide; illustrative language should not be adopted without counsel. Contracting with AI Vendors (PDF)
4. GC AI. (2026, June 5). A SaaS Agreement Has up to 50 Clauses. Six Carry the Risk., on the AI training and output rights clause not existing in pre-2024 templates and moving among the most-negotiated clauses alongside liability and indemnity; the threshold consent question extending to foundation models the vendor licenses from a third party; the buyer position of opt-out at minimum and opt-in for training with a prohibition on non-customer-facing model improvement; and zero-retention processing as the fallback. Note: published by a vendor of contract review software. gc.ai/blog/saas-agreement
5. SiLaw. (2026, May 31). AI Vendor Contract Clauses Checklist for Quebec SMEs, on the contract as where a Quebec business operationalises Law 25; section 17 cross-border rules requiring data-location transparency and a written transfer agreement; section 12.1 automated-decision rules requiring the vendor to supply explanation factors; breach notification timing sufficient for the diligence duty to the provincial commission; the clause list covering IP indemnity, security, sub-processor and location transparency, regulatory covenant and explainability support; and the reported 2026 industry scan finding about 33 percent of AI vendors offer IP indemnification by default. Note: a Quebec law firm publication; statutory provisions were not verified against the statute and the industry scan was not accessed. silaws.com/2026/05/31/ai-vendor-contract-clauses-checklist
6. Agent Mode AI. (2026, May 7). AI Vendor Exit Clauses: The 2026 Procurement Red-Flag Checklist, on agentic AI contracts being token-metered with minimum commitments and discount tiers; the risk sitting in the reserved right to revise the rate card and in fair use definitions that reset on renewal; the redline position of explicit customer ownership of customer-derived output with indemnification and a notification and defence protocol; and the observation that templates are now being tested at renewal, with customers who signed without redlines discovering which clauses bound them. Note: a commercial publication. agentmodeai.com/ai-vendor-exit-clauses-checklist

This article discusses contracting practice and is provided for general informational purposes only. It is not legal advice, this publication is not a law firm, and the sources cited are commentary rather than opinions addressed to any reader. Statutory descriptions were not verified against the legislation. No clause or position described here should be adopted without advice from qualified counsel on the specific agreement.