What Market Surveillance Authorities Can Do Under the AI Act

“Regulators can inspect you” understates Article 74. It gives market surveillance authorities full access to the training, validation and testing datasets behind a high-risk system, and — on a reasoned request, once two conditions are met — access to its source code. Those are unusual powers and the conditions on them are the part worth knowing.

The framework it borrows from

Article 74 of Regulation (EU) 2024/1689 does not invent a supervisory system. It applies Regulation (EU) 2019/1020, the Union’s general market surveillance and product compliance regulation, to AI systems. That matters because 2019/1020 already carries a substantial toolkit: powers to require documents and information, to carry out on-site inspections, to acquire product samples including under a cover identity, to require the withdrawal or recall of products, and to require the removal of content from an online interface. Article 74 then adds the AI-specific powers on top.

The practical consequence is that a provider preparing for AI Act supervision should not read Article 74 alone. The baseline powers are in the horizontal regulation; Article 74 is the delta.

When these powers start being exercised against high-risk systems has moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, moving the application date for stand-alone Annex III high-risk systems from 2 August 2026 to 2 December 2027 and for high-risk AI embedded in Annex I regulated products from 2 August 2027 to 2 August 2028. The powers themselves are not what moved — and note that market surveillance under Regulation (EU) 2019/1020 does not wait for the high-risk regime in any event, since the Article 5 prohibitions and, from 2 August 2026, the Article 50 transparency duties are supervised on their own timetable.

Which authority is yours

Article 74 does not put every provider in front of the same regulator, and identifying the right one in advance is worth the hour it takes.

• The general case. Member States designate market surveillance authorities under Article 70, and had to do so by 2 August 2025. Which national body holds the role varies considerably between Member States.
• Financial institutions. Where a high-risk system is placed on the market by a provider regulated under Union financial services law, the authority responsible for that entity’s financial supervision is its market surveillance authority for the AI Act.
• Biometrics, law enforcement, borders and justice. For the Annex III use cases covering biometrics, law enforcement, migration and the administration of justice, Article 74 points at the data protection supervisory authorities or the authorities designated under the Law Enforcement Directive. This is the provision that puts a data protection regulator in a product-safety role.
• Union institutions. Where Union institutions, bodies, offices and agencies are in scope, the European Data Protection Supervisor acts as their market surveillance authority, with the Court of Justice acting in its judicial capacity excluded.

Access to documentation and training data

The first AI-specific power is broad and unconditional in a way that product legislation rarely is. Market surveillance authorities are to be granted full access to the documentation as well as to the training, validation and testing datasets used to develop the high-risk AI system, including — where appropriate and subject to security safeguards — through application programming interfaces or other technical means and tools enabling remote access.

Three things follow. First, “full access” is not a summary or a datasheet; the Annex IV technical documentation and the Article 10 data governance record are the starting point, not the answer. Second, the express mention of APIs and remote access means an authority can ask for a mechanism rather than a delivery — which is easier to satisfy if you built one and awkward if the datasets exist only as historical snapshots on decommissioned storage. Third, and least comfortable: if your training data was licensed, scraped or purchased under terms that prevent you from making it available to a regulator, that constraint does not remove the obligation. Provenance records are worth keeping for this reason alone, and the same holds for operational records — see how audit logs function as evidence in a market surveillance investigation.

Article 78 imposes confidentiality obligations on the authorities in return: information obtained is to be treated in line with the confidentiality of intellectual property rights, trade secrets and source code, with disclosure only where necessary and subject to safeguards. That is protection against onward disclosure, not a ground for refusing access.

Access to source code, and its two conditions

The second power is the one that makes Article 74 consequential, and it is deliberately gated. Access to the source code of a high-risk AI system may be granted on a reasoned request and only where both of the following are satisfied:

• access to source code is necessary to assess the conformity of the high-risk AI system with the Chapter III Section 2 requirements; and
• testing or auditing procedures and verifications based on the data and documentation supplied by the provider have been exhausted or proved insufficient.

Read the second condition as a design instruction. It makes source code access a last resort that becomes reachable precisely when the documentation is thin. A provider whose technical file genuinely lets an authority assess conformity has a strong argument that the second condition is not met; a provider whose file is a marketing description has handed the authority the predicate for the request. The incentive runs the same direction as good documentation practice, which is not always true of compliance obligations.

Note also what the power is not. It is access for the purpose of a conformity assessment by an authority under confidentiality obligations — not publication, not disclosure to complainants, and not a right for third parties. And it is a power over the high-risk system; the separate supervisory regime for general-purpose models is exercised by the AI Office under Chapter IX Section 5, with its own procedures for requesting information and conducting evaluations.

What follows a finding

Where an authority has sufficient reason to consider a system presents a risk, Chapter IX requires it to evaluate the system against the Regulation and, if it finds non-compliance, to require the relevant operator to take appropriate corrective action, to bring the system into compliance, to withdraw it from the market or to recall it — within a period the authority prescribes. If the operator does not act, the authority takes provisional measures to prohibit or restrict the system on its national market, and notifies the Commission and the other Member States. There is a separate route for formal non-compliance — a CE mark affixed in breach of Article 48, a missing EU declaration of conformity, a missing or wrong notified body number, an absent registration, no authorised representative — where the authority requires the operator to put the failure right and can restrict or withdraw the product if it does not.

Penalties are a separate track, imposed under Member State rules laid down pursuant to Article 99. An authority’s corrective powers do not depend on a fine being imposed, and a fine is not the usual first move — the Article 99 tiers set the ceiling, while the day-to-day exposure for most providers is a withdrawal order with a deadline attached.