EU AI Act compliance tools need runtime evidence, not policy templates

At a glance

What this is: This guide says EU AI Act compliance platforms fail if they stop at policy templates, because auditors need runtime evidence, shadow AI discovery, and exportable proof that controls actually ran.

Why it matters: For IAM, GRC, and AI security teams, the issue is whether governance can follow AI systems into production, where unmanaged local tools and agents bypass inventories, logs, and static approval workflows.

Context

EU AI Act compliance is not a document exercise. For high-risk systems, the control question is whether a platform can prove that risk classification, oversight, and enforcement happened during real runtime activity, not just in policy decks or workflow screenshots.

The article focuses on enterprise AI governance across cloud-native and multi-cloud environments, where local tools, shadow AI, and agent workflows can sit outside IAM logs and traditional cloud inventories. That is a genuine identity and governance problem because the systems acting on data may not appear in the normal control plane.

Key questions

Q: What fails when EU AI Act compliance tools only produce policy reports?

A: Policy-only tools fail because they can describe governance intent but cannot prove that discovery, risk classification, approvals, or runtime enforcement actually occurred. Under the EU AI Act, that gap becomes an audit risk, especially for high-risk systems. Practitioners need evidence that survives independent review, not just screenshots or manual exports.

Q: Why do shadow AI tools create such a large EU AI Act governance gap?

A: Because unmanaged AI assets often sit outside the logs and inventories that teams use to govern normal infrastructure. If local models, agents, or MCP-connected workflows are invisible, then risk classification, oversight, and approval controls start from an incomplete asset base. That leaves a compliance programme unable to prove full coverage.

Q: Should organisations treat runtime monitoring as part of AI governance or as a separate security task?

A: Treat it as part of governance. AI systems can drift after release through retraining, data changes, or expanded use, so approval without monitoring only captures one moment in time. Runtime assurance closes the gap between what was approved and what is actually running.

Q: Should AI governance teams prioritise evidence collection over framework mapping?

A: Yes, when the question is audit survival rather than policy alignment. Framework mapping is useful only if it sits on top of real evidence that the control executed in production. Without that evidence, mappings to ISO 42001, MITRE ATLAS, or the NIST AI RMF become labels rather than proof.

Technical breakdown

Why policy templates fail runtime audit tests

Policy templates describe intent, but they do not prove control execution. EU AI Act audits need evidence that a control was enforced during inference, approval, or monitoring events, which means timestamps, immutable trails, and exportable artifacts matter more than static attestations. In practice, a governance workflow without runtime records cannot demonstrate that a model stayed within policy when it mattered most.

Practical implication: Treat policy documentation as supporting material, not as audit evidence.

Shadow AI breaks inventory and logging assumptions

Shadow AI appears where governance tooling is weakest: local installations, unmanaged agents, embedded MCP servers, and developer-run model stacks. These assets often bypass IAM logs and cloud inventory systems, so the organisation never sees the full AI estate it is supposed to govern. Once discovery fails, every downstream control, from risk classification to oversight, starts with an incomplete dataset.

Practical implication: Build discovery that can find AI assets outside cloud-native tagging and standard identity logs.

Runtime enforcement is the difference between claims and proof

Runtime enforcement means the control acts while the workload is running, not after a review cycle. In this article, that includes continuous monitoring, kernel-level enforcement, and evidence collection tied to actual production behaviour. For AI governance, this shifts assurance from narrative compliance to observable control performance, which is what regulators and auditors increasingly expect.

Practical implication: Prioritise controls that can capture and constrain behaviour in production.

Threat narrative

Attacker objective: The practical objective is to exploit unmanaged AI surfaces or governance gaps before they are detected, then avoid leaving audit-grade evidence of control failure.

