NIS2 and EU AI Act overlap

How much of your NIS2 work counts toward the AI Act?

Seven of nine control areas carry over in part. The risk register, the asset inventory, the logging platform, the incident procedure, the supplier clause set, the document library and the training programme you built for NIS2 all work as a base under the AI Act. Four things have to be built from zero, and the two reporting channels cannot be merged.

~30,000

German entities in scope of the NIS2 implementing act, in force since 6 December 2025

openkritis.de

2,520

Hungarian organisations on the audit register of the regulator SZTFH

SZTFH, 2026-07-10

16 months

delay to the AI Act high-risk rules, new date 2 December 2027

Regulation (EU) 2026/1744

An 80 percent reuse figure circulates in the industry. I think that is too high, and it pushes planning in the wrong direction. What really transfers is the scaffolding: the roles, the review cycles, the approval workflow, the format of the registers. The evidence itself barely transfers at all. A cybersecurity risk assessment says nothing about whether your training data is representative, and a vulnerability scan report does not replace a bias measurement. The good news is that building the scaffolding is what takes months. Filling it in takes weeks.

Who falls under both NIS2 and the AI Act?

The two scopes are independent of each other. NIS2 catches you by sector and size. The AI Act catches you by what you use AI for. The intersection is still large: any organisation above 50 staff in a listed sector that screens CVs or monitors performance with AI sits under both.

National detail matters more than people expect. Germany published the NIS2 implementing act in the Federal Law Gazette on 5 December 2025 and it entered into force the next day. Around 30,000 companies are affected, split into roughly 8,250 essential and 21,600 important entities. Registration runs through the BSI portal within three months of establishing that you are in scope under §33(1) BSIG, and the BSI states that the statutory registration deadline has already passed. Management liability sits in §38 BSIG. Hungary moved in the opposite direction: Act CXXXV of 2025 rewrote the scope test with effect from 6 January 2026 and removed the automatic consolidated headcount calculation, so a number of group subsidiaries dropped out of scope while their preparation programmes were still running on the wider 2025 reading. I checked the German and Hungarian transpositions for this article. If you sit in Austria or another member state, the sector lists are the same, but the section numbers, the registration route and the fine mechanics are not, and I am not going to quote provisions I have not read. Scope, deadlines and fine bands are set out in our NIS2 explainer; here only the intersection matters.

Sector under NIS2 Annex I or II	Typical AI use	Where it lands under the AI Act
Energy, water, transport	load forecasting, network anomaly detection, traffic control	Annex III point 2, high-risk where it acts as a safety component. Article 27 does not require a FRIA for this point.
Healthcare providers	imaging support, triage, clinical documentation	Annex I if embedded in a medical device: 2 August 2028. Emergency call triage sits in Annex III point 5.
Manufacturing, NACE 26 to 30	machine vision quality control, predictive maintenance	Usually minimal risk. AI embedded in machinery products was carved out of the high-risk regime by the omnibus, with a delegated act to fill in the detail.
Digital infrastructure: cloud, data centre, CDN	anomaly detection, capacity planning, customer service agents	Article 50 chatbot disclosure has applied since 2 August 2026. Otherwise usually minimal risk.
Managed IT and managed security service providers	agents running inside customer systems, automated alert triage	Role dependent. Article 25 decides whether you are provider or deployer for a given system.
Online marketplaces, search engines, social platforms	recommender systems, content moderation, generative content	Article 50(2) and 50(4) marking. Systems already on the market before 2 August 2026 have until 2 December 2026.
Any listed sector above 50 staff	CV screening, promotion scoring, performance monitoring	Annex III point 4, high-risk from 2 December 2027. By far the most common intersection.

Sectors listed in NIS2 Annexes I and II, and where their typical AI use lands under the AI Act

The last row deserves separate attention. Most companies assume the high-risk part of the AI Act is about energy and healthcare. In practice the most common high-risk system is an HR tool that arrived bundled with a cloud recruiting suite, and that IT knows nothing about. Where NIS2 and the AI Act genuinely converge is energy: essential entity status and Annex III point 2 meet on the same SCADA system.

What do NIS2 and the AI Act ask for on the same control?

