Runtime evidence for Spain’s AI Act: what AESIA guidance changes

At a glance

What this is: AESIA’s December 2025 guidance makes EU AI Act compliance an evidence-driven, runtime control problem for high-risk AI systems.

Why it matters: IAM, AI governance, and security teams need controls that can prove continuous enforcement, especially where models handle prompts, data, and human oversight.

By the numbers:

• The Spanish AI regulatory sandbox tested 12 high-risk AI systems across six sectors, including biometrics, employment, healthcare, and critical infrastructure.
• AESIA published 16 practical guides in December 2025, including 13 on technical requirements and one checklist per obligation.
• 24 months after the EU AI Act enters

👉 Read AccuKnox’s analysis of Spain’s AI Act runtime evidence requirements

Context

The core governance gap is not whether organisations have AI policies, but whether they can prove that risks are controlled while the system is running. For high-risk AI, the EU AI Act shifts attention from intent to evidence, which means logging, lifecycle risk management, robustness, and human oversight become operational controls rather than compliance language. That is especially relevant where AI systems interact with prompts, responses, sensitive data, and decision workflows.

This matters to AI governance and security teams because a static assessment cannot by itself satisfy a continuous-control requirement. Where identity and access controls intersect with AI systems, the same evidence question appears: who or what can act, what it can see, and whether those boundaries are enforced in runtime. In practice, that brings AI governance closer to IAM-style control verification than to one-off policy review.

Key questions

Q: How should security teams prove that a high-risk AI system is actually controlled at runtime?

A: They should produce evidence from the live control path, not rely on policy documents. That means logging prompts, responses, policy decisions, blocks, and overrides in a way that ties directly to the risk controls the AI system is supposed to enforce. If the control cannot show its work, it is not audit-ready.

Q: Why do policy documents fall short for EU AI Act compliance evidence?

A: Because the EU AI Act is concerned with continuous control of risk, robustness, and record-keeping across the lifecycle. A document can describe intent, but it cannot show how the system behaved when a prompt injection, out-of-scope request, or sensitive-data attempt occurred. Supervisors will want runtime proof that the boundary was enforced.

Q: What are the signs that AI governance controls are only paper-based?

A: Common signs include missing prompt-level logs, no record of blocked responses, no evidence that red-team findings were closed in production, and no trace from control decision to audit record. If teams cannot reconstruct who submitted what, what the model returned, and what was prevented, governance is incomplete.

Q: How do EU AI Act requirements differ from traditional security controls in practice?

A: Traditional security controls often focus on access, hardening, or periodic review. The AI Act adds a continuous evidentiary requirement around lifecycle risk management, human oversight, logging, and robustness. That means teams must design controls that both enforce policy and generate records a supervisor or auditor can inspect.

Technical breakdown

Why runtime evidence matters more than policy for the EU AI Act

The EU AI Act requires high-risk providers to manage risk across the full lifecycle, keep automatic records of relevant events, and support accuracy, robustness, cybersecurity, and human oversight. Those requirements are control outcomes, not documentation exercises. A policy can describe the intended boundary of a model, but only runtime enforcement can show when prompts are blocked, when responses are suppressed, and when a system stays inside scope under pressure.

Practical implication: Practitioners should treat logging and inline enforcement as compliance evidence, not optional telemetry.

How prompt firewalls produce audit-ready AI control evidence

A prompt firewall sits between the user, application, and model as a policy enforcement point. It inspects prompts and responses, blocks sensitive data, restricts out-of-scope interactions, and records each decision. That changes red teaming from a point-in-time assessment into a continuous control loop because failed probes, refusals, and policy decisions become durable evidence of enforcement. The useful distinction is not detection versus prevention, but whether the control can demonstrate that it prevented unsafe output while preserving a trace for audit.

Practical implication: Use inline policy enforcement where the audit trail must prove both the block and the reason for the block.

Why ENS traceability aligns with AI Act record-keeping

Spain’s Esquema Nacional de Seguridad focuses on access control, confidentiality, integrity, traceability, authenticity, and availability. For public-sector deployments and suppliers, the most relevant overlap is traceability, because the same event trail that supports AI Act record-keeping also supports ENS evidence of controlled and auditable operation. That makes runtime AI controls useful beyond a single regulation: they help unify compliance evidence across AI governance and public-sector security requirements.

Practical implication: Map AI runtime logs to traceability requirements early so one control set can support both AI Act and ENS reviews.

Threat narrative

Attacker objective: The objective is to force model behaviour outside the approved control boundary while avoiding a reliable audit trail.

1. Entry occurs when a user or application submits a prompt that attempts to push a high-risk model beyond its approved scope.
2. Escalation happens when prompt injection or unsafe input seeks to bypass policy, leak sensitive data, or influence the model’s behaviour.
3. Impact is the generation of out-of-scope, unsafe, or unlogged model output that cannot be defended during audit or supervisory review.

