AI Is Now in Scope: Privacy-by-Design Under NIS2
If an AI system touches your critical operations or personal data, NIS2 and GDPR expect it to be governed — by design, not by patch.
A mid-sized energy company rolls out an AI tool that predicts maintenance windows from operational data. It works so well that within months it also ingests employee schedules, contractor records, and customer consumption profiles. Nobody ran a privacy assessment; the tool grew from a pilot into critical infrastructure without ever passing through governance. When the NIS2 audit arrives, the company cannot answer basic questions: what data does the model hold, who can access it, and how would it be restored after an incident?
This pattern — AI adopted faster than it is governed — is now a compliance problem, not just a hygiene one. NIS2 requires in-scope entities to manage risks across their network and information systems, and AI systems that process operational or personal data are exactly that. GDPR adds data protection by design as a standing legal duty.
The misconception to correct: AI governance is something to formalize "once the AI Act settles." NIS2 and GDPR apply to your AI systems today.
What Does Privacy-by-Design Mean for AI Systems?
Privacy-by-design is the principle — codified in GDPR Article 25 — that data protection must be engineered into systems from the outset rather than added afterwards. Applied to AI, it translates into concrete design choices made before deployment.
The Design Choices That Matter
Data minimization. Train and operate on the least personal data the purpose allows, and anonymize or pseudonymize where possible.
Purpose limitation. Prevent scope creep by defining what the model may ingest — the pilot that quietly swallowed HR data is a governance failure, not an accident.
Access control. Treat model inputs, outputs, and training data as sensitive assets with least-privilege access.
Transparency and traceability. Document data flows and training datasets so questions from regulators and data subjects can actually be answered.
Does NIS2 Really Apply to AI Deployments?
Yes. NIS2 does not name AI as a separate category — it doesn't need to. The NIS2 Directive obliges essential and important entities to take risk-management measures for all network and information systems supporting their critical services. An AI system that schedules maintenance, screens transactions, or supports clinical decisions is such a system, and it inherits the full obligation set: risk analysis, supply chain security (including the AI vendor and its APIs), incident handling, business continuity, and backup management.
Management accountability applies too: NIS2 places responsibility for these measures at board level, with personal liability for serious neglect. "The data science team handles that" is not a governance answer a supervisor will accept.
The Risks of Ungoverned AI
Ungoverned AI concentrates three risk families. Security: AI systems widen the attack surface — training data can be poisoned, models manipulated through crafted inputs, and integrations abused; ENISA's framework for good cybersecurity practices for AI maps controls across the AI lifecycle precisely because conventional controls don't transfer automatically. Privacy: models trained on excessive personal data create GDPR exposure that is hard to unwind — you cannot easily "delete" a person from a trained model, with fines reaching up to 4% of global turnover for serious infringements. Continuity: when critical processes depend on AI, the model, its configuration, and its data pipelines become assets you must be able to restore — most organizations have no RTO/RPO defined for them at all.
That last gap is the most overlooked. An AI-dependent process without tested recovery is a single point of failure wearing an innovation badge — which is why AI assets belong inside your data security and backup perimeter from day one.
Building Compliant AI Governance: A Five-Step Plan
Inventory your AI estate. List every AI system in use — including embedded AI in SaaS tools and shadow deployments — and record what data each one touches and which business process depends on it.
Run privacy impact assessments. Conduct a DPIA for each AI system processing personal data, documenting lawful basis, minimization choices, and safeguards. This is both a GDPR duty and your first piece of audit evidence.
Engineer the safeguards in. Apply data minimization, pseudonymization, encryption at rest and in transit, and least-privilege access to training data, models, and outputs — under EU jurisdiction where sovereignty matters.
Extend recovery to AI assets. Define RTO/RPO for AI-dependent processes and include models, configurations, and data pipelines in immutable backups with a tested disaster recovery path — an ungoverned dependency is bad, an unrecoverable one is worse.
Assign ownership and rehearse. Give each AI system a named owner, put AI incidents in your response runbooks, and exercise the scenario annually — including the ransomware variant where attackers target the data your models depend on, the case ransomware protection with isolated copies is built for.
Policy vs. Evidence: What Auditors Actually Check
| Governance artifact | Policy version (weak) | Evidence version (strong) |
|---|---|---|
| Privacy assessment | "We follow GDPR principles" | Completed DPIAs per AI system, reviewed annually |
| Access control | "Access is restricted" | Access logs for training data and model endpoints |
| Data flows | Architecture diagram from the pilot | Current, versioned data-flow documentation |
| Recovery | "Backups are in place" | Restore-test reports for AI-dependent processes with measured RTO |
The pattern is consistent: NIS2 supervision and GDPR accountability both reward organizations that can show their controls operating, not describe them. Building the evidence trail into normal operations — assessments filed, logs retained, restores tested and documented — costs far less than reconstructing it under audit pressure.
Conclusion
AI systems have joined the category of infrastructure your regulators expect you to govern: NIS2 pulls them into risk management and board accountability, GDPR demands protection by design, and both want evidence over assurances. The practical path is unglamorous and effective — inventory, assess, engineer safeguards in, extend backup and recovery to AI assets, and rehearse the failure scenarios. If you want to check whether your AI-dependent processes would survive an incident and an audit, we're happy to help you assess both.
Frequently Asked Questions
Does NIS2 apply to AI systems?
Yes. NIS2 requires essential and important entities to implement risk-management measures for all network and information systems that support their services, and AI systems processing operational or personal data qualify. The obligations include risk analysis, supply chain security for AI vendors, incident handling, business continuity, and backup management. Management bodies carry personal accountability for these measures, so AI governance cannot be delegated informally to technical teams.
What is privacy-by-design in the context of AI?
Privacy-by-design means engineering data protection into AI systems from the start rather than adding it afterwards: minimizing the personal data used for training and operation, pseudonymizing where possible, enforcing least-privilege access to models and datasets, and documenting data flows for traceability. It is a legal requirement under GDPR Article 25 for systems processing personal data. Retrofitting these safeguards after deployment is more expensive and produces weaker audit evidence.
What evidence do regulators expect for AI governance?
Regulators look for demonstrable, operating controls: completed privacy impact assessments per AI system, access logs for training data and model endpoints, current data-flow documentation, incident-response procedures that cover AI scenarios, and restore-test reports proving AI-dependent processes can be recovered within defined targets. Written policies alone are insufficient — both NIS2 supervision and GDPR accountability are built around evidence that controls actually run.