AI Audit Logs in an EU Market Surveillance Investigation

The AI Act’s enforcement chapter is not a self-contained procedure. It sits on top of the EU’s general market surveillance regulation and adds a small number of AI-specific access powers, and the order those powers run in decides what your logs are for.

How a file actually opens

Article 74(1) of Regulation (EU) 2024/1689 applies Regulation (EU) 2019/1020 — the market surveillance and product compliance regulation — to AI systems covered by the AI Act. That is the structural point most summaries skip. The investigating authority is a national market surveillance authority using product-safety machinery that predates the AI Act, and Regulation (EU) 2019/1020 on EUR-Lex is where its general powers of inspection, information-gathering and restriction come from.

Files open from three directions in practice. A serious incident report under Article 73, which the provider files itself — within 15 days of awareness in the ordinary case, and on much shorter clocks for a widespread infringement or a death. A complaint, including from a person affected by a decision. Or the authority’s own initiative, including the Article 79 procedure for AI systems presenting a risk at national level, which begins with the authority evaluating the system against the requirements and, where non-compliance is found, requiring corrective action.

The first of those is the one worth internalising. Under Article 73 a provider is the party that starts the process, on a deadline, and the content of that first report will be drawn from logs. If your logging cannot support a factual account of what happened within days, the regulatory clock has already exposed the gap. The incident reporting duty is worth reading before, not after.

What can be demanded, and in what order

Two provisions carry the AI-specific access powers, and they escalate.

Article 21 is the cooperation duty on providers. On a reasoned request from a competent authority, a provider must supply all the information and documentation necessary to demonstrate the conformity of the high-risk AI system with the Chapter III requirements, in a language easily understood by that authority. Article 21(2) then adds the specific one: on a reasoned request, the provider shall give the authority access to the automatically generated logs referred to in Article 12(1), to the extent those logs are under its control. Article 21(3) applies the confidentiality regime in Article 78 to whatever the authority obtains.

Article 74 then gives the market surveillance authority its own powers. It is granted full access to the documentation as well as the training, validation and testing data sets used for the development of the high-risk AI system, including, where appropriate and subject to security safeguards, through application programming interfaces or other technical means enabling remote access.

Two things follow. First, “reasoned request” is a precondition, not a formality: the request has to be motivated, which is also what makes it reviewable. Second, the data-set access power is broader than most providers expect — it reaches the material the system was built from, not only the material it produced. A provider that cannot reconstruct which data set version trained a deployed model has a documentation problem long before it has an evidence problem, and the Article 10 data governance requirements are what that reconstruction rests on.

Source code is the last resort, by design

Article 74 also provides for access to the source code of a high-risk AI system, and it is deliberately conditioned. The access is available on a reasoned request and only where two cumulative conditions are met: that access to the source code is necessary to assess the conformity of the system with the Chapter III, Section 2 requirements, and that testing or auditing procedures and verifications based on the data and documentation supplied by the provider have been exhausted or proved insufficient.

That second condition is the sentence to remember, because it makes your documentation and your logs the thing that keeps an investigation out of your source tree. An authority cannot reach for the code first. It has to work with what you gave it, and only when that is exhausted or inadequate does the code condition open. A provider with thorough technical documentation and logs that answer the questions actually asked is, on the face of the text, less likely to face a source code demand than one whose file is thin.

Confidentiality then travels with the material: information and documentation obtained by market surveillance authorities is subject to the Article 78 confidentiality obligations, which cover trade secrets, source code and intellectual property. That is a protection, not a veto, and it does not entitle you to withhold the material in the first place.

What the logs are doing in that process

The AI Act does not contain a law of evidence, and this is where a lot of writing on the topic overreaches. Article 21(2) makes logs accessible to a competent authority. It does not make them proof of anything, it does not assign them a probative weight, and it does not displace the national procedural rules that govern any subsequent administrative or judicial proceeding. What the logs do in an investigation is more prosaic and more useful: they are the only contemporaneous record of what the system did, so they set the factual frame everything else is argued inside.

Practically, that gives them three jobs. They establish the scope — how many affected decisions, over what window, in which configuration. They establish whether the incident is a defect in the system or a deployment outside the instructions for use, which is the line between a provider problem and a deployer problem. And they establish whether you knew, which is a different question from whether you were at fault, and frequently the one that shapes the penalty discussion under the penalty tiers.

The asymmetry is worth stating plainly. A complete log can support your account and can bound your exposure. An absent log cannot do either, and the absence itself is a breach of Article 19 or Article 26(6) that the authority can act on independently of whatever it was originally investigating.

The integrity gap in the text

Article 12 requires logging. Article 19 and Article 26(6) require retention. Neither says the logs must be tamper-evident, and no provision of the Regulation imposes an append-only, hash-chained or independently timestamped format. The nearest hooks are Article 15, which requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance, and Article 17, under which the quality management system has to cover record-keeping among other things.

So integrity protection is not a stated statutory requirement, and this page will not claim it is. It is an evidential one. A log that your own engineers can edit is worth less in an argument about what happened than one they cannot, and that difference bites in exactly the situation the logs exist for. Treat write-once storage and integrity checks as a decision you make for evidential reasons and record in the quality management system — not as a box the Regulation ticks.

What is genuinely unresolved

Three things, and pretending otherwise would make this page worse.

There is no enforcement practice yet. Chapter III applies from 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for Annex I product-embedded ones, following the amendments made by Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026. Nobody can tell you how national authorities will read Article 74 in practice, because none of them has yet had to.

The institutional map is still settling. The same 2026 regulation revised Article 74 and the surrounding governance provisions, including the boundary between national authorities, the AI Office and the Commission’s own supervisory role. Which body opens your file is a question to answer against the current text rather than against the 2024 original.

Admissibility is national. Whether a log is admissible, what authenticates it, and who bears the burden are questions of Member State procedural law and of the relevant sectoral regime, not of the AI Act. A rule of thumb that works in one Member State may not travel. If your answer to “can we prove this?” depends on the country, that is not a gap in this page; it is the actual state of the law.