NHI Mgmt Group analysis

Evidence, not intention, is now the decisive standard for AI governance. The EU AI Act and AESIA guidance together move compliance away from paper controls and toward runtime proof. That matters because AI systems are evaluated on what they do continuously, not what a policy says they should do once. For practitioners, the discipline shifts toward control observability and traceable enforcement, not static approval workflows.

Runtime policy enforcement is becoming the control plane for AI governance. A prompt firewall does not solve governance by itself, but it turns boundary-setting into a measurable operating condition. That is a different category of assurance than a model card or a one-time red-team report. For teams governing AI systems, the real question is whether the control can refuse, record, and explain its own decisions under live conditions.

Traceability is the named concept that connects AI Act compliance to operational security. In this context, traceability means the organisation can reconstruct what the model saw, what it produced, and what was blocked. That creates a stronger evidentiary chain for supervisors and internal risk owners. For practitioners, traceability should be designed as a runtime property, not retrofitted after an incident.

AI governance is converging with identity and access control principles. When a model, a user, and an application interact, the governance question resembles authorised access: who can submit, what can be accessed, and which outputs are allowed to leave the boundary. That intersection is where identity teams add value to AI programmes, especially when models interact with sensitive data or privileged workflows. Practitioners should align AI controls with the same rigor used for access verification and auditability.

Spanish compliance is pushing the market toward evidence-producing controls, not checkbox tooling. AESIA’s guidance and ENS both reward systems that generate continuous records, not just better policy language. That will favour architectures that can enforce, log, and demonstrate control in the same transaction. For practitioners, the market signal is clear: adopt controls that can survive scrutiny from both AI supervisors and security auditors.

What this signals

Runtime evidence is becoming the organising principle for AI governance programmes. Teams that cannot show prompt-level decisions, block events, and exception handling will struggle to satisfy both internal risk owners and external supervisors. For identity and security leaders, that means treating AI control telemetry as a governance asset, not an engineering afterthought.

Traceability will matter more as AI systems move into regulated workflows. Spanish public-sector deployments, and the suppliers that serve them, will need evidence that can survive audit across both AI governance and security frameworks. The practical implication is to design logs, control points, and review workflows so they are usable by compliance, security, and model-risk teams at the same time.

AI governance and identity governance are starting to converge at the control boundary. The more an AI system can act, retrieve, or expose data, the more it resembles a governed access path that needs assurance, logging, and lifecycle ownership. Teams should prepare for AI controls to be measured with the same discipline used for privileged access and service-account oversight.

For practitioners

• Build runtime evidence into AI governance Define the evidence your high-risk AI system must produce during normal operation, including prompt decisions, blocked outputs, and escalation events. Tie those records to the obligations in the EU AI Act and the traceability expectations in ENS so one control plane supports both reviews.
• Place policy enforcement inline with the model Use an enforcement layer between the application and the model so unsafe prompts can be blocked before generation, not analysed after the fact. Preserve the full decision trail for each refusal so auditors can verify control operation rather than reading a policy statement.
• Run red teaming on every material model change Retest prompts, retrieval paths, and output handling whenever the model, system prompt, or surrounding application changes. Keep the adversarial test record with the production evidence because point-in-time assurance does not satisfy a continuous-control expectation.
• Map AI logs to public-sector traceability requirements If the deployment touches Spanish public bodies or suppliers, map runtime logs to ENS traceability and integrity requirements before go-live. That reduces procurement friction and makes the audit story consistent across security and AI governance teams.

Key takeaways

• Spain’s AESIA guidance makes EU AI Act compliance a runtime evidence problem, not a policy-writing exercise.
• Prompt firewalls and red teaming matter because they generate the audit trail that continuous AI governance requires.
• Identity and security teams should align AI controls with traceability, lifecycle evidence, and enforceable boundaries now.

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.
• Package Firewall: A package firewall is a control that blocks or screens software packages before they enter a development or build environment. It is used to prevent vulnerable, malicious, or non-compliant dependencies from reaching downstream pipelines where later detection may be too late to reduce risk.
• Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.
• Human Oversight: Human oversight is the requirement that a person remains responsible for reviewing, approving, or correcting AI-driven output before it causes a material action. In governance terms, it is the control that prevents automation from becoming unowned authority.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• How the prompt firewall enforces policy between users, applications, and the model in live traffic
• The mapping between AI Act obligations, AESIA guidance, and runtime control evidence
• Why the same enforcement model can support ENS traceability in Spanish public-sector deployments
• The vendor's framing of red teaming as an operational proof mechanism rather than a one-time test

👉 The full AccuKnox article covers prompt firewall enforcement, red teaming evidence, and ENS mapping detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a practical foundation for building stronger control and audit models across identity-led security programmes.