How do you govern AI under NIS2, the AI Act and the GDPR?

Does NIS2 apply to AI systems?

Yes, indirectly. NIS2 doesn't name AI, but it covers the security of all network and information systems an essential or important entity uses to provide its services, and AI systems are part of them. See our NIS2 compliance guide for the full set of duties.

Take a logistics firm that lets an AI model plan routes. Within weeks the tool is business-critical, holds personal data and has API access to core systems. Nobody assessed the risk, because it started as a pilot.

Article 21(1) of Directive (EU) 2022/2555 requires "appropriate and proportionate technical, operational and organisational measures" for the security of network and information systems, based on an all-hazards approach. For AI, the most relevant Article 21(2) measures are:

• (a) risk analysis: include AI tools in your risk assessment and asset inventory.
• (c) business continuity: backup management and disaster recovery for AI-dependent processes.
• (d) supply chain security: AI vendors and model providers are suppliers like any other.
• (i) access control and asset management: who and what can reach the model, its data and its API keys.

If an AI system is involved in a significant incident, the Article 23 reporting deadlines of 24 hours, 72 hours and one month apply as usual. Management is accountable under Article 20.

How do the AI Act, GDPR and NIS2 fit together?

They overlap but ask different questions: NIS2 whether your systems are secure and resilient, the AI Act whether the AI is safe and lawful, the GDPR whether personal data is protected.

When the AI Act applies

According to the European Commission's AI Act implementation timeline, the prohibitions and AI literacy duties have applied since 2 February 2025, obligations for general-purpose AI model providers since 2 August 2025, and the transparency rules in Article 50 from 2 August 2026. Following the Digital Omnibus on AI, agreed by the Council and Parliament on 7 May 2026, high-risk rules for Annex III systems apply from 2 December 2027 and for AI embedded in regulated products from 2 August 2028.

Most organisations are deployers: they use AI someone else built. Under Article 26, deployers of high-risk AI must follow the provider's instructions, assign trained human oversight, monitor operation and keep system logs for at least six months.

What does privacy by design mean for AI systems?

It means building data protection into the AI system from the start rather than adding it later. GDPR Article 25(1) requires the controller to implement "appropriate technical and organisational measures, such as pseudonymisation" both when designing and while running the processing.

For AI, that translates into four design choices:

1. Data minimisation. Feed the model only the personal data it needs; Article 25(2) makes this the default.
2. Purpose limitation. Decide what the system is for and don't reuse prompts, outputs or training data for other purposes without a legal basis.
3. Access control. Least-privilege access to the model, its data stores and API keys, with MFA for administrators.
4. Traceability. Log inputs, outputs, model versions and configuration changes so you can explain and reconstruct what happened.

Before you deploy, check whether you need a data protection impact assessment (DPIA): Article 35 requires a DPIA when processing, "in particular using new technologies", is likely to result in a high risk to people's rights. AI Act Article 26(9) says deployers of high-risk AI should use the provider's information to carry out that DPIA. Where your data is stored matters too; see what is data sovereignty.

What are the risks of ungoverned AI?

Three kinds: security, privacy and continuity. All three are already showing up in breach data.

• Security. AI Act Article 15(5) names the AI-specific attacks: data poisoning, model poisoning, adversarial examples and confidentiality attacks. The IBM Cost of a Data Breach Report 2025 found that 13% of organisations reported breaches of AI models or applications, and 97% of those lacked proper AI access controls.
• Privacy. Staff paste customer data into tools you don't control. IBM found that one in five organisations had a breach involving shadow AI, which added $670,000 to the average breach cost. The Verizon 2026 DBIR, as summarised by Help Net Security, reports that 45% of employees now use AI tools regularly and 67% of users accessing AI on corporate devices used non-corporate accounts.
• Continuity. Lose an AI system's configuration, prompts or vector store and the process that depends on it stops. If they're not backed up, you can't restore them.

Governance is lagging: IBM reports that 63% of breached organisations had no AI governance policy or were still developing one. See also AI and backup and AI browser security risks.

How do you build AI governance that works under NIS2?

Treat AI as part of your existing NIS2 risk management, not as a separate project. Six steps cover most organisations.

1. Inventory every AI system, including shadow AI: which tools, which data they touch, which systems they connect to, and who owns them.
2. Classify each one under the AI Act (prohibited, high-risk, transparency duty or minimal risk) and check whether a DPIA is required under GDPR Article 35.
3. Engineer the safeguards: minimisation, pseudonymisation, least-privilege access, MFA for administrators and logging, as described above.
4. Assess AI suppliers under NIS2 Article 21(2)(d): where data is processed, how incidents are reported to you, and how you get your data back on exit.
5. Add AI to backup and disaster recovery. Set an RTO (how long you can be without it) and RPO (how much data you can lose) per system, back up data, configurations and the servers they run on, and test the restore.
6. Assign ownership and train people. AI Act Article 4 requires measures for AI literacy; NIS2 Article 20 requires management to follow training and oversee the measures.

For technical controls, ENISA's multilayer framework for good cybersecurity practices for AI (2023) has three layers: cybersecurity foundations, AI-specific cybersecurity and sector-specific measures. For recovery targets, see RTO and RPO explained.

What evidence do auditors and regulators expect?

Proof that the controls work, not only a policy that says they exist.

What to do next

AI governance under NIS2 is ordinary risk management applied to a new kind of system: know what AI you run, protect the data by design, assess the suppliers and make sure you can recover. Start with the inventory.

Mindtime covers the backup and recovery layer. You can include the VMs, Linux servers, SQL Server databases and AWS, Azure or Google Cloud workloads that your AI systems run on in your backup scope, with immutable copies, an air-gapped copy and granular restore. Data stays in our own Tier III data centres in the Netherlands and Germany, under EU law, and we are ISO 27001 and NEN 7510 audited. Read our NIS2 compliance guide for how this fits Article 21.

Want to check whether your AI-dependent processes can be restored? Get a free assessment.

This article is information, not legal advice.