NIS2 and self-hosted AI infrastructure
NIS2 doesn't mention AI at all, but for companies it applies to, the directive's supply-chain and risk-management obligations reach into how AI infrastructure is sourced and operated, the same way they reach into any other IT dependency. This is general background on the directive's structure, not legal advice, and whether it applies to your organization, and what it requires, depends on your sector, size, and the implementing law in your member state. Confirm with counsel before treating anything here as a compliance answer.
What NIS2 is, in general terms
NIS2 is an EU directive on cybersecurity, the successor to an earlier NIS directive, aimed at raising the baseline level of cyber risk management across sectors the EU treats as critical or important to the internal market. Being a directive rather than a regulation, it doesn't apply directly and uniformly the way GDPR does; each EU member state transposes it into national law, and the specifics, scope thresholds, sector lists, enforcement mechanics, can differ from one country to the next. That means two companies in the same industry but different member states may face meaningfully different obligations even though both are working from the same underlying directive.
The directive generally organizes obligations around whether an entity is classified as "essential" or "important," categories tied to sector and size, with essential entities typically facing closer supervision. We're deliberately not stating specific thresholds, sector lists, or deadlines here, those details vary by member state's implementing legislation and by the entity's own classification, and getting one wrong in a blog post is worse than leaving it for your counsel to confirm.
What the obligations tend to cover
Where NIS2 does apply, the obligations it imposes tend to cluster around a few themes, described here at a general level rather than as a checklist to satisfy:
- Risk management measures. In-scope entities are generally expected to implement technical and organizational measures to manage the risks to the security of their network and information systems, proportionate to the risk.
- Incident reporting. Significant incidents typically need to be reported to a national authority within defined timeframes, with the exact triggers and windows set by the implementing law.
- Supply chain security. Entities are generally expected to assess and manage risk arising from their suppliers and service providers, not just their own internal systems, in recognition that a weak link in a vendor can become an entity's own incident.
- Governance and accountability. Management bodies are often given some level of direct responsibility for approving and overseeing cybersecurity risk-management measures, rather than treating it purely as a technical function.
Why AI infrastructure sits inside the supply-chain question
If your organization is in scope for NIS2, the supply chain security element is where AI infrastructure choices become relevant, not because NIS2 singles out AI, but because AI infrastructure is infrastructure. The vendor operating the hardware your models run on, what's in that vendor's own supply chain, who has access to the systems, and how incidents on their end would reach you, are the same category of questions a NIS2 risk assessment would ask about any other supplier of network and information systems. An AI workload that runs on infrastructure you don't understand the operator or supply chain of is a gap in that assessment the same way an unreviewed cloud vendor or a subcontracted data center would be.
This is a reason to ask the question, not a reason to assume any particular answer is required. Self-hosting on infrastructure with a known, simple operator and a short supply chain can make that part of a risk assessment easier to reason about than a multi-vendor arrangement with several subcontracted layers, but "easier to reason about" isn't the same as "satisfies NIS2," and a self-hosted setup can just as easily be poorly secured. The directive cares about the risk-management outcome, not about which hosting model you picked.
What we're not claiming
We're not stating that GPUwerk is NIS2 certified, that NIS2 has no certification scheme at all, it's a directive with obligations on in-scope entities, not a badge a vendor earns. We're not claiming any specific deadline, fine amount, or sector threshold applies to your organization; those vary by member state and by classification, and we haven't attempted to track every national implementation here. And we're not claiming that using self-hosted infrastructure from any vendor, including us, resolves NIS2 obligations on its own. It narrows one input into a supply-chain risk assessment; it doesn't replace the assessment.
What to actually do
- Confirm whether NIS2 applies to your organization at all, and under which member state's implementing law, before treating any of the obligations above as binding on you.
- If in scope, inventory your AI infrastructure vendors as part of your supply chain risk assessment, the same way you would any other IT supplier, including who operates the hardware and what's known about their own security practices.
- Ask AI infrastructure vendors directly about their supply chain, rather than assuming a shorter chain is automatically compliant or a longer one is automatically a problem. See our private LLM hosting page for how GPUwerk answers this for its own setup: single-tenant hardware, EU-Central, operated by PRINT IT! SE.
- Verify any deadline or classification question with counsel before it goes into a compliance filing or board report.