Nine areas ask for something similar. Supply chain, business continuity and training overlap almost fully. Risk management and documentation overlap at framework level but not in content. Logging overlaps halfway, because the AI Act wants the decision trail of the model, not the server log. Incident handling overlaps in process and not at all in channel.

Control area	What NIS2 asks	What the AI Act asks	Carries over?
Risk management	Article 21(2)(a): policies on risk analysis and information system security. In Hungary, Cybersecurity Act §6(2) to (3), with a review at least every two years under §6(4).	Article 9: continuous, iterative risk management across the full lifecycle, from 2 December 2027.	Mostly. The framework, the scoring scale and the review cycle transfer. The AI-specific risk types are missing: bias, hallucination, prompt injection.
Data and access management	Article 21(2)(i): human resources security, access control policies and asset management.	Article 10: relevance, representativeness and bias examination of training, validation and test datasets. Article 26 puts input data relevance on the deployer.	Only the access half. Article 10 data quality requirements have no NIS2 counterpart.
Logging	Article 21(2)(e) plus national detail on traceability of events. In Hungary, Cybersecurity Act §6(5)(c) with the logging measures of MK Decree 7/2024.	Article 12: automatic event logging over the lifetime of the system. Article 19 and Article 26(6): retain logs for at least six months.	The infrastructure yes, the content no. A SIEM does not know which prompt produced which tool call.
Incident handling and reporting	Article 23: early warning in 24 hours, notification in 72 hours, final report in one month, to the national CSIRT or competent authority. In Germany through the BSI, in Hungary to the National Cyber Security Centre (NKI).	Article 73: serious incident within 15 days; 2 days for widespread infringement or serious disruption of critical infrastructure; 10 days where a person has died. Reported to the AI market surveillance authority.	The process yes, the channel no. The 24-hour clock is the stricter one. Build for it and the AI Act deadlines follow.
Supply chain	Article 21(2)(d): supply chain security, including relationships with direct suppliers. In Hungary §6(5)(d) requires the requirements to be passed on as a contractual obligation, §6(6) keeps the manager liable, and §11(9) gives a right to request information.	Article 25: responsibilities along the AI value chain. Article 53(1)(b) and Annex XII: the GPAI provider informs the downstream provider.	Yes, and this is the best ratio of the nine. The same due diligence pack extends with AI annexes.
Business continuity	Article 21(2)(c): business continuity, backup management, disaster recovery and crisis management.	Article 15(4): redundancy, backup and fail-safe arrangements, and control of feedback loop bias.	Yes. The AI outage scenario goes into the same BCP document as one extra chapter.
Management accountability	Article 20: management bodies approve the measures, oversee implementation, can be held liable, and have to take training. In Germany §38 BSIG; in Hungary, Government Decree 418/2024 §42(4) allows a personal fine of HUF 15 million on the manager.	Article 26: deployer obligations sit on the organisation. Article 99: fines hit the organisation, up to EUR 35 million or 7% of worldwide turnover for prohibited practices.	Partly. The AI Act knows no personal fine on an individual manager. The Hungarian NIS2 implementing decree does.
Documentation	Article 21(2)(a) and (f): security policies, and procedures to assess the effectiveness of the measures. In Hungary, an information security policy reviewed at least every two years under §6(3) point 7.	Article 11 and Annex IV: technical documentation. Article 17: quality management system. Article 18: ten-year document retention. Article 72: post-market monitoring plan.	The repository, the versioning and the approval workflow yes. Annex IV content is almost entirely new writing.
Training	Article 20(2) and Article 21(2)(g): basic cyber hygiene and cybersecurity training, management included.	Article 4: AI literacy, applicable since 2 February 2025. The omnibus softened it into a duty to support the development of AI literacy.	Yes. One annual programme with two modules and a completion record is evidence under both.

NIS2 and EU AI Act compared control by control. Own reading of the two regimes, not regulator guidance.

That table is my own reading of the two regimes. No cybersecurity regulator, CSIRT or AI market surveillance authority has published guidance on aligning the two, and up to August 2026 I found no national position on the question at all. Anyone promising a firmer answer is selling their own interpretation as settled law. The national mapping of the ten Article 21(2) measures is broken down measure by measure in our NIS2 checklist.

