Your AI contract needs a workable answer when the rules change

A supplier sends through its standard AI terms. The service looks useful, the pilot has gone well and the business wants to sign before the end of the month. Then a government announcement arrives promising new safety obligations and a new regulator.

The question usually lands with Legal in a very practical form: does this mean we need another clause?

Possibly. But the more useful question is what the parties will actually do if a new requirement changes the service during the contract term. Who investigates? Who pays? Can the supplier replace the model? Can the customer stop an affected use without losing the rest of the service?

Those questions are worth answering without pretending to know the final legislation. A contract can provide a sensible process for uncertainty rather than attempting to predict every future rule.

What was announced this week

On 10 November 2026, the Australian Government announced its intention to legislate mandatory safety and security protections for frontier AI companies operating in Australia. It proposed a targeted regulator working with the Australian AI Safety Institute. The announcement outlined obligations covering security, serious risks, independent evaluation, rapid incident notification, published safety frameworks and responses to changing standards. It also said further legislative detail would follow consultation and development work. [1]

That is an announced legislative direction, not a basis for telling a customer that every proposed obligation is already an enacted duty applying to its business. The Finance Minister's speech on 11 November reiterated the proposed protections while discussing public-sector adoption of AI. [2]

The contracting recommendations below are practical suggestions for dealing with change. Their application will depend on the actual service, parties and law, including any later legislation.

Start with the service you are buying

An AI procurement can contain several different businesses behind one product screen. The customer may contract with an application provider that uses an external model, another hosting service and an implementation partner.

Before allocating responsibility for regulatory change, identify which party controls the thing that might need changing. The application provider may control user permissions and the customer interface but have limited influence over the underlying model. An implementation partner may configure the workflow without operating any of the services after launch.

Ask for a short description of the relevant relationships. It should identify the contractual supplier, the important dependencies and the customer responsibilities. You do not need an architectural diagram covering every component in the supplier's business. You need enough information to understand whose decision could interrupt the work you are buying.

For example, imagine an organisation purchasing an AI tool to help staff prepare supplier summaries. Its supplier changes the underlying model because of a new regulatory requirement. The replacement might perform the task differently, use different processing arrangements or require the customer to retrain staff.

That hypothetical change is not resolved merely by establishing that the supplier can legally use the replacement. The customer also needs to know whether the replacement still meets the agreed service requirements.

Separate legal compliance from commercial improvement

A broad change clause can obscure very different situations.

One change may be necessary to comply with a binding requirement. Another may reflect a supplier's interpretation of non-binding guidance. A third may be an optional redesign that the supplier wants to introduce across its customer base. Each can be reasonable, but they do not automatically justify the same rights, costs or timetable.

My preference would be to distinguish these situations in the discussion before trying to draft them. Ask the supplier what it expects the clause to cover and work through an example of each.

A useful change proposal should explain:

• The legal requirement or other development being relied on.
• Which part of the service is affected and why.
• The proposed response and reasonable alternatives considered.
• The expected effect on functionality, information handling and customer work.
• The implementation date and any period in which the current service cannot continue.
• The proposed charges, with an explanation of their basis.

This is not a request for the supplier to guarantee that policy will never change. It is a request for enough information to make a commercial decision.

Avoid a blank cheque disguised as compliance

The phrase “changes required by law” can become a shortcut for passing through any cost associated with the supplier's evolving business.

The customer should understand the proposed allocation rather than assuming every compliance cost belongs to one side. The answer may differ between a general change affecting all users and a customer-specific requirement arising from a new use the customer has chosen.

For a standard subscription, a buyer might seek to have ordinary provider compliance costs included in the price. For a bespoke implementation, the parties might agree a defined process for evaluating additional work. Neither starting position removes the need to discuss what happens if the cost becomes substantial.

Ask how shared implementation costs will be treated, whether charges require prior agreement and what happens if the parties cannot agree. Avoid a process in which the supplier can announce a large increase, impose it immediately and leave the customer with no workable alternative.

Finance should be part of this conversation. A contractual review right will not help much if the operational team assumes a fixed annual budget while the agreement permits material unplanned charges.

Preserve the ability to test a replacement

A model or service replacement can affect the quality of work even where the user interface looks unchanged.

In the supplier-summary example, the team might discover that the replacement is better at concise summaries but less reliable at distinguishing a signed variation from an unsigned proposal. That would matter to the intended use, regardless of the reason for the replacement.

Consider agreeing proportionate testing before material changes take effect. The customer can provide a small set of representative tasks and acceptance criteria, while keeping confidential information within an authorised environment. The point is to compare the service against the agreed purpose, not to demand a guarantee that every answer will be perfect.

Discuss the consequences of an unsuccessful test. Can the supplier adjust the configuration? Can the customer narrow the affected use? Is a previous version available for a limited period where lawful and technically feasible? What happens if no suitable option exists?

Record who makes the operational decision and what evidence they need. Otherwise, testing can finish with a long list of observations but no clear answer about whether staff should continue using the service.

Make urgent changes possible without making every change urgent

Some developments will not fit a comfortable notice period. A binding restriction or serious safety issue may require an immediate response.

The agreement should allow appropriate protective action while still requiring an explanation and a plan. A supplier may need to suspend an affected function first and provide fuller information as it becomes available. That is different from a general right to make any material change without notice whenever the supplier considers it convenient.

For urgent changes, consider a short operational sequence: identify the affected service, notify the nominated contact, explain the immediate restriction, provide an initial assessment, and set a time for the next update. Specify how the parties will review continued suspension or a proposed replacement.

The customer's internal process matters too. A notice sent to an unattended procurement mailbox should not be the only way the service owner learns that a critical function has changed. Nominate an operational contact and a substitute, with a sensible escalation route.

Agree what happens if the service no longer fits

A renegotiation process needs an ending.

If a necessary change removes a capability on which the business depends, the customer may need to discontinue the affected service. Discuss whether termination can be limited to that component, what happens to prepaid fees, and what transition assistance is available.

Keep those questions connected to the work the service supports. A team may need exports, retained records or a period of assistance to move a process elsewhere. The appropriate arrangement will vary, but it should not be discovered for the first time after the parties have reached an impasse.

Also consider dependencies within the customer's organisation. If several business units use the same agreement, one team's inability to continue should not automatically end a service that remains useful for everyone else. Conversely, preserving the rest of the agreement should not trap the affected team in charges for a function it can no longer use.

Keep the agreed process usable after signature

Once the clause is negotiated, turn it into a short working note for the service owner. Record where notices will arrive, who assesses them, which changes need testing and who can agree to additional charges.

At a regular contract review, ask whether the supplier has announced relevant changes, whether any assessment remains open and whether the information about key dependencies is still accurate. This can be a brief item rather than another committee.

The goal is a contract that helps the parties make a timely decision when circumstances change. That is more useful than either a sweeping promise to comply with everything forever or a broad disclaimer that leaves all the consequences with the customer.

If your team is working through the documents behind an AI procurement, you can Book a Demo with Contract Cloud to explore whether its contract workspace suits the way you review and manage those agreements.

Sources

[1] Australian Government, New Australian AI safety and security protections, 10 November 2026. This is a policy announcement describing proposed legislation.

[2] Minister for Finance, AI Government Showcase 2026, 11 November 2026. Ministerial speech, not legislation.