Contract clauses: audit rights, notification and exit

Due diligence tells you what is true today. Contract terms are what make it stay true, and what give you a remedy when it does not. Three clause families do most of the work, and all three are routinely omitted from AI procurement because the template predates the problem.

Audit rights and information access

The ordinary audit clause gives you a right to audit controls. For AI you need something more specific, because the questions are different and the vendor will resist the broad version.

Ask for: the right to obtain the instructions for use and technical documentation relevant to your deployment; the right to test the system on your own data before go-live and at defined intervals afterwards, which is what validating in your own context requires operationally; access to the logs relating to your use, in a form you can retain, because Article 26(6) puts a six-month retention duty on you and you cannot retain what you cannot obtain; and the right to receive the results of the vendor's own testing, including performance for specific groups, rather than a summary.

Where a vendor refuses, record the refusal and the reason in the third-party assessment. A refusal that is priced and accepted by a named decision-maker is a governance position. A refusal that is forgotten is a gap discovered by an auditor.

Notification, which is the clause that actually protects you

The most consequential AI-specific term is the duty to tell you when something changes. Without it, your inventory, your classification and your monitoring baseline all decay silently.

Require notification, with a defined period and a defined channel, of: a change to the underlying model or model version; a change to the intended purpose or to the stated capabilities and limitations; new AI features enabled in the product, including by default; a change of sub-processor or upstream model provider; a serious incident or a material performance degradation affecting your deployment; and any regulatory action or determination concerning the system.

The last three are ones vendors accept more readily than buyers expect, because they are already obliged to know them. The model version clause is the one that gets negotiated hardest, and it is the one to hold, because it is the difference between a reproducible decision and an unexplainable one.

Tie the notification period to your own deadlines rather than to a round number. If a vendor has thirty days to tell you about a serious incident, you cannot meet the Article 73 reporting deadlines, which run from when you establish the causal link or its reasonable likelihood: fifteen days generally, ten days where a person has died, and two days for widespread infringement or serious and irreversible disruption of critical infrastructure. Immediate notification for anything meeting the serious incident definition in Article 3(49) is the only workable term.

Exit

Exit planning for AI has two components that a standard SaaS exit clause misses.

The first is evidentiary. When the relationship ends, you still owe answers about decisions the system made. You need the right to retain, or receive, the logs and records relating to your use for the period your own retention obligations run, which may be six months under Articles 19 and 26(6), three years under Colorado SB 26-189, or longer under sector record-keeping rules. Vendors routinely delete on termination by default.

The second is operational continuity. If the supplier withdraws the product, fails, or becomes non-compliant, what runs in its place and how long does the switch take. For a claims-triage system with a service standard attached, the answer cannot be discovered during the outage. Document the fallback, and note whether the fallback is a manual process that no longer has enough trained people.

What no contract can transfer

This is the part to write into the assessment in plain terms. Contractual allocation of responsibility does not move regulatory obligations. FINMA Guidance 08/2024 states that responsibility remains with the institution even where AI is bought in or outsourced. SR 26-2 expects the institution to validate vendor models in its own context. Your Article 26 deployer duties, your Article 27 FRIA where it applies, your data protection obligations as controller and your oversight arrangements remain yours whatever the contract says.

What the contract does is give you the inputs to discharge those duties and a remedy when the supplier makes it impossible. That is worth a great deal. It is not indemnity from the regulator.

Worked example: a bank renegotiates after a silent model swap

A bank uses a vendor service to summarise commercial loan applications for credit officers. In February the summaries become noticeably different in style and start omitting covenant details that were previously included. Nobody can say when this began.

The vendor confirms it moved to a different underlying model in January, as it is permitted to do under a clause allowing it to improve the service. There was no notification, because none was required. The bank cannot say which applications were summarised by which model, so it cannot bound the population affected and cannot tell whether any credit decision turned on an omission.

The remediation is a sampling exercise across two months of applications, which costs more than the annual licence. The contract changes that follow are the three clause families above: notification of model change with a defined period, the right to obtain per-decision model version identifiers in the logs, and log retention aligned to the bank's own obligations rather than to the vendor's deletion schedule.

One further change is worth noting. The bank added the model version identifier to its own decision record rather than relying on the vendor's logs, because a control you operate is worth more than a control you have a contractual right to request.

As of 24 September 2026.