Where is NIS2 work not enough on its own?

In four areas. The fundamental rights impact assessment, data governance and bias testing, the design of human oversight, and the demonstration of accuracy all call for evidence that a cybersecurity programme never produces. Each needs its own work package, and the expertise comes from somewhere else.

Fundamental rights impact assessment, Article 27

A FRIA is not a risk assessment in the IT sense. It has to walk through what concrete harm the system can do to natural persons and groups, how often and for how long it runs, which human oversight measures protect the people affected, and where they can complain. It binds public bodies, private entities providing public services, and deployers running creditworthiness evaluation or life and health insurance risk assessment. It does not bind critical infrastructure. The completed template has to be submitted to the market surveillance authority. The omnibus moved this to 2 December 2027 as well, because Article 27 sits in Chapter III Section 3.

Data governance and bias testing, Article 10

Nothing to carry over here. Article 10 asks that training, validation and test datasets be relevant, sufficiently representative and as far as possible free of errors, and that biases be examined. That needs data analysis, subgroup performance measurement, and documentation of what you did about the gaps you found. The omnibus widened one thing: processing of special category data for the purpose of bias detection now extends to all AI systems, not only high-risk ones, with a restored strict necessity test.

Human oversight, Article 14 and Article 26

Article 14 is a design requirement: the system has to be built so that human oversight can actually be exercised, including intervention and shutdown. Article 26 then asks the deployer to assign that oversight to a competent, trained and empowered natural person. The security officer role that several national NIS2 transpositions require is not automatically suitable, and in Hungary the Cybersecurity Act §11 goes further by expecting that person to sit outside IT operations. Two separate roles, one shared responsibility matrix.

Accuracy, robustness and cybersecurity, Article 15

This is the one of the four where NIS2 work partly counts. Article 15(5) names resilience against data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks, so the penetration testing and vulnerability management programme extends onto it. What NIS2 does not give you is the accuracy metric. You have to state the performance level at which the system operates, declare it in the instructions for use under Article 13, and measure whether it holds. We covered running the AI Act and the GDPR together in the AI Act, GDPR and AI security article.

What happens when an AI agent gets access to a NIS2 system?

From that moment the agent is part of the network and information system. It belongs in the asset inventory, it needs its own identity and least-privilege access, its activity has to be logged, and if it causes damage the 24-hour clock starts. Very few companies run this all the way through today.

Access management

The most common mistake is letting the agent log in under a human account, because that was the fastest way to integrate it. That breaks the access control policy and the point of logging at once, since the log shows a colleague acting at moments when a model wrote to the system. What to require instead: a dedicated service account, a named human owner, read access by default, write operations only through a narrow and revocable API, rotated keys, and a kill switch that removes the agent from the system in one click. That last one serves the rapid response duty under NIS2 and the human oversight requirement of AI Act Article 14 at the same time.

Logging

An agent leaves traces in three layers, and conventional NIS2 logging only captures the first.

Infrastructure layer: login, API call, database operation. This is what already lands in the SIEM and what NIS2 Article 21(2)(e) is about.
Decision layer: which prompt arrived, which tool the model called, with which parameters, and what came back. This is the subject of AI Act Article 12, and it does not reach a typical SIEM.
Model version layer: which model, which version, which system prompt, which temperature. Without it a decision made six months ago cannot be reconstructed.

Retention is driven by the stricter deadline. The AI Act sets at least six months under Article 19 and Article 26(6), and sector rules in several member states go longer. On the tooling side, our LangFuse and LangSmith comparison shows what that second layer looks like in practice.

The 24-hour clock on an AI incident

Here comes the legally shakiest point, and it is better said out loud than confidently got wrong. The Hungarian Cybersecurity Act §66(2) makes reportable anything that causes serious disruption to the operation or service provision of the organisation or financial loss, or significant material or non-material damage to someone else. That wording says nothing about an attacker. If an agent writes bad data back into the ERP and shipping stops, the facts fit the text grammatically. No national guidance exists on this.

