ot-ai-compliance-map

Which obligations actually apply when you run AI inside an industrial or KRITIS environment — mapped across EU AI Act, NIS2 (German implementation) and IEC 62443.

Machine-readable. Scenario-driven. Built by a practitioner, not a law firm.

You want to deploy an on-premises AI assistant in a plant. Three regulatory frameworks land on the same system at the same time:

• EU AI Act — is this "high-risk"? What documentation do I owe?
• NIS2 / NIS2UmsuCG — how does an AI component change my risk-management and reporting duties?
• IEC 62443 — which zone does it live in, which conduits does it open, does my SL-T still hold?

Ask three specialists and you get three answers that don't compose. Most projects then either over-comply into paralysis, or under-comply and discover it at audit.

The most common single error we see: assuming that AI in critical infrastructure is automatically "high-risk" under the AI Act. Usually it is not — but there is a precise line where it flips, and almost nobody can say where. This map says where.

• OT/ICS security architects designing an AI deployment
• CISOs at KRITIS operators and industrial companies
• Integrators and vendors who have to answer "is this compliant?" in a workshop
• Anyone who has to produce evidence, not opinions

Start here → docs/ — readable briefings, one per deployment scenario. No tooling required, nothing to run, readable in the browser. Three ways people actually use them:

Open data/scenarios.yaml and ask: which of these shapes is your deployment? The properties block — autonomy, write access, network egress, human-in-the-loop, safety influence — is a scoping questionnaire in disguise. Five questions that determine everything downstream, and they're the right five.

Every briefing ends with an evidence checklist: binding requirements and classification decisions, flattened into one printable list with their source records. Non-binding advice gets its own clearly labelled suggestions. Walk the deployment, tick what exists, and what's left is your gap analysis. → e.g. the evidence checklist for the read-only assistant

"Is this high-risk under the EU AI Act?" — the question most projects get wrong. Each briefing opens with the classification, the reasoning, and the precise line where the answer flips. → the short answer for a read-only assistant

data/                          # source of truth (edit here)
├── frameworks.yaml            # the three frameworks, versions, in-force dates
├── scenarios.yaml             # deployment shapes
└── obligations/{eu-ai-act,nis2-de,iec62443}.yaml

docs/                          # GENERATED — read here, never edit
tools/generate_briefings.py    # data/ → docs/

Install the generator dependency once with python3 -m pip install -r requirements.txt. Regenerate after any data change: python3 tools/generate_briefings.py. CI-friendly staleness check: python3 tools/generate_briefings.py --check.

Each record carries: id, type, source (the actual article/clause), sources (traceable public references), applies_to, what_it_requires, evidence (what you must be able to show), confidence, and its own last_verified date.

confidence is a first-class field. Where the law is unsettled — and in 2026 a lot of it is — the map says so instead of pretending.

Going from answering to acting changes exactly three things, and each moves a control:

1. The system acquires an identity. It must be its own, with least privilege per target system — not a shared service account. The convenience decision made in week one is what destroys incident attribution in month nine.
2. Every integration must be mapped to the zone/conduit model. It may use an existing conduit or require a new one. MCP makes adding an integration a five-minute task; the IEC 62443 reassessment it triggers is not. That asymmetry is how zone models silently go stale.
3. It touches the incident-handling process, not just the asset inventory — which pulls it into NIS2's process scope. Useful default: the agent may add information, never remove or downgrade it.

What does not change: the AI Act classification. Bounded, supervised actions on IT systems don't make a system a safety component. But the classification must be re-run and re-documented on every capability change — and almost nobody owns that.

The AI-specific threat worth naming to an OT audience: indirect prompt injection. Retrieved content can carry instructions the model follows, which turns a document-integrity problem into an action-execution problem. Mitigations are architectural (least privilege, allow-listed operations, approval gates for side effects), never prompt-based.

• NIS2 in Germany is live. The BSIG 2025 was promulgated on 2 December 2025 and entered into force on 6 December 2025. Its §§30, 32, 33 and 38 cover documented risk-management, incident reporting, registration, and management implementation/training duties. This is a present-tense obligation (official BSIG, §32 reporting, §33 registration).
• The AI Act timeline now reflects the Digital Omnibus amendments. Article 50 transparency rules apply from 2 August 2026; Annex III high-risk rules apply from 2 December 2027; high-risk AI embedded in regulated products covered by Annex I applies from 2 August 2028. Re-check the Commission timeline before relying on a future date (EC AI Act implementation timeline, EC AI Act FAQ).
• Obligations that already applied since 2025 (prohibited practices, AI literacy, GPAI provider duties) are not affected by the postponement. AI literacy in particular is widely overlooked and applies to operators today.

Corrections are the point. If an obligation is mis-scoped, a citation is wrong, or a confidence rating is too generous — open an issue. Practitioner disagreement is more useful here than polish.

This is not legal advice. It is a structured engineering aid built from public regulatory texts, intended to make compliance conversations concrete and to be checked by qualified counsel. Regulations change; every record carries a last_verified date for a reason. Verify before you rely.

Data (data/, docs/): CC BY 4.0 — use it, fork it, cite it. Code (when added): MIT.