Definition: AI security in critical infrastructure covers all measures that operators use to pick, run and monitor AI systems. This applies to energy, water, transport, healthcare and digital infrastructure. The goal: AI must not put the security of supply at risk. Three things count most. The AI must stay stable under stress. People must keep control. And the AI must be part of the risk management the law asks for.
Where AI is used in critical infrastructure
AI is now used in many sectors. It mostly starts as a helper:
- Energy: Forecasts for load and renewable output, grid state estimates, predictive maintenance for substations and wind turbines.
- Water and wastewater: Leak detection, tuning of pumps and dosing systems, analysis of water quality sensor data.
- Transport: Traffic control, checks on the state of tracks and bridges, dispatching.
- Healthcare: Support for diagnostics and bed management in hospitals.
- Security operations: Spotting anomalies in IT and OT networks, analysing security events in the SOC.
Every risk check must answer one key question. Does the AI only prepare information for people? Or does it act directly on physical processes? Each step towards automated control raises the bar. The system must then be more stable and easier to trace. It also needs a better plan B.
Specific risks
- Manipulated input data: Faked sensor values or crafted inputs (adversarial examples) can push a model into wrong forecasts or control commands.
- Poisoned training data: Someone with access to past operating data or to a supplier's models can plant backdoors. These only trigger under certain conditions.
- Unexpected operating conditions: Models trained on normal operations may act in odd ways during extreme weather, partial outages or crises. That is just when you need them most.
- New links between IT and OT: AI platforms often need data from control systems and links to cloud services. Each new interface can weaken the split between office IT and the control network.
- Vendor dependency: Model updates, remote access for maintenance and licence terms all affect whether the system stays up.
Legal framework: the BSI Act and NIS2
Germany transposed the NIS2 Directive (EU) 2022/2555 through the NIS2UmsuCG. The revised BSI Act (BSIG) has applied since December 2025. It knows three groups: important entities, particularly important entities and operators of critical facilities. The last group has the strictest rules.
The BSIG has no separate rules for AI. But AI systems are part of your IT. And Section 30 BSIG says your risk management must cover all IT systems, parts and processes. That includes:
- risk analysis
- supply chain security
- vulnerability management
- incident handling
Operators of critical facilities have extra duties. They must use attack detection systems and regularly prove compliance to the BSI. Significant incidents have reporting deadlines. This also applies if an AI system caused the incident or was hit by it:
- 24 hours: early warning
- 72 hours: notification
- one month: final report
Top management is liable if this is not done. It must also go to training on a regular basis (Section 38 BSIG).
There is also the German KRITIS umbrella act (KRITIS-Dachgesetz, in force since 17 March 2026). It transposes the CER Directive (EU) 2022/2557 and deals with the physical resilience of critical facilities. Its focus is not cybersecurity or AI. Operators should check how it fits with their BSIG duties in their own case.
High-risk AI under the EU AI Act
Annex III point 2 of Regulation (EU) 2024/1689 sets out which AI systems count as high risk. These are AI systems that act as safety components. They help run critical digital infrastructure or road traffic. Or they help supply water, gas, heat or power. A pure forecast or analysis function with no safety role does not count by default. Art. 6(3) also allows exceptions. If you use one, you must document it.
For high-risk systems, providers must show several things (Art. 9 to 15):
- a risk management system
- data quality
- technical documentation
- logging
- human oversight
- accuracy, robustness and cybersecurity
Art. 15 names protection against data poisoning, model poisoning and manipulated inputs. Deployers are the infrastructure operators themselves. Under Art. 26, they must use the system as planned. Skilled staff must oversee it. They must also watch it while it runs and keep the logs it writes.
The Digital Omnibus (in force since 27 July 2026) moved the deadlines back. Duties for Annex III high-risk systems apply from 2 December 2027. For high-risk AI in regulated products under Annex I, they apply from 2 August 2028.
Practical safeguards
- Classify the purpose: For every AI system, note whether it advises, recommends or controls. Also note whether it counts as a safety component under the AI Act.
- Bring AI into the ISMS: List models, training data and AI platforms in the asset register and in the risk analysis under Section 30 BSIG. Include their suppliers.
- Keep humans in the decision: Set plausibility limits on control commands from AI systems. Only carry out critical actions after operating staff approve them.
- Ensure a fallback: Operations must be able to continue without AI in a defined, safe mode. This belongs in your emergency and recovery plans.
- Keep the network split: Do not connect AI platforms directly to the control network. Use controlled transfer points with one-way data flow where you can.
- Test under stress: Before go-live, test models with extreme values, missing sensor data and deliberately manipulated inputs. MITRE ATLAS lists relevant attack scenarios.
- Monitoring and reporting: Keep watching model behaviour and data quality. Include AI-related disruptions in your incident reporting to the BSI.
Conclusion
For critical infrastructure operators, AI is not a separate topic. It is part of their existing duties under the BSIG and NIS2. For safety-relevant uses, the AI Act adds stricter rules. SecTepe helps operators bring AI systems into risk analysis, attack detection and emergency management.
Frequently asked questions
Is every AI system at a critical infrastructure operator automatically high-risk?
No. What matters is whether the system is a safety component in running the infrastructure. A customer service chatbot at a municipal utility, for example, is not high-risk AI under Annex III point 2.
Does an AI incident have to be reported to the BSI?
Yes, if it meets the criteria of a significant security incident. Whether an AI system or a classic component caused it makes no difference to the duty to report.
More terms in “AI & Machine Learning”
- Adversarial Machine Learning
- AI Backup and Model Recovery
- AI Certification
- AI Data Protection Impact Assessment (AI DPIA)
- AI Forensics
- AI Governance for Managing Directors
- AI Governance Framework
- AI Incident Response Playbook
- AI Monitoring and Anomaly Detection
- AI Penetration Testing
- AI Phishing Detection
- AI Poisoning