Directive (EU) 2022/2555 never mentions artificial intelligence. It catches AI companies anyway, and it does so through two tests that have nothing to do with what the software does and everything to do with what kind of service you sell and how big you are.
NIS2 is two tests, not one
The NIS2 Directive was adopted on 14 December 2022 and entered into force on 16 January 2023, with a transposition deadline for member states of 17 October 2024. It is a directive, not a regulation, so the text that binds you is your member state’s implementing law, not the directive itself — and a large number of member states missed the deadline, which means the practical answer to “does this apply to me” still varies by country. Read the directive at EUR-Lex, then read the national act.
Article 2(1) sets the general scope, and it is a conjunction. An entity is in scope if it is of a type listed in Annex I or Annex II and it qualifies as a medium-sized enterprise, or exceeds the ceilings for one, under Article 2 of the Annex to Recommendation 2003/361/EC, and it provides its services or carries out its activities within the Union. Fail either limb and the general rule does not catch you. Article 2(2) then lists categories that are in scope regardless of size, which is where a lot of confident advice goes wrong.
This page describes how the tests are structured. It is not legal advice, and scope determinations under NIS2 turn on facts about your service and your national transposition that a page cannot know. Take advice on your own facts before deciding you are out of scope.
Is an inference API a cloud computing service?
For an AI infrastructure business, the whole sector question collapses into one entry in Annex I, sector 8, “digital infrastructure”: cloud computing service providers. The neighbouring entries — data centre service providers, content delivery network providers, DNS service providers, TLD name registries, trust service providers, providers of public electronic communications networks — are also in that sector, and a company that runs its own GPU estate may well be a data centre service provider on top of whatever else it is.
Article 6(30) defines a cloud computing service as a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources, including where those resources are distributed across several locations. Recital 33 expands it to the usual service models and deployment models. Two business shapes sit on opposite sides of that definition and a third sits on the line:
- Renting GPUs or managed clusters is about as squarely within “on-demand administration of a scalable and elastic pool of shareable computing resources” as anything gets. If you sell capacity that a customer provisions, scales and administers, the sector test is not a close question.
- Selling a hosted model behind an API is harder. The customer gets broad remote access to shareable resources, and the resources are elastic, but the customer administers almost nothing — they send a request and receive tokens. Whether that is “on-demand administration” within Article 6(30), or a software service that happens to run on somebody else’s cloud, is not settled. Regulators have not produced a definitive line, and different national transpositions and different supervisory authorities may not answer it the same way.
- Managed service providers and managed security service providers are a separate Annex I entry, and an AI company that runs, tunes and monitors deployments inside a customer’s own environment can fall there even if it is not a cloud provider at all.
The honest position is that a pure inference API is arguable in both directions, and that the argument gets weaker the more of a platform you sell: storage, fine-tuning jobs, dedicated capacity, vector indexes and per-tenant isolation all push you towards the definition. Where Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 applies — it lays down technical and methodological requirements for cloud computing service providers, data centre service providers, CDN providers, managed service providers and several other digital entity types, and specifies when an incident is significant for them — it is the most detailed picture available of what a supervisor expects, and it is worth reading even to decide whether you are the kind of entity it addresses. It is published on EUR-Lex.
The size threshold, and who is caught regardless
Assume the sector test is met. The size test then uses the standard EU SME definition in the Annex to Recommendation 2003/361/EC, where the staff headcount criterion is mandatory and the financial criterion is a choice between turnover and balance sheet total. Read through Article 2(1) NIS2, the practical floor is: at least 50 staff, or an annual turnover and an annual balance sheet total that both exceed EUR 10 million. Below that you are a small or micro enterprise and the general scope rule does not reach you.
Two refinements matter more to a start-up than the headline number. First, the SME calculation aggregates linked and partner enterprises, so a small subsidiary of a large group is usually not small. Second, Article 2(2) catches certain entities irrespective of size, including DNS service providers, TLD name registries and providers of publicly available electronic communications services, and also any entity that is the sole provider in a member state of a service essential for the maintenance of critical societal or economic activities. Cloud computing service providers are not on that irrespective-of-size list — which is exactly why the headcount number is worth getting right rather than assuming the worst.
Article 3 then sorts in-scope entities into two classes. Essential entities are the Annex I entities that exceed the medium-sized ceilings, plus the named categories; important entities are everyone else in Annex I and Annex II. The substantive duties are the same. The supervision is not: Article 32 allows ex ante supervision of essential entities, including on-site inspections and targeted security audits, while Article 33 restricts supervision of important entities to ex post action once there is evidence of non-compliance. Article 34 sets the administrative fine ceilings at the higher of EUR 10 million or 2% of total worldwide annual turnover for essential entities, and the higher of EUR 7 million or 1.4% for important entities.
What Articles 20, 21 and 23 actually require
Article 21(2) lists ten categories of cybersecurity risk-management measure, and they must be proportionate to the risk. Three of them are where AI infrastructure businesses tend to find genuine work rather than paperwork. Point (d) is supply chain security, including the security-related aspects of the relationship with each direct supplier — for an application built on third-party models, your model providers are direct suppliers and their security posture is part of your compliance, not just your procurement. Point (e) is security in acquisition, development and maintenance including vulnerability handling and disclosure, which for a model-serving stack means having somewhere for a researcher to report a jailbreak that leaks another tenant’s data. Point (j) is multi-factor authentication, which is where the majority of real incidents in this sector actually start.
Article 20 puts the approval of those measures on the management body and provides that management bodies can be held liable for infringements, and it requires members of management bodies to follow training. This is the provision that changes who has to care.
Article 23 is the reporting clock, and it has three stages rather than one. An early warning goes to the CSIRT or competent authority without undue delay and in any event within 24 hours of becoming aware of a significant incident; an incident notification follows within 72 hours, updating the early warning and giving an initial assessment; a final report is due not later than one month after that notification. Article 23(3) defines a significant incident as one that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Note what the 24-hour clock runs from: becoming aware, not confirming, not finishing triage.
Article 21(2)(d) asks for the security-related aspects of the relationship with each direct supplier, which for an AI feature means an accurate list of every model provider a request can reach and what each one receives. That list is harder to keep honest than it sounds when three teams have their own keys. A gateway that sits in front of the providers gives you one place where the supplier set, the routing rules and the per-request record of which provider actually served a call are all visible — which is the same artefact the subprocessor disclosure work needs.
Jurisdiction, representatives and overlapping regimes
Article 26 gives digital infrastructure and digital provider entities a main-establishment rule rather than the default rule that you answer to every member state where you operate: cloud computing service providers, data centre service providers, CDN providers, managed service providers, managed security service providers and online platform types are deemed to be under the jurisdiction of the member state where they have their main establishment in the Union. An entity not established in the Union but offering services in it must designate a representative established in one of the member states where the services are offered, and is then under that state’s jurisdiction. A non-EU AI hosting company selling into the Union therefore does not escape NIS2 by having no European entity; it acquires a designation obligation instead.
Finally, NIS2 is not the only cybersecurity instrument pointed at this sector, and Article 4 matters when they collide: where a sector-specific Union act imposes requirements at least equivalent in effect to Articles 21 or 23, the NIS2 provisions do not apply. The clearest case is the financial sector, where Regulation (EU) 2022/2554 (DORA) governs instead — and an AI vendor selling to EU banks is likely to be an ICT third-party service provider under that regime whether or not NIS2 catches it directly. Separately, the Cyber Resilience Act reaches products with digital elements rather than service operators, and the AI Act’s own Article 15 accuracy and robustness requirements apply to high-risk systems independently of all of this. Mapping which regime owns which control, once, is cheaper than discovering the overlap during an incident.
Top comments (0)