Conformity assessment vs. internal audit: not the same thing
Before getting into the "how," it's worth clearing up a common mix-up, because these are two different exercises with two different purposes.
The conformity assessment (Article 43) is a formal, one-off procedure: it happens before a high-risk system goes to market, and its output is the EU declaration of conformity and CE marking. In some cases it requires the involvement of an external notified body. Once passed, the system can be placed on the market.
The internal compliance audit — the subject of this article — is different: a continuous governance process the company itself organizes to verify it keeps complying throughout the system's lifecycle, not just at the moment it goes to market. The AI Act doesn't literally name this as a specific procedure with that label; it follows from the obligation to keep several management systems "alive" — the risk management system (Article 9), the quality management system (Article 17), post-market monitoring — all of which require constant review and updating, not a one-time snapshot.
The 5 documentation blocks the audit should review
An internal AI Act compliance audit doesn't start from scratch: the Regulation itself already requires five documentation blocks to be kept up to date, and they're the natural starting point for checking what's missing or out of date.
| Element | What it requires |
|---|---|
| Technical documentation (Annex IV, Art. 11) | Description of the system and its intended purpose, methodology and architecture, training data (provenance and labeling), assessment of human oversight, validation and testing procedures, capabilities and limitations, description of the risk management system, log of changes throughout the lifecycle, harmonized standards applied, a copy of the EU declaration of conformity, and the post-market monitoring plan. |
| EU database registration (Art. 71) | Providers must register high-risk systems under Annex III — including those self-assessed as NOT high-risk under Article 6(3), with that decision justified. Public-sector deployers must also register their use of the system. |
| Automatic event logs (Art. 12) | High-risk systems must support automatic recording of events ("logs") throughout their operational lifetime, to help identify risks or substantial modifications, facilitate post-market monitoring, and support monitoring of the system's operation (Art. 26(5)). |
| Risk management system (Art. 9) | A continuous, iterative process — identification, evaluation, mitigation, and testing against predefined metrics and thresholds — that must be documented and maintained, not a one-time assessment. |
| Quality management system (Art. 17) | Compliance strategy, change management, design control, testing procedures, data management, a post-market monitoring system, serious incident reporting, and document retention — proportionate to the size of the organization, lighter-weight for SMEs and startups. |
Who can actually ask you for this in Spain
The market surveillance authority designated for the AI Act in Spain is AESIA (Agencia Española de Supervisión de Inteligencia Artificial — the Spanish AI Supervision Agency), created in August 2023. AESIA appears on the European Commission's official list of market surveillance authorities designated per Member State, but it's worth being precise here: on that list it's flagged with an asterisk noting that, as of the source consulted, the national formal designation decision was still pending final adoption.
In parallel, Spain is processing the draft Organic Law on the good use and governance of artificial intelligence ("Proyecto de Ley Orgánica para el buen uso y la gobernanza de la inteligencia artificial"), approved by the Council of Ministers on May 26, 2026 and in parliamentary process in Congress since June 2026, which would legally consolidate AESIA's role. The model it proposes is decentralized: AESIA as the lead authority and single point of contact with the EU, coordinated with sectoral authorities — data protection authorities for biometrics, judicial authorities for AI used in the justice system, financial regulators for solvency matters.
In practice, this means AESIA is the reference point to have on your radar when preparing an internal audit, but its role is in the process of legal consolidation, not yet fully operational with an established enforcement track record. Worth keeping an eye on how that law progresses through the rest of 2026 and 2027.
What's at stake if you skip it
Article 99 sets three tiers of penalties depending on the type of breach, and they apply to both providers and deployers — the company using the system, not just the one that built it:
| Violation | Maximum penalty |
|---|---|
| Prohibited practices (Art. 5) | €35,000,000 or 7% of total worldwide annual turnover, whichever is higher. |
| Non-compliance with other obligations (high-risk, transparency, etc.) | €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. |
| Incorrect, incomplete, or misleading information to authorities | €7,500,000 or 1% of total worldwide annual turnover, whichever is higher. |
One important nuance: for SMEs and startups, the lower of the two figures applies — the opposite of large companies, where the higher one applies. Even so, it's not a small number: a well-run internal audit is, above all, how you catch and fix these gaps before a market surveillance authority does.
How to set up the internal audit: 4 steps
Step 1 — Define the scope: which systems to audit first
You don't need to audit everything at once. Start with the high-risk systems under Annex III, plus anything you already suspect has incomplete or outdated documentation.
Step 2 — Gather the documentation for all 5 blocks
For each system in scope: technical documentation (Annex IV), EU database registration status, evidence that automatic logs are active, and the latest review of both the risk management system and the quality management system.
Step 3 — Set the cadence (quarterly/half-yearly)
The Regulation doesn't set a fixed frequency, but since these are iterative processes by definition (Art. 9), it's worth setting a recurring calendar — quarterly or half-yearly depending on how many systems you have — plus a mandatory extra review whenever a substantial change occurs.
Step 4 — Document findings and a corrective action plan
Every audit should leave a trail: what was missing, what got fixed, who's responsible, and by when. That trail is also the first thing a market surveillance authority will ask for if an inspection happens.
Frequently asked questions
How often should the internal audit be done?
The Regulation doesn't set a fixed frequency, but it does require the risk management system (Article 9) to be a continuous, iterative process; in practice, many organizations run it on a quarterly or half-yearly cycle, plus a mandatory review whenever a system undergoes a substantial modification.
Do we need a notified body for the internal audit?
No. A notified body only gets involved in the conformity assessment (Article 43) before the system goes to market. The internal compliance audit is an ongoing process the organization runs itself, with no mandatory third-party involvement.
If we find a system that should be registered in the EU database and isn't, what do we do?
Register it immediately as a priority corrective action — it's an obligation the market surveillance authority can verify directly (Article 71).
If we're an SME, does that mean less documentation?
Article 17 requires the quality management system to be proportionate to the size of the organization — same substantive content, an adapted level of formality, not a substantive exemption.