# Risk Management System — legal context bundle > Curated from overview.legal on 2026-08-22. Canonical page: https://overview.legal/topics/risk-management-system > Sources are cited per item. Verify against the official texts before relying on them. This new topic is needed because risk management systems are a distinct and mandatory requirement under the AI Act, encompassing systematic processes for identifying, assessing, mitigating, and monitoring risks throughout an AI system's lifecycle, which is not adequately covered by existing topics. ## Overview ## Legal Framework The AI Act establishes a dedicated risk management system obligation for high-risk AI systems in [Article 9](/laws/ai-act/art-9), making it one of the core compliance pillars alongside the quality management system in [Article 17](/laws/ai-act/art-17). Article 9 applies exclusively to high-risk AI systems and requires providers to establish, implement, document, and maintain a structured risk management process. [Article 8(1)](/laws/ai-act/art-8#par-1) explicitly ties compliance with all Section 2 requirements to the risk management system: > "The risk management system referred to in Article 9 shall be taken into account when ensuring compliance with those requirements." > — [AI Act Art. 8(1)](/laws/ai-act/art-8#par-1) The system is not a one-time assessment but a continuous obligation. Article 9(2) defines it as an iterative process spanning the entire lifecycle of the AI system, covering four sequential steps: identification and analysis of known and reasonably foreseeable risks; estimation and evaluation of risks under intended use and reasonably foreseeable misuse; evaluation of emerging risks through post-market monitoring data under [Article 72](/laws/ai-act/art-9#par-2); and adoption of appropriate, targeted risk management measures. Critically, Article 9(3) scopes the obligation to risks that can be reasonably mitigated through development, design, or adequate technical information — not all conceivable risks. The definition of "risk" in [Article 3(2)](/laws/ai-act/art-3#par-25) provides the operative threshold: ## Key Developments Because the AI Act is newly in force, no court has yet interpreted Article 9's risk management requirements. However, enforcement authorities have developed a mature risk-assessment methodology under the GDPR that provides a practical template. The EDPB's breach notification guidelines demonstrate how regulators calibrate "risk" using probability and severity — the same dual-axis definition the AI Act adopts. In one illustrative ransomware scenario involving a hospital, the EDPB concluded: > "The unavailability of the data has a high impact on a substantial part of the data subjects. Moreover, there is a residual risk of high severity to the confidentiality of the patient data." > — [EDPB Guidelines 01/2021 §37](/posts/38047#seg-37) Dutch courts have confirmed that supervisory authorities exercise discretion in enforcement — corrective measures are a power, not a mandatory obligation for every infringement. The Rechtbank held that GDPR Article 58(2) frames corrective measures as a competence rather than a duty, meaning authorities can prioritise based on risk severity. This enforcement-discretion framework will likely carry over to AI Act supervisory authorities when assessing whether a provider's risk management system is adequate. ## Status of the Debate This topic is **contested and actively emerging**. The AI Act's risk management obligation is doctrinally novel — it imposes a lifecycle-wide, iterative process that blends product-safety logic with fundamental-rights protection, a combination no prior EU instrument has operationalised in exactly this way. Courts have not yet ruled on Article 9, and no enforcement decisions have tested its boundaries. The open questions are: what constitutes "reasonably foreseeable misuse" in adaptive AI systems; how post-market monitoring data feeds back into risk evaluation; and how Article 9 interacts with the quality management system under [Article 17](/laws/ai-act/art-17). Resolution will likely come through the first wave of conformity assessments and supervisory authority enforcement decisions, potentially reaching courts when providers challenge corrective measures. ## Practical Guidance - **Treat risk management as a lifecycle process, not a pre-market checkpoint.** Article 9(2) requires regular systematic review and updating throughout the system's entire lifecycle — build feedback loops from post-market monitoring into your risk register. - **Document all four steps separately and sequentially.** Identify and analyse known risks (Art. 9(2)(a)), estimate and evaluate under intended use and foreseeable misuse (Art. 9(2)(b)), incorporate post-market data (Art. 9(2)(c)), and adopt targeted measures (Art. 9(2)(d)). Each step must produce auditable evidence. - **Scope risks to what is reasonably mitigable.** Article 9(3) limits the obligation to risks addressable through design, development, or technical information — do not over-include speculative risks that cannot be mitigated through these levers. - **Integrate with the quality management system.** [Article 17](/laws/ai-act/art-17) requires the QMS to cover design control, testing, and data management — align your risk management documentation with QMS procedures to avoid duplication and demonstrate coherence. - **Use the probability-severity matrix from Article 3(2).** Adopt the Act's own definition of "risk" as your internal scoring methodology, ensuring consistency between your risk assessments and the regulator's analytical framework. ## Legislation (full text of key provisions) ### Risk management system *Source: AI Act, aiact-art-9-en, 2024-06-12 — https://overview.legal/posts/92094* ### Recital 65 — high-risk AI risk management system *Source: AI Act, aiact-rec-65-en, 2024-06-12 — https://overview.legal/posts/93812* The risk-management system should consist of a continuous, iterative process that is planned and run throughout the entire lifecycle of a high-risk AI system. That process should be aimed at identifying and mitigating the relevant risks of AI systems on health, safety and fundamental rights. The risk-management system should be regularly reviewed and updated to ensure its continuing effectiveness, as well as justification and documentation of any significant decisions and actions taken subject to this Regulation. This process should ensure that the provider identifies risks or adverse impacts and implements mitigation measures for the known and reasonably foreseeable risks of AI systems to the health, safety and fundamental rights in light of their intended purpose and reasonably foreseeable misuse, including the possible risks arising from the interaction between the AI system and the environment within which it operates. The risk-management system should adopt the most appropriate risk-management measures in light of the state of the art in AI. When identifying the most appropriate risk-management measures, the provider should document and explain the choices made and, when relevant, involve experts and external stakeholders. In identifying the reasonably foreseeable misuse of high-risk AI systems, the provider should cover uses of AI systems which, while not directly covered by the intended purpose and provided for in the instruction for use may nevertheless be reasonably expected to result from readily predictable human behaviour in the context of the specific characteristics and use of a particular AI system. Any known or foreseeable circumstances related to the use of the high-risk AI system in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to risks to the health and safety or fundamental rights should be included in the instructions for use that are provided by the provider. This is to ensure that the deployer is aware and takes them into account when using the high-risk AI system. Identifying and implementing risk mitigation measures for foreseeable misuse under this Regulation should not require specific additional training for the high-risk AI system by the provider to address foreseeable misuse. The providers however are encouraged to consider such additional training measures to mitigate reasonable foreseeable misuses as necessary and appropriate. ### Recital 138 — national AI regulatory sandboxes for innovation *Source: AI Act, aiact-rec-138-en, 2024-06-12 — https://overview.legal/posts/93958* AI is a rapidly developing family of technologies that requires regulatory oversight and a safe and controlled space for experimentation, while ensuring responsible innovation and integration of appropriate safeguards and risk mitigation measures. To ensure a legal framework that promotes innovation, is future-proof and resilient to disruption, Member States should ensure that their national competent authorities establish at least one AI regulatory sandbox at national level to facilitate the development and testing of innovative AI systems under strict regulatory oversight before these systems are placed on the market or otherwise put into service. Member States could also fulfil this obligation through participating in already existing regulatory sandboxes or establishing jointly a sandbox with one or more Member States’ competent authorities, insofar as this participation provides equivalent level of national coverage for the participating Member States. AI regulatory sandboxes could be established in physical, digital or hybrid form and may accommodate physical as well as digital products. Establishing authorities should also ensure that the AI regulatory sandboxes have the adequate resources for their functioning, including financial and human resources. ### Recital 115 — systemic risk management for general-purpose AI *Source: AI Act, aiact-rec-115-en, 2024-06-12 — https://overview.legal/posts/93912* Providers of general-purpose AI models with systemic risks should assess and mitigate possible systemic risks. If, despite efforts to identify and prevent risks related to a general-purpose AI model that may present systemic risks, the development or use of the model causes a serious incident, the general-purpose AI model provider should without undue delay keep track of the incident and report any relevant information and possible corrective measures to the Commission and national competent authorities. Furthermore, providers should ensure an adequate level of cybersecurity protection for the model and its physical infrastructure, if appropriate, along the entire model lifecycle. Cybersecurity protection related to systemic risks associated with malicious use or attacks should duly consider accidental model leakage, unauthorised releases, circumvention of safety measures, and defence against cyberattacks, unauthorised access or model theft. That protection could be facilitated by securing model weights, algorithms, servers, and data sets, such as through operational security measures for information security, specific cybersecurity policies, adequate technical and established solutions, and cyber and physical access controls, appropriate to the relevant circumstances and the risks involved. ### Recital 155 — high-risk AI post-market monitoring systems *Source: AI Act, aiact-rec-155-en, 2024-06-12 — https://overview.legal/posts/93992* In order to ensure that providers of high-risk AI systems can take into account the experience on the use of high-risk AI systems for improving their systems and the design and development process or can take any possible corrective action in a timely manner, all providers should have a post-market monitoring system in place. Where relevant, post-market monitoring should include an analysis of the interaction with other AI systems including other devices and software. Post-market monitoring should not cover sensitive operational data of deployers which are law enforcement authorities. This system is also key to ensure that the possible risks emerging from AI systems which continue to ‘learn’ after being placed on the market or put into service can be more efficiently and timely addressed. In this context, providers should also be required to have a system in place to report to the relevant authorities any serious incidents resulting from the use of their AI systems, meaning incident or malfunctioning leading to death or serious damage to health, serious and irreversible disruption of the management and operation of critical infrastructure, infringements of obligations under Union law intended to protect fundamental rights or serious damage to property or the environment. ### Recital 164 — AI Office monitoring and enforcement powers *Source: AI Act, aiact-rec-164-en, 2024-06-12 — https://overview.legal/posts/94010* The AI Office should be able to take the necessary actions to monitor the effective implementation of and compliance with the obligations for providers of general-purpose AI models laid down in this Regulation. The AI Office should be able to investigate possible infringements in accordance with the powers provided for in this Regulation, including by requesting documentation and information, by conducting evaluations, as well as by requesting measures from providers of general-purpose AI models. When conducting evaluations, in order to make use of independent expertise, the AI Office should be able to involve independent experts to carry out the evaluations on its behalf. Compliance with the obligations should be enforceable, inter alia, through requests to take appropriate measures, including risk mitigation measures in the case of identified systemic risks as well as restricting the making available on the market, withdrawing or recalling the model. As a safeguard, where needed beyond the procedural rights provided for in this Regulation, providers of general-purpose AI models should have the procedural rights provided for in Article 18 of Regulation (EU) 2019/1020, which should apply mutatis mutandis, without prejudice to more specific procedural rights provided for by this Regulation. ### Recital 81 — provider quality management system *Source: AI Act, aiact-rec-81-en, 2024-06-12 — https://overview.legal/posts/93844* The provider should establish a sound quality management system, ensure the accomplishment of the required conformity assessment procedure, draw up the relevant documentation and establish a robust post-market monitoring system. Providers of high-risk AI systems that are subject to obligations regarding quality management systems under relevant sectoral Union law should have the possibility to include the elements of the quality management system provided for in this Regulation as part of the existing quality management system provided for in that other sectoral Union law. The complementarity between this Regulation and existing sectoral Union law should also be taken into account in future standardisation activities or guidance adopted by the Commission. Public authorities which put into service high-risk AI systems for their own use may adopt and implement the rules for the quality management system as part of the quality management system adopted at a national or regional level, as appropriate, taking into account the specificities of the sector and the competences and organisation of the public authority concerned. ### Recital 179 — regulation phased application dates *Source: AI Act, aiact-rec-179-en, 2024-06-12 — https://overview.legal/posts/94040* This Regulation should apply from 2 August 2026. However, taking into account the unacceptable risk associated with the use of AI in certain ways, the prohibitions as well as the general provisions of this Regulation should already apply from 2 February 2025. While the full effect of those prohibitions follows with the establishment of the governance and enforcement of this Regulation, anticipating the application of the prohibitions is important to take account of unacceptable risks and to have an effect on other procedures, such as in civil law. Moreover, the infrastructure related to the governance and the conformity assessment system should be operational before 2 August 2026, therefore the provisions on notified bodies and governance structure should apply from 2 August 2025. Given the rapid pace of technological advancements and adoption of general-purpose AI models, obligations for providers of general-purpose AI models should apply from 2 August 2025. Codes of practice should be ready by 2 May 2025 in view of enabling providers to demonstrate compliance on time. The AI Office should ensure that classification rules and procedures are up to date in light of technological developments. In addition, Member States should lay down and notify to the Commission the rules on penalties, including administrative fines, and ensure that they are properly and effectively implemented by the date of application of this Regulation. Therefore the provisions on penalties should apply from 2 August 2025. ### Recital 163 — scientific panel monitoring support for AI Office *Source: AI Act, aiact-rec-163-en, 2024-06-12 — https://overview.legal/posts/94008* With a view to complementing the governance systems for general-purpose AI models, the scientific panel should support the monitoring activities of the AI Office and may, in certain cases, provide qualified alerts to the AI Office which trigger follow-ups, such as investigations. This should be the case where the scientific panel has reason to suspect that a general-purpose AI model poses a concrete and identifiable risk at Union level. Furthermore, this should be the case where the scientific panel has reason to suspect that a general-purpose AI model meets the criteria that would lead to a classification as general-purpose AI model with systemic risk. To equip the scientific panel with the information necessary for the performance of those tasks, there should be a mechanism whereby the scientific panel can request the Commission to require documentation or information from a provider. ## Guidance ### Statement 3/2024 on data protection authorities’ role in the Artificial Intelligence Act framework *Source: EDPB, statement-32024-on-data-protection-authorities-role-in-the-en, 2024-07-16 — https://overview.legal/posts/125732 — original: https://www.edpb.europa.eu/documents/reports-statements-and-letters/statement-32024-on-data-protection-authorities-role-in-the_en* Final 1 Statement 3/2024 on data protection authorities’ role in the Artificial Intelligence Act framework Adopted on 16 July 2024 The European Data Protection Board has adopted the following statement: 1 BACKGROUND AND PURPO SE OF THIS STATEMENT 1. On 12 July 2024, Regulation (EU) 2024/1689 laying down harmonised rules on a rtificial i ntelligence (Artificial Intelligence Act, hereinafter the “ AI Act ”) and amending certain Union Legislative Acts was published in the Official Journal 1 . 2.… ### SPE Programma - AI Privacy Risks & Mitigations Large Language Models (LLMs) (Isabel BARBERÁ) *Source: EDPB, ai-privacy-risks-and-mitigations-in-llms, 2025-04-21 — https://overview.legal/posts/50754 — original: https://edpb.europa.eu/system/files/2025-04/ai-privacy-risks-and-mitigations-in-llms.pdf* "The AI Privacy Risks & Mitigations Large Language Models (LLMs) report puts forward a comprehensive risk management methodology for LLM systems with a number of practical mitigation measures for common privacy risks in LLM systems. In addition, the report provides use cases examples on the appli... ### EDPB Annual Report 2022 *Source: EDPB, edpb-annual-report-2022-en, 2023-04-17 — https://overview.legal/posts/125861 — original: https://www.edpb.europa.eu/documents/reports-statements-and-letters/edpb-annual-report-2022_en* EDPB Annual Report 2022 1 2022 ANNUAL REPORT STREAMLINING ENFORCEMENT THROUGH COOPERATION An Executive Summary of this report, which provides an overview of key EDPB activities in 2022, is also available. Further details about the EDPB can be found on our website at edpb.europa.eu. 1 GLOSSARY 4 2 FOREWORD 7 3 2022 – HIGHLIGHTS 9 3.1. ENFORCEMENT COOPERATION 9 3.1.1. Vienna statement on enforcement cooperation 10 3.1.2. Guidelines 02/2022 on the application of Art. 60 GDPR 10 3.1.3. Guidelines… ## Enforcement decisions ### EDPS finds Commission infringed purpose limitation and data transfer rules in Microsoft *Source: EDPS, 2024-03-08 — https://overview.legal/posts/125645 — original: https://gdprhub.eu/index.php?title=EDPS_-_2021-0518* Facts — Following an investigation in 2019-2020, the EDPS issued recommendations and the Commission modified the ILA. The EDPS investigated whether these modifications were sufficient to bring processing in compliance with data protection requirements and found infringements. Data accessed by Microsoft include identity and contact data of users (when signing on to the service and when checking the licenses), data generated by the users while using the software and data generated by Microsoft based on the usage of the software. The EDPS found that the processing presents significant risks as it monitors the behaviour of users, combines datasets and uses artificial intelligence. Reference date is the 12th May 2021, the date when the investigation was launched. Some measures were taken meanwhile by the Commission, which were taken into account in the recommendations issued. Holding — The EDPS found infringements with regards to purpose limitation, transfers to a third country and further, unathorised disclosure of personal data. Purpose limitation: The EDPS found that it was not sufficiently defined in the International License Agreement (ILA) which types of personal data are to be processed for which purposes. Instead, there was only a list of purposes stating that Microsoft uses these data for: troubleshooting billing remunerating Microsoft staff, internal reporting and business modelling, financial reporting following the use of the system for own reasons (analytics) to improve the service security risk management protection of intellectual property These stated purposes were considered to be too vague and general pursuant to the Art 29 WP. The Commission and Microsoft could not demonstrate that all these data were necessary and that a less intrusive collection of data would be insufficient to achieve the purposes cited. In addition, some of these purposes were actually not in the interest of the Commission but for purposes of individual to Microsoft (like remuneration of their personnel). In this case, the processor acts as controller; thus, these purposes and the data used for this purposes should have been precisely defined. Also, if data were used for purposes other than for which they were collected, the compatibility of these new purposes with the original ones should have been assessed. As a processor, Microsoft should have processed the personal data on documented instructions by the Commission. This was not ensured as the Commission did not issue sufficiently clear documented instructions to Microsoft. For example, though the Commission gave instructions for analytics and improvement of the service, these instructions were not sufficiently detailed and precise and did not exclusively concern uses of data for the purposes of the controller. Some instructions were given orally, but this was not enabled by the ILA and the oral instructions were not documented. The Commission did not assess whether it is necessary and proportionate to transmit data to Microsoft Ireland and its sub-processors. Further details of this infringement are given under the part on further unauthorised disclosure or personal data. Transfer to third countries : The Commission transferred personal data to Microsoft, a company established in the US. This raises questions about adequacy for such transfers to a third country. After the reference date, the Commission adopted the Transatlantic Data Privacy Framework (TDPF), which is an adequacy decision in respect of recipients in the US who register under this framework. The EDPS found that even when the software and data storage is property of Microsoft, it is directly transferred to these subcontractors and cannot therefore be covered by the TDPF to Microsoft US and onward transfer from Microsoft US to other subcontractors under SCCs. The EDPS found that in was not clearly specified in the ILA what types of personal data can be transferred to which recipients in which third country. The Commission also did not appraise the transfers and therefore could not determine whether any supplementary measures are necessary. In addition, the Commission should have performed a data transfer impact assessment and (as there are no SCCs applicable by EUIs as exporters) should have submitted the DPAs with these processors or subprocessors in third countries to the EDPS for approval. Because it failed to do this, the Commission did not implement effective supplementary measures for these transfers. Another issue was that the “EU storage guarantee” offered by Microsoft did not cover all types of data. Some data may be accessible to recipients in third countries. The “EU Data Boundary” also has numerous exceptions and exclusions which cover customer data, service generated data, diagnostic data and professional services data. Further unauthorised disclosure or personal data: A specific reference was made to Article 9 Regulation (EU) 2018/1725, which concerns transmission of personal data by EU institutions to recipients established in the EU. According to the EDPS, this article is also applicable to transmission of personal data to processors of EUIs. Therefore all transmission of personal data should be in the public interest and if the data subject’s legitimate interests may be prejudiced, the controller has to weigh the competing interests and establish that it is proportionate to transmit the personal data. The purpose of management and functioning of the Commission, use of products the staff is familiar with etc. was not found to be the purpose of processing of the personal data by MS. As long as the purposes are not specified, specific and explicit, it is not possible to do this balancing. In addition, the EDPS found that the Commission did not ensure that transfers take place “solely to allow tasks within the competence of the controller to be carried out”. The EDPS determined that organisational and contractual measures to restrict/prevent access of third country authorities were not sufficient, and that further technical measures are thus necessary. The EDPS also found that the organisational measures applied are only limiting transfers but does not ensure that transfers are protected. Further, the encryption is only found to be an adequate measure if the controller is in control of the encryption key. In this case, customers control the keys, but Microsoft has access to the encryption key, and thus, even when law does not oblige it to decrypt the data on an authority request, it may do it voluntarily. Also, the ILA does not detail encryption of data other than “customer data”, i.e. diagnostic data, service generated data or professional services data. The contract also enabled the processor not to notify the Commission about a request of disclosure also when EU or Member State law did not prohibit this notification and enabled recipients in third countries not to notify requests for disclosure also when the law prohibiting it did not constitute a necessary and proportionate measure in a democratic society respecting the essence of the fundamental rights and freedoms recognised by the Charter. ### Italian DPA: AgID's automatic transfer of PEC addresses to INAD index unlawful *Source: Garante per la protezione dei dati personali (Italy), 2026-05-28 — https://overview.legal/posts/122875 — original: https://gdprhub.eu/index.php?title=Garante_per_la_protezione_dei_dati_personali_(Italy)_-_419/2026* Facts — The data controller for the case is a government body called the Agency for Digital Italy (AgID). AgID is tasked with driving the adoption of digital technologies in both government and the private sector. Additionally, AgID is Italy’s soon-to-be notification authority for the AI Act. The case revolves around two public online indexes of certified email addresses: the INI-PEC and the INAD. INI-PEC is the older of the two indexes and includes, among others, the email addressess of professionals (the data subjects). INAD was created by AgID in 2023 as provided by Italian law and functions as an index of “digital domiciles” (where data subjects are supposed to get certain important communications) for both professionals and other owners of a digital email address. Shortly after setting up the INAD index, AgID automatically included the addresses of professionals from the old INI-PEC index. As a result, the addresses automatically became the digital domicile for communications not related to the professional lives of the data subjects. Data subjects were given the option to opt-out of the inclusion in the INAD index. Some data subjects complained that this processing severely infringed on their privacy. As the DPA’s decision explains, it is not uncommon for professionals to give co-workers access to their professional email addresses, on the assumption that they will only be used for strictly professional communications. When the addressess became digital domiciles, third parties (such as public bodies) started using them for communications unrelated to the data subjects' personal lives - which occasionally led to unintended data disclosures. The data subjects also claimed that the controller had not informed them about the processing, which prevented them from opting out in a timely fashion. Holding — The investigation — On the duty of information — First of all, the DPA clarified that by including email addresses in the INAD index, the controller further processed personal data for a new purpose, incompatible with the original purpose of the processing (i.e.: the inclusion of email addresses in the older index). With regards to the duty of information, the controller pointed out that it contacted professional orders to inform them about the creation of the INAD index. In the context of these communications, the controller asked professional orders to inform the data subjects about this processing of personal data and about their right to opt out. The controller stated that it did not directly contact the data subjects via their email addresses, as it feared that its emails would have been mistaken as phishing or scams . The controller later launched a more effective information campaign with the help of other government bodies; however, this campaign only took place in 2025 - two years after addresses where included in the INAD index. On the controller’s identity — The DPA’s investigation also focused on a second issue, relative to the authentication procedure for digital domiciles: for a long time, a company (InfoCamere S.c.p.a.) was erroneously listed as a service provider for the INAD index. During the investigation, the controller confirmed that InfoCamere had no role in the processing of personal data. The controller also stated that it had contacted the actual service provider in order to correct the error and that the provider had done so with great delay. The DPA's conclusion — The DPA held that until 2025, the controller had failed to inform the data subjects about the inclusion of their email address in the INAD index, in violation of Articles 5(1)(a), 5(1)(b), 5(2), 12, 14 and 25 GDPR. On these grounds, the DPA fined the controller €55,000. With regards to the erroneous indication of the service provider in the authentication screen, the DPA found that the mistake was isolated and that overall, the information provided during the procedure was still sufficient to clarify that AgID was the controller. On these grounds, the DPA found that the mistake did not, in and of itself, constitute a violation of the GDPR. ### Italian DPA sanctions Lusha Systems for processing contact data without consent in B2B *Source: Garante per la protezione dei dati personali (Italy), 2026-07-14 — https://overview.legal/posts/184678 — original: https://gdprhub.eu/index.php?title=Garante_per_la_protezione_dei_dati_personali_(Italy)_-_542/2026* Facts — Lusha Systems Inc. (the controller) operated a subscription-based platform that provided professional contact information through a business-to-business (B2B) database. It was an US company wholly owned by Lusha Systems Ltd. In April 2025, the Italian DPA (Garante) initiated an investigation after media reports revealed that telephone numbers of senior Italian officials were available on the platform. The DPA later received one complaint and one report from data subjects who had received unsolicited advertising communications. The data subjects further stated that after requesting information about the source of their contact details, they discovered that their data were available on the controller’s platform without their consent. The controller explained that, for a subscription fee, it provided its Clients with a Business Contact Card for each Contact. The controller further distinguished between “Clients”, namely customers who used the platform and accessed its B2B database, and “Contacts”, namely the individuals whose personal data were included in that database, regardless of whether they used or were aware of the platform. Clients received Contact Cards containing information such as names, professional email addresses, telephone numbers, job titles, roles and locations, which could be used for sales, marketing, recruitment, business intelligence and fraud prevention. The DPA limited its investigation to the processing of Contacts’ personal data. The controller stated that it collected and combined data from publicly available sources, specialised providers, affiliated companies and commercial partners. It also inferred missing professional email addresses through algorithms that identified standard company email patterns. Through its Community Program and integrations with email, calendar and CRM services, it could also obtain information from Clients’ professional networks and communications. The data were cross-referenced, enriched and regularly updated to reflect changes in Contacts’ professional circumstances. The controller argued that the GDPR did not apply because it was established outside the EU and provided services only to businesses. It additionally claimed that the weekly updating of Contact Cards ensured accuracy rather than constituting monitoring or profiling. The controller maintained that the collection and disclosure of the data were necessary for its own economic interest in providing accurate professional contact information and for its Clients’ interests, including fraud prevention. According to the controller, it processed only a limited range of information concerning the Contacts’ professional lives. It further claimed that individuals who made professional information publicly available, particularly through services such as LinkedIn, could reasonably expect that the information might be reused and that they could be contacted regarding professional opportunities. Regarding transparency, the controller stated that its Personal Information Notice was sent to each Contact before their information became available in the database. It explained that it notified Contacts that they had a seven-day period during which they could opt out before their information became available to Clients. The controller also maintained that excluding public officials and public figures from the database was not a requirement under the GDPR. It attributed the presence of certain public officials to technical limitations in its filtering system. It also argued that public figures had a lower expectation of privacy. After the proceedings began, the controller removed profiles connected with Italian public bodies and officials, strengthened its filters and customer-verification measures, discontinued the Community Program in Italy and extended the opt-out period to fourteen days. Holding — Regarding the territorial scope of the GDPR, the DPA acknowledged that Article 3(2)(a) GDPR could apply to the processing of Clients’ data, but not to Contacts, since they were not recipients of the service. However, it held that Article 3(2)(b) GDPR applied because the controller systematically combined, enriched and updated Contacts’ professional information in order to assess their circumstances and determine whether and how they would appear in the database. Referring to Recital 24 and Recital 30, the DPA held that monitoring did not require profiling. It noted that the systematic observation of online traces and changes in a person’s professional situation was sufficient. The fact that the processing also served data accuracy did not alter that conclusion. It emphasised that the fact that the controller also updated the information to ensure its accuracy did not prevent the processing from constituting monitoring. Regarding transparency, the DPA found that the information concerning the collection of the Contacts’ data, the purposes of the processing and the legal basis relied upon was scattered across several documents. Also, the relevant information was not easily accessible from the controller’s homepage, while the Personal Information Notice could not be located directly through the website without prior knowledge of its existence. It further pointed out that the documents were provided in English rather than in the language of the affected data subjects. The DPA held that presenting the information in this manner did not satisfy the requirement that information be concise, transparent, intelligible and easily accessible. It therefore found an infringement of Article 5(1)(a) GDPR and Article 12 GDPR. Moreover, the DPA assessed whether Article 6(1)(f) GDPR provided a valid legal basis for the processing. It examined the controller’s Legitimate Interest Assessment and considered it essentially non-existent, as it contained only generic statements on necessity and proportionality and no genuine balancing assessment. The DPA then applied the three-part test under Article 6(1)(f) GDPR. It held that making the Contacts’ data available to Clients for their own marketing and sales activities could not constitute a legitimate interest, since the disclosure of contact information to third parties for their independent advertising purposes required prior consent under the applicable national and ePrivacy framework . However, it acknowledged that the controller’s interest in fraud prevention could be considered legitimate. The DPA nevertheless found that the processing was not necessary for the purposes pursued. It held that the controller collected information extending beyond ordinary professional contact details, including third-party data contained in CRM databases, email headers and subject lines, information about calendar meetings, and browsing data collected through browser extensions or other software integrations used by Clients. It pointed out that much of this information was not publicly available but was extracted from private interpersonal communications, disclosed by Clients, obtained through integrations with information systems or acquired from third-party providers. The DPA held that the collection and combination of such extensive information was neither strictly necessary nor proportionate for creating professional Contact Cards. Furthermore, it stressed that fraud prevention could also have been achieved through less intrusive means. The DPA therefore concluded that the necessity requirement and the principle of data minimisation were not met. Regarding the balancing test, the DPA emphasised that there was no prior relationship between the controller and the Contacts. Creating a professional profile on LinkedIn or another professional platform did not create a reasonable expectation that unpublished contact details would be collected from multiple sources, continuously updated and disclosed to an unspecified number of paying customers. It further noted that the processing could expose Contacts to communications from unknown third parties for purposes they could not reasonably anticipate. The DPA concluded that the Contacts’ interests, rights and freedoms prevailed over the controller’s economic interests and that the safeguards adopted by the controller could not change this outcome. Therefore, the DPA held that Article 6(1)(f) GDPR did not provide an appropriate legal basis and found that the controller infringed Article 5(1)(a) GDPR, Article 5(1)(c) GDPR, and Article 6 GDPR. Regarding public officials, the DPA held that their status did not reduce their entitlement to data protection and that no public interest justified disclosing their direct contact details for commercial purposes. The DPA further found that the controller had been aware of the risk that public officials could be included in its database but had failed to implement sufficiently effective technical and organisational measures. Its filters recognised general titles such as “President” but failed to exclude more specific titles such as “President of the Italian Republic” and “Vice Prime Minister”. The DPA therefore found an infringement of the principle of data minimisation under Article 5(1)(c) GDPR and the obligation of data protection by design and by default under Article 25 GDPR. The DPA imposed a fine of €2,000,000. Furthermore, it prohibited any further processing of personal data of data subjects located in Italy that had been collected without an adequate legal basis and ordered their deletion. ## Recent developments ### One-Stop-Shop case digest on right to object and right to erasure updated *Source: European Data Protection Board, 2026-06-25 — https://overview.legal/posts/53055 — original: https://www.edpb.europa.eu/news/one-stop-shop-case-digest-on-right-to-object-and-right-to-erasure-updated_en* Brussels, 25 June - The EDPB has published an update of the One-Stop-Shop (OSS) case digest on right to object and right to erasure. This project has been developed in the framework of the of the Support Pool of Experts programme, which aims to support cooperation among Data Protection Authorities (DPAs).Thematic one-stop-shop case digests are drafted on the basis of one-stop-shop decisions taken from the EDPB’s public register (based on Art.60 GDPR). Such case digests complement the EDPB's publ ### Is the AI Act caging ChatGPT and other General Purpose Artificial Intelligence systems? *Source: Gaming Tech Law, 2023-03-29 — https://overview.legal/posts/6223 — original: https://www.gamingtechlaw.com/2023/03/draft-ai-act-general-purpose-artificial-intelligence/#entry-4244* > The growth of generative artificial intelligence systems has led EU lawmakers to focus on General Purpose AI in drafting the AI Act, which will set the framework governing artificial intelligence in the European Union. As previously reported, the EU Parliament has already broadened the definition of artificial intelligence for the purposes of the AI Act… ### Het reguleren van de risico's van kunstmatige intelligentie. *Source: SSRN, 2022-08-22 — https://overview.legal/posts/51837* Dit artikel stelt dat het beschouwen van de negatieve gevolgen van kunstmatige intelligentie als risico's een bewuste keuze is met gevolgen. Risicobeheer brengt zijn eigen specifieke uitdagingen met zich mee: een verzameling van instrumenten en problemen die in andere vakgebieden zijn ontstaan. Bovendien zijn er minstens vier modellen voor risicobeheer, elk met verschillende doelen en methoden. De opkomende conflicten over de regulering van de risico's van kunstmatige intelligentie illustreren de spanningen die ontstaan wanneer toezichthouders één model van risicobeheer hanteren, terwijl belanghebbenden een ander model voorstellen. ### CJEU: PNR Directive Valid if Limited to the “Strictly Necessary” *Source: eucrim, 2022-08-04 — https://overview.legal/posts/6292 — original: https://eucrim.eu/news/cjeu-pnr-directive-valid-if-limited-to-the-strictly-necessary/#entry-388* > In a landmark ruling of 21 June 2022, the CJEU (Grand Chamber), upheld the EU’s regime to collect and use records of travellers, provided that it is strictly interpreted in line with the EU’s fundamental rights. In addition, indiscriminate processing of the data in cases of flights carried out only within the EU is banned unless there is a threat of terrorism. In general, the passengers’ data must also be deleted after six months at the latest. ## Literature ### REGULATION OF APPLIED ARTIFICIAL INTELLIGENCE IN BIOMEDICAL ENGINEERING AS A HIGH-RISK ARTIFICIAL INTELLIGENCE SYSTEM IN THE EU AI ACT *Source: AFMN Biomedicine, 2026-07-13 — https://overview.legal/posts/132435 — original: https://doi.org/10.65641/afmnai-2026-075* lt;p style= quot;text-align: justify; quot; gt; lt;span class= quot;a_GcMg font-feature-liga-off font-feature-clig-off font-feature-calt-off text-decoration-none text-strikethrough-none quot; gt;Artificial intelligence (AI) represents a global phenomenon changing all spheres of human life. Biomedical engineering is no exception, as many AI systems are applied to biomedical engineering inventions. The European Union has enacted the new EU AI Act, one of the world amp;rsquo;s first laws on AI. The ### The ethics of regulation: Social contract insights on the 2024 European Union Artificial Intelligence Act *Source: Ethics & bioethics, 2026-07-06 — https://overview.legal/posts/83515 — original: https://doi.org/10.2478/ebce-2026-0014* Abstract The paper provides a critical analysis of the EU AI Act (Regulation 2024/1689) within the broader context of contemporary AI developments. Starting from an historical overview on the development of advanced AI systems, it moves the focus onto the intrinsic meaning of Artificial Intelligence to highlight how, despite such fascinating wording, there cannot be a shift of responsibility onto the systems themselves—as was proposed, for example, by the European Parliament resolution of 16 Feb ### Italy’s Artificial Intelligence Act and Global AI Governance: The EU Model’s Practice and Prospects *Source: Law and Economy, 2026-02-25 — https://overview.legal/posts/132619 — original: https://doi.org/10.63593/le.2788-7049.2026.03.004* The Italian Artificial Intelligence Act, enacted on September 17, 2025, represents the first comprehensive national implementation of the European Union’s AI Act. This study examines the Italian legislation through the theoretical lens of multi-level governance, analyzing its dual function as both a “bridging legislation” that translates EU framework into domestic practice and a site of significant regulatory innovation. Through detailed textual analysis and case studies, particularly in healthc ### Eu regulatory ecosystem for ethical AI *Source: AI and Ethics, 2025-06-02 — https://overview.legal/posts/53866 — original: https://doi.org/10.1007/s43681-025-00749-x* Abstract AI applications raise complex ethical, legal, and security challenges that demand comprehensive and coordinated governance at multiple levels. In this paper, we examine how key European Union (EU) regulatory frameworks, such as the AI Act, GDPR, and NIS2, interact to set standards for AI security, functionality, and ethical performance. By comparing the objectives and requirements outlined in these regulatory instruments, we identify points of convergence that encourage a holistic appro ### A Comparative Analysis of the EU AI Act and the Colorado AI Act: Regulatory Approaches to Artificial Intelligence Governance *Source: International Journal of Computer Applications, 2024-09-26 — https://overview.legal/posts/132613 — original: https://doi.org/10.5120/ijca2024923954* International Journal of Computer Applications (0975 – 8887) Volume 186 – No. 38 , September 2024 23 A Comparative Analysis of the EU AI Act and the Colorado AI Act: Regulatory Approaches to Artificial Intelligence Governance Mayur Jariwala School of Computer and Information Sciences, University of the Cumberlands, Williamsburg, KY, USA ABSTRACT This comparative study examines the EU AI Act and the Colorado AI Act, focusing on their regulatory approaches to artificial intelligence. The EU AI Act provides a comprehensive framework with a risk - based classification, emphasizing transparency, accountability, and the protection of fundamental rights across diverse sectors. It aims to set a global benchmark for AI governance, influencing international standards. The Colorado AI Act targets high - risk AI systems, prioritizing consumer protection, fairness, and the prevention of algorithmic discrimination. It mandates detailed documentation, ri sk management, and transparency measures to ensure ethical AI deployment. This analysis explores the impacts of each act on innovation, industry practices, and consumer protection, as well as their potential global influence. The findings highlig ## Related topics - **Monitoring Actions under AI Act** — https://overview.legal/topics/monitoring-actions-ai-act The content specifically addresses 'Monitoring actions' as a distinct topic under the AI Act, which encompasses systematic oversight procedures, compliance veri - **Post-Market Monitoring for AI Systems** — https://overview.legal/topics/post-market-monitoring-ai Risk management systems require ongoing post-market monitoring to identify and respond to risks that emerge during real-world deployment. This is a distinct and - **Artificial Intelligence** — https://overview.legal/topics/ai AI systems and their implications for data protection - **AI Corrective Actions** — https://overview.legal/topics/corrective-actions-ai This new topic is needed because corrective actions are a specific and distinct obligation under the AI Act that encompasses systematic procedures for addressin - **Provider Obligations for AI Systems** — https://overview.legal/topics/provider-obligations-ai The content specifically addresses obligations imposed on providers of high-risk AI systems, which is a distinct and important category of requirements that des - **Monitoring** — https://overview.legal/topics/monitoring Systematic observation and tracking of individuals --- Generated by overview.legal · https://overview.legal/topics/risk-management-system · 2026-08-22