An EU AI Act audit rarely starts with regulators demanding to see source code, but it starts with paperwork. Article 74 sets out what a market surveillance authority can actually request from a provider of a high-risk AI system, and it draws a clear line between what’s available on request and what requires a much higher bar to reach.
The first tier is broad: full access to technical documentation and to the training, validation, and testing datasets used to build the system, provided on request, including through an API or other remote access method where appropriate. The second tier, access to the system’s actual source code, is deliberately harder to reach. It’s only available on a reasoned request, and only where two conditions are both met: the authority needs it specifically to assess compliance with the Chapter III, Section 2 requirements, and testing or auditing based on the documentation already provided has been exhausted or proved insufficient. In practice, this means an organisation that can produce clean, complete documentation and datasets on request is unlikely to ever reach the source code stage at all.
Two tiers of access
| Tier | What’s requested | Legal basis | Threshold to reach it |
|---|---|---|---|
| 1. Data and documentation | Technical documentation, and the training, validation, and testing datasets used to develop the system | Article 74(12) | Available on request, limited to what’s necessary for the authority’s task |
| 2. Source code | The system’s actual source code | Article 74(13) | Only on reasoned request, and only where access is necessary to assess Chapter III compliance, and testing based on documentation already provided has proved insufficient |
The gap between the two rows is the point. Tier 1 is the default and covers almost every request an authority makes. Tier 2 only becomes relevant once Tier 1 has already happened and turned out not to be enough.
Other ways an investigation can start or widen
A complaint is one of the most direct routes into a review: any person can lodge a complaint with a market surveillance authority under Article 85. Separately, national bodies that supervise fundamental rights protections, such as non-discrimination authorities, have their own power under Article 77 to request documentation directly for Annex III high-risk systems, and where that documentation doesn’t settle the question, to ask the market surveillance authority to organise technical testing of the system. For high-risk AI systems used by financial institutions, the market surveillance authority isn’t a separate AI-specific body at all, it’s the same national authority that already supervises that institution under EU financial services law.
What happens if the authority finds a problem
Where a market surveillance authority has reason to believe a high-risk system presents a risk, Article 79 sets out the national-level procedure for addressing it, which can range from requiring corrective action to restricting or withdrawing the system from the market. Sustained or serious non-compliance is what feeds into the fine tiers under Article 99, covered in full in EU AI Act fines explained. Which authority actually runs this process depends on the system in question, covered in Who enforces the EU AI Act.
Where the Digital Omnibus changes the compliance timeline
Article 74’s market surveillance powers sit in Chapter IX, which follows the Act’s general default timeline rather than the accelerated 2 August 2025 date given to the governance and penalties chapters. In practice, a market surveillance authority’s power to request a specific piece of documentation only bites once the underlying obligation to produce that documentation is itself binding, which for stand-alone Annex III high-risk systems is now 2 December 2027, and for Annex I embedded systems 2 August 2028, following the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026.
Deeploy documents AI use for organisations
The organisations that struggle most in this kind of review are rarely the ones with the most complex systems, they’re the ones whose documentation and datasets aren’t in a state to be handed over on request. Deeploy keeps technical documentation, model cards, and monitoring evidence current and organised as a system runs in production, so a Tier 1 request under Article 74(12) can be answered directly, which is also the single best way to make sure a Tier 2 source code request never becomes necessary in the first place.
Frequently asked questions
Technical documentation and the training, validation, and testing datasets used to develop the system, under Article 74(12). This is the default, broadly available request, distinct from the much narrower source code access under Article 74(13).
Only under specific conditions. Access to source code requires a reasoned request, and is only granted where it's necessary to assess compliance with the Chapter III, Section 2 requirements, and where testing or auditing based on documentation already provided has been exhausted or proved insufficient.
Often from a complaint lodged with a market surveillance authority under Article 85, though authorities also carry out proactive market surveillance under their general powers, and a separate fundamental rights authority can trigger a review under Article 77 for Annex III systems.
Not quite. Article 74's documentation and source code powers are aimed primarily at providers, since they hold the technical documentation, datasets, and source code an authority needs to assess compliance. Deployers face a narrower cooperation duty under Article 26(12), and in practice are asked for whatever they specifically hold: the six-month logs under Article 26(6), oversight records under Article 26(2), and the Fundamental Rights Impact Assessment where one applies. A deployer that has substantially modified the system stops being treated as a deployer at all for that system, taking on the full provider-level exposure instead.
