Skip to main content

Governance

Audit Rights in an AI Contract That You Could Actually Use

Most AI contracts contain an audit clause that cannot be exercised when it matters. This guide separates the statutory rights you already hold — GDPR Article 28(3)(h), transfer clauses, DORA — from the ones you must negotiate, explains why the EU AI Act gives customers no audit right at all, and sets out what a usable clause, and the evidence behind it, looks like in practice.

Audit Rights in an AI Contract That You Could Actually Use

The clause arrives late. Procurement has spent weeks on an AI-assisted platform, the commercial terms are agreed, the sponsor has a go-live date, and the papers reach you for governance sign-off with days to spare. You turn to the audit section and find one sentence: the supplier will make its current SOC 2 Type II report available on request, and no other inspection rights are granted.

That is the whole of your assurance for a system that will shape decisions about customers or staff for the length of the term. The useful question is not whether you have "an audit right" — nearly every contract has something — but whether it can be exercised by a real team at the moment you need it: after an incident, when a regulator asks, or when the model changes and nobody says so.

The rights you already have, and the ones you must negotiate

UK and EU GDPR, Article 28(3)(h). Where the vendor processes personal data on your behalf, the contract must require it to make available all information necessary to demonstrate compliance with Article 28, and to allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate. Two limits matter. It reaches only processing carried out on your instructions, and only Article 28 obligations — not model quality. And where the vendor uses your data for its own purposes, such as improving its own models, it acts as controller, and your rights do not follow the data there.

Transfer clauses. Clause 8.9 of the 2021 EU standard contractual clauses places documentation and audit duties on the data importer, and the UK equivalents sit in the IDTA or the UK Addendum. They say nothing about the AI system itself.

DORA. If you are an in-scope financial entity, Article 30 requires ICT contracts to include access, inspection and audit rights, and for services supporting critical or important functions those rights must be unrestricted and available to you, a third party you appoint, and your competent authority. It is the strongest statutory hook available, and only a minority of buyers hold it.

The EU AI Act gives you no customer audit right. This is the point most often misread. A provider's documentation, logging and cooperation duties run to market surveillance authorities and, where one is involved, a notified body. What it owes you as deployer is the instructions for use and information under Article 13, not access to its evidence. Fines of up to 3% of global annual turnover for most obligations, and 7% for prohibited practices, motivate providers to satisfy regulators — not you.

SourceWho owes it, to whomWhat it gets you
GDPR Article 28(3)(h)Processor to controllerAudits and inspections, limited to processing on your behalf
SCCs Clause 8.9 / IDTAData importer to exporterThe same duty, for restricted transfers
DORA Article 30ICT provider to financial entityAccess, inspection and audit; unrestricted for critical or important functions
EU AI ActProvider to authorities and notified bodiesNothing you can enforce; deployers get instructions for use
ISO/IEC 42001 certificateCertification body assesses the vendor's management systemThird-party audit of an AI management system, within a stated scope
The contractVendor to youEverything else — the only source of model-level assurance

Who is responsible for this

Your organisation stays accountable in whichever role it holds. You are controller for the personal data you feed in. You are deployer if you use the system under your own authority. You become provider under Article 25 of the AI Act if you put your name or trade mark on a high-risk system, substantially modify it, or change its purpose so that it becomes high-risk — at which point the original provider must cooperate closely and give you the information and reasonably expected technical access you need. Write that duty into the contract before it is triggered.

Internally, the contract owner holds the right and must be willing to use it. Legal and procurement draft it; second-line compliance specifies what evidence would actually satisfy them, because a lawyer cannot guess that; internal audit tests whether the right was ever exercised. The DPO advises and monitors, and should not be the person who quietly accepts a weak clause because the deal is late.

One clarification saves arguments: an ISO/IEC 42001 certificate says a certification body audited the vendor's AI management system — scope, Statement of Applicability, internal audit, management review, nonconformity and corrective action. It is not a certification of a model, and it is not your audit. Read the scope statement, which often covers one business unit or service line rather than the product you are buying.

What a usable audit right looks like

  • Scope beyond personal data. Cover the AI system, its operation and its supporting controls, not only processing under the DPA.
  • Trigger events, not just an annual allowance. A once-a-year right is useless in February. Add triggers: a security or safety incident, a serious malfunction, a material change to the model or its data, a regulator's request.
  • Notice proportionate to the trigger. Long notice for routine audits is fine; incident-driven access needs days, not months.
  • Named artefacts, in a schedule. A right to "audit" with no list gets you a sales engineer and a slide deck. Name change logs, evaluation results for the version in production, data provenance documentation, the human oversight design, incident records affecting your tenant, and the sub-processor list.
  • Access to logs you must keep yourself. The AI Act requires deployers of high-risk systems to retain automatically generated logs for at least six months unless other law provides otherwise — and those logs sit on the vendor's infrastructure.
  • A mandated auditor. Keep the right to appoint an independent third party, with objection limited to genuine competitors.
  • Flow-down. If the vendor hosts on a hyperscaler or calls a model it does not control, it must pass through equivalent rights or tell you where the chain stops.
  • Costs allocated by outcome. Routine audits at your cost; incident-triggered audits, and those finding material nonconformity, at theirs.
  • Remedies attached to findings. A remediation window, the right to suspend use, termination for unremedied material findings. Without a remedy, an audit right is a reading right.
  • Survival and regulator access. The right must outlive termination for as long as the vendor holds your data, and your regulator needs a direct route in.

Where these clauses fail

The commonest failure is placement: the audit right lives only in the data processing addendum, so it reaches personal data and nothing else, while the real exposure is the model behaving badly on cases where no personal data is in dispute. Next is the "report in lieu of audit" substitution, where a SOC 2 or ISO certificate discharges the obligation entirely — indefensible as your only line, and in a controller-processor relationship it cannot lawfully extinguish the Article 28 right.

Then the quieter killers: annual caps with no incident trigger; confidentiality carve-outs letting the vendor withhold anything "proprietary", which is everything interesting; multi-tenant environments where physical inspection tells you nothing; rights that lapse on termination while the vendor still holds your data. Last, the clause nobody uses — an unexercised right decays, and the first attempt comes at the worst moment.

Limits, and when to take advice

Some of this is genuinely unsettled. Harmonised standards supporting the AI Act are still in development, and until they are cited in the Official Journal a provider cannot claim presumption of conformity through them — so a clause promising compliance with "the applicable harmonised standards" may promise nothing enforceable today. Other obligations depend on implementing acts and guidance that are not final. Certification bodies set their own procedures and rules on what a client may share, so a refusal to hand over a Statement of Applicability is not automatically bad faith.

Take specialist legal advice where the stakes justify it: high-risk classification that is genuinely arguable; restricted transfers layered on an AI service; DORA critical-or-important-function designation; regulated products such as medical devices; and any case where you may have become a provider without intending to. A well-drafted audit right does not make you compliant. It makes it possible to find out whether you are.

  • AI contracts
  • third-party risk
  • GDPR Article 28
  • audit rights
  • vendor assurance
  • DORA

More guides

Start Free AI Compliance Review