It is worth starting with a basic premise: the AI Act, NIS2 and the GDPR have long since ceased to operate in isolation from one another.
Nowadays, determining which obligations apply to you depends partly on the size of your business, partly on the sector in which you operate and, increasingly, on the role you play within the supply chain.
The good news is that, once you’ve looked at the big picture, you realise that although many regulatory requirements use different terminology, they essentially ask for similar things.
Let’s see where the three frameworks actually overlap.
Risk management: one requirement, three languages
Article 9 of the AI Act requires risk to be managed throughout the entire lifecycle of high-risk systems. NIS2 calls for technical, operational and organisational measures to address risks to information systems. ISO 27001, for those with a structured ISMS, sets out similar controls in Annex A.
Three standards, a single underlying principle: identify, assess, mitigate, document.
If you already have a well-established risk assessment process for NIS2 or ISO 27001, you’re off to a good start: you have a solid foundation on which to build AI Act compliance as well. It’s not a case of starting from scratch, but rather of expanding the scope of your risk management to include artificial intelligence systems.Safety by design
Article 15 of the AI Act stipulates that high-risk systems must be designed with adequate levels of accuracy, robustness and cybersecurity. Control A.8 of ISO 27001 and the technical requirements of NIS2 say the same thing in different words: security must be built in at the design stage, not tacked on afterwards. It is worth remembering this because AI systems bring with them new and not always intuitive risk vectors — prompt injection, data leakage through integrations, poorly controlled access to repositories, and an extended supply chain. In other words, it may be useful to treat AI as a component of critical infrastructure, not as just any software.
Documentation and audit trail
This is perhaps the area where the convergence is most evident. The GDPR requires a record of processing activities and a DPIA for high-risk processing operations; NIS2 mandates logging, periodic audits and the traceability of measures taken; the AI Act adds technical documentation of the system, automated logging records for high-risk operations and the traceability of decisions. Three requirements which, if managed using separate tools, risk multiplying the workload: it is often advisable to consider a single documentation system that meets all three.
Incident reporting: the most sensitive issue
Here, the advice is to be careful, as a single incident can trigger multiple reporting obligations to different authorities. Article 73 of the AI Act requires the reporting of serious incidents to market supervisory authorities; Article 33 of the GDPR requires notification to the Data Protection Authority (within 72 hours); added to these are the NIS2 obligations towards the ACN, with their own timelines and trigger thresholds. The deadlines do not align, and this is the real sticking point: those without integrated and well-documented escalation procedures risk managing the emergency in a piecemeal fashion, with the dual drawback of exposing themselves to non-compliance and exacerbating the damage. Preparing in advance a matrix setting out ‘which incident → which notifications → by when’ is one of those investments that pays off at the first serious incident.
Further considerations on the AI Act
It is worth adding a few points to broaden the discussion, particularly in relation to the AI Act.
The timetable set out in Article 73 (the ‘phased’ scheme)
It is worth being precise, as there is no single deadline. The report must be made without undue delay and, in any event, within 15 days for serious incidents in general, within 10 days in the event of a fatality, and within 2 days in the event of a widespread breach or a serious and irreversible disruption to critical infrastructure. An initial incomplete report is also permitted, to be supplemented at a later date. This helps to calibrate internal escalation procedures for the worst-case scenario.
Risk classification
Once the inventory has been compiled, each system must be classified in accordance with the taxonomy used by the AI Act. This classification determines which obligations apply and with what degree of urgency
The possible relaxation of the “triple notification” requirement
A useful point regarding overlaps: the European Commission’s draft guidelines (published in September 2025 and open for consultation until November 2025) provide for a simplified regime for sectors already subject to equivalent reporting obligations. In practice, for sectors where equivalent reporting already exists — such as critical infrastructure subject to NIS2 — the obligation under Article 73 would apply only to breaches of fundamental rights, whilst other incidents would need to be reported in accordance with sector-specific rules. As this is a draft under consultation, it is advisable to keep an eye on it when designing procedures, without treating it as definitive just yet.
The general timeline for implementation
The requirements for high-risk systems, including Article 73, will come into force in August 2026. There is therefore a window of opportunity to prepare the system at a leisurely pace, but now is also the right time to do so, before the deadlines become binding.
Another point to bear in mind: the FRIA
Alongside the GDPR’s DPIA, the AI Act introduces, in certain cases, a fundamental rights impact assessment (FRIA, Article 27), which applies in particular to data controllers that are public bodies and to certain private entities. This represents a further opportunity for potential synergy with the DPIA in terms of documentation, as the two assessments share some of the same rationale and source data.
Do you have any doubts or questions about the AI Act, NIS 2 and the GDPR?
Get in touch and we’ll be happy to help!