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

At a glance

What this is: Spain’s AESIA guidance reframes EU AI Act compliance as a runtime evidence problem, where high-risk AI systems must demonstrate continuous control, logging, robustness, and oversight.

Why it matters: For AI governance, IAM, and security teams, the key shift is that policy alone is no longer enough, because control decisions now need to be enforced and auditable while the system is running.

By the numbers:

• AESIA published 16 practical guides in December 2025, including 13 on technical requirements and a per-obligation checklist for providers and deployers of high-risk AI systems.
• The Spanish regulatory sandbox tested 12 high-risk AI systems across six sectors, including biometrics, employment, healthcare, and critical infrastructure.
• The EU AI Act requires high-risk providers, under Articles 8 to 17, to run a lifecycle risk-management system, automatically log events, and design for accuracy, robustness, and cybersecurity.
• Annex III high-risk obligations apply 24 months after entry into force, while prohibited-practice rules applied at six months.

Context

The governance gap here is simple: AI teams often have policies about risk, logging, and oversight, but not runtime controls that can prove those requirements are being met continuously. In regulated AI environments, evidence has become part of the control itself, especially when systems can be manipulated through prompts, outputs, or data exposure.

Spain’s AESIA guidance makes that gap visible for EU AI Act programmes because it operationalises high-risk obligations into checklists and technical expectations. The article’s core identity angle is that AI systems now need governance artefacts that can be inspected, logged, and mapped to control enforcement, not just written into policy documents.

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 static AI policies fall short for EU AI Act compliance?

A: Static policies describe intent, but they do not prove that risks are controlled continuously. High-risk AI obligations depend on lifecycle risk management, logging, robustness, and human oversight being observable in operation. If the organisation cannot show how those controls worked during actual use, policy documents alone will not satisfy supervision or audit demands.

Q: What are the signs that an AI governance control is not producing usable evidence?

A: The main warning signs are manual log reconstruction, missing refusal records, unclear escalation paths, and a gap between what the policy says and what the system actually allowed. If evidence has to be assembled after the fact, the control is not integrated into runtime governance and will be weak under review.

Q: Which matters more for regulated AI: red teaming or runtime enforcement?

A: They serve different purposes, but runtime enforcement is what carries the day in production because it prevents unsafe behaviour and creates the audit trail. Red teaming is still essential because it reveals how the system fails, but those findings only matter if they are translated into enforced controls and repeatable evidence.

Technical breakdown

Why runtime evidence matters for EU AI Act compliance

The EU AI Act turns high-risk AI compliance into a control problem, not a paper exercise. Risk management, logging, robustness, and human oversight only satisfy the regulation if they are demonstrable during operation, not after an incident review. That is why runtime enforcement matters: the system must generate its own evidence while decisions are being made. In practice, this moves AI governance closer to continuous control validation, where each blocked action, logged event, or intervention becomes part of the compliance record.

Practical implication: treat runtime logging and policy enforcement as compliance controls, not optional observability features.

How a prompt firewall produces compliance evidence

A prompt firewall sits between users, applications, and the model as a policy enforcement point. It inspects prompts and responses, blocks sensitive data, restricts out-of-scope interactions, and records every decision. That makes it materially different from passive monitoring because the same control both prevents unsafe behaviour and preserves the evidence trail. For EU AI Act programmes, that matters because a refusal, escalation, or block can be tied directly to the control objective the regulation expects.

Practical implication: place enforcement inline so the audit trail is created by the control, not reconstructed later.

Why automated red teaming belongs in the compliance workflow

Red teaming gives practitioners adversarial evidence that a model can resist prompt injection, unsafe outputs, or boundary violations. The article positions it as part of the proof chain, not a separate security exercise. That is important because AI governance often fails when testing is treated as a one-time validation rather than a repeatable control input. For high-risk AI, adversarial testing should feed the assurance case and be repeated when the model, prompts, or deployment context changes.

Practical implication: tie red-teaming results to model change management and compliance sign-off.

Threat narrative

Attacker objective: The objective is to bypass model boundaries, expose sensitive information, or force unsafe behaviour that defeats the organisation’s compliance position.

