Under Article 25 of the EU AI Act, parties in the value chain of a high-risk AI system must set out in a written agreement which information, technical access and assistance are needed to comply with the AI Act obligations. According to the official explanation from the AI Act Service Desk, the original provider must work closely with new providers in doing so. In practice this means an AI contract in 2026 must concretely arrange: which logs, documentation and model versions can be requested for audits, within which time frames customers and regulators receive them, and how suppliers cooperate with chain audits.
Contract guides and clause libraries from 2026 translate this into explicit audit rights over usage logs, security reports, model cards and outcome evidence. Auditability is therefore no longer an optional due-diligence clause, but a regulation-driven obligation you negotiate in advance and set up technically.
For anyone deploying AI in high-trust work — the legal profession, healthcare, finance, government — the practical consequence is immediate: do not negotiate only on price and performance, but set out which evidence you can later request to demonstrate what a system has done. This shift belongs in the EU AI Act and compliance topic hub.
What does Article 25 AI Act prescribe about information and access in the chain?
The AI Act Service Desk explanation of Article 25 describes the responsibilities along the AI value chain. Its core is that a written agreement between parties must specify which information, technical access and other assistance are needed to comply with the obligations under the regulation. The original provider must cooperate with parties further down the chain that further develop or deploy a system.
That changes the nature of the arrangement. Where access to documentation and logs was previously often a matter of goodwill, it now becomes a condition for being able to demonstrate compliance at all. Without contractually arranged access to evidence, a deployer cannot substantiate its own obligations. This shift aligns with a broader movement in AI governance, in which principles give way to testable control duties.
Which logs, documents and evidence must an AI contract make requestable?
Recent practical sources concretely indicate which evidence elements a credible AI contract must cover. Sota.io's supply-chain guide on AI API contracts under the AI Act describes example clauses in which customers receive an audit right over documentation, the instructions under Article 13 and the post-market monitoring records under Article 72, with a ten-year retention period and transferability of compliance documentation on contract termination. An analysis by Atonement Licensing on audit rights in enterprise contracts adds rights over complete usage logs, outcome attribution and independent billing audits.
On the basis of these sources, the following evidence elements recur as the core of an auditable AI contract:
- Machine-readable usage logs with timestamps, token counts and model versions, with a defined retention period (Atonement Licensing cites at least twelve months).
- Technical documentation and model cards, including the instructions under Article 13 and dataset documentation.
- Security audit reports such as SOC 2 and ISO 27001.
- Model change logs with prior notification of changes.
- Outcome and billing evidence where relevant, so that results and costs are verifiable.
- Clear time frames and remedies for supplying evidence and for cases where access is refused.
A ContentWave blog on the impact of AI Act enforcement on enterprise LLM procurement states that procurement teams are increasingly including audit and inspection rights, minimum logging standards and secure log access in RFPs and SLAs, with conformity evidence, model cards and dataset documentation as auditable deliverables. In our assessment the most important step here is the distinction between an abstract audit right and a concrete right to receive defined datasets within an agreed time frame — the latter makes the difference between paper and evidence.
How do you translate contractual audit rights into a verifiable workflow?
An audit right on paper only has value if the underlying evidence trails actually exist, are searchable and are linked to the right workflow. That aligns with the broader 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 want to set up auditability technically, this sequence is useful:
- Determine, per high-trust workflow, which evidence has been contractually promised (logs, documentation, model versions, outcome evidence).
- Ensure that this evidence is recorded and traceable per run, including which models and data were used.
- Set out who has access and how an audit — internal or external — proceeds in practice.
- Check whether the supplied evidence sets match the agreed audit rights and retention periods.
Within this architectural picture, a verification layer such as IamVera.ai can fit. Vera is not a chatbot and not its own language model, but a privacy-focused verification layer that can route a task through selected independent AI models and expose verification steps, corrections, disagreements and sources for inspection. This supports review and control by making the verification steps visible, so that professionals can check the outcome themselves. Pre-processing and anonymisation take place on EU infrastructure; the workflow is designed to send only anonymised content to the chosen models, and when a privacy check fails, nothing is sent onward.
Such a visible evidence layer per workflow adds no new obligations, but makes clear which evidence sets fall under an AI workflow and how they have been used in audits or disputes. The professional final judgement remains with the user. 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.
Sources and references
Sources: The article draws on the official AI Act Service Desk explanation of Article 25 and on contract analyses by Sota.io, Atonement Licensing and ContentWave.