NIS2 and AI vendors in the supply chain: mapping Article 21 for essential entities

Most NIS2 mappings that land on a CISO's desk treat AI as just another line item in the IT systems register. That is a category error. A generative-AI vendor is not an application you host — it is a service provider that processes your operational content, runs on someone else's infrastructure, and carries its own opaque chain of sub-processors. Under Article 21 of the NIS2 Directive (and the national law that transposes it), that vendor is a link in your supply chain that has to be assessed, documented and monitored — the same way you would treat a SCADA or MES supplier.

This guide shows how to map an AI vendor onto Article 21 in concrete terms, where standard vendor management drifts away from the regulation, and what minimum set of documents you need to produce to survive an audit. It is not legal advice — it is a working map for the security architect and compliance lead who actually have to do this work.

A note on jurisdiction: the examples below use the Polish transposition of NIS2, in force since 3 April 2026, because that is the regime I know in detail. The Article 21 obligations themselves are harmonised across the EU; the deadlines, penalty figures and registration mechanics differ by member state. If you operate under the German NIS2UmsG or another national act, treat the substance as transferable and the dates as illustrative.

Table of contents

• The legal ground: what actually applies
• Why an AI vendor is a supply-chain problem, not an IT problem
• Anatomy of the chain: how many vendors you really have
• Mapping Article 21(1)(d) to concrete questions
• Four areas where the standard relationship fails
• Management liability: why it changes the calculation
• A risk-register skeleton for an AI vendor
• Audit-readiness checklist
• The decision: four paths and when each makes sense
• Disclosure and biases
• What this does not cover

The legal ground: what actually applies

Before we get into the mapping, let us set the ground — because a lot of analysis still operates on the pre-transposition state.

The NIS2 Directive (2022/2555) does not bind a company directly. What binds you is the national act that implements it. In Poland that is the amended Act on the National Cybersecurity System: the amendment of 23 January 2026 (Journal of Laws 2026, item 252) entered into force on 3 April 2026, modifying the original 2018 act.

From the standpoint of an AI vendor decision, four elements of the current legal state matter:

• Self-identification instead of an administrative decision. Whether the rules apply to you is increasingly decided not by an authority's ruling but by your own obligation to verify your status. If you meet the criteria, you are an essential or important entity — regardless of whether anyone formally told you so.
• Deadlines. Registration in the register of essential and important entities by 3 October 2026 (for entities meeting the criteria at the entry-into-force date). Implementation of the information security management system and the Chapter 3 obligations by 3 April 2027. First audit of an essential entity by 3 April 2028.
• Penalties. Up to EUR 10,000,000 or 2 percent of total worldwide annual turnover for an essential entity. On top of that, up to 300 percent of the remuneration of a person holding a management position.
• Supply chain as a distinct risk area. The requirement to assess the security of relationships with direct suppliers is squarely in the substantive scope of the act, identical to Article 21 of the Directive.

The practical takeaway: the 2027 and 2028 deadlines look distant, but an AI vendor decision made today will be assessed in that first audit. Documentation debt taken on now gets repaid under time pressure in 2027.

Why an AI vendor is a supply-chain problem, not an IT problem

Classic IT vendor management asks: does the supplier hold SOC 2? Does it encrypt data at rest? Does it have a continuity plan? Good questions — but insufficient for an AI vendor, for three reasons.

First, an AI vendor processes content, it does not merely store it. When a maintenance team pastes a fault description into a model to generate a service instruction, the vendor receives the organisation's operational knowledge — sometimes trade secrets, sometimes personal data, sometimes information that has real value in the hands of a competitor or an attacker. This is not a file backup. It is a continuous stream of sensitive content.

Second, an AI vendor rarely runs on its own infrastructure. The major generative-AI providers run on hyperscalers. That means your supply-chain risk assessment does not stop at the vendor — it reaches the vendor's compute sub-provider and beyond.

Third, a vendor's product-development practices are opaque. Article 21 requires you to factor in the quality of a supplier's secure-development practices. For an AI vendor that means questions about training-data governance, model lifecycle, and whether your content is used for further training. These are questions a classic security questionnaire has no field for.

So an AI vendor does not belong in the same drawer as an ERP system. It needs its own mapping.

Anatomy of the chain: how many vendors you really have

The first step of the mapping is to draw the real chain. An organisation that "just bought a licence for an AI assistant" usually has no idea how many suppliers actually entered its supply chain.

