How should teams determine whether an AI service falls under NIS2?

How to classify an AI service under NIS2

The practical test is not whether the workload is “AI” in the abstract. Teams should ask whether the service sits inside the organisation’s network and information systems, supports a covered business function, and is operated or materially controlled by the entity. That means the classification should follow ownership, dependency, access, and reporting obligations, not the branding of the tool.

A useful starting point is the service boundary. If the AI service is part of the production environment, processes operational data, or directly supports a regulated business process, it is much more likely to belong in the NIS2 scope of the entity. If it is only a peripheral pilot with no operational dependency, the case is weaker and needs stronger evidence before it is treated as in-scope.

For a defensible decision, teams should document who owns the service, where it runs, what data it touches, which administrators can change it, and whether a supplier or platform provider shares operational responsibility. That evidence matters because NIS2 scope decisions are usually challenged through control evidence, not through a description of the AI model itself. NIS2 Directive Guide is a useful reference for the essential and important entity model and the incident and governance obligations that sit behind the classification.

Where the AI service is integrated through APIs, cloud tenancy, managed services, or delegated administration, the question becomes one of control and accountability as much as technology. The stronger the operational dependence, the more likely the service should be treated as part of the entity’s security and reporting perimeter rather than as an external convenience layer.

What evidence makes the NIS2 classification defensible?

The strongest classifications are supported by artefacts that show how the service is actually used. Teams should be able to produce service ownership records, architecture diagrams, data flow maps, admin access lists, supplier responsibility matrices, logging coverage, and incident escalation paths. These items show whether the AI service is a controlled operational component or simply an external dependency.

If the service supports a business process that the organisation could not easily absorb without disruption, that is a sign the service is functionally embedded. In that case, evidence should show how the service is monitored, who can approve changes, how access is granted and reviewed, and how incident reporting would work if the service failed or was compromised. The point is to prove that the classification is based on operational reality, not assumptions.

When the service is delivered by a vendor, the contract and operating model matter. Teams should confirm whether the organisation can direct security settings, obtain logs, enforce access restrictions, and meet incident notification duties in practice. If those obligations cannot be met, the classification should be revisited rather than papered over.

For a broader control and audit lens, the Identity Security Regulatory Map helps connect regulatory requirements to the kinds of ownership, access, and audit evidence that make a scope decision sustainable.

When should an AI service be treated as in-scope even if it is externally hosted?

External hosting does not automatically place a service outside NIS2. If the organisation operates the service, determines its use, or relies on it for a covered function, the service can still sit inside the control perimeter even when the infrastructure is outsourced. The practical issue is whether the entity retains enough control to manage risk, evidence, and reporting obligations.

This is where shared-responsibility models become important. An AI service may be supplied by a third party, but the entity may still be responsible for data governance, user access, logging, incident escalation, and business continuity. If the AI service can affect availability, integrity, or regulated operations, its external location is not a reason to exclude it from scope by default.

Teams should also be cautious with pilot-to-production drift. A service that starts as a test environment can become operational without a formal review of ownership, access, or logging. That is a common failure mode because the service is treated as “just tooling” long after it begins supporting a regulated workflow.

The EU NIS2 Directive is the primary authority for the scope logic, and it should be used alongside the vendor contract and internal system inventory rather than as a standalone checklist.

Risk and Threat Considerations

Misclassifying an AI service can leave a covered business function without the logging, access control, and incident handling discipline that NIS2 expects. The risk is not only regulatory. A poorly classified service can also create blind spots in accountability, supplier oversight, and incident reporting when the service is disrupted or abused.

Failure mechanism: Organisations often focus on the model or user interface and ignore the operational dependencies behind it, so they miss where the service is actually controlled, who can administer it, and whether the business has a real response path if it fails.

Impact: That gap can produce weak evidence, delayed escalation, and incomplete incident reports, and it can also leave the organisation unable to demonstrate why the service was treated as in-scope or out-of-scope in the first place.

Practitioner Guidance

What to verify: Confirm three things before you finalise the classification: the service’s role in a covered business function, the organisation’s level of operational control, and the evidence trail for access, logging, and incident handling. If any one of those is unclear, the classification is not yet defensible.

Decision rule: If the AI service can change regulated outcomes, affect availability, or trigger incident-reporting duties, treat it as part of the NIS2 control perimeter until the ownership and responsibility model proves otherwise. If it is only a disconnected experiment with no production dependency, keep it out of the core scope and document why.

Practitioner takeaway: The safest approach is to classify by operational reality, not by deployment label, because NIS2 scope follows control, dependency, and evidence, not whether the system is marketed as an AI service.

Related resources from NHI Mgmt Group

• How should organisations determine whether a credit scoring model falls under the EU AI Act high-risk rules?
• How should organisations determine whether a product or service falls under ITAR or a different export control regime?
• How do organisations know whether AI is truly under governance control?
• How can teams tell whether AI access is actually under control?