1. Entry begins when developer-installed or locally run AI assets, such as Ollama instances, MCP servers, or LangChain agents, operate outside the organisation's managed inventory.
2. Credential and governance blind spots emerge because these tools often bypass IAM logs and cloud inventories, so the AI estate is not fully visible to control owners.
3. Impact follows when auditors or regulators ask for proof of runtime control execution and the organisation can only produce static policy documents instead of operational evidence.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime evidence is now the controlling concept for EU AI governance: if a platform cannot show that a control operated during production activity, it does not satisfy the audit problem the Act creates. Static policy artefacts may support a control story, but they do not prove control execution. Practitioners should judge tools by evidence integrity, not by how complete the dashboard looks.

Shadow AI discovery is an identity governance problem, not just a discovery problem: unmanaged local models, agents, and MCP-connected workflows can sit outside the identity systems that teams normally trust. That means the governance gap is not only visibility, but also accountability for systems that act without appearing in the normal lifecycle. Practitioners should treat undiscovered AI assets as ungoverned identities until proven otherwise.

AI governance debt is the right shorthand for this market shift: organisations that postponed runtime controls now have to retrofit evidence, monitoring, and framework mapping under regulatory pressure. That debt compounds quickly because every missing discovery path or approval trail becomes a future audit finding. Practitioners should assume the shortest path to compliance is operational proof, not more policy language.

Framework mapping only matters when it is tied to behaviour: MITRE ATLAS, ISO 42001, and the NIST AI RMF are useful only when they connect to actual enforcement, logging, and response workflows. Otherwise, framework coverage becomes another layer of paper compliance. Practitioners should insist that each mapped control produces a verifiable runtime signal.

The EU AI Act raises the bar for AI control ownership across security and GRC teams: governance can no longer live only in the compliance function if the operational evidence sits in Kubernetes, runtime telemetry, and agent logs. That shifts responsibility toward platform and infrastructure teams with security, audit, and legal oversight aligned around the same proof set. Practitioners should redesign ownership around evidence production, not just policy approval.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Ultimate Guide to NHIs — Regulatory and Audit Perspectives

What this signals

AI governance debt is building faster than most programmes can evidence. Teams that can describe their control set but cannot prove runtime execution will face a widening gap between compliance language and audit reality. The practical response is to redesign governance around evidence generation, not around document production.

Shadow AI discovery is becoming the first real control boundary for EU AI Act readiness. If local models, embedded agents, and MCP-connected workflows are not in the inventory, every later control is operating on partial truth. That is why runtime discovery and continuous monitoring now matter more than one-time reviews.

52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. That shift reflects where the evidence actually lives. For practitioners, it means the teams that run platforms increasingly own the proof required for AI governance.

For practitioners

• Define an audit-evidence baseline for every AI system Require timestamped proof for discovery, classification, approval, runtime monitoring, and exportable artifacts before a platform is accepted.
• Inventory shadow AI outside IAM and cloud logs Search for local model runtimes, embedded agents, MCP servers, and developer-run tooling that do not appear in standard inventory sources.
• Map controls to AI governance frameworks Align discovered assets and enforcement points to MITRE ATLAS, ISO 42001, and the NIST AI RMF so evidence can be traced consistently.
• Test whether runtime monitoring produces usable artefacts Verify that monitoring outputs can be exported as PDF, CSV, or JSON and still preserve enough detail for audit review and legal use.
• Separate policy documentation from control proof Treat questionnaires and policy templates as supporting material only, and require direct operational evidence for any control claimed in the audit pack.

Key takeaways

• The article argues that EU AI Act readiness depends on operational evidence, not on policy templates that only describe intent.
• Shadow AI creates governance blind spots because unmanaged models and agents can evade the inventories and logs used by standard control processes.
• Runtime monitoring, continuous evidence collection, and exportable artefacts are the controls most likely to survive real audit scrutiny.

Key terms

• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Audit-Ready Evidence: Audit-ready evidence is access proof that can be retrieved directly from the control system without manual reconstruction. It should show who approved access, what policy they used, when the decision occurred, and whether any exceptions or compensating controls were applied.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern identity control. It helps security and governance teams connect operational proof to the identity systems their programmes rely on.