The minimum chain for a public LLM vendor looks like this:

• The application-layer provider (interface, assistant, integration) — the party you signed with.
• The model provider — sometimes the same entity, sometimes another (when the application is built on someone else's API).
• The hyperscaler — the compute infrastructure the model runs on.
• Operational sub-processors — CDN, observability, billing, support, sometimes content moderation.

From an Article 21 perspective, each of these links is part of your supply-chain risk assessment. Not because you have a contract with them (usually you do not), but because your content flows through them. A standard DPA typically lists sub-processors in a separate document that can change on as little as 30 days' notice. That means your supply-chain risk register is a living document, not a one-off.

For an on-prem deployment the same diagram is dramatically shorter: the software or model provider, your infrastructure, done. The number of links you have to assess and monitor is one of the most underrated variables in the build-versus-buy calculation — I will come back to it in the decision section.

Mapping Article 21(1)(d) to concrete questions

Article 21(1)(d) speaks of supply-chain security, including security aspects of the relationship between an entity and its direct suppliers. The clarifying paragraph requires you to account for each supplier's specific vulnerabilities, the overall quality of its products and cyber practices, and its secure-development practices.

Let us translate that into the questions you actually ask an AI vendor — and document the answers to:

Supplier-specific vulnerabilities:

• Where is content physically processed (region, specific data centre)?
• Which content categories may be sent, and which may not (client-side data classification)?
• Is client content isolated from other clients at the infrastructure level, or only logically?
• Can client content end up in a training set — by default, optionally, never?

Quality of products and cyber practices:

• What certifications does the vendor and its hyperscaler hold (SOC 2 Type II, ISO 27001, ISO 42001)?
• How is vendor-employee access to client content managed?
• What is the mechanism and SLA for data deletion at contract end?

Secure-development practices:

• How does the vendor manage the model lifecycle and its updates?
• What are its training-data governance practices?
• Does the vendor offer an attestation or a third-party report covering these areas?

Every "don't know" in this table is a gap in the mapping that an auditor will see. Every "vendor declines to answer" is a position you must either accept deliberately (with a management rationale) or solve another way.

Four areas where the standard relationship fails

From an analysis of publicly available contracts (DPAs, master service agreements, sub-processor lists), four recurring friction points emerge between a standard public-AI-vendor offering and Article 21.

1. Sub-processor transparency

A standard DPA lets the vendor change sub-processors on limited notice. For an essential entity that must keep a current supplier list in its mapping, that means a continuous monitoring obligation. In practice: someone in the organisation checks the sub-processor list every month and updates the risk register. If no one does, the mapping is stale the day the vendor makes its first change.

2. Audit rights

Classic enterprise SaaS grants an audit right within narrow bounds: annual frequency, scope limited to certifications. Article 21 expects an assessment of development practices. Few AI vendors will agree to an audit of their MLOps pipeline or training-data governance, and where they do, the audit itself is expensive. The most common workable solution is accepting a third-party report in place of a self-run audit — which you must deliberately document as a compensating control, not pass over in silence.

3. Incident notification

The Polish act requires reporting a serious incident within tight timeframes (an early warning measured in hours from detection). If the incident occurs at the vendor or its hyperscaler, you must learn of it faster than a standard "without undue delay" formula provides. A standard contract rarely guarantees notification in hours. The conclusion: you cannot rely on vendor notification alone — you need your own monitoring and a runbook for the "incident at the vendor" scenario.

4. Liability asymmetry

A typical contract caps the vendor's liability at twelve months of fees. On your side, the exposure is a penalty of up to EUR 10 million or 2 percent of turnover, plus personal management liability. The asymmetry is not a "you may not" argument — it is a position the board should see and accept deliberately, in writing, because it is their head on the line.

Management liability: why it changes the calculation

The most important change the current legal state introduces is not technical. It is about who is on the hook. The Polish act provides for a penalty of up to 300 percent of the remuneration of a person in a management position for failing to discharge the obligations.

That moves the AI vendor decision from "the IT team picked a tool" to "the board accepted a risk." In practice that means:

• the decision to admit a public AI vendor to operational content should be documented as a deliberate risk-acceptance, not as an operational purchase;
• an analysis of alternatives (including options where content never leaves the organisation) should be part of that documentation, because the auditor will ask whether lower-risk options were considered;
• the compliance lead and CISO need a formal escalation path to the board, not just a signature on a purchase order.

For the CISO this is good and bad news at once. Bad: the pressure rises. Good: the argument for solid mapping and for considering lower-risk architectures stops being "the security team being paranoid" and becomes protection for the board.

A risk-register skeleton for an AI vendor

The minimum register worth holding for each AI vendor in the chain, before the auditor arrives. Each item is one column or one entry:

• Vendor and role in the chain (application / model / hyperscaler / sub-processor).
• Content categories sent to the vendor (cross-referenced to the data-classification policy).
• Processing location (region plus, where available, a specific data centre).
• Sub-processor list and date of last review.
• Mechanism for monitoring sub-processor changes (who, how often, recorded where).
• Available attestations or certifications (type, validity date).
• Data-deletion mechanism and SLA at contract end.
• Incident-response runbook for the "incident at the vendor" scenario.
• Risk-acceptance decision (who accepted, date, rationale, compensating controls).
• Next review date (recommended: quarterly).

This register is the heart of the Article 21 mapping for AI. If it exists and is current, the supply-chain audit for the AI area is defensible. If it is missing, no amount of vendor certifications will stand in for it.

Audit-readiness checklist

A short self-check before the first audit (reminder: for an essential entity the Polish deadline is 3 April 2028, but decisions made today will be assessed then):

• Does every AI vendor have an entry in the supply-chain risk register?
• Does the data classification define which content categories may be sent to an external vendor?
• Is there a documented, quarterly procedure for reviewing the sub-processor list?
• Is the decision to admit a public AI vendor documented as board-level risk-acceptance?
• Is there a runbook for an incident at the AI vendor, consistent with the notification timeframes?
• Does the contract include a data-deletion mechanism with a confirming SLA?
• Have lower-supply-chain-risk alternatives been considered and documented?

Seven questions. Every "no" is a line item in the workplan to April 2027.

The decision: four paths and when each makes sense

The Article 21 mapping does not end with "allowed" or "not allowed." It ends with choosing an architecture whose risk profile is acceptable. Four typical paths:

Path 1: Public AI vendor with full mapping. Sensible when the content categories processed are low-risk and the organisation has the capacity for continuous register and monitoring upkeep. Hidden cost: ongoing supply-chain maintenance.

Path 2: Dedicated / isolated hyperscaler offering (e.g. models run in a segregated tenant). Shortens the chain and improves control over location, but does not remove the hyperscaler from the supply chain. Requires its own calibration analysis.

Path 3: On-prem deployment of an open-source or licensed model. Content never leaves the organisation; the supply chain shrinks to the software or model provider and your own infrastructure. The Article 21 mapping becomes shorter, because many of the location and sub-processor questions resolve by definition. The cost shifts to infrastructure and operational competence.

Path 4: Hybrid — low-risk content to a public vendor, sensitive content on-prem. The most flexible, but it requires hard, enforced data classification, otherwise it becomes a fiction.

There is no universally best path. There is the path whose supply-chain risk profile the board is willing to accept deliberately, knowing the liability asymmetry. The Article 21 mapping is the tool that makes that decision deliberate rather than default.

// disclosure & biasesDisclosure and biases

The author (Fryderyk Pryjma) works on an on-prem AI platform for European manufacturers. The analysis in this post may be biased toward architectures where content never leaves the organisation (Path 3 and partly 4). Where that bias could tilt the conclusions, I have tried to flag it inline — in particular, in the decision section I list the public vendor and the hyperscaler offering as fully legitimate paths, because for many organisations they are the right choice. The estimates of compliance effort and the readings of contractual practice are my judgement, based on analysis of publicly available documents and conversations with compliance leads, not a binding legal interpretation.

What this does not cover

This pillar is deliberately not a complete analysis of NIS2 or its Polish transposition. I left out:

• the other points of Article 21(1) (e.g. point (f) — policies on assessing the effectiveness of measures — which also touches AI vendor selection);
• the detailed relationship between the notification obligations and the CSIRT incident-reporting mechanism in a vendor-breach scenario;
• the AI Act and its high-risk-system classification, which may overlap with the vendor decision;
• cross-mapping with ISO 27001 and ISO 42001;
• the concrete build-versus-buy economics with figures for a mid-sized 500-FTE company;
• the technical architecture of an on-prem deployment (GPU sizing, RAG, network isolation).

I develop these threads in later posts.