The working distinction we use is this. If the trigger was external influence, for example a prompt injection hidden in an incoming email or document, treat it as a cybersecurity incident and start the 24-hour clock. If it is a pure model error with no adversarial involvement, it is primarily a quality failure, and it can become a serious incident under AI Act Article 73 if the system is high-risk. Except that Article 73 does not apply to high-risk systems until 2 December 2027, so today there is no EU-level AI reporting duty for a malfunctioning non-high-risk agent. If the company is in NIS2 scope, national cybersecurity law may still be there.

What do you have to require from your AI vendor in the contract?

NIS2 Article 21(2)(d) makes supply chain security your problem, and several national transpositions turn that into an explicit duty to push the requirements onto subcontractors by contract while the management stays liable. That is why the contract is not a formality. It is the only legal instrument you have.

Clause	Why you need it	Legal basis
Role allocation	Record who is the provider and who is the deployer for each system, and what happens when that changes.	AI Act Art. 3(3), 3(4), Art. 25
Trademark and intended purpose limits	Put your name on it, or change what it is used for, and you become the provider with the full Article 16 package.	AI Act Art. 25(1)
Documentation handover	Without the capability and limitation description flowing down from the GPAI provider you cannot meet your own obligations.	AI Act Art. 53(1)(b), Annex XII, Art. 13
Log format and retention	If the vendor will not export the decision trail in a usable format, there is nothing for you to retain for six months.	AI Act Art. 12, Art. 19, Art. 26(6)
Notice of model and version changes	A silent model swap can amount to a substantial modification and flip your role.	AI Act Art. 25(1)(b)
Incident notification SLA	The vendor has to tell you well inside 24 hours, otherwise you cannot meet your own early warning deadline.	NIS2 Art. 23 and Art. 21(2)(d)
Audit and information rights	Some member states give a statutory right to request information from partners, but the contract is what makes it enforceable.	NIS2 Art. 21(2)(d); in Hungary, Cybersecurity Act §11(9)
Data processing and training exclusion	Rule out training on your data and fix where it is stored. A German buyer will also expect a processing agreement under Art. 28 GDPR.	GDPR Art. 28, AI Act Art. 10

Minimum clause set for an AI vendor contract

For German and Austrian buyers the last row is usually the first question, not the last. An Auftragsverarbeitungsvertrag under Article 28 GDPR has ten mandatory contents, and a procurement team will check them before it looks at anything AI-specific. Bitkom measured data protection requirements as the single largest external obstacle to AI adoption in Germany at 77 percent in its March 2026 survey of 604 companies. An AI vendor that arrives without a processing agreement and a subprocessor list does not get to the technical discussion.

The reverse is true too, and this is the most underused channel in the market. Tens of thousands of suppliers who are not themselves in NIS2 scope receive the same requirements through contract, without any statute applying to them directly. If you are a software developer or an AI vendor, sooner or later someone will put this clause set in front of you. Better that you bring it to the table yourself.

What does a combined compliance plan look like?

One inventory, one risk register, one logging policy, one incident process with two reporting tracks, one supplier pack and one training programme. On top of that come the four AI-specific work packages. The schedule below assumes the NIS2 foundations exist and that you need to be AI Act ready by 2 December 2027.

Phase	What happens	Output
Days 0 to 30	Extend the asset inventory with AI fields: model, version, data source, role, business owner. Review the Article 50 transparency duties, because those have applied since 2 August 2026.	One merged inventory, chatbot disclosure and content marking in order
Days 30 to 90	Add an AI view to the existing risk register. Extend the logging and retention policy to the decision trail. Split incident escalation into two tracks.	One risk register, one log policy, one escalation process
Days 90 to 180	Classification: the security class required by your national NIS2 transposition, and in parallel the AI Act risk category under Article 6 and Annex III. Send out the supplier clause set. Run the training programme with two modules.	Classification decisions, signed supplier annexes, training records
First half of 2027	For everything classified high-risk: Annex IV technical documentation, data governance and bias testing records, a human oversight plan, and a FRIA where Article 27 applies.	A documentation pack per system
Second half of 2027	Conformity assessment under Article 43, EU declaration of conformity, CE marking, and registration in the EU database where relevant.	Market ready by 2 December 2027
2028	The next mandatory NIS2 audit cycle. By then the AI controls sit among the ordinary cybersecurity evidence.	One audit preparation covering two regimes

