AESIA's Specialised Technical Guides To Support Compliance With The European Artificial Intelligence Act (Guides 13 & 14)

We continue our analysis of the second set of Specialised Technical Guides (Guides 3 to 15) published by the Spanish Artificial Intelligence Supervisory Agency (AESIA) to support compliance with the European Artificial Intelligence Act (AI Act).

On this occasion we take a look at the key aspects of Guides 13 and 14:

Guide 13: "Post-market monitoring plan"

Guide 13, entitled "Post-market monitoring plan", explains what post-market monitoring systems entail and why they are important in high-risk AI systems. These systems consist of a set of processes and tools that collect data from an AI system and translate them into a series of indicators that reflect how the system is operating, enabling monitoring after the system has been placed on the market. In practice, this allows providers to assess whether an AI system adequately meets the requirements applicable to high-risk systems. These systems operate through subsystems, including indicator capture systems, indicator logging systems, automated alert systems, and different analysis interfaces for those responsible for surveillance.

To help build an appropriate post-market monitoring framework, the Guide outlines the main phases involved in developing these systems as well as the components that must be included: 

Accordingly, the following measures/actions must be implemented to develop an effective post-market monitoring plan:

• Continuous monitoring of high-risk AI systems to ensure that the system continues to operate safely and effectively once placed on the market. The Guide notes that continuous monitoring – through monitoring system indicators, safety indicators, and by monitoring indicator variations via alerts, etc – is key to remain prepared for sudden changes to a system’s behaviour and for performance issues emerging from a range of factors, such as ageing training data or inadequate training. 
• Regular evaluation (periodic monitoring) to measure an AI system's performance and accuracy, which will make it possible to detect issues quickly and to take remedial action to correct them. Some of the measures used to assess a system’s performance and accuracy include: performance tests (which measure a system’s response time and its ability to handle large volumes of data (and accuracy tests (which measure a system’s accuracy when performing specific tasks, such as image object recognition or language translation).
• Transparent communication to the recipient of the information (eg, the provider, deployer, etc.) as to the system’s characteristics, its performance and the consequences of its use in production, so as to support a proper understanding of all use-case implications.
• Training for supervisors, providing them with basic training on how the AI system works and how it is used. 
• Flexibility through a flexible and scalable plan to enhance system monitoring, ie, adapting the system to internal and external changes that may impact operation. Measures to achieve this include identifying applicable regulations, assessing the system’s performance and security, identifying performance and security risks, monitoring compliance with existing regulations, establishing a contingency plan, etc.

Finally, the Guide notes that the other AESIA Guides must be taken into account when implementing a robust post-marketing monitoring system. This is why the final section of the Guide maps post-marketing monitoring systems against other AESIA Guides and explains the links between them.

Guide 14: "Reporting of serious incidents"

Guide 14, entitled "Reporting of serious incidents", sets out the procedural framework and operational measures that providers and, in certain cases, deployers must implement to comply with Article 73 of the AI Act.

The Guide highlights the following key operational aspects:

• Obliged parties: Providers bear primary responsibility for reporting incidents, regardless of geographical origin, provided that the system operates in the EU market. Deployers must notify the authorities if they detect the incident and are unable to contact the provider.
• Hierarchy of deadlines: An incident must be reported immediately after establishing a causal link between the system and the incident, according to the following deadlines:
  • 2 days: In the event of a widespread breach or an incident relating to critical infrastructure.
  • 10 days: If a fatality has occurred.
  • 15 days: In the case of all other serious incidents.
• Incremental reporting: To ensure prompt reporting, an initial incident report may be submitted even if it is incomplete, followed by a complete report once all the information has been gleaned.
• Exceptions for equivalent regimes: Where systems are subject to EU sector legislation with equivalent reporting obligations (including safety components of medical devices regulated by Regulations 2017/745 and 2017/746), reporting will be limited exclusively to incidents affecting fundamental rights. If the system operates in several Member States, the incident report must be addressed to all market surveillance authorities (MSAs) in the Member States concerned.

The Guide also identifies the following processes with a view to appropriate management:

1. Technical assessment and investigation: Once an incident has been reported, the provider must conduct a risk assessment without delay and implement corrective measures. The provider may not modify the system in a way that could affect the evaluation of the causes without first informing the pertinent authorities. The MSA then has 7 days to adopt appropriate measures, which may include the withdrawal or banning of the system, and must immediately notify the European Commission. If the incident affects fundamental rights, the MSA shall also inform the relevant national authorities.
2. Integration within governance and QMS: The procedure must be formalised within the provider’s Quality Management System (QMS). Key operational measures include: maintaining contact with the AVM; establishing a communication channel with the deployer (Art. 13.3.a); having an understanding of the system’s categorisation to determine whether exceptions apply; and understanding what constitutes fundamental rights under EU law so as to identify when a deviation amounts to a reportable breach. 

Ver post @Linkedin

Related links

• 'New AESIA Guidelines to support compliance with the AI Act' (02 February 2026)
  • AESIA introductory guides: Guides 1 & 2
  • AESIA's Specialised Technical Guides: Guides 3 & 4 | Guides 5 & 6 | Guides 7 & 8 | Guides 9 & 10 | Guides 11 & 12

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.