Right-to-Audit Clauses in AI Vendor Contracts

Almost every AI vendor contract has an audit clause and almost none of them survive contact with an incident. The failure is rarely the absence of a right; it is a right whose trigger, scope, evidence and remedy were negotiated away one clause at a time by people optimising different sentences.

Where the right comes from

Three sources, and knowing which one you are invoking changes what you can insist on.

Article 28(3)(h) GDPR requires the processor contract to oblige the processor to make available to the controller all information necessary to demonstrate compliance with Article 28, and to allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. This is not optional and it is not negotiable in principle — a DPA that removes it is non-compliant. What is negotiable is everything about how it operates. Regulation (EU) 2016/679 on EUR-Lex.

Sectoral regulation is stronger where it applies. Article 30(3) of DORA, Regulation (EU) 2022/2554, applying since 17 January 2025, requires contractual arrangements for ICT services supporting critical or important functions to include unrestricted rights of access, inspection and audit for the financial entity, an appointed third party, and the competent authority. Regulation (EU) 2022/2554 on EUR-Lex. If you are in scope of DORA, cite it: the negotiating position is materially different from a purely contractual ask.

The AI Act’s supply-chain hook is Article 25(4): a third party supplying an AI system, tools, services, components or processes used or integrated in a high-risk AI system must, by written agreement, specify the information, capabilities, technical access and other assistance needed for the provider to comply with the Regulation — with a carve-out for free and open-source components other than general-purpose AI models. It is not an audit right, but it is a statutory basis for demanding information and access, and it is the provision to cite when a vendor says its architecture is confidential.

Nine ways a clause is hollowed out

• Report substitution as a full discharge. “Supplier may satisfy this clause by providing its most recent SOC 2 Type II report.” A report on a scope the supplier chose, for a period it chose, tested by an auditor it engaged. Useful, and not the same as a right.
• Notice plus frequency plus window. Ninety days’ notice, once per twelve months, during business hours, at a mutually agreed time. Every element is reasonable; together they make a post-incident audit impossible.
• No incident trigger. The single most valuable addition, and the most commonly missing: a right that arises on a personal data breach, a material adverse finding, or a regulator’s direction, outside the annual allowance.
• Auditor vetoes. “Not a competitor of Supplier” sounds fair and, applied to a vendor that describes most large consultancies as competitors, removes the qualified auditor pool.
• Multi-tenant exclusion. “Excluding shared infrastructure and other customers’ data.” The second half is necessary. The first half excludes almost everything that matters in a hosted AI service.
• No sub-processor reach. The audit stops at the vendor’s boundary while the inference runs at a hyperscaler and the safety review is done by a third supplier.
• Confidentiality that beats disclosure to a regulator. Findings marked confidential with no carve-out for supervisory authorities. This one is fatal, because the entire point of the evidence is that you can show it to someone.
• Cost allocation as deterrent. You pay your costs and the supplier’s reasonable costs, uncapped, with rates set by the supplier. Fine for a scheduled audit; a deterrent for an urgent one.
• No remedy. A right to audit with no consequence for refusal, and no link from findings to remediation to termination, is an entitlement to be told no politely.

AI-specific scope the standard clause misses

A general IT audit clause was drafted for a hosting relationship. The items that matter for a model vendor are usually not in it:

• Retention and deletion configuration as actually deployed — not the setting in the console, the effective behaviour including safety retention, backups and cached embeddings.
• Training-use controls. Evidence that customer content is excluded from training pipelines, which is a data-flow question rather than a policy question.
• Human review paths. Who can read content, under what trigger, and the access logs for that path.
• Model change management. How a model version is promoted, what evaluation gates it passes, and what notice customers get. Silent model swaps are the AI-specific version of an unannounced change to a service.
• Evaluation and safety artefacts — red team summaries, evaluation results relied on in the documentation you were given, and their dates.
• The sub-processor set, verified. Not the published list; the list reconciled against the actual data flows.

Drafting the parts that matter

1. Separate the routine from the triggered right. One scheduled exercise a year with generous notice, satisfiable by reports and a questionnaire; and a separate triggered right with short notice, arising on defined events. Negotiating these as one clause is what produces the worst of both.
2. Define the trigger events explicitly. A personal data breach affecting your data; a material finding in the supplier’s own audit; a regulator’s request or direction; a change of control or of sub-processor at a critical layer; a material failure of a security or availability commitment.
3. Flow it down and say so. Under Article 28(4) the processor must impose the same data protection obligations on any sub-processor. Make the clause say the supplier shall procure equivalent audit rights, and shall exercise them at your reasonable request where direct access is not possible — the fallback that actually works against a hyperscaler.
4. Enumerate the evidence. A clause that lists what you can ask for is far more useful than one that grants abstract “access”. Name the artefacts: sub-processor register, retention configuration exports, access log samples for content review, penetration test summaries, certification scope statements, ISO 42001 statement of applicability, model change records.
5. Carve out regulator disclosure from confidentiality, expressly, including onward disclosure to your own auditors and supervisory authorities without prior consent.
6. Attach a remedy ladder. Findings produce a remediation plan within a stated period; failure to remediate produces a service credit or suspension right; a material unremedied finding or a refused audit produces termination for cause with no early termination charge and with transition assistance.
7. Make it survive. The right must outlast termination for as long as the supplier holds any of your data, and the transition assistance obligation must be its own clause with its own period.

A compact version of the triggered limb, as a discussion draft:

Triggered audit. In addition to the annual review under clause X.1,
Customer may, on 5 business days' written notice, audit Supplier's
processing of Customer Data on the occurrence of: (a) a Personal Data
Breach affecting Customer Data; (b) a material adverse finding in any
audit or certification of Supplier; (c) a request or direction from a
supervisory or competent authority; or (d) any change to a sub-processor
performing inference, storage or content review.

Such audit may be conducted by Customer or an auditor mandated by
Customer that is bound by confidentiality (and Supplier shall not
unreasonably object to a mandated auditor). Supplier shall procure
equivalent rights in respect of each sub-processor and, where direct
access is not available, shall exercise those rights on Customer's
reasonable request and provide the results.

Findings may be disclosed to Customer's auditors and to any supervisory
or competent authority without further consent. This clause survives
termination for so long as Supplier retains Customer Data.

What you will actually get

Be realistic about leverage. A large model provider on standard terms will not grant on-site inspection to every customer, and a clause demanding it is a clause that will not be signed — or worse, will be signed and quietly unperformable. The version that survives negotiation with a major vendor is usually: reports and questionnaires for the routine case, a genuine incident trigger, enumerated evidence, sub-processor flow-down exercised by the vendor on your behalf, regulator disclosure carved out, and a remedy ladder ending in termination.

That is a good outcome. It is also worth noticing what it means: your assurance is documentary rather than inspective, and its value depends entirely on the evidence list being specific. Spend the negotiating capital on the enumeration and the trigger rather than on the word “unrestricted”. The related question of what else belongs in the DPA is in the sub-processing DPA clauses page, and the broader clause set in AI contract clauses.