According to Gartner, 78% of European organisations deployed at least one generative AI tool in production in 2025. Fewer than a third have updated their information security policies accordingly. The gap is not trivial: NIS2 requires documented risk management across all information systems, and AI tools fall squarely within that scope. Here are the three vectors that GRC teams systematically overlook, and how to address them in practice.
The regulatory context: NIS2 and AI, an intersection not yet mapped
The NIS2 Directive, transposed into national law across Europe since late 2024, requires entities within its scope to document their risk management for information systems and networks. Article 21 explicitly lists, among the required measures, supply chain security, access management, and control of the software assets used in critical processes.
Generative AI falls within this scope in three respects: as a tool used by employees (usage risk), as a component of automated systems (integration risk), and as a potential target of adversarial attacks (exploitation risk). These three dimensions constitute as many risk vectors that security policies drafted before 2024 structurally did not anticipate.
The EU AI Act, progressively in force since 2025, creates a complementary regulatory layer for high-risk systems, but does not replace NIS2. The two texts overlap: an AI system used in a compliance or risk management process may be subject to both frameworks simultaneously. This intersection is still rarely addressed in the GRC programmes of mid-market organisations.
Vector 1: data leakage through prompts, shadow AI under NIS2
The first vector is the most widespread and the least documented in risk registers. Employees use consumer AI tools (web interfaces of language models, writing assistants, data analysis tools) and inject internal data into them: client contracts, HR data, audit reports, strategic plans.
These uses constitute data transfers outside the organisation's security perimeter. Under NIS2, if this data includes information relating to critical systems or to natural persons, its exfiltration, whether intentional or not, may constitute a security incident to be notified to the competent authority within 24 hours for the early warning, and within 72 hours for the intermediate report.
The common mistake: assuming the risk is nil if the organisation has not deployed an LLM internally. Shadow AI, meaning the unsupervised use of AI tools by employees outside IT policies, is present in 61% of organisations that have no formalised AI policy, according to a 2025 IBM Security study. Most of these uses do not appear in any risk register.
The action to take: an inventory of the AI tools used, whether sanctioned or not, followed by an acceptable use policy that distinguishes data that may be submitted to external tools from data that must remain strictly confined. This policy must be enforceable: documented, communicated and audited, to be valid in a NIS2 audit.
Vector 2: hallucinations in regulated decision-making processes
The second vector is more subtle and potentially more costly in terms of liability. Language models produce incorrect outputs with confidence: the phenomenon of hallucination is documented and inherent to the current architecture of LLMs. It is not a bug that can be fixed in the short term; it is a statistical property of these systems.
The risk becomes critical when AI outputs are integrated without human validation into regulated decision-making processes: compliance reports submitted to the regulator, risk analyses used to make coverage decisions, assessments of critical providers under Article 21 NIS2, or the classification of security incidents.
A concrete example observed in 2025: the GRC team of a mid-market financial institution used an AI assistant to produce the ICT risk management report required by DORA. The report contained incorrect references to regulatory articles and invented metrics. The document was validated without in-depth review and sent to the competent authority. The resulting regulatory risk was direct.
The answer is not to prohibit the use of AI in these processes. It is to explicitly define which processes require systematic human validation before any external output, and to document this control. NIS2 requires security measures to be proportionate to the risk: the absence of human control over AI outputs in regulated processes is an insufficient measure.
Vector 3: the attack surface widened by AI agents and API integrations
The third vector emerges with more advanced deployments: AI agents granted access to internal systems through APIs, connectors or automation tools. These agents can read data, trigger actions and modify configurations, often with access levels far exceeding what they actually use.
Under NIS2, access management (Article 21, paragraph i) requires limiting rights to what is strictly necessary for operations. An AI agent with read-write access to an entire document management system, when it only needs to read specific documents, violates this principle, regardless of whether the agent is a human or an automated system.
Furthermore, AI agents can be targeted by prompt injection attacks: a malicious document injected into an agent's context can alter its behaviour and lead it to exfiltrate data, bypass controls or trigger unauthorised actions. These attack vectors have been documented by OWASP since 2024 in its Top 10 for LLM Applications, and their exploitation in real conditions has been increasing through 2025-2026.
The action to take is a review of the access rights of all deployed AI agents, followed by the integration of these agents into the critical asset map and into existing access management policies. This review is not a one-off task: it must be repeated with every change to the agent system.
Assessing your exposure: three operational questions
Before launching a formal programme, three questions help situate your exposure without a detailed audit.
Do you have an inventory of the AI tools used in your organisation, including uses not sanctioned by the IT department? If this inventory does not exist, your NIS2 risk register is structurally incomplete.
Do your compliance processes include explicit human validation of any AI output intended for external or regulatory use? If this control is not documented, it is not auditably present.
Are the AI agents you have deployed included in your ICT asset map, and do they undergo an access review? If these agents are not within the scope of your access management, your effective attack surface exceeds your declared control perimeter.
Presidio brings together ICT asset mapping, access management and decision traceability in a single register compliant with NIS2 and DORA: contact our team for a 30-minute diagnostic. Also read: NIS2: preparing your maturity audit in 90 days.
Conclusion
Generative AI creates three new risk vectors that NIS2 explicitly covers but that most GRC programmes have not yet integrated: data leakage through unsupervised uses, the introduction of undetected errors into regulated decision-making processes, and the widening of the attack surface through agents with excessive access.
Organisations that make effective progress on these vectors treat AI as an ICT asset in its own right, subject to the same requirements of mapping, access management and control as any other critical component. This is not an additional constraint: it is the condition for the operational benefits of AI not to turn into regulatory liability.