EU AI Act Article 74: Market Surveillance Powers Over AI Systems

Overview: How AI Systems Are Actually Policed

Most of the EU AI Act describes what providers and deployers must do. Article 74 describes what happens when somebody checks. It plugs AI systems into the established machinery of European product surveillance — Regulation (EU) 2019/1020, the framework under which everything from toys to machinery is monitored on the single market — and then extends that machinery with AI-specific inspection powers reaching into documentation, training data and, in defined circumstances, source code. Together with the corrective procedures of Articles 79 to 83, Article 74 is the operational answer to the question every compliance officer eventually asks: who can knock on our door, what can they demand, and what can they do to our product.

The Framework: Regulation 2019/1020 Applies

Article 74(1) declares that Regulation 2019/1020 applies to AI systems covered by the AI Act. That single sentence imports a complete enforcement toolkit: powers to require information, carry out inspections including unannounced on-site checks, acquire product samples including under cover identity, order corrective actions, restrict making available on the market, order withdrawal and recall, and impose penalties through national procedures. It also imports the cooperation architecture — mutual assistance between authorities of different Member States, coordinated activities, and the information and communication system in which surveillance actions are recorded. For providers familiar with CE-marked products, the choreography is recognisable; the novelty is the subject matter.

AI-Specific Powers: Documentation, Data and Source Code

Article 74 then sharpens the toolkit for AI. Authorities must be granted full access to the documentation and to the training, validation and testing datasets used by the provider, including, where appropriate and subject to security safeguards, through application programming interfaces or other relevant technical means enabling remote access. Deeper still, access to source code: granted on reasoned request, and only where two cumulative conditions are met — access is necessary to assess the conformity of a high-risk AI system with the Chapter III Section 2 requirements, and testing or auditing procedures and verifications based on the data and documentation provided have been exhausted or proved insufficient. Confidentiality obligations under Article 78 bind the authorities throughout, addressing the trade secret anxiety that source code access naturally provokes. Providers should read the structure carefully: documentation and data access is the norm; source code is the escalation step, with legal preconditions a provider can insist upon.

Who Surveils Whom: The Allocation Rules

Article 74 distributes surveillance across regulators to follow existing supervisory relationships:

• For high-risk AI related to products under Annex I sectoral legislation, the market surveillance authority is in principle the authority already responsible for that product sector
• For AI used by financial institutions regulated under Union financial services law, the market surveillance authority is in principle the national financial supervisor, and supervisory information flows are aligned with financial oversight
• For high-risk AI in law enforcement, border management, justice and democracy — the Annex III points 6, 7 and 8 territory — Member States must designate data protection authorities or bodies meeting the same independence conditions, with adapted procedures protecting operational confidentiality
• For AI systems used by Union institutions, the European Data Protection Supervisor takes the surveillance role

Authorities also report annually to the Commission and national competition authorities any information identified in the course of surveillance that may be of interest for competition law — a quiet but significant bridge between AI supervision and antitrust.

From Inspection to Correction: Articles 79 to 83

When surveillance finds a problem, a graduated procedure engages. Under Article 79, where an authority finds that an AI system presents a risk to health, safety or fundamental rights, it evaluates the system, requires the operator to take corrective action, withdraw or recall the system within a prescribed period, and — where non-compliance is not national in effect — informs the Commission and other Member States, triggering the Union safeguard procedure under Article 81 if objections arise. Article 80 handles misclassification: authorities can evaluate systems claimed under the Article 6(3) derogation and force reclassification into the high-risk regime. Article 82 covers compliant systems that nonetheless present risks, where authorities can require measures despite formal conformity. Article 83 addresses formal non-compliance — missing CE marking, absent registration, incomplete declaration of conformity — which must be corrected or the system restricted. Behind it all stand the Article 99 penalty ceilings and national sanctioning procedure.

Practical Steps for Providers and Deployers

1. Build a surveillance-response playbook: who receives an authority request, who assembles documentation, what the statutory deadlines are, and who approves source code discussions with the legal preconditions checked
2. Keep the Annex IV technical documentation, dataset records and logs in retrievable condition — full access means full access, and assembling evidence under deadline is where providers fail first
3. Engineer for remote inspection: the regulation contemplates API-based access for authorities; systems whose evidence is exportable on demand convert inspections from crises into correspondence
4. Know your authority allocation in every market — product regulator, financial supervisor or independent authority — and the cooperation routes between them
5. Treat complaints seriously upstream: any person can lodge a complaint with a market surveillance authority under Article 85, and complaint-driven inspection is the most common trigger for the whole machinery

Concrete Example

A provider sells an Annex III point 5(b) credit scoring system to lenders in three Member States. A consumer association files a complaint alleging discriminatory outcomes. The financial supervisor in the lead Member State opens a surveillance case: it requests the technical documentation and the bias examination records under Article 74's access powers, then demands evaluation runs on the validation datasets via the provider's API. The statistical evidence is ambiguous, documentation-based verification is exhausted, and the authority issues a reasoned request for source code access to inspect the feature engineering pipeline — the Article 74(13) conditions now satisfied. The inspection reveals a proxy variable problem; the authority requires corrective action under Article 79, the provider retrains and redocuments, the fix propagates to all three markets through the cooperation mechanisms, and no fine is imposed because the provider cooperated within deadlines at every step. Every fork in that story — deadlines met or missed, evidence retrievable or reconstructed, preconditions checked or waived — was determined by preparation done years earlier.

Action Before August 2, 2026

Market surveillance powers become fully operational against the high-risk regime on August 2, 2026, and authorities have been explicit that early enforcement will concentrate on prohibited practices, misclassification and the absence of basic conformity artefacts — the failures visible without deep inspection. The rational preparation order is therefore: verify registrations, declarations and CE marking first; make documentation retrievable second; rehearse the response playbook third. Surveillance is not an adversarial lottery — it is a procedure with defined powers, preconditions and appeal routes, and operators who know the procedure better than the inspector arrives knowing them hold a structural advantage that no amount of last-minute remediation can buy.

Deployers Are Inside the Surveillance Perimeter Too

A common misreading treats market surveillance as a provider problem. It is not. Deployers hold their own obligations under Article 26 — using systems per instructions, assigning oversight, retaining logs for at least six months, monitoring operation, suspending use and informing the provider and authorities when the system presents a risk — and every one of those duties is inspectable. Authorities investigating a complaint about a deployed system will typically approach the deployer first, because the deployer holds the operational records: who relied on which output, what the human reviewer saw, when anomalies appeared and what was done. Deployers should therefore maintain their own response capability, not assume the provider's compliance file covers them: a register of deployed high-risk systems with their registration numbers, the instructions for use actually followed, oversight assignments with training records, and the log retention pipeline verified end to end. The cooperation duty cuts across the value chain as well — Article 26 requires deployers to cooperate with competent authorities in any action those authorities take regarding the system. In the enforcement stories that will define this regulation's first years, the organisations caught flat-footed will rarely be the model developers, who have compliance teams and lobbying budgets; they will be the mid-sized employers, lenders and agencies that deployed someone else's system and assumed the paperwork lived elsewhere. A one-page internal standard — what we deploy, where it is registered, who watches it, where the logs live — is the cheapest insurance the AI Act era offers.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.