NIS2 + EU AI Act: One Compliance Program, Not Two

NIS2 + EU AI Act: One Compliance Program, Not Two

Learn more about AI implementation in Luxembourg in our comprehensive guide.

If your company is in scope of NIS2 — transposed in Luxembourg in 2025, with the ILR (Institut Luxembourgeois de Régulation) supervising most sectors — and you also deploy AI systems, a second regulatory clock is about four weeks away: the EU AI Act's main obligations apply from 2 August 2026. I keep seeing the same reflex in Luxembourg companies: NIS2 goes to the CISO, the AI Act goes to legal, and two teams build two risk registers, two vendor questionnaires, two incident procedures and two training plans — for what is largely the same underlying work.

That is the expensive way to do it. The two laws overlap on five duty areas: risk management, incident reporting, supply-chain control, governance and training, and logging and documentation. They diverge on what they protect — NIS2 secures your network and information systems; the AI Act protects the safety and fundamental rights of people affected by your AI — but the machinery underneath is shared. This article maps the overlap duty by duty, with a combined evidence pack that satisfies supervisors on both sides.

Not sure whether you're in scope of one law, both, or neither? That's a 30-minute conversation, not a 30-page memo. Book a free 30-minute consultation — scope first, program design second.

Who is in scope — and why many Luxembourg firms are in both

NIS2 in Luxembourg: essential and important entities, supervised by the ILR

NIS2 (Directive 2022/2555) applies to essential and important entities across a long sector list: energy, transport, health, water, digital infrastructure, ICT service management, public administration and space on the high-criticality side; postal services, waste, chemicals, food, manufacturing of critical products, digital providers and research on the important side. As a general rule, medium-sized and larger companies in these sectors — roughly 50+ employees or over €10 million turnover — are in scope, with some entities captured regardless of size.

Luxembourg's 2025 transposition law makes the ILR the competent authority for most sectors, with carve-outs — notably financial entities, where DORA acts as lex specialis under CSSF supervision. In-scope entities have registration and notification duties towards the ILR; the practical details (portal, deadlines, sector classifications) have evolved since transposition, so check current ILR guidance rather than a 2024-era summary.

AI Act roles: provider or deployer — and most SMEs are deployers

The AI Act doesn't care what sector you're in. It assigns you a role: provider if you develop or substantially modify an AI system placed on the EU market, deployer if you use one under your own authority. Buying an AI-powered tool and running it on your operations makes you a deployer, with real obligations — human oversight, monitoring, log retention, staff AI literacy — especially for high-risk use cases under Annex III. Our EU AI Act August 2026 deadline guide covers the full obligation set.

Here is the punchline: a mid-sized Luxembourg logistics firm, hospital group, energy supplier or manufacturer is very plausibly a NIS2 important entity and an AI Act deployer at the same time. Two laws, one company, one budget. Luxembourg's AI Act market surveillance designations are still being finalised — the ILR is expected to play a central role alongside the CNPD — which makes the case for one coherent program even stronger.

The five duty areas where NIS2 and the AI Act overlap

1. Risk management. NIS2 Article 21 requires an all-hazards risk analysis and proportionate measures across your network and information systems. The AI Act requires risk management for high-risk AI (Article 9 for providers) and risk-aware deployment for deployers. An AI system runs on your network and information systems — so a model, its data pipeline and its hosting are simultaneously NIS2 assets and AI Act subject matter.

2. Incident reporting. NIS2 sets a hard cadence for significant incidents: an early warning within 24 hours, a notification within 72 hours, a final report within one month. The AI Act adds serious-incident reporting for high-risk AI systems — generally within 15 days of awareness, shorter for the most severe cases. One event — say, a poisoned model that misroutes operations — can start both clocks at once.

3. Supply-chain and vendor duties. NIS2 makes supply-chain security explicit: you must assess the security posture of direct suppliers and reflect it contractually. The AI Act runs parallel logic down the AI value chain: deployers rely on provider documentation, providers owe transparency to deployers. Your AI vendors are NIS2 suppliers.

4. Governance and training. NIS2 Article 20 puts accountability on the management body — directors must approve the measures, oversee them, follow training, and can be held liable for breaches. The AI Act's Article 4 requires AI literacy for staff operating AI systems (in force since February 2025), and high-risk deployments demand competent human oversight. Both laws force the same change: named owners, trained people, board attention.

