Abstract: Autonomous AI agents are entering infrastructure operations: triaging alerts, remediating incidents, proposing configuration changes, and managing deployments. The tooling is maturing fast. The governance model is not. This article examines what happens when agentic AI meets EU-regulated infrastructure, identifies the structural accountability gap that current approaches leave open, and proposes a guardrail architecture that makes AI agents auditable, bounded, and compliant by construction.
The agentic shift in operations
The operational use of AI in infrastructure has moved beyond chatbots and copilots. The current generation of tooling, agentic SRE platforms, autonomous remediation engines, AI-driven deployment pipelines, operates with increasing autonomy. An agent receives an alert, correlates it with recent changes, proposes a remediation, executes it within a sandbox, verifies the result against SLOs, and either promotes the fix or rolls it back. Some of these systems run without human approval for well-understood failure modes.
This is genuinely useful. Alert fatigue is real. The time from detection to remediation matters. Automating the predictable cases frees human operators to focus on the novel ones. The engineering case for agentic AI in operations is strong.
The governance case, however, has not kept pace. Most agentic AI deployments in infrastructure are governed by informal conventions: prompt engineering, ad-hoc testing, and trust in the vendor’s safety claims. For infrastructure that falls under EU regulation, NIS2, the AI Act, the Cyber Resilience Act, DORA, this is insufficient.
The accountability gap
EU regulation is built on a simple principle: someone is accountable. NIS2 Article 20 places cybersecurity risk management responsibility on the management body. The AI Act assigns obligations to providers, deployers, and importers. DORA requires financial entities to retain full responsibility for ICT risk management, including when they outsource to third parties.
An autonomous AI agent complicates this chain. When an agent remediates an incident by modifying a firewall rule, scaling a deployment, or restarting a service, the action has consequences. If the remediation causes a secondary outage, who is accountable? The operator who configured the agent? The vendor who trained the model? The platform team that approved the agent’s scope of action?
The honest answer in most current deployments: nobody has thought about it. The agent just does things, and if they work, nobody asks.
This is the accountability gap. Not a failure of technology, but a failure of governance architecture. The agent operates in a space between human decision-making (where accountability is clear) and traditional automation (where deterministic scripts produce predictable outputs). An AI agent is neither. It makes decisions under uncertainty, with variable outputs, in contexts its operators did not fully anticipate. And current deployment practices do not capture the evidence needed to reconstruct its reasoning after the fact.
What the AI Act actually requires
The AI Act does not ban autonomous agents in infrastructure. What it requires is transparency, traceability, and human oversight – properties that are achievable but not automatic.
For high-risk AI systems (which includes safety components of regulated products and systems used in critical infrastructure management), Article 9 requires a risk management system that operates throughout the entire lifecycle. Article 12 requires automatic logging of events relevant to identifying risks, including the input data, the system’s output, and any human override decisions. Article 14 requires human oversight measures that allow a natural person to understand the system’s capabilities and limitations, monitor its operation, and intervene or interrupt it.
For general-purpose AI models used within these systems, Article 53 requires documentation of training, evaluation, and known limitations.
None of this is impossible. But it requires architecture, not just deployment. An agent that executes actions without structured logging of its inputs, reasoning trace, outputs, and outcomes does not meet Article 12. An agent that operates without a defined intervention mechanism does not meet Article 14. An agent whose risk profile is not assessed within the context of the specific infrastructure it operates on does not meet Article 9.
NIS2 and the evidence problem
NIS2 creates a parallel set of obligations. Essential and important entities must implement cybersecurity risk management measures (Article 21) and report significant incidents within defined timelines (Article 23). The implementing acts specify that these measures must be proportionate and that their effectiveness must be evaluable.
An AI agent that remediates incidents autonomously creates two evidence challenges.
First, the agent’s actions are themselves security-relevant events. A firewall rule change, a service restart, a credential rotation – these are the kinds of changes that incident investigators examine first. If the agent’s actions are not logged with sufficient detail to distinguish them from malicious activity, the incident response process is compromised. An analyst looking at a modified firewall rule needs to know immediately whether it was changed by an authorised agent executing a known playbook, or by an attacker. The audit trail must make this unambiguous.
Second, the agent may mask incidents. An agent that automatically remediates a symptom (restarting a crashing service, scaling up to absorb a traffic spike) may prevent the underlying incident from being detected and reported. If the root cause is a security incident that meets the NIS2 reporting threshold, automatic remediation of the symptom without escalation is a compliance failure.
A guardrail architecture for agentic operations
The solution is not to avoid AI agents in regulated infrastructure. It is to deploy them within an architecture that makes their operation auditable, bounded, and interruptible. This architecture has four components.
Scoped authority. Every agent operates within a defined scope: which systems it can observe, which actions it can take, which conditions must hold before it acts. This scope is expressed as policy, not as prompt instructions. Policy-as-code (OPA, Kyverno, Cedar) provides the enforcement mechanism. The agent’s scope is a first-class infrastructure artifact, version-controlled, reviewed, and auditable. Changes to an agent’s scope are change management events, not configuration tweaks.
Structured evidence. Every agent action produces a structured record: the trigger (what initiated the action), the context (what the agent observed), the decision (what action was selected and why), the execution (what was actually done), and the outcome (what changed and whether the verification passed). This is not a log line. It is an evidence record with a defined schema, signed by the agent’s identity, and stored in an append-only evidence store. This record is what satisfies Article 12 of the AI Act and what enables incident investigators to reconstruct the agent’s behaviour under NIS2.
Human gates at consequence boundaries. Not every agent action requires human approval. Restarting a crashed pod does not. Modifying a network policy does. The distinction is consequence, not complexity. Actions that cross defined consequence thresholds – security-relevant changes, actions affecting availability of critical services, modifications to compliance-relevant controls – require human approval before execution. The agent proposes; the human authorises; the agent executes; the evidence record captures both decisions. This is what Article 14 of the AI Act means by human oversight in practice.
Circuit breakers and safe-halt. An agent that is producing unexpected outcomes must be stoppable. A circuit breaker pattern monitors the agent’s error rate, the deviation of its actions from expected patterns, and the SLO impact of its interventions. If any of these exceed defined thresholds, the agent is halted and a human is notified. The safe-halt state is defined in advance: what the agent stops doing, what state it preserves, and what evidence it emits on shutdown. This is the degraded mode requirement from the AI Act and the fail-safe principle from the Machinery Regulation, applied to software agents.
The autonomy gradient
Not all agent actions carry the same risk. A practical guardrail architecture applies different levels of oversight based on consequence.
L4 – Autonomous (bounded): well-understood remediations with known blast radius. Pod restart, certificate rotation, horizontal scaling within defined limits. The agent acts, logs, and reports. Human is notified after the fact.
L3 – Supervised autonomous: remediations that affect service topology or resource allocation beyond a single workload. The agent acts within pre-approved playbooks, human monitors dashboards and can intervene. Evidence is generated for each action.
L2 – Semi-automated: actions with security or compliance implications. Network policy changes, access control modifications, deployment to production of components with changed dependencies. The agent proposes and prepares; human reviews and approves; agent executes.
L1 – Assisted: novel situations, cascading failures, actions affecting other tenants or external systems. The agent provides analysis and recommendations. Human makes the decision and may execute manually.
The classification of actions into these levels is itself a governance artifact. It must be documented, reviewed, and updated as the agent’s capabilities and the infrastructure’s risk profile change. The boundary between L3 and L2 – between “act and report” and “propose and wait” – is the most consequential decision in the entire architecture.
Evidence schema in practice
A minimal evidence record for an agent action contains:
Identity: which agent, which version, which policy version governed it, which credentials it used.
Trigger: the event or condition that initiated the action, with timestamp and source reference.
Context: the observations the agent made before deciding – metrics, logs, configuration state, correlated events. This is the input data that Article 12 of the AI Act requires to be logged.
Decision: the action selected, alternatives considered (if available from the agent’s reasoning), confidence level, and the policy rule that authorised the action.
Approval: for gated actions, the identity of the human who approved, with timestamp. For autonomous actions, the policy rule that pre-authorised the action class.
Execution: the precise changes made – before/after state, commands issued, API calls made, resources modified.
Outcome: verification result – did the remediation achieve its objective? SLO status before and after. Any secondary effects detected.
This schema is verbose by design. The cost of storing structured evidence is negligible compared to the cost of reconstructing an agent’s behaviour from unstructured logs during an incident investigation or regulatory audit.
The vendor transparency problem
Most agentic AI platforms in the infrastructure space are commercial products with proprietary models. The deploying organisation does not have access to the model weights, the training data, or the detailed evaluation methodology. This creates a tension with the AI Act’s transparency requirements.
Article 13 requires that high-risk AI systems be designed to be sufficiently transparent for deployers to interpret the system’s output and use it appropriately. Article 26 requires deployers to use the system in accordance with the instructions of use and to monitor its operation.
In practice, this means deploying organisations must demand from their vendors: documentation of the agent’s capabilities and known limitations, evaluation results for the specific operational domain, clear specification of what the agent can and cannot do reliably, and a mechanism for the deployer to monitor and override the agent’s behaviour.
If the vendor cannot provide this, deploying the agent in a regulated environment creates an unquantified risk. The deployer is accountable under NIS2 and the AI Act regardless of what the vendor promises in a sales pitch.
What this means for infrastructure teams
Infrastructure teams adopting agentic AI in EU-regulated environments need to address four things before deployment.
First, classify the agent’s actions by consequence level and map them to the autonomy gradient. This determines where human gates are required and what evidence must be captured.
Second, implement structured evidence capture from day one. Retrofitting audit trails onto an agent that was deployed without them is painful and produces lower-quality evidence. The evidence schema should be agreed with your compliance team before the agent is deployed.
Third, define the circuit breaker conditions. Under what circumstances does the agent stop? What does “stop” mean in terms of preserved state and ongoing monitoring? What is the escalation path?
Fourth, document the accountability chain. When the agent acts, who is responsible? The answer is not “the AI.” The answer is a named role with documented authority and the evidence to prove that the authority was exercised appropriately.
Conclusion
Agentic AI in infrastructure operations is not a future scenario. It is a present reality that is expanding rapidly. The engineering benefits are real. The governance gap is equally real.
EU regulation does not prohibit autonomous agents in infrastructure. It requires that they be transparent, traceable, overseen, and accountable. These are architectural properties, not features that can be bolted on after deployment.
The organisations that will deploy agentic AI successfully in regulated environments are the ones that treat the guardrail architecture as a first-class engineering concern – not as a compliance checkbox, but as the infrastructure that makes the agent trustworthy enough to operate. Scoped authority, structured evidence, human gates at consequence boundaries, and circuit breakers for safe-halt. The pattern is not complicated. The discipline of implementing it is what separates production-grade deployments from experiments that will not survive their first audit.