Management board personal liability under the amended Polish NIS2 act: what it means for AI decisions

Reading time: ~12 min

Who this is for: the CISO, board member, IT director or compliance lead at an essential entity who has heard that "the board is now personally responsible for NIS2," and wants to understand what that practically means for AI deployment decisions.

This is not legal advice. It is a mapping of the structure of obligations and the questions worth resolving with your own law firm. I deliberately do not cite the wording or numbering of specific provisions — practical interpretations are still forming, and you should verify the national legislation at the source and with a lawyer.

Table of contents

1. What changed in the responsibility layer
2. "Personal liability" — what it actually means, and what it does not
3. Why the AI decision lands on this particular desk
4. Three decision points where responsibility becomes tangible
5. What the board should be able to show (the decision trail)
6. Where the AI architecture choice fits into all this
7. Disclosure and biases
8. What I do not cover here
9. Related

---

1. What changed in the responsibility layer

NIS2 and its national transposition shift the weight from "IT will take care of it" to "the management body has to oversee this and is responsible for it." This is not cosmetic. Previously, cybersecurity could be delegated downward along with the responsibility. Now the duty to oversee risk management is assigned to the leadership — and that duty cannot be passed off to a subordinate or a vendor.

In practice this means two things. First, the board has a duty to approve and oversee risk-management measures, not merely to "be aware" of them. Second, members of the leadership are expected to have the competence to recognise and assess risk — which implies that "I'm not familiar with this" stops being a line of defence.

Note: the precise scope of the obligations, the definition of "leadership," and the catalogue of sanctions depend on the final text of the national legislation. Treat the below as a skeleton for a conversation with a lawyer, not as an interpretation of the law.

2. "Personal liability" — what it actually means, and what it does not

A fair amount of misunderstanding has grown around this phrase, so let's separate the layers.

What it is. The regime provides that the management body is responsible for a breach of the duty to oversee cybersecurity risk management. This is liability for a failure to oversee, not for every individual technical incident. An incident can happen despite due diligence — the regulator's question is rather: did the leadership implement, approve and oversee adequate measures.

What it is not. It is not automatic criminal liability of every board member for every leak. And it does not disappear the moment a contract with a vendor is signed — selecting and overseeing a vendor is itself part of risk management, so "outsourcing" does not transfer the oversight duty outside the organisation.

The practical consequence for a reader of this portal: if you are a CISO, your board starts asking questions it did not ask before, because the consequence of failing to act is now closer to them personally. And if you are a board member — you need to be able to demonstrate that oversight actually existed.

3. Why the AI decision lands on this particular desk

Deploying AI in an organisation often touches three things the regime takes seriously at once: processing a large volume of data (including sensitive data), introducing a new vendor into the supply chain, and a new surface of technical risk.

When that data goes to a public model API, the organisation introduces an external processor into its supply chain — and that is exactly the element the board has a duty to oversee. So the seemingly "technical" decision of "which AI vendor we use" stops being purely an IT decision. It becomes an element whose oversight rests with the leadership.

This does not mean the board has to read API documentation. It means a documented process has to exist: who assessed the vendor's risk, what criteria were applied, who approved the decision, and on what basis.

4. Three decision points where responsibility becomes tangible

Point 1 — vendor selection. Did an AI vendor risk assessment happen at all, and is it documented? The absence of an assessment is not a neutral state — it is an absence of evidence of oversight.

Point 2 — data flow. Does the organisation know, and can it demonstrate, which categories of data leave its environment (or do not) during the operation of the AI system? "We don't think anything sensitive does" is not an answer you can defend in an audit.

Point 3 — incident response. Is there a plan for the situation where the AI component is itself the source or vector of an incident? Reporting obligations do not disappear because the problem involves "new technology."

At each of these points the question from an auditor or regulator will be similar: show the trail. Not intent, not a declaration — a decision trail.

5. What the board should be able to show (the decision trail)

A minimal set of artefacts that turn "we oversaw it" from a declaration into a fact:

• A documented risk assessment for the AI deployment, with a date and author.
• Vendor selection criteria and a record that they were applied — including how the question of data flow and sub-processors was handled.
• Approval at leadership level, showing that the management body actually engaged with this, rather than merely receiving a note for information.
• A data-flow map showing what goes where in the running system.
• Logs and the ability to reconstruct — so that after an incident it is possible to retrace what happened.

The common denominator: auditability. The regime rewards organisations that can show how they made decisions, not merely claim they were careful.

6. Where the AI architecture choice fits into all this

Here we reach the heart of it from this portal's perspective. The architecture of an AI deployment directly affects how easy (or how hard) it is to produce that decision trail.

A deployment based on a public model API requires documenting and overseeing external data processing: where the data goes, who the sub-processor is, what the data-processing agreement looks like, what happens when terms change. That is workable, but it generates an ongoing duty to oversee an entity over which the organisation has limited influence.

An on-prem deployment moves the boundary: if the data does not leave the environment, a large part of the supply-chain and sub-processor questions disappears — at the cost of taking on responsibility for your own infrastructure, its maintenance and its security. This is not "better"; it is a different distribution of the same risk: less risk on the external vendor's side, more on the side of your own operational competence.

Awareness of that distribution is precisely what the regime expects of the leadership — not a particular choice, but a demonstration that the choice was a conscious one.

Inline disclosure: I work on CortexMine, a productized on-prem AI platform for European manufacturers, so I have an interest in the "on-prem / productized" category. Productized on-prem is one answer to the decision-trail problem, but not for everyone: organisations with a low data-sensitivity profile, or without the operational capacity to run their own infrastructure, are often better served by a well-documented cloud deployment than by their own server room. The choice depends on the risk profile, not on what I happen to be building.

// disclosure & biases7. Disclosure and biases

The author works on CortexMine, a productized on-prem AI platform for European manufacturers. This post touches a category (on-prem vs public cloud) in which I have an obvious interest, so I have tried to keep the analysis of liability at a neutral level: I describe the structure of obligations and questions, I do not recommend a specific solution. Where bias could affect the conclusions, I flag it inline. This content is not legal advice.

8. What I do not cover here

• The wording and numbering of specific provisions of the national legislation — I deliberately do not cite them; a lawyer must confirm these against the current text of the act.
• The catalogue and amount of sanctions — I deliberately give no figures, as they depend on the final regulation and the category of entity.
• Sectors other than manufacturing and related essential entities — energy, healthcare and finance have their own specifics.
• Detailed mapping of supply-chain obligations — covered separately in the analysis of obligations toward AI vendors for essential entities.
• The operational view of AI deployment in manufacturing — for the business perspective see aidlafabryk.pl.

9. Related

• NIS2 and AI vendors in the supply chain: obligations of essential entities
• Public cloud LLMs and NIS2: a quick look at supply-chain requirements
• Vendor lock-in in AI: three layers, two contractual traps