5. Logging and documentation. NIS2 expects you to prove the effectiveness of your measures — policies, logs, test results, audit trails. The AI Act requires automatic logging of high-risk systems, with deployers keeping logs for at least six months, plus technical documentation and monitoring records. Different documents in theory; the same evidence discipline in practice. For what the security measures look like operationally, see our guide on AI-era cybersecurity for Luxembourg businesses.

The duty-by-duty mapping table: one control, two regulatory hats

This is the artefact I wish more compliance decks contained. For each duty area, one combined control you build once and evidence twice.

NIS2 duty (2025 LU transposition)	EU AI Act duty	One combined control
All-hazards risk analysis and security policies (Art. 21)	Risk management for high-risk AI (Art. 9); deployer risk-aware use (Art. 26)	Single risk register where every AI system is an inventoried asset, tagged with both a NIS2 criticality rating and an AI Act risk class
Incident handling; 24h / 72h / 1-month reporting to CSIRT/authority (Art. 23)	Serious-incident reporting for high-risk AI (Art. 73)	One incident taxonomy and escalation runbook with a dual decision tree: which event triggers which regulator, on which clock
Supply-chain security, incl. supplier assessment and contract terms (Art. 21(2)(d))	Value-chain duties: provider documentation, instructions for use, deployer reliance	Single vendor register with a security annex and an AI annex per contract; one due-diligence questionnaire covering both
Management-body accountability, approval and training (Art. 20)	Human oversight (Arts. 14, 26) and AI literacy (Art. 4)	One governance committee owning cyber and AI; one training curriculum spanning cyber hygiene and AI literacy, with attendance logged
Effectiveness assessment, logging and audit evidence	Automatic logging (Art. 12); deployer log retention ≥ 6 months; post-market monitoring	Central logging and monitoring platform with a retention schedule that satisfies the stricter of the two regimes per data type
Business continuity, backup and crisis management (Art. 21(2)(c))	Accuracy, robustness and cybersecurity of AI systems (Art. 15)	Continuity plans that include AI failure modes: fallback procedures, degraded-mode operations, model rollback tested alongside backups

Two honest caveats. The mapping is at the control level, not the legal level — a lawyer still needs to confirm which articles bind your entity type. And "one control" doesn't mean "half the work"; it means you stop paying for the same work twice.

Want this table applied to your actual systems? In our projects with Luxembourg firms, we build this mapping as a working spreadsheet, not a slide. Book a free 30-minute call and bring your AI inventory, even a rough one.

Where the two laws diverge — and where force-fitting backfires

A merged program only works if you respect the differences:

• Different protected interests. NIS2 protects the security of network and information systems — confidentiality, integrity, availability. The AI Act protects health, safety and fundamental rights of people affected by AI. A perfectly secure AI system can still be unlawful (say, a biased high-risk hiring tool), and a lawful AI system can still be insecurely hosted.
• Different classification logic. NIS2 classifies your entity (essential vs important, by sector and size). The AI Act classifies each AI system (prohibited, high-risk, limited, minimal — by use case). You resolve NIS2 status once; you classify AI systems continuously.
• Different penalty structures. NIS2 foresees fines up to €10 million or 2% of worldwide turnover for essential entities (€7 million or 1.4% for important ones), plus personal management liability. The AI Act scales up to €35 million or 7% for prohibited practices.
• Different supervisors — probably. NIS2 supervision sits with the ILR for most sectors; AI Act market surveillance designations were still being finalised at the time of writing, so verify before wiring your reporting lines. And if you're a CSSF-regulated financial entity, your cyber regime is DORA rather than NIS2 — read our DORA + EU AI Act playbook for Luxembourg finance instead.

And a third regime never left the room: if your AI touches personal data, GDPR applies in parallel — our guide to GDPR-compliant AI for Luxembourg SMEs shows how a DPIA slots into the same evidence pack.

The 2026–2027 timeline, on one page

• Already in force: NIS2 duties for essential/important entities under Luxembourg's 2025 law; AI Act prohibitions and AI literacy (since 2 February 2025); GPAI model obligations (since 2 August 2025).
• 2 August 2026: the AI Act's main wave — high-risk obligations under Annex III, transparency duties, penalties. Plan against this date, even though the EU's Digital Omnibus proposal could shift some high-risk dates toward late 2027; treat any delay as a bonus, not a plan.
• Through 2027: AI Act obligations for AI embedded in regulated products (2 August 2027); NIS2 supervision maturing — expect the ILR's audit and enforcement practice to sharpen as registrations settle.

The strategic implication: your NIS2 program is (or should be) already running. The cheapest AI Act program is the one that extends it — adding AI-specific columns to registers that already exist — rather than a parallel build starting from zero this July.

