Article 25 AI Act makes audit rights in AI contracts a legal obligation

You must now negotiate and document in writing which logs, models, documentation and technical access your AI suppliers will make available for audit, within defined timeframes, as a condition of deployment. This is no longer optional due diligence — it is a regulatory obligation under Article 25 of the EU AI Act.

The prompt is an analysis of 1 September 2026 of audit rights and evidence obligations in AI contracts, which argues that parties in the AI value chain must now set out in writing which information, technical access and assistance are needed to comply with the AI Act. The analysis draws on the official AI Act Service Desk explanation of Article 25 and on contract guides from 2026 that translate this into explicit audit rights over usage logs, security reports, model cards and outcome evidence. In our assessment, the shift from optional access to contractually binding evidence rights represents a fundamental change in how you demonstrate compliance: without written agreement on what you can request and when, you cannot substantiate your own obligations to regulators or courts.

What has changed in AI contracts?

Where access to documentation and logs was previously a matter of goodwill or competitive advantage, it is now a condition for being able to demonstrate compliance at all. The original provider must work closely with parties further down the value chain — integrators, deployers, end-users — to ensure that evidence trails exist and remain accessible. This aligns with a broader movement in AI governance in which abstract principles give way to testable control duties.

The practical consequence is immediate for anyone deploying AI in high-trust work: legal services, healthcare, finance, government. You cannot negotiate only on price and performance. You must set out in advance which evidence you can later request to demonstrate what a system has done, and you must have the technical means to retrieve it.

Which evidence elements must an auditable contract cover?

Recent contract guides and procurement standards identify a consistent set of evidence elements that recur across credible AI contracts:

• Usage logs and outcome attribution — complete records of inputs, outputs and decisions made by the system in each workflow.
• Model documentation and versioning — model cards, training data summaries and records of which model version was deployed when.
• Post-market monitoring records — ongoing performance data, failure logs and drift detection results.
• Compliance documentation and instructions — the lawful basis, data processing records and instructions under the relevant AI Act articles.
• Audit access and timeframes — the right to request evidence within a defined period, typically ten days to two weeks, and the right to transfer compliance records if the contract ends.
• Independent verification rights — access to security reports, penetration test results and third-party audit findings.

What is the difference between an audit right on paper and one that works?

An audit right has value only if the underlying evidence trails actually exist, are searchable and are linked to the right workflow. The distinction that matters most is between an abstract right to audit and a concrete right to receive defined datasets within an agreed timeframe. The former is a clause; the latter is evidence.

This aligns with a shift from logging obligation to reconstruction obligation. It is not only about retaining data, but about being able to show what happened in a specific process. If you cannot retrieve usage logs for a particular legal research task, a model card for the version deployed, and the outcome attribution for a specific decision, then you have no evidence to present.

How do you set up auditability technically?

If you want to move from contract language to working systems, this sequence is useful:

1. Map which workflows touch high-risk AI — document which tasks in your organisation use AI systems and which data they process.
2. Define the evidence set per workflow — specify which logs, model versions, inputs and outputs must be captured for each task.
3. Establish log retention and searchability — ensure logs are stored in a format that allows you to retrieve records by date, user, task type and outcome within the agreed timeframe.
4. Create a verification layer — introduce a step between the user and the AI model that records what was sent, what was returned, and what corrections or disagreements arose.
5. Test audit retrieval — run a dry run in which you retrieve a sample of evidence for a completed workflow and verify that you can reconstruct what happened.

A verification layer can be a technical component that routes tasks through selected models and exposes verification steps, corrections and sources for inspection. This makes the evidence visible so that professionals can check outcomes themselves. Pre-processing and anonymisation can take place on your own infrastructure before any data reaches external models, and the workflow can be designed to send only anonymised content onward.

What remains your own responsibility?

Tooling can make evidence trails visible and searchable. It can enforce anonymisation, route tasks consistently and record what happened at each step. What it cannot do is judge whether the outcome was correct, whether the decision was fair, or whether the evidence is sufficient for your purposes. That remains with you. For teams applying this to legal work, a defensible workflow for legal research is a concrete starting point for designing audit rights and evidence delivery together. The professional final judgement stays with the user.