1. Entry occurs through manipulated prompts or adversarial inputs aimed at pushing the model beyond its intended scope.
2. Credential or data exposure follows when the model is induced to reveal sensitive information or produce restricted content.
3. Impact is governance failure, because the organisation cannot demonstrate that risks were controlled continuously or that refusals and blocks were logged.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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 becoming the new compliance boundary for AI governance. The EU AI Act and AESIA guidance both push high-risk AI programmes away from static documentation and toward continuously enforced controls. That changes the governance burden from proving intent to proving operation. For practitioners, the control is only real if it creates evidence as it acts.

AI governance debt builds when teams separate policy from enforcement. Organisations often write risk, logging, and oversight requirements into process documents while leaving runtime behaviour ungoverned. That gap becomes audit debt the moment a supervisor asks how a specific unsafe prompt was blocked or why a response was refused. Practitioners should treat evidence generation as part of the control plane, not the reporting layer.

Prompt boundary enforcement is now an AI security control, not just a content filter. The article’s runtime firewall framing reflects a broader shift in AI security: the boundary between allowed and disallowed model behaviour has to be enforced at the point of interaction. That is where the identity bridge matters as well, because access, delegation, and oversight all depend on who or what can invoke the model and under what conditions. Practitioners should align AI runtime controls with governance expectations before deployment scales.

Spain’s public-sector AI market will increasingly reward controls that map cleanly to supervision requirements. AESIA’s guidance makes procurement, assurance, and auditability converge around the same evidence set. That means providers and deployers need a control narrative that survives regulatory review, not just a technical demonstration. The practical conclusion is that runtime controls must be explainable to auditors, not only effective against attacks.

AI red teaming should be treated as an assurance input to the lifecycle, not an isolated test event. When adversarial testing is separated from change management, the organisation learns about failure without embedding the lesson into the running control model. The stronger pattern is to feed test outcomes back into enforcement, logging, and oversight. Practitioners should close the loop between testing and control validation.

From our research library:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

Runtime evidence is now a governance requirement, not a reporting convenience. Teams that separate model policy from enforcement will struggle to satisfy auditors because the necessary proof has to be created where the model acts. The practical shift is from documenting controls to instrumenting them so that every refusal, block, and escalation can be inspected later.

Runtime evidence also sharpens the identity boundary around AI systems. Once prompts, responses, and blocks become part of the assurance case, access to the model and authority to invoke it become governance questions, not just technical ones. Organisations that treat AI runtime as an identity and control plane will be better positioned to manage both compliance and abuse.

New AI providers can create exposure faster than guardrails can mature, as AccuKnox notes in related secrets research showing DeepSeek alone generated 113,000 new exposed API keys in 2025. That is a reminder that AI rollouts need both enforcement and inventory discipline from day one.

For practitioners

• Implement inline runtime enforcement Place a policy enforcement layer between users, applications, and the model so prompts, responses, and blocks are controlled at execution time.
• Build an auditable decision trail Log every prompt, response, refusal, and block in a format that can support regulatory review and internal assurance.
• Tie red teaming to change control Repeat adversarial testing whenever prompts, models, or deployment context change so the test evidence stays current.
• Map controls to Spanish public-sector requirements Where deployments serve Spain’s public sector or suppliers, map runtime controls to ENS traceability and integrity expectations as well as EU AI Act duties.

Key takeaways

• Spain’s AESIA guidance makes high-risk AI compliance a runtime evidence problem, because supervisors will expect proof that controls operated continuously.
• The useful evidence is generated by the control itself, especially when a prompt firewall blocks unsafe inputs and records every decision.
• Practitioners should align red teaming, logging, and enforcement so that AI governance survives both audit review and adversarial testing.

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.
• High-Risk AI System: A high-risk AI system is one whose outputs can materially affect a person’s rights, opportunities, or safety. These systems need stronger oversight because errors, bias, or unauthorized actions can create legal exposure as well as security and trust problems.
• Adversarial Testing: A testing approach that tries to break a policy by using hostile or unexpected inputs. For PBAC and AI access controls, that means probing for prompt injection, role crossover, leakage, and connector drift so the organisation can see whether the policy still holds under pressure.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect runtime AI control decisions with broader identity and access governance.