The combined evidence pack: ten documents that serve both regimes

When a supervisor, auditor or major client asks you to demonstrate compliance, what they actually want is documents. Build each of these once, tag it for both regimes:

1. Asset and AI system inventory — every system, AI use case, owner, vendor, criticality and AI risk class in one register.
2. Risk assessment methodology and register — one method, two lenses (system security / AI harm), reviewed on a fixed cadence.
3. Governance policy signed by management — scope, roles, board approval; satisfies NIS2 Article 20 accountability and anchors AI oversight.
4. Vendor register with contract annexes — security clauses and AI documentation clauses per supplier, plus due-diligence records.
5. Incident response runbook with dual reporting decision tree — who calls whom, which regulator, 24h/72h vs 15-day/2-day clocks.
6. Training and AI literacy log — curriculum, attendance, refresh dates, covering management as well as operators.
7. Logging and retention schedule — what is logged where, kept how long, and who can produce it within 48 hours.
8. Business continuity and AI fallback plan — tested procedures for running without the model, not just without the server.
9. Human oversight matrix — named, trained individuals per high-risk AI system, with authority to intervene documented.
10. Effectiveness review record — board minutes, test results, audit findings; proof the program is alive, not laminated.

Produce these ten documents and you can answer most of what either regime will ask of a mid-sized company — an estimate from project experience, not a legal guarantee, but one that has held up well.

Where does 20 More fit? We are not a law firm and won't pretend to be one. We build and deploy AI systems for Luxembourg SMEs with this evidence pack produced alongside the build — inventory, logging, oversight matrix, fallback plans — so your lawyers review documents instead of drafting them from nothing. Scoping this properly before August is exactly what an AI consultant in Luxembourg should do with you in the first session: book a free 30-minute consultation and we'll tell you honestly how much of this you already have.

Frequently Asked Questions

Does NIS2 apply to AI systems?

Not to AI as such — NIS2 applies to entities and the security of their network and information systems. But any AI system an in-scope entity runs sits on those systems, so its infrastructure, data pipelines and vendors fall under NIS2 risk-management and supply-chain duties. The AI-specific obligations (risk classification, human oversight, transparency) come from the EU AI Act. In short: NIS2 secures the system your AI runs on; the AI Act governs what the AI is allowed to do.

Can one risk assessment cover both NIS2 and the AI Act?

Yes, if it's structured for it. Use a single risk register and methodology, with each AI system assessed through two lenses: a security lens (threats to confidentiality, integrity, availability — NIS2) and a harm lens (impact on people's safety and rights — AI Act). What does not work is running one generic assessment and hoping it answers both. The overlap is in the machinery — inventory, scoring, ownership, review cadence — not in the questions asked.

Who supervises NIS2 and the AI Act in Luxembourg?

For NIS2, the ILR is the competent authority for most sectors under Luxembourg's 2025 transposition law, with exceptions — financial entities are covered by DORA under CSSF supervision. For the AI Act, Luxembourg's market surveillance designations were still being finalised at the time of writing, with the ILR expected to play a central role alongside the CNPD. Check current ILR and government guidance before wiring your reporting procedures.

We're a 60-person Luxembourg manufacturer using AI tools we bought, not built. Are we really in scope of both?

Quite possibly. Manufacturing of certain product categories is a NIS2 "important entity" sector, and at 60 employees you likely clear the size threshold — verify your classification against the transposition law or with the ILR. Using purchased AI tools makes you an AI Act deployer: lighter duties than a provider, but real ones — AI literacy, human oversight, log retention — escalating significantly if a use case (e.g. AI-assisted recruitment) is high-risk.

What happens if one incident triggers both reporting regimes?

You run both clocks in parallel. A significant incident under NIS2 requires an early warning within 24 hours and a notification within 72 hours; if the same event is a serious incident involving a high-risk AI system, AI Act reporting applies too — generally within 15 days, as little as two days in the most severe cases. This is why a single incident taxonomy with a dual decision tree beats two separate procedures: in a real incident, nobody has time to reconcile two playbooks.

Where should we start if we've done little on either regime?

Start with the inventory — one register of systems, AI use cases, owners and vendors. It is the foundation both regimes build on, and it immediately reveals your exposure: your NIS2 sector classification and your AI Act risk classes. Then stand up the governance committee and the incident runbook; policies and training follow. Most mid-sized firms can build the skeleton of a combined program within one to two quarters — the mistake is spending that time producing two parallel PowerPoints instead.

— Laurent Tousch, Founder of 20 More, AI automation consultant in Luxembourg