Combined compliance roadmap for an organisation starting from NIS2 foundations

One thing not to postpone. The Article 50 transparency duties took effect on 2 August 2026, and the Article 99 penalty regime has applied since 2 August 2025. If a chatbot runs on your website and nothing tells the visitor they are talking to a machine, that is a breach today, not a future risk. It is a few hours of work and the cheapest item in the whole programme.

Summary and frequently asked questions

We closed our NIS2 audit. Do we still need AI Act compliance?

Yes, if the company uses or supplies an AI system that falls under the AI Act. The two scopes are independent: a water utility can be a NIS2 entity with no AI at all, and a 30-person HR firm can be an AI Act deployer with no NIS2 obligation. Evidence from the NIS2 audit is reusable for risk management, logging, supply chain and training, but there is no mutual recognition between the two regimes.

When do the AI Act high-risk requirements actually apply?

2 December 2027 for standalone Annex III systems, and 2 August 2028 for Annex I systems embedded in regulated products. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and pushed those dates back by 16 and 12 months. The Article 50 transparency duties were not moved and have applied since 2 August 2026.

Does an AI Act incident report go to the same place as a NIS2 one?

No. Under NIS2 Article 23 you send an early warning within 24 hours, a full notification within 72 hours and a final report within one month, to your national CSIRT or competent authority: the BSI in Germany, the National Cyber Security Centre (NKI) in Hungary. A serious incident under AI Act Article 73 goes to the AI market surveillance authority, as a rule within 15 days. Two authorities, two forms, two clocks. The Hungarian Cybersecurity Act §6(7) says explicitly that a cyber report does not discharge reporting duties under other law.

Does an AI agent failure count as a NIS2 incident?

There is no national guidance on this in Hungary as of August 2026, and I have not found one elsewhere either. The Hungarian Cybersecurity Act §66(2) makes an event reportable when it causes serious disruption or financial loss, and that wording does not exclude a model error. If an external attacker triggered it, for example through a prompt injection hidden in an incoming document, the classification is clear. For a pure model error it is arguable, and no authority has taken a position.

Is an ISO 27001 or ISO 42001 certificate enough for both?

Not enough, but it helps a lot. The Hungarian Cybersecurity Act §6(8) allows a certified ICT product, service or process to be used as evidence of compliance, and AI Act Articles 40 to 42 tie the presumption of conformity to harmonised standards. I found no national guidance anywhere saying that an ISO 42001 certificate creates a formal presumption of NIS2 compliance. It is an efficiency argument, not a legal presumption.

What happens if we put our own name on a vendor AI system?

Under AI Act Article 25 you become the provider, and the Article 16 provider obligations land on you. The same happens if you substantially modify the system, or change its intended purpose so that it becomes high-risk. The original provider is then released, but has to cooperate and give reasonable technical access. This is the most expensive sentence in a vendor contract.

Are we still in NIS2 scope after the 2026 changes?

Worth recalculating, because national transposition dates and thresholds differ. Germany brought the NIS2 implementing act into force on 6 December 2025, with roughly 30,000 entities in scope: essential above 250 staff or EUR 50 million turnover, important above 50 staff or EUR 10 million. Hungary went the other way on 6 January 2026: Act CXXXV of 2025 rewrote the scope test and dropped the automatic consolidated headcount calculation, so a number of group subsidiaries fell out of scope while still preparing under the wider 2025 reading.

Sources

This article is information, not legal advice. The provisions reflect the position on 14 August 2026, and at several points we flagged where national practice is still missing. Classification and an obligation list for a specific system are worth establishing only with knowledge of that system and with legal counsel involved.

If you are starting now: our NIS2 compliance programme covers the cybersecurity side, and EU AI Act compliance covers classification, documentation and the FRIA. Plan them as one project, because the inventory, the risk register and the supplier pack are the same in both.

NIS2 and the EU AI